Lecture 3: Software Process Models Dr Valentina Plekhanova University of Sunderland, UK cs0vpl/SE-Com185.htm.

Lecture 3Lecture 3:: Software Process ModelsSoftware Process Models

Dr Valentina PlekhanovaDr Valentina Plekhanova

University of Sunderland, UKUniversity of Sunderland, UK

http://www.cet.sunderland.ac.uk/~cs0vpl/SE-Com185.htmhttp://www.cet.sunderland.ac.uk/~cs0vpl/SE-Com185.htm

Lecture 3 Valentina Plekhanova 2

Week 8:Week 8: 24.04.2003-28.03.2003 24.04.2003-28.03.2003Project Control SessionProject Control Session Tutorial Time: 10 minutes for each Team Tutorial Time: 10 minutes for each Team Students will present project file, particularly

ScheduleSchedule, plus any project documentationdocumentation. Students will describe where they are in the

project and any problems encountered. During the discussion reviewers will ask to see

evidence of deliverables for any tasks that are complete to determine whether they have in fact been done.












Basic Definitions: Basic Definitions: Process ModelProcess Model A representation of a process. Some of the key components of a process

model are the activitiesactivities that must be performed, the agentsagents that perform the activities, the productsproducts that are produced, and the resourcesresources that are needed for an activity [Pankaj K. Garg, Mehdi Jazayeri, 1996.] .


Traditional Definition Traditional Definition [Boehm, 1988][Boehm, 1988]

The main functionmain function of a software development process model is to establish the orderorder in which major tasks are performed within a project, and to establish the transition criteriatransition criteria for proceeding from one task to the next.


GoalGoal A process model presents desired phases or

activities in a project …????


Process Element Process Element Any component of a process. Process elements range from individual

process steps to very large parts of process.


Process Step Process Step An atomic action of a process that has no

externally visible substructure.


AgentAgent An actor (human or machine) who

performs a process elements.


Role Role A coherent set of process elements to be

assigned to an agent as a unit of functional responsibility.

A single agent can perform multiple roles and a single role may be performed by multiple agents.


Artifact Artifact A product created or modified by the A product created or modified by the

enactment of a process element.enactment of a process element.


Software Process Models: Software Process Models: IntroductionIntroduction

What are the common process models for What are the common process models for

developing software?developing software?


Software Process ModelsSoftware Process Models A process model is a development strategydevelopment strategy

that encompasses the processprocess, methods methods and tools layerstools layers and the generic phasesgeneric phases (see Lecture 1).

The process model for a project is selected to support the nature of the project, the application domain, tools available, and the controls and deliverables required.


Software Process ModelsSoftware Process Models The process model for a project is selected

to support the nature of the project, the application domain, tools available, and the controls and deliverables required.

No agreement on a ‘best’ process model.


Software Process ModelsSoftware Process Models The life cycle history of each software product is

different. Some products will spend years in the conceptual

stage, other products will be quickly designed and implemented and some products must be developed from scratch.

Various models have been designed to undertake the process.


Software Process ModelsSoftware Process Models It is recognised that: Process Model

Describes development strategy encompassing processes, methods, tools.

Brings order into chaotic activities. Assists in controlling and co-ordination of

software projects.


Software Process Models: BenefitsSoftware Process Models: Benefits There are several benefits that have been

suggested for utilising process modelling [Kellner and Hansen, 1989; White, 1992]. The main ones are (but not limited to): facilitating reasoning and communication about the

process; analysing, studying, controlling and managing the

process; determining ways in which the process may be

improved.


Some ModelsSome Models or Some Paradigms or Some Paradigms of Software Developmentof Software Development Waterfall Waterfall Document-driven Time-Milestone Driven Model Evolutionary PrototypingEvolutionary Prototyping Risk-Based Spiral Model Risk-Based Spiral Model "Buy Commercial-Off-The-Shelf" Model Evolutionary Development Risk Reduction/Waterfall Incremental Development


The Linear Sequential ModelThe Linear Sequential Model Also called the waterfall modelwaterfall model

or classic life-cyclelife-cycle.

The waterfall modelwaterfall model presents a documentation-driven approach [Royce, 1970; Boehm, 1981]. This model was developed to provide support for the developers to produce the necessary documentation.


Sequential set of phasesSequential set of phases Software Requirements Analysis System and Software Design Writing the Programs (or coding, program

implementation, code generation)

Testing (unit testing, integration testing, system testing, acceptance testing)

Maintenance


The Waterfall ModelThe Waterfall Model Requirements Documents

System Specification

System Design Models

Working Alpha System

Final Release System

RequirementsRequirementsCaptureCapture

SystemSystemAnalysisAnalysis

SystemSystemDesignDesign

SystemSystemImplementationImplementation

SystemSystemTestingTesting

SystemSystemMaintenanceMaintenance


The Waterfall ModelThe Waterfall Model: Advantages: Advantages The waterfall model allows correction of

the failed tasks. This is represented by the feedback loops for task performances.

Simple to implement and manage. Well used.


