csns.calstatela.edu

PART I Introduction to Software Engineering Part I provides a general overview of the field and the elements of Software Engineering. Most of the main issues are introduced for (possibly) a more complete analysis in subsequent parts of this course. California State University, Fall 2008, Part I 1 Chapter 1 Software and Software Engineering California State University, Fall 2008, Part I 2 Software engineering

The economies of ALL developed nations are dependent on software More and more systems are software controlled Software engineering is concerned with theories, methods and tools for professional software development Software engineering expenditure represents a significant fraction of GNP in all developed countries California State University, Fall 2008, Part I 3 Software costs Software costs often dominate system costs. The costs of software on a PC are often greater than the hardware cost

Software costs more to maintain than it does to develop. For systems with a long life, maintenance costs may be several times development costs Software engineering is concerned with costeffective software development California State University, Fall 2008, Part I 4 What is software? Computer programs and associated documentation Software products may be developed for a particular customer or may be developed for a general market Software products may be

Generic - developed to be sold to a range of different customers Bespoke (custom) - developed for a single customer according to their specification California State University, Fall 2008, Part I 5 What is software engineering? Software engineering is an engineering discipline which is concerned with all aspects of software production Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on the problem to be solved, the development constraints and the resources available California State University, Fall 2008, Part I 6

Difference between SE and computer science? Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software Computer science theories are currently insufficient to act as a complete underpinning for software engineering California State University, Fall 2008, Part I 7 Computer Programs are not Software but part of it Algorithm, Recipe & Computer Program

Algorithms and Recipes are Finite Set of well defined steps to accomplish a task/solve a problem The output is the completion of the task or solution to the problem Any reference as to the number of steps? The number of steps in an Algorithm and Recipe are finite Typically the number of steps in a Computer Program is finite The number of steps in a Computer Program may be infinite Program Example: 30 GOTO 30 (an infinite loop, infinite steps) Computer Programs with Loops are Not Nice It is impossible to tell if a computer program (with loops) halts or run forever (Alan Turings halting problem) This is not a concern in Software Engineering but in Theory of Computer Science Software Engineering assumes that all programs being developed will work as designed and developed.

California State University, Fall 2008, Part I 8 Some Software Characteristics? software is engineered not manufactured software doesnt wear out (doesnt it?) software is usually complex or very complex software is mostly custom built California State University, Fall 2008, Part I 9 What is Software? Software is a set of items or objects

