Transcript CIS224 Software Projects: Software Engineering and

Lecture 2a
Development Process
(Based on Stevens and Pooley (2006,
Chapter 4) and Fowler (2004, Chapter 2))
David Meredith
[email protected]
www.titanmusic.com/teaching/cis224-2007-8.html
CIS224
Software Projects: Software Engineering
and Research Methods
1
How do we build good, large
systems?
• Large project may take several people several
months or years to complete
– Don’t just tell them to deliver product when it’s
finished
– Might tell them we want part A finished in 1 month,
part B finished after 2 months etc.
• Large projects should be broken down into short
phases with unambiguous milestones
• How do you eat an elephant?
– One spoonful at a time!
2
The need for a plan
• Large project has to follow a plan
– So can evaluate what has been achieved
– Determine whether project is on schedule and within
budget
• Need to systematically document project
– So that people can join and leave mid-way through
– So that system can be maintained when it is delivered
• Usually use a development process or
methodology to manage a large software
project
3
Development process and
methodology or method
• Development process
– The type of plan and way of working adopted within a
particular software project
– The rules that define how project carried out
– Describes documents, design models and artifacts
that should be delivered and in what order
• Methodology, method
– techniques for developing design models
– usually specifies modelling language to be used (e.g.,
UML)
– specifies method for capturing user requirements
4
Model
• an abstract representation of a specification, a
design or a system, from a particular point of
view
• usually expressed using diagrams
• represents essentials of a particular aspect of a
system or project without irrelevant details
• allows team members to focus on a particular
aspect of project without getting side-tracked
• purpose of model is to communicate
– a model must have a precise and well-understood
meaning
5
Modelling language
• Way of expressing the different models used in a project
• Defines collection of model elements which are the
building blocks of the models we construct
• Modelling language is usually diagrammatic
– in which case, model elements will be graphical elements of
diagrams (e.g., types of arrow, types of box, etc.)
• Modelling language has syntax and semantics
– Syntax
• rules governing how the model elements can be put together to
make legal models
– Semantics
• rules governing how a legal diagram should be interpreted
6
What makes a good modelling
language?
• Sufficiently expressive
– need to be able to use the language to express those
aspects of the project and system that we need to
discuss and describe
• Easy to use
– needs to aid development, not hinder it
• Unambiguous
– model must have a precise meaning so everyone
interprets it in the same way
• Widely used
– so that people in the industry can understand a model
even if they are new to a project
7
Waterfall process
Analysis
Design
Implementation
Testing
Maintenance
• Software life-cycle broken down into 5 large
phases
• Assumes that once a phase has ended, we
never return to it
– This is nearly always impossible because we don’t
always make the right decisions
– e.g., if requirements change during testing, we have to
revisit the analysis and design phases
• Waterfall process doesn’t work because we
always need to be able to revise earlier decisions
8
Iterative process
• Every decision involves taking a risk - the risk that the
decision is the wrong one!
• Need to manage such risks in a software project
• The more you build on a decision, the harder it is to go
back and change it, if it turns out to be wrong
• Need to find out as soon as possible whether or not a
decision is right
– do this by having frequent evaluation steps during the
development process
• One of the biggest causes of failure in software projects
is requirements change or misunderstanding
• Users find it easier to criticise a working system than to
imagine a perfect one
– better to present users with prototypes for evaluation during the
development process
9
A simple spiral process
See Boehm, B. (1988). A spiral model of software development and enhancement. IEEE Computer, 21(5): 61—72.
Engineer:
design, implement, test
Analyse requirements
for this iteration
Evaluate
Analyse risks and plan
10
Iterative process
• Decomposes software into subsets of
functionality
• Does complete software life-cycle for each
subset of functionality before going on to the
next
• Production quality software produced on each
iteration
• Beware of “pseudo-iterative” development
process:
– "We are doing one analysis iteration followed by two
design iterations..."
– "This iteration's code is very buggy but we'll clean it
up at the end."
11
Time-boxing
• An iteration is forced to be of a fixed duration
• If necessary, must sacrifice functionality, not
quality or delivery
• Learning to sacrifice functionality is good
practice for when have to decide at big release
between sacrificing functionality or delaying
release
• Helps developers to prioritise requirements and
identify what is really necessary
12
Rework
• Iterative development implies reworking
and deleting existing code
• Seen as bad in manufacturing
• But in software engineering, rework is not
necessarily bad
• Often easier and less error-prone to
rework code than patch badly-made
existing code
• “Be prepared to throw one away” (Brooks,
1975)
13
Making rework more efficient
• Automated regression
– Detecting defects introduced by changes
– See www.junit.org
• Refactoring (Fowler, 1999)
– Change existing software by making a series of small behaviourpreserving transformations
– Transformations can be automated
– See www.refactoring.com
• Continuous integration
– www.martinfowler.com/articles/continuousIntegration.html
– automatic build (including test) each time a team member
checks code into the code base
14
Hybrid development processes
• Neither waterfall nor iterative processes are ever
“pure”
– Always some “back-flow” in the waterfall process
• e.g., need to revisit design half way through implementation
– Exploratory phase before first iteration in an iterative
process
• To get high-level view of requirements
– Usually non-iterative phase at end of iterative
development for user training, ironing out final bugs,
etc.
• Hybrid development processes
– e.g., Rational Unified Process
15
What is a good development
process?
• Uses iteration to manage risk
• Supports architecture-centric, componentbased design
• Has high level of user involvement
• Should be use-case driven
• Should allow users to evaluate prototypes
and partial solutions frequently
16
(Rational) Unified Process (RUP)
• Proposed by
• Jacobson, I., Booch, G. and Rumbaugh, J. (1999). The Unified
Software Development Process. Addison-Wesley.
• Accepts the need for non-iterative preliminary phase for
planning, risk-assessment and high-level requirements
capture
• Accepts the need for non-iterative phase at the end of a
project for deploying software, training users and ironing
out final bugs
• RUP is not a process – it is a process framework
• Provides vocabulary and loose structure for discussing
processes
• First step in using RUP is to choose a development case
which is a process to use
– This process may not be one of the traditional processes
• RUP is essentially iterative
17
(Rational) Unified Process (RUP)
• Phase 1: Inception
– Business case completed
– Feasibility studies completed
– Decision taken to go ahead with project
• Phase 2: Elaboration
–
–
–
–
Basic architectural decisions made
Outline plan for construction finalised
Major risks identified and understood
High-level user requirements captured
• Phase 3: Construction
– Consists of a sequence of iterations, each one probably
consisting of
• Analysis → Design →Implementation → Test → Evaluation
• Phase 4: Transition
– System introduced to users
– Late-stage, non-iterative activities such as deployment, user
training
18
Other processes
• Object-oriented design (OOD)
– Booch, G. (1991). Object-Oriented Design with Applications.
Benjamin/Cummings
• Object modeling technique (OMT)
– Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and
Lorensen, W. (1991). Object-Oriented Modeling and Design.
Prentice-Hall.
• Object-oriented software engineering (OOSE) and
Objectory
– Jacobson, I., Christenson, M., Jonsson, P. and Oevergaard, G.
(1992). Object-Oriented Software Engineering: A Use Case
Driven Approach. Addison-Wesley.
• Catalysis
– D'Souza, D. and Wills, A. C. (1998). Catalysis: Objects,
Frameworks and Components in UML. Addison-Wesley.
19
Predictive planning
• Assumes project is in two stages:
1. make plans - difficult to predict cost and time of this
2. execute plans - much more predictable
• Generally, project becomes more predictable as it
progresses
• Requirements analysis is inherently unpredictable
– Requirements churn:
• changes in requirements at a late stage in a project
– Two solutions:
• Can freeze requirements early on, but could result in system that
doesn't meet users' needs
• Can put more effort into requirements analysis early on...but will
this help?
• Can give a fixed-price/fixed-scope contract
– But will probably fail or overrun
20
Adaptive planning
• Sees requirements churn as inevitable
• Accepts that it is impossible to predict how
requirements will change as software is
developed
• Developing the software changes the
requirements as users become more aware of
what is possible
• Cannot fix scope until confident that
requirements won't change
• Can have fixed-price/variable-scope contract
– Requires users to regularly assess functionality of
product so far
– Customer may cancel project if too slow
• Uses iterative process
21
Agile programming
• Defined by the “Agile Programming Manifesto”
– www.agilemanifesto.org
• Claims that we should value
– individuals and interactions over processes and
tools
– working software over comprehensive
documentation
– customer collaboration over contract negotiation
– responding to change over following a plan
• Examples: Extreme programming (XP), Scrum,
Feature-driven development (FDD), Crystal,
Dynamic systems development method (DSDM)
22
Agile processes
• Use adaptive planning, not predictive planning
• Are people-oriented
– Most important factor is quality of people and working
relationships
• Use short, time-boxed iterations with frequent customer
and user evaluation
• Low ceremony, lightweight
– i.e., few written reports and control points
• Embrace requirements change
• Use automated testing
• Avoid building in features that are not definitely required
23
Choosing the right process
• Depends on
–
–
–
–
–
–
–
Kind of system
Technology being used
Size and distribution of team
Risks
Consequences of failure
Working style of team
Culture of organisation
• Better to start simple and add complexity than
start complex and simplify
• Iterative development supports frequent process
change and evolution
24
Retrospectives
•
•
End each iteration with an iteration
retrospective
Make list with three categories:
1. things to keep
2. problems – things to get rid of
3. things to try
•
•
End project with a project retrospective
(www.retrospectives.com)
Learn from your successes and your mistakes
25
Patterns
• See
• Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995).
Design Patterns: Elements of Reusable Object-Oriented
Software. Addison-Wesley.
• Complete example software designs for solving
commonly encountered problems
• A pattern identifies the common features in a
class of good designs and incorporates them
into a re-usable pattern
• A pattern is a software design on which you may
base a new system
26
Summary
• Waterfall process and software life-cycle
– cannot easily revise decisions
• Iterative ("spiral") process - sequence of mini waterfalls
– allows risk to be managed effectively
– involves frequent user evaluation of working software
– uses time-boxing to prioritise requirements and stay on schedule
• rework not necessarily bad in software development
• Rational Unified Process
Inception →Elaboration → Construction → Transition
•
•
•
•
Predictive and adaptive planning
Agile programming
Retrospectives
Patterns
27