SPM Chapter4

Selection of an appropriate project approach
CHAPTER
Software Project Management Slide# 1

CHAPTER
Objectives
Main Objectives:
• Take account of the characteristics of the system to be developed

when planning a project;
• Select an appropriate process model;
• Make best use of the ‘waterfall’ process model where appropriate;
• Reduce risks by the creation of appropriate prototypes;
• Reduce other risks by implementing of the project in increments;
• Identify where unnecessary organizational obstacles can be
removed by using ‘agile’ development methods.

4.1 Introduction
0
Select Project
1 Identify project 2 Identify project
scope and objective infrastructure
3
Analyze project
characteristics
4 Identify the
Review products and activities
5 Estimate effort
for activity
For each activity
Lower level detail 6 Identify
activity risks
10Lower level planning

7 Allocate resources
9 Execute plan
8 Review/publicize plan
Project analysis is the subject of step 3

4.1 Introduction
The development of software in-house usually means that:
• The project team and the users belong to the same organization;
• The applications being considered slot into a portfolio of existing
computer-based systems;
• The methodologies and technologies to be used are not selected
by the project manager, but are dictated by local standards.

4.2 Choosing technologies
The chosen technology will influence:
• The training requirements for development staff;

• The type of staff to be recruited;
• The development environment - both hardware and software;
• System maintenance arrangements.

Steps of project analysis:
1. Identify project as either objectives driven or product driven;

2. Analyze other project characteristics;
3. Identify high level project risks;
4.Take into account user requirements concerning implementation;
5. Select general life-cycle approach.

2. Analyze other project characteristics

The following questions can be carefully asked:
• Is a data-oriented or process-oriented system to be
implemented?
• Will the software that is to be produced be a general tool or
application specific?
• Is the application to be implemented of a particular type for
which specific tools have been developed?
• Is the system to be created safety critical?
• What is the nature of the hardware/software environment in
which the system will operate?

3. Identify high level project risks
• Product uncertainty
• Process uncertainty
• Resource uncertainty

5. Select general life-cycle approach
• Control systems
• Information systems
• General tools
• Specialized techniques
• Hardware environment
• Safety-critical systems
• Imprecise requirements

4.3 Technical plan contents list
The technical plan is likely to have the following contents:
1. Introduction and summary constraints:

(a) character of the system to be developed;
(b) risks and uncertainties of the project;
(c) user requirements concerning implementation.
2. Recommended approach
(a) selected methodology or process model;
(b) development methods;
(c) required software tools;
(d) target hardware/software environment.

4.3 Technical plan contents list
3. Implementation:
(a) required development environment;
(b) required maintenance environment;
(c) required training.
4. Implications:
(a) project product and activities - this will have an
effect on the schedule and staff-time;
(b) financial - this report will be used to produce
costings.

4.4 Choice of process models
• Process - to achieve an outcome, the system will have to execute

one or more activities;
• Applies to the development of computer-based systems;
• These activities called process models.
Methodology : SSADM
SSADM (Structured Systems Analysis and Design Methodology) is a methodology used
in the analysis and design stages of system development. It was launched in 1981,
commissioned by CCTA (Central Computing and Telecommunications Agency) in a bid
to standardize the many and varied IT projects being developed across government
departments.

SSADM Methodology
What is SSADM?
Structured Systems Analysis and Design Methodology (SSADM) is an
integrated set of standards and guides for the analysis and design of
computer systems. It is an integrated set of standards and guidelines
consisting of :
Structural standards, which define the structure of a development

project in the form of explicitly defined tasks, with clearly defined
interfaces between them, and clearly defined tangible products;
Technique guides, which provide development staff with a set of
proven usable techniques and tools, and detailed rules and guidelines
on when and how to use them; and
Documentation standards, which provide the means of recording
the products of development activity at a detailed level.
SSADM Methodology
HISTORY OF SSADM
SSADM was introduced in 1981 as the standard method of analysis
and design for UK Government projects. ITSD adopted SSADM since
May 1988. After a series of successful pilot implementation, the full
implementation of SSADM commenced in 1991. Since November
1991, all administrative computer systems developed in ITSD used
SSADM (or Rapid Application Development (RAD) since November
1997). Currently, a customised SSADM Version 4.2 is being adopted.

