The Systems Life Cycle Methodology

Contact Martin Modell   Table of Contents


A methodology should provide a framework or procedure within which the analyst can systematically and comprehensively investigate a business or business area, document the findings developed from that investigation, draw conclusions from those findings, and develop recommendations based upon those conclusions.In many organizations this framework has been formalized into a standardized set of steps or phases which defines both the sequence of the phases and the documentation deliverables which the firm deems necessary to the accomplishment of the desired tasks in the most efficient and practical manner.

This chapter discusses the need for a methodology and the generic phases which such a methodology should contain.

What is a System Development Life Cycle

In order to accomplish any given set of tasks effectively one must have a work plan or procedure.Without such a procedure or work plan, activities are performed in a haphazard manner and with little if any coordination.The results are that the various intermediate products rarely fit together into a cohesive whole, and worse yet the finished product rarely meets the initial specifications.In some cases because of a lack of a work plan there are no initial specifications.The overall work plans for systems development are called system development life cycles, and the detail plans are called methodologies.In some cases, the system development life cycle is also called a methodology, but for our purposes we will make a distinction between the two.

A definition

A method is "a means or manner of procedure, a regular and systematic way of accomplishing something.An orderly and systematic arrangement. Procedures according to a detailed, logically ordered plan."[1]

A definition

A methodology is "the system of principles, practices, and procedures applied to a specific branch of knowledge." [2]

The Purpose of a Methodology

Methodologies, specifically data processing development project methodologies, provide a framework or procedure within which the analytical tasks can be performed.Most methodologies cover the entire span of development activities from project initiation through post-implementation review.The organization of these phases and the steps within them, are also called the development, or project life cycle.

A definition

A Life cycle is the course of developmental changes through which a project passes from its inception as a project request to the mature state as characterized by a stable production environment..A progression through a series of differing stages of development.[3]

Depending upon the authors and the objectives, these methodologies will be either very general or very detailed.The very general ones provide a framework, and leave the specifics to the development teams.At the other end of the spectrum are those which specify each detailed task and each detailed deliverable or work product.

Aside from the development methodologies, there are others which specify the manner in which specific analytical or implementation tasks are to be performed.

Development methodologies have in common a general preference for a top-down approach.  That is they begin with functional analysis (a very general view of the firm, or area of the firm) and proceed through process and task analysis (a very detailed view of specific areas).  Most specify the content of the deliverables and most include other project definition, management, and control information as well.These project-related items include checkpoints, walk-through, quality reviews, management reviews, funding reviews, and large numbers of approvals (signatures of concerned parties, usually development management and user management).

The specific methodology followed by the firm may be home-grown or purchased from any one of a large number of firms who specialize in the development of methodologies.  The methodology may be specific to a batch environment, an on-line environment, or a database environment. Methodologies exist which have been tailored to specific development products [i.e., specific database management systems (DBMS) products].

The source of the methodology is not important; what is important is that one exists, and that it be followed.From the perspective of the analytical process, a methodology provides for, and ensures that, the analyst will

  1. Systematically and comprehensively investigate a business, or business area
  2. Completely and accurately document the findings developed from that investigation
  3. Draw supportable conclusions from those findings
  4. Develop meaningful recommendations based upon those conclusions
  5. In the case of analysis conducted as part of a data processing development project, design a system (which may incorporate both manual and automated procedures) which accomplishes the necessary and desired tasks in the most efficient and practical manner

The Need for a Methodology

Any methodology, regardless of which one is used, ensures that:

  1. All necessary activities are accomplished in the correct or desired sequence.
  2. The documentation developed as a result of any given project is consistent and comparable with the documentation developed from any other project.
  3. The documentation developed as a result of a given project contains adequate, understandable information.
  4. Appropriate reviews and approvals are obtained at the appropriate points in the project.


Generally speaking the analytical portions of a methodology must include and provide for:

  1. Business organizational analysis
  2. Business function analysis
  3. Business process and activity analysis
  4. Business data analysis

