Transcript Document 7131553

CSUN Information Systems
IS Theories & Practices
IS 655:
Supplementary
Note 2
System Development
Process &
Project Management
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.
2
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)
3
System Building Blocks
4
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
5
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.
6
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
7
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
8
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)
9
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
10
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)
11
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
12
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
13
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
14
Installation/Conversion
Strategies
 Abrupt cutover
Old System
New System
 Parallel conversion
Old system
New System
 Location (Pilot) conversion
Old System
New System
 Staged (Phased) conversion
Old System
New System
15
Installation/Conversion
Strategies …
Abrupt
Cutover
R
i
s
k
Location
Staged
Conversion Conversion
Parallel
Conversion
Cost
16
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
17
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
18
Classic Project Phases
19
Model-Driven
Development
20
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.
21
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
22
Rapid Application
Development
23
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
24
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
25
Hybrid Strategies
26
Hybrid: Multiple
Implementation
27
Hybrid: Staged
Implementation
28
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.
29
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.
30
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”
31
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.
32
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
33
PERT Chart
Project Initiation
5-3-2001
N/A
5-3-2001
N/A
Legend
Task
Scheduled Scheduled
Start
Finish
Actual
Actual Start
Finish
Preliminary Investigation
5-3-2001
5-12-2001
5-3-2001
5-11-2001
Problem Analysis
Task
Requirements Analysis
intertask
dependency
Scheduled Scheduled
Start
Finish
Actual
Actual Start
Finish
Decision Analysis
5-12-2001
6-12-2001
5-28-2001
7-15-2001
6-13-2001
7-30-2001
5-12-2001
6-14-2001
5-30-2001
7-18-2001
6-13-2001
8-3-2001
Design
Construction
7-3-2001
9-25-2001
7-19-2001
11-13-2001
7-5-2001
10-9-2001
7-20-2001
In Progress
Implementation
9-10-2001
12-14-2001
TBD
TBD
34
Microsoft Project
PERT Chart
35
Critical Path
TASK D
Duration
Tue 2/20/01 7 days
Tue 2/20/01 0 days
TASK A
TASK B
TASK C
TASK E
TASK I
Mon 2/5/01
3 days
Wed 2/7/01
2 days
Fri 2/9/01
2 days
Mon 2/19/01 6 days
Tue 2/27/01 5 days
Mon 2/5/01
0 days
Wed 2/7/01
0 days
Fri 2/9/01
0 days
Tue 2/20/01 1 day
Tue 2/27/01 0 days
TASK F
The critical
path is
highlighted
in red
TASK G
Wed 2/14/01 3 days
Fri 2/16/01
Fri 2/16/01
Tue 2/20/01 2 days
2 days
2 days
Slack Time
TASK H
Thu 2/15/01 1 day
Tue 2/20/01 3 days
36
Gantt Chart
ID
Task Name
2001
May
1
Preliminary investigation
2
Problem analysis
3
Requirements analysis
4
Decision analysis
5
Design
6
Construction
7
Implementation
Jun
Jul
Aug
Sep
Oct
Nov
Dec
Today
Complete Task
Legend
Incomplete Task
37
Microsoft Project
Gantt Chart
38
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.
39