17spm_L08
Managing the Software Process
SPM 2017 © Ron Poet Lecture 08 1
Introduction
All Projects Need: Requirements
� A description of the requirements.
� The current best approach (for the last 20 years) is user driven
requirements.
o Work out what the user needs.
SPM 2017 © Ron Poet Lecture 08 2
o Not necessarily what they want, depends on how important the
users are.
� The rest are non-functional requirements.
All Projects Need: Cost Estimation
� The effort is the total amount of work needed.
� The elapsed time is how long it will take.
o An effort of 20 man-months with 5 workers will take 4 months.
� The total cost also includes:
o Non-productive workers, not directly involved in software
production.
o Cost of buildings and equipment.
SPM 2017 © Ron Poet Lecture 08 3
All Projects Need: Team Structure
� There are many different jobs involved in creating software.
� People have different skill levels.
� Teams of up to about 10 people are relatively easy to manage.
� Larger projects need a middle-management layer.
� This can cause problems.
o It is easy for the top level management to become remote from the
actual work.
o Middle management can hide problems.
SPM 2017 © Ron Poet Lecture 08 4
All Projects Need: Scheduling and Tracking
� Scheduling the work that has to be done.
� Keeping track of progress.
� Current best practice is test-driven development.
� Test cases are written first.
� Chunks of code are only accepted when they pass all their tests.
SPM 2017 © Ron Poet Lecture 08 5
Differences Between Approaches
� When to gather requirements.
� How much documentation is needed.
� How change is managed.
� Different ways of organising people.
SPM 2017 © Ron Poet Lecture 08 6
Process is not a Panacea
� Methodologies only work as well as the people using them.
� Any methodology can be distorted to give the answer that management
is looking for, rather than reality.
� Understand the strengths and weaknesses of a process before using it.
o Do one or two pilot projects
o Do a non-critical realistic project.
o Make sure that a critical mass of team members have used the
process in a real project.
SPM 2017 © Ron Poet Lecture 08 7
Software Process Models
� Opportunistic
� Waterfall
� Phased-release
� Spiral
SPM 2017 © Ron Poet Lecture 08 8
� Evolutionary
� Concurrent engineering
� Rational unified process
� Agile
� Open source
Opportunistic
� This is what happens if we don’t follow a specific model.
1. Produce an initial version
2. If good enough or we run out of money, then finish
3. Think of ways to improve it
SPM 2017 © Ron Poet Lecture 08 9
4. Modify the code, goto step 2.
Problems with the Opportunistic Model
� No requirements capture “If you don’t know where you are going you
might not get there”.
� No cost control or scheduling.
� No overall software design, so the code quickly becomes
unmanageable.
SPM 2017 © Ron Poet Lecture 08 10
unmanageable.
� Difficult to do functional testing if don’t know what the functionality
should be.
� Never ending changes.
� Will work for a small project.
Waterfall Model
� Each step completed before the next step is started.
o Can’t swim upstream because of the waterfalls.
1. Requirements gathering
2. Specification
SPM 2017 © Ron Poet Lecture 08 11
3. Design
4. Implementation
5. Deployment
6. Maintenance.
Advantages
� Easy set of milestones – the end of each stage.
� Make sure all activities take place.
� Easy to write contracts.
� The disadvantages (next slide) outweigh the advantages.
SPM 2017 © Ron Poet Lecture 08 12
� It is an old fashioned approach favoured by governments and large
organisations.
Disadvantages
� Does not account for changing requirements.
o Many requirements are revealed by a prototype.
o Many requirements show up during the implementation.
� There is no customer involvement until delivery, which may be after
SPM 2017 © Ron Poet Lecture 08 13
several years.
� It assumes that maintenance is just bug fixing.
o It often involves adding new features.
� There is no concept of retiring the product, which is important for
security.
Phased Release
� This is similar to the waterfall model, but the software is produced in
phases, rather than all at once.
� Initial stage
o Requirements capture
SPM 2017 © Ron Poet Lecture 08 14
o Specification
o Planning
� Several phases, each containing.
o Design
o Implementation
o Deployment.
Disadvantages
� This is very similar to the waterfall model, and has many of the same
disadvantages
� There is no learning from earlier phases.
o It is assumed that all the initial requirements are still correct.
SPM 2017 © Ron Poet Lecture 08 15
� Maintenance is covered by additional phases.
� If the software is unsuccessful then this will be discovered at the end of
phase 1.
o Less money is wasted before cancellation.
Spiral Method
� This approach repeats the entire waterfall cycle over and over again.
� Each cycle has a review stage and risk analysis stage before beginning
again.
� The first loop is a prototype, the others are releases.
SPM 2017 © Ron Poet Lecture 08 16
� “The question is not whether to build a pilot system and throw it away.
You will do that anyway. The question is whether to plan in advance
to build a throwaway.” – Fred Brooks.
� Maintenance is just ongoing development.
Minor Approaches
� Evolutionary model.
o This is like the spiral model, but the cycles overlap.
o As one release is prepared for deployment, planning for the next
release is already underway.
SPM 2017 © Ron Poet Lecture 08 17
� Concurrent model.
o Work is done on several components simultaneously
o Periodic integration stages
� Rational Unified Process (RUP).
o Introduced at the same time as UML
o Too focussed on code.
Agile Approaches
� A less formal approach rather than a more rigid model.
� An iterative approach with many small iterations (typically 2 weeks
long).
� The direction of the project is regularly reassessed.
SPM 2017 © Ron Poet Lecture 08 18
� Do not generate lots of paper.
� Have fairly close delivery dates for each small iteration.
� Good for small projects with high requirement risk.
o If a wrong direction is taken, not much works needs to be thrown
away.
o Designed to save money
Agile: XP (eXtreme Programming)
� The development team includes all of the stakeholders.
o Including customers and users, on site if possible.
� Requirements capture consists of writing user stories
o Similar to use cases
SPM 2017 © Ron Poet Lecture 08 19
o
o Each must take no more than 2 weeks to develop and test.
� Planning consists of deciding which user stories will be developed in
each iteration.
� Programmers pick tasks and provide their own estimate (1 to 3 days)
of the time required.
XP (2)
� There are 3 project variable that can be changed: scope, resources and
time
� They are interdependent and only two are independent.
o The third one can be derived from the other two.
SPM 2017 © Ron Poet Lecture 08 20
� Quality is not a project variable and can’t be changed
� Automated test cases are written before the code to be tested.
� Acceptance testing is based on the user stories.
o The user stories must work as expected.
XP (3)
� Regular refactoring is encouraged
� Refactoring means that the code is reorganised.
o The small scale pieces of code remain the same.
o Methods may be moved between classes
SPM 2017 © Ron Poet Lecture 08 21
o
o New classes may be created.
� Typical refactoring activities include:
o Adding inheritance (see Advanced Programming).
o Adding new patterns (see Software Engineering)
XP (4)
� Pair programming is encouraged.
o Both people needs to work closely together.
o Ego-less programming.
o Very hard to make work well
SPM 2017 © Ron Poet Lecture 08 22
o
o There is no ‘owner’ of any piece of code
� Disadvantages of XP.
o Harder to write contracts.
o Does not scale up well.
� Widely adopted for small projects.
Choosing a Process Model
� Software is usually developed using a combination of the approaches.
� The model to use depends on the relationship with the organisation
paying the money.
� Will the customer share in development?
SPM 2017 © Ron Poet Lecture 08 23
o Yes, then an agile method might be appropriate.
o No, then use an approach where the requirements can be gathered
initially and then signed off by the customer.
o If the customer wants to change the requirements, they will have to
pay some more money.
Re-engineering
� No matter what we do, the design will deteriorate over time.
� Periodically it should be re-engineered, which is similar to refactoring,
but with the design documents as well as the code.
� You know it is time to re-engineer when adding new features becomes
harder and harder.
SPM 2017 © Ron Poet Lecture 08 24
harder and harder.
� It is often difficult to persuade management of the need for this.
� They will have to spend money to change the internal structure of the
software and design.
o But there are no external changes.