System Development Life Cycle -Examination and Study
Evaluation of existing system components
This phase of the system development life cycle examines the results of the analysis, and using both the narratives and models, identifies the problems which exist as the result of misplaced functions, split processes or functions, convoluted, or broken, data flows, missing data, redundant or incomplete processing, and non-addressed automation opportunities.
The activities for this phase as illustrated in figure 3-1 are:
Each system component must be examined and evaluated. Most evaluation is performed at the procedural level. Various techniques can be used during the evaluation process to uncover all the problems inconsistencies, and omissions in the existing system.Data components are evaluated to determine whether the data gathered by the firm is:
Each process, activity and procedure is evaluated to determine:
The evaluation of the components seeks to achieve an end-to-end test of the analysis products, looking for inconsistent references, missing data or missing processes, missing documents or transactions, overlooked activities, functions, inputs or outputs, etc.In many respects this evaluation should be conducted in conjunction with the other evaluation processes. The analyst and the user alike should be looking for "holes" in the document, both to determine "correctness" and completeness.
Level to level Evaluation
Depending upon the size and scope of the project, the analysis may have been conducted in levels. That is the analysis team may have first tried to achieve a broad-brush overview of the user function. This may have been followed by a more narrowly focused analysis of a particular function or group of functions, and working in successively finer and finer detail, finally arriving at the operational task level. This leveled approach usually works each level to completion before beginning the next lower level. Although in theory the work at the level under analysis should be guided by the work at the preceding (higher) level, in practice, this may not be true.
The reality is that these levels may be under concurrent analysis, or may be analyzed by different teams. The latter is especially in long running projects where staffing turnover, transfer and promotion continually change the make up of the analysis team.
Level to level evaluation and validation seeks to ensure that the information, perspective and findings at each level correspond. or at least do not conflict with, the information perspective and findings at each of the levels both higher and lower.
Carrier to Data Evaluation
Carrier to data evaluation focuses in on the data transactions to determine whether the data on the documents (data carriers) which enter the firm are passed consistently and accurately to all areas where it is needed.
It seeks to determine whether or not the firm is receiving the correct data, whether it understands what data it is receiving (i.e. what the transmitter of that data intended), and whether it is using that data in a manner which is consistent with its origin.Since, with few exceptions, the firm collects data on its own forms, and with even fewer exceptions, the firm can specify what data it needs and in what form it needs that data, this level of evaluation, should compare the firm's use of the incoming data with the data received to ensure that the forms, instructions, and procedures for collection or acquisition, and dissemination are consistent with the data's subsequent usage.
Process to Process Evaluation
Process to process evaluation seeks to trace the flows of processes and determine whether the various processes are consistent with each other. That is if one process is expecting data from another, that they both have a common understanding of the data to be transferred. Process to process evaluation and validation seeks to answer the following questions:
This evaluation approach is similar in nature to Zero-Based Budgeting, in that it assumes nothing is known about the existing environment. It is a "Start from Scratch" approach. All user functions processes and tasks are re-examined and rejustified. The reasons for each user activity are documented and all work flows are retraced.
Zero based evaluation should be undertaken where the analysis indicates that the systems, processes, activities and procedures are undergoing resystemization or reautomation. It should also be undertaken where the analysis indicates that the existing systems and automation may have been erroneous, or the environment may have changed sufficiently to warrant this start from scratch approach.
In any case, the analyst should never assume that the original reasons for data being collected or being processed are still valid. Each data transaction, and each processes must be examined as if it were being proposed for the first time, or for a new system. The analyst must ask:
Although some of the problems with the existing system may have been known or suspected at the time of project initiation, the scope and extent of those problems, and in many cases the reasons for those problems, many not have been accurately known.
The analytical results not only represent the analysts understanding of current environment, and his diagnosis of the problems inherent in that environment, but also his understanding of the users unfulfilled current requirements and projections of his needs for the foreseeable future. The combination of these four aspects of the analysis will be used to devise a design for future implementation. Thus it is imperative that it be as correct and as complete as possible.
It is at this point that the analyst and user, should have the detailed analytical documentation before them, as well as, the results of the evaluation of that analysis.During the interviews conducted during the functional, process, activity, task and data analysis phases, each user was asked questions which sought to identify one or more of the following processing problems:
During the interviews, the users were also asked to enumerate processes and activities which were not currently being performed, and which could not be performed or could only be performed with great difficulty in the current environment, but which the users felt should be performed.
As the analysis progressed, the analysts should have been able to identify areas of opportunity. Areas of opportunity result from the synergy between data and process, data and data, process and data. Synergy which has created the ability to achieve a corporate mission or goal, or to provide a new service, or create a new product, or provide new information about the firm's products, competitors, customers or markets, but where that opportunity has not as yet been identified or taken advantage of.
System Design Requirements Document
The product of the Examination and Study phase is document which is usually referred to as a System Design Requirements Document, or a Client Requirements Document. This document classifies, catalogues, and enumerates all existing and identified problems and opportunities, by function, processes, activity, task and procedure. For each of these it lists the change requirements or specifications - the specifications and requirements for correcting the problems or the possible methods of taking advantage of the identified opportunities.
Simply stated, this is the verified documented list of all of places and ways where system and procedural changes have fallen behind the business activities which they were intended to support. It also documents all of the ways where the users anticipate changes to occur, or where changes which have occurred have created opportunities to take advantage of recognized synergies within and between business activities and among the resources of the business.
Prioritization of changes
Each item pair - problem and requirement or specification, or opportunity and proposed method or approach - is evaluated against all other pairs and prioritized. The prioritization may be performed by any one of a number of available methods such as:
The above methods (and variations thereof) are the most prevalent ones and while they accomplish part of the goal of analysis, and are necessary there are two other rankings which should be performed by both the user and the analysis and design team. These are dependency ranking and synergy or impact/benefit ranking.
Dependency ranking seeks to determine item dependencies, items which form the foundation for other items, or which items must be accomplished before certain others. This assumes that there are three types of changes which must be made during any new system designFoundation changes - changes upon which all others are based. These include:
Synergy or impact/benefit ranking
Synergy or impact/benefit ranking is the most difficult task to perform in this phase but it is also the one where major benefits to the firm exist. Although it is termed a ranking, in reality it is the examination of each item or combination of items (the items in this case being proposed changes or modifications) to assess;a) the number of specific, recognizable, direct or indirect benefits which are expected to be achieved from this changeb) the extent of the positive impact, that is:
Cost benefit ranking
The Examination and Study phase usually includes a cost benefit analysis of each proposed change, and an evaluation of the costs and benefits of each change with respect to its various rankings and prioritizations. The item by item cost benefit analysis provides another (and sometimes the most definitive) method of evaluating the proposed change specifications and requirements.
Make versus buy decisions
Once the list of change requirements and specifications is completed and the list proposed systems change solutions (not the design itself) have been identified and prioritized, one last set of tasks faces the analysis team. That is, to determine whether it is feasible to obtain from a commercial vendor, a prepackaged application system which will accomplish a large enough number of changes, in a viable, acceptable and cost effective manner, as opposed to attempting the design and development of a system using internal resources.This analysis is called the "Make versus Buy" decision. In many cases the feasibility of obtaining a pre-built package is extremely cost-effective.
The make or buy decision may also extend to retaining an outside firm to custom-build a package to the user's specifications.Using the analysis documentation of the current system, which is the base upon which to apply the changes, and the change requirements and specifications developed in the Examination and Study phase, the analysis and design team (including the user representatives) must examine and arrive at an answer to each of the following make versus buy issues.
Make versus Buy issues
Package evaluation and selection
If the decision has been reached to buy, the analysis and design team must must recognize that any system that is acquired, rather than custom built, will not fully meet the firm's needs. Pre-built packages are by their very nature generalized to suit the largest number of potential customers. This implies that while most packages will address the basic functional requirements, some percentage of the needed user functionality will be missing. Each package will have its own configuration of supported functions, any these may not be the same from package to package. Those functions which are supported, basic or otherwise, can also be implemented in sometimes radically different ways, and the depth and comprehensiveness of the functional support can also differ radically.
Additionally there may be some specialized company functional needs which may not be addressed by any vendor package. The analyst can also expect that each package will support not only different functional requirements but may also be designed to operate in markedly different types of businesses. For instance a financial package designed for manufacturing organizations will have different design characteristics from one designed for a financial, or a service organization. This difference in functionality may make comparative product evaluation difficult if not impossible.
Most packages were originally designed for a specific company, in a specific industry, and then generalized for commercial sale. These packages may have been designed by the specific firm itself, or may have been designed for the firm by an outside service consultancy
Depending upon its origins the implementation may vary from very good to very poor, and the documentation can be expected to vary across an equally wide range. In any case, because of these origins as custom systems, one can expect the implementation to bear a strong imprint from the original users.
Industry surveys indicate that a functional and procedural "fit" of between 30 to 50% is considered average. This means that 30-50% of the package capability will exactly match the company's requirements. The analyst must assess the closeness of the fit between desired functionality and needed functionality. The analyst must also assess the closeness of the procedural implementation to the way the firm currently does business, and to assess the impact of either modifying the firm to conform to the package requirements, or modifying the package to conform to the firm's requirements.
In addition, the analyst must "look beneath the covers" at how the system works, not only what it does. Many packages come with their own forms, coding structures, processing algorithms, and built-in standards and policies. Many of these package internals are not changeable. The analyst must determine the degree to which the user is willing to accept these package "internals". The analysis must also examine in detail the vendor of the product, the vendor's service and reliability, and any vendor restrictions on the company's use of the product.
The lack of available literature, and the lack of detailed evaluation information available, may make this evaluation process very time consuming.
Some issues to consider when examining the "buy" option:
Cost Benefit Analysis
The Examination and study phase is completed when a cost benefit analysis is developed for the system design phase for the selected approach.
A system design project will require the expenditure of a certain level of resources, both in terms of manpower and other assets. In effect the firm is buying a product, the completed work and the accompanying document, 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, 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 being to develop estimates for project budgetary planning and later actuals for project monitoring purposes. This is usually done at each phase of the development project. This allows Data Processing 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 on-going operations.
The first cost benefit analysis is usually performed at the project initiation phase and is used by user and DP management to allocate a budget 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 the concrete information as to costs and benefits. The development alternative selected will allow hardware and software costs to be added, as well as user documentation and training costs 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 thus 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:
A per period costs should be assigned on any one of the following bases:
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 results for all assigned personnel totaled. 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.
All costs in each of these categories should be totaled and the sum becomes the total project cost.
User and Project Implementation Costs
Aside from the costs to be incurred in the project itself, there may be ongoing costs to be incurred when the project is completed and implemented. These costs fall into the same basic categories as project costs, with the difference that the staff being costed is the user area staff, etc.
In addition to the above costs, the following might be included:
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 form the user requesting the project.
They are determined by quantifying the costs of the existing environment and problems, or by estimating the savings from rectifying these problems. Benefits are usually broken out into two sub-categories - Direct Benefits and Indirect Benefits.
Direct Benefits - are those whose value can be calculated or estimated in monetary terms. These include savings or reductions in:
The benefits here 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, or faster collections, or 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 decreasing the receivables period and increasing the cash flow.
2. More rapid identification and payment of vendor invoices offering discounts allowing the firm to reduce its purchasing costs.
3. Faster access to information allowing employees to process more transactions in the same period of time.
4. Reductions in work due to reducing the number of processing steps or resulting from simplified procedures
5. Improved editing or validation procedures which reduce errors.
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:
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, with the costs and projected benefits.The data requirements of the operational level units, while extensive, rarely change since they are contingent upon fixed sources of input.
Data Directed Systems Design - A Professional's Guide
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.