SSADM Methodology
BENEFITS OF SSADM
Deliver the system to users on time
Deliver systems that meets user’s needs
Deliver systems which respond to changes in the
business environment
Improve the effective and economic use of the skill
available
Improve quality by reducing error rates
Improve flexibility
Improve productivity
Avoid lock-in to a single source of supply
Avoid IT developers’ bureaucracy
SSADM Methodology
OVERVIEW OF STRUCTURE
Stage 0:
Feasibility Study
Stage 1:
Investigation of current env.
Stage 2:
Business system options
Stage 3:
Definitions of requirements
Stage 4:
Technical system options
Stage 5:
Logical design
Stage 6:
Physical design

SSADM Methodology
Stage 0: Feasibility overview LDS

context diagram
current physical
level 1 DFD
uses c.p.DFD and

- The aim is to establish the whether the direction and requirements
overview LDS
of the project feasible.
- To evaluate the feasibility of the proposal, involving an analysis of
the problem and determination of the best solution.
- Economic feasibility
- Technical feasibility
subsets of DFD and LDS
- Operational feasibility used for BSOs and TOs
and for estimation of system size
and complexity
LDS included in
environment descriptions
Software
RJP/SSADM Project
0/PP Management Slide# 17
SSADM Methodology
Stage 1:
Investigation of the level 1 current physical DFD (c.p. DFD)
current environment overview LDS
refine & validate

- An overview of the current processing and data is created. Current LDM
problems are documented as a necessary improvements and any
new data or functions that will be required.
- DFD is produced showing the current system
- ERD is produced showing entities and relationships obtained by
analysis
in step 130 the c.p.of the data in the current system. c.p. DFD converted to
DFD is updated from current logical DFD (c.l. DFD)
results of Step 120
amend LDM to support c.l. DFD
and EPDs as required
Software 1/PP
RJP/SSADM Project Management Slide# 18
SSADM Methodology
Stage 2: Business System Options
DFDs and LDM may be used

- Describes a suggested new system in terms of its functionality
to support and
both these steps
its boundary: input, outputs, processes, and data.
- The aim is to help the user choose, from all the listed requirements,
just what they want their new system to do.
Software Project Management

RJP/SSADM 2/PP
Slide# 19
SSADM Methodology
Stage 3: Definition of Requirements
Step 320 required system
Step 310 amend c l DFD to
Develop required LDM prepared
Define required agree with BSO and LDS data model
system (this gives required
processing system DFD) . . DFD to identify
use r.s.
Step 330 update & enquiry functions
Derive system
functions refer to r.s. LDM as necessary
Step 350 Step 340 validate and

Develop Enhance enhance LDM
specification required data from RDA
prototypes model
Step 360
Develop
use r.s. DFD and processing use r.s. DFD and LDM as inputs to
LDM for specification
entity/event modelling, creating ELHs,
reference EAPs and ECDs
- Determine the desired system data, functions and events.
- Prototyping techniques Step
are370also suggests for the development.
- Modified DFD and ERD to match requirements
Confirm system
objectives
update required system LDM
as necessary
Step 380
Assemble cross check LDM against all
requirements
specification other products

RJP/SSADM 3/PP
Slide# 20
SSADM Methodology
Stage 4: Technical Options
LDM now part of requirements

spec. which is input to
this stage
- This assesses the different options for implementing the

specification and describes the costs, benefits, and constraints.
- Factors include internal and external constraints.
- Procedure is firstly to draw up an initial list of approximately
technical system options. Then expanded to include details derived
from potential suppliers.

RJP/SSADM 4/PP
Slide# 21
SSADM Methodology
Stage 5: Logical Design
requirements spec. input to
this stage
update entity descriptions

in LDM, include state indicators
on ELHs and create update
process models
- To design the Menu structure and dialogues of the required system

- To specify the Update/Enquiry process module create enquiry
- Deliverables process modules, screen/report layouts process models
check LDM and other logical

design products for consistency

