Structured design Waterfall development Parallel development Rapid Application development Phased development Prototyping Throwaway prototyping Agile Development Extreme Programming XP Waterfall Development ID: 603162
Download Presentation The PPT/PDF document "System development methodologies" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
System development methodologies
Structured design
Waterfall development
Parallel development
Rapid Application development
Phased development
Prototyping
Throwaway prototyping
Agile Development
Extreme Programming (XP)Slide2
Waterfall Development
PLANNING
ANALYSIS
DESIGN
IMPLEMENTATION
SYSTEMSlide3
Waterfall Development
Disadvantages:
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 requirementsSlide4
Parallel Development
PLANNING
ANALYSIS
OVERALL
DESIGN
OVERALL
IMPLEMENTATION
SYSTEM
SUBDESIGN
SUBDESIGN
SUBDESIGN
SUBIMPLEMENT
SUBIMPLEMENT
SUBIMPLEMENTSlide5
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
Disadvantages
Same as for waterfall plus:
Subsystems are not usually independent so changes in one subsystem can affect others
Additional work to coordinate and integrate subsystemsSlide6
Phased Development
PLANNING
OVERALL
ANALYSIS
SYSTEM
VERSION 1
V1 DESIGN
V1 IMPLEMENT
V1 ANALYSIS
SYSTEM
VERSION 2
V2 DESIGN
V2 IMPLEMENT
V2 ANALYSIS
SYSTEM
VERSION 3
V3 DESIGN
V3 IMPLEMENT
V3 ANALYSISSlide7
Phased Development
Advantages
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
Slide8
Prototyping
PLANNING
SYSTEM
PROTOTYPE
IMPLEMENTATION
SYSTEM
IMPLEMENTATION
DESIGN
ANALYSISSlide9
Prototyping
Advantages
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 beginningSlide10
Throwaway Prototyping
PLANNING
DESIGN
PROTOTYPE
IMPLEMENTATION
SYSTEM
IMPLEMENTATION
DESIGN
ANALYSIS
ANALYSIS
DESIGNSlide11
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 systemSlide12
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 completeGeneral principles:
Superficial planning processContinuous, automated testing (every day)Continuous integrationHeavy user involvement
Pair programmingSpecific attention to human interactions and limitationsSlide13
Extreme Programming
PLANNING
ANALYSIS
DESIGN
IMPLEMENTATION
SYSTEMSlide14
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 inputSlide15
Selecting a Methodology
Depends on:
Clarity of user requirements
Familiarity with technology
System complexity
System reliability requirementsTime available
Visibility of risk factorsSlide16
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
MethodsSlide17
Selecting a Methodology
Use a little
‘
common sense
’
What is critical? Enron Arthur Andersen & Co., LLP
WorldCom NortelSlide18
Selecting a Methodology
Requirements Clarity
Technology Familiarity
System Complexity
Reliability Concerns
Time SchedulesSchedule Visibility (Murphy’s Law)Slide19
Project Management
A
‘
hot
’
skillProject Management Tasks: identifying project size create and manage work plan
staff the project control and direct the projectSlide20
Managing a Info. Sys. Project
Four Phases
:
Initiating
Planning
Executing
Closing Slide21
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 thirdSlide22
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 creepSlide23
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 resourcesFailure to adapt to business changeFailure to stick with the plan
Failure to monitor the planSlide24
Creating a Work Plan
Identify Tasks
Estimate Completion Times
Create Deliverable Timetable
Suggest MilestonesSlide25
Project Parameters
From clear objectives, identify high level tasks
Milestones MUST be identified in advance
Recognize that historical time estimates have been poor (222%)Slide26
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 consultantSlide27
Statement of Work
I. Purpose
II. Background
A. Problem, opportunity, or directive statement
B. History leading to project request
C. Project goal and objectives D. Product description
III. Scope
A. Stakeholders B. Data
C. Processes D. LocationsIV. Project Approach A. Route B. Deliverables
V. Managerial Approach A. Team building considerations B. Manager and experience C. Training requirements
(continued)Slide28
Statement of Work (concluded)
V. Managerial Approach (continued)
D. Meeting schedules
E. Reporting methods and frequency
F. Conflict management
G. Scope management
VI. Constraints
A. Start date B. Deadlines
C. Budget D. Technology
VII. Ballpark Estimates A. Schedule B. BudgetVIII. Conditions of Satisfaction
A. Success criteria B. Assumptions C. RisksIX. AppendicesSlide29
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)Slide30
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)Slide31
Estimating Time and Effort
Effort: convert from lines of code to person-months (i.e. COCOMO estimates)
Time: schedule time converted from person-monthsSlide32
A Notable Technique:
‘
Timeboxing
’
Develop a
‘hard’
end dateSystem delivered on time in whatever state can be achievedPopular with software production Something is delivered in the
‘timebox’Slide33
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 statusSlide34
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 sequenceSlide35
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) Slide36
A Gantt ChartSlide37
Gantt Chart showing Progress on Activities versus Planned DurationsSlide38
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)Slide39
A PERT ChartSlide40
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 expertiseRe-use components
Define and use metricsInstitute version control