32 Systemdevelopment Methodologies 101107012049 Phpapp02

7/31/2019 32 Systemdevelopment Methodologies 101107012049 Phpapp02

1/36

Fundamen

talInformatio

nTechnologyEngineers

By: Alex PuahFujitsu Asia Pte Ltd

System Development

MethodologiesSoftware Crisis: The Need for a Methodology

What is a Methodology?

The Objectives of the Software DeveloperWhat is software quality?

The Generic Tasks of System Development

Methodologies

Classical Life Cycle (Waterfall)

Prototyping

Spiral Method


2/36


3/36

Fundamen

talInformatio



Software Crisis

Some findings of the OASIG (UK) 1996:

80-90% of software projects do not meet theirperformance goals,

about 80% are delivered later and over budget,

around 40% fail or are abandoned,

under 40% fully address training and skillsrequirements,

less than 25% properly integrate enterprise andtechnology objectives,

just 10-20% meet all their success criteria


4/36

Fundamen

talInformatio



Software Crisis

Some of the problems identified:

Lack of a complete requirements specification,

Lack of an appropriate developmentmethodology,

Poor decomposition of design into manageablecomponents

Conclusion:

The need for a structured approach to softwaredevelopment


5/36

Fundamen

talInformatio



What is a Methodology?

A particular combination of procedures,

techniques (methods) and tools for developing a

system

Elements of a methodology

Procedures: A sequence of well defined steps

Methods: Technical know-how for building software

Examples: techniques to carry out requirements analysis,design, testing, etc.

Tools: Provide automated or semi-automated support

for process and techniques/methods


6/36

Fundamen

talInformatio



Generic Tasks of System

Development Requirements Gathering, Analysis and Specification

Tailor:

System Development

Design: Tailor:

Systems Development: Construction

Tailor:

Systems Development:

Testing Tailor:


Implementation, Operations and Maintenance Tailor:



7/36

Fundamen

talInformationTechnologyEngineers


Objectives of the System Developer

Each methodology attempts to approach

system development in a way that would

result in a better product and achieveobjectives

What are the objectives of the software

developer?


8/36

Fundamen



Software Quality

What are the characteristics of software

quality?

Which software quality factor is most

important?


9/36

Fundamen



Characteristics of Methodology

All methodologies however contain the

following components:

A work breakdown structure that providesguidance on what to do and when to do it.

Techniques on how to do whatneeds to be done

Advice on how to manage the quality of theseresults


10/36

Fundamen



Why do we need a methodology?

Ensure high quality outputs

Ensure system development process issystematic and not haphazard or based on

individual inspiration Allows system development process to be

managed, taught and practiced to ensure highquality assurance

Achieve efficiency and effectiveness in softwareengineering

In your opinion, what is a good methodology?


11/36

Fundamen



Difference Between SDLC and

Methodology SDLC describes the stages or phases in the

development of a system

A methodology is a particular combination

of procedures, techniques and tools for

developing an (information) system.

Each methodology will have its ownsystems development life cycle.


12/36

Fundamen

talInformationTechnolog

yEngineers


Classical SDLC (Waterfall Model)

Characterized by a sequential approachanearlier phase has to be completed before the

next phase is embarked User get to see the system late in its

development

Any wrong requirements or design aretherefore realized later and may results inmore expensive loop-backs.


13/36

Fundamen


yEngineers



Analysis

Design

Implementation

Testing

Evaluation &

Maintenance


14/36

Fundamen


yEngineers



Question:

In what situations would the Classical System

Development Life Cycle be more useful?


15/36

Fundamen


yEngineers


Prototyping

Iterative process

Stages: Requirements Gathering

Build initial prototypea working model, based oninitial requirements consolidated

Refinement of requirements through review andrevision of prototype

Features of the prototype used as requirements toformally engineer the product

Main objective of prototyping is to enhance thequality of the requirement specification.


16/36

Fundamen


yEngineers


Prototyping

InitialRequirements

Gathering

Quick Design

Build Prototype

Evaluate &

Refine

Requirements

Engineer

Product


17/36

Fundamen


yEngineers


Prototyping

Questions:

When would prototyping be most useful?

How can prototyping reduce or increasedevelopment time?


18/36

Fundamen


yEngineers


Good Candidates for Prototyping

Projects exhibiting the following characteristics

are usually good candidates for the use of

prototyping: A large degree of uncertainty in the system

The user is unable or unwilling to examine an abstract

paper model such as a data flow diagrams

The user is unable or unwilling to articulaterequirements: I dont know what I want, but Ill

recognize it when I see it!


19/36

Fundamen


yEngineers


Good Candidates for Prototyping

Candidates for prototyping

The system is intended to be on-line, with full-screen

terminal activities (i.e. where user interface is importantespecially in systems used by the mass public)

The system does not require large amounts of

algorithmic process

Systems where the emphasis is on screen layout, reportformat, error messages, data entry etc. rather than on

