17spm_L02
The Software Development
Process
SPM 2017 © Ron Poet Lecture 2 1
Process
The Software Development Process
� There are many different ways of managing a software
project
� Most of them have the following steps
o Inception
o Elaboration
o Construction
o Continued Support
o Product Retirement
SPM 2017 © Ron Poet Lecture 2 2
Inception
� All projects have a starting point
o A brief description of the reason why the system is
needed
o What its scope will beo What its scope will be
o Roughly how much it will cost
� The inception phase will generate the business case for
undertaking the projected work.
o How much it will cost, in more detail.
o How much it will bring in.
o How long it will take.
SPM 2017 © Ron Poet Lecture 2 3
Elaboration Steps
� Finding Requirements
� Evaluating Risks
� Producing a Baseline Architecture
� Planning and Setting Priorities� Planning and Setting Priorities
SPM 2017 © Ron Poet Lecture 2 4
Elaboration: Requirements Gathering
� This involves finding out what the customer wants.
� This will initially involve a brief project description.
Our customers may have several sites, and we provide
several services to these sites. At the moment, the several services to these sites. At the moment, the
customer gets a bill for all services at a given site. We
want the customer to be billed for all services at all sites.
We call this consolidated billing.
� The final result will be
o A fairly comprehensive list of use cases,
o Non functional requirements.
� The project description will also be expanded
SPM 2017 © Ron Poet Lecture 2 5
Use Cases
� A use case is a typical interaction between a user and the
system to achieve a simple goal.
� Some typical examples for a word processor might be:
o Make selected text bold.o Make selected text bold.
o Create an index for this document.
� As you can see, these use cases are focused on one simple
task (from the user’s point of view).
o The actual engineering effort can vary greatly.
� An important part of designing a system is to discover all
of the potential use cases.
o It will not be possible to find all of them immediately
SPM 2017 © Ron Poet Lecture 2 6
Use Cases (2)
� Systems will normally have a large number of small use
cases.
o Each one should be as simple as possible, but no
simpler.simpler.
o The more complex the use case, the more scope there is
for ambiguity.
� Many of the use cases will interact with each other, and
these relationships will be described in a use case diagram.
o There will typically be many different user roles
associated with the use cases.
SPM 2017 © Ron Poet Lecture 2 7
Use Cases (3)
� Some of the use cases will be clear and unambiguous,
whereas other will be difficult to describe accurately.
o These use cases are examples of requirements risk (see
later).later).
SPM 2017 © Ron Poet Lecture 2 8
Domain Model
� A domain model is a description of all the different parts
of the system.
� This is the big picture of how the system will operate and
describes the world that the computer system will support.describes the world that the computer system will support.
� It differs from the use cases in that it tries to describe the
complete domain in which the system will operate.
� In object oriented analysis, we look for things that make
up the domain of interest.
o In the earlier example we notice the words customer,
site, service and bill, which will form the basis of our
object oriented domain model.
SPM 2017 © Ron Poet Lecture 2 9
Elaboration: Risk Analysis
� We obviously want our systems to work, but there is a risk
that they will not.
� The following 4 types of risk are present in most projects.
1 Requirements Risk1 Requirements Risk
2 Technology Risk
3 Skills Risk
4 Political Risk
� We will look at requirements risk in detail, and so the other
topics can be dealt with quickly.
� There will be other areas of risk associated with the
software construction process itself, covered later.
SPM 2017 © Ron Poet Lecture 2 10
Political Risk
� All projects need funding before they get off the ground
o Write the project proposal
o Sell it to the people controlling the money
o Protect it from threats.o Protect it from threats.
� The amount of politics involved varies depending on
whether you work in a small company, large company or
government agency
o Each project needs someone with political skill.
� We will not try and teach you how to become an office
politician on this course!
SPM 2017 © Ron Poet Lecture 2 11
Skills Risk
� It is common to hear the attitude the once someone learns
to program then they can undertake any programming task
almost immediately.
� This can lead to the situation where programmers who
have trained in Java must work on a project in C++ using have trained in Java must work on a project in C++ using
object oriented design, with no additional training.
� Or a student who has learned to program in C++ is given a
test in Java!
SPM 2017 © Ron Poet Lecture 2 12
Skills Risk (2)
� The reality is that every programming language has it’s
own techniques which must be mastered before a person
can use it well.
o A project written in C++ in the Java style will take a lot
longer to complete than one written using C++ as it was longer to complete than one written using C++ as it was
intended to be used
o C++ does not check for common run time errors, while
Java does.
o C++ written in the Java style will have more bugs.
SPM 2017 © Ron Poet Lecture 2 13
Learning by Mistakes
� It is true that we learn by making mistakes
o life is too short to make all of them personally.
o It is better to learn by the mistakes of others.
� Of course, it is necessary to make a certain number of
mistakes personally to learn well.mistakes personally to learn well.
� You will have plenty of opportunities to learn by mistakes
on the Programming course (if you are learning
programming for the first time).
SPM 2017 © Ron Poet Lecture 2 14
Technical Risk
� Technology moves fast, and many projects involve new
technology.
� The most important technique for dealing with new
technology is to design an experiment that uses the new technology is to design an experiment that uses the new
ideas in a simplified way
o This code will not be used in the project.
o It will make the project related code easier to write.
SPM 2017 © Ron Poet Lecture 2 15
Technical Risk (2)
� There will usually be a choice between several similar
technologies
o It is not immediately apparent which technology will be
best.best.
o In this case we should design experiments to compare
the technologies.
� Connecting various components of the finished system can
also be difficult.
SPM 2017 © Ron Poet Lecture 2 16
Requirements Risk
� The most common form of failure is to build the wrong
system.
o It may work perfectly, with lots of elegant algorithms,
but does not do what is required.but does not do what is required.
� There are two main causes for this failure.
o A cultural problem between the way the engineers think
and the way the customers think about systems.
o The fact that natural language is ambiguous, and the
same words can mean different things to different
people, making accurate communications difficult.
SPM 2017 © Ron Poet Lecture 2 17
Requirements Risk (2)
� From the engineer’s perspective, the risk is that we do not
know what the customer really wants.
� The solution that we will use on this course involves
o A more precise technique for describing what the o A more precise technique for describing what the
system should do, what the requirements are. These are
Use Cases or User Stories.
o A way of producing parts of the system quickly, so that
the customer can see how the requirements look in
practice. This is achieved through Prototyping.
SPM 2017 © Ron Poet Lecture 2 18
Elaboration: Baseline Architecture
� This is a simple description of how the complete system
may be structured.
o For example, we may decide to use a three tier
architecture, with client, server and database architecture, with client, server and database
components.
� This can be described in a simple way using a component
diagram.
� We can also partition the code into manageable chunks at
this stage, using a package (module) diagram to represent
this.
SPM 2017 © Ron Poet Lecture 2 19
Elaboration: Planning
� The use cases are built in batches through several
iterations.
o The planning stage assigns use cases to the successive
iterations.iterations.
o The time to complete each use case needs to be
estimated at this stage.
SPM 2017 © Ron Poet Lecture 2 20
Elaboration: Planning (2)
� Three numbers can be associated with each use case:
o The priority, ranging from cannot do without, down to
can survive without it for a while.
o How well do I understand what is required? A low o How well do I understand what is required? A low
value indicates high requirements risk.
o How confident am I in the time estimate, ranging from
pretty sure to no idea. A low value indicates high
scheduling risk.
� Planning should assign high risk items to early iterations if
possible.
SPM 2017 © Ron Poet Lecture 2 21
Elaboration: Planning (3)
� The common practice of putting off risky items to the end
leads to the well known experience that a project is on time
and on budget for 90% of the time, but then there are major
problems that lead to long delays.problems that lead to long delays.
� The presence of a large number of high risk items might
indicate that the requirements stage has not been
completed.
� It could also mean that the customer does not really know
what he wants, and cannot finalise the requirements until
he sees some of the use cases in action.
o The iteration approach to construction helps here.
SPM 2017 © Ron Poet Lecture 2 22
Construction
� The iteration approach to construction builds the use cases
in batches.
o Each batch involves analysis, design, coding, testing
and integration.and integration.
� An iteration finishes with a demonstration to the customer
and users, together with system tests.
SPM 2017 © Ron Poet Lecture 2 23
Construction (2)
� Building the high risk use cases first means that the
customer and users get a quick look at the items that are
likely to be wrong, so that errors get correctly at an early
stage.stage.
� However, there can be a need to reassure the customer that
everything is going fine by also building and
demonstrating some low risk features at an early stage.
SPM 2017 © Ron Poet Lecture 2 24