1 / 50 ©Jozef De Man 2007-2009 SW Development Life Cycles Software Development Life Cycles Prof. Dr. ir J. De Man

SW Development Life Cycles

1 / 50©Jozef De Man 2007-2009

Software Development Life Cycles

Prof. Dr. ir J. De Man


2 / 50©Jozef De Man 2007-2009

End-of-LifeOpportunity

Business Case Planning Development Validation Deployment Maintenance Phase-Out

Development Project

The (Development) Project Life Cycle covers the planning, development and verification of the product

Product and Project Life

CycleThe Product Life Cycle models the evolution of a product from

opportunity identification to its end-of-life


3 / 50©Jozef De Man 2007-2009

Philippe Kruchten The Rational Unified ProcessAddison-Wesley, 2000

Life CyclesIntroduction

The Life Cycle defines what must be done what must be produced (final and intermediate) in what sequence by whom

Basic Components Phases and Milestones Activities (Processes, Work Flows) Roles (Actors) Work Products (Artefacts)


4 / 50©Jozef De Man 2007-2009

Life Cycle Models

OverviewBuild & Fix

Waterfall, V-model

Incremental Development, Evolutionary Development

Spiral Model

Agile Development (Extreme Programming, Scrum,...)

Model-driven Software Development

End-user Programming

Open Source

Perpetual Beta


5 / 50©Jozef De Man 2007-2009

modifyfix

build

use

The Build&Fix Model

Start immediately with coding

No paperwork

Gradually add functionality to the working code

Critique Very efficient Works with single person as

developer Difficult to maintain, transfer

to other person Does not scale up (?)


6 / 50©Jozef De Man 2007-2009

analysis

design

codingunit test

systemtest

Waterfall ModelSimplified Picture

structured development process

a phase must be finished before the next one starts

the result of each phase must be documented

Winston Royce, Managing Development of Large Scale Software Systems, Proceeding of IEEE WESCON, August 1970

integrationtest


7 / 50©Jozef De Man 2007-2009

Waterfall ModelAssumptions

The requirements can be known in advance of implementation

The requirements can be fully defined without reference to an implementation

The requirements can be well-understood by all stakeholders: users, customer, developers, maintainers

The architecture of the system is well understood

Elapsed time and cost are not critical


8 / 50©Jozef De Man 2007-2009

analysis

design

codingunit test

integrationtest

systemtest

Waterfall Modeliteration with preceding phase

Feedback from each phase tothe preceding one

Baseline documents between phases are updated


9 / 50©Jozef De Man 2007-2009

Waterfall ModelSupport

All (intermediate) work products are placed under formal change control

version control status control changes are only allowed by formally approved change

requests or fault reports

All (intermediate) work products must be maintained

Traceability is established between baselines to trace requirements to implementation (downstream) and problems to corrections (upstream)


10 / 50©Jozef De Man 2007-2009

analysis

design

codeunit test

integrationtest

systemtest

black box test cases

white box test cases

Waterfall ModelV-model

System Test cases are developed during Analysis

Integration Test cases during Design

Unit Test cases during Coding

The addition of test cases reveals other feedback loops


11 / 50©Jozef De Man 2007-2009

analysis

design

codeunit test

integrationtest

systemtest

black box test cases

white box test cases

V-modelFeedback from Testing

very long and costly correction of early errors


12 / 50©Jozef De Man 2007-2009

V-modelHow to reduce the correction cycle?

Rapid prototyping build a prototype to uncover problems early use a fraction of the originally estimated time follow waterfall model in-the-small document the result throw it away (this is not the product)

Involve the customer Preliminary software review (prototype) Design Reviews Acceptance

Winston Royce, Managing Development of Large Scale Software Systems, Proceeding of IEEE WESCON, August 1970 (!)


13 / 50©Jozef De Man 2007-2009

V-modelHow to reduce the correction cycle (2)?

Write “quite a lot” of documentation Requirements Preliminary Design Interfaces, Test Plan, Design Operating instructions Update as required during life cycle

Plan, control, monitor testing separate testing group “visual inspection” by second party of all documents coverage of every logical path

Winston Royce, Managing Development of Large Scale Software Systems, Proceeding of IEEE WESCON, August 1970 (!)


14 / 50©Jozef De Man 2007-2009

Waterfall ModelCritique

The documentation of the intermediate results allows different people to work in each phase, supports transfer of work to other people and serves as basis for evolution

