Choosing the Right Software Project Approach

SPM (6e) Selection of project approach© The
McGraw-Hill Companies, 2017
1
Software Project Management
UNIT 2
Chapter Four
Selection of an
appropriate
project approach

Knowing Is Not Enough…..;
We Must Apply…...
Wishing Is Not Enough……;
We Must Do……!!!!
24-07-20
2

3
Outline of lecture
• Building versus buying software
• Taking account of the characteristics of the project
• Process models
• Waterfall
• Prototyping and iterative approaches
• Incremental delivery
• Agile approaches

4
Selection of project approaches
• This lecture concerned with choosing the right
approach to a particular project: variously called
technical planning, project analysis, methods
engineering and methods tailoring
• In-house: often the methods to be used dictated
by organizational standards
• Suppliers: need for tailoring as different customers
have different needs

5
Build or buy?
Outsourc
e?
In-house
developm
ent?
Build Buy
either

6
Some advantages of off-the-shelf (OTS) software
• Cheaper as supplier can spread development costs
over a large number of customers
• Software already exists
• Can be trialled by potential customer
• No delay while software being developed
• Where there have been existing users, bugs are
likely to have been found and eradicated

7
Some possible disadvantages of off-the-shelf
• Customer will have same application as everyone else:
no competitive advantage, but competitive advantage
may come from the way application is used
• Customer may need to change the way they work in
order to fit in with OTS application
• Customer does not own the code and cannot change it
• Danger of over-reliance on a single supplier

8
General approach
• Look at risks and uncertainties e.g.
• are requirement well understood?
• are technologies to be used well understood?
• Look at the type of application being built e.g.
• information system? embedded system?
• criticality? differences between target and
development environments?
• Clients’ own requirements
• need to use a particular method

9
Structure versus speed of delivery
Structured approach
• Also called ‘heavyweight’ approaches
• Step-by-step methods where each step and intermediate
product is carefully defined
• Emphasis on getting quality right first time
• Example: use of UML and USDP
• Future vision: Model-Driven Architecture (MDA). UML
supplemented with Object Constraint Language, press the
button and application code generated from the UML/OCL
model

10
Structure versus speed of delivery
Agile methods
• Emphasis on speed of delivery rather than
documentation
• RAD Rapid application development emphasized use of
quickly developed prototypes
• JAD Joint application development. Requirements are
identified and agreed in intensive workshops with
users

Difference between
motivation and inspiration
Motivation is external and short
lived.
Inspiration is internal and
lifelong
-Sri Sri Ravi Shankar SPM (6e) Selection of project approach© The
11

Processes versus Process Models
• Starting from the inception stage:
• A product undergoes a series of transformations
through a few identifiable stages
• Until it is fully developed and released to the
customer.
• This forms its life cycle or development process.
• Life cycle model (also called a process model):
• A graphical or textual representation of the life cycle.
12

13
Choice of process models
• ‘Waterfall’ also known as ‘one-shot’, ‘once-through’
• incremental delivery
• evolutionary development
Also use of ‘agile methods’ e.g. extreme programming

14
Waterfall

15
Waterfall
• the ‘classical’ model
• imposes structure on the project
• every stage needs to be checked and signed off
• BUT
• limited scope for iteration
• V model approach is an extension of waterfall where
different testing phases are identified which check
the quality of different development phases

16
Evolutionary delivery: prototyping
‘ An iterative process of creating quickly and
inexpensively live and working models to test out
requirements and assumptions’
Sprague and McNurlin
main types
• ‘throw away’ prototypes
• evolutionary prototypes
what is being prototyped?
• human-computer interface
• functionality

17
Reasons for prototyping
• learning by doing
• improved communication
• improved user involvement
• a feedback loop is established
• reduces the need for documentation
• reduces maintenance costs i.e. changes after the
application goes live
• prototype can be used for producing expected
results

18
prototyping: some dangers
• users may misunderstand the role of the
prototype
• lack of project control and standards possible
• additional expense of building prototype
• focus on user-friendly interface could be at
expense of machine efficiency

19
other ways of categorizing prototyping
• what is being learnt?
• organizational prototype
• hardware/software prototype (‘experimental’)
• application prototype (‘exploratory’)
• to what extent
• mock-ups
• simulated interaction
• partial working models: vertical versus horizontal

Don't be pushed
around by the
fears in your
mind……
Be led by the
dreams in your
heart…..

21
Incremental delivery
desig
n
buil
d
instal
l
evaluat
e
desig
n
buil
d
instal
l
evaluat
e
desig
n
buil
d
instal
l
evaluat
e
increment
1
increment
2
increment
3
first incremental delivery
second incremental delivery
third incremental delivery
delivered
system

