System Development Life Cycle -Examination and Study

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:

1. Identification of Current Environment Problems
   
2. Identification of problem causes
   
3. Identification of alternative solutions
   
4. Evaluation and Feasibility Analysis of each solution
   
5. Selection and recommendation of most practical and appropriate solution
   
6. Project Cost Estimation and Cost Benefit Analysis

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:

1. needed
   
2. Verified or validated in the appropriate manner
   
3. useful in the form acquired
   
4. acquired at the appropriate point, by the appropriate functional unit
   
5. complete, accurate and reliable
   
6. made available to all functional areas which need it
   
7. saved for an appropriate length of time
   
8. modified by the appropriate unit in a correct and timely manner
   
9. discarded when it is no longer of use to the firm
   
10. correctly and appropriately identified when it is used by the firm
    
11. appropriately documented as to the type and mode of transformation when it does not appear in its original form
    
12. appropriately categorized as to its sensitivity and criticality to the firm.

Each process, activity and procedure is evaluated to determine:

1. Whether all processes link together appropriately
   
2. Are all processes being performed in the proper timeframe
   
3. Are the resources necessary for the process available when needed
   
4. Are all proposed processes consistent with the job descriptions of those expected to perform them
   
5. Are all proposed processes consistent with the functional descriptions or charters of the organizations to which they have been delegated
   
6. Do the people charged with the responsibility for performance of the processes have the necessary authorities
   
7. Whether the supervisory personnel understand the processes in the same way that the persons actually performing them do.

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.

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 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 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:

1. Are the process time constraints similar between and across processes, and are all processes aware of those constraints?
   
2. Have all processes been identified?
   
3. Are there accompanying narratives for each process as a whole and for each component task?
4. Are all inputs, outputs, data storage and retrieval activities, and forms, reports and transactions for each process clearly identified and described?
   
5. Have all forward and backward references for these been clearly indicated and do those references have corresponding references in the sourcing or receiving process?

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:

1. does this need to be done?
   
2. are all the steps correct? And, are they all necessary?
   
3. should this task or process be performed by the current unit?
   
4. Does the work accomplished justify the resources being devoted to it?
   
5. For each report:
   • Is this report necessary?
     
   • If it is necessary, is it necessary in its current form?
     
   • To its current level of detail?
     
   • Should it be produced as frequently as it is?

6. For each process:
   • Is it still necessary?
     
   • Does it need to be performed as frequently as it is?
     
   • If manual should it be automated, and if currently automated, should it revert to manual?
     
   • Do the procedures and standards which govern the process still apply, or should they be revised? made simpler? made more comprehensive?
     
   • Can it be combined with another similar processes?
     
   • Has it grown so complex that it needs to be fragmented into a larger number of more simplified processes?
     
   • Can the cost of the process be justified in terms of the benefit to the firm?
     
   • Does the volume of work expected justify the size of the organization or the resources devoted to it?

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:

1. Missing data
2. Inefficiencies in processing
3. Difficulties in data access
4. Cumbersome procedures
5. Procedures which did not reflect how activities were actually performed
6. Procedures which specified actions which were no longer necessary<
7. Missing procedures
8. Users were asked to identify areas where responsibilities for activities were either not specified, or where responsibility for certain activities were accompanied by the appropriate authorities.
9. Activities where responsibilities were split - where responsibility was shared across multiple functions - were identified.
10. Identical or highly similar activities which were performed in multiple areas were identified.
11. Activities which appeared to be aimed at accomplishing the same purpose but which were performed in highly dissimilar manners were identified, and the causes for those dissimilarities were identified.

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.

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.

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:

1. a simple high, medium or low priority - reflecting perceived importance to the firm and the user
   
2. a simple scalar prioritization - where each item is assigned a number which places it in rank order such that the first item pair in the list is the most important, the second is next in importance, etc.
   
3. a complex scalar prioritization - where each item pair is assigned a degree of difficulty to implement, or a degree of importance, or both, and within the first a scalar prioritization. The result is a ranking of the most important items within another ranking method, i.e. most important high priority item (assuming there are multiples)

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:

• Changes in charter, responsibility assignment or technology; Development of a new product or service, new technology; Selection of a new market; Finalization of corporate reorganization;
  Movement to new location, or modernization of existing location, etc.
• Architectural and procedural changes - changes which once the foundation items are determined can be designed and developed. These are basic structural changes, and form the bulk of the difficult and usually time consuming system design tasks. These include changes in data gathering, validation, verification, storage and evaluation procedures. The also include all of the activities which aggregate and regroup those procedures to activities, the activities to processes, and the processes to systems
• Presentation, Display or Cosmetic changes - many changes which have been identified result from changes in user perception and perspective, or from increased user awareness of his environment and needs. These result in requests for changes in report form and content, faster access to existing data, or improved methods of accomplishing existing tasks. These changes usually do not require structural or architectural changes. Each of these changes while small in itself, when added to the vast number of other similar changes may require the largest part of the design team energy.

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:

