03.2. lifecycle models

Enterprise Software

Systems Development

Lecture 4: ESSD Lifecycle Models

National Research University - Higher School of Economics, 2015-16

Enterprise Software Systems Development: Module 1


Contents

•

•

•

•

•

•

•

•

•

•

Build-and-Fix model

Waterfall model

Rapid prototyping model

Incremental model

Synch-stabilization model

Spiral model

OO model

Models benefits and drawbacks

Business-case: E-shop model choice

References




Lifecycle Models (revision)

What is a lifecycle model? Q.1:

Q.2: Which lifecycle models do you know?

Q.3: What are the common/distinctive features of lifecycle models ?

Q.4: What does lifecycle model choice depend on ?

*Work in SGs of 3 (2 mins). Discuss results (1 min). Give your

answer.




Lifecycle Models • A lifecycle model determines the set of processes, activities

task, as well as the order of their sequence and

• Two major components of virtually any framework for (E)SSD:

methodology /

–

–

Process model

Role model

• Additionally, we can consider:

–

–

–

Artifacts (document patterns and results)

Practices

Major pre-determined control points (optional)




Choosing the Lifecycle Model for (E)SSD

The task for process architect and management •

• To –

–

be considered Business criteria

Technology criteria

• Compromise between market/client’s demand and resources/experince

developer’s

• The lifecycle model can be pre-determined by the client OR preferred by most influential developer’s representative(s)

May vary for project-based (depending on aims\scope) and

product-based development (often longer lifecycle and

repeating activities)

•




Choosing the Lifecycle Model for (E)SSD

• Choice criteria: – Project type

• Is any process of standard model required to be performed \checked

• Problem domain understandability

System model

• Project from scratch OR redevelopment

• Developer team experience

–

– ISO/IEC standard lifecycle 12207):

models (see TR 15271 Guide for ISO/IEC

•

•

•

Waterfall

Incremental

Evolving




Incomplete Lifecycle Models

Q.1: Should a lifecycle model always cover all SDL phases? Why?

Q.2: Which SDL phases can be omitted in a lifecycle model?

Q.3: What product requirements are compatible with an incomplete lifecycle model(s)?

*Work in SGs of 3 (2 mins). Discuss results (1 min). Give

answer.

your




Lifecycle Models: Code-and-Fix

• Features: – No projects specifications and preliminary design

– Several full project rebuilds and client approval

Benefits: – Cost reduction for small projects with distinct requirements

predictable behavior

Drawbacks:

• and

• – Early lifecycle errors show up only at the very end => serious

costs increase is possible – Non-applicable for large (over 1000 lines = 1KLOC) products

Conclusion: incomplete lifecycle model •




Lifecycle Models: Code-and-Fix

Retirement

Maintenance

Modify till

client satisfied

Build Version #1




“One-Path” Lifecycle Models

Q.1: Should a lifecycle model always be iterative? Why?

Q.2: What are model(s)?

the strong points of a non-iterative lifecycle

Q.3: What are model(s)?

the weak points of a non-iterative lifecycle


answer.




Lifecycle Models: Waterfall

• Features:

–

–

Sequential change of all lifecycle phases

SQA group verifies\tests results after every client side participates)

Feedback with earlier lifecycle phases

