1. Chapter 3 Prescriptive Process Models
Software Engineering: A Practitioner’s Approach, 6th edition
by Roger S. Pressman – Ir. I. Joko Dewanto., MM
Universitas Esa Unggul

2. Software process model
Attempt to organize the software life cycle by
defining activities involved in software production
order of activities and their relationships
Goals of a software process
standardization, predictability, productivity, high product quality, ability to plan time and budget requirements

3. Code&Fix The earliest approach Write code
Fix it to eliminate any errors that have been detected, to enhance existing functionality, or to add new features
Source of difficulties and deficiencies
impossible to predict
impossible to manage

4. Models are needed Symptoms of inadequacy: the software crisis
scheduled time and cost exceeded
user expectations not met
poor quality
The size and economic value of software applications required appropriate "process models"

5. Process model goals (B. Boehm 1988)
"determine the order of stages involved in
software development and evolution,
and to establish the transition criteria for
progressing from one stage to the next.
These include completion criteria for the current
stage plus choice criteria and entrance criteria
for the next stage. Thus a process model addresses
the following software project questions:
What shall we do next?
How long shall we continue to do it?"

6. Process as a "black box" Quality? Uncertain / Incomplete requirement
In the beginning

7. Problems
The assumption is that requirements can be fully understood prior to development
Interaction with the customer occurs only at the beginning (requirements) and end (after delivery)
Unfortunately the assumption almost never holds

8. Process as a "white box"

9. Advantages Reduce risks by improving visibility
Allow project changes as the project progresses
based on feedback from the customer

10. The main activities of software production
They must be performed independently of the model
The model simply affects the flow among activities

11. Prescriptive Models That leads to a few questions …
Prescriptive process models advocate an orderly approach to software engineering
That leads to a few questions …
If prescriptive process models strive for structure and order, are they inappropriate for a software world that thrives on change?
Yet, if we reject traditional process models (and the order they imply) and replace them with something less structured, do we make it impossible to achieve coordination and coherence in software work?

12. The Waterfall Model

13. Waterfall Model Assumptions
1. The requirements are knowable in advance of implementation.
2. The requirements have no unresolved, high-risk implications
e.g., risks due to COTS choices, cost, schedule, performance, safety, security, user interfaces, organizational impacts
3. The nature of the requirements will not change very much
During development; during evolution
4. The requirements are compatible with all the key system stakeholders’ expectations
e.g., users, customer, developers, maintainers, investors
5. The right architecture for implementing the requirements is well understood.
6. There is enough calendar time to proceed sequentially.

14. Process for Offshore? Analysis Design Construct System test
Accept. test
Deploy

15. The V Model
If we rely on testing alone, defects created first are detected last
System
Requirements
Software
Design
Implementation
Unit
Testing
Integration
system test plan
software test plan
integration plan
unit plan
Product
Release
time
User
Need

16. Incremental Models: Incremental

17. Incremental Models: RAD Model

18. Evolutionary Models: Prototyping

19. Risk Exposure

20. Unified Process Model A software process that is: use-case driven
architecture-centric
iterative and incremental
Closely aligned with the
Unified Modeling Language (UML)

21. The Unified Process (UP)
inception

22. UP Work Products
inception

23. Lifecycle for Enterprise Unified Process
inception

24. Synchronize-and Stabilize Model
Microsoft’s life-cycle model
Requirements analysis—interview potential customers
Draw up specifications
Divide project into 3 or 4 builds
Each build is carried out by small teams working in parallel

25. Synchronize-and Stabilize Model (contd)
At the end of the day—synchronize (test and debug)
At the end of the build—stabilize (freeze build)
Components always work together
Get early insights into operation of product

26. Evolutionary Models: The Spiral

27. Spiral Model Simplified form Precede each phase by
Waterfall model plus risk analysis
Precede each phase by
Alternatives
Risk analysis
Follow each phase by
Evaluation
Planning of next phase

28. Simplified Spiral Model
If risks cannot be resolved, project is immediately terminated

29. Full Spiral Model Radial dimension: cumulative cost to date
Angular dimension: progress through the spiral

30. Full Spiral Model (contd)

31. Analysis of Spiral Model
Strengths
Easy to judge how much to test
No distinction between development, maintenance
Weaknesses
For large-scale software only
For internal (in-house) software only

32. Object-Oriented Life-Cycle Models
Need for iteration within and between phases
Fountain model
Recursive/parallel life cycle
Round-trip gestalt
Unified software development process
All incorporate some form of
Iteration
Parallelism
Incremental development
Danger
CABTAB

33. Fountain Model Features Overlap (parallelism) Arrows (iteration)
Smaller maintenance circle

34. Software Process Spectrum
Crystal Clear
Crystal Violet
ICONIX
DSDM XP
OPEN
FDD
RUP
SCRUM
EUP dX
lightweight
heavyweight
middleweight

35. Conclusions Different life-cycle models Each with own strengths
Each with own weaknesses
Criteria for deciding on a model include
The organization
Its management
Skills of the employees
The nature of the product
Best suggestion
“Mix-and-match” life-cycle model

36. Model Driven Architecture

37. What is MDA in essence?
Automated approach to translate high level design to low level implementation by means of separation of concerns
From high-level model to running application
Risk proportional to expectations!

38. Finding the “right” language
Developer
Model Driven Architecture
Automation
Abstraction
IDEs & 4GL
3GL
Assembler
Moving up the abstraction tree
What are we building rather then how
Separation of concerns
What-from-how
Computer Hardware

39. “You should use iterative development only on projects you want to succeed”
Martin Fowler

40. Model Driven Architecture
Can you actually have incremental MDA?
Or is it automated waterfall?
Need rigorous models
Need high quality requirements
Capture requirements
Understand requirements

41. MDA or Offshore? Automation versus reduce cost of labor Objectives
Reduce required intelligence
Increase repetition
Goal
Reduce costs of development