ch2_processmodels
ch2_processmodels
Chapter 2:
Software Process Models
Chapter 2 & 3 in Software Engineering Book
2
Overview
What are software process models?
Models:
Waterfall models.
Evolutionary models.
CBSE models.
Iterative models.
3
6
7
Waterfall model.
Evolutionary models.
Iterative Models.
10
1. Waterfall Model
Requirements
Design
Operations &
Maintenance
11
1. Waterfall Model
2. Evolutionary Models
13
Concurrent Activities
Initial
Specification
Version
Outline
Description Development
Validation Final
Version
14
1. Requirements gathering.
2. Design and build SW prototype.
3. Evaluate prototype with customer.
4. Refine requirements.
15
Development
System
and
validation
integration
•Web services that are developed according to service standards and which
are available for remote invocation.
•Collections of objects that are developed as a package to be integrated with
a component framework such as .NET or J2EE.
•Stand-alone software systems (COTS) that are configured for use in a
particular environment.
16
17
4. Iterative Models
18
System incomplete
Risk assessment and reduction: Risks are assessed and activities put in
place to reduce the key risks.
Planning: the project is reviewed and the next phase of the spiral is
planned.
21
What is risk?
Situations or possible events that may cause a project to fail to meet its goal.
Example risks:
Experienced staff leave the project.
Hardware which is essential for the system will not be delivered on schedule.
More about risks in Chapter 3 (22 in the book).
22
Development team:
Size.
Location: distributed vs. co-located.
Experience (skilled) and discipline (self-organizing).
Methods:
Individuals & interactions vs. Processes, phases & tools.
Adaptations to changing circumstances.
Measures of progress: working software, rapid delivery.
23
Evaluation of Models
24
Activity
1. Waterfall Model
Applicability:
Appropriate when requirements are well-understood.
Changes will be fairly limited during the design process.
Large interactive systems.
Problems:
Lack of process visibility;
Systems are often poorly structured;
Applicability:
For small or medium-size interactive systems;
For parts of large systems (e.g. the user interface);
For short-lifetime systems.
27
Disadvantages:
Developers may make implementation compromises in order to get a
prototype working quickly.
The process in not visible (few documents that reflect every version of
the system).
Systems poorly structured.
28
3. CBSE
Advantages:
Reduce amount of software to be developed.
Reduce costs and risks.
Faster delivery.
Disadvantages:
Requirements compromises’, system does not meet real needs of users.
Control over system evolution is lost.
29
Disadvantages:
Increments should be relatively small (20,000 lines of code).
Can be difficult to map the customer’s requirements onto increments of the right
size.
Hard to identify common functions.
30
Disadvantages:
Requires highly skilled people in risk analysis and planning.
Requires more time, and is more expensive.
Estimates of budget and time are harder to judge at the beginning of the
project since the requirements evolve through the process.
31