1
IS Theories & Practices
System Development Process &
Project Management
IS 655: Note 5
CSUN Information Systems
IS 655 : Note 5 2
Process vs. Project Management
Process Management is an ongoing activity that documents, manages the use of, and improves an organization’s chosen methodology (the “process”) for system development. Process management is concerned with the activities, deliverables, and quality standards to be applied to all projects.
Project Management is the process of scoping, planning, staffing, organizing, directing, and controlling the development of an acceptable system at a minimum cost within a specified time frame.
IS 655 : Note 5 3
System Development Methodologies
Architected Rapid Application Development (Architected RAD)
Dynamic Systems Development Methodology (DSDM)
Joint Application Development (JAD) Information Engineering (IE) Rapid Application Development (RAD) Rational Unified Process (RUP) Structured Analysis and Design eXtreme Programming (XP)
IS 655 : Note 5 4
System Building Blocks
IS 655 : Note 5 5
1. Scope Definition
• Purpose: define perceived problems, opportunities, and directives (POD); assess the risk of project; establish scope, preliminary requirements and constraints, participants, budget and schedule (preliminary study)
• Issues: Is the project worthwhile? (using PIECES framework) Define the scope of project
• Deliverable: Project charter/plan
•Feasibility check: Cancel project / Approve to continue / Reduce or expanse the scope with budget and schedule modification
IS 655 : Note 5 6
PIECES Framework for Systems Improvement
P the need to improve performance
I the need to improve information (and data)
E the need to improve economics, control costs, or
increase profits
C the need to improve control or security
E the need to improve efficiency of people and processes
S the need to improve service to customers, suppliers, partners, employees, etc.
IS 655 : Note 5 7
2. Problem Analysis
• Purpose: to study and analyze the existing system from the users’ perspectives as they see Data, Processes, and Interfaces
• Issue: Cost/benefits of building new system to solve these problems
• Deliverable: system improvement objectives (business criteria to evaluate the new system)
• Feasibility check: Cancel project / Approve to continue / Reduce or expanse the scope with budget and schedule modification
IS 655 : Note 5 8
3. Requirement Analysis
• Purpose: discover users’ needs or expectations out of the new system in terms of Data, Processes, and Interfaces
• Issue: Specify requirements for the new system (WHAT TO BE DONE) without prematurely expressing technical details (HOW)
• Errors and omissions in requirement analysis result in user dissatisfaction of final system and costly modifications
• Deliverable: business requirements statement
IS 655 : Note 5 9
4. Logical Design• Purpose: translating business user requirements into a system model that depicts only WHAT TO DO without specifying any possible technical design or implementation of those requirements (conceptual design). • Issue: using graphical model of a system to represent user requirements in terms of Data, Processes and Interfaces, and to facilitate improved communication between system stakeholders.•Caution: Analysis paralysis – excessive system modeling dramatically slows progress toward implementation of the intended system solution.•Deliverable: Logical Systems Models (DFD, ERD etc)
IS 655 : Note 5 10
5. Decision Analysis
• Purpose: identify all candidate solutions, analyze the feasibility of each candidate, recommend a candidate system as the target solution
• Issue: Feasibility analysis in terms of technical, operational, economic, schedule (TOES), and risk
•Deliverable: approved system proposal
•Feasibility check: Cancel project / Approve system proposal with budget and schedule modification / Reduce the scope of proposed solution with budget and schedule modification
IS 655 : Note 5 11
Decision Analysis
Candidate solutions evaluated in terms of TOES and Risks:– Technical feasibility – Is the solution technically practical? Does
our staff have the technical expertise to design and build this solution?
– Operational feasibility – Will the solution fulfill the users’ requirements? To what degree? How will the solution change the users’ work environment? How do users feel about such a solution?
– Economic feasibility – Is the solution cost-effective?
– Schedule feasibility – Can the solution be designed and implemented within an acceptable time?
– Risk feasibility – What is the probability of a successful implementation using the technology and approach? (Risk Management)
IS 655 : Note 5 12
6. Physical Design• Purpose: to transform business requirements into technical design specifications for construction
• Issue: HOW technology will be used to build the system in terms of Data, Processes, and Interfaces
• Design by Specifications vs. Design by Prototyping
• Deliverable: System design specifications (blueprints)
•Feasibility check: Continue/ Reduce or expanse the scope with budget and schedule modification
IS 655 : Note 5 13
7. Construction Phase
• Purpose: to build and test a system that fulfill business requirements and design specs; implement interfaces between new and existing systems
• Issue: Construct database, application programs, user/system interfaces, implement purchased or leased software
• Deliverable: proposed system within budget and schedule
IS 655 : Note 5 14
8. Implementation Phase
• Purpose: deliver the production system into operation
• Issue: Train users, write manuals, load files, populate database, final test
• Conversion plan: parallel systems, switch point
• Deliverable: system up and running
IS 655 : Note 5 15
Installation/Conversion Strategies
Abrupt cutover
Parallel conversion
Location (Pilot) conversion
Staged (Phased) conversion
New System
Old system
Old System New System
Old System New System
Old System New System
IS 655 : Note 5 16
Installation/Conversion Strategies …
Risk
Cost
AbruptCutover
LocationConversion
StagedConversion
ParallelConversion
IS 655 : Note 5 17
Operation and Support
• Ongoing system support would be provided until the system becomes obsolete and is replaced by a new one
• Issues: technical support for user, fixing bugs, recovering plan, adapt to emerging requirements
• When a system has reached entropy, new project for new system should be initiated
IS 655 : Note 5 18
Summary: Systems Development Process
Scope Definition Phase: What Business Problem Problem Analysis Phase: What System Issues
(Info/Data, Processes, Communications/Interfaces) Requirement Analysis Phase: What User Needs Logical Design: Conceptual Model – What to Do Decision Analysis Phase: What Solution Design Phase: Physical Model: How to Do Construction Phase: Do It Implementation Phase: Use It
IS 655 : Note 5 19
Classic Project Phases
IS 655 : Note 5 20
Model-Driven Development
IS 655 : Note 5 21
Model-Driven Development
Model-driven development – a system development strategy that emphasizes the drawing of system models to help visualize and analyze problems, define business requirements, and design information systems.
– Process Modeling – a process-centered technique popularized by the structured analysis and design methodology used models of business process requirements to derive effective software designs for a system.
– Data Modeling – a data-centered technique to model business data requirements and design appropriate database systems.
– Object Modeling – a technique to merge the data and process concerns into singular constructs called objects. Object models are diagrams that document a system in terms of its objects and their interactions.
IS 655 : Note 5 22
Model-Driven Development …
Advantages:
– Planning ahead
– Extensive modeling current system and requirement analysis
– Analyze many alternative technical solutions
– Suitable for well understood systems
Disadvantages:
– Long duration
– Passive participation of user as they don’t see the product
– Requirements in each phase should be fully addressed: impractical and/or inflexible
IS 655 : Note 5 23
Rapid Application Development
IS 655 : Note 5 24
Rapid Application Development
Rapid application development (RAD) techniques emphasize extensive user involvement in the rapid and evolutionary construction of working prototypes of a system to accelerate the system development process.
RAD is based on building prototypes that evolve into finished systems (often using time boxing)
– A prototype is a smaller-scale, representative or working model of the users’ requirements or a proposed design for an information system.
– A time box is a non-extendable period of time, usually 60-120 days, by which a candidate system must be placed into operation. Improvements will be released in later versions
IS 655 : Note 5 25
Rapid Application Development …
Advantages:
– Handle uncertain or imprecise user requirements
– Active user participation in building physical product: increase enthusiasm, support
– Early detection of errors and omissions: with testing and modifying prototype
– Reduce risk with iterative prototyping Disadvantages:
– Increase lifetime costs to operate, support, and maintain the system (constantly doing and fixing)
– Short problem analysis may result in solving wrong problems
– Discourage an analyst from considering other technical alternatives than the one being used in prototyping
IS 655 : Note 5 26
Hybrid Strategies
IS 655 : Note 5 27
Hybrid: Multiple Implementation
IS 655 : Note 5 28
Hybrid: Staged Implementation
IS 655 : Note 5 29
Measures of Project Success
– The resulting information system is acceptable to the customer.
– The system was delivered “on time.”– The system was delivered “within budget.”– The system development process had a
minimal impact on ongoing business operations.
IS 655 : Note 5 30
Poor Expectations Management
Scope Creep – the unexpected and gradual growth of requirements during an information systems project.
Feature Creep– the uncontrolled addition of technical features to a system.
IS 655 : Note 5 31
Causes of Project Failure Failure to establish upper-management commitment to the project Lack of organization’s commitment to the system development
methodology Taking shortcuts through or around the system development
methodology Poor expectations management Premature commitment to a fixed budget and schedule Poor estimating techniques Overoptimism The mythical man-month (Brooks, 1975) Inadequate people management skills Failure to adapt to business change Insufficient resources Failure to “manage to the plan”
IS 655 : Note 5 32
Inter-task Dependencies
Finish-to-start (FS)—The finish of one task triggers the start of another task.
Start-to-start (SS)—The start of one task triggers the start of another task.
Finish-to-finish (FF)—Two tasks must finish at the same time.
Start-to-finish (SF)—The start of one task signifies the finish of another task.
IS 655 : Note 5 33
Task Splitting & Delaying Critical Path – the sequence of dependent tasks that
determines the earliest possible completion date of the project.
– Tasks that are on the critical path cannot be delayed without delaying the entire project schedule. To achieve resource leveling, critical tasks can only be split.
Slack Time – the amount of delay that can be tolerated between the starting time and completion time of a task without causing a delay in the completion date of the entire project.
– Tasks that have slack time can be delayed to achieve resource leveling
IS 655 : Note 5 34
PERT Chart
5-3-2001 5-12-2001
5-3-2001 5-11-2001
Preliminary Investigation
5-12-2001 6-12-2001
5-12-2001 6-14-2001
Problem Analysis
5-28-2001 7-15-2001
5-30-2001 7-18-2001
Requirements Analysis
6-13-2001 7-30-2001
6-13-2001 8-3-2001
Decision Analysis
9-10-2001 12-14-2001
TBD TBD
Implementation
7-19-2001 11-13-2001
7-20-2001 In Progress
Construction
7-3-2001 9-25-2001
7-5-2001 10-9-2001
Design
5-3-2001 N/A
5-3-2001 N/A
Project Initiation
ScheduledStart
ScheduledFinish
Actual Start ActualFinish
Task
ScheduledStart
ScheduledFinish
Actual Start ActualFinish
Task
intertaskdependency
Legend
IS 655 : Note 5 35
Microsoft Project PERT Chart
IS 655 : Note 5 36
Critical Path
The critical path is highlighted in red
TASK C
Fri 2/9/01 2 days
Fri 2/9/01 0 days
TASK D
Tue 2/20/01 7 days
Tue 2/20/01 0 days
TASK I
Tue 2/27/01 5 days
Tue 2/27/01 0 days
TASK E
Mon 2/19/01 6 days
Tue 2/20/01 1 day
TASK B
Wed 2/7/01 2 days
Wed 2/7/01 0 days
TASK A
Mon 2/5/01 3 days
Mon 2/5/01 0 days
TASK H
Thu 2/15/01 1 day
Tue 2/20/01 3 days
TASK F
Wed 2/14/01 3 days
Fri 2/16/01 2 days
TASK G
Fri 2/16/01 2 days
Tue 2/20/01 2 days
Duration
Slack Time
IS 655 : Note 5 37
Gantt Chart
Incomplete Task
Complete Task
Legend
ID
1
2
3
4
5
6
7
Preliminary investigation
Problem analysis
Requirements analysis
Decision analysis
Design
Construction
Implementation
May Jun Jul Aug Sep Oct Nov Dec
2001Task Name
Today
IS 655 : Note 5 38
Microsoft Project Gantt Chart
IS 655 : Note 5 39
Scheduling Strategies
Forward Scheduling – a project scheduling approach that establishes a project start date and then schedules forward from that date.
Reverse Scheduling – a project scheduling strategy that establishes a project deadline and then schedules backward from that date.
