| Article Index |
|---|
| System Description and Specification |
| Page 2 |
| Page 3 |
| Page 4 |
| Page 5 |
| All Pages |
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
In this phase of risk analysis we attempt to rate the likelihood and consequences of each risk. The first step is to establish the risk probability, the second one to describe the consequences of the risk, the third one to estimate the risk’s impact on the project, and finally to determine the accuracy of the risk estimate itself. These four items can be quantified with a “yes” or “no” answer, but a better approach is to establish a probability rating for risk likelihood, consequence, impact, and projection accuracy. Historical data collected by the developers can often serve to quantify some of the project risks. As a general rule we can assume that the higher the probability of occurrence and impact of a risk the more concern that it should generate.
Risk Assessment
Is based on the aforementioned impact and probability of occurrence of a risk, as determined during the risk estimation phase. The accuracy of the risk estimate is also a factor that must be taken into account. The first task at this stage is the establishment of acceptable risk levels for the project’s critical activities. For system development projects three typical critical activities are cost, schedule, and performance. A degradation of one or more of these factors will determine the project’s termination. Risk analysts talk about a referent point (or break point) at which the decision to terminate or continue a project is equally acceptable. Since risk analysis is not an exact science, the break point can better be visualized as a break area.
Figure 2.2 Referent Level in 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.
