System Development Life Cycle
1. Planning (Why build the system?)
a. Identifying business value
Technique – System request
Deliverable – System request
b. Analyze feasibility
Technique –
Technical feasibility
Economic feasibility
Organizational feasibility
Deliverable–Feasibility study, System concept
Project Management
c. Develop work plan
Technique –
Task identification
Time estimation
Deliverable – Work plan
d. Staff the project
Technique –
Creating a staffing plan
Creating a project charter
Deliverable – Staffing plan & Project charter
e. Control and direct project
Technique –
Refine estimates
Track tasks
Coordinate project
Manage scope
Mitigate risk
Deliverable– Gantt chart, CASE tool, Standards
list, Project binder/s, Risk assessment
Project plan
2. Analysis (Who, what, when, where will the system
be)
a. Analysis
Technique -
Problem analysis
Benchmarking
Reengineering
Deliverable – Analysis plan
b. Information gathering
Technique -
Interviews
Questionnaires
Deliverable –
Information
c. Process modeling
Technique – Data flow diagramming
Deliverable – Process model
d. Data modeling
Technique – Entity relationship modeling
Deliverable – Data model, System Proposal
3. Design (How will the system work?)
a. Physical design
Technique –
Custom development
Package development
Outsourcing
Deliverable – Design plan
b. Architecture design
Technique – Hardware design
Network design
Deliverable – Architecture design, infrastructure Design
c. Interface design
Technique – Interface structure chart
User interface design
Deliverable – Interface design
d. Database & File design
Technique – Selecting data storage format
Optimizing data storage
Deliverable – Data storage design
e. Program design
Technique – Program structure chart
Program specifications
Deliverable – Program design, System specification
4. Implementation (System delivery)
a. Construction
Technique – Programming, Testing
Deliverable –
documentation
Test
plan,
programs
b. Installation
Technique – Direct conversion
Parallel conversion
Phased conversion
Deliverable – Conversion plan, training plan,
support plan
&
Project Initiation
• The first step in any new development project
– someone sees an opportunity to improve the
business
• New systems originate from some business
need or opportunity
• Many ideas arise from application of new
technology
• But, understanding of technology is secondary
to a sound understanding of the business and
its objectives
• Clear understanding of how the system will
improve the business
• Both IT experts and business experts should
work closely – organizations can leverage the
exciting technologies
• Ultimately, IS needs
organization’s bottom line!
to
affect
the
• Project Initiation begins with someone,
project sponsor, identifies business value in
using IT
• The proposed project is described very briefly
using a technique called the system request
• This is submitted to an approval committee
 IS steering committee, or
 Senior executives, or
 Decision-making body that governs the
use of business investments
• System request is reviewed, decision is made
whether or not, to investigate the proposal
• Next step is the feasibility analysis
• This decides whether to proceed with the IS
development project
• Examines the technical, economic, and
organizational pros and cons of developing the
system
• Provides a slightly more detailed picture of the
advantages of investing in the system as well
as the possible obstacles
• Mostly the project sponsor works with the
analyst team
• On completion of the feasibility analysis, the
system request is revised and submitted along
with the final feasibility study, back to the
approval committee
• The board then decides whether to approve,
decline, or table it with additional information
Identifying Business Value:
System Request:
• Documents the business reasons for building
the system and the value it is expected to
provide
• Typically has four essential components project sponsor, business need, functionality,
and expected value
SYSTEM REQUEST
[Date]
Project Name: [Internet Sales]
Project Sponsor:
Business Need:
Functionality:
Expected Value:
Tangible:
Intangible:
Special Issues or Constraints:
Estimating Expected Value/Revenue:
• Thumb rules – Internet business might end up
generating revenue at least same as that with a
half dozen additional stores
• Comparing with the best in the business – based
on a some percentage of the revenue of the best
player in the business, and some annual growth
rate to predict future sales
• Industry standards – Internet sales is about 20%
of the revenues from the traditional stores
Estimate conservatively from within the range of
figures obtained.
Feasibility Analysis:
• Need for the new system and its basic
functionality has been defined in the system
request
• Create a more detailed business case,
understand opportunities and limitations
associated
• Feasibility analysis guides the organization in
determining whether to proceed with the project
• Three techniques – technical, economic, and
organizational
• Some firms also conduct a formal legal
feasibility to assess conformance with laws
Technical Feasibility:
Can we build it? – Technical Risk analysis
• Familiarity with application –
 Less familiarity generates more risk
 Development of new systems is riskier