RJP/SSADM 5/PP
Slide# 22
SSADM Methodology
Stage 6: Physical Design
LDM is main
input
LDM is used
for reference
- To specify the physical data and process design, using the language
and feature of the chosen physical environment
- To resulting design should provide sufficient information for
subsequent processes in the Implementation phases
- Major deliverables are physical data design, program specifications,
process data interfaces

RJP/SSADM 6/PP
Slide# 23
SSADM Methodology
Stages of SSADM v4 annotated to show main uses of the three

basic diagrammatic techniques. Notice how the diagrams carry forward from
stage to stage becoming transformed from the existing physical system
through a logical system and eventually to the required system.
Key to abbreviations:
c.p. = current physical diagram
c.l. = current logical diagram
r.s. = required system diagram
DFD = dataflow diagram
E.P.D. = elementary process description
LDM = logical data model
ELH = entity life history

SSADM Methodology
SSADM & SYSTEM DEVELOPMENT LIFE CYCLE
SSADM
Feasibility study report
System Analysis and Design Report
Documentation for
Implementation Phase

4.5 Rapid Application Development (RAD)
RAD is an object-oriented approach to systems development

that includes a method of development as well as software
tools.


• RAD Advantages and Disadvantages

– Advantages
• Systems can be developed more quickly with significant
cost savings
– Disadvantages
• RAD stresses the mechanics of the system itself and does
not emphasize the company’s strategic business needs
• Might allow less time to develop quality, consistency, and
design standards

4.5 Joint Application Development (JAD)
JAD was developed by IBM. The motivation for using JAD is to

cut the time required by personal interviews, to improve the
quality of the results of information systems as a result of the
participative processes.



– Advantages
• Allows key users to participate effectively
• When properly used, JAD can result in a more
accurate statement of system requirements, a
better understanding of common goals, and a
stronger commitment to the success of the
new system
– Disadvantages
• More expensive and can be cumbersome if the
group is too large relative to the size of the
project

4.6 Waterfall model

4.7 V-process model

4.8 Spiral model

Advantages of the Spiral Model

• The spiral model is a realistic approach to the development of large-scale
software products because the software evolves as the process progresses.
In addition, the developer and the client better understand and react to risks
at each evolutionary level.
• The model uses prototyping as a risk reduction mechanism and allows for the
development of prototypes at any stage of the evolutionary development.
• It maintains a systematic stepwise approach, like the classic life cycle model,
but incorporates it into an iterative framework that more reflect the real
world.
• If employed correctly, this model should reduce risks before they become
problematic, as consideration of technical risks are considered at all stages.
Disadvantages of the Spiral Model
• Demands considerable risk-assessment expertise
• It has not been employed as much proven models (e.g. the WF model) and
hence may prove difficult to ‘sell’ to the client (esp. where a contract is
involved) that this model is controllable and efficient. [More study needs to
be done in this regard]

4.9 Software prototyping
Throw-away prototypes
• Use only to test out some ideas and is then discarded when
the true development of the operational system is
commenced.
• Using a different software environment or
• Using a different kind of hardware platform.
Evolutionary prototypes
• Developed and modified until it is finally in a state where it
can become the operational system.

Reasons:
• Learning by doing
• Improved communication
• Improved user involvement
• Clarification of partially known requirements
• Demonstration of the consistency and completeness of
a specification
• Reduced need for documentation
• Reduced maintenance costs
• Feature constraint
• Production of expected results.

Drawbacks
• Users can misunderstand the role of the prototype

• Lack of project standards possible
• Lack of control
• Additional expense
• Machine efficiency
• Close proximity of developers

4.10 Other ways of categorizing prototypes
What is being learnt?
• Learn about the area of uncertainty;

• Real prototype
– specify what they hope to learn from the prototype
– plan how the prototype is to be evaluated
– report on what has actually been learnt.

To what extent is the prototyping to be done?
• Mock-ups
• Simulated interaction
• Partial working model:
– Vertical
– Horizontal

What is being prototyped?
• The human-computer interface
• The functionality of the system

4.11 Controlling changes during prototyping
• Cosmetic (about 35% of changes)

