Introduction to System Development Life Cycles - PowerPoint PPT Presentation

Loading...

PPT – Introduction to System Development Life Cycles PowerPoint presentation | free to download - id: 6628d6-ZDYxY



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Introduction to System Development Life Cycles

Description:

INTRODUCTION TO SYSTEM DEVELOPMENT LIFE CYCLES Examples of objectives might include Improve customer satisfaction 10% within 1 year Reduce the response time for ... – PowerPoint PPT presentation

Number of Views:49
Avg rating:3.0/5.0
Date added: 3 August 2019
Slides: 54
Provided by: FredN151
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Introduction to System Development Life Cycles


1
Introduction to System Development Life Cycles
2
What is an information system (IS)?
Hardware, software, data, people, and procedures
that work together to produce quality information
SystemSet of components that interact to achieve
common goal
Businesses use many types of systems
3
What are the phases of the system development
cycle?
Phase 2. Analysis
  • Conduct preliminary investigation
  • Perform detailed analysis activities
  • Study current system
  • Determine user requirements
  • Recommend solution

Phase 1. Planning
Phase 3. Design
  • Review project requests
  • Prioritize project requests
  • Allocate resources
  • Identify project development team
  • Acquire hardware and software, if necessary
  • Develop details of system

Phase 4. Implementation
Phase 5. Support
  • Develop programs, if necessary
  • Install and test new system
  • Train users
  • Convert to new system
  • Conduct post-implementation system review
  • Identify errors and enhancements
  • Monitor system performance

4
Who Participates in the SDLC?
5
What is a systems analyst?
Responsible for designing and developing
information system
Liaison between users and IT professionals
6
What is the project team?
Formed to work on project from beginning to end
Consists of users, systems analyst, and other IT
professionals
Project leaderone member of the team who
manages and controls project budget and schedule
7
What is feasibility?
Operational feasibility
Measure of how suitable system development will
be to the company
Four feasibility tests
Schedule feasibility
Economic feasibility (also called cost/benefit
feasibility)
Technical feasibility
8
What is documentation?
Collection and summarization of data and
information
Includes reports, diagrams, programs, and other
deliverables
9
Why create (or modify) an information system?
To improve existing system
To correct problem in existing system
Competition can lead to change
Outside group may mandate change
10
What is a request for system services?
  • Formal request for new or modified information
    system
  • Also called project request

11
Planning phase
Begins when steering committee receives project
request
Steering committeedecision-making body for the
company
Function of committee
Review and approve project requests
Allocate resources
Form project development team for each approved
project
Prioritize project requests
12
Analysis Phase
13
Preliminary Investigation
  • Determine exact nature of problem or improvement
    and whether it is worth pursuing
  • Findings are presented in feasibility report,
    also known as a feasibility study

14
Detailed Analysis
1. Study how current system works
2. Determine users wants, needs, and requirements
3. Recommend solution
Sometimes called logical design
15
System Proposal
16
Identify Possible Solutions
Horizontal market softwaremeets needs of many
companies
Buy packaged softwareprewritten software
available for purchase
Vertical market softwaredesigned for particular
industry
Write own custom softwaresoftware developed at
users request
Outsourcehave outside source develop software
17
Design Phase
Acquire hardware and software
Develop all details of new or modified
information system
18
Acquisition
  • What is needed to acquire new hardware and
    software?
  • Identify all hardware and software requirements
    of new or modified system

Surf Web
Talk with other systems analysts
Visit vendors stores
Read print and online trade journals, newspapers,
and magazines
19
How to Test Software Products?
  • References from vendor
  • Talk to current users of product
  • Product demonstrations
  • Trial version of software
  • Benchmark test measures performance

20
Detailed Design
Detailed design specifications for components in
proposed solution
Includes several activities
Database design
Input and output design
Program design
21
Prototyping Tools/Methods Mockup
  • Sample of input or output that contains actual
    data

22
Prototyping Tools/Methods Prototype
Working model of proposed system
Beginning a prototype too early may lead to
problems
23
Prototyping Tools/Methods CASE
  • CASE (Computer-Aided Software Engineering) tools
    support activities of the SDLC

24
Implementation Phase
  • Purpose is to construct, or build, new or
    modified system and then deliver it to users