This analytical portion forms the first and most critical phase of the development project.In many cases these phases are the project itself since the information developed may show that no further work is necessary, feasible, or desirable.  In all cases, the results of the analysis phases determine

System Development Life Cycle Phases

Assuming that the project proceeds in a normal and orderly fashion, it can be expected to follow the following general phases:

  1. Project initiation
  2. Analysis
    1. General Business analysis
    2. Detail Business analysis
  3. Examination and study
    1. Evaluation of existing system components
    2. Problem identification
    3. Feasibility analysis of alternative approaches
  4. Design
    1. Development of General Business System Design
    2. Development of Detailed Business System Design
    3. Development of procedural solution specifications
  5. Implementation of the procedural solutions
  6. Testing of the procedural solutions
  7. Implementation of the procedural solutions into the normal business processing schedule (production)
  8. Post-implementation review of results.

Although the preceding list contains many project phases, it can be simplified to:

These three are bracketed by project initiation and by project conclusion and review. Additionally, all five activities include the administrative tasks of planning, scheduling, and control (see Figure 3.1).Since this book is about the process of analysis, it is appropriate that we examine the portions of the life cycle associated with analysis, examination and study.

Project Initiation

Normally a project is initiated by a user requesting service, by the data processing development staff, by the data processing maintenance staff, or by the data processing operations staff.The initiation process may be formal or informal.  The informal route (usually verbal) is usually followed up by a more formal request, usually a memorandum or internal form.Either should state the name of the requester, the nature of the request (either the nature of the business problem to be resolved or the type of service required), the reason for the request, and the time frame within which the requester would like the service.The request should also include appropriate authorization signatures, appropriate funding information, and any priority ratings which the request may have been assigned.

It is strongly advised that no project be initiated without this information.  Although the exact structure of the information may vary, it is needed for performing two vital functions:

The project initiation request sets the tone and scope of the project.  Projects can be targeted at any level of the organization; thus the analyst's first task must be to determine the scope and extent of environment to be analyzed, and the number of levels of analysis which must be undertaken to achieve the desired results.


Each phase of the life cycle, and in some cases each step within each phase should result in a review of the completed products whether they are narratives, models, orcost spreadsheet.Reviews may be:

  1. formal or informal
  2. by management , peers or users
  3. by oral presentation, demonstration, formal document submission or a combination of all three
  4. interim, checkpoint, milestone or decision point
  5. overview or in-depth

Reviews are an important part of the life cycle.  Reviews are intended to catch flaws in logic, perception or design, and to recommend appropriate corrective actions.

A definition

To review is to study or examine again. To consider retrospectively.To examine with an eye to correction or criticism   To subject to formal inspection.

A review is a reexamination or reconsideration.. A retrospective view or survey.An inspection or exami nation with the intention of evaluating.[4]

All reviews should result in an approval of the finished or submitted product.The approved product should form the basis for continued work.

Although there are many different types of reviews, and many different methods of review, there are certain items which are common to all reviews:

  1. The review should be facilitated, or lead, by a neutral party, someone not involved in the project.
  2. Reviews should be attended by people who have been associated with the project, but not necessarily with the development of the product under review.
  3. The draft product(s) to be reviewed should be distributed to the reviewers before the actual review session to allow to for them to study the materials and formulate any questions
  4. The goals of the review should be clearly stated and all reviewers should be reminded that the goal of the review is to find any flaws or errors in the materials.
  5. Reviewers who make comments in their copy of the materials should return the copy with the comments to the submitter.
  6. Each comment, criticism, and suggestion should be written on a review item form, given an identifier and  logged.
  7. Each comment, criticism and suggestion shouldbe evaluated by the submitter and the action (or non-action) taken should be noted on the written form.  A reason should given if a comment, criticism or suggestion is ignored.
  8. Each reviewer should be sent a copy of the final productwith all changes noted and the completed review item forms
  9. If the review was based on a demonstration the final product should be re-demonstrated for reviewers with any changed identified.
  10. The final product review should be accompanied by an approval sheet which should be signed or initialed by the reviewers indicating their approval or disapproval.
  11. The approved product, along with any reviewer notes and comments, all approval sheets, and all completed review item forms , should be filed for reference as part of the project documentation.