– implemented;
– recorded.
• Local (about 60% of changes)
– implemented;
– recorded;
– back-up so that they can be removed at a later stage if
necessary;
– inspected retrospectively.
• Global (about 5% of changes)

4.12 Incremental delivery
• This approach involves breaking the application

down into small components which are then
implemented and delivered in sequence.
• Each component delivered must give some benefit
to the user.
• Time boxing: is associated with an incremental
approach.

Incremental delivery plan

Identify system objectives
Create open technology plan
Plan increments
Design increment
Build the increment
Implement the increment
Evaluate the results

Advantages of this approach
• The feedback from early increments improve the later stages;

• The possibility of changes in requirements is reduced because of the
shorter time-span between the design of a component and its
delivery;
• Users get benefits earlier than with a conventional approach;
• Early delivery of some useful components improves cash flow,
because you get some return on investment early on;
• Smaller sub-projects are easier to control and manage;
• ‘Gold-plating’ that is requesting of features that are unnecessary and
not in fact used.
• The project can be temporarily abandoned if more urgent work crops
up.
• Job satisfaction is increased for developers who see their labours
bearing fruit at regular, short, intervals.
Disadvantages:
• Software breakage, that is, later increments may require

modifications to earlier increments.
• Programmers may be more productive working on one large
system than on a series of smaller ones.
• Conceptual integrity sometimes suffers because there is little
motivation to deal with scalability, extensibility, portability or
reusability beyond what any vogue requirements might imply.

The incremental delivery plan

• The process is similar to strategic planning, but
more detailed level;
• The elements of incremental plan
– system objectives
– open technology plan
– incremental plan

Identify system objectives
• Functional goals
– objectives it is intended to achieve;
– jobs the system is to do;
– computer/non-computer functions to achieve them.
• Quality goals
– reliability
– response
– security.

Create open technology plan

Minimum require the use of:
• A standard high-level language;

• a standard operating system;
• small modules;
• variable parameters
• standard database management system.

Plan increments
• Steps typically should consist of 1% to 5% of the total
project;
• non-computer steps should be included;
• an increment should, ideally, not exceed one month and
should not, at worst, take more than three months;
• each increment should deliver some benefit to the user;
• some increments will be physically dependent on others;
• value-to-cost ratios may be used to decide priorities.

4.12 Incremental delivery example

4.13 Dynamic Systems Development Method (DSDM)
DSDM is an organized, common-sense process

focused on delivering business solutions quickly
and efficiently. It is similar in many ways to
SCRUM and XP, but it has its best uses where the
time requirement is fixed.

Nine core DSDM principles have been enunciated:

1. Active user involvement is imperative;
2. DSDM teams must be empowered to make decisions;
3. Focus on frequent delivery of products;
4. Fitness for business purpose is the essential criterion for
acceptance of deliverables;
5. Iterative and incremental delivery is necessary to converge on an
accurate business solution;
6. All changes during development are reversible;
7. Requirements are base-lined at a high level;
8. Testing is integrated throughout the life cycle;
9. A collaborative and co-operative approach between all
stakeholders is essential.

Feasibility
Business study
Implement
Agree schedule
Create
Functional Identify
functional Review Implementation Train
mode iteration functional
prototype business users
prototype
User approval and user
Review prototype
guidelines
Identify design
prototype
Review
Agree Design/build design
schedule iteration prototype
Create design prototype

DSDM development process consists of 7 phases:
1. Pre-project: not strictly defined.

2. Feasibility Study
3. Business Study
4. Functional model
5. Design and Build
6. Implement/Deploy/Maintain
7. Post-project: Maintenance

Finding out if and how the
project will work out
Studying the business

aspects of the project
The product is wrapped up,

documentation is written, and
a review document is drawn
Functional prototypes of up, comparing the requirement
the system are made and The
withproduct is designed and
their fulfillments.
reviewed. developed in iterations. Each
iteration is made of the area
being developed, and then that
area is coded and reviewed.
http://www.agileapproach.co.uk/html/dsdm_lifecycle.html
In order to prioritize the relative importance of requirements, they

can be categorized using the MoSCoW classification:
• Must have – essential features