22
The incremental process

23
Incremental approach: benefits
• feedback from early stages used in developing
latter stages
• shorter development thresholds
• user gets some benefits earlier
• project may be put aside temporarily
• reduces ‘gold-plating’
BUT there are some possible disadvantages
• loss of economy of scale
• ‘software breakage’

24
Overview of incremental plan
• steps ideally 1% to 5% of the total project
• non-computer steps should be included
• ideal if a step takes one month or less:
• not more than three months
• each step should deliver some benefit to the user
• some steps will be physically dependent on others

25
which step first?
• some steps will be pre-requisite because of
physical dependencies
• others may be in any order
• value to cost ratios may be used
• V/C where
• V is a score 1-10 representing value to customer
• C is a score 0-10 representing value to
developers

26
V/C ratios: an example

27
Genesis of ‘Agile’ methods
Structured development methods have several
disadvantages
• produce large amounts of documentation which
can largely remain unread
• documentation has to be kept up to date
• division into specialist groups and need to follow
procedures stifles communication
• users can be excluded from decision process
• long lead times to deliver anything etc. etc
The answer? ‘Agile’ methods?

Agile Methods
• Agile is an umbrella term that refers to a group of
development processes:
• Crystal technologies
• Atern (formerly DSDM)
• Feature-driven development
• Scrum
• Extreme Programming (XP)
• Similar themes:
• Some variations
28

29

Important Themes of Agile Methods
• Base on the incremental approach:
• At a time, only one increment is planned,
developed, and then deployed at the customer
site.
• Agile model emphasizes face-to-face communication
over written documents.
• An agile project usually includes a customer
representative in the team.
• Agile development projects usually deploy pair
programming.
30

31
Atern/Dynamic system development method
(DSDM)
• UK-based consortium
• arguably DSDM can be seen as replacement for
SSADM (Structured System Analysis and Design
Method)
• DSDM is more a project management approach
than a development approach
• Can still use DFDs, LDSs etc!
• An update of DSDM has been badged as ‘Atern’

32
Eight core Atern/DSDM principles
1. Focus on business need
2. Delivery on time – use of time-boxing
3. Collaborate
4. Never compromise quality
5. Deliver iteratively
6. Build incrementally
7. Communicate continuously
8. Demonstrate control

33

102
Atern/DSDM framework

103
Atern DSDM: time-boxing
• time-box fixed deadline by which something has to be
delivered
• typically two to six weeks
• MoSCoW priorities
• Must have - essential
• Should have - very important, but system could
operate without
• Could have
• Want - but probably won’t get!

Extreme Programming Model
• Extreme programming (XP) was proposed by
Kent Beck in 1999.
• The methodology got its name from the fact
that:
• Recommends taking the best practices to
extreme levels.
• If something is good, why not do it all the
time.
104

105
Extreme programming
• increments of one to three weeks
• customer can suggest improvement at any
point
• argued that distinction between design and
building of software are artificial
• code to be developed to meet current needs
only
• frequent re-factoring to keep code structured

Taking Good Practices to Extreme
• If code review is good:
• Always review --- pair programming
• If testing is good:
• Continually write and execute test cases ---
test-driven development
• If incremental development is good:
• Come up with new increments every few days
• If simplicity is good:
• Create the simplest design that will support only
the currently required functionality.
107

Taking Good Practices to Extreme
• If design is good,
• everybody will design daily (refactoring)
• If architecture is important,
• everybody will work at defining and refining
the architecture (metaphor)
• If integration testing is important,
• build and integrate test several times a day
(continuous integration)
108

Extreme programming
Another methodology but why?
•Social Change- Giving up defences
•Based on Excellent programming techniques, clear
communication and teamwork
•Lightweight – only do whatever adds value to the customer
•Addresses constraints in software development
•Can work with teams of any size
•Adapts to rapidly changing requirements

110
Extreme programming
• developers work in pairs
• test cases and expected results devised
before software design
• after testing of increment, test cases added to
a consolidated set of test cases

Extreme programming
XP addresses risks at all levels of development process
•Schedule Slips
•Defect Rate
•Business misunderstood
•Business changes
•False feature list
•Staff turnover

112
Limitations of extreme programming
• Reliance on availability of high quality developers
• Dependence on personal knowledge – after
development knowledge of software may decay
making future development less easy
• Rationale for decisions may be lost e.g. which test
case checks a particular requirement
• Reuse of existing code less likely

113
Grady Booch’s concern
Booch, an OO authority, is concerned that with
requirements driven projects:
‘Conceptual integrity sometimes suffers because this
is little motivation to deal with scalability,
extensibility, portability, or reusability beyond what
any vague requirement might imply’
Tendency towards a large number of discrete
functions with little common infrastructure?

