1. 1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.

2. 2 A Layered Technology Software Engineering a “quality” focus process model methods tools

3. System Development Life Cycle It is about developing a software-driven It is about developing a software-driven solution to a business problem solution to a business problem It concerns a process which takes from two months to two years It concerns a process which takes from two months to two years This is called a System Development Life Cycle but it should really be called a (Business) Solution Development Life Cycle This is called a System Development Life Cycle but it should really be called a (Business) Solution Development Life Cycle 3

4. Business Solution Characteristics A software-driven solution consists of two parts: Model Model Prototypes Prototypes Diagrams and supporting Documents Diagrams and supporting Documents System System Hardware Hardware Software Software 4

5. Sample Deliverables Analysis: Analysis: Use case Use case Shows the dynamics between the users (actors) of the system and the system itself Shows the dynamics between the users (actors) of the system and the system itself This is a narrative representation This is a narrative representation Conceptual Diagram Conceptual Diagram Shows the structure of the objects and their relationships Shows the structure of the objects and their relationships This is a graphical representation This is a graphical representation System Sequence Diagram System Sequence Diagram Shows the dynamics between the users (actors) of the system and the system itself Shows the dynamics between the users (actors) of the system and the system itself This is a graphical representation This is a graphical representation Contracts Contracts Shows the state of each object before each action Shows the state of each object before each action This is a narrative representation This is a narrative representation 5

6. Sample High-level Architecture Design Logical Blueprint 6

7. Sample Deliverables - Design Design: Design: Interaction Diagram Interaction Diagram Shows the interaction between objects Shows the interaction between objects This is a graphic representation This is a graphic representation It is a dynamic blueprint It is a dynamic blueprint Class Diagram Class Diagram Shows the structure between objects Shows the structure between objects Shows the structure inside objects Shows the structure inside objects This is a graphic representation This is a graphic representation It is a static blueprint It is a static blueprint 7

8. A Generic Process Model 8

9. Identifying a Task Set A task set defines the actual work to be done to accomplish the objectives of a software engineering action A task set defines the actual work to be done to accomplish the objectives of a software engineering action A list of the tasks to be accomplished A list of the tasks to be accomplished A list of the work products to be produced A list of the work products to be produced A list of the quality assurance filters to be applied A list of the quality assurance filters to be applied 9

10. 10 A Process Framework Process framework Framework activities work tasks work products milestones & deliverables QA checkpoints Umbrella Activities

11. 11 Framework Activities Communication Communication Planning Planning Modeling Modeling Analysis of requirements Analysis of requirements Design Design Construction Construction Code generation Code generation Testing Testing Deployment Deployment

12. 12 Umbrella Activities Software project management Software project management Formal technical reviews Formal technical reviews Software quality assurance Software quality assurance Software configuration management Software configuration management Work product preparation and production Work product preparation and production Reusability management Reusability management Measurement Measurement Risk management Risk management

13. 13 Process Patterns Process patterns define a set of activities, actions, work tasks, work products and/or related behaviors Process patterns define a set of activities, actions, work tasks, work products and/or related behaviors A template is used to define a pattern A template is used to define a pattern Typical examples: Typical examples: Customer communication (a process activity) Customer communication (a process activity) Analysis (an action) Analysis (an action) Requirements gathering (a process task) Requirements gathering (a process task) Reviewing a work product (a process task) Reviewing a work product (a process task) Design model (a work product) Design model (a work product)

14. Process Pattern Types Stage patterns - defines a problem associated with a framework activity for the process Stage patterns - defines a problem associated with a framework activity for the process Task patterns - defines a problem associated with a software engineering action or work task and relevant to successful software engineering practice Task patterns - defines a problem associated with a software engineering action or work task and relevant to successful software engineering practice Phase patterns - define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature Phase patterns - define the sequence of framework activities that occur with the process, even when the overall flow of activities is iterative in nature 14

15. Waterfall Model 15

16. Incremental Model 16

