Risk Identification

Consists of categorizing risk into particular fields. In this sense project risk relates to budget, schedule, and staffing problems that may impact development. In this sense project type and complexity may pose additional risk factors. Technical risk is related to the possibility of encountering difficulties that were not initially anticipated. For example, an unexpected development in the field may make a project technically obsolete. Business risk, perhaps the most deluding one, relates to market changes, company strategy changes, sale difficulties, loss of management support, and loss of budgetary support.

Risk Estimation

Risk Assessment

Figure 2.2 shows the effects of cost and schedule overruns on a software project. The dark region bound by the curves (the uncertainty or break area) represents the region in which the decisions to stop or continue the project are approximately of equal weight. Below this area is the go region, in which the project continues without question. The area above the curve (no-go region) represents conditions that determine the cancellation of the project. Note that in Figure 2.2 we have considered only two project risks; often there are others that can influence the decision to terminate. The reader should not assign any meaning to the particular shape of the curve in Figure 2.2. The fact that it is not uniform simply indicates that the uncertainty factor in risk assessment may not be a smooth function.

The following steps are usually followed during the risk assessment process:

1. The referent level is defined for each significant risk in the project.

2. The relationship between the risk, its likelihood, and its impact on the project is established for each referent level.

3. The termination region and the uncertainty area are defined.

4. An attempt is made to anticipate how a compound risk will affect the referent level for each participating risk.

Risk Management

Once the elements of risk description, likelihood, and impact have been established for each project risk, they can be used to minimize the particular risk or its effects. For example, assume that the analysis of historical data and the risk estimation process determine that for the particular project there is a substantial risk of schedule overruns due to low programmer productivity. Knowing this, management can attempt to locate alternative manpower sources which could be tapped if the identified risk is realized. Or perhaps steps can be taken to improve productivity by identifying the causes of low programmer output. Risk management, in itself, can become costly and time-consuming. Scores of risks can be identified in a large development project. Each risk may be associated with several risk management measures. Keeping track of risks and remedies can become a major project in itself. Therefore, managers and directors must sometimes perform cost-benefit analysis of the risk management activities to determine how it will impact project cost. The Pareto principle, sometimes called the 80/20 rule, states that 80 percent of project failures are related to 20 percent of identified risks. The risk analysis phase should help recognize this critical 20 percent, and eliminate the less significant risks from the risk management plan.

2.1.2 Risk Analysis in a Smaller Project

Risk analysis is a specialty field on which numerous monographs and textbooks have been published. A frivolous or careless attempt at risk analysis and management is often counterproductive. In the smaller software project it is common that specialized personnel are unavailable to perform accurate risk analysis. Furthermore, even if technically qualified personnel could be found, it is doubtful that a formal risk investigation would be economically justified. Consequently, most smaller projects take place with no real risk analysis and without a risk management plan. In this case the feasibility study or other project documents should clearly state that risk analysis and risk management efforts have not been performed, the reasons why this step was skipped, and the dangers that can result from the omission.Perhaps a greater danger than the total omission of a formal risk analysis is its trivialization. When risk analysis has been performed superficially, with little rigor, and by untrained personnel, the most likely results are the identification of unreal risks, or, worse, a false feeling of confidence resulting from a plan that has failed to identify the real perils associated with the project. If the risk analysis and management have been performed with less-than-adequate resources then the resulting low accuracy of the risk projection should be clearly noted in the project documentation. Occasionally, it may be considered valid to attempt some form of perfunctory risk analysis for the purpose of gaining experience in this field or for experimenting with a specific methodology. This should also be clearly noted so that management does not place undue confidence in the resulting plan.

Table 2.1 is a variation of the risk management and monitoring plan as presented by Charette. We have simplified the plan to include only those elements that, in our judgment, should never be omitted. Most computer systems development projects demand a tangible economic benefit. This does not mean that every system must generate a profit, but rather that the expected benefits must justify the cost. Exceptions to this rule are systems that are legally mandated or those whose purpose is beyond economic analysis, as could be the case with a project for national defense, or a scientific or academic experiment. Under normal circumstances the system’s economic justification is the most important result of the feasibility study since it is a critical factor in deciding project support.

Table 2.1 Simplification of a Risk Management Outline

I. Introduction

II. Risk Analysis

1. Risk Identification

a. Risk Survey

b. Risk Item Checklist

2. Risk Estimation

a. Probability of Risk

b. Consequence of Risk

c. Estimation Error

3. Risk Evaluation

a. Evaluation of Risk Analysis Methods

b. Evaluation of Risk Referents

c. Evaluation of Results

III. Risk Management

1. Recommendations

2. Options for Risk Aversion

3. Risk Monitoring Procedures