computational power (for example, decision support, ad

hoc retrieval, record management systems, etc.)


20/36

Fundamen


yEngineers


Guidelines for Developing a

Prototype

Work in manageable modules

Not necessary to build a complete systembefore testing functionality

Build modules that allow interaction with theirkey features

Modules can be built and tested separately fromother parts of the system

Less important features can be left to laterstages


21/36

Fundamen


yEngineers



Prototype

Build the prototype rapidly

Speed is essential in prototyping

Prototype can be started even though requirements are

still being gatheredprototyping helps users focus

their thoughts on what they really want or need

Rapid prototyping allows the developers of the system

to discover how feasible the final system is likely to be

and make any necessary adjustments to resources oreven to scrap a project is it looks unworkable.


22/36

Fundamen


yEngineers



Prototype Modify the prototype in successive

iterations

Modules should not be highly interdependentso that modifications can be made in a stand-alone manner

It is usual to make the modifications in a very

short time spanoften just a day or twoinorder to keep up the momentum and not toallow users requirements to change due toelapsed time

s


23/36

Fundamen


yEngineers



Prototype Stress on the user interface as an

essential part of the prototyping

Obtaining user feedback is the key idea behindprototyping

For many users the interface is the only part ofthe system they understand

Hence, it is important that users are able tointeract easily with the interfacethe interfaceshould be such that users will need a minimumamount of training

s


24/36

Fundamen


yEngineers



Prototype Stress on the user interface as an

essential part of prototyping (contd)

A 3 day training course for each prototype willdefeat the purpose of prototyping

Interface intricacies may need to be ignored or

at least streamlined until the user can interacteasily

s


25/36

Fundamen


yEngineers


Spiral Model

Attempts to capture the best features ofclassical life cycle and prototyping

Incorporates a new elementrisk analysis Works by iteration around (the spiral, from

center and outwards) four main activities:planning, risk analysis, engineering andcustomer evaluation

Go, no-go decision made at each iteration

s


26/36

Fundamen


yEngineers


Spiral Model

Classic life-cycle or prototyping approaches

can be used in the engineering quadrant

The number of development activities at theengineering quadrant increases at each

outward iteration

s


27/36

Fundamen


yEngineers


Spiral Model

er r

r t u e nsdoc e t

Requreme tsdocumntandvalidaionreort

t

START

Go-nogo decision

Engineering

Risk AnalysisPlanning

Customer Evaluation

Towards a completed system

Initial software prototype

Next level prototype

Engineered system

RA based on customer

reaction

RA based on initial

requirements

Initial requirements

gathering & project

planning

Planning based on

customer comments

Customer evaluation

s


28/36

Fundamen


yEngineers


Advantages of the Spiral Model

Evolutionary approach allows for developer andcustomer to understand and react to risks at eachevolutionary level.

Prototyping can be applied as a risk-reductionmechanism at each evolution.

Maintains the systematic stepwise approach(classic life cycle) while incorporating an iterative

framework that reflects the real world Demands consideration of technical risk at eachevolutionhence reducing risks before theybecome problematic.

s


29/36

Fundamen


yEngineers


Weaknesses of the Spiral Model

May be difficult to control its evolutionary

nature (particularly in contract situations)

Demands considerable risk assessmentexpertise and relies on this expertise for

success

Not as commonly used as classic life cycleand prototyping

s


30/36

Fundamen


yEngineers


Questions

Prototyping replaces the usual software life

cycle and results in a better product in a

shorter period of time. Discuss

rs


31/36

Fundamen


yEngineers


Questions

What are the differences between a

prototype and the actual product

rs


32/36

Fundamen


yEngineers


Basic Planning

Systematization Plan

Project Planning

Requirements Specification

rs


33/36

Fundamen


yEngineers


Project Planning Activities

Define project deliverables

defined by contract or agreed with client/user

specified by methodology

internal deliverables

deliverables from subcontractors/vendors

rs


34/36

Fundamen


yEngineers



Develop the work breakdown structure

a list of tasks that need to be performed to achieve theproject objectives and deliverables

basis for project estimation and scheduling allow for hidden activities

Examples: Briefings, project meetings and productionof minutes, reviews, re-working, management andadministration

failure to identify all activities is a major cause ofproject slippage

rs


35/36

Fundamen


yEngineers



Identify staffing and other resources (resource

allocation)

identify skills and roles required to carry out activities

match staff to roles and assess staff availability

identify required development and test environment

identify supporting facilities (eg. administrative support,

project office)

rs


36/36

Fundamen


yEngineers


Determine project structure / organization

Estimate effort required to complete tasks

A estimate is the quantification of the effort or duration

required to accomplish the tasks identified in the workbreakdown structure

Identify dependencies and establish a schedule ofproject activities

Estimate project costs

Identify and evaluate risks

32 Systemdevelopment Methodologies 101107012049 Phpapp02

Documents

Transcript of 32 Systemdevelopment Methodologies 101107012049 Phpapp02