Although reviews are time consuming and take a great deal of effort to prepare and conduct,each review will catch a certain number of product flaws. The earlier a flaw is caught the less damage it will cause to the project schedule. The longer a flaw remains undetected the greater the degree of effort it will take to correct it.

Flaws in the products ofthe project scope determination, requirements identification, alternative approach identification and selection, project schedule preparation, and staffing and resource allocation activities will have far-reaching impact on the project. The larger the project the greater the impact of an undetected flaw and the more critical the early reviews become.

Frequent reviews will prevent a project from deviating from its schedule, and from losing sight of its goals. Many projects go off on tangents, follow divergent paths misinterpret user requirements and management directives without realizing it.Reviews force the project team to focus on the goals, clarify their direction and approach.  Reviews provide the frequent project corrections needed to ensure a successful completion of all activities.  They also help to ensure that the user, and the firm get what is needed in the way of a new system, or new business processes.

Five phases of the Business Process Reengineering life cycle

The Business Process Reengineering (BPR) project life cycle normally consists of five major phases:

  1. Current Systems Analysis – This phase results in the identification and documentation of the present environment.  This is usually referred to as the “AS-IS” model because it documents the environment as it is.
  2. Business Process Improvement Analysis – This phase results in the identification ofareas for improvement, processes which should be:
    1. eliminated
    2. combined with others
    3. split apart
    4. reorganized

This phase of Business Process Reengineering normally uses a zero-basedbusiness and processing environment as the base for its “TO-BE” model.   That is it assumes that all existing all existing business functions, all existing business activities, all activities involved in the production of existing products and delivery of existing services are subject to scrutiny, change or potential elimination.   All business processes within the firm must be reexamined, and rejustified.

Any processes that survive the rejustification process, are then examined to determine whether they can or should be reworked, streamlined, or combined.   The goal of the process is to eliminate any unnecessary processing, remove bottlenecks and make the firm more responsive to its customers.   In some more radical efforts the firm may also reexamine its lines of business, products and core functions.

Develop Alternative Business Structural Approaches – This phase identifies and documents the various alternative approaches and the costs and benefits associated with each alternative.   The alternatives should also be ranked in order of preference based on

Future System Analysis – This phase results in the identification and documentation of the business processes as they should be.   This is usually referred to as the “TO-BE” model.

Develop Plans To Implement The Selected Alternative > – The selected alternative normally cannot be implemented all at once.   In most cases implementation is in phases, top down, and in a manner design to cause the least disruption on the products and services offered by the firm and the least impact on the firm’s customers.   In some cases the changes can be made rapidly and with little preparation.   In other cases there are many activities and extensive preparation which must be accomplished before a specific change can be made.   All the changes must be accounted for in the plan and management must determine the order of the changes based on preparation time and change dependencies

Cost-Benefit Analysis

Each phase of a development project will normally require the expenditure of a certain level of resources, both in terms of personnel and other assets.In effect the firm is buying a product: the completed work and the accompanying documents from each phase.In order for user and data processing management to assess the relative value of each of these products in advance of their being contracted for, many firms require a separate justification document, called a cost-benefit analysis.  This document provides, sometimes in estimate form, the costs for producing the product and the benefits which the firm can expect to accrue as a result of that effort.

In the early stages the project has little form or definition, thus early cost-benefit documents are predominantly based upon estimates.As more and more information is developed these cost-benefit documents become more and more detailed and more and more accurate.

Cost-benefit analysis (CBA) is used in two ways.The first is to develop estimates for project budgetary planning and, later, to apply actual costs for project monitoring purposes.This is usually done at each phase of the development project and allows data processing (DP) management to assess whether the costs of the project can be justified by the potential benefits to the user and the firm.

