software lifecycle software lifecycle basics lifecycle models methods and tools

Software Lifecycle

Software Lifecycle Basics

Lifecycle Models

Methods and Tools

Topic 2 Software Lifecycle 2

Software Lifecycle

• A series of steps through which a software product progresses

• Lifetimes vary from days to months to years• Consists of

– people!

– overall process

– intermediate products

– stages of the process

3Software LifecycleTopic 2

Software Production Personnel

• Client – individual or organization that wants product to be developed

• Developer(s) – (members of) organization producing product

• User – person on whose behalf client has commissioned developer, person(s) who will utilize software in operation


Kinds of SW projects

• Internal software development: user = client = developer

• Contract software development: user = client developer

• Commercial software development: user client = developer.


Quality Products through Process

• Quality software products developed through– systematic software processes

– with explicit product quality requirements

• Effective testing and analysis must be included– incremental analysis activities

– to complement synthesis activities

• Powerful tools and processes are essential to assure effectiveness


What is a Process?

• Device for producing a product (getting job done)• Indirect nature

– Process description (program) created to describe wide class of instances

• Humans create process descriptions (models or programs) to solve classes of problems

• Software Processes: stratagem for creating and evolving software products


Major Components of a Lifecycle Model:

• Phases

• Intermediate Products

• Reviews

Major Components of a Lifecycle Model:

• Phases

• Intermediate Products

• Reviews

The Lifecycle Approach

• Phasing promotes manageability and provides organization

• Intermediate software products promote visibility and assure continuity between phases

• Reviews assure ultimate satisfaction of requirements


Phases of a Software Lifecycle

• Standard Phases– Requirements Analysis and Specification

– Design

– Implementation and Integration

– Operation and Maintenance

• Testing throughout!

• Requirements changes inevitable!


Intermediate Software Products

• Objectives:– Demarcate end of phases

– Enable effective reviews

– Specify requirements for next phase

• Form:– Rigorous

– Machine processible

• Content:– Specifications

– Tests

– Documentation


Lifecycle Reviews• Reviews conducted with each phase

• Review intermediate software products

• Objectives– Validate that inspected specification conforms with requirements and/or verify that

it conforms to product resulting from previous phase• Detect points of non-conformance

– Discover “all” defects currently present in the product under development (as early as possible)

• Detect defects in software specification

• Detect defects in a specification's representation

– Measure product quality

– Measure development process• Evaluate techniques and tools

Feedback for specifiers to improveFeedforward for process and quality control

Feedback for specifiers to improveFeedforward for process and quality control


Requirements Analysis and Specification• Problem Definition —> Requirements Specification

– determine exactly what client (and user) wants and process constraints

– develop a contract with client

– what task the product is to do

• Difficulties– client asks for wrong product

– client is computer/software illiterate

– specifications may be ambiguous, inconsistent, incomplete

• Validation– extensive specification reviews to check that requirements specification

satisfies client needs

– look for ambiguity, consistency, incompleteness

– check for feasibility, testability

– develop system/acceptance test plan


Design• Requirements Specification —> Design

– develop architectural design (system structure): decompose software into modules with module interfaces

– develop detailed design (module specifications): select algorithms and data structures

– maintain record of design decisions and traceability– how the product is to do its task

• Difficulties– miscommunication between module designers– design may be inconsistent, incomplete, ambiguous

• Verification– extensive design reviews (inspections with checklists) to determine that

design conforms to requirements– check module interactions– develop integration test plan


Implementation and Integration• Design —> Implementation

– implement modules and verify they meet their specifications– combine modules according to architectural design– how the product does its task

• Difficulties– module interaction errors– order of integration has a critical influence on quality and productivity

• Verification and Testing– extensive code reviews (inspections with checklists) to determine that

implementation conforms to requirements and design– develop and test on unit/module test plan: focus on individual module

functionality– test on integration test plan: focus on module interfaces– test on system test plan: focus on requirements and determine whether

product as a whole functions correctly


Operation and Maintenance• Operation —> Change

– maintain software after (and during) user operation

– integral part of process

– determine whether product as a whole still functions correctly

• Difficulties– design not extensible

– lack of up-to-date documentation

– personnel turnover

• Verification and Testing– extensive review to determine that change is made correctly and all

documentation updated

– test to determine that change is correctly implemented

