SPM Chapter4

(1)

Selection of an appropriate project approach

(2)

Selection of an appropriate project approach

Objectives

CHAPTER

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;

Slide# 2

Software Project Management

• Reduce other risks by implementing of the project in increments; • Identify where unnecessary organizational obstacles can be

(3)

Selection of an appropriate project approach

Select Project

0

4.1 Introduction

Select Project Identify project

scope and objective

1 Identify project

infrastructure

2

Identify the products and activities

4 Estimate effort for activity 5 Identify activity risks 6 Analyze project characteristics 3

For each activity Lower level detail

Review activity risks Allocate resources 7 Review/publicize plan 8

Lower level planning

10

Execute plan

(4)

Selection of an appropriate project approach

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.

Slide# 4

(5)

Selection of an appropriate project approach

4.2 Choosing technologies

The chosen technology will influence:

• The training requirements for development staff; • The type of staff to be recruited;

(6)

Selection of an appropriate project approach

Steps of project analysis:

1. Identify project as either objectives driven or product driven; 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.

Slide# 6

(7)

Selection of an appropriate project approach

2. Analyze other project characteristics

The following questions can be carefully asked: 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?

which specific tools have been developed? • Is the system to be created safety critical?

(8)

Selection of an appropriate project approach

3. Identify high level project risks

• Product uncertainty

• Process uncertainty

• Resource uncertainty

Slide# 8

(9)

Selection of an appropriate project approach

5. Select general life-cycle approach

• Control systems

• Information systems

• General tools

(10)

Selection of an appropriate project approach

4.3 Technical plan contents list

The technical plan is likely to have the following contents:

1. Introduction and summary constraints: 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;

Slide# 10

(a) selected methodology or process model; (b) development methods;

(c) required software tools;

(11)

Selection of an appropriate project approach

4.3 Technical plan contents list

3. Implementation:

