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, Software Engineering: A Practitioner’s Approach, 6/e Chapter 3 Prescriptive Process Models Software Engineering: A Practitioner’s Approach, 6/e Chapter 3 Prescriptive Process Models 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.

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, Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering 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? 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? 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?

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, The Waterfall Model

Process iteration System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems. System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems. Iteration can be applied to any of the generic process models. Iteration can be applied to any of the generic process models. Two (related) approaches Two (related) approaches Incremental delivery; Incremental delivery; Spiral development. Spiral development.

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, The Incremental Model

Incremental delivery Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. User requirements are prioritised and the highest priority requirements are included in early increments. User requirements are prioritised and the highest priority requirements are included in early increments. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve.

Incremental development advantages Customer value can be delivered with each increment so system functionality is available earlier. Customer value can be delivered with each increment so system functionality is available earlier. Early increments act as a prototype to help elicit requirements for later increments. Early increments act as a prototype to help elicit requirements for later increments. Lower risk of overall project failure. Lower risk of overall project failure. The highest priority system services tend to receive the most testing. The highest priority system services tend to receive the most testing.

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, The RAD Model

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, Evolutionary Models: Prototyping communication Quick plan Modeling Quick design Construction of prototype Deployment delivery & feedback

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, Evolutionary Models: The Spiral

Spiral development Process is represented as a spiral rather than as a sequence of activities with backtracking. Process is represented as a spiral rather than as a sequence of activities with backtracking. Each loop in the spiral represents a phase in the process. Each loop in the spiral represents a phase in the process. No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required. No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required. Risks are explicitly assessed and resolved throughout the process. Risks are explicitly assessed and resolved throughout the process.

Spiral model of the software process

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, Still Other Process 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)

Class Project definition Teams Teams Reports Reports Professional resources Professional resources 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,

Web Resources: Web Resources: Software Engineering Reference Library: Software Engineering Reference Library: Software Engineering Checklists: Software Engineering Checklists: Adaptable Process Model: Adaptable Process Model:  Work Product Templates: Umbrella Activities: Umbrella Activities: Tiny Tools: Tiny Tools: Industry Commentary: Industry Commentary-Management See content of Industry Commentary: Industry Commentary-Management See content of Industry Commentary-Technical See content of Industry Commentary-Technical See content of Supplementary Content: See content at: Supplementary Content: See content at: Distance Learning Distance Learning

Software Engineering Document Templates System Specification Software Project Plan SQA Plan Technical review summary report SCM Plan Software change request Software change report Engineering change order Software Requirements Specification Software Design Specification Test Specification

SYSTEM SPECIFICATION 1.0 Introduction This section provides an overview of the entire system or product. This document describes all subsystems including hardware, software, human activities, documents, and process. 2.0 Functional and Data Description This section describes overall system function and the information domain in which it operates. 3.0 Subsystem Description A description of each subsystem is presented. 4.0 System Modeling and Simulation Results If system modeling and simulation and/or prototyping is conducted, these are specified here. 5.0 Project Issues An overview of the overall system/product project plan is presented. 6.0 Appendices Presents information that supplements the System Specification.

SYSTEM SPECIFICATION 1.0 Introduction This section provides an overview of the entire system or product. This document describes all subsystems including hardware, software, human activities, documents, and process. 1.1 Goals and objectives Overall business s goals and project objectives are described. 1.2 System statement of scope A description of the entire system is presented. Major inputs, processing functionality and outputs are described without regard to implementation detail. 1.3 System context The system is placed in a business or product line context. Strategic issues relevant to context are discussed. The intent is for the reader to understand the "big picture." 1.4 Major constraints Any business or product line constraints that will impact the manner in which the system is to be specified, designed, implemented or tested are noted here. 2.0 Functional and Data Description This section describes overall system function and the information domain in which it operates. 2.1 System architecture A context-level model of the system architecture is presented. 2.2 Data Description Top-level data objects that will be managed/manipulated by the system or product are described in this section. 2.3 Interface Description The system's interface(s) to the outside world are described. 3.0 Subsystem Description A description of each subsystem is presented. 3.1 Description for Subsystem n A detailed description of each subsystem is presented. Section 3.1 is repeated for each of n subsystems. 3.2 Diagrammatic model for Subsystem n A diagrammatic model for each subsystem is presented. Section 3.2 is repeated for each of n subsystems. 4.0 System Modeling and Simulation Results If system modeling and simulation and/or prototyping is conducted, these are specified here. 4.1 Description of system modeling approach (if used) The system modeling approach (including tools and/or mathematical models) is described. 4.2 Simulation results The results of any system simulation are presented with specific emphasis on data throughput, timing, performance, and/or system behavior. 4.3 Special performance issues Special performance issues are identified. 4.4 Prototyping requirements If a system prototyping is to be built, its specification and implementation environment are described here. 5.0 Project Issues An overview of the overall system/product project plan is presented. 5.1 Projected development costs The results of system-level cost estimates are presented. 5.2 Project schedule A top-level schedule for the development project is proposed. 6.0 Appendices Presents information that supplements the System Specification. 6.1 Business Process Descriptions If the specification is developed for a business system, a description of relevant business processes is presented here. 6.2 Product Strategies If the specification is developed for a product, a description of relevant product strategy is presented here. 6.3 Supplementary information (as required)