The second is to develop user costs and benefits which will result if the project is implemented.This allows user management to plan future budgets and to estimate when the costs will be incurred.Although the costs in the first CBA contain only project costs, the costs in all succeeding analyses should also contain separate projected user costs for implementation and ongoing operations.

The first cost-benefit analysis is usually performed at the project initiation phase and is used by user and DP management to allocate abudget for the first phase.At the end of the problem identification and analysis phase a second cost-benefit analysis is normally generated.Since work has already been performed and the scope and direction of the project are fairly clear, this document can be based upon concrete information as to costs and benefits.The development alternative selected will allow the cost of hardware and software to be added, as well as the costs of user documentation and training to be estimated.>  At the end of the proposed environment analysis phase, user costs should be well defined and fairly accurate numbers generated.

During the problem identification and analysis phase, it is usually necessary to perform a separate CBA for each alternative being evaluated. These alternative CBA documents can assist in making the selection between multiple viable alternatives.

Project Development Costs

All costs which can be expected as a result of this unit of work should be estimated and itemized.Cost figures are usually generated by the project manager and the systems analyst assigned to the project.Generally, these costs will be broken out into one or more of the following categories.

  • Direct personnel costs. These cost are developed from the project plan for this phase.>  (See Chapter 4 for a discussion of project plans.) From that plan, the number of people at each level and the number of periods (hours, days, weeks, months, etc.) that each person will be working on the project should be extracted.A per period cost should be assigned on any one of the following bases:

    1. Standard cost. Applicable to all personnel at all levels
    2. Level-by-level costs. Applicable to all personnel at each given level
    3. Per-person costs. Based upon the compensation for each person (this is only used where there are no company policy restrictions on publication of personnel compensation)

      The per-period cost for each person should be multiplied by the number of periods each person is expected to work on the project, and the total cost for all assigned personnel should be determined.For the best results, each person, the person's level, the costs assigned to that person, and the number of periods the person is expected to work on the project should be detailed, either in the body of the analysis or as a separate appendix.>  When developing these costs, be sure to include any benefits, additions, payroll added costs, and vacation and holiday costs to be assigned to the project.

    4. Indirect personnel costs. These costs include project management, staff, and administrative services which may be needed to support the project personnel.  For example, the cost related to project managers, area managers, secretaries, and file clerks, are included in this category.These costs may be calculated in the same manner as direct costs: that is, they may be estimated or taken as a percentage of the total development department administrative costs.
    5. Travel costs. If the project requires personnel to travel between locations or if personnel must be transported to a central location, all costs of travel, accommodations, board, entertainment, and other travel-related expenses should be estimated.In lieu of an estimate, a budgetary maximum may be used.
    6. Printing and graphics costs. The costs for development of charts, graphs, and diagrams, and for printing the final report (usually in multiple copies) should be estimated.
    7. Space costs. If staff must be assembled from diverse locations, it may be necessary to assign office space for them during the project's duration.These costs should be calculated from the firm's space budget costs and added to the project cost totals.
    8. Machine costs. These costs include estimates of the costs of any computer time necessary to run analyses, simulations, print machine-stored documentation, analyze machine-stored files, analyze existing user applications, create duplicate copies of user reports, etc.
    9. Supply costs. These costs include paper, copier supplies, binders and covers for reports, pencils, pens, other stationery supplies, and any special materials which may be necessary for the project.
    10. Training costs. These costs include any special training required by project personnel in terms of familiarization with specific business functions, special software, special machinery, general education, etc.
    11. Special software costs. These costs include the acquisition of any specialized software for either mainframe, mini-, or microcomputers which will be necessary for the project.

    All costs in each of these categories should be totaled; the sum becomes the total project cost.

    User and Project Implementation Costs

    Aside from the costs to be incurred by the project itself, there may be ongoing costs that will be incurred when the project is completed and implemented.These costs fall into the same basic categories as project costs, except that the staff being costed is the user area staff, etc.In addition to the above costs, the following might be included:

    1. Special user training costs.Includes all costs for training user personnel in the use of the new system, procedures, etc.
    2. Special or new user documentation and user forms.  Includes all new forms and documents, manuals, procedural documents, etc., which might be needed by the user as a result of the new system being implemented.
    3. Special user hardware.Includes user-owned computers, terminals, printers, personal computers, communications devices, security devices, etc.
    4. Special user software license or acquisition costs.  Includes additional copies of PC software, multiple site licenses for mainframe and minicomputer locations, ongoing training costs.


    Benefits are usually more difficult to quantify, and most benefits are shown in estimated form, especially during the early stages of a project.In many cases, these benefits numbers are obtained from the user requesting the project.  They are determined by quantifying the costs of the existing environment and problems, or by estimating the savings which would result from rectifying these problems.Benefits are usually broken out into two sub-categories--direct benefits and indirect benefits.

    Direct benefits

    Direct benefits are those whose value can be calculated or estimated in monetary terms.These include savings or reductions in

    1. Direct or indirect personnel costs. Calculated in the same manner as development direct and indirect personnel costs.These benefits are obtained from the reduced level of effort or reduced level of staff which can be expected if the project is successful.
    2. Supply costs. Calculated by estimating the reductions in supplies usage (paper, stationery, etc.) which can be expected if the project is successful.
    3. Machine costs. Calculated by estimating the reduction in computer usage expected if the project is successful.>  This benefit area may also include reduced rental or lease costs on machinery being upgraded as a result of this project.
    4. Travel costs. Calculated by estimating the reduction in travel and entertainment costs which can be expected if the project is successful.
    5. Interest or penalty costs. Calculated by estimating the reduction in interest on money borrowed to finance inefficient operations, or penalties incurred for late payments, etc.

    The above benefits are estimates of those reductions of such costs which might be achieved through more efficient processing if the project is successful.

    In some cases the benefits may be achieved through actual increases in revenue, faster collections, more rapid turnover, or increased productivity.  Some examples of benefits to be looked for, and estimated, in this area are:

    1. More rapid processing of customer invoices decreases the time between shipment and billing, thus the accounts receivable period decreases and cash flow increases
    2. More rapid identification and payment of vendor invoices offering discounts allow the firm to reduce its purchasing costs
    3. Faster access to information allows employees to process more transactions in the same period of time.
    4. Reductions in work due to a reduced number of processing steps or to simplified procedures
    5. Improved editing or validation procedures which reduce errors.

    Indirect benefits

    Indirect benefits are those which can't be quantified, or assigned a monetary value, but which nonetheless result in desirable outcomes from the project.These might include:

    1. Access to previously inaccessible or missing information
    2. Faster access to information
    3. More flexible processing, or additional processing capability or ease
    4. Additional functionality
    5. Standardization of information
    6. Improved communications or reporting procedures
    7. Improved, clearer, or more accurate reports or screens
    8. Reports providing more detail, or reports removing unneeded detail
    9. Improved understanding of the basic functional or processing interactions within the firm
    10. Improved documentation of the basic functions and processing within the firm

    A cost-benefit analysis may be as short as a single page or may cover many pages.>  In format it is similar in style to a standard budget, with costs being equated to the expense side and benefits being equated to the income side.All cost items should be subtotaled by category and an overall total cost figure computed.All benefits should be subtotaled by category and a total benefit figure computed.  In more complete cost-benefit analyses, both the costs and the benefits would be "spread" across the project or phase time frame.

    [1]The American Heritage Dictionary, Second College Edition

    [2]The American Heritage Dictionary, Second College Edition

    [3]Paraphrased from Webster’s II, New Riverside University Dictionary

    [4]Webster’s II, New Riverside University Dictionary

    Contact Martin Modell   Table of Contents

    A Professional's Guide to Systems Analysis, Second Edition
    Written by Martin E. Modell
    Copyright © 2007 Martin E. Modell
    All rights reserved. Printed in the United States of America. Except as permitted under United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a data base or retrieval system, without the prior written permission of the author.