cmpt 275 software engineering

1

CMPT 275Software Engineering

Software life cycle

Janice Regan, 2008 2

Software Life Cycle Sequence of processes completed as a

software project moves from inception to retirement

At beginning of project development, choose Software development paradigm Software development process model

Define the order/manner in which software life cycle processes are performed

Then you are ready to start software specification, design, implementation, validation


Development Processes Next we will discuss a list of processes that

need to occur some time during the lifetime of a project. The exact order of the processes and the

number of times the processes are done will vary according to the process model developed

Some processes can be considered to happen before, during or after development

Other process occur at any time during development


Processes For each process we consider we will

decide/indicate when the process will most likely occur, give a name for the process, and give a list (partial?) of activities that comprise the process

WHEN: before, during, after development Name of process

List of activities


Development Processes - 1 WHEN: before development

Concept Exploration Identifying idea and need for a product Formulate possible approaches to solution

(high level only) Determining feasibility, identifying and

mitigating risks promotion concept and setting up

funding/support


Development Processes - 2

WHEN: before development System allocation

Estimating, planning and identifying staffing needs for each phase

Determine system architecture


Development Processes - 3 WHEN: during development

Requirements Analysis gathering, specifying and analyzing the

requirements. Defining functionality and scope (limits on

functionality) Define interface requirements Prioritize requirements Validate and Verify requirements


Development Processes - 4 WHEN: during development System and Software Design

Design how software will be structured internally

Establish system architecture Select or develop algorithms (if needed) Describe software system abstractions and

relationships Analysis of the design and verification that

the design meets the requirements


Development Processes - 5 WHEN: during development

Implementation: Programming (and building) Verification that implemented software

meets all requirements Plan unit implementation and integration

(implementation/test) Create user manual (operating instructions)


Development Processes - 6

WHEN: during development Testing (verification of implementation

phase) Testing modules (unit test) Testing combinations of modules

(integration test) Testing the whole system (system test)


Development Processes - 7 WHEN: post development

Installation Installation at user site (plan test accept) User testing, verifying user needs are met

(includes user acceptance test or UAT) Errors corrected, bugs fixed


Development Processes - 8 WHEN: post development

Operation and Support (maintenance) Software enhanced (new features, new

requirements) Errors corrected, bugs fixed Evolution to newer platforms (newer OS,

hardware) Retirement: post development


Integral Processes Integral processes take place during all

phases of development Verification and Validation: Software Configuration and Management

Configuration Control, Revision management Tracking and control of changes

Documentation development / distribution Training

Plan, Develop, Validate, Implement training program


Life cycle models Combine the development processes and activities

in different ways (different order, once or repeated …) to model the life cycle of a project

By making models of the life cycle of successful software projects can help us design better approaches to plan the life cycle of future projects

There are several ‘generic’ life cycle models that are often used or used as a basis for design of custom life cycle models


Generic Life Cycle models Sequential (activity centered) Perspective

The waterfall method V model

Iterative (activity centered) development Evolutionary Spiral


Types of Generic Process Models - 2

Component Based Perspective Focus on applying reusable components

(most already exist) Rational Unified Process

Combines aspects of all three perspectives Useful for large systems


Waterfall Process Model Project

Initiation ConceptExploration System

Allocation RequirementsDesign

ImplementationInstallation Operation

& Support

Verification Validation


Waterfall Process Model

ProjectPlanning

RequirementAnalysis

Design

ImplementationTesting

Maintenance


V Model System

RequirementsAllocation

RequirementsElicitation

Unit Test

Implementation

Operation

Component Integration/test

RequirementsAnalysis

PreliminaryDesign

DetailedDesign

SystemIntegration/test

ClientAcceptance


Why a Waterfall Process Model? Phases (processes) are performed once

Makes the process easy to follow One phase should not be started until the

previous one is complete Makes the process easy to manage Documents need only be produced and

approved once (this is a costly process) Parallels other engineering process models