2.1.3 Cost-Benefit Analysis

Cost-benefit analysis is a standard business evaluation instrument, but not all project results can be exactly measured in dollars and cents. Some systems bring about less tangible benefits that relate to factors such as the company’s long-term plans, a higher quality of product or services, or increased employee morale. It could be a taxing task to attempt to attach a dollar value to some of the less concrete project benefits. It is often preferable to include a category of intangible benefits in the cost-benefit analysis document rather than to attempt to quantify these gains. The reference point for evaluating the benefits of a new system is usually the existing system. For example, a manufacturer called Acme Corporation plans to upgrade its present inventory management system with a new one based on the use of bar codes to identify products in stock. The new system requires an investment of $500,000 in software and computer equipment but has the following advantages:

1. The number of employees used in inventory management functions will be reduced by 4. This will bring about a saving of $90,000 per year.

2. The flow of materials and supplies to the assembly line will be improved, with an estimated reduction in lost time of 200 work hours per month. Since an hour of lost time at the assembly line costs

the company $12, this will bring about a saving of $2400 per month.

3. The better control of stocks will allow the company to reduce the size of its inventory. The smaller investment and the reduction in warehousing costs is estimated to bring the company a saving of

$20,000 per year.

In this case the cost-benefit analysis could appear as follows:

Acme Corporation

Cost-benefit analysis for new inventory management system over a 5-year period

1. COST

a. Computer and peripherals ................................. $300,000

b. Software ................................................. 110,000

c. Installation and technical support ....................... 90,000
===============

total investment ................. $500,000

2. BENEFITS

a. Personnel reductions .......... $450,000

b. Reductions in down time ....... 144,000

c. Savings in inventory costs .... 100,000

===============

total savings ............... $694,000

Balance ..................... $194,000

In the case of Acme Corporation the benefits over a five-year period are relatively modest. Therefore it is likely that Acme’s higher management would like to see a more detailed and accurate analysis before committing to a major overhaul of the company’s existing system. On the other hand, some systems can be economically justified clearly and definitively. Under different circumstances the development and implementation of a computerized inventory control would bring about savings that leave no doubt regarding the project’s benefits, even without considering less tangible factors such as improvements in distribution operations.

2.2 Requirements Analysis and Specification

Once the feasibility of a proposed system has been established, the next task that the analyst must undertake is defining the system’s requirements. Requirements analysis, or requirements engineering as it is sometimes called, has been considered a critical phase of computer systems development since the original conception of an engineering methodology for software development. The fundamental notion consists of generating an unambiguous and consistent specification that describes the essential functions of the proposed system. In other words, the specifications phase of the system development process must describe what the system is to do. How it is to do it is addressed during the design phase.

2.2.1 The Requirements Analysis Phase

Before the systems requirements can be specified, the interface between the system and the real world must be analyzed. Based on this interface, a set of specifications of the software requirements is developed. The documents containing the program specification play a decisive role during the entire development process. For example, the development of a software system to control the operation of a probe vehicle via remote to operate on the surface of the planet Mars should be based on a detailed analysis of the interface requirements. In this case the following elements may be considered critical:

1. What information is returned by the sensors on the Mars probe.

2. What vehicle operation controls installed on the probe are governed by the software.

3. What is the time lapse between perception by the probe’s sensors and reception by the earth system.

4. What is the time lapse between a command issued by the earth system and its execution by the probe.

The analysis of this data helps determine the operational specification of the system. In this case the delay in receiving information and transmitting commands may require that upon sensing certain types of obstacles, the vehicle come to a stop until a command signal is received. In this case the requirements analysis phase serves to define the system specifications. Concrete system specification guidelines result from the requirements analysis phase. In particular this could refer to difficulties, tradeoffs, and conflicting constraints; also from the functional and nonfunctional requirements. Functional requirements are those which are absolutely essential while the nonfunctional ones are merely desirable features. In this sense a functional requirement of the Martian probe could be that the vehicle not be damaged by obstacles in its path. A nonfunctional requirement could be that given several possible safe paths to a destination point, the software selects the one that can be traversed in the shortest time.

Customer/User Participation

An ideal scenario is that the customer, client, or eventual user of a system provides the detailed specification. In this “neat” world all the developer has to do is implement a system according to these specifications thus ensuring that the client’s needs are thoroughly satisfied. In reality the customer/user often has little more than a sketchy idea of the intended system; its specification must be developed through a series of interviews, proposals, models, and revisions. Communications skills and systems analysis experience are important factors in the success of this difficult and critical phase.