• Should have – mandatory but system can operate without them
• Could have – requirement can be delayed
• Won’t have – delay to a later increment of readily accepted

4.14 Extreme programming (XP)
Extreme programming (XP) is a further development of many of

the RAD and DSDM principles that have been explored above.
“Extreme Programming turns the conventional software process

sideways. Rather than planning, analyzing, and designing for the
far-flung future, XP programmers do all of these activities—a little
at a time—throughout Development”.

Problems in
software development
Risks:
• Schedule slips
• Business misunderstood
• Defect rate
• Project cancelled
• System goes sour
• Business changes

Schedule slips
• Many projects are not delivered on time

– Examples: Word 1.0, Netscape 6
• Some deadlines cannot be moved
– Example: Y2K
• What if:
most business value is delivered on time

Business misunderstood
• Without direct communication, developers have to

guess what the customer wants.
– Example: The Orthodontics Project
• What if:
an on-site customer steers development

Defect rate
• The software is put in production, but the defect rate

is so high that it isn’t used.
• What if: you have automated testing

Project cancelled
Size of project Early On-Time Delayed Cancelled Sum
1 function point 14.68% 83.16% 1.92% 0.25% 100.00%
10 function points 11.08% 81.25% 5.67% 2.00% 100.00%
100 function points 6.06% 74.77% 11.83% 7.33% 100.00%
1,000 function points 1.24% 60.76% 17.67% 20.33% 100.00%
10,000 function points 0.14% 28.00% 23.83% 48.00% 100.00%
100,000 function points 0.00% 13.67% 21.33% 65.00% 100.00%
Average 5.53% 56.94% 13.71% 23.82% 100.00%
Table 1: Percentage of projects early, on-time, late, canceled
(from Patterns of Software Systems Failure and Success, by Capers Jones)
What if:
short releases deliver at least some useful working software, reflecting
investment to date

System goes sour
• Software is put into production successfully, but after a

couple of years the cost of making changes or the defect
rate rises so much that the system must be replaced.
• What if:
the design is simple and the code quality is high

Business changes
• New laws, market changes: business priorities change
• What if:
the customer can change their mind, substitute
functionality, and change priorities

Economics of
software development
cost of change
Requirements Analysis Design Implementation Testing Production

What if…
cost of change
Time

XP Practices
• Planning Game • Pair Programming
• Small Releases • Collective Ownership
• Metaphor • Continuous Integration
• Simple Design • 40 Hour Week
• Testing • On-site Customer
• Refactoring • Coding Standard

Description of XP Practices
XP Practice Summary Industry Practice
Planning Game Determine the scope for the next release by Project Planning
selecting stories on which release is based Fundamental
Small Releases A release containing some new business value Evolutionary Prototype
occurs approximately every two weeks Best Practice
Metaphor The high level vision of the entire system is used Requirement Engineer
to drive the detailed design & construction Fundamental
Simple Design The design of the system should be as simple as Simple Design
possible to support the current functionality needs Fundamental
Testing Developer’s create until tests prior to construction, Testing
referred to as Test First. Customers create Test Cases
functional tests. Tests are reused during project Fundamental
Refactoring The system is restructured and reworked Refactoring
throughout the project to decrease complexity, Incremental Dev.
increase flexibility, etc. Fundamental
Fundamental – identifies activities that all software projects should always do to allow basic success.
Best Practice – a common term used to identify practices proven through experience in software industry.

Description of XP Practices
XP Practice Summary Industry Practice
Pair Code is written by two people on the same Extreme Practice
Programming machine at the same time
Collective Any code in the system can be changed by Unselfish Teams/Egoless
Ownership anyone at anytime Good Practice
Continuous Code change or additions are integrated into Integration
Integration production build every time a small task is
completed and no less than one a day Best Practice
40 Hour Week Overtime is required no more than one week Quality of Life
at a time Good Practice
On-site A customer or the selected customer Requirement Engineer
Customer representative is always available to provide and
select stories and answer questions Fundamental
Coding Code is written according to a set of rules to Coding Standard
Standard help improve communication via code Best Practice
Good Practice – covers practices that have not been proven to provide excellent results on a consistent basis.
Extreme Practice – used to identify practices identified exclusively with extreme programming.

