Chapter 4.

Selection of an appropriate project approach

Step Wise - an overview

1. Identify project objectives 0.Select project 2. Identify project infrastructure 3. Analyse project characteristics Review 4. Identify products and activities 5. Estimate effort for activity 6. Identify activity risks 7. Allocate resources 8. Review/ publicize plan
2

Lower level detail 10. Lower level planning

activity For each

9. Execute plan

Step 3 Analysis of project characteristics

y

3.1 Distinguish the project as either objective or product-based.

Object v/s Product Is there more than one way of achieving success? Mostly in earlier stage projects are objective and in later stage it become product driven

Step 3 Analysis of project characteristics

y

3.2 Analyze other project characteristics (including quality based ones)

what is different about this project? Whether it is a information system or embedded system? What are the critical issues? Malfunctioning threatened human life?

Step 3 continued
y

3.3 Identify high level project risks

what could go wrong? what can we do to stop it?

3.4 Take into account user requirements concerning implementation

For example customer want the product in java

3.5 Select development methodology and life cycle approach

waterfall? Increments? Prototypes? Generally Company use the same method or SDLC as they were using in past It also depends on project need.
5

Analyse project characteristics

y

There is two way to develop a software:

In-house Software houses

Either it is in-house development or by software houses it is required to review methodologies and techniques for each project y This process of reviewing is known as technical planning or project analysis
y
6

Steps of project analysis

y y

Identify project as either objective driven or product driven Analyse other project characteristics
Is a data-oriented or process-oriented
x Data oriented- Information systems x Process oriented- embedded control system

Will the software to be produce is a general tool or application specific? Are there tool available for implementing the particular type of application? Is the system to be critical? What is the nature of hardware and software environment?
7

Steps of project analysis

y

Identify high level project risk

Some of the risks are:
x Product uncertainty x Process uncertainty x Resource uncertainty

Take into account user requirement concerning implementation. Select general life-cycle approach

Technical plan content list

Output of project analysis is technical plan. y It contains :
y

Introduction and summary of constraints:

x Character of the system to be developed x Risk and uncertainties x User requirement concerning implementation

Recommended approach
x x x x Select methodology Development methods Required s/w tools Target hardware/software environment

Technical plan content list

Development needs
x Required development environment x Required maintenance environment x Required training

Implementations
x Project products and activities x Financial- this report will be used to produce costing

10

LIFE CYCLE MODELS

11

Waterfall

The waterfall model

12

Waterfall
y y y

the classical model every stage needs to be checked and signed off Ideal for:
Where requirement are well defined Development methods are well understood

BUT
limited scope for iteration

13

V-process model

Another way of looking at the waterfall model

14

3. Spiral Model (SSADM ver4)

15

Evolutionary delivery: prototyping

An iterative process of creating quickly and inexpensively live and working models to test out requirements and assumptions Main types: y throw away prototypes y evolutionary prototypes What is being prototyped? y human-computer interface y functionality
16

Reasons for prototyping

y y y y y y y

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

17

Prototyping: some dangers

users may misunderstand the role of the prototype y lack of project control and standards possible y additional expense of building prototype y focus on user-friendly interface could be at expense of machine efficiency
y

18

INCREMENT DELIVERY MODEL

19

Incremental delivery
delivered system
design build install evaluate

first incremental delivery

increment 1

design

build

install

evaluate

increment 2

second incremental delivery

design build install evaluate

increment 3

third incremental delivery

20

Increment Delivery Model(cont.)

In this model we break the application down into small components. y These components are then implemented and delivered in sequence.
y

21

The incremental process

Incremental delivery

22

Incremental approach:benefits
y y y y y

feedback from early stages used in developing latter stages user gets some benefits earlier Easy to control and manage project may be put aside temporarily reduces gold-plating: BUT there are some possible disadvantages loss of economy of scale
More productivity at larger scale

y y

software breakage
23

The incremental delivery plan

The nature and order of each increment to be delivered to the user have to be planned. y Elements of increment plan are:
y

System objective Incremental plan Open technology plan

24

System objective
Project planner ideally wants well defined objective but as much freedom as possible about how to be met. y Objectives
y

Function goal
x Objective x Jobs the system is to do x Computer/non-compute function to achieve them

Quality Goal
x Reliability , response and sercurity
25

Open technology plan

If it is required to add new components continually to the system the system should be extendible, portable and maintainable y So it require:
y

A standard high level language A standard operating system Small modules A standard DBMS

26

The outline incremental plan

Steps ideally 1% to 5% of the total project y Ideal if a step takes one month or less:
y

not more than three months

Each step should deliver some benefit to the user y Some steps will be physically dependent on others
y

27

28

Agile methods
structured development methods have some perceived advantages
produce large amounts of documentation which can be largely 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?

29

Dynamic system development method

UK-based consortium y arguably DSDM can be seen as replacement for SSADM y DSDM is more a project management approach than a development approach y Can still use DFDs, LDSs etc!
y

30

Nine core DSDM principles

1. Active user involvement 2. Teams empowered to make decisions 3. Frequent delivery of products 4. Fitness for business purpose 5. Iterative and incremental delivery 6. Changes are reversible 7. Requirements base-lined at a high level 8. Testing integrated with development 9. Collaborative and co-operative approach
31

DSDM framework
Figure 4.6 here

DSDM process model

32

DSDM: time-boxing timetime-box fixed deadline by which something has to be delivered y typically two to six weeks y MOSCOW priorities
y

Must have - essential Should have - very important, but system could operate without Could have Want - but probably wont get!

33

Extreme programming
y y

increments of one to three weeks

customer can suggest improvement at any point

argued that distinction between design and building of software are artificial y code to be developed to meet current needs only y frequent re-factoring to keep code structured

34

Extreme programming - contd

y y

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

35

Grady Boochs 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?
36

Macro and micro processes

A macro process containing three iterative micro processes

37

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
38

Combinations of approach
installation one-shot one-shot incremental evolutionary yes yes yes incremental yes yes yes evolutionary no no yes

one-shot or incremental installation - any construction approach possible evolutionary installation implies evolutionary construction

39