Follow your passion…..
It will lead you to your
purpose
114

Project Characteristics that Suggest
Suitability of Extreme Programming
• Projects involving new technology or research
projects.
• In this case, the requirements change rapidly
and unforeseen technical problems need to
be resolved.
• Small projects:
• These are easily developed using extreme
programming.
115

Agile Methods
• Agile Modeling
• Agile Unified Process (AUP)
• Dynamic Systems Development Method (DSDM)
• Essential Unified Process (EssUP)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Open Unified Process (OpenUP)
116

Scrum
• One of the “agile processes”
• Self-organizing teams
• Product progresses in a series of month-long “sprints”
• Requirements are captured as items in a list of “product
backlog”
117

Scrum Characteristics
• Simple and scalable
• Empirical process
• Short-term detailed planning with constant feedback provides
simple inspect and adapt cycle
• Simple techniques and work artifacts
• Requirements are captured as user stories in a list of product
backlog
• Progress is made in Sprints
• Teams collaborating with the Product Owner
• Optimises working environment
• Reduces organisational overhead
• Detects everything that gets in the way of delivery
• Fosters openness and demands visibility
118

Scrum Team
• These are the people who build products, make
estimates
• Scrum recommends team sizes of 7
• The teams are cross functional
119

Sprints
• Scrum projects make progress in a series of “sprints”
• Analogous to XP iterations (Is an iteration )
• Target duration is one month (Can have 1 day of sprint
planning, 4 days of work and 1 day of sprint review )
• +/- a week or two
• Sprints range from a couple of days to 30 days
• During a sprint, a product increment is designed,
coded, and tested
• Sprints are short duration milestones
120

• More smiling, less worrying...
• More compassion, less
judgment….
• More blessed, less stressed….
• More love, less hate….

Key Roles in Scrum Process
• Three core roles and a range of ancillary roles
• Core Scrum roles:
• Product Owner
• Team
• Scrum Master
• Ancillary roles:
• Stakeholders (customers, vendors)
• Managers (including Project Managers)
122

Key Roles in Scrum Process
• Product Owner
• Acts on behalf of customers to represent their
interests.
• Development Team
• Team of five-nine people with cross-functional skill
sets.
• Scrum Master
• Facilitates scrum process and resolves impediments
at the team and organization level by acting as a
buffer between the team and outside interference.
123

Scrum Ceremonies
• A team's agility is built on engineering practices, a
strategic approach to development and change, and
great team collaboration.
• Agile ceremonies facilitate communication across
the team and promote shared understanding of
what is being built within a sprint.
• Scrum Ceremonies are
• Sprint Planning Meeting
• Sprint
• Daily Scrum
• Sprint Review Meeting
•
124

• What is it?
A collaborative effort involving a
• Scrum Master- who facilitates the meeting,
• a Product Owner- who clarifies the details of the product
backlog items and their respective acceptance criteria, and
• the Development Team- who define the work and effort
necessary to meet their sprint goal.
• In this meeting, the product owner and the team members decide
which Backlog Items the Team will work on in the next sprint
• Scrum Master should ensure that the Team agrees to realistic
goals
125
Sprint Planning

• What does the team do?
• Capacity Planning : Team collaboration to decide how much time can be
allocated to the sprint.
• Sprint Goal: The product owner’s summary of the desired outcome for the
sprint being planned. It provides a shared objective, and states why it’s
worthwhile undertaking the sprint.
• Sprint Backlog - The sprint backlog is a list of tasks identified by the
Scrum team to be completed during the Scrum sprint.
• During the sprint planning meeting, the team selects some number of
product backlog items, usually in the form of user stories, and identifies
the tasks necessary to complete each user story.
• User stories are pulled into the sprint backlog based on a collective
agreement of the team. This is a chance for the team to ask questions
to clarify what is being asked in the user story if not covered fully in
backlog refinement. SPM (6e) Selection of project approach© The
126
Sprint Planning

Sprint Planning
• What is the Output?
• A sprint goal and sprint backlog to work
from for the time boxed sprint.
127

Sprint
• Fundamental process flow of Scrum
• A month-long iteration, during which an
incremental product functionality completed
• NO outside influence can interfere with the
Scrum team during the Sprint
• Each Sprint begins with the Daily Scrum
Meeting
128

Daily Scrum
• Held daily:
• Short meeting
• Lasts for about 15mins only
• Main objective is to answer three questions:
• What did you do yesterday
• What will you do today?
• What obstacles are in your way?
129

