Slide 3.1 © The McGraw-Hill Companies, 2002 SOFTWARE LIFE-CYCLE MODELS

Slide 3.2 © The McGraw-Hill Companies, 2002 Software Life-Cycle Models l Life-cycle model (formerly, process model) l The steps through which the product progresses –Requirements phase –Specification phase –Design phase –Implementation phase –Integration phase –Maintenance phase –Retirement

Slide 3.3 © The McGraw-Hill Companies, 2002 Build and Fix Model l Problems –No specifications –No design l Totally unsatisfactory l Need life-cycle model –“Game plan” –Phases –Milestones

Slide 3.4 © The McGraw-Hill Companies, 2002 Waterfall Model l Characterized by –Feedback loops –Documentation-driven –Operational product at end l Advantages –Documentation –Maintenance may be easier l Disadvantages –Customer may not be aware of what getting –Costly when discrepancy found in later stages –Sometimes freezes part of development –May lead to badly structured systems

Slide 3.5 © The McGraw-Hill Companies, 2002 Rapid Prototyping Model (Throwaway) l Determine needs of customer l Refine with interaction of customers l Experiment with parts not understood l Prototype system poorly structured l Operational product at end

Slide 3.6 © The McGraw-Hill Companies, 2002 Evolutionary Rapid Prototyping Specification Development Validation Concurrent Activities Problem Description (outline) Initial Version Intermediate Version Final Version l Process not visible (need deliverables) l Need highly skilled team l Appropriate – Small teams – Part of system not well understood – Short lifecycle system

Slide 3.7 © The McGraw-Hill Companies, 2002 Incremental Model l Divide project into builds l Operational quality portion of product within weeks l Smaller capital outlay, rapid return on investment l Need open architecture— maintenance implications l Requires skilled developers

Slide 3.8 © The McGraw-Hill Companies, 2002 Incremental Model: View 2 l More risky version—pieces may not fit

Slide 3.9 © The McGraw-Hill Companies, 2002 Transformation Model l Uses formal specification l Viewed as a sequence of steps that transforms a specification into an implementation l Proves program correctness Requirements Anal. and Spec. Optimization Decisions and rationale Reusable components Lower level specifications Tuning Recording of development history Verification Requirements Formal Specifications

Slide 3.10 © The McGraw-Hill Companies, 2002 Spiral Model l Simplified form –Waterfall model plus risk analysis l Precede each phase by –Alternatives –Risk analysis l Follow each phase by –Evaluation –Planning of next phase

Slide 3.11 © The McGraw-Hill Companies, 2002 Simplified Spiral Model l Focus on eliminating errors early l Examines level of effort l Accommodates growth and change (evolution) l Restrictions –In-house development (not contracted) –Good for large-scale systems –Requires training in risk analysis and resolution

Slide 3.12 © The McGraw-Hill Companies, 2002 Full Spiral Model (contd)

Slide 3.13 © The McGraw-Hill Companies, 2002 Risk l A risk is something that may occur in the course of a project, and which, under the worst outcome, would affect it negatively and significantly [Braude, 2001]. l Two types: –Those that can be avoided or worked around –Those cannot be avoided l Problems are those risks that have not been identified. Risks must be managed! l Risk retirement is process whereby risks are reduced or eliminated.

Slide 3.14 © The McGraw-Hill Companies, 2002 Risk Management Activities l Identification –Mindset: try to continually identify risks –Write down concerns and press all team members to think of more l Retirement planning –Outline the steps that can be taken to retire the risk. l Prioritization –Options: likelihood (10 most likely), impact (10 most impact), retirement cost (10 highest cost) –Formula: (11-l)  (11-i)  rc –(lowest is first) l Retirement or mitigation

Slide 3.15 © The McGraw-Hill Companies, 2002 Types of Risks (Pressman, 2001) l Generic (every project) –Product size –Business impact (constraints imposed by mgm’t) –Customer characteristics –Process definition –Development environment –Technology to be built –Staff size and experience l Product-specific ( characteristics of product)

Slide 3.16 © The McGraw-Hill Companies, 2002 Example Risks l Underestimation of size l Time lag in learning new tools l Lack of top management commitment l Personnel resign l Changing scope and/or objectives l Technical breakthroughs—change in product l Unrealistic schedule l Personnel lack required knowledge or skills

Slide 3.17 © The McGraw-Hill Companies, 2002 Feature Driven Development (FDD)

Slide 3.18 © The McGraw-Hill Companies, 2002 Exam Questions l What is Extreme Programming? l What are the advantages and disadvantages of using Extreme Programming as development model?