Paralysis by analysis: too much time may be spent the get the analysis right based on uncertain customer requirements

Maintaining “quite a lot of documentation” is costly and delays the process

The product is only delivered at the end, only documents are produced in the preceding phases; at the end we may discover that the product is not what the customer expected

It is difficult to cope with changing requirements during development


15 / 50©Jozef De Man 2007-2009

Incremental Development

Functionality is defined as separate “features”

Functionality is added incrementally highest risk first (to reduce risk and improve predictability) highest customer-value first

Advantages: Surprises at the end are reduced A usable product is delivered after the first increment Last increments can be abandoned to meet schedule

Plan

Design

Test

Waterfall Iterative


16 / 50©Jozef De Man 2007-2009

Evolutionary Development

Similar to incremental model

First version with basic functionality is delivered to the customer to obtain immediate feedback

Requirements can be defined and developed on the basis of a working system

“Late” requirements become the rule

Very fast time-to-market

Requires partnership supplier-customer - attractive for internal customer


17 / 50©Jozef De Man 2007-2009

Determine objectives,alternatives,constraints

Evaluate alternativesRisk Analysis

Development &Verification

Plan next phase

prototype

design

implement

test

deploy

reduce risklife cycle model may change at each cycle

Boehm’s Spiral Modela model for life cycles

feasibility study

development

Barry Boehm,A Spiral Model of Software Development and Enhancement, IEEE Computer, May 1988


18 / 50©Jozef De Man 2007-2009

http://agilemanifesto.org/

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation

Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent BeckMike Beedle

Arie van BennekumAlistair Cockburn

Ward CunninghamMartin Fowler

James GrenningJim HighsmithAndrew HuntRon Jeffries

Jon KernBrian Marick

Robert C. MartinSteve Mellor

Ken SchwaberJeff SutherlandDave Thomas


19 / 50©Jozef De Man 2007-2009

Plan

Design

Test

Waterfall Iterative Agile

Agile MethodsOverview

Kent Beck, Embracing Change with Extreme Programming, IEEE Computer, Volume 32, Number 10, October 1999, pp. 70-77


20 / 50©Jozef De Man 2007-2009

Agile DevelopmentPrinciples

Our highest priority is to satisfy the customerthrough early and continuous delivery

of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for

the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a

preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

http://www.agilemanifesto.org/principles.html


21 / 50©Jozef De Man 2007-2009

Agile DevelopmentPrinciples (2)

Build projects around motivated individuals. Give them the environment and support they need,

and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development

team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able

to maintain a constant pace indefinitely.



22 / 50©Jozef De Man 2007-2009

Agile DevelopmentPrinciples (3)

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs

emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts

its behavior accordingly.



23 / 50©Jozef De Man 2007-2009

Extreme Programming12 Practices

Kent Beck


24 / 50©Jozef De Man 2007-2009

Extreme Programming12 Practives (2)

Planning game. Customers decide the scope and timing of releases based on estimates provided by programmers.Programmers implement only the functionality demanded by the stories in this iteration.Small releases. The system is put into production in a few months, before solving the whole problem. New releases are made often—anywhere from daily to monthly.Metaphor. The shape of the system is defined by a metaphor or set ofmetaphors shared between the customer and programmers.Simple design. At every moment, the design runs all the tests, communicates everything the programmers want to communicate, contains no duplicate code, and has the fewest possible classes and methods. Thisrule can be summarized as, “Say everything once and only once.”



25 / 50©Jozef De Man 2007-2009

Extreme Programming12 Practices (3)

Tests. Programmers write unit tests minute by minute. These tests are collected and they must all run correctly. Customers write functional tests for the stories in an iteration. These tests should also all run, although practically speaking, sometimes a business decision must be made comparing the cost of shipping a known defect and the cost of delay.Refactoring. The design of the system is evolved through transformationsof the existing design that keep all the tests running.Pair programming. All production code is written by two people at onescreen/keyboard/mouse.Continuous integration. New code is integrated with the current systemafter no more than a few hours. When integrating, the system is builtfrom scratch and all tests must pass or the changes are discarded.Collective ownership. Every programmer improves any code anywhere inthe system at any time if they see the opportunity.



26 / 50©Jozef De Man 2007-2009

Extreme Programming12 Practives (4)

