copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc.

Size: px
Start display at page:

Download "copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc."

Transcription

1 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. with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

2 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? with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

3 Waterfall Model Communicat ion project init iat ion requirement gat hering Planning estimating scheduling tracking Mode ling analysis design Const ruct ion code t est Deployment delivery support f eedback A.k.a.: Classic Life Cycle Useful for problems that are well understood Real problems are more complex than that; changes = confusion Customer must state all requirements upfront Customer must have patience Lack of feedback to the customer makes blunders disastrous with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

4 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 analy s is des ign C o n s t r u c t i o n c ode t es t D e p l o y m e n t d e l i v e r y f e e d b a c k increment # 2 delivery of nt h 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 increment # 1 analy sis des ign C o n s t r u c t i o n c ode t es t D e p l o y m e n t d e l i v e r y f e e d b a c k delivery of 2nd 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 analys is design C o n s t r u c t i o n code t es t D e p l o y m e n t d e l i v e r y f e e d b a c k delivery of 1st increment project calendar t ime with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

5 Incremental Model Applies elements of the waterfall model in incremental fashion First increment is often a core product Subsequent elements offer expanded functionality Subsequent features (some known, some unknown) are created, while the core product may undergo evaluation If a customer requires deadlines that are impossible to meet, a sequence of releases may solve the problem Permits for staffing of a team to fluctuate with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

6 RAD Model Team # n M o d e lin g business m odeling data m odeling process modeling Communicat ion Team # 2 Modeling business m odeling dat a m odeling process modeling Co n st ru ct io n com ponent reuse automatic code generation testing Planning Team # 1 Mode ling business modeling dat a modeling process modeling Const ruct ion com ponent reuse aut om at ic code generat ion t est ing Deployment int egrat ion delivery feedback Const ruct ion component reuse aut omat ic code generat ion t est ing days with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

7 RAD Model Emphasizes short development cycle If requirements are well understood and project scope is constrained, it may allow rapid creation of S/W systems For large projects may require vast human resources (for many RAD teams) Developers and customers must be able to cope with fast action For systems that are not highly modularized the RAD approach may not work If systems require mutual tuning of various components, the RAD approach may not work RAD may not be appropriate with technical risks high (new technology) with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

8 Evolutionary Models: Prototyping Communicat ion communication Quick plan Quick plan Modeling Quick design Mode ling Quick de sign Deployment Deployment Delive ry delivery & & Fe edback feedback Const ruct ion Construction of prot of prototype ot ype with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

9 Evolutionary Models: Prototyping Useful when the customer has a legitimate need but is clueless about the details First prototype may be barely useful: too slow, too big, too unfriendly, etc. DANGERS: The customer may LOVE the prototype which is held together with chewing gum. When informed that it is a prototype which has to be re-built, he may want few fixes only The developer may be tempted to deliver the raw prototype as a final product, sacrificing quality for a quick buck with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

10 Evolutionary Models: The Spiral communication planning estimation scheduling risk analysis start modeling analysis design deployment delivery feedback construction code test with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

11 Evolutionary Models: The Spiral Combines iterative prototyping with systematic aspects of the waterfall model Can be used throughout the S/W life cycle: from conceptualization to maintenance Anchor point milestones are used for each evolutionary pass Anchor point milestones: Work products Required conditions to be attained Realistic to the development of large-scale systems Iteratively reduces risk Allows repeated use of the prototyping approach PROBLEM: Customers may not like it, fearing lack of control with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

12 Evolutionary Models: Concurrent none Modeling act ivit y Under developm ent represents the state of a software engineering activity or task A wait ing changes Under review Under revision Baselined Done with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

13 Evolutionary Models: Concurrent The former image depicted only the modeling activity Indeed, concurrent engineering is a set of framework activities such as Communication, Modeling, etc. Each of these activities is in one of its states A state is some externally observable mode of behaviour PROBLEMS: Prototyping (and other evolutionary processes) pose problems to project planning (too much uncertainty) Evolutionary speed may not be optimal: too slow affects productivity, too fast leads to chaos Sometimes software processes should focus on flexibility and extensibility, rather than on quality - delivery delays may make us miss the market niche and window of opportunity with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

14 Still Other Process Models Component based development the the process to apply when reuse is a development objective Formal methods emphasizes emphasizes the mathematical specification of requirements AOSD provides a process and methodological approach for defining, specifying, designing, and constructing aspects like security, fault tolerance, adherence to business rules, systemic: DB mirroring, memory management, concurrency Unified Process a a use-case driven, architecture- centric, iterative and incremental software process closely aligned with the Unified Modeling Language (UML) with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

15 The Unified Process (UP) Elaborat elaboration inception Incept ion inception Release soft ware increment t ransit ion const ruct ion product ion with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

16 UP Phases UP Phases Incept ion Elaborat ion Const ruct ion Transit ion Product ion Workflows Requirements Analysis Design Implementation Test Support Iterations #1 #2 #n-1 #n with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,

17 Incept ion phase UP Work Products 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 e pt i o n Elaborat ion 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 Const ruct ion 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 Transit ion phase Delivered soft ware increment Bet a t est report s General user feedback with permission by R.S. Pressman & Associates, Inc., copyright 1996, 2001,