Document Sample
intro Powered By Docstoc
					Systems Development Life Cycle (SDLC)

           Feasibility        Feasibility Study

                          S   Requirements
                          S     Analysis
            Analysis      A    Specification
                          D   Logical System
                              Physical Design


Structured Methodologies
    Structured methods consist of three basic elements:
       A default structure of steps and tasks which the project team
        should consider following.
       A set of techniques to be applied in each step that provide
        (largely diagrammatic) structured definitions of user requirements
        and system components.
       A set of products developed by each of the techniques.

    Features:
         Rigorous “top down” analysis of user requirements
         Project Management
         Communication and consistency
         Lower LIFETIME costs
         Documentation
         Widely understood and adopted
         Flexible and adaptable
         Information Systems (database) specific
         Require careful planning and customisation
Other Methodologies
    Object Oriented Development
       Suited to process oriented systems implemented in OO
       “systems that are strongly database-oriented……are not ideally
        suited to object oriented development” - Bennett, McRobb & Farmer
       Requires high level of expertise
       Often used for customisable packages (e.g. SAP)

    RAD
       Iterative development
       Process and user expectations must be carefully handled
       Can be used in conjunction with Structured Methods
       Particularly suited to small projects and user interface
       DSDM
3-Schema Architecture

External Design     Conceptual Model                           Physical/Internal
                      P             S          ELHs
                      r             u          UPMs
                      o             p
                      d     Pur     pl
                      u     ch      ie
                      ct    as      r                                 Physical
                    Pro     Pur
                    duc     ch
                                              Ord                      Data
                            as                PurcPro
                                          Pr er Purc
                    t        n
                            der           S ha-                       Storage
                            ee            oc Queces
                                         1up 4 has
                            Or            es ry ePr
                                          pli     s
                                          s        oc
                            der           er      Ord    Pro
                                                   s     ces
                                                  Ord     4
                     Pu        S
                             Purc                 er
                                                          s            FCIM
                     rc 3      e                         Nex
                     12      hase
  User and System    ha      Purc
                             Ord     Su                   t
                               o     ppli                P.O            PDI
  Interfaces         se      12
                             er 2    2222
                     Or      e012
                             Item    er
                             Ord     Pro
Systems Development Template


        Conceptual Model   External Design

        Internal Design

Basic SSADM Concepts

    Separation of Logical and Physical
       Physical or historical constraints
       Implementation independence
       Re-use

    The Three Views of SSADM
       Data
       Processing
       Events (Time)
CASE Tools

    The claims made in their favour by suppliers are often
     exaggerated, but most will provide a mix of the following
         Diagramming tools
         Diagram validation
         Automatic generation of first-cut low level diagrams
         Report production
         Code generation
Getting Started

    Learning Outcomes:
       Assemble a Project Initiation Document;
       Understand the need for and application of Project Management
       Assess the technical, operational and financial feasibility of a
Why Projects Fail

    Lack of business wide understanding of and commitment
     to the project;
    Lack of clearly defined objectives, deliverables and
     success criteria;
    Lack of ownership or sponsorship within the business;
    Problems establishing the right project team;
    Plans that are too optimistic and lack contingency;
    Poor day-to-day management of issues and control of
     project tasks;
    Lack of awareness of change management and business
     impact issues;
    Lack of focus on project goals and milestones;
    Poor understanding of risks and project dependencies.
Project Initiation

      Define objectives, deliverables and scope of project;
      Establish a sound financial business case for the project;
      Assess costs and business benefits;
      Agree plans, resources and organisation for the project;
      Establish key risks and success criteria;
      Formalise controls and reporting lines.
Project Management
             Three components:
                 Planning
                 Controls
                 Organisation
             Planning
              1. Break the project into a number of stages or phases (e.g. project
                 initiation, feasibility study, analysis, testing).
              2. Identify the activities to be undertaken in each phase.
              3. Break down the activities in the first stage into a detailed task list.
              4. Estimate effort required to complete each task or activity.
              5. Assign resources to each task and activity.
              6. Schedule the project.

Project Controls
    While no project is helped by unnecessary bureaucracy,
     there are some formal controls that are invaluable in
     ensuring that a project is effectively managed, regardless
     project size:

         Progress Reports
         Project Issues
         Change Control
         Risk Log
Project Organisation
      A well-defined project structure ensures that the right
       people are involved in the project and that roles
       responsibilities are clearly defined.

      Key Roles:
            Project Manager
            Project Sponsor

      User Representation
      Project Board

 On student projects the role of the Project Sponsor will be undertaken by a representative of the
 organisation that will be the recipient of the final deliverable(s). In addition there will be an academic
 Supervisor who will act as a co-sponsor, and is responsible for both the mentoring of the Project
 Manager (student) and agreeing the academic objectives of the project.
Feasibility Study
     Feasibility assessment is an activity that can take many
      forms, varying from an informal study carried out as part
      of strategy planning or project initiation, to a high level
      systems analysis “mini project”, depending on the size or
      complexity of overall project.
     The basic questions to be answered in any kind of
      feasibility study are:
        Is there a computer solution to the given business problem?
        Is the solution justifiable in business terms, both organisationally
         and financially? For example:
           • Will benefits outweigh costs?
           • Will the proposed solution be politically acceptable?
           • Can the solution be developed in time?
           • Can the level of change associated with the system be
              absorbed at this time?
           • Are the skills in place and the people available to develop
              and manage the system?
           • Is the risk of project failure acceptable to the organisation?
