1. System development methodologies
Structured design
Waterfall development
Parallel development
Rapid Application development
Phased development
Prototyping
Throwaway prototyping
Agile Development
Extreme Programming (XP)

2. Waterfall Development
PLANNING
ANALYSIS
DESIGN
IMPLEMENTATION
SYSTEM

3. Waterfall Development
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
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

4. Parallel Development SYSTEM PLANNING ANALYSIS SUBDESIGN OVERALL DESIGN
IMPLEMENTATION
SYSTEM
SUBDESIGN
SUBIMPLEMENT

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

6. Phased Development SYSTEM VERSION 1 VERSION 2 VERSION 3 PLANNING
OVERALL
ANALYSIS
SYSTEM
VERSION 1
V1 DESIGN
V1 IMPLEMENT
V1 ANALYSIS
VERSION 2
V2 DESIGN
V2 IMPLEMENT
V2 ANALYSIS
VERSION 3
V3 DESIGN
V3 IMPLEMENT
V3 ANALYSIS

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

8. Prototyping
PLANNING
SYSTEM
PROTOTYPE
IMPLEMENTATION
DESIGN
ANALYSIS

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

10. Throwaway Prototyping
PLANNING
DESIGN
PROTOTYPE
IMPLEMENTATION
SYSTEM
ANALYSIS

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

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

13. Extreme Programming
PLANNING
ANALYSIS
SYSTEM
DESIGN
IMPLEMENTATION

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

15. Selecting a Methodology
Depends on:
Clarity of user requirements
Familiarity with technology
System complexity
System reliability requirements
Time available
Visibility of risk factors

16. Selecting a Methodology
Agile
Methods
Structured
Methodologies
RAD Methodologies
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

17. Selecting a Methodology
Use a little ‘common sense’
What is critical?
Enron
Arthur Andersen & Co., LLP
WorldCom
Nortel

18. Selecting a Methodology
Requirements Clarity
Technology Familiarity
System Complexity
Reliability Concerns
Time Schedules
Schedule Visibility (Murphy’s Law)

19. Project Management A ‘hot’ skill Project Management Tasks:
identifying project size
create and manage work plan
staff the project
control and direct the project

20. Managing a Info. Sys. Project
Business Administration Lecture 1 Notes
Four Phases:
Initiating
Planning
Executing
Closing
Drew Parker September 1999 2

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

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

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

24. Creating a Work Plan Identify Tasks Estimate Completion Times
Create Deliverable Timetable
Suggest Milestones

25. Project Parameters From clear objectives, identify high level tasks
Milestones MUST be identified in advance
Recognize that historical time estimates have been poor (222%)

26. Negotiating scope Scope: Deliverable – a statement of work
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

27. Statement of Work I. Purpose II. Background III. Scope
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. Locations
IV. Project Approach
A. Route
B. Deliverables
V. Managerial Approach
A. Team building considerations
B. Manager and experience
C. Training requirements
(continued)

28. 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. Budget
VIII. Conditions of Satisfaction
A. Success criteria
B. Assumptions
C. Risks
IX. Appendices

29. Estimating Project Size
Business Administration Lecture 1 Notes
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)
Drew Parker September 1999

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

31. Estimating Time and Effort
Business Administration Lecture 1 Notes
Estimating Time and Effort
Effort: convert from lines of code to person-months (i.e. COCOMO estimates)
Time: schedule time converted from person-months
Drew Parker September 1999

32. A Notable Technique: ‘Timeboxing’
Business Administration Lecture 1 Notes
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’
Drew Parker September 1999

33. Business Administration 362 1999-3 Lecture 1 Notes
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
Drew Parker September 1999 6

34. Techniques: Representing and Scheduling Projects
Business Administration Lecture 1 Notes
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
Drew Parker September 1999 8

35. Business Administration 362 1999-3 Lecture 1 Notes
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)
Drew Parker September 1999

36. A Gantt Chart

37. Gantt Chart showing Progress on Activities versus Planned Durations

38. Business Administration 362 1999-3 Lecture 1 Notes
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)
Drew Parker September 1999

39. A PERT Chart

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