System Development Life Cycle - PowerPoint PPT Presentation

About This Presentation
Title:

System Development Life Cycle

Description:

Technique Creating a staffing plan. Creating a project charter ... C 130 lines/FP. COBOL 110 lines/FP. VB 30 lines/FP. Java 55 lines/FP ... – PowerPoint PPT presentation

Number of Views:1636
Avg rating:3.0/5.0
Slides: 63
Provided by: csr97
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com