Convert to new system
Train users
Install and test new system
Develop programs
25
Testing
  • Three kinds of tests performed by system
    developers

Systems test
Unit Test
Verifies each individual program works by itself
Verifies all programs in application work together
Integration Test
Verifies application works with other applications
26
Training
  • Showing users exactly how they will use new
    hardware and software in system

27
Support Phase
Conduct post-implementation system reviewmeeting
to find out if information system is performing
according to expectations
Identify errors
  • Providing ongoing assistance after the system is
    implemented

Identify enhancements
Monitor system performance
28
Feasibility
  • Every organization which performs system
    development, or has it done for them, needs a way
    to choose which projects are worth the effort
  • Feasibility study is a common approach to make
    such decisions thoughtfully
  • Basis for feasibility study is generally the
    problems and opportunities analysis

29
Problems Opportunities
  • We can look for problems and opportunities in
    many parts of our organization, and the existing
    systems which are supported
  • Track maintenance costs for existing systems
  • Measure existing processes to determine their
    cost, and compare to industry standards
  • Monitor availability of support for existing
    system components
  • Look for signs of unhappy employees

30
Problems Opportunities
  • Check quality of work products (outputs)
  • Listen to customers, vendors, and suppliers
  • Both complaints and suggestions
  • Measure customer satisfaction
  • Monitor competitors offerings and plans
  • Monitor changes in technology which could help
  • Dont forget obvious measures of success, like
    sales, profit, or number of contracts awarded

31
Project Selection
  • Selection of projects is based on many factors
    cost, urgency, the systems affected, etc.
  • From the organizations perspective, choosing
    projects is kind of like shopping
  • Theres generally a limited amount of funds and
    people available to work on the possible
    projects, and management needs to choose which
    projects to support

32
Project Selection
  • There are five typical requirements for a project
    to be supported
  • Management support for the project
  • Appropriate timing of commitment to the project
  • Relevance to helping meet organizational goals
  • Project must be practical and feasible
  • Project must be worthwhile compared to other
    possible expenditures
  • Are we getting enough bang for our buck?

33
Project Objectives
  • Based on the problems and opportunities
    identified for a project, we can set objectives
    for the project
  • These not only help the feasibility study which
    follows, but set goals against which we can later
    test the system
  • Objectives should not only address the type of
    improvement sought, but set a desired level of
    improvement

34
Project Objectives
  • Examples of objectives might include
  • Improve customer satisfaction 10 within 1 year
  • Reduce the response time for customer complaints
    by 15
  • Get a new feature to market before competitors
  • Reduce error rate for data entry from 2 to 0.5
  • Improve sales to new customers by 5
  • Reduce voluntary employee turnover by 10

35
Feasibility Analysis
  • Feasibility consists of several types we want to
    assess for each candidate project
  • Technical feasibility
  • Can the project be done with existing technology?
  • Are people available to use the technologies
    needed?
  • Economic feasibility
  • How much does the system cost to develop?
    Maintain? How long will it be usable?
  • Some add schedule feasibility how long will it
    take to create the system?

36
Feasibility Analysis
  • Operational feasibility
  • What impact will the new system have on how we do
    business? Will there be changes to where or how
    processes are performed?
  • Will there be changes to employee skills needed?
    Changes to employee training?
  • Are existing users amenable to a new system?
  • These types of feasibility can be measured for
    each project, and compared to determine which is
    most feasible

37
Feasibility Analysis
  • Like voting or buying a car, feasibility analysis
    is rarely completely logical or quantifiable
  • Many other issues can also affect it
  • Political climate
  • State of the US and/or global economy
  • Preferences of the decision makers favored
    vendors, technologies, types of projects, etc.

38
Planning Activities
  • To help structure development activities, we use
    a life cycle model to identify the major sets of
    activities, called life cycle phases
  • There are many kinds of life cycle models
  • The Waterfall model is the oldest, and uses
    phases like Requirements Analysis, High Level
    Design, Low Level Design, Coding, and Testing
  • The Rational Unified Process has Inception,
    Elaboration, Construction, and Transition phases

39
Planning Via the SDLC
  • Each life cycle phase is broken down into more
    and more specific activities, until the time
    needed for each activity can be reliably
    estimated
  • Then the tasks are put into a Gantt chart or Pert
    chart to show when they occur relative to each
    other
  • Tasks might occur sequentially, have to start or
    end together, or wait for some other tasks to be
    completed

