1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Chapter 2 The Process

2 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Software Engineering A Layered Technology Software Engineering a “quality” focus process model methods tools

3 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener A Common Process Framework Common process framework Framework activities work tasks work products milestones & deliverables QA checkpoints Umbrella Activities

4 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Umbrella Activities  Software project management  Formal technical reviews  Software quality assurance  Software configuration management  Document preparation and production  Reusability management  Measurement  Risk management

5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Process as Problem Solving

6 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener 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 (an “entry point” to the model)  characteristics of the project  common sense judgment; concurrence of the project team

7 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener The Primary Goal: High Quality Remember: High quality = project timeliness Why? Less rework!

8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener The Linear Model

9 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Iterative Models Prototyping RAD

10 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener The Incremental Model

11 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener An Evolutionary (Spiral) Model

12 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Still Other Process Models  Component assembly model—the process to apply when reuse is a development objective  Concurrent process model—recognizes that different part of the project will be at different places in the process  Formal methods—the process to apply when a mathematical specification is to be developed  Cleanroom software engineering—emphasizes error detection before testing

13 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Project Presentations Requirements Analysis System design Unit & Integration Testing System Testing Operation & Maintenance Program design Coding Acceptance Testing Requirements Design Implementation

14 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Requirements Analysis and Definition The system's services, constraints and goals are established by consultation with system users. They are then defined in a manner that is understandable by both users and development staff. This phase can be divided into: Feasibility study (often carried out separately) Requirements analysis Requirements definition Requirements specification

15 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener System and Program Design System design: Partition the requirements to hardware or software systems. Establishes an overall system architecture Software design: Represent the software system functions in a form that can be transformed into one or more executable programs Unified Modeling Language (UML)

16 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Programming and Unit Testing The software design is realized as a set of programs or program units. (Written specifically, acquired from elsewhere, or modified.) Individual components are tested against specifications.

17 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Integration and System Testing The individual program units are: integrated and tested as a complete system tested against the requirements as specified delivered to the client

18 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Acceptance Testing The client carries out independent tests before accepting the system and putting it into production.

19 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Operation and Maintenance: Software Life Cycle Operation: The system is put into practical use. Maintenance: Errors and problems are identified and fixed. Evolution: The system evolves over time as requirements change, to add new functions or adapt the technical environment. Phase out: The system is withdrawn from service.

20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Discussion of the Waterfall Model Advantages: Process visibility Separation of tasks Quality control Cost control Disadvantages: Each stage in the process reveals new understanding of the previous stages, that requires the earlier stages to be revised. The Waterfall Model is not enough!

21 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Iterative Refinement (Evolutionary Development) Concept: Initial implementation for user comment, followed by refinement until system is complete. Vaporware: user interface mock-up Throw-away software components Dummy modules Rapid prototyping Successive refinement Get something working as quickly as possible!

22 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Iterative Refinement Requirements Design Implementation (prototype) Evaluation

23 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001and revised by Ayşe Bener Observations about Software Processes Completed projects should look like the Waterfall Model but... the development process is always partly evolutionary. Risk is lowered by: Prototyping key components Dividing into phases Following a visible software process Making use of reusable components Conclusion It is not possible to complete each step and throw it over the wall.