than extensions to an existing system
• Familiarity with technology –
 Less familiarity generates more risk
 Risk increases with new technology itself
Contd..
• Project size –
 Large – no. of people in the
development team, or time to complete
the project, or the no. of distinct features
in the system
 Large projects have more risk, because
 More complicated to manage
 Greater chance that some important
system
requirements
will
be
overlooked, or misunderstood
Economic Feasibility:
• Should we build it? – Cost-benefit analysis
o Identify Costs and benefits –
 Development costs
 Development team salary
 Consultant fees
 Development training
 Hardware and Software
 Office space and equipment
o Annual operating costs
 Software upgrades
 Software licensing
 Hardware repairs
 Hardware upgrades
 Operational team salaries
 User training
o Annual benefits
 Cost savings
 Increased revenues
• Intangible costs and benefits
o Assign Values to costs and Benefits –
o Rely on the people who have the best
understanding of the costs and benefits
o consultants
o Past projects
o Industry reports
• Determine Cash Flow –
o Cost-benefit projections over 4 to 5
years
o Assume a rate of growth to adjust for
business improvements
• Determine Return on Investment –
o Consider the time value of money
o Calculate the NPV
Organizational Feasibility:
How well the system will be accepted by its
users and incorporated into the ongoing
operations of the organization.
• Can be the most difficult feasibility dimension
to assess
• Conduct a stakeholder analysis
• Project champion(s)
 High-level non-IS executive, may/may not be
the project sponsor
 Promotes/supports the project
 Communicates the importance of the project
to other organizational decision makers
 More than one champion is preferable
• Organizational management
 Know about the project
 Also needs to support the project
 Encourage people in the organization to use
the system
• System users
 Ultimately determine the success/failure
of the project by using or not using the
system
 Important stakeholders
 User participation should be promoted
throughout the development process
• Other stakeholders
Project Management
Major activities:
• Creating the work plan
• Staffing the project
• Controlling and directing the project
Creating the work plan:
• Dynamic schedule, records and keeps
track of all the tasks that need to be
accomplished over the life of the project
• Lists each task along with the important
info about it
• The level of detail and the amount of info
depends on the needs of the project
• Increases as the project progresses
Work Plan Information
Example
Name of task -
Conduct personal interviews
Start date -
Aug 25, 2006
Completion date -
Aug 29, 2006
Person assigned to the task - Sr. Manager; Sunil Malik
Deliverable(s) -
Top management views
Completion status -
Open
Priority -
High
Resources needed -
Spreadsheet software
Estimates time -
12 hours
Actual time -
14 hours
Two steps in creating work plan:
• Identifying Tasks
 Stepwise refinement
Top down approach
Break high level tasks to subtasks until
desired level of detail is achieved
 Use a methodology