40
Planning Via the SDLC
  • Tasks for a project often include the acts of
    creating specific documents or work products,
    approving things or making decisions such as
  • Prepare system test plan
  • Approve system release
  • Conduct user satisfaction survey
  • Approve system requirements specification
  • So the life cycle model provides guidance on the
    types of activities needed, but the tasks provide
    authority for people to do them

41
Waterfall Model
42
Features of a Waterfall Model
  • A waterfall model is easy to follow.
  • It can be implemented for any size project.
  • Every stage has to be done separately at the
    right time so you cannot jump stages.
  • Documentation is produced at every stage of a
    waterfall model allowing people to understand
    what has been done.
  • Testing is done at every stage.

43
Advantages of a Waterfall Model
  • Easy to understand, easy to use
  • Provides structure to inexperienced staff
  • Milestones are well understood
  • Sets requirements stability
  • Good for management control (plan, staff, track)
  • Works well when quality is more important than
    cost or schedule

44
Disadvantages of a Waterfall Model
  • All requirements must be known up front
  • Deliverables created for each phase are
    considered frozen inhibits flexibility
  • Can give a false impression of progress
  • Does not reflect problem-solving nature of
    software development iterations of phases
  • Integration is one big bang at the end
  • Little opportunity for customer to preview the
    system (until it may be too late)

45
When to use the Waterfall Model
  • Requirements are very well known
  • Product definition is stable
  • Technology is understood
  • New version of an existing product
  • Porting an existing product to a new platform.

46
Agile SDLCs
  • Speed up or bypass one or more life cycle phases
  • Usually less formal and reduced scope
  • Used for time-critical applications
  • Used in organizations that employ disciplined
    methods

47
Agile Manifesto
48
Some Agile Methods
  • Adaptive Software Development (ASD)
  • Feature Driven Development (FDD)
  • Crystal Clear
  • Dynamic Software Development Method (DSDM)
  • Rapid Application Development (RAD)
  • Scrum
  • Extreme Programming (XP)
  • Rational Unify Process (RUP)

49
Extreme Programming - XP
  • For small-to-medium-sized teams developing
    software with vague or rapidly changing
    requirements
  • Coding is the key activity throughout a software
    project
  • Communication among teammates is done with code
  • Life cycle and behavior of complex objects
    defined in test cases again in code

50
XP Practices (1-6)
  1. Planning game determine scope of the next
    release by combining business priorities and
    technical estimates
  2. Small releases put a simple system into
    production, then release new versions in very
    short cycle
  3. Metaphor all development is guided by a simple
    shared story of how the whole system works
  4. Simple design system is designed as simply as
    possible (extra complexity removed as soon as
    found)
  5. Testing programmers continuously write unit
    tests customers write tests for features
  6. Refactoring programmers continuously
    restructure the system without changing its
    behavior to remove duplication and simplify

51
XP Practices (7 12)
  1. Pair-programming -- all production code is
    written with two programmers at one machine
  2. Collective ownership anyone can change any code
    anywhere in the system at any time.
  3. Continuous integration integrate and build the
    system many times a day every time a task is
    completed.
  4. 40-hour week work no more than 40 hours a week
    as a rule
  5. On-site customer a user is on the team and
    available full-time to answer questions
  6. Coding standards programmers write all code in
    accordance with rules emphasizing communication
    through the code

52
XP is extreme because
  • Commonsense practices taken to extreme levels
  • If code reviews are good, review code all the
    time (pair programming)
  • If testing is good, everybody will test all the
    time
  • If simplicity is good, keep the system in the
    simplest design that supports its current
    functionality. (simplest thing that works)
  • If design is good, everybody will design daily
    (refactoring)
  • If architecture is important, everybody will work
    at defining and refining the architecture
    (metaphor)
  • If integration testing is important, build and
    integrate test several times a day (continuous
    integration)
  • If short iterations are good, make iterations
    really, really short (hours rather than weeks)

53
Summary
  • This has been a (very) quick tour through the
    life cycle of a system.
  • You will have to doto some extentall of these
    activities for your project.
About PowerShow.com