17. Evolutionary Model: Spiral 17

18. Other Models Component based development - the process to apply when reuse is a development objective Component based development - the process to apply when reuse is a development objective Formal methods - emphasizes the mathematical specification of requirements Formal methods - emphasizes the mathematical specification of requirements AOSD - provides a process and methodological approach for defining, specifying, designing, and constructing aspects AOSD - provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Process - a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) Unified Process - a “use-case driven, architecture- centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) 18

19. UP Phases 19

20. Personal Software Process(PSP) Planning. This activity isolates requirements and develops both size and resource estimates. In addition, a defect estimate (the number of defects projected for the work) is made. All metrics are recorded on worksheets or templates. Finally, development tasks are identified and a project schedule is created. Planning. This activity isolates requirements and develops both size and resource estimates. In addition, a defect estimate (the number of defects projected for the work) is made. All metrics are recorded on worksheets or templates. Finally, development tasks are identified and a project schedule is created. High-level design. External specifications for each component to be constructed are developed and a component design is created. Prototypes are built when uncertainty exists. All issues are recorded and tracked. High-level design. External specifications for each component to be constructed are developed and a component design is created. Prototypes are built when uncertainty exists. All issues are recorded and tracked. High-level design review. Formal verification methods are applied to uncover errors in the design. Metrics are maintained for all important tasks and work results. High-level design review. Formal verification methods are applied to uncover errors in the design. Metrics are maintained for all important tasks and work results. Development. The component level design is refined and reviewed. Code is generated, reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results. Development. The component level design is refined and reviewed. Code is generated, reviewed, compiled, and tested. Metrics are maintained for all important tasks and work results. Postmortem. Using the measures and metrics collected (this is a substantial amount of data that should be analyzed statistically), the effectiveness of the process is determined. Measures and metrics should provide guidance for modifying the process to improve its effectiveness. Postmortem. Using the measures and metrics collected (this is a substantial amount of data that should be analyzed statistically), the effectiveness of the process is determined. Measures and metrics should provide guidance for modifying the process to improve its effectiveness. 20

21. 21 The Process Model: Adaptability the framework activities will always be applied on every project... BUT 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 tasks (and degree of rigor) for each activity will vary based on: the type of project the type of project characteristics of the project characteristics of the project common sense judgment; concurrence of the project team common sense judgment; concurrence of the project team

22. 22 The CMMI The CMMI defines each process area in terms of “specific goals” and the “specific practices” required to achieve these goals. The CMMI defines each process area 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 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 process- related activities. Specific practices refine a goal into a set of process- related activities.

23. Homework #2 Research and put together a comparative write-up or traditional Process Models (300 words max): Research and put together a comparative write-up or traditional Process Models (300 words max): Waterfall Waterfall V Phased Phased Evolutionary Evolutionary Spiral Spiral CBSE CBSE RUP RUP PSP/TSP PSP/TSP 23

24. 24 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 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: Many different assessment options are available: SCAMPI SCAMPI CBA IPI CBA IPI SPICE SPICE ISO 9001:2000 ISO 9001:2000

25. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 25 Assessment and Improvement

26. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 26 Personal Software Process (PSP) Recommends five framework activities: Recommends five framework activities: Planning Planning High-level design High-level design High-level design review High-level design review Development Development Postmortem Postmortem stresses the need for each software engineer to identify errors early and as important, to understand the types of errors stresses the need for each software engineer to identify errors early and as important, to understand the types of errors

27. 27 Team Software Process (TSP) Each project is “launched” using a “script” that defines the tasks to be accomplished Each project is “launched” using a “script” that defines the tasks to be accomplished Teams are self-directed Teams are self-directed Measurement is encouraged Measurement is encouraged Measures are analyzed with the intent of improving the team process Measures are analyzed with the intent of improving the team process

28. 28 The Primary Goal of Any Software Process: High Quality Remember: High quality = project timeliness Why? Less rework!