SOFTWARE PROJECT PLAN 1.0 Introduction This section provides an overview of the software engineering project. 1.1 Project scope A description of the software is presented. Major inputs, processing functionality and outputs are described without regard to implementation detail. 1.2 Major software functions A functional decomposition of the software (for use during estimation and scheduling) is developed here. 1.3 Performance/Behavior issues Any special requirements for performance or behavior are noted here. 1.4 Management and technical constraints Any special constraints that affect the manner in which the project will be conducted (e.g., limited resources or 'drop dead' delivery date) or the technical approach to development are noted here. 2.0 Project Estimates This section provides cost, effort and time estimates for the projects 2.1 Historical data used for estimates Describes the historical data that is relevant to the estimates presented. 2.2 Estimation techniques applied and results A description of each estimation technique and the resultant estimates are presented here. 2.3 Reconciled Estimate The final cost, effort, time (duration) estimate for the project (at this point in time) is presented here. 2.4 Project Resources People, hardware, software, tools, and other resources required to build the software are noted here. 3.0 Risk Management This section discusses project risks and the approach to managing them. 3.1 Project Risks Each project risk is described. The CTC format may be used. 3.2 Risk Table The complete risk table is presented. Name of risk, probability, impact and RM3 pointer are provided. 3.3 Overview of Risk Mitigation, Monitoring, Management An overview of RM3 is provided here. The Complete RM3 is provided as a separate document or as a set of Risk Information Sheets. 4.0 Project Schedule This section presents an overview of project tasks and the output of a project scheduling tool. 4.1 Project task set The process model, framework activities and task set that have been selected for the project are presented in this section. 4.2 Functional decomposition A functional breakdown to be used for scheduling is presented here. 4.3 Task network Project tasks and their dependencies are noted in this diagrammatic form. 4.4 Timeline chart A project timeline chart is presented. This may include a time line for the entire project or for each staff member. 5.0 Staff Organization The manner in which staff are organized and the mechanisms for reporting are noted. 5.1 Team structure The team structure for the project is identified. Roles are defined. 5.2 Management reporting and communication Mechanisms for progress reporting and inter/intra team communication are identified. 6.0 Tracking and Control Mechanisms Techniques to be used for project tracking and control are identified. 6.1 Quality assurance and control An overview of SQA activities is provided. Note that an SQA Plan is developed for a moderate to large project and may be a separate document or included as an appendix. 6.2 Change management and control An overview of SCM activities is provided. Note that an SCM Plan is developed for a moderate to large project and may be a separate document or included as an appendix. 7.0 Appendix Supplementary information is provided here.

SOFTWARE PROJECT PLAN 1.0 Introduction This section provides an overview of the software engineering project. 1.1 Project scope A description of the software is presented. Major inputs, processing functionality and outputs are described without regard to implementation detail. 1.2 Major software functions A functional decomposition of the software (for use during estimation and scheduling) is developed here. 1.3 Performance/Behavior issues Any special requirements for performance or behavior are noted here. 1.4 Management and technical constraints Any special constraints that affect the manner in which the project will be conducted (e.g., limited resources or 'drop dead' delivery date) or the technical approach to development are noted here. 2.0 Project Estimates This section provides cost, effort and time estimates for the projects 2.1 Historical data used for estimates Describes the historical data that is relevant to the estimates presented. 2.2 Estimation techniques applied and results A description of each estimation technique and the resultant estimates are presented here Estimation technique m Tables or equations associated with estimation technique m are presented. Section is repeated for each of m techniques Estimate for technique m Estimate generated for technique m. 2.3 Reconciled Estimate The final cost, effort, time (duration) estimate for the project (at this point in time) is presented here. 2.4 Project Resources People, hardware, software, tools, and other resources required to build the software are noted here. 3.0 Risk Management This section discusses project risks and the approach to managing them. 3.1 Project Risks Each project risk is described. The CTC format may be used. 3.2 Risk Table The complete risk table is presented. Name of risk, probability, impact and RM3 pointer are provided. 3.3 Overview of Risk Mitigation, Monitoring, Management An overview of RM3 is provided here. The Complete RM3 is provided as a separate document or as a set of Risk Information Sheets. 4.0 Project Schedule This section presents an overview of project tasks and the output of a project scheduling tool. 4.1 Project task set The process model, framework activities and task set that have been selected for the project are presented in this section. 4.2 Functional decomposition A functional breakdown to be used for scheduling is presented here. 4.3 Task network Project tasks and their dependencies are noted in this diagrammatic form. 4.4 Timeline chart A project timeline chart is presented. This may include a time line for the entire project or for each staff member. 5.0 Staff Organization The manner in which staff are organized and the mechanisms for reporting are noted. 5.1 Team structure The team structure for the project is identified. Roles are defined. 5.2 Management reporting and communication Mechanisms for progress reporting and inter/intra team communication are identified. 6.0 Tracking and Control Mechanisms Techniques to be used for project tracking and control are identified. 6.1 Quality assurance and control An overview of SQA activities is provided. Note that an SQA Plan is developed for a moderate to large project and may be a separate document or included as an appendix. 6.2 Change management and control An overview of SCM activities is provided. Note that an SCM Plan is developed for a moderate to large project and may be a separate document or included as an appendix. 7.0 Appendix Supplementary information is provided here.