Feasibility Study (continued)
        There are several points in the life cycle where a decision to drop the
         project might be made. The Feasibility Study provides easily the most cost
         effective point to do so.
        Whether an informal approach or an SSADM Feasibility Study is
         undertaken, the basic steps we go through will be the same:

    1.     Define the business problem to be solved;
                                                       Define the                    Strategy
                                                        Problem                      Planning

    2.     Develop high-level alternatives (or
           “options”) for its solution;                       Project Definition Statement
    3.     Assess the feasibility of the options
           and select options for discussion with
           the Project Board;
    4.     Make recommendations to and                  Option
           document the decision of the Project
           Board;                                              Action Plan
    5.     Develop action plan for further analysis            Feasibility Options
           and subsequent development of the
           chosen option.                              Assemble
                                                       Feasibility            Feasibility Report
SSADM Feasibility Products

   Problem Definition Statement
      A Problem Definition Statement provides a textual summary of
       requirements and their relative priority. It should include
       references to formal SSADM products (which it does not replace
       but merely supplements), and should include a list of the
       minimum requirements.
      We should attempt to be efficient and methodical by using the
       PID to identify the major functional areas that the system will be
       required to support, and using these as a checklist of high level
       processes to be covered by the overview DFD.
Feasibility Options

    Feasibility Options
       At the centre of a Feasibility Option is a high level combination of
        two standard SSADM products:
       Business System Option (BSO). A BSO defines the functional
        scope of a proposed solution. At its most basic level it consists of
        textual descriptions of those requirements satisfied by the
        solution. All BSOs must satisfy the minimum requirement as
        identified by user representatives.
       Technical Systems Option (TSO). A TSO defines a possible
        technical environment for the implementation of the system. It will
        include descriptions of hardware and software, technical support
        arrangements, distribution of the system and development tools.
Feasibility Options (continued)

       Feasibility Options (continued)
          Functional support. Textual descriptions can be supplemented with
           process and data models showing the subset of functional requirements
           covered by the option.
          Costs. These will be very approximate and must include: hardware;
           software; human resources; consultancy; training; together with
           maintenance and running costs (which are frequently higher than the
           development costs).
          Benefits. Including financial benefits (e.g. increased profits or reduced
           costs), strategic benefits (i.e. the meeting of strategic business
           objectives), removal of problems (e.g. capacity constraints) etc.
          Organisational Impact Analysis. Again this will be at a high level, and
           will describe the cultural and operational changes associated with the
          Development approach and approximate timings.
             • Is SSADM the most suitable method for developing the option? If
                 not, what method should be used?
             • How many projects are necessary? If the proposed system is large
                 or complex, a phased approach may be best;
             • Who will develop the option? Possibilities include in-house project
                 teams, contractors, software houses, package vendors, etc.

         Tips on presenting options will be given in Lecture 7 (Business System Options).
Assessing Financial Feasibility
     Financial feasibility has two key elements:
        Are funds are available for the solution to be developed and
        Is there a positive balance of costs and benefits over time?
     Cost Benefit Analysis
        Financial costs are usually easier to estimate than the financial
        For example a system may claim to improve the decision making of
         a set of employees, but measuring the increased profits generated
         directly by that improvement might well prove impossible.
        There are a number of methods for assessing cost benefits,
         including Return on Investment and Payback Periods as outlined
         below. Most organisations will have internal standards for which of
         the methods should be used in conducting a CBA, and what result
         will be considered acceptable in assessing feasibility.
Return on Investment
    Return on Investment (RoI)
       RoI is the simplest, and one of the most frequently used,
        measures of financial feasibility. It delivers a percentage figure
        that can be compared against prevailing interest rates, in order to
        assess whether the proposed investment is financially
       The basic formula is:
               RoI = (Net Benefit / Investment) x 100
       Where Net Benefit = the sum of tangible benefits – Total costs,
        including annual running and development costs.
       Standards vary from organisation to organisation as to what
        period the costs and benefits are measured. A common
        standard is to use the sums of annual costs and benefits over a
        four-year period; another is to use the costs and benefits over the
        expected life of the solution.
       Standards also vary as to what RoI rate is acceptable, with
        values such as twice bank base rate, or base rate plus 5% being
        fairly typical.
Payback Period
       Payback Period
          Another common measure is that of Payback Period. This is a measure
           of when sufficient benefits will have accrued to cover both the initial
           investment costs and the on-going running costs of the solution.
          For example a project with an investment cost of £120,000, annual
           running costs of £20,000, and annual benefits of £50,000 will pay back
           the investment in 4 years.

       In assessing overall cost benefit, measures such as RoI and
        Payback Period will frequently be used in combination, and
        viewed differently by different organisations.
          For example some might view a RoI of 20% with a pack back of 2 years
           as preferable to a RoI of 30% with a Payback Period of 4 years,
           depending on their strategic aims and current financial position.

       For a full description of these methods the reader is referred to a text such as
                                         Robson (1997).

Shared By:
Description: intro