The Systems Life Cycle Methodology

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.

Methodology

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

• if there is a problem to be addressed,
• if there is a feasible solution to the problem, and
• if developing a solution to the problem is cost beneficial to the user and to the firm as a whole.

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:

• Analysis
• Design
• Implementation

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:

• identification of the user of record who will both fund and sign off on the completed project and
• setting the initial parameters for the project.

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.

Reviews

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

• cost, and

• overall business benefit.

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.