that form a configuration that includes programs documents data structures data... California State University, Fall 2008, Part I 10 Softwares Dual Role Software is a product Delivers computing potential Produces, manages, acquires, modifies, displays, or transmits information Software is a vehicle for delivering a product Supports or directly provides system functionality Controls (affects) other programs (e.g., an operating system) Effects communications (e.g., networking software) Helps build other software (e.g., software California State University, Fall 2008, Part I 11

Wear vs. Deterioration Hardware Failure Rate: Bathtub Diagram Failure Rate Infant Mortality Wear Out time California State University, Fall 2008, Part I 12 Legacy Software Why must it change? software must be adapted to meet the needs of new computing environments or technology. software must be enhanced to implement new business requirements. software must be extended to make it interoperable with other more modern systems or databases.

software must be re-architected to make it viable within a network environment. California State University, Fall 2008, Part I 13 Software Wear vs. Deterioration increased failure rate due to side effects Failure rate change actual curve idealized curve Time California State University, Fall 2008, Part I 14 Software Applications

system software (O.Ss., compilers, editors, databases) application software (business) engineering/scientific software embedded software (dashboard control, oven control) product-line software (spreadsheets, graphics) WebApps (Web applications) AI software (robotics, expert systems, voice recognition) California State University, Fall 2008, Part I 15 SoftwareNew Categories

Ubiquitous computingwireless networks Net-sourcingthe Web as a computing engine Open sourcefree source code open to the computing community (a blessing, but also a potential curse!) Also Data mining Grid computing Cognitive machines Software for nanotechnologies California State University, Fall 2008, Part I 16 Software Evolution Laws

The Law of Continuing Change (1974): E-type systems (real world software that will Evolve) must be continually adapted else they become progressively less satisfactory. The Law of Increasing Complexity (1974): As an E-type system evolves its complexity increases unless work is done to maintain or reduce it. The Law of Self Regulation (1974): The E-type system evolution process is selfregulating with distribution of product and process measures close to normal. The Law of Conservation of Organizational Stability (1980): The average effective global activity rate in an evolving E-type system is invariant over product lifetime. The Law of Conservation of Familiarity (1980): As an E-type system evolves all associated with it, developers, sales personnel, users, for example, must maintain mastery of its content and behavior to achieve satisfactory evolution.

The Law of Continuing Growth (1980): The functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime. The Law of Declining Quality (1996): The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes. The Feedback System Law (1996): E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base. Source: Lehman, M., et al, Metrics and Laws of Software EvolutionThe Nineties View, Proceedings of the 4th International Software Metrics Symposium (METRICS '97), IEEE, 1997, can be downloaded from: http://www.ece.utexas.edu/~perry/work/papers/feast1.pdf California State University, Fall 2008, Part I 17 Software Myths Affect managers, customers (and other non-technical stakeholders) and practitioners

Add more programmers to catch up (management) We can accommodate those changes later (customer) Quality can only be assessed with the program running (practitioner) Are believable because they often have elements of truth, but Invariably lead to bad decisions, therefore Insist on reality as you navigate your way through software engineering California State University, Fall 2008, Part I 18 Software Engineering (SE) Definition the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines (1969). the application of a systematic, disciplined,

quantifiable approach to the development, operation, an maintenance of software, that is, the application of engineering to software (1993) engineering discipline concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. Software Engineering is concerned with all the types of practical problems related to producing software. California State University, Fall 2008, Part I 19 Software Engineering Challenges How do we ensure the quality of the software that we produce? How do we meet growing demand and still maintain budget control?

How do we upgrade the aging software system? How do we avoid disastrous time delays? How do we successfully institute new software technologies? How do we successfully integrate the many components of a large complex software system? ??? California State University, Fall 2008, Part I 20 Software Engineering Most Challenging Two Goals Software MUST BE on time! One of the most challenging elements of quality complex software development and therefore of software engineering is to deliver it on schedule. Software MUST BE in budget!

The other most challenging aspect of quality complex software development and therefore of software engineering is to deliver the software within budget. California State University, Fall 2008, Part I 21 A Layered Technology Software Engineering is a layered process tools methods process model a quality focus The bedrock that supports SE is a quality focus. The foundation for SE is the process layer. SE methods provide the technical how tos for building S/W. SE tools provide (automated) support for the process & methods. California State University, Fall 2008, Part I 22

Chapter 2 Process: A Generic View California State University, Fall 2008, Part I 23 A Process Framework SOFTWARE PROCESS Process framework Umbrella Activities Framework activities # m (n m of them) work tasks work products QA checkpoints milestones & deliverables California State University, Fall 2008, Part I 24 Framework Activities (five)

California State University, Fall 2008, Part I Communication Requirements gathering Planning Schedule & risks Modeling Analysis of requirements Design Construction Code generation Testing Deployment (S/W delivery) 25 The Process Model: Adaptability the framework activities will always be

applied on every project ... BUT the tasks (and degree of rigor) for each activity will vary based on: the type of project characteristics of the project common sense judgment; concurrence of the project team California State University, Fall 2008, Part I 26 Umbrella Activities

Software project management (tracking & control) Risk management (includes quality of the product) Software quality assurance Formal technical reviews (remove errors) Measurement (assist in delivering the right S/W) Software configuration management Reusability management Work product preparation and production California State University, Fall 2008, Part I 27 The Capability Maturity Model Integration (CMMI) The CMMI defines each process area (5 of these areas are shown in the framework activities described earlier) in terms of specific goals and the specific practices required to achieve these goals. Specific goals establish the characteristics that must exist if the activities implied by a process area are to be effective. Specific practices refine a goal into a set of processrelated activities.

Capability Levels each process area (such as planning or requirements management) is formally assessed against the specific goals and practices and is rated according to six capability levels from level 0 to level 5. (Incomplete, Performed, Managed, Defined, Quantitatively and Optimized). 28 California State University, Fall 2008, PartManaged I CMMI Example: Project Planning Application The specific goals (SG) and some of the associated specific practices (SP) defined for project planning are: In addition to SGs & SPs. the CMMI defines a set of 5 generic goals (GG) which correspond to the 5

capability levels. California State University, Fall 2008, Part I SGs SPs 1. Establish estimates (Est.) 1. 2. 3. 4. Est. scope of the project Define project life cycle Est. effort and costs 2. Develop a project plan 1. 2.

3. 4. 5. Establish budget & schedule Identify project risks Plan for data management Plan for project resources . 3. Obtain commitmen t to the plan 1. Review plans that affect the project 2. Reconcile work and resource levels 3. Obtain plan commitment 29 Process Patterns

Process patterns define a set of activities, actions, work tasks, work products and/or related behaviors A template is used to define a pattern Typical examples: Customer communication (a process activity) Analysis (an action) Requirements gathering (a process task) Reviewing a work product (a process task) Design model (a work product) California State University, Fall 2008, Part I 30 Process Patterns: an example

A template is used to define a pattern Pattern Name: Prototyping Intent: build a prototype assessed by stakeholders (SHs) iteratively Type: phase pattern (other types are task & stage pattern) Initial context: (conditions that must be met prior to the initialization of this pattern) identify SHs; -communications SHs & S/W team; -the problem to be solved is identified; -initial parts has been understood. Problem: there is a clear recognition among SHs that there is a problem Solution: the prototyping process is described here Resulting context: the S/W prototyping is approved by SHs after which it may evolve or even be discarded Related patterns: customer-communications; iterative design; iterative development; customer assessment; requirement extraction. Known uses/examples: prototyping is recommended when

requirements are uncertain. California State University, Fall 2008, Part I 31 Process Assessment The process should be assessed to ensure that it meets a set of basic process criteria that have been shown to be essential for a successful software engineering. Many different assessment options are available: SCAMPI CBA IPI (CMM-Based Appraisal for Internal Process Improvement) SPICE (International Standard for Software Process Assessment) (Standard CMMI Assessment Method for Process

Improvement) http://www.cs.helsinki.fi/u/paakki/Pyhajarvi.pdf ISO 9001:2000 (International Organization of Standardization) http://www.praxiom.com/iso-9001.htm NASA: Software organizations have exhibited significant shortcomings in their ability to capitalize on the experience gained from completed projects. California State University, Fall 2008, Part I 32 Assessment and Improvement as they relate to S/W Process Software Process is examined by identifies

modifications to identifies capabilities and risk of Software Process Assessment Software Process Improvement leads to leads to Capability Determination motivates California State University, Fall 2008, Part I 33 The Personal Software Process (PSP)

Recommends five framework activities: Planning High-level design High-level design review Development Postmortem (determines the effectiveness of the process) stresses the need for each software engineer to identify errors early and as important, to understand the types of errors. represents a disciplined, metric-based approach to Software Engineering. California State University, Fall 2008, Part I 34

Team Software Process (TSP) Each project is launched using a script that defines the tasks to be accomplished Teams are self-directed: they plan & track their work. Measurement is encouraged. Risk is continually assessed and the team reacts to it. Measures are analyzed with the intent of improving the team process California State University, Fall 2008, Part I 35 The Primary Goal of Any Software Process: High Quality Remember: High quality = project timeliness + project affordability Why? Less rework!

California State University, Fall 2008, Part I 36 Product and Process If the process is weak, the end product will undoubtedly suffer. Read Margaret Davis brief essay: Process and Product: Dichotomy or Duality. Software Engineering Notes, ACM Press, Vol. 20, No. 2, April, 1995, pp. 17-18. California State University, Fall 2008, Part I 37 Chapter 3 Prescriptive Process Models California State University, Fall 2008, Part I 38

Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering That leads to a few questions If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work? California State University, Fall 2008, Part I 39 Prescriptive Models: Definition Prescriptive process models define a distinct set of:

activities, actions, tasks, milestones, and work products that are required to engineer high-quality software. These process models are not perfect, but they do provide a useful roadmap for software engineering work. California State University, Fall 2008, Part I 40 The Waterfall Model: First Version Communication project initiation requirement gathering Planning estimating scheduling tracking Modeling analysis

design Construction code test Deployment delivery support feedback Also called the classic life cycle is the oldest paradigm for software engineering. Cons: real projects rarely follow a sequential flow requirements are not initially completely explicit customer has to wait until deployment takes place if a problem occurs (most likely) is detected only at the end Pros: there is a level of feedback implicit in the model a linear model is easy to understand provides a nice simple model to work with California State University, Fall 2008, Part I 41 The Waterfall Model: Another Version There are many representations of the waterfall model with several stages (more

than 5) but for our practical purposes we will use 5 stages. Notice that coding occurs during the implementation stage. Requirements Definition System and Software Design Implementation and unit testing Integration and system testing Operation and maintenance California State University, Fall 2008, Part I 42 The Incremental Model increment #n Co mmuni c at i o n Planni ng Modeling analys is des ign C o n s t ru c t i o n c ode t es t

De p l o y m e n t d e l i v e ry fe e dba c k delivery of nt h increment increment # 2 Communic a t ion Planning Modeling analys is des ign Co n s t ru c t i o n c ode De p l o y m e n t t es t d e l i v e ry fe e d b a c k increment # 1 delivery of

2nd increment Communic at ion Planning Modeling analys is des ign C o n s t ru c t i o n c ode De p l o y m e n t t es t d e l i v e ry fe e dba c k delivery of 1st increment project calendar time California State University, Fall 2008, Part I 43 The Rapid Application Development (RAD) Model

Team # n Mo d e lin g business modeling data modeling process modeling C o n st ru ct io n component reuse automatic code generation testing Team # 2 Communication Modeling business modeling dat a modeling process modeling Planning Construction Team # 1 component reuse aut omat ic code

generat ion t est ing Modeling Deployment int egrat ion delivery feedback business modeling dat a modeling process modeling Construction component reuse aut omat ic code generat ion t est ing 60 - 90 days California State University, Fall 2008, Part I 44 Evolutionary Models: Prototyping

Qu ick plan Communication Mo de ling Quick de sign Deployment Delivery & Feedback California State University, Fall 2008, Part I Construct ion of prototype 45 Evolutionary Models: The Spiral planning estimation scheduling risk analysis communication modeling

analysis design start deployment delivery feedback California State University, Fall 2008, Part I construction code test 46 Evolutionary Models: Concurrent none Modeling activity represents the state of a software engineering activity or task Under development A waiting

changes Under review Under revision Baselined Done California State University, Fall 2008, Part I 47 Still Other Process Models Component based developmentthe process to apply when reuse is a development objective Formal methodsemphasizes the mathematical specification of requirements AOSD(aspect oriented software development)

provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Processa use-case driven, architecturecentric, iterative and incremental software process closely aligned with the Unified Modeling Language (UML) California State University, Fall 2008, Part I 48 The Unified Process (UP) Elaboration elaboration Inception inception inception inception construction Release software increment transition production

California State University, Fall 2008, Part I 49 UP Phases UP Phases Inception Elaboration Construction Transition Production Workflows Requirements Analysis Design Implementation Test Support Iterations #1 California State University, Fall 2008, Part I

#2 #n-1 #n 50 UP Work Products Inception phase Vision document Init ial use-case model Init ial project glossary Init ial business case Init ial risk assessment . Project plan, phases and it erat ions. Business model, if necessary. One or more prot ot ypes I nc ept i o n California State University, Fall 2008, Part I Elaboration phase Use-case model

Supplement ary requirement s including non-funct ional Analysis model Soft ware archit ect ure Descript ion. Execut able archit ect ural prot ot ype. Preliminary design model Revised risk list Project plan including it erat ion plan adapt ed workflows milest ones t echnical work product s Preliminary user manual Construction phase Design model Soft ware component s Int egrat ed soft ware increment Test plan and procedure Test cases Support document at ion user manuals inst allat ion manuals descript ion of current increment

Transition phase Delivered soft ware increment Bet a t est report s General user feedback 51 Chapter 4 Agile Development California State University, Fall 2008, Part I 52 The Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the

right, we value the items on theKent left Beck more. et al California State University, Fall 2008, Part I 53 What is Agility? Effective (rapid and adaptive) response to change Effective communication among all stakeholders Drawing the customer onto the team Organizing a team so that it is in control of the work performed Yielding Rapid, incremental delivery of software California State University, Fall 2008, Part I 54 An Agile Process

Is driven by customer descriptions of what is required (scenarios) Recognizes that plans are short-lived Develops software iteratively with a heavy emphasis on construction activities Delivers multiple software increments Adapts as changes occur California State University, Fall 2008, Part I 55 Extreme Programming (XP) The most widely used agile process, originally proposed by Kent Beck (www.extremeprogramming.org/rules.html). XP Planning

Begins with the creation of user stories that describe required features and functionality of the software to be built. Agile team assesses each story (written on an index card) and assigns a cost (measured in development weeks). Customer assigns a value (priority) to each story Stories are grouped to for a deliverable increment A commitment is made on delivery date After the first increment project velocity is used to help define subsequent delivery dates for other increments California State University, Fall 2008, Part I 56 Extreme Programming (XP) XP Design

XP Coding Rigorously follows the KIS (Keep It Simple) principle Encourage the use of CRC (Class-Responsibility-Collaborator) cards For difficult design problems, suggests the creation of spike solutions (a design prototype). Encourages refactoring (an iterative refinement of the internal program design that does not affect the external behavior of the code) Recommends the construction of a unit test for a story before coding commences Encourages pair programming (two efficient and compatible programmers work together at one computer workstation to create code for one story) XP Testing

All unit tests are executed (easily and repeatedly) daily Acceptance tests are defined by the customer and executed to assess customer visible functionality California State University, Fall 2008, Part I 57 Extreme Programming (XP) user stories values acceptance test criteria iteration plan simple design CRC cards spike solutions prototypes refactoring pair programming Release software increment

project velocity computed unit test continuous integration acceptance testing California State University, Fall 2008, Part I 58 Adaptive Software Development Focus on human collaboration and team self-organization (www.adaptivesd.com). ASD distinguishing features

Mission-driven planning Component-based focus Uses time-boxing (this is an incremental S/W paradigm: a schedule for each incremental delivery) Explicit consideration of risks Emphasizes collaboration for requirements gathering Emphasizes learning throughout the process California State University, Fall 2008, Part I 59 Adaptive Software Development adaptive cycle planning uses mission statement project constraints basic requirements Requirements gathering J AD mini-specs time-boxed release plan Release software increment

adjustments for subsequent cycles components implemented/ tested focus groups for feedback formal technical reviews postmortems JAD = Joint Application Development, a popular technique for requirements gathering. Find more at www.carolla.com/wp-jad.htm. California State University, Fall 2008, Part I 60 Dynamic Systems Development Method Promoted by the DSDM Consortium (www.dsdm.org, www.cs3inc.com/DSDM.htm) DSDMdistinguishing features Similar in most respects to XP and/or ASD It is an evolution of RAD (rapid application development) practices Nine guiding principles

Active user involvement is imperative. DSDM teams must be empowered to make decisions. The focus is on frequent delivery of products. Fitness for business purpose is the essential criterion for acceptance of deliverables. Iterative and incremental development is necessary to converge on an accurate business solution. All changes during development are reversible. Requirements are baselined at a high level Testing is integrated throughout the life-cycle. California State University, Fall 2008, Part I 61 Dynamic Systems Development Method DSDM Life Cycle (with permission of the DSDM consortium) California State University, Fall 2008, Part I

62 Dynamic Systems Development Method DSDM Pizza Diagram California State University, Fall 2008, Part I 63 Scrum Originally proposed J Sutherland and his team mimicking the sport of Rugby, where everyone in the team pack acts together to move the ball down the field analogy to development is the team works together to successfully develop quality software Further developed by Schwaber and Beedle Scrumdistinguishing features

Development work is partitioned into low coupling packets Testing and documentation are on-going as the product is constructed Work occurs in sprints and is derived from a backlog of existing requirements Meetings are very short and sometimes conducted without chairs 64 California State University, Fall 2008, Part I Scrum California State University, Fall 2008, Part I 65 Crystal Proposed by Cockburn and Highsmith Crystaldistinguishing features

Actually a family of process models that allow maneuverability based on problem characteristics Face-to-face communication is emphasized Suggests the use of reflection workshops to review the work habits of the team California State University, Fall 2008, Part I 66 Feature Driven Development Originally proposed by Peter Coad et al FDDdistinguishing features Emphasis is on defining features Uses a feature template

a feature is a client-valued function that can be implemented in two weeks or less. the a(n) A features list is created and plan by feature is conducted Design and construction merge in FDD California State University, Fall 2008, Part I 67 Feature Driven Development California State University, Fall 2008, Part I 68 Agile Modeling

Originally proposed by Scott Ambler Suggests a set of agile modeling principles Model with a purpose Use multiple models Travel light (build only those models that provide value) Content is more important than representation Know the models and the tools you use to create them Adapt locally California State University, Fall 2008, Part I 69 Chapter 5 Practice: A Generic View California State University, Fall 2008, Part I

70 What is Practice? Practice is a broad array of concepts, principles, methods, and tools that you must consider as software is planned and developed. It represents the detailsthe technical considerations and how tosthat are below the surface of the software processthe things that youll need to actually build high-quality computer software. California State University, Fall 2008, Part I 71 The Essence of Practice George Polya, in a book written in 1945 (!), describes the essence of software engineering

practice Understand the problem (communication and analysis). Plan a solution (modeling and software design). Carry out the plan (code generation). Examine the result for accuracy (testing and quality assurance). At its core, good practice is common-sense problem solving California State University, Fall 2008, Part I 72 Core Software Engineering Principles Provide value to the customer and the user KISkeep it simple! but not any simpler Maintain the product and project vision

What you produce, others will consume Be open to the future consider what ifs Plan ahead for reuse but beware of general solutions. California State University, Fall 2008, Part I 73 Software Engineering Practices Consider the generic process framework Communication Planning Modeling Construction

Deployment Here, well identify Underlying principles How to initiate the practice An abbreviated task set California State University, Fall 2008, Part I 74 Communication Practices Principles

Listen Prepare before you communicate Facilitate the communication Face-to-face is best Take notes and document decisions Collaborate with the customer Stay focused Draw pictures when things are unclear Move on rather an iterating endlessly Negotiation works best when both parties win. California State University, Fall 2008, Part I 75 Communication Practices Initiation

The parties should be physically close to one another Make sure communication is interactive Create solid team ecosystems Use the right team structure An abbreviated task set Identify who it is you need to speak with Define the best mechanism for communication Establish overall goals and objectives and define the scope Get more detailed Have stakeholders define scenarios for usage Extract major functions/features Review the results with all stakeholders

California State University, Fall 2008, Part I 76 Planning Practices Principles 1. Understand the project scope 2. Involve the customer (and other stakeholders) 3. Recognize that planning is iterative 4. Estimate based on what you know 5. Consider risk 6. Be realistic 7. Adjust granularity (level of detail) as you plan 8. Define how quality will be achieved 9. Define how youll accommodate changes

10. Track what youve planned California State University, Fall 2008, Part I 77 Planning Practices Initiation Ask Boehms W5H2questions Why is the system begin developed? What will be done? When will it be accomplished? Who is responsible? Where are they located (organizationally)? How will the job be done technically and

managerially? How much of each resource is needed? California State University, Fall 2008, Part I 78 Planning Practices An abbreviated task set Re-assess project scope Assess risks Evaluate functions/features Consider infrastructure functions/features Create a coarse granularity plan

Number of software increments Overall schedule Delivery dates for increments Create fine granularity plan for first increment Track progress California State University, Fall 2008, Part I 79 Modeling Practices We create models to gain a better understanding of the actual entity to be built Analysis models represent the customer requirements by depicting the software in three different domains: the information domain, the functional domain, and the behavioral domain. Design models represent characteristics of the

software that help practitioners to construct it effectively: the architecture, the user interface, and component-level detail. California State University, Fall 2008, Part I 80 Analysis Modeling Practices Analysis modeling principles Represent the information domain Represent software functions Represent software behavior Partition the above representations to uncover details Move from essence toward implementation

Elements of the analysis model (Chapter 8) Data model Flow model Class model Behavior model California State University, Fall 2008, Part I 81 Design Modeling Practices Principles

Design must be traceable to the analysis model Always consider architecture of the system to be built Focus on the design of data Interfaces (both user and internal) must be designed User interface design tuned to the needs of enduser Components should exhibit functional independence Components should be loosely coupled Design representation should be easily understood The design model should be developed iteratively Elements of the design model Data design Architectural design Component design Interface design California State University, Fall 2008, Part I

82 Construction Practices Preparation principles: Before you write one line of code, be sure you: Understand of the problem youre trying to solve (see communication and modeling) Understand basic design principles and concepts. Pick a programming language that meets the needs of the software to be built and the environment in which it will operate. Select a programming environment that provides tools that will make your work easier. Create a set of unit tests that will be applied once the component you code is completed. California State University, Fall 2008, Part I

83 Construction Practices Coding principles: As you begin writing code, be sure you: Constrain your algorithms by following structured programming [BOH00] practice. Select data structures that will meet the needs of the design. Understand the software architecture and create interfaces that are consistent with it. Keep conditional logic as simple as possible.

Create nested loops in a way that makes them easily testable. Select meaningful variable names and follow other local coding standards. Write code that is self-documenting. Create a visual layout (e.g., indentation and blank lines) that aids understanding. California State University, Fall 2008, Part I 84 Construction Practices Validation Principles: After youve completed your first coding pass, be sure you: Conduct a code walkthrough when appropriate. Perform unit tests and correct errors youve uncovered. Refactor the code (improve its internal structure without altering its external structure).

California State University, Fall 2008, Part I 85 Construction Practices Testing Principles All tests should be traceable to requirements Tests should be planned long before testing begins The Pareto Principle (80-20 rule: 80% of the effects come from 20% of the causes) applies to testing Testing begins in the small and moves toward in the large (test integration by steps until all system is included) Exhaustive testing is not possible. California State University, Fall 2008, Part I

86 Deployment Practices Principles Manage customer expectations for each increment A complete delivery package should be assembled and tested A support regime should be established Instructional materials must be provided to end-users Buggy software should be fixed first, delivered later California State University, Fall 2008, Part I 87 Chapter 6 System Engineering

California State University, Fall 2008, Part I 88 System Engineering Elements of a computer-based system Software Hardware People Database Documentation Procedures Systems

A hierarchy of macro-elements California State University, Fall 2008, Part I 89 The Hierarchy Business or Product Domain World view Domain of interest Domain view System element Element view Detailed view California State University, Fall 2008, Part I 90 System Modeling

define the processes that serve the needs of the view under consideration. represent the behavior of the processes and the assumptions on which the behavior is based. explicitly define both exogenous and endogenous input to the model. exogenous inputs link one constituent of a given view with other constituents at the same level of other levels; endogenous input links individual components of a constituent at a particular view. represent all linkages (including output) that will enable the engineer to better understand the view. California State University, Fall 2008, Part I 91 System Modeling

A system engineer considers the following factors when determining alternative solutions: Assumptions that reduce the number of permutations thus enabling a model to reflect the problem in a reasonable manner Simplifications that enable the model to be created in a timely manner Limitations that help to bound the system Constrains that will guide the manner in which the model is created and the approach taken when it is created. Preferences that indicate the preferred architecture for all data, functions and technology California State University, Fall 2008, Part I 92

Business Process Engineering (BPE) uses an integrated set of procedures, methods, and tools to identify how information systems can best meet the strategic goals of an enterprise focuses first on the enterprise and then on the business area creates enterprise models, data models and process models creates a framework for better information management distribution, and control California State University, Fall 2008, Part I 93 System Architectures Three different architectures must be analyzed and designed within the context of business objectives and goals:

data architecture applications architecture technology infrastructure data architecture provides a framework for the information needs of a business or business function application architecture encompasses those elements of a system that transform objects within the data architecture for some business purpose technology infrastructure provides the foundation for the data and application architectures California State University, Fall 2008, Part I 94 The BPE Hierarchy Information strategy planning (ISP)

Business area analysis (BAA) strategic goals defined success factors/business rules identified enterprise model created processes/services modeled interrelationships of processes and data Application Engineering (a.k.a software engineering) Business system design: modeling applications/procedures that address BAA and constraints of ISP Construction and delivery: using CASE and 4GTs (fourth generation tools), testing California State University, Fall 2008, Part I

95 Information Strategy Planning Management issues define strategic business goals/objectives isolate critical success factors conduct analysis of technology impact perform analysis of strategic systems Technical issues create a top-level data model cluster by business/organizational

area refine model and clustering California State University, Fall 2008, Part I 96 Defining Objectives and Goals Objectivegeneral statement of direction Goaldefines measurable objective: reduce manufactured cost of our product Subgoals: decrease reject rate by 20% in first 6 months gain 10% price concessions from suppliers re-engineer 30% of components for ease of manufacture during first year

Objectives tend to be strategic (long term) while goals tend to be tactical (short term) California State University, Fall 2008, Part I 97 Business Area Analysis (BAA) define naturally cohesive groupings of business functions and data (Martin) perform many of the same activities as ISP, but narrow scope to individual business area identify existing (old) information systems / determine compatibility with new ISP model

define systems that are problematic defining systems that are incompatible with new information model begin to establish re-engineering priorities California State University, Fall 2008, Part I 98 The BAA Process admin. manufacturing sales QC distribution acct engring Process Flow Models

California State University, Fall 2008, Part I Process Decomposition Diagram Data Model Matrices e.g., entity/process matrix 99 Product Engineering The complete product System analysis (World view) capabilities hardware Component

engineering (Domain view) software Processing requirement data function behavior Analysis & Design Modeling (Element view) program component Software Engineering Construction & Integration (Detailed view)

California State University, Fall 2008, Part I 100 Product Architecture Template Example: Conveyor Line Sorting System (CLSS) user interface processing input processing process and control functions output processing maintenance and self-test California State University, Fall 2008, Part I 101 System Context Diagram (CD) for CLSS 1.1 Sorting station operator

User Interface Processing Requests 2.1 Bar code reader 2.2 Conveyor line Bar Code Line speed indicator Queries 3.1 Conveyor Line Sorting System (CLSS) Diagnostic Data Shunt

Commands Formatted Reporting Data 4.1 Sorting mechanism 4.2 Mainframe 5.1 Sorting station operator Input Processing California State University, Fall 2008, Part I Maintenance and self test Output Processing 102 Architecture Flow Diagram

operator interface operator requests operator interface subsystem CLSS queries, reports, displays bar code acquisition request shunt control status sorting reports CLSS processing & control bar code reader subsystem bar code sensor data acquisition subsystem bar code

decoding subsystem timing/location data report requests shunt control subsystem part number raw bar code data bin location data base access subsystem line speed

key report formating subsystem sort records data acquisition interface California State University, Fall 2008, Part I sensor status bar code reader status diagnostics subsystem shunt commands CLSS reports mainframe communications driver

BCR status pulse tach input shunt controller shunt status communications status diagnostic interface CLSS = conveyor line sorting system formated reporting data output interface 103 System Modeling with UML Deployment diagrams

Activity diagrams Each 3-D box depicts a hardware element that is part of the physical architecture of the system Represent procedural aspects of a system element Class diagrams Represent system level elements in terms of the data that describe the element and the operations that manipulate the data These and other UML models will be discussed later California State University, Fall 2008, Part I 104 Deployment Diagram CLSS processor Operator display Sorting subsystem

Sensor data acquisition subsystem Conveyor Pulse tach California State University, Fall 2008, Part I shunt controller Bar code reader Shunt actuator 105 Activity Diagram st art c onveyor line get c onveyor speed read bar c ode valid bar code invalid bar code

det er mine bin loc at ion set f or rejec t bin send shunt c ont rol dat a get shunt st at us get c onveyor st at us read bar c ode produc e report ent ry conveyor stopped California State University, Fall 2008, Part I conveyor in motion 106 Class Diagram class name Box barcode

forwardSpeed conveyorLocation height width depth weight contents readBarcode() updateSpeed() readSpeed() updateLocation() readLocation() getDimensions() getWeight() checkContents() California State University, Fall 2008, Part I attributes note use of capital letter for multi-word attribute names operations (parentheses at end of name indicate the list of attributes that the operation requires)

107

Recently Viewed Presentations

  • Science Lab Safety - TECH Biology

    Science Lab Safety - TECH Biology

    Lab Safety Rap Lab Rap! Pay attention to the lyrics... TPS (Think Pair Share) Quick write: 1. (T) List 3 rules from the rap. 2. (P) Turn to your partner and discuss why the rules you chose are important.
  • Brown Bag Session - Fairfax

    Brown Bag Session - Fairfax

    Pets. Disabilities, Access & Functional Needs. Home / Car. IS-700.A: National Incident Management System, An Introduction. January 2009 Page 2. Home / Car Emergency Kits (1 of 2) Water—one gallon per person, per day (3-day supply for evacuation, 2-week supply...
  • Influence of AM fungi on accumulation of Withaferin-A

    Influence of AM fungi on accumulation of Withaferin-A

    The plants are exploited for its varied medicinal properties by pharmaceutical industries. Therefore, the present study was designed to investigate the effect of AM fungi on enhancement of secondary metabolites in micropropagated plants.
  • Academy Celebrates Legislative Success!  The Academys Medical Imaging

    Academy Celebrates Legislative Success! The Academys Medical Imaging

    The House version of the 21st Century Cures legislation provides $8.75 billion in funding for the NIH over a five-year period. In spite of bipartisan agreement in support of medical innovation and research, this legislation has yet to pass the...
  • Mankiw 5/e Chapter 6: Unemployment

    Mankiw 5/e Chapter 6: Unemployment

    Frictional unemployment due to the time it takes to match workers with jobs may be increased by unemployment insurance Chapter summary 3. Structural unemployment results from wage rigidity - the real wage remains above the equilibrium level causes: minimum wage,...
  • Location, Climate, Distribution of Natural Resources and ...

    Location, Climate, Distribution of Natural Resources and ...

    SS6G6: The student will explain the impact of location, climate, distribution of natural resources, and population distribution in Canada. A. Describe how Canada's location, climate, and natural resources have affected where people live. B. Describe how Canada's location, climate, and...
  • Types of Distributions

    Types of Distributions

    AGENDA . . . Vocabulary, terms and expressions. Graphing (good AND bad practices) Types of . Distributions (4 of 'em) Our first mnemonic . model: SUCS(S) We won't get through the entire PPT today, but the document will be posted...
  • Working Together for A Successful Transition to Middle School

    Working Together for A Successful Transition to Middle School

    Middle school is a defining point for students in the college and career readiness process. Source: The Forgotten Middle: Ensuring that All Students Are On Target For College and Career Readiness Before High School, ACT, 2008.