(a) required development environment; (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;

effect on the schedule and staff-time;

(12)

Selection of an appropriate project approach

4.4 Choice of process models

• Process - to achieve an outcome, the system will have to execute one or more activities;

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

Slide# 12

(13)

Selection of an appropriate project approach

What is SSADM?

Structured Systems Analysis and Design Methodology (SSADM) is an

SSADM Methodology

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; interfaces between them, and clearly defined tangible products;

(14)

Selection of an appropriate project approach

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.

Slide# 14

(15)

Selection of an appropriate project approach

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 quality by reducing error rates Improve flexibility

(16)

Selection of an appropriate project approach

OVERVIEW OF STRUCTURE

Stage 0:

Feasibility Study

Stage 1:

Investigation of current env. Stage 2:

Business system options Stage 3:

Definitions of requirements

Slide# 16

Stage 4:

Technical system options Stage 5:

Logical design

Stage 6:

(17)

Selection of an appropriate project approach

Stage 0: Feasibility overview LDS context diagram current physical level 1 DFD

level 1 DFD

uses c.p.DFD and overview LDS

subsets of DFD and LDS

- The aim is to establish the whether the direction and requirements 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

- Operational feasibility subsets of DFD and LDS_{used for BSOs and TOs}

and for estimation of system size and complexity

(18)

Selection of an appropriate project approach

Stage 1:

Investigation of the current environment

level 1 current physical DFD (c.p.DFD) overview LDS

in step 130 the c.p. DFD is updated from

c.p.DFD converted to

current logical DFD (c.l.DFD)

refine & validate LDM

- An overview of the current processing and data is created. Current 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 of the data in the current system.

Slide# 18

RJP/SSADM 1/PP

DFD is updated from results of Step 120

current logical DFD (c.l.DFD)

(19)

Selection of an appropriate project approach

Stage 2: Business System Options

DFDs and LDM may be used to support both these steps

- Describes a suggested new system in terms of its functionality and 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.

(20)

Selection of an appropriate project approach

Stage 3: Definition of Requirements

Step 310 Define required system processing Step 330 Step 320 Develop required data model

amend c l DFD to

agree with BSO and LDS

(this gives required

system DFD) _{use r}_._s_._{DFD to identify}

required system LDM prepared SSADM Methodology Step 360 Develop processing specification Step 350 Develop specification prototypes Step 340 Enhance required data model Step 330 Derive system functions . .

update & enquiry functions

use r.s.DFD and LDM as inputs to entity/event modelling, creating ELHs, EAPs and ECDs

use r.s.DFD and LDM for

reference

refer to r.s.LDM as necessary

validate and enhance LDM from RDA

- Determine the desired system data, functions and events.

Slide# 20

Step 380 Assemble requirements specification Step 370 Confirm system objectives

RJP/SSADM 3/PP

update required system LDM as necessary

cross check LDM against all other products

- Determine the desired system data, functions and events.

(21)

Selection of an appropriate project approach

Stage 4: Technical Options

LDM now part of requirements

LDM now part of requirements spec.which is input to

this stage

- This assesses the different options for implementing the - 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

(22)

Selection of an appropriate project approach

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

create enquiry

- To design the Menu structure and dialogues of the required system - To specify the Update/Enquiry process module

Slide# 22

Software Project ManagementRJP/SSADM 5/PP

check LDM and other logical design products for consistency

create enquiry process models

- To specify the Update/Enquiry process module

(23)

Selection of an appropriate project approach

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, - Major deliverables are physical data design, program specifications,

(24)

Selection of an appropriate project approach

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

basic diagrammatic techniques.Notice how the diagrams carry forward from

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

Slide# 24

r.s. =required system diagram

DFD =dataflow diagram

E.P.D. =elementary process description

LDM =logical data model

(25)

Selection of an appropriate project approach

SSADM & SYSTEM DEVELOPMENT LIFE CYCLE

SSADM

Feasibility study report

System Analysis and Design Report

(26)

Selection of an appropriate project approach

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.

Slide# 26

(27)

Selection of an appropriate project approach

(28)

Selection of an appropriate project approach

4.5 Rapid Application Development (RAD)

• 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

Slide# 28

(29)

Selection of an appropriate project approach

4.5 Joint Application Development (JAD)

(30)

Selection of an appropriate project approach

Slide# 30

(31)

Selection of an appropriate project approach

(32)

Selection of an appropriate project approach

–

Advantages

–

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

Slide# 32

–

Disadvantages

• More expensive and can be cumbersome if the

group is too large relative to the size of the

(33)

Selection of an appropriate project approach

(34)

Selection of an appropriate project approach

4.7 V-process model

Slide# 34

(35)

Selection of an appropriate project approach

(36)

Selection of an appropriate project approach

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 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.

Slide# 36

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

(37)

Selection of an appropriate project approach

4.9 Software prototyping

Throw

-

away prototypes

• Use only to test out some ideas and is then discarded when • 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

(38)

Selection of an appropriate project approach

Reasons:

• Learning by doing

• Improved communication • Improved communication • Improved user involvement

• Clarification of partially known requirements

• Demonstration of the consistency and completeness of a specification

• Reduced need for documentation

Slide# 38

• Reduced maintenance costs • Feature constraint

(39)

Selection of an appropriate project approach

Drawbacks

• Users can misunderstand the role of the prototype • Users can misunderstand the role of the prototype • Lack of project standards possible

• Lack of control

• Additional expense • Machine efficiency

(40)

Selection of an appropriate project approach

4.10 Other ways of categorizing prototypes

What is being learnt?

• Learn about the area of uncertainty; • 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.

Slide# 40

(41)

Selection of an appropriate project approach

To what extent is the prototyping to be done?

• Mock-ups

• Simulated interaction

• Partial working model:

(42)

Selection of an appropriate project approach

What is being prototyped?

• The human-computer interface

• The functionality of the system

Slide# 42

(43)

Selection of an appropriate project approach

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.

(44)

Selection of an appropriate project approach

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.

Slide# 44

(45)

Selection of an appropriate project approach

Identify system objectives Incremental delivery plan

Identify system objectives

Create open technology plan

Plan increments

Design increment

Build the increment

(46)

Selection of an appropriate project approach

4.12 Incremental delivery 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;

Slide# 46

• ‘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

(47)

Selection of an appropriate project approach

Disadvantages:

• Software breakage, that is, later increments may require • 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.

(48)

Selection of an appropriate project approach

The incremental delivery plan

• The process is similar to strategic planning, but • The process is similar to strategic planning, but

more detailed level;

• The elements of incremental plan – system objectives

– open technology plan – incremental plan

Slide# 48

(49)

Selection of an appropriate project approach

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

(50)

Selection of an appropriate project approach

Create open technology plan

Minimum require the use of: Minimum require the use of:

• A standard high-level language; • a standard operating system; • small modules;

• variable parameters

Slide# 50

(51)

Selection of an appropriate project approach

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;

(52)

Selection of an appropriate project approach

4.12 Incremental delivery example

Slide# 52

(53)

Selection of an appropriate project approach

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

(54)

Selection of an appropriate project approach

Nine core DSDM principles have been enunciated:

1. Active user involvement is imperative;

2. DSDM teams must be empowered to make decisions; 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;

Slide# 54

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

(55)

Selection of an appropriate project approach

Feasibility Business study Identify design Business study Functional mode iteration Identify functional prototype Agree schedule Create functional prototype Review prototype Implementation Implement Train users

(56)

Selection of an appropriate project approach

DSDM development process consists of 7 phases:

1. Pre-project: not strictly defined.

2. Feasibility Study

3. Business Study

4. Functional model

DSDM development process consists of 7 phases:

Slide# 56

5. Design and Build

(57)

Selection of an appropriate project approach

Finding out if and how the project will work out

Studying the business Studying the business aspects of the project

The product is wrapped up, documentation is written, and a review document is drawn

Functional prototypes of the system are made and

reviewed. The product is designed anddeveloped in iterations. Each iteration is made of the area being developed, and then that area is coded and reviewed.

(58)

Selection of an appropriate project approach

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

Slide# 58

(59)

Selection of an appropriate project approach

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. 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

(60)

Selection of an appropriate project approach

Problems in

software development

Risks

:

• Schedule slips

• Business misunderstood

• Defect rate

• Project cancelled

• System goes sour

Slide# 60

(61)

Selection of an appropriate project approach

Schedule slips

• Many projects are not delivered on time

– Examples:

Word 1.0, Netscape 6

• Some deadlines cannot be moved

– Example:

Y2K

• What if:

(62)

Selection of an appropriate project approach

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

Slide# 62

(63)

Selection of an appropriate project approach

Defect rate

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

is so high that it isn’t used.

(64)

Selection of an appropriate project approach

Project cancelled

Size of project Early On-Time Delayed Cancelled Sum

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%

Slide# 64

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:

(65)

Selection of an appropriate project approach

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:

(66)

Selection of an appropriate project approach

Business changes

• New laws, market changes: business priorities change

• What if:

the customer can change their mind, substitute

functionality, and change priorities

Slide# 66

(67)

Selection of an appropriate project approach

Economics of

software development

(68)

Selection of an appropriate project approach

What if…

cost of change

Slide# 68

(69)

Selection of an appropriate project approach

XP Practices

• Planning Game

• Pair Programming

• Planning Game

• Small Releases

• Metaphor

• Simple Design

• Testing

• Refactoring

• Pair Programming

• Collective Ownership

• Continuous Integration

• 40 Hour Week

(70)

Selection of an appropriate project approach

Description of XP Practices

XP Practice Summary Industry Practice

Planning Game Determine the scope for the next release by Project Planning 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

Slide# 70

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

(71)

Selection of an appropriate project approach

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

(72)

Selection of an appropriate project approach

Slide# 72

(73)

Selection of an appropriate project approach

4.15 Managing iterative processes

Microprocess

Stop/checkpoint

Macroprocess A macroprocess containing three

iterative microprocesses.

Microprocess

Iterate as required

Microprocess

Iterate as

Stop/checkpoint Macroprocess

Iterate as required

Stop/checkpoint

(74)

Selection of an appropriate project approach

traditional Waterfall lifecycle model Iterative lifecycle model

Slide# 74

(75)

Selection of an appropriate project approach

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

 Quick feedback loop from business stakeholders to engineering back

 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  Focus on getting the highest priority features and the highest risk

features implemented as fast as possible

(76)

Selection of an appropriate project approach

4.16 Selecting the most appropriate process model

When uncertainty is high then an evolutionary approach is to be favoured.

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.

Slide# 76

(77)

Selection of an appropriate project approach

4.17 Conclusion

This chapter has stressed the need to examine each project 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 may be able to reduce project uncertainties by allowing knowledge to be bought through experimentation. The incremental approach