On-site customer. A customer sits with the team full-time (customer = end-user, marketing, product management,...).40-hour weeks (sustainable pace). No one can work a second consecutive week of overtime. Even isolated overtime used too frequently is a sign of deeper problems that must be addressed.Open workspace. The team works in a large room with small cubicles around the periphery. Pair programmers work on computers set up in the center.Just rules. By being part of an Extreme team, you sign up to follow the rules. But they’re just the rules. The team can change the rules at any time as long as they agree on how they will assess the effects of the change.accept responsibility for.



27 / 50©Jozef De Man 2007-2009

ScrumOverview

controlchaos.com


28 / 50©Jozef De Man 2007-2009

Agile DevelopmentPlanning

User Stories written by the customer, a few sentences with little detail

Release Planning Select stories with highest (business) value Unit for first effort estimation (a few weeks) Estimation in “ideal” weeks keep releases small (months)

Iteration Planning regular iterations (heartbeat of the project) Identify tasks of a story Let developers sign-on for tasks Ask developers for estimates extremeprogramming.

org


29 / 50©Jozef De Man 2007-2009

Agile DevelopmentTracking

Measure velocity of the team number of user stories in iteration number of tasks in iteration adjust planning of next iterations to measured velocity

Daily stand-up meetings (from Scrum) short (stand-up) communication within entire team mutual encouragement problems are revealed early tasks can be reshuffled


30 / 50©Jozef De Man 2007-2009

Agile DevelopmentPeople

Sustainable pace (not necessarily 40-hour week) overtime must be exceptional chronic overtime will affect quality it reduces morale

Team in one room direct face-to-face communication minimize paperwork and formal communication


31 / 50©Jozef De Man 2007-2009

Agile DevelopmentDesign

System metaphor easily understood by everyone serves as guidance for communication, terminology (e.g.

program variables) the domain itself may be an acceptable “naive” metaphor

Spike Solutions develop a “depth-first” solution to analyze requirements,

technical obstacles, obtain a better estimate


32 / 50©Jozef De Man 2007-2009

Agile DevelopmentDesign (2)

Things should be made as simple as possible, but not too simple (A. Einstein)

Yagni - You aren’t gonna need it implement the minimum that is expected do not prepare the code for potential future requirements

(they may never be needed)

Remove code that is not needed anymore

Refactoring

Code reveals intention (instead of comments)


33 / 50©Jozef De Man 2007-2009

Agile DevelopmentProcess

Customize XP rules to the team’s needs (not the person) some aspects of extreme programming are not essential and

can be suppressed or modified if necessary

Review/revise rules at the end of an iteration/release use release/iteration planning meetings to review what went

well or not and to adjust the process (XP rules)

Measure: Team velocity (stories/tasks per iteration) to adjust effort

planning Score of acceptance testing (quality) ...


34 / 50©Jozef De Man 2007-2009

Agile Developmentand CMMI

See technical report

CMMI or Agile, why not embrace both? CMU/SEI-2008-TN-003


35 / 50©Jozef De Man 2007-2009

Model Driven Software DevelopmentProcess Model

ERA

Process Description

Project/Process

The Process Model Hierarchy is an example ofModel Driven Software Development.The upper levels of the hierarchy define the genericpart of the software.Specific applications are generated by supplyinga data structure with the lower-level model definition

Process Model


36 / 50©Jozef De Man 2007-2009

Model Driven Software DevelopmentOther examples

Compiler-compilers (compiler generators)

Report generators, Form generators

Application generators

(Relational) Databases

Finite-state machines

ERP, CRM, PDM systems

Software Product Lines


37 / 50©Jozef De Man 2007-2009

MDSDComponent Development

Focus on re-usability

Includes parameterized components components with meta-model functionality reuse of designs by means of patterns

Two approaches separate component factory recommended: by-product of development project using e.g.

refactoring (identify duplication within projects)


38 / 50©Jozef De Man 2007-2009

End-User ProgrammingPrinciple

The designer of a system will always have difficulties capturing the requirements of the “end-user”

It is difficult to implement evolutionary changes to an existing system quickly and efficiently

End-User Programming offers a solution by turning the end-user into the implementer

The end-user must be able to express the solution with minimal education/training in computer programming

Examples: spreadsheets, databases, scripting languagesStefan Thomke and Eric Von Hippel,

Customers as Innovators, a new way to create value HBR April 2002


39 / 50©Jozef De Man 2007-2009

Open SourceDefinition