The developer of systems specifications must not assume that a customer does not really know what he or she wants. It is the client’s system, not the developer’s. New systems often encounter considerable resistance from employees who must devote time and effort to learning its operation, often with little or no compensation. Furthermore, employees may feel threatened by a new system which could make their jobs unnecessary. The more participation that clients and users have in the systems specifications and definition the less resistance that they will present to its implementation. If there is a single secret to being a successful analyst it is to maximize the client’s participation in the specification, design, development, and implementation phases, thus making sure that the participants include those who will be the effective users of the new system. A regrettable situation is that the developer initially deals with an administrative elite, while the actual systems operators, administrators, and users do not become visible until much later in the development process.

The Virtual Customer

While in many development projects there is a clearly identifiable customer, in others the client role is not quite visible. For example, a software company developing a program that is to be marketed to the public may not have a visible client who can participate in the system’s specification, design, and development phases. Another example: a research group at a university or a private firm is often confronted with the task of developing a program for which no user or client is immediately at hand. The customer/user element plays such an important role in the development process that in these cases it may be advisable to invent some sort of a virtual participant to play this role. In the context of research and development, the team’s director sometimes takes on this function. Or perhaps a higher level of management will play the devil’s advocate for the duration. As separation of powers ensures the operation of a democracy, separation of interests between clients and developers promotes the creation of better systems. When this duality does not naturally exist, creating it fictitiously may be an option.

2.2.2 The Specifications Phase

Once the systems requirements have been determined the analyst creates a list of program specifications. These specifications serve to design, code, and test the proposed program and, eventually, validate the entire development effort; their importance can hardly be overstressed. Since specifications are derived directly from the requirement analysis documents, a preliminary step to

composing a list of specifications is to validate the requirements analysis phase. Whatever method or notation is used in requirements analysis, the following goals should be achieved:

1. Information contents and flow are determined.

2. Processes are defined.

3. Systems interfaces are established.

4. Layers of abstraction are drawn and processing tasks are partitioned into functions.

5. A diagram of the system essentials and its implementation is made.

We can adopt varying degrees of formality and rigor in composing the actual specifications. Many difficulties in system design and coding can be traced to imprecise specifications. The English language (in fact, any natural language) contains terms and expressions that require interpretation. For example: the statement that a routine to calculate mathematical functions must do so with the “highest possible degree of precision” may seem a strict specification. However, at system design and coding time the expression “the highest possible degree of precision” has to be interpreted to mean one of the following:

1. The precision of the most accurate computer in the world.

2. The precision of the most accurate machine of a certain type.

3. The highest precision that can be achieved in any high-level language.

4. The highest precision that can be achieved in a particular programming language.

5. The highest precision that can be achieved in a certain machine.

6. The highest precision that will be required by the most demanding user or application.

7. The highest degree of precision that will be required by the average user or application.

This list could be easily expanded to include many other alternatives. On the other hand, the specifications could have stated that mathematical functions will be calculated “so that the resulting error will not exceed 20 units of machine Epsilon.” In this case very little interpretation is possible at design or coding time. Furthermore, the specification could later be used to validate the resulting product by performing tests that ascertain that the numerical error of the mathematical calculations is within the allowed error range. In recent years the software engineering and programming communities have moved towards stricter and more formal methods of specification, some of which are discussed later in this section. The analyst should be wary of imprecise terms and expressions in the specification documents and should aim at describing the problems and tasks at hand in the least unambiguous terms possible.

The Software Specifications Document

The Software Specifications Document (SSD), also called the Software Requirements Specification, is the culmination and the conclusion of the system analysis. The elements always present in the SSD include the following:

1. An information description

2. A functional description

3. A list of performance requirements

4. A list of design constraints

5. A system testing parameters and a criterion for validation

The National Bureau of Standards, the IEEE, and others have proposed formats for the SSD. Table 2.2 is a simplified outline of the fundamental topics that must be visited in this document.

Headington and Riley propose a six-step program specifications plan consisting of the following parts:

1. Problem title

2. Description

3. Input specifications

4. Output specifications

5. Error handling

6. Sample program execution (test suite)

Table 2.2 Outline of the Software Specifications Document

I. Introduction

1. Purpose and Scope

2. System Overview

3. General Description and Constraints

II. Standards and Conventions

III. Environment Elements

1. Hardware Environment

2. Software Environment

3. Interfaces

IV. Software Specifications

1. Information Flow

2. Information Contents

3. Functional Organization

4. Description of Operations

5. Description of Control Functions

6. Description of System Behavior

7. Database and Data Structures

V. Testing and Validation

1. Performance Parameters

2. Tests and Expected Response

3. Validation Protocol

VI. Appendices

1. Glossary

2. References

Although this simplification is intended for the specification of small projects within the context of an undergraduate course in C++ programming, it does cover the fundamental elements. Even if it is not used as a model, it may be a good idea to check the actual specification against this plan.