phase (sometimes

–

• Benefits:

– Cost reduction for software correction (due

Drawbacks:

to feedback)

•

– Requires technically “literate” client specifications

to create satisfactory

– Under high risks, should be combined with rapid protoryping




Lifecycle Models: Waterfall

Implementation, Transfer, Maintenance /

Verification

Coding & Testing /

Verification

Design /

Verification

Requirements /

Verification




Waterfall Model - applicability

•

•

Appicability degree varies depending on methodology

Benefits:

–

–

easy to understand and estimate

visibility (processes are easy to trace)

• Drawbacks:

–

–

changes become complicated: terminated phases get “frozen”

does not model iterations and evolution




Lifecycle Models: V-Model (waterfall-based)

Coding

Testing

Detailed Design

Integration Testing

Design

Product Testing

Functional Design

Acceptance

Requirements

Maintenance

Business analysis




“Independent” Lifecycle Models

Q.1: Should a lifecycle model always be independent? Why?

Q.2: When can a “non-independent” lifecycle model be used?

Q.3: What are the limitations of using “non-independent” lifecycle model(s)?


answer.




Lifecycle Models: rapid prototyping

Features: •

– Requirement analysis and specifications are generally

before coding and testing

possible

–

–

Client has no technical knowledge to discuss requirements

Rapid prototype has limited

reliability/performance

functionality and





• Benefits:

–

–

Idea basis for software development and discussions/interviews

Technical risk reduction (cheap detection of potential problems)

• Drawbacks:

– Temptation to use “non-technological” code

(low quality, insufficient testing and documenting)




Lifecycle Models: “Shark teeth”/ prototyping

Testing

Testing

Implementation

Detailed

Design

Partial / Unit

Testing

Preliminary

Design

Integration

Developer

Requirement

Analysis

Product Project

Review

Manager

Acceptance

Prototype 2

Prototype 1 Product

Requirements

Client




Adding Functionality Lifecycle

Q.1: Is it possible to add SS features with a lifecycle Why?

Models

model?

Q.2: When can a “feature-additive” lifecycle model be used?

Q.3: Can we treat SDL as an evolution-like process? Why?


answer.




Lifecycle Models: Incremental

• Features:

– Product decomposition to sequential releases (each

development cycle gives an operational product)

Benefits: •

–

–

–

Operational product at every development step

Flexible introduction of the new functionality at the client’s site

Easy maintenance due to “straightforward expanding” of the

major product modules





Drawbacks: •

– Requires expandable software solution (non-applicable for

products, which immediately require full functionality )

Product should be “architecture scalable”

Product should have stable upgrade path

–

–

– Non-applicable for products, which quickly go beyond the

frame of their original concept (degenerates into Build-and-

Fix)





• Product is divided into subsystems and is supplied

releases/builds

in

•

•

Each release provides operational quality of the subsystem

With each release, the new subsystem is included into th

previous release





& Testing /

Increm ent 1

& Testing /

Increm ent 2

& Testing /

Increm ent 3

Each release includes: detailed design, implementation,

integration, testing and transfer

Implementation

Verification

Design /

Verification

Implementation, Integra tion,

Tra nsfer, Ma intena nce /

Verification

Implementation

Verifica tion

Design /

Verification

Implementation, Integration,

Tra nsfer, Ma intena nce /

Verification

Requirements / Verification

2

n

Implementation

Verification

Design /

Verification

Implementation, Integration,

Tra nsfer, Maintena nce /

Verification




Lifecycle Models: Evolution

Requirement

s

Version 1

Requirements

Version 2

Requirements

Version n

Code & Test

Project

Installation

Acceptance

Maintenance

Code & Test

Project

Installation

Acceptance

Maintenance

Code & Test

Project

Installation

Acceptance

Maintenance




“One-Path”/“Cyclic” Lifecycle Models

Q.1: Which “cyclic” SDL models do you know?

Q.2: Can waterfall model be considered cyclic? Why?

Q.3: What is the relationship between a SDL model and a SDL methodology ?

*Work in SGs of 3 (2 mins). Discuss results (1 min).

answer.

Give your




Lifecycle Models: Iterative approach

•

•

An example: Spiral model, Boehm, 1987

Model with tasks/activities emphasis –

–

Deals with tasks changes and iterations

Risk management focus

•

•

Any waterfall model phase/activity is cyclic

Every cycle contains 4 stages –

–

–

–

Define goals, alternatives, point out constraints

Evaluate alternatives, identify risks, point out ways of mitigating

Implement and test the current cycle

Plan the next cycle




Lifecycle Models: synch-stabilization or Microsoft

• Team members activities are continuously sychronized – Planning phase

•

•

•

Vision

Specification document

Activity schedule and team

– Development phase

•

•

•

First 1/3 of functions (critical functions, shared components)

Second 1/3 of functions

Final 1/3 of functions (least critical functions )

– Stabilization phase

•

•

•

Internal testing

External testing

Release production

• Currently is being substituted by MSF





Features: • –

–

–

–

3-4 incremental product versions, including:

Synchronization (testing, integration, testing)

Stabilization (reduction of faults, detected by tests)

“Freezing” – working product “slice”

• Benefits: –

–

“f req u en t an d early” t est in g (and error detection) Continuous interoperability (modules are tested together =>

operational product version always available => intra-module

relationships are easy-to-test)

Early product correction (full earlier version product “assembly”

allows to detect product odds before full-scale implementation =>

redesign cost cutdown)

–





• Drawbacks:

– Suitable for certain product types (e.g., only for those, which

support test automation)

Certain amount of time should be spent for synch-stabilization

(not development itself) –

– Frequent integration/testing cycles required (monthly or

weekly)

Seldom used outside Microsoft –




Lifecycle Models: Spiral

• Features:

–

–

–

Rapid prototyping advantages application to the entire lifecycle

Based on waterfall model and risk analysis

Risks analyzed at the start of each phase (detection and mitigating

of the most serious project risks)

Project terminated if risks cannot be eliminated –

– Several prototyping steps and unlimited iterations number allowed




Lifecycle Models: Spiral (Boehm, 1987) A kind of iterative/evolution model

Every cycle includes 4 phases:

1. Define goals: define product,

define business goals,

understand constraints, suggest

alternatives Estimate alternatives: risk analysis, prototyping

Product development: detailed

product, code, unit testing,

integration

Next cycle planning: client

assessment, design plan, supply,

implementation

2. Risk? Prototypes

Risk?

Risk?

Risk?

Operations

3. 3 2

1 Review/Accept. Models

Req. Mgmt. 4. Concept/

Vision

Product Det.

Design Design

Code

Unit

test

Req.

Mgmt. Req.

Anal. Impl. Plan

К и П

проекта

Integr.

testing

Accept.

testing

Integr. & Test

Plan

Inslalla-

tion

3

4

2

1





•

•

Features:

4 major kinds of activities for every stage:

–

–

–

–

Define goals, alternatives, constraints

Evaluate alternatives, detecting and mitigating risks

Develop and verify the next-level product

Plan the next stage



• Benefits :

–

–

–

Reusability (due to alternative analysis and evaluation)

Reasonable testing (due to risk analysis)

”Seamless“ transfer to maintenance (due to cyclic product development till

product transfer)

• Drawbacks:

–

–

–

Suitable for in-house projects only (requirement and risk evaluation required)

Suitable for large-scale projects only (risk evaluation is cost-intensive)

Risk assessment experience required




“Object-based” Lifecycle Models

Q.1: Is the OO model an iterative or a sequential one? Why?

Q.2: What are the lifecycle features of the OO model?

Q.3: What are the challenges of an OO model? How can we mitigate these challenges?


answer.

your




Lifecycle Models: OO (e.g. fountain)

• Features:

–

–

–

–

Intensive interaction between lifecycle phases

Explicit iterative lifecycle phases change

Phases interlap (e.g., OOA and requirement specification, etc.)

OOD phases usually include OOA phases (e.g., use-case analysis,

object modeling, etc.)

– Backtrack to

interaction)

