System development methodologies

• Structured designWaterfall developmentParallel development

• Rapid Application developmentPhased developmentPrototypingThrowaway prototyping

• Agile DevelopmentExtreme Programming (XP)

Waterfall Development

PLANNING

ANALYSIS

DESIGN

IMPLEMENTATION

SYSTEM

Waterfall DevelopmentDisadvantages:

Design must be completely specified on paper before programming begins

Use of paper specifications can result in misunderstanding of user requirements

Complex and lengthy – large amount of time elapses between analysis and delivery of the system – user needs may change

Advantages:

System requirements identified long before programming begins

Large degree of management control promotes documentation and ensures ability to trace user requirements thus minimizing changes to requirements

Parallel Development

PLANNING

ANALYSIS

OVERALLDESIGN

OVERALLIMPLEMENTATION

SYSTEM

SUBDESIGN

SUBDESIGN

SUBDESIGN

SUBIMPLEMENT

SUBIMPLEMENT

SUBIMPLEMENT

Parallel Development

Advantages

Same as for waterfall development plus:

Time is reduced compared to the waterfall method which decreases the chances that user needs will change before the system is implemented

DisadvantagesSame as for waterfall plus:

Subsystems are not usually independent so changes in one subsystem can affect others

Additional work to coordinate and integrate subsystems

Phased Development

PLANNING

OVERALLANALYSIS

SYSTEMVERSION 1

V1 DESIGN

V1 IMPLEMENT

V1 ANALYSIS

SYSTEMVERSION 2

V2 DESIGN

V2 IMPLEMENT

V2 ANALYSIS

SYSTEMVERSION 3

V3 DESIGN

V3 IMPLEMENT

V3 ANALYSIS

Phased DevelopmentAdvantages

Quickly gets a useful version into the hands of the users

System provides business value sooner compared to structured methodologies

Users able to provide feedback and discover important new requirements sooner

Disadvantages

User begins to work on a system that is intentionally incomplete

Problems with success and acceptance of the system can occur if the essential features are not identified for the first version.

Must manage user expectations in terms of having to wait for features that will be implemented in subsequent versions

Prototyping

PLANNING

SYSTEMPROTOTYPE

IMPLEMENTATION

SYSTEM

IMPLEMENTATION

DESIGN

ANALYSIS

PrototypingAdvantages

Provides users with a system to interact with very quickly

Reassures users that the project is indeed progressing towards a finished system

Helps to refine requirements more quickly – users can interact with the prototype and better understand what it can and cannot do easier than if the system were on paper.

Disadvantages

Fast pace makes it more difficult to conduct a thorough analysis

Initial prototype could lead you down an ineffective path and once started, it is difficult to go back to the beginning

Throwaway Prototyping

PLANNING

DESIGNPROTOTYPE

IMPLEMENTATION

SYSTEM

IMPLEMENTATION

DESIGN

ANALYSIS

ANALYSIS

DESIGN

Throwaway Prototyping

Advantages

Combines complete analysis and design with advantages of prototyping to refine key issues before that system is built

Tends to produce more stable and reliable systems than prototyping.

Disadvantages

Slower than prototyping since the design prototypes are thrown away and do not become part of the final system

Extreme Programming (XP)

• A team of users and developers document “user stories”• Users describe user acceptance tests which will demonstrate that

the system provides the required functionality once it is completed

• Developers then plan a series of releases – no release to take more than a couple of months to complete

• General principles:– Superficial planning process– Continuous, automated testing (every day)– Continuous integration– Heavy user involvement– Pair programming– Specific attention to human interactions and limitations

Extreme Programming

PLANNING

ANALYSIS

DESIGN

IMPLEMENTATION

SYSTEM

Extreme Programming

Advantages

Fast delivery of results

Works well in projects with undefined or changing requirements

Disadvantages

Requires discipline

Works best in small projects

Requires much user input

Selecting a Methodology

Depends on:• Clarity of user requirements• Familiarity with technology• System complexity• System reliability requirements• Time available• Visibility of risk factors

Selecting a Methodology

Ability to Develop Systems Waterfall Parallel Phased Prototyping Throwaway XP

With unclear user requirements Poor Poor Good Excellent Excellent Excellent

With unfamiliar technologies Poor Poor Good Poor Excellent Poor

That are complex Good Good Good Poor Excellent Poor

That are reliable Good Good Good Poor Excellent Good

With a short time schedule Poor Good Excellent Excellent Good Excellent

With schedule visibility Poor Poor Excellent Excellent Good Good

Structured Methodologies

RAD Methodologies

Agile

Methods

Selecting a Methodology

• Use a little ‘common sense’– What is critical?