Use a standard list of tasks – template
Books, consultants, web sites, past
projects
• Time estimation
Estimation of time and effort needed to
complete the project
Assign projected values
Estimation software packages – Constar,
Construx, Over 50 available in the market
Start with a range of possible values, 3 – 4
months
Gradually be more specific as the project
progresses
Try for conservative time estimates
The nos. can come several sources:
Experienced developers, consultants
Whether it is manual or automated – estimation
is a tough job as it involves tradeoffs among
three components – size of the system (in
terms of what it does), the time taken, and the
cost.
If time estimate is less than available – two
alternatives – reduce functionality or extend
deadline.
Two basic ways to estimate time:
One – the amount of time spent in the planning
phase is used to predict the time required for
the entire project. Use industry standard
percentages or organization’s own experience.
A typical business application spends 15% of
its efforts in planning, 20% in analysis, 35% in
design, and 30% in implementation phase – in
terms of person months.
Two – more complex, more reliable (hoped) is
a 3 – step process.
• Estimate size of
KLOC/Function Points
the
project
in
• Estimate Efforts in terms of person-months
from the size
• Estimate the schedule time in months from
the effort. No. of persons required is the
total person months divided by the
schedule time
Size in KLOC = (Most optimistic + 4*Most
likely + Most pessimistic)/6
Size in FP = Total Unadjusted FP * Adjusted
Project Complexity
TUFP – computed from no. of inputs, outputs,
queries, files, and program interfaces
PCA – computed from the impact of 14 factors
on the complexity like, data communications,
rate of transaction, end-user efficiency,
complex processing etc.
FP can be converted to LOC depending on the
language of implementation.
C–
130 lines/FP
COBOL – 110 lines/FP
VB –
30 lines/FP
Java –
55 lines/FP
Effort (in person months) = 1.4 *Thousands of
LOC
(A thumb rule for
business software)
small/moderate
sized
Schedule time (months) = 3.0 * personmonths1/3
Historical data or estimation software can be
used
Timeboxing:
• Task-oriented
projects
projects
vs.
time-oriented
• Used in Rapid Application Development
(RAD) methodologies
• Sets a fixed deadline for a project
• Delivers the system by that deadline no
matter what, even if functionality needs to
be reduced
• Ensures that project teams do not get hung
up on the final “finishing touches” that can
drag out indefinitely
• Satisfies the business by providing a product
within a relatively fast time frame
• Deadline should not be impossible to meet
• Build the core of the system to be delivered
• Timeboxing creates a sense of urgency,
helps focus on the most important features
• Functionality that cannot be completed needs
to be postponed
• Prioritized set of functionalities are
implemented
• However, quality cannot be compromised,
regardless of other constraints, e.g., do not
reduce testing time without reducing features
• A high quality system is delivered at the end
• Future iterations will be needed to make
changes and enhancements
• Timeboxing approach may be used once
again!
Staffing the project:
• Means much more than assigning people to
the project
 Matching people’s skills with the needs of
the project
 Motivating them to meet the project’s
objectives, and
 Minimizing the conflict that will occur over
time
• Deliverable – staffing plan delineating
 The people along
reporting structure
with
the
 The project charter, describing the
project’s objectives and rules
overall
• After the estimates are complete, a staffing
plan is created
 Lists the roles required for the project
 The proposed reporting structure
 Project manager oversees the overall
progress of the project
 A functional lead is be assigned to
manage a group of analysts
 A technical lead oversees the progress
of a group of programmers and
technical staff members
 There are many team structures, popular
one is chief programmer team structure
 Next, assignment of persons is done,
one person may fill more than one role
on a project team
 While making assignments, think in
terms
of
‘technical
skills’
and
‘interpersonal skills’
 Interpersonal skills – customers, senior
management, and team members
 Training/mentoring may be required for
both
• Motivation:
 Recognition is a good motivator
 Motivation has a great influence on
performance
 Do/Don’ts
• Assign unrealistic deadlines
• Ignore
good
appreciation
efforts
-
show
• Make decisions without team’s inputs
• Do maintain good working conditions/
environment – working space, lighting,
technology, privacy
• Handling conflict:
 Organize the project to minimize conflict
among group members
 Group cohesiveness contributes more
to productivity than individual capacities
 Define roles clearly
 Hold team members accountable for
their tasks
 Develop a detailed project charter
listing the project’s norms and ground
rules
 When the team should be at work
 When staff meetings will be held
 How group members will communicate
with each other
 Procedure for updating the work plan
as tasks get completed
Staffing Plan:
Role
Description
Assigned To
Project Mgr. -oversees the project,
MoonSwamy
to ensure that it meets
the time and cost req.
Infrastructure - ensures the system
Sobhraj
Analyst
conforms to infrastructure
standards
System analyst -designs the IS-focus on
Bani
interfaces with distribution
system
System analyst - designs the IS-focus on
the process models &
interface design
Bala
System analyst - designs the IS-focus on
Raju
data models & system
performance
Programmer
coding
Joy
Programmer
coding
Toy
Project Charter:
Project objective: The project team will create
a working Web-based system to sell CDs to
customers.
The Internet sales system team members will
• Attend a staff meeting each Friday at
2.00pm to report on the status of
assigned tasks.
• Update the work plan with actual data
each Friday at 5.00pm.
• Discuss all the problems with Moonswamy
as soon as they are detected.
• Agree to support each other when help is
needed, especially for tasks that could
hold back the progress of the project.
• Post important changes to the project on
the team bulletin board as they are made
Controlling and directing the project:
• Final step of project management
• Continues until the final product is delivered
to the project sponsor and the users
• Includes – refining original project estimates,
tracking
tasks,
encouraging
efficient
development practices, managing scope,
and mitigating risk
• These activities ensure that the project stays
on track, and chances of failure is kept at a
minimum
•Refining estimates:
 Follows a cyclone/hurricane model
 Better predictions are made after tracking