Free Redistribution - The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

Source Code - The program must include source code, and must allow distribution in source code as well as compiled form.

Derived Works - The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

opensource.org

free as in free speech, not free lunch

Copyleft All Rights Reversed


40 / 50©Jozef De Man 2007-2009

Open SourceDefinition (2)

The detailed definition contains several additional points, e.g. No Discrimination Against Persons or Groups No Discrimination Against Fields of Endeavor License Must Not Restrict Other Software License Must Be Technology-Neutral

Many different licenses exists with different restrictions: GNU General Public License (GPL) Lesser GPL Artistic, Apache, Mozilla, Nokia, IBM, MIT,...

opensource.org/licenses


41 / 50©Jozef De Man 2007-2009

Perl scripting language

GNU compiler collection

GNU Debugger

GNU/Linux Operating System

Emacs editor

Sendmail mail engine

Apache web server

Mozilla/Firefox web browser

Tomcat JSP

Mailman mail distribution

MySQL relational database

GNU is Not Unix

FreeBSD Unix

OpenBSD Unix

Open SourceA few examples

Thunderbird Mail Client

Subversion version control

Bugzilla

Wikis

Eclipse


42 / 50©Jozef De Man 2007-2009

Open SourceFavorable Conditions

Development starts from a substantial code base (not from the ground up), often developed by a single person or in a company

Selected features have minimal impact on the architecture

Interaction between features is small

Features do not have to be negotiated between participants (e.g. they are defined externally, e.g. by standards bodies)

The software is a “commodity” good, low cost is more important than distinguishing features


43 / 50©Jozef De Man 2007-2009

Open SourceWhy would one contribute?

Benefits of revealing innovation must outweigh the cost loss of intellectual property diffusion cost

In Open Source The intellectual property value associated with fixing a bug

or even implementing a feature is low and return is difficult to enforce

The cost to publish on the web is low The benefits of the combined efforts of all contributors are

much higher


44 / 50©Jozef De Man 2007-2009

Open SourceBusiness Model: public-private

Open source is made available as a public good

Why are private companies willing to contribute?

Contributors receive higher benefits than free riders They can drive implementation of features They have superior knowledge to offer services for the

software They can invest resources in add-ons with higher added-

value than the commodity open source


45 / 50©Jozef De Man 2007-2009

Open SourceContributors

Individual users who have an interest in the improvement and evolution of the open

source for their own use an academic interest in cutting-edge technology ...Hobby

Companies offering services related with the open source (e.g. packaged, fully tested, stable version at a fee)

Companies using the the open source as a platform for their own products


46 / 50©Jozef De Man 2007-2009

Open SourceBasic Roles

CommonSource

Co-developer Co-Developer

Modify andRelease in Common Source

User

Propose Modificationsfor Common Source

Contributor

Use and Modify


47 / 50©Jozef De Man 2007-2009

A Benevolent Dictator is arecognized and respected authority

Open SourceThe Cathedral and the Bazaar

The Cathedral Developed by a “closed group” Project Management techniques applied Managed by a Project Manager

The Bazaar - open source Developed by an open community No formal project management “Managed” by a Benevolent Dictator

But Open source is often developed in cathedral style! Or by a single person (cave development)

Eric Raymond The Cathedral and the Bazaar; First Monday


48 / 50©Jozef De Man 2007-2009

Open SourceContribution by testing

Characteristics Software is visible to very large community It is used and tested by a large expert community (e.g. at

universities) Access to the source enables more precise description of

possible defects Defects can easily be submitted and tracked via the web

Consequence Open source can be at least of the same quality as

commercial competitors Reaction time for urgent faults (security alerts) can be much

shorter


49 / 50©Jozef De Man 2007-2009

Perpetual Beta

Successful web (2.0) applications are offered as beta for a prolonged period to a large user community (e.g. Gmail)

SaaS: Sofware as a Service

Applications are not going through a release cycle but are offered as a continuously updated service


50 / 50©Jozef De Man 2007-2009

Development Production UseDistribution

Development pushed down the value chain

Review by customer (waterfall)Continuous participation of the customer/user (agile)

Customization by the user (e.g. spreadsheets)Development by expert users (open source)

ConclusionIncreasing participation of the customer/user

Documents

1 / 50 ©Jozef De Man 2007-2009 SW Development Life Cycles Software Development Life Cycles Prof. Dr. ir J. De Man