The Waterfall ModelThe Waterfall Model: Disadvantages: Disadvantages Real projects are not sequential. Can not state requirements completely early. Customer does not see system until after testing. Development often results in parts of project being

‘blocked’. Emphasis is on ease of project management. Method does not scale up to large projects well. Can not ensure that the delivered product satisfies the

customer’s requirements and the project proceeds in an essentially fixed sequence of phases.


The Prototyping ModelThe Prototyping Model The prototyping model is often used when some

aspects of the system are not well defined. PrototypingPrototyping is focused on a target product [Lantz,

1985; Connell and Shafer, 1989; Gane, 1989]. This model helps to ensure (in comparison with

the waterfall model) the development of delivered products that satisfy the customer’s real needs.


The Prototyping ModelThe Prototyping Model The general idea is to construct a series of

prototypes to allow users to examine these and then to indicate what changes they want in the next one.

It should be pointed out that the prototypes It should be pointed out that the prototypes are usually built using a waterfall model are usually built using a waterfall model process.process.


The Prototyping Model:The Prototyping Model: Basic Steps - Requirements GatheringRequirements Gathering Obtain requirements from customer. Identify areas of uncertainty. Quick Design and BuildQuick Design and Build Quick design of aspects of system visible

to customer. Quick development of a prototype

implementation.


The Prototyping Model:The Prototyping Model: Basic Steps - Customer Evaluation of PrototypeCustomer Evaluation of Prototype Prototype used to refine the requirements

of the system.

*********************** These basic steps are repeated until

requirements are well defined. Should discard prototype and build the

‘real’ system.


The Prototyping Model:The Prototyping Model: AdvantagesAdvantages Customer can provide input to system early

during the development of the prototype, and will usually get a system which does what they require, and which they want.

Reduces problems in requirements which are the most expensive to fix.


The Prototyping Model:The Prototyping Model:DDisadvantagesisadvantages Customers see a working version early, and

unless they have a basic knowledge of the process, can not understand why it should be thrown away.

The customer sees the prototype built quickly - may not understand why the ‘real’ version takes so long.

Developer may make implementation decisions to get the prototype working quickly, and these may be carried over to the ‘real’ system.


The Spiral ModelThe Spiral Model The Spiral modelSpiral model is a risk-driven approach

[Boehm, 1988]. The primarily goal of this model is to

determine the risks involved in the process of product development and then to attempt to minimise those risks.

Spiral model is divided into a number of framework activities (or task regions).


The Spiral ModelThe Spiral Model The specific character of the spiral model

is that it provides risk analysis before initiating each life-cycle phase.

This model represents a significant advantage by the incorporation of risk analysis, multiple paradigms, managerial and planning issues.


The Spiral ModelThe Spiral Model The spiral modelspiral model views the development process in

polar coordinates. … (!!!) The plane is divided into four quadrants that represent

different kinds of activities, as follows:I. Determination of objectives, alternatives, and

constraints.II. Evaluation of alternatives; identification and resolution

of risks.III. Development activities.IV. Review and planning for future cycles.


The Spiral ModelThe Spiral Model ((figure shows a single cycle of the spiral)figure shows a single cycle of the spiral)


The Spiral ModelThe Spiral Model Specific activities may overlap multiple spirals. Also, concurrent spirals may be required to

address varying areas of risk. The commitment line may involve a decision to

terminate the project or change direction based on the review results.

Some cycles of the spiral may require months to complete, while others require only days.


The Spiral ModelThe Spiral Model Each cycle of the model addresses all the

activities between review and commitment events.

Early in the process, cycles may be short as alternatives in the decision space of the project are explored.

As risks are resolved, cycles may stretch, with the development quadrant subsuming several steps in the waterfall.


The Spiral ModelThe Spiral Model The spiral may be terminated with product

delivery—in which case modification or maintenance activities are new spirals—or continue until the product is retired.


The Spiral Model: Advantages The Spiral Model: Advantages Matches reality in that requirements

change over the life of a project. Has advantages of prototyping - customer

has early input into system. Many adaptations possible. Requires consideration of risks at all stages

of the development


The Spiral Model: DisadvantagesThe Spiral Model: Disadvantages Customers may be concerned about control

of the process in the spiral model. Can lead to difficulties in contract negotiations.

Requires considerable expertise in risk assessment.

Has not been as widely used as linear sequential model (seen as ‘new’).


Summary Summary Current software process models differ

from each other by the goals and the different ordering of project tasks.

Most current software models present only Most current software models present only one aspect that bears upon process one aspect that bears upon process development - namely, to present a development - namely, to present a description of process activities for description of process activities for software creation and evolution. software creation and evolution.


SummarySummary However, software is developed by people within

a complex environment which can be defined by organisational, social, technical, psychological and other aspects.

Hence, one of the major reasons for the lack of process modelling success in practical applications is that the existing process models do not represent the human factors and environment settings in which projects exist.


Week 4: 24.02.03- 28.02.03Week 4: 24.02.03- 28.02.03 Project Control SessionProject Control Session Tutorial Time: 10 minutes for each Team Tutorial Time: 10 minutes for each Team Project Team will present project file: Schedule,

any project documentation. Students will describe where they are in the

