Software Engineering A Practitioner s Approach 6 e Chapter 3

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, 2005 1

Problem Solving Loop Problem definition Technical development Status quo Solution integration 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 2

Prescriptive Models Prescriptive process models advocate an orderly approach to software engineering That leads to a few questions … n If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change? n 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? n 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 3

The Waterfall Model Communication project initiation requirement gathering Planning estimating scheduling tracking Modeling analysis design Construction code test Deployment delivery support 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, 2005 4

The Waterfall Model Analysis: information domain, required function, behavior, performance, interfacing o Design: data structure, software architecture, interface representations, procedural detail o Testing: logical internal, functional external o 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 5

The Waterfall Model The most widely used paradigm for software engineering o It is often difficult for the customer to state all requirements explicitly at the beginning o Change can cause confusion as the project team proceeds o The customer must have patience. A major blunder can be disastrous o 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 6

Software functionality and features The Incremental Model Increment # n C o m m u n i c a t i o n P l a n n i n g M o d e l i n g a naly s is d es ign C o n s t r u c t i o n code t est D e p l o y m e n t d e l i v e ry f e e d b a c k delivery of nth Increment # 2 C o m m u n i c a t i o n P l a n n i n g M o d e l i n g analy s is des ign C o n s t ru c t i o n code t est Increment # 1 D e p l o y m e n t d e l i v e ry f e e d b a c k delivery of 2 nd Increment C o m m u n i c a t i o n P l a n n i n g M o d e l i n g analy s is des ig n C o n s t ru c t i o n code D e p l o y m e n t t est d e l i v e ry f e e d b a c k delivery of 1 st Increment Project calendar time 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 7

The Incremental Model Focuses on the delivery of an operational product quickly, not a prototype o The first increment is a core product, supplementary features are developed for the next increment o Early increments serve as a platform for evaluation, then a plan is developed for the next increment o Suitable for staffing is unavailable, timing is not enough, technical risk is unknown o 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 8

The RAD Model T e am # n Team # n M o d e lin g b u s in e s s m o d e lin g d a t a m o d e lin g p r o c e s s m o d e lin g C o n s t r u c t io n Team # 2 T e am # 2 Communication c om pon ent re us e a u t o m a t ic c o d e g e n e r a t io n t e s t in g M o d eling b u si n e s s m o d e l i n g d a t a m o d e lin g p ro c e s s m o d e l i n g Planning C o ns t r uc t i o n Team # 1 Te a Modeling g M o d e lin business modeling b u s in e ss m o d e lin g d at a m o d e lin data modelingg p r o ce s m o d e lin g process smodeling c o m p o n e n t re u s e a u t o m a t i c co d e g e n e ra t i o n t e st i n g Deployment Deployme nt int egrat ion integration deliv ery delivery feedback Constructiont io n Co n st r u c co m p o n e n re u se component treuse au t o m at co d e automaticiccode g e n e r at io n t generation e s t in g testing 6 0 - 9 0 d ays 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 9

Rapid Application Development o o o Suit for requirements are well understand, project scope is constrained, business application can be modularized Require sufficient human resources to create the right number of RAD teams Require commitment from both developers and customers Not all types of applications are appropriate for RAD Not appropriate when technical risks are high 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 10

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

The Prototyping Model The prototype can serve as the first system o Users get a feel for the actual system and developers get to build something immediately o Prototype is built to serve as a mechanism for defining requirements. It is then discarded and the actual software is engineered with an eye toward quality and maintainability. o 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 12

The Prototyping Model o But … The customer often demands that a few fixed be applied to make the prototype a working product. Ø The developer often makes implementation compromises in order to get a prototype working quickly. Ø 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 13

Evolutionary Models: The Spiral Concept development projects New product development projects Product enhancement projects Product maintenance projects Planning estimation scheduling risk analysis Communication Modeling analysis design start Deployment delivery feedback Construction code test 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 14

The Spiral Model o o Suitable for large–scale systems and software Software evolves as the process progresses, the developer and customer better understand react to risks at each evolutionary level Use prototyping as a risk reduction mechanism, but maintain the systematic stepwise approach Difficult to convince customers (particular in contract situations) that the evolutionary approach is controllable 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 15

Comments on Evolutionary processes Evolutionary process poses a problem to project planning because of the uncertain number of cycles required to construct the product o Evolutionary software process does not establish the maximum speed of the evolution o Software process should be focused on flexibility and extensibility rather than on high quality. We should prioritize the speed of the development over zero defects o by J. Nogueira 2000 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 16

Comments on Evolutionary processes The intent of evolutionary models is to develop high-quality software in an iterative and incremental manner. However, o It is possible to use an evolutionary process to emphasize flexibility, extensibility, and speed of development o 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 17

Component-based Development Planning Risk Analysis Identity candidate classes Customer Evaluation Engineering, Construction & Release Look-up classes library Put new classes in library Customer Communication Construct nth iteration of system Extract classes if available Engineer classes if unavailable OO analysis OO design OO programming OO 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, 2005 18

Component-based Development In addition to incorporate many characteristics of the spiral model, it composes applications from prepackaged software components (classes) o Emphasize the creation of classes that encapsulate both data and the algorithms used to manipulate the data o Apply when reuse (object-oriented class) is a development objective o 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 19

The Formal Methods Models o o o Specify, develop, and verify a computer-based system by applying a rigorous, mathematical (set and logic) notation Specification with Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily Time consuming and expensive Extensive training is required Difficult to use as a communication mechanism 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 20

The Unified Process na “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML) 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 21

The Unified Process (UP) elaboration inception g plannin tion munica com inception m deploy Release software increment ing model ion struct con ent construction transition production 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 22

UP Work Products Inception phase Elaboration phase Vision document Initial use-case model Initial project glossary Initial business case Initial risk assessment Project plan phases and iterations Business model if necessary One or more prototypes Use-case model Supplementary requirements including non-functional Analysis model Software architecture description Executable architecture prototype Preliminary design model Revised risk list Project plan including iteration plan, adapted workflows, milestones, technical work products Preliminary user manual Construction phase Design model Software components Integrated software increment Test plan and procedure Test cases Support documentation user manuals, installation manuals, description of current increment transition phase Delivered software increment Beta test reports General user 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, 2005 23

Fourth Generation Techniques o o o o Nonprocedural languages for database query Report generation Data manipulation Screen interaction and definition Code generation High-level graphics capability Spreadsheet capability Automated generation of HTML for web-site creation 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 24

Fourth Generation Techniques Greatly reduce the software development time and improve productivity for small and intermediate applications. But, the maintainability of large software systems is open to question o The current 4 GT tools are not much easier than programming languages, and the resultant source code is inefficient o Coupled with component-based development approaches, it may become the dominant approach to software development o 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