The waterfall method should only be used if the requirements are well understood


Impractical to fully complete any one of thephases before starting the next one difficult to capture all requirements before

proceeding to design … Users don’t get to see the results until the

end problems may emerge only at the end when

user realizes the product is not what was needed

Why not ?


How can we modify these sequential life cycle model to address these problems

Prototypes can be useful to show to the user to catch problems

before implementation can also be misleading as the client must understand that

the system is not ‘almost ready’ Allow for return to earlier processes to update

models to include changes to fix deficiencies found in later processes: incorporate iteration

Allow for an incremental approach of developing a basic solution, then adding additional functionality

Fixing the problems


Modified Waterfall Model

ProjectPlanning

RequirementAnalysis

Design

ImplementationTesting

Maintenance

Add some iteration


Evolutionary model Iterative and incremental (many waterfalls) Software system to be developed is partitioned

into development phases (sub goals) that include some user driven subset of the functionality of the entire project (e.g. Critical Functionality, Required Functionality, Desired Functionality)

Each phase has its own requirements analysis followed by design, implementation, and testing

Each phase adds additional functionality to the project


Boehm’s spiral model

After Boehm, 1987

Unit Test

and testAcceptance test

System test


Spiral model Round 0: Feasibility study Round 1: Requirements development Round 2… : Development / test of system Risk analysis aspect is critical. In any round

development can stop is risk is too high Requirements clearly defined and completely

defined, risks are all low and a single round of development reduces to a waterfall

Requirements clearly defined, but lowest risk in 1st round, higher in 2nd reduces to evolutionary


Evolutionary Process Model - 1 Advantages:

Helps assure modularity and maintainability Each version built on tested results of a previous version User/client feedback of first iteration (could be a prototype)

provides opportunity to catch potential problems, or misunderstanding early

Helps improve project time estimation Record time taken during first iteration Helps produce better estimations for next iterations

Test plans can be expanded for new functionality in later iterations


Disadvantages:Because of overlapping iterations Synchronizing documentation Management overhead

Evolutionary Process Model - 2


Programming Paradigm The process life cycle models we have

discussed were developed before the OO paradigm came into common use

Some models can be adapted to the new paradigm

What about life cycle models specifically for the OO paradigm?


OO: Dividing Tasks During requirements analysis identify

requirements or groups of requirements that have different priorities. As an example Core functionality (for OO a few use cases) Necessary additional functionality (for OO add

use cases) Desired additional functionality ( for OO add

more use cases)


OO: Incremental Development A proposed approach for the example:

Develop the Core functionality. Get feedback from the client

As a second iteration/increment add the necessary additional features, repeat the linear sequential process. Get more feedback

Finally (time permitting) complete a third iteration/increment to add the desired additional functionality


Prototyping Build a mock up of the system for evaluation by

client Helps confirm you are on the right track

Mock-ups may be throwaway, that is rapidly constructed, (usually in a modeling language too inefficient for the final system) to illustrate the functionality of the system

Mockups may be incremental, demonstrating some aspects of the system

Beware the client may see the mock-up as an almost finished product, not a tool for interactive development with input from the client

33

Agile development: Scrum Please refer to an excellent online

summary and video at

http://scrumreferencecard.com/scrum-reference-card/

http://scrumtrainingseries.com/Intro_to_Scrum/Intro_to_Scrum.htm

Janice Regan, 2008




34

SCRUM Three roles Project owner – has overview of entire

project (might include multiple scrum teams)

Scrum manager (no management authority, a facilitator)

Scrum team (ideally small < 6) a group of developers with a variety of skills

Janice Regan, 2008

35

Scrum: incremental development Task are kept in a “backlog” Scrum team accepts tasks (features) from

“backlog” as they are ready to deal with them.

Develop working system by adding one feature or one small group of features at a time.

Janice Regan, 2008

cmpt 275 software engineering

Documents

development system

list of processes

project development

software life cycle

development processesnext

software design design

requirementsjanice regan

system system testjanice