the cyclones for some time
 Accurate predictions as they approach a
coast
 According to one leading expert Barry W.
Boehm
 A well-done project plan has a 100%
margin of error for project cost, and
 A 25% margin of error for schedule time
Margins of error for well-done estimates:
Phase
Deliverable
Cost(%)
Time(%)
Planning
System request
400
60
Project plan
100
25
Analysis
System proposal
50
15
Design
System specification
25
10
Possible actions when a schedule date is
missed:
• If you assume rest of the project is simpler than
the part that was late, and is also simpler than
believed when the original estimates were
made, do not change schedule – high risk
• If you assume rest of the project is simpler than
the part that was late, and is no more complex
than the original estimate, increase the total
schedule by the amount of time you are behind
– moderate risk
• If you assume that the rest of the project is as
complex as the part that was late, then increase
the entire schedule by the percentage of weeks
that you are behind – low risk
Tracking tasks:
• Work plans are updated with actual numbers
regularly
• Shared with every team member
• Better tracking helps in better staffing decisions,
predicting deadlines, calculate costs accurately, and
understanding of the progress of the project
• Scrutinize the work plan regularly for potential
issues – delays, resources
• Tasks may be interrelated, or may overlap
• Develop the work plan graphically – Gantt chart
• Tasks and time are plotted along y- and x-axes
• Shading indicated completion of tasks
Coordinating Project Activities:
Three techniques are commonly used to help
coordinate.
• CASE tools:
 Automates all or part of the development
process
 Upper CASE tools – used in analysis and
design phase
 Lower CASE – used in generating code
 Integrated CASE – contains functionality of
both
 Visible Analyst Workbench, Oracle Designer,
Rational Rose, Logic Works suite
• Standards:
 With many people things can get messy and
confusing
 Create standards that the project team must
follow
 Task coordination becomes simple
 Standards work best if created at the beginning
of each major phase of the project, and
communicated well
 Some standards are applied for the entire SDLC
e.g., file naming conventions, status reporting,
documentation, procedural standards etc.
 Others will be applied as appropriate e.g., coding
standards and guidelines, User interface design
standards etc.
• Documentation:
 A
final
technique
documentation
applied
is
good
 Includes detailed info about the tasks of the
SDLC
 The documentation
binder(s)
is
stored
in
project
 Binders contain all the deliverables and all the
internal communication that takes place – the
history of the project
 Never wait till the last minute to create
documentation
 Document the system’s history as it evolves
 Include dividers to separate content according
to major phases, internal communication
 Takes time up front, but pays off in the long run
Managing Scope:
• Follow the steps for good project management –
stay on schedule, no schedule or cost overruns
• Scope creep – occurs when new requirements are
added to the project after the original scope was
defined and “frozen”!
• Many reasons
 Users suddenly understand the potential of the
new system and realize new, useful
functionality/ies
 Developers discover interesting capabilities, to
which they become attached
 A Sr. Mgr. may wish to let the new system
support a new strategy developed at a recent
board meeting
•
Addressing changes is increasingly difficult after
the project begins - focus is removed from
original goals
•
Impact on cost and schedule
•
Project manager’s role is critical to keep scope
creep to a minimum
•
The key is to identify the requirements as
completely as possible early
•
Use of prototyping and presentations/meetings
– reduces scope creep to less than 5%
• Allow
only
requirements
absolutely
necessary
• Assess the ramifications – project team
members, deadline may be offset
• Track the implementation of change so
that an audit trail exists to measure the
change’s impact
• Sometimes, additions are recorded as
future enhancements
Managing Risk:
• Final facet of project management
• Assessment of risk and addressing the
risks
• Many causes – weak personnel, scope
creep, poor design, too optimistic estimates
• Risk assessment document tracks potential
risks
 Likelihood of risk
 Potential impact
 Addressing the risk
• Assess the root cause/s
• Prioritize risks
• List of risk changes – as some are removed
others surface
• Good project managers work hard to keep
risks from having an impact on the schedule
and costs