1. Software Engineering Process
Software Engineering Process

2. 4 SWEBOK KAs covered so far
Software Requirements
Software Design
Software Construction
Software Testing
Software Maintenance
Software Configuration Management
Software Engineering Management
Software Engineering Process
Software Engineering Models and Methods
Software Quality
Software Engineering Professional Practice
Software Engineering Economics
Computing Foundations
Mathematical Foundations
Engineering Foundations
Today’s topic

3. Engineering software is a big job
Variety of tasks:
Requirements
Verification (testing)
Design
Maintenance
Implementation

4. Practical issue: What order should tasks be done in?
That is, what process to use?

5. The old way: Waterfall (sequential) model
Requirements
Design
Implementation
Verification
Maintenance
60s and 70s-era advice

6. Imagine this scenario What could go wrong? Requirements Design
Implementation
Verification
6 months
6 months
3 months
What could go wrong?
60s and 70s-era advice
6 months
Release!

7. Imagine this scenario Requirements Design Implementation Verification
6 months
6 months
I don’t like it…
3 months
60s and 70s-era advice
6 months
Release!

8. Using Waterfall turns out to be a poor practice
High failure rates
Low productivity
High defect rates
45% of features in requirements never used
Early schedule and estimates off by up to 400%

9. Why Waterfall doesn’t work
False assumption: Specifications …
… are predictable and stable
… can be correctly defined at the start
… have low change rates
Actual stats:
25% of requirements changed
35% to 50% changed in large projects

10. Waterfall is a “defined” process control model
(think mass manufacturing)
Software devel. needs an “empirical” model
(think new product development)

11. Basis of empirical process model…
Feedback
Adaptation

12. Iterative Development Process
Planning
Requirements
Analysis
Design
Implementation
Deployment
Testing
Evaluation
Initial Planning

13. Iterative Development Process
Planning
Requirements
Analysis
Design
Implementation
Deployment
Testing
Evaluation
Initial Planning
Where are
feedback
&
adaptation?

14. Iterative Development Process
Planning
Requirements
Analysis
Design
Implementation
Deployment
Testing
Evaluation
Initial Planning
Feedback
Adaptation

15. Iterative and incremental development
also called iterative and evolutionary
Larman Figure 2.1

16. How long should iterations be?
Short is good
2 to 6 weeks
1 is too short to get meaningful feedback
Long iterations subvert the core motivation

17. Iterative and incremental development addresses the “yes…but” problem
Yes, that’s what I asked for, but now that I try it, what I really need is something slightly different.

18. System converges over time
Unstable requirements
Requirements more stable
Larman Figure 2.2

19. More benefits of iterative development
Fewer defects
Greater productivity
Early mitigation of risk
Early visible progress
Meet real needs of stakeholders
No “analysis paralysis”
Iterative process improvement

20. Iterative and incremental development is a broad approach
But how to operationalize?
To help with that, there are more specific methods and practices
In particular, there are agile methods

21. What is an agile method? Where does it come from? values, principles,
more specific
more general
values
principles
practices
Where does it come from?
Agile values,
principles
Agile method
values, principles,
practices
beget

22. Individuals and interactions over processes and tools
Agile Values
From the Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

23. Individuals and interactions over processes and tools
Can you think of a principle or practice that might be based on the agile values?
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

24. Examples of agile methods and their practices
Scrum
Common project workroom
Self-organizing teams
Daily scrum …
Extreme programming (XP)
Pair programming
Test-driven development
Planning game

25. A word about agile modeling (quoting Larman)
Experienced analysts and modelers know the secret of modeling:
Thus, we favor hand-drawn diagrams over typeset ones
The purpose of modeling (sketching UML, …) is primarily to understand, not to document.

26. You know you’re doing agile wrong when you…
You know you’re doing agile wrong when you…
Define most requirements before starting design or implementation
Spend days/weeks modeling before programming
Believe that iterations should be 3 months
Think you need to create many formal documents
Try to plan project in detail from start to finish