程序代写代做代考 17spm_L08

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.