• Enron• Arthur Andersen &

Co., LLP• WorldCom• Nortel

Selecting a Methodology

• Requirements Clarity• Technology Familiarity• System Complexity• Reliability Concerns• Time Schedules• Schedule Visibility (Murphy’s Law)

Project Management• A ‘hot’ skill• Project Management Tasks:

– identifying project size– create and manage work plan– staff the project– control and direct the project

Managing a Info. Sys. Project

Four Phases:• Initiating• Planning• Executing• Closing

Three Attributes of an IT Project

• System Quality and Functionality• Development Speed• Development Cost

The contemporary thinking is that the Project Sponsor gets to pick two, the Project Manager controls the third

Some typical causes of project failure

• Not enough commitment from senior management• Not enough commitment to following an appropriate

system development methodology - taking shortcuts• Not managing expectations well enough

– scope creep– feature creep

More causes of project failure

• Poor estimating techniques• Over optimism• Mythical man-month• Inadequate people management skills• A weak or problematic project team• Insufficient or inappropriate resources• Failure to adapt to business change• Failure to stick with the plan• Failure to monitor the plan

Creating a Work Plan

• Identify Tasks• Estimate Completion Times• Create Deliverable Timetable

– Suggest Milestones

Project Parameters

• From clear objectives, identify high level tasks• Milestones MUST be identified in advance• Recognize that historical time estimates have

been poor (222%)

Negotiating scope

• Scope: – Defined in terms of features (size), quality, time, cost, and

resources– Also defined in terms of processes, data and stakeholders

• Deliverable – a statement of work– May be much more than a section of the system proposal,

particularly if it forms the basis for a contract with a consultant

Statement of WorkI. PurposeII. Background

A. Problem, opportunity, or directive statementB. History leading to project requestC. Project goal and objectivesD. Product description

III.ScopeA. StakeholdersB. DataC. ProcessesD. Locations

IV. Project ApproachA. RouteB. Deliverables

V. Managerial ApproachA. Team building considerationsB. Manager and experienceC. Training requirements

(continued)

Statement of Work (concluded)

V. Managerial Approach (continued)D. Meeting schedulesE. Reporting methods and frequencyF. Conflict managementG. Scope management

VI.ConstraintsA. Start dateB. DeadlinesC. BudgetD. Technology

VII. Ballpark EstimatesA. ScheduleB. Budget

VIII. Conditions of SatisfactionA. Success criteriaB. AssumptionsC. Risks

IX.Appendices

Estimating Project Size

• Expert Opinion goes a long way– Consultants tend to have a proprietary application

for this– a significant expertise to bring to a project

• Can use historical data (if it exists)• Algorithmic Models Exist (COCOMO)

Estimating Project Size

• An example: IBM’s Function Point Approach– Calculate inputs, outputs, queries, files and

interfaces– determine complexity of each, and factor it to

determine overall project size– convert to lines of code (based on a standard)

Estimating Time and Effort

• Effort: convert from lines of code to person-months (i.e. COCOMO estimates)

• Time: schedule time converted from person-months

A Notable Technique: ‘Timeboxing’

• Develop a ‘hard’ end date• System delivered on time in whatever state can

be achieved• Popular with software production

– Something is delivered in the ‘timebox’

Executing the Project

• executing the baseline plan by:– selecting/training/managing the people on the project– getting resources

• e.g. space, computers

• monitoring progress and adjusting the plan• manage changes to the statement of work• maintain project workbook • communicate the project status

Techniques: Representing and Scheduling Projects

• Several Methods– pen and paper– GANTT chart– PERT charts: arrows and nodes, critical path

• in all cases– determine tasks– determine times– determine sequence

Gantt Chart

• Graphical representation of project showing each task activity as a horizontal bar

• length of horizontal bar represents time to completion• visual display of the duration of activities in the

project• estimated and actual times can be displayed• most useful for small projects or sub projects (due to

number of activities)

A Gantt Chart

Gantt Chart showing Progress on Activities versus Planned Durations

PERT Chart

• PERT (Program Evaluation and Review)• graphic representation of task activities and their

inter-relationship• the ordering of the activities is shown by connecting

activities with arrows• the arrows indicate the sequence of activities• two arrows emerging from one activity indicate the

new activities can be accomplished in parallel ( at the same time)

A PERT Chart

Useful risk reduction practices

• Prepare 3 estimates – worst, best and estimated, and compare to actuals

• Use standard notations and methodologies• Use CASE and other automated project management and

control tools• Practice iterative development and “time boxing”• Use a formal change-request process• Create “Centers of Excellence” or specific expertise• Re-use components• Define and use metrics• Institute version control