System Development Life Cycle

1
System Development Life Cycle

• Planning (Why build the system?)
• Identifying business value
• Technique System request
• Deliverable System request

2

• Analyze feasibility
• Technique Technical feasibility
• Economic feasibility
• Organizational feasibility
• DeliverableFeasibility study, System concept

3

• Project Management
• Develop work plan
• Technique Task identification
• Time estimation
• Deliverable Work plan
• Staff the project
• Technique Creating a staffing plan
• Creating a project charter
• Deliverable Staffing plan Project charter

4

• 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

5

• Analysis (Who, what, when, where will the system
  be)
•  Analysis
• Technique - Problem analysis
• Benchmarking
• Reengineering
• Deliverable Analysis plan
• Information gathering
• Technique - Interviews
• Questionnaires
• Deliverable Information

6

• Process modeling
• Technique Data flow diagramming
• Deliverable Process model
• Data modeling
• Technique Entity relationship modeling
• Deliverable Data model, System Proposal

7

• Design (How will the system work?)
• Physical design
• Technique Custom development
• Package development
• Outsourcing
• Deliverable Design plan
• Architecture design
• Technique Hardware design
• Network design
• Deliverable Architecture design, infrastructure
  Design

8

• Interface design
• Technique Interface structure chart
• User interface design
• Deliverable Interface design
• Database File design
• Technique Selecting data storage format
• Optimizing data storage
• Deliverable Data storage design
• Program design
• Technique Program structure chart
• Program specifications
• Deliverable Program design, System
  specification

9

• Implementation (System delivery)
• Construction
• Technique Programming, Testing
• Deliverable Test plan, programs
  documentation
• Installation
• Technique Direct conversion
• Parallel conversion
• Phased conversion
• Deliverable Conversion plan, training plan,
• support plan

10
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

11

• 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 to affect the organizations
  bottom line!
• 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

12

• 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

13

• 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

14

• 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

15
SYSTEM REQUEST
Date   Project Name Internet Sales   Project
Sponsor   Business Need   Functionality   Expec
ted Value Tangible   Intangible   Special
Issues or Constraints
16
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.

17
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

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

• 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

20
Economic Feasibility

• Should we build it? Cost-benefit analysis
• Identify Costs and benefits
• Development costs
• Development team salary
• Consultant fees
• Development training
• Hardware and Software
• Office space and equipment

21

• Annual operating costs
• Software upgrades
• Software licensing
• Hardware repairs
• Hardware upgrades
• Operational team salaries
• User training
• Annual benefits
• Cost savings
• Increased revenues

22

• Intangible costs and benefits
• Assign Values to costs and Benefits
• Rely on the people who have the best
  understanding of the costs and benefits
• consultants
• Past projects
• Industry reports

23

• Determine Cash Flow
• Cost-benefit projections over 4 to 5 years
• Assume a rate of growth to adjust for business
  improvements
• Determine Return on Investment
• Consider the time value of money
• Calculate the NPV

24
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

25

• 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

26

• 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

27
Project Management

• Major activities
• Creating the work plan
• Staffing the project
• Controlling and directing the project

28

• 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

29
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
30

• 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

31

• 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

32
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.
33
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
organizations 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.
34

• Two more complex, more reliable (hoped) is a 3
  step process.
• Estimate size of the project in KLOC/Function
  Points
• 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

35
Size in KLOC (Most optimistic 4Most 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.
36
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
small/moderate sized business software) Schedule
time (months) 3.0 person-months1/3 Historical
data or estimation software can be used
37
Timeboxing

• Task-oriented projects vs. time-oriented projects
• 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

38

• 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

39

• 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!

40
Staffing the project

• Means much more than assigning people to the
  project
• Matching peoples skills with the needs of the
  project
• Motivating them to meet the projects objectives,
  and
• Minimizing the conflict that will occur over time
• Deliverable staffing plan delineating
• The people along with the overall reporting
  structure
• The project charter, describing the projects
  objectives and rules

41

• 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

42

• 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

43

• Motivation
• Recognition is a good motivator
• Motivation has a great influence on performance
• Do/Donts
• Assign unrealistic deadlines
• Ignore good efforts - show appreciation
• Make decisions without teams inputs
• Do maintain good working conditions/ environment
  working space, lighting, technology, privacy

44

• 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
  projects norms and ground rules

45

• 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

46
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
47
System analyst - designs the IS-focus on
Bala the process models
interface design System analyst - designs the
IS-focus on Raju data models
system performance Programmer coding
Joy   Programmer coding Toy
48
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.

49

• 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

50
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

51

• 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

52
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
53
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

54
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

55
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

56

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

57

• Documentation
• A final technique applied is good documentation
• Includes detailed info about the tasks of the
  SDLC
• The documentation is stored in project binder(s)
• 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 systems 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

58
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

59

• Addressing changes is increasingly difficult
  after the project begins - focus is removed from
  original goals
• Impact on cost and schedule
• Project managers 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

60

• Allow only absolutely necessary requirements
• Assess the ramifications project team members,
  deadline may be offset
• Track the implementation of change so that an
  audit trail exists to measure the changes impact
• Sometimes, additions are recorded as future
  enhancements

61
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

62

• 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