earlier lifecycle phases is possible (arrows mean




Lifecycle Models: OO




Lifecycle Models: OO

• Benefits:

– Naturally suitable for OO (E)SSD

Drawbacks: •

– Weal development constraints may lead (under bad project

discipline) to degradation to Build-and-Fix




Product Size/Scope & Lifecycle Models

Q.1: How can we measure product complexity? Where is ESS?

Q.2: How can SDL methodologies scale to meet the complexity?

Q.3: Can a SDL methodology work with single/multiple model(s)? Why?


answer.

your




Lifecycle Models: Project Complexity High Technical

Complexity

National Air

Communication

Control System DOD Arms

Control System

Telecom Switch

Embedded

Automobile

Application Commercial

Compiler

Low Management

Complexity

High Management

Complexity Large-Scale

Model

Small-scale

Research Model

Web Application ESS

On-line Store

Business

Spreadsheet

Low Technical

Complexity

Is there a single universe lifecycle model?




Formal/Iterative Models (1) Waterfall

Few risks, sequential order

Late integration & testing

DOD-STD-2167 +MIL-STD-1521

Weakly Formalized

Little documentation

Light process

Few “customs”

MIL-STD-498

Well-Formalized

Well-documented

Traceability

Changes control

Many “customs” Adaptive

development

XP SCRUM

Iterative

Risk-driven

Continuous integration & testing

CMMI

CMM




Formal/Iterative Waterfall

Models (2)

Weakly Formalized

Strongly Formalized RUP Process Model

“Light” RUP

“Large” Formal RUP “Middle”

RUP

Iterative

42




Lifecycle Models: Benefits and Odds

Wh at are th e strength s and weaknesses of … model ?

Why? Q.1:

Q.2:

Q.3:

Q.4:

Q.5:

Q.6:

Q.7:

…

…

…

…

…

…

…

build-&-fix …

waterfall …

rapid prototyping …

incremental …

synchro-stabilization…

spiral …

OO …

*Work in pairs (2 mins). Discuss results (1 min). Give your

answer. National Research University - Higher School of Economics, 2015-16



SDL models: comparison and conclusion

Build-and-Fix Totally invalid for non-trivial p rojects

Rapid Prototyping Product features meet client’s requirements

Rarely used outside Microsoft

OO Intra-phase iterations,

SDL Model Benefits Shortcomings

Valid for small p rojects, which do not

require maintenance

Waterfall Well-discip lined, document driven Software may not meet client's requirements

Temp ts for reusing code, which should be

rewritten from scratch

Incremental Early ROI; maintainability Requires op en architecture; may degenerate into

Build-and-fix

Synchostabilization Meets future client requirements; p rovides

comp onent integration

Spiral Accumulates features of all the above Only valid for large in-house p rojects;

models develop ers should know risk management well

may degenerate into Build-and-fix

inter-phase p arallelism




References

Readings: Main

Sommerville I. Software Engineering (8th Edition). Pearson Education Ltd., 2008, 850 pp.

Schach S.R.: Object-Oriented and Classical Software Engineering (5 ed.) McGraw-Hill, 2001, 744 pp.

Zykov S.V. Enterprise portal development.– М.: MIPT, 2005.– 258 pp. (in Russian).

Booch G., Jacobson I., Rumbaugh J. The Unified Modeling Language User Guide. Addison Wesley, 1998

Fowler M. Patterns of Enterprise Application Architecture. Addison Wesley, 2004, 533 pp.


http://www.amazon.com/gp/reader/0073191264/ref=sib_dp_pt/104-7158000-1555147



References

Additional Readings:

• Martin Fowler, The New Methodology

http://www.martinfowler.com/articles/newMethodology.html






















































Business-Case: African Ethnic E-Shop

SDL Model Choice

Project: E-shop of African

ethnic goods

Based on the product objectives, choose the most suitable

model. Justify your choice in a short (1-page) essay.

Determine and justify acceptability and suitability/utility for each

the seven SDL models studied.

of




Thanks for your attention!

Questions?

• http://www.hse.ru/org/persons/3468544/index.html

• http://zykov.altweb.ru

• [email protected]

• [email protected]


http://www.hse.ru/org/persons/3468544/index.html



































http://zykov.altweb.ru



















mailto:[email protected]





























03.2. lifecycle models

Documents

lifecycle model choice

longer lifecycle

process of standard

essd choice criteria

productbased development

project type

fix features

activities task