– test to determine that no inadvertent changes were made to compromise system functionality (check that no affected software has regressed)


Lifecycle Models

• Over time different lifecycle models developed, e.g.,– build-and-fix model

– waterfall model

– prototyping model

– incremental model

– spiral model

– .…

• Different lifecycle models decompose software engineering activities in different ways and are applicable for different applications and organizations

No "right" or "wrong" lifecycle modelNo "right" or "wrong" lifecycle model


Build FirstVersion

Retirement

Operations Mode

Modify untilclient is satisfied

Build-and-Fix

Is this yourusual model?

Is this yourusual model?


Requirements

Verify

Retirement

Operations

Test

ImplementationVerify

Design

Req. Change

Waterfall (collapsed)

Key features:- requirements phase- intermediate products- V & V steps

Key features:- requirements phase- intermediate products- V & V steps


Rapid Prototype

Verify

Retirement

Operations

Test


Design

Req. Change

Rapid Prototyping

Key feature:- prototype

Key feature:- prototype


For each build:Perform detaileddesign, implement.Test. Deliver.

Requirements

Verify

Retirement

Operations

Verify

Arch. Design

Incremental

Key features:- incremental delivery- frequent builds

Key features:- incremental delivery- frequent builds


Concept of Operation

Requirements Plan

Requirements OAC

Risk Assessment

Risk It

em Set

Risk M

anag

emen

t Plan

Requirements

Risk Control

Requirements Validation

Abstract Specification Plan

Abstract Specifcation OAC

Risk Assessment

Risk Control

Abstract Specification

Abstract Specification Validation

Concrete Specification Plan

Concrete Specification OAC

Concrete Specification

Concrete Specification Validation and Verification

Software Development Plan

Risk Assessment

Risk Control

Progress through steps

Cumulative cost

Evaluate alternatives, identify, resolve risks

Develop, verify next-level product

Plan next phases

CommitReview

partition

Determine objectives, alternatives, constraints (OAC)

The Spiral Model [Boehm,1988]


Add a Risk Analysisstep to each phase!

Add a Risk Analysisstep to each phase!

Requirements

Verify

Retirement

Operations

Test


Design

Req. Change

Risk Assessment

Risk Assessment

Risk Assessment

(Extremely) Simplified Spiral Model


Synchronize-and-Stabilize

• Requirements phase similar to Waterfall model• Features are divided into “builds” or versions• Synchronize: code is integrated at the end of each day,

then tested and debugged• Stabilize: when all features of a build are completed and

known faults are fixed• Always have a working version of the product• Used successfully by Microsoft• Design phase is de-emphasized


Extreme Programming

• Based on incremental model• Potential features are identified, along with cost (similar

to requirements phase)• Initial features are chosen based on cost-benefit analysis• Implementation proceeds by programming pairs• Design is de-emphasized• No specialization among team members; “ego-less

programming”


Software Methods and Tools

• Methods provide a means or procedure for accomplishing a task

• Tools are devices for performing some task– analytical tools

– software tools

• Methodology guides the proper use of methods and tools• Process helps to enact a methodology• Environments are a synergistic collection of tools with

process support


Analytical Tools

• Problem solving techniques that help in software development– cost-benefit analysis

• compare expected benefits against estimated costs

– stepwise refinement• divide and conquer

– abstraction• focus on some important property and ignore (for the time being)

irrelevant details

• Analytical tools underlie many software development methods


Software Tools

• Software tools are an automated implement for performing a task

• Tools facilitate work because they are– fast, immune to boredom and "cheating"

• Ideal Software Tools are ...– powerful, effective, convenient, natural, reliable, robust

• Most software development tools are not• exceptions: compilers, editors, loaders

– these have been polished, refined, and debugged through long-term use and hence made reliable and robust

– these have been made natural and effective through extended exposure and maintenance


Tool Obstacles

• Tool use obstacles– developers tend to be like hammer and screwdriver carpenters

– tools are not powerful and/or effective

– tools are unreliable and/or unrobust• comes with time and money

– tools are inconvenient and/or unnatural • comes from successful use

• Tool building obstacles– Short history of large-scale software development

– Limited success in • developing software well

• exploiting “tools” successfully

– Few software techniques have had time and use required to achieve tool status

– No “tools” at all in some key areas (e.g., real-time analysis)