Software Engineering
Plans, Documents and Process: 1
Bringing engineering discipline to software
How to fix the problem?
We saw, the early approach was to apply the methods that were used in other fields of engineering.
The favoured approach: plan projects in detail before starting development, and produce extensive documentation for every planned activity.
Projects were then required to follow that plan and progress was measured against it.
COMP3297: Software Engineering 2
Software Process
During a project, the process answers questions such as:
These can be intermediate or final products – artefacts
There are many different Process Models that provide general frameworks for creating this organization.
Q: What hangs in the framework? A: Software development activities.
What do we do next?
For how long do we do it? What do we produce as a result?
COMP3297: Software Engineering 3
Reminder: the process has two aspects:
It defines the activities
It specifies how they are organized into a project.
The “obvious” model:
linear, sequential, fully planned upfront
Plan
Project Management
Software Quality Assurance Software Configuration Management
Specification
Development
This is the Waterfall Model
Testing
Evolution
Deliver
COMP3297: Software Engineering
Better than nothing
Easy to understand
High level of control Allows specialized teams Easy to verify at stages
4
Typical Deliverable Artefacts (also milestones)
Waterfall Model
Requirements
Design
In its rigid form:
A phase cannot begin until
the previous phase is complete.
A previous phase cannot be reentered once it has been declared complete.
Each phase terminates in a major milestone and deliverable. A review follows each phase.
Traditional software engineering
Requirements Spec. Design Spec.
Implementation
Code
Test Reports
Installed System
Operation & Maintenance
Testing
Deployment
COMP3297: Software Engineering
5
Heavyweight planning Heavyweight documentation
Idea is that we can improve predictability via extensive documentation and planning of all phases of development.
Big up-front plans – hence the big project Gantt charts
COMP3297: Software Engineering 6
Waterfall Model with Feedback
Requirements
Design
Implementation
In practice, need feedback since problems are discovered in later phases.
This involves so much expensive rework of documents that they are
typically frozen after limited feedback.
Requirements Spec. Design Spec.
Testing
Code
Test Reports
Installed System
Operation & Maintenance
Deployment
COMP3297: Software Engineering 7
Regulatory standards reflect this thinking Example: DO-178C required data (Airborne Software)
How much would you think this certification effort costs?
Say HKD for 100 LOC?
COMP3297: Software Engineering 8
A major problem with Waterfall
(also see more when we revisit process later in the course)
Easy to manage, but:
Inflexible. Discourages change – volume of new documents and repeated steps makes change expensive. Commitments are made early and project can’t respond to changing requirements or new information.
Can only work when requirements are well understood and unlikely to change during development, and risks are low.
So, what sort of project could this be?
Brought discipline, but a big problem is late validation: the customer doesn’t see a working program until late in the project. A mistake in requirements analysis can easily stay undetected for a long period –
expensive to fix when it is finally detected.
COMP3297: Software Engineering 9
Relative cost of fixing a requirements defect at various stages of development
160 140 120 100
80 60 40 20
0
Reqs Design
Code Unit Test
System Test UAT
Post-release
Waterfall was an attempt to avoid defects reaching the late
stages of a project, but it often had the opposite effect.
COMP3297: Software Engineering
10
Summary
Older predictive process models like Waterfall assume we can: First
o develop a perfect knowledge of requirements at the start of a project, Then
o design a solution that will satisfy those requirements Then
o implement that design, without change, to create a successful solution While
o following a detailed project plan created at the very beginning.
Not possible:
o for complex problems where the solution is not known in advance, o for projects where needs and requirements are changing.
COMP3297: Software Engineering 11
That is Defined Process Control
Models like Waterfall specify in detail the steps/tasks/activities, and their ordering, needed to develop the software product.
They are manufacturing models, like those used in industrial mass- production. Treat software development like manufacturing and assume that:
q all knowledge is available up-front, and
q all steps can be fixed and are repeatable with little variation, leading to
predictable outcomes.
COMP3297: Software Engineering 12
Defined Process Control for Software?
Defined process control is open loop
Input Process Output
It does not work for innovative, complex software development. Example:
We do not have perfect knowledge up-front, just assumptions.
Yet the process model forces us to make decisions based on those assumptions without the benefit of feedback based on delivered, working software.
COMP3297: Software Engineering 13
What is needed?
Real-world teams that succeed with different approaches:
q self-organize developers into motivated, cooperative teams and collaborate closely rather than working in isolation as individuals or specialized groups
q produce working increments frequently rather than trying to integrate large increments at longer timescales
q continuously revise their understanding of requirements
q quickly respond to change when necessary
These are characteristics of a lighter and adaptable approach to development compared with the heavyweight, rigidly planned and tightly managed predictive approaches of Traditional Development.
We saw, this is the Agile approach to software development.
COMP3297: Software Engineering 14
That is Empirical Process Control
This form of control is best for complex problems where there is more that we don’t know than we do know.
Closing the loop
Input
Process
Output
Knowledge comes from experience. Make decisions based on what is known.
Empirical control is built on three principles which form the basis for Agile frameworks like Scrum:
COMP3297: Software Engineering
15
Transparency Inspection Adaptation
Principles
Transparency
Inspection
Adaptation
All information that is important for developing the product must be available to everyone connected to development.
Nothing is hidden and there must be common understanding. This enables inspection and, hence, adaptation.
Periodically review the current state of the work, of progress, and of the use of the framework itself.
On the basis of inspection, make changes where necessary to adapt the product and/or process and bring aspects that have deviated back under control.
Frequency of inspection and adaptation depends on the amount of risk we want to take.
We’ll revisit these when we cover Scrum in detail.
COMP3297: Software Engineering 16
So, how to organize technical activities?
Can’t escape the Waterfall-like dependencies among the software development activities, but we do know that Waterfall can work on small projects with well-defined, stable requirements.
Simple idea: Develop in a sequence of very small, self-contained “mini- projects” – these are iterations of development.
Roughly, each “mini-project” passes through the same set of development activities and builds the piece of the product that currently is of highest risk and/or most value. The overall project iterates through that cycle repeatedly.
Each iteration builds on the product of the previous iteration. So the system grows incrementally.
Iterative and Incremental Process
COMP3297: Software Engineering 17
Generic iterative cycle
Integrate
System Testing
Project vision Rough initial planning
Each iteration results in a potentially releasable executable: Incremental delivery of increasingly large subset of product features.
Design, implement and test
Configuration and Change Management
Review
Refine feature descriptions
Choose features to be developed in this increment
COMP3297: Software Engineering
18
Deploy increment
Project as a series of iterations
Short timeboxed iterations of the same length. In Scrum, usually 1-2 weeks
Project vision Rough initial planning
Sprint 1
Sprint 2
Deploy
Potentially releasable product increment
Sprint 3
Deploy
Product Backlog
Deploy
COMP3297: Software Engineering
19
Features of Iterative and Incremental Process
Each iteration has well-defined goals. But these are not set until planning at the start of the iteration. Helps us handle change.
No massive, heavyweight up-front Waterfall-like planning.
Every iteration delivers a working release – a stable, integrated, tested, partially complete but releasable system. This is our proof that we achieved the goals of the iteration.
As the system grows, increment by increment, it is a working product at every stage.
Additional advantage: In a competitive market, users often can’t wait for a fully-featured system to be developed. Here we can have high- value partial functionality available early. Also have a partial system even if money runs out.
COMP3297: Software Engineering 20