http://www.extremeprogramming.org/

4.15 Managing iterative processes
Macroprocess A macroprocess containing three

Stop/checkpoint iterative microprocesses.
Microprocess
Iterate as
required
Macroprocess
Stop/checkpoint
Microprocess
Iterate as
required
Macroprocess
Stop/checkpoint
Microprocess
Iterate as
required

Iterative lifecycle model
traditional Waterfall lifecycle model
http://www.objectivasoftware.com/En/Methodology/IterativeProcess.htm

The Benefits of Objective's Iterative Process are the following:

 Quick feedback loop from business stakeholders to engineering back
to business stakeholders
 Rapid software product conceptualization and materialization
through prototyping
 Ability to refine requirements and design, and handle changes in
both in the early phases of a product lifecycle
 Focus on getting the highest priority features and the highest risk
features implemented as fast as possible
 Ability to validate pieces of design incrementally, providing
continuous analysis and mitigating the ris

4.16 Selecting the most appropriate process model
When uncertainty is high then an evolutionary approach is to

be favoured.
Where the requirements are relatively certain but there are
many complexities, as with a large embedded system needing
a large amount of code, then an incremental approach might
be favoured.
Where deadlines are tight, then either an evolutionary or an
incremental approach is favoured over a one-shot strategy.

4.17 Conclusion
This chapter has stressed the need to examine each project

carefully to see whether it has characteristics that suggest a particular
approach or process model. These characteristics might suggest the
addition of specific activities to the project plan.
The classic waterfall process model that attempts to minimize
iteration should lead to projects that are easy to control. Unfortunately
many projects do not lend themselves to this structure. Prototyping
may be able to reduce project uncertainties by allowing knowledge to
be bought through experimentation. The incremental approach
encourages the execution of a series of small, manageable, ‘mini-
projects’, but does have some costs.

SPM Chapter4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SPM Chapter4

Uploaded by

Copyright:

Available Formats

Selection of an appropriate project approach

Software Project Management Slide# 1

• Take account of the characteristics of the system to be developed

Software Project Management Slide# 2

10Lower level planning

Project analysis is the subject of step 3

Software Project Management Slide# 3

The development of software in-house usually means that:

Software Project Management Slide# 4

The chosen technology will influence:

• The training requirements for development staff;

Software Project Management Slide# 5

Steps of project analysis:

1. Identify project as either objectives driven or product driven;

Software Project Management Slide# 6

2. Analyze other project characteristics

Software Project Management Slide# 7

3. Identify high level project risks

Software Project Management Slide# 8

5. Select general life-cycle approach

Software Project Management Slide# 9

The technical plan is likely to have the following contents:

1. Introduction and summary constraints:

Software Project Management Slide# 10

Software Project Management Slide# 11

• Process - to achieve an outcome, the system will have to execute

Software Project Management Slide# 12

Structural standards, which define the structure of a development

Software Project Management Slide# 14

Software Project Management Slide# 16

Stage 0: Feasibility overview LDS

uses c.p.DFD and

refine & validate

Stage 2: Business System Options

DFDs and LDM may be used

Software Project Management

Step 350 Step 340 validate and

Software Project Management

Stage 4: Technical Options

LDM now part of requirements

- This assesses the different options for implementing the

Software Project Management

update entity descriptions

- To design the Menu structure and dialogues of the required system

check LDM and other logical

Software Project Management

Software Project Management

Stages of SSADM v4 annotated to show main uses of the three

c.l. = current logical diagram

r.s. = required system diagram

DFD = dataflow diagram

E.P.D. = elementary process description

LDM = logical data model

ELH = entity life history

Software Project Management Slide# 24

SSADM & SYSTEM DEVELOPMENT LIFE CYCLE

System Analysis and Design Report

Software Project Management Slide# 25

RAD is an object-oriented approach to systems development

Software Project Management Slide# 26

Software Project Management Slide# 27

• RAD Advantages and Disadvantages

Software Project Management Slide# 28

JAD was developed by IBM. The motivation for using JAD is to