1. the number of other changes which could be accomplished if this change is made
   
2. the number of other changes which would not be necessary if this change is made
   
3. the number of other changes which would be made easier if this change were made
   
4. the number of additional (and unanticipated) things which could be accomplished or goals which could be achieved if this change or combination of changes were made
   
5. if this change in combination with one or more other changes, if all made at the same time would increase any of the above (synergy)

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.

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.

1. Costs associated with developing the system "in-house"
   
2. Costs associated with acquiring a system externally
   
3. Any exceptional or specialized requirements which are unique to the firm
   
4. Number of externally available packages
   
5. Time frame in which the user needs the system
   
6. Development time estimates versus time to evaluate, select, install and modify an external package
   
7. Availability of internal personnel to develop the needed system "in-house"
   
8. The degree of comfort the analyst and user have in the firmness of the specifications for the system
   
9. The expected life of the proposed system
   
10. The presence of any proprietary information about the firm's operations or the user's system, which the firm may be unable or unwilling to release to outside firms or non-employees
    
11. Expected volatility of proposed system
    
12. Absence of specialized development or functional expertise within the firm which might be needed to developed the proposed system

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:

1. The systems maintainability
   
2. The availability of training
   
3. The level and quality of the documentation
   
4. Viability of the vendor
   
5. The experiences of other customers
   
6. Frequency of vendor maintenance and modification
   
7. Vendors support capability, including problem resolution, "hot-line" service, etc.
   
8. The ease with which the system can be enhanced by internal personnel
   
9. The impact of any company modification on any system warranties, guarantees, or service contracts
   
10. The relative currency of the software and hardware base of the package
    
11. Any related offerings by the same vendor
    
12. Any items or functions promised for future delivery
    
13. Testing periods, benchmark periods
    
14. Acquisition options, i.e. lease, franchise, license, purchase
    
15. The impact of any proprietary products or processing on the company
    
16. Any restrictions on disclosure, resale, etc.
    
17. Site licensing versus single CPU licensing, versus company wide licensing
    
18. Duplication restrictions on software, documentation or manuals
    
19. The willingness of the vendor to "customize" the package to the firm's specifications

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.

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:

1. Direct Manpower Costs - these costs are developed from the project plan for this phase. From that plan, should be extracted 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.

   A per period costs should be assigned on any one of the following bases:

   • standard cost - applicable to all personnel at all levels,
   • level by level costs - applicable to all personnel at each given level
   • 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 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.

2. Indirect Manpower Costs - these include project management, staff and administrative services which may be needed to support the project personnel. In this category would be project managers, area managers, secretarial, filing, etc. costs. These may be calculated in the same manner as direct costs, estimated, or taken as a percentage of the total development department administrative costs.

3. 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.

4. Printing and Graphics Costs - the development of charts, graphs, diagrams, and printing the final report (usually in multiple copies) should be estimated.

5. Space Costs - if staff must be assembled from diverse locations, it may be necessary to assign office space for them to work in during the project's duration. These costs should be calculated from the firms space budget costs and added to the project cost totals.

6. Machine Costs - these 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.

7. Supplies Costs - these include costs of paper, copier supplies, binders and covers for reports, pencils, pens, other stationary supplies, any special materials which may be necessary for the project.

8. Training Costs - these include any special training required by project personnel in terms of familiarization with specific business functions, special software, special machinery, general education, etc.

9. Special Software Costs - these 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 and the sum becomes the total project cost.

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:

1. Special user training costs - including all costs for training user personnel in the use of the new system, procedures, etc.
   
2. Special or new user documentation and user forms - including 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 - including user owned computers, terminals, printers, Personal Computers, communications devices, security devices, etc.
   
4. Special user software license or acquisition costs - including additional copies of PC software, multiple site licenses for mainframe and minicomputer locations, on-going 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 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:

1. Direct or indirect manpower costs - these cost savings are calculated in the same manner as development direct and indirect manpower costs. These benefits are obtained from the reduced level of effort, or reduced level of staff which can be expected to be achieved if the project is successful.
   
2. Supply costs - these cost savings are calculated by estimating the reductions in supplies usage (paper, stationary, etc.) which can be expected to be achieved if the project is successful.
   
3. 3. Machine Costs - these cost savings are calculated by estimating the reductions in computer usage which can can be achieved 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 - these cost savings are calculated by estimating the reductions in travel and entertainment costs which can be expected to be achieved if the project is successful.
   
5. Interest or penalty costs - in many cases inefficient operations result in the company having to borrow money to finance its operations, or to incur penalties for late payments, etc.

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:

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, 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.