Sprint Review Meeting
• Team presents what it accomplished during the
sprint
• Typically takes the form of a demo of new
features or underlying architecture
• Informal meeting:
• The preparation time should not exceed about
2-hours
130

The past is a place of reference,
not a place of residence…..;
the past is a place of learning….,
not a place of living…..”
131

Sprint Artifacts
• Product backlog
• Sprint backlog
• Sprint burndown chart
132

Product Backlog
• All work items related to a product/project, ordered by
a Product Owner.
• A list of all desired work on the project --- usually a
combination of :
• story-based work (e.g. “let user search and replace”)
• task-based work (“improve exception handling”)
• List is prioritized by the Product Owner
133

Sprint Backlog
• The sprint backlog comes from the product backlog, but it
contains only that item, or those items, that can be completed
during each sprint.
• A subset of Product Backlog Items, which define the work for a
Sprint
• Created by Team members
• Each Item has it’s own status
• Updated daily
134

Sprint Burndown Chart
• A burn down chart shows how much work is remaining to be
done in the project,
• Day-wise depicts the total Sprint Backlog hours remaining
• Ideally should burn down to zero to the end of the Sprint
135

Lean Software Development
• It based on the principle “Just in time production”
• It aims at increasing speed of software development and
decreasing cost
• Lean development can be summarized in seven steps:
1) Eliminating Waste
2) Amplifying learning
3) Defer commitment (deciding as late as possible)
4) Early delivery
5) Empowering the team
6) Building Integrity
7) Optimize the whole
137

Managing Iterative Processes
• There are two levels of development suggested by
Booch i.e.
• Micro Process
• Macro Process :
•closely related with waterfall process model.
•At this level, a range of activities carried out by a
variety of specialist groups has to be coordinated.
•Within the macro process there will be micro
process activities which might involve iterative
working
138

macro and micro processes
• The figure illustrate
• how a sequential macro
process can be imposed on
a number of iterative
sub-processes.
• With iterative micro
processes, the use of
time-boxes is needed to
control at the macro level
139

Attitude is a choice….
Happiness is a choice….
Optimism is a choice….
Kindness is a choice….
Giving is a choice….
Respect is a choice….
Whatever choice you make makes you.
Choose wisely..!!
140

Selecting the most appropriate
Process Model
141

142
combinations of approach
yes yes no
yes yes yes
yes yes no
evolutionar
y
incremental
evolutionar
y
incremental
one-shot
one-shot
installation
con
stru
ctio
n
• one-shot or incremental installation - any
construction approach possible
• evolutionary installation implies evolutionary
construction

EVOLUTIONARY PROJECT MANAGEMENT
A project management process delivering evolutionary
results “ high-value-first“ progress towards the desired
goals, and seeking to obtain, and use, realistic, early
feedback.

144
‘rules of thumb’ about approach to be used
IF uncertainty is high
THEN use evolutionary approach
IF complexity is high but uncertainty is not
THEN use incremental approach
IF uncertainty and complexity both low
THEN use one-shot
IF schedule is tight
THEN use evolutionary or incremental

The Five Core Values of XP
145
Communicatio
n.
Simplicity.
Feedback.
Courage.
Respect

Communication
146
Often problem that arise in SW project can be
tracked back to lack of communication.
XP enforces the Communication Value by employing
many practice that could not be carried without
communicating (e.g. pair programming, unit testing
etc.).
XP employs a Coach whose job is that of noticing
when people are not communicating and
reintroduce them.

Simplicity
147
''Do the simplest thing that could possibly work''
(DTSTTCPW) principle (elsewhere known as KISS).
An XP coach may say DTSTTCPW when he sees an XP
developer doing something that is needlessly
complicated.
YAGNI principle (''You ain’t gonna need it'')
Simplicity and Communication support each other
mutually.

Feedback
148
Feedback works in XP at different time scales.
Programmers have feedback on a minutes time scale on
the status of the system thanks to unit tests.
When customers write new stories the programmers
estimate those immediately to give prompt feedback to
the customer about the quality of the stories.
The customer review the scheduler every 2-3 weeks
and provide prompt feedback to the developer.

Courage
XP team should have the courage of throwing code
away.
XP team should have the courage of mainly refactor
the architecture of the system, if architectural flaw
are detected.
Courage with counterbalancing values is dangerous.
Doing something without regard for consequences is
not effective teamwork. 149

Thank you…!!
150

Choosing the Right Software Project Approach

Recommended

Recommended

More Related Content

Similar to Choosing the Right Software Project Approach

Similar to Choosing the Right Software Project Approach (20)

More from RohanMistry15

More from RohanMistry15 (20)

Recently uploaded

Recently uploaded (20)

Choosing the Right Software Project Approach