lOMoARcPSD|29067427

Unit 2 Part 1: Software Project Management & Requirements

Analysis
English A: Language and Literature SL (Dr. Datar Science, Dr. Behere Arts and Shri.
Pilukaka Joshi Commerce College)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by Dr. KK ([email protected])
 lOMoARcPSD|29067427

UNIT 2
Part 1
Software project management:
1. Software project management complexities
2. Responsibilities of a software project manager
3. Metrics for project size estimation
4. Project estimation techniques
5. Empirical estimation techniques
6. COCOMO
7. HALSTEAD’S SOFTWARE SCIENCE
8. RISK MANAGEMENT
Part 2
Requirements analysis and specification:
1. Requirements gathering and analysis
2. Software requirements specification (SRS)
3. Formal system specification
4. Axiomatic specification
5. Algebraic specification
6. Executable specification and 4GL
1. Software project management complexities
Management of software projects is much more complex than management of many other
types of projects. The main factors contributing to the complexity of managing a
software project are the following:
Invisibility: Invisibility of software makes it difÏcult to assess the progress of a project and is a
major cause for the complexity of managing a software project.
Changeability: Frequent changes to the requirements and the invisibility of software are possibly
the two major factors making software project management a complex task.
Complexity: Even a moderate sized software has millions of parts (functions) that interact
with each other in many ways—data coupling(degree of interdependence between software
modules based on the data they exchange.), serial and concurrent runs, state transitions, control
dependency, file sharing, etc. This makes managing these projects much more difÏcult as
compared to many other kinds of projects.
Uniqueness: Every software project is usually associated with many unique features or
situations. This makes every project much different from the others. Due to the uniqueness of the
software projects, a project manager in the course of a project faces many issues that are quite

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

unlike the ones he/she might have encountered in the past. As a result, a software project
manager has to confront many unanticipated issues in almost every project that he manages.
Exactness of the solution: conformity with the function definition. This requirement not only
makes it difÏcult to get a software product up and working, but also makes reusing parts of one
software product in another difÏcult. This requirement of exact conformity of the parameters of a
function introduces additional risks and contributes to the complexity of managing software
projects.
Team-oriented and intellect-intensive work: In a software development project, the life cycle
activities not only highly intellect-intensive, but each member has to typically interact, review,
and interface with several other members, constituting another dimension of complexity of
software projects.
2. Responsibilities of a software project manager
 Job Responsibilities for Managing Software Projects
 Skills Necessary for Managing Software Projects
Job Responsibilities for Managing Software Projects
A software project manager takes the overall responsibility of project. The job responsibilities of a project
manager ranges from invisible activities like building up of team morale to highly visible customer
presentations.
Most managers take responsibilities for project proposal writing, project cost estimation, scheduling,
project stafÏng, project monitoring and control, software configuration management, risk management,
managerial report writing and presentation, and interfacing with clients. These activities are certainly
numerous and varied.
We can broadly classify a project manager’s varied responsibilities into the following two major categories:
 Project planning: Project planning is undertaken immediately after the feasibility study phase and
before the starting of the requirements analysis and specification phase. The initial project plans
are revised from time to time as the project progresses
Estimation: The following project attributes are estimated.
Cost: How much is it going to cost to develop the software product?
Duration: How long is it going to take to develop the product?
Effort: How much effort would be necessary to develop the product?
The effectiveness of all later planning activities such as scheduling and staffing are
dependent on the accuracy with which these three estimations have been made.
Scheduling: After all the necessary project parameters have been estimated, the
schedules
for manpower and other resources are developed.
StafÏng: Staff organisation and staffing plans are made.
Risk management: This includes risk identification, analysis, and abatement
planning.
Miscellaneous plans: This includes making several other plans such as quality
assurance
plan, and configuration management plan, etc

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

Sliding Window Planning

In the sliding window planning technique, starting with an initial plan, the project is planned more
accurately over a number of stages.
The SPMP Document of Project Planning
Once project planning is complete, project managers document their plans in a software
project management plan (SPMP) document. Listed below are the different items that the
SPMP document should discuss. This list can be used as a possible organisation of the
SPMP document.
Organisation of the software project management plan (SPMP) document
1. Introduction
(a) Objectives
(b) Major Functions
(c) Performance Issues
(d) Management and Technical Constraints
2. Project estimates
(a) Historical Data Used
(b) Estimation Techniques Used
(c) Effort, Resource, Cost, and Project Duration Estimates
3. Schedule
(a) Work Breakdown Structure
(b) Task Network Representation
(c) Gantt Chart Representation
(d) PERT Chart Representation
4. Project resources
(a) People
(b) Hardware and Software
(c) Special Resources
In the sliding window planning
technique, starting with an
initial plan, the project is
planned more accurately over

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

a number of stages.
100 Fundamentals of Software Engineering
5. Staff organisation
(a) Team Structure
(b) Management Reporting
6. Risk management plan
(a) Risk Analysis
(b) Risk Identification
(c) Risk Estimation
(d) Risk Abatement Procedures
7. Project tracking and control plan
(a) Metrics to be tracked
(b) Tracking plan
(c) Control plan
8. Miscellaneous plans
(a) Process Tailoring
(b) Quality Assurance Plan
(c) Configuration Management Plan
(d) Validation and Verification
(e) System Testing Plan
(f) Delivery, Installation, and Maintenance Plan
 Project monitoring and control: Project monitoring and control activities are undertaken once the
development activities start.

Skills Necessary for Managing Software Projects

 Knowledge of project management techniques.
 Decision taking capabilities.
 Previous experience in managing similar projects.
3. Metrics for project size estimation
 Lines of Code (LOC)
 Function Point (FP) Metric

 Lines of Code (LOC)

LOC is possibly the simplest among all metrics available to measure project size. This
metric measures the size of a project by counting the number of source instructions in the
developed program. Obviously, while counting the number of source instructions,
comment lines, and header lines are ignored.

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

Determining the LOC count at the end of a project is very simple. However, accurate
estimation of LOC count at the beginning of a project is a very difÏcult task. One can
possibly estimate the LOC count at the starting of a project, only by using some form
of systematic guess work. Systematic guessing typically involves the following. The project
manager divides the problem into modules, and each module into sub-modules and so on,
until the LOC of the leaf-level modules are small enough to be predicted. To be
able to predict the LOC count for the various leaf-level modules sufÏciently accurately,
past experience in developing similar modules is very helpful. By adding the estimates
for all leaf level modules together, project managers arrive at the total size estimation.

 LOC is a measure of coding activity alone.

 LOC count depends on the choice of specific instructions.
 LOC measure correlates poorly with the quality and efÏciency of the code.
 LOC metric penalises use of higher-level programming languages and code reuse.
 LOC metric measures the lexical complexity of a program and does not address the more
important issues of logical and structural complexities.
 It is very difÏcult to accurately estimate LOC of the final program from problem
specification.

 Function Point (FP) Metric

Conceptually, the function point metric is based on the idea that a software product
supporting many features would certainly be of larger size than a product with less
number of features.

Function point (FP) metric computation

Step 1: Compute the unadjusted function point (UFP) using a heuristic expression.
Step 2: Refine UFP to reflect the actual complexities of the different parameters

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

used in UFP computation.

Step 3: Compute FP by further refining UFP to account for the specific
characteristics of the project that can influence the entire development effort.
Step 1: UFP computation
The unadjusted function points (UFP) is computed as the weighted sum of five characteristics
of a product as shown in the following expression.
UFP = (Number of inputs)*4 + (Number of outputs)*5 + (Number of inquiries)*4
+ (Number of files)*10 + (Number of interfaces)*10

1. Number of inputs
2. Number of outputs
3. Number of inquiries
4. Number of files
5. Number of interfaces
Step 2: Refine parameters
Step 3: Refine UFP based on complexity of the overall project
4. Project estimation techniques
The different parameters of a project that need to be estimated include—project size,
effort
required to complete the project, project duration, and cost. Large number of estimation
techniques have been proposed by researchers. These can broadly be classified into three
main categories:
 Empirical estimation techniques
 Heuristic techniques
 Analytical estimation techniques

 Empirical estimation techniques

While using this technique, prior experience with development of similar products is helpful.
Although empirical estimation techniques are based on common sense and subjective decisions,
over the years, the different activities involved in estimation have been formalised to a large
extent.
Expert Judgment
Expert Judgment is a widely used project estimation technique that relies on the experience and
expertise of individuals or groups familiar with similar projects or domains. This method is
commonly employed for estimating costs, schedules, resource needs, risks, and other project
parameters.

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

How Expert Judgment Works

1. Identify Experts:
o Select individuals or teams with relevant experience, skills, or domain knowledge.
Experts may include:
 Project managers
 Engineers
 Financial analysts
 Subject matter experts (SMEs)
2. Define the Problem/Scope:
o Provide the experts with detailed project information, including objectives,
requirements, constraints, and assumptions.
3. Gather Estimates:
o Experts analyze the information and provide their estimates based on their
knowledge and past experiences.
4. Review and Refine:
o Consolidate and evaluate the provided estimates, allowing for discussions and
refinements if necessary.
5. Document Estimates:
o Record the final estimates along with any supporting rationale or assumptions.
Delphi Cost Estimation method
The Delphi Cost Estimation method is a structured, iterative process used to gather expert
opinions for estimating the cost of a project. It is particularly useful when precise historical data is
unavailable, the project is complex, or the estimation requires consensus from multiple
stakeholders. Here’s an overview of the method:
How Delphi Cost Estimation Works
1. Select Experts:
o Identify a panel of experts with relevant knowledge and experience in the project
domain. These can be internal team members or external consultants.
2. Define the Scope:
o Clearly outline the project scope, objectives, assumptions, and requirements for
the experts to provide estimates.
3. First Round of Estimates:
o Experts independently provide cost estimates based on the information provided.
This step ensures anonymity to avoid bias or influence.
4. Compile and Share Results:

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

o A facilitator collects the estimates and summarizes them, often using statistical

measures like the mean, median, or range. The results are shared
with the panel, maintaining anonymity.
5. Second Round (Iterative Feedback):
o Experts review the summarized estimates and revise their own estimates based on
the group’s input and reasoning. This step aims to reduce the range of estimates.
6. Repeat Until Consensus:
o The process continues for multiple rounds until the group reaches a consensus or
the estimates converge within an acceptable range.
7. Finalize the Estimate:
o The agreed-upon cost estimate is documented as the final output.
 Heuristic techniques
Heuristic estimation techniques use mathematical formulas to estimate various aspects of a
project. They assume that there is a relationship between different project factors, and once
you know some basic information (like the size of the project), you can calculate other details
(like effort, time, or resources) using these relationships.
There are two main types of heuristic estimation models:
1. Single-Variable Models
 These models estimate a project parameter (like time or effort) based on one main
factor, usually the size of the software.
 The formula looks like this:

In the above expression, e represents a characteristic of the software that has already
been estimated (independent variable). Estimated Parameter is the dependent
parameter (to be estimated). The dependent parameter to be estimated could be
effort, project duration, staff size, etc., c1 and d1 are constants. The values of the
constants c1 and d1 are usually determined using data collected from past projects
(historical data). The COCOMO model is an example of a single variable cost
estimation model.
2. Multivariable Models
 These models estimate a project parameter based on more than one factor.
 The formula looks like this:

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

where, p1, p2, ... are the basic (independent) characteristics of the software already
estimated, and c1, c2, d1, d2, .... are constants.
Multivariable estimation models are expected to give more accurate estimates
compared to the single variable models, since a project parameter is typically
influenced by several independent parameters. The independent parameters
influence the dependent parameter to different extents. This is modelled by the
different sets of constants c1, d1, c2, d2, .... Values of these constants are usually
determined from an analysis of historical data.
The intermediate COCOMO model can be considered to be an example of a
multivariable estimation model.
 Why use multivariable models?
o Projects are usually affected by many factors, not just one. For example, effort
doesn’t just depend on size—it’s also affected by the project complexity, team
experience, tools used, and more.
o Multivariable models give more accurate estimates because they consider all
these factors.
 Analytical estimation techniques
Analytical estimation techniques derive the required results starting with certain basic
assumptions regarding a project. Unlike empirical and heuristic techniques, analytical techniques
do have certain scientific basis.
example :
Halstead’s software science
Starting with a few simple assumptions, Halstead’s software science derives some interesting
results.
Halstead’s software science is especially useful for estimating software maintenance efforts.
In fact, it outperforms both empirical and heuristic techniques as far as estimating software
maintenance efforts is concerned.
5. Empirical estimation techniques
 Expert Judgement
 Delphi Cost Estimation
6. COCOMO
COCOMO (Constructive Cost Model) is a popular estimation method used in software
development to calculate the effort, cost, and time required for a project. It is based on
mathematical formulas and historical project data.
There are four major variations of COCOMO, each increasing in complexity and accuracy:

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

1. Basic COCOMO Model

 Overview: The simplest version of COCOMO, which estimates project effort and time
based on the size of the software (measured in KLOC – thousands of lines of code).
Three basic classes of software development projects
Organic: We can classify a development project to be of organic type, if the project deals with
developing a well-understood application program, the size of the development team is
reasonably small, and the team members are experienced in developing similar types of
projects.
Semidetached: A development project can be classify to be of semidetached type, if
the development team consists of a mixture of experienced and inexperienced staff. Team
members may have limited experience on related systems but may be unfamiliar with
some aspects of the system being developed.
Embedded: A development project is considered to be of embedded type, if the
software being developed is strongly coupled to hardware, or if stringent regulations on
the operational procedures exist. Team members may have limited experience on related
systems but may be unfamiliar with some aspects of the system being developed.
What is a person-month?
Person-month (PM) is considered to be an appropriate unit for measuring effort, because
developers are typically assigned to a project for a certain number of months.

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

Observations from the development time—size plot

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

Problem:
Assume that the size of an organic type software product has been
estimated to be 32,000 lines of source code. Assume that the average salary of a software
developer is `15,000 per month. Determine the effort required to develop the software
product, the nominal development time, and the cost to develop the product.
Solution:
From the basic COCOMO estimation formula for organic software:
Effort = 2.4 × (32)1.05 = 91 PM 145 230
Nominal development time = 2.5 × (91)0.38 = 14 months 14 14
Staff cost required to develop the product = 91 ×15,000 = 1,365,000 2175000 34,50,000

2. Intermediate COCOMO
The intermediate COCOMO model refines the initial estimate obtained using the basic
COCOMO expressions.
The intermediate COCOMO model uses a set of 15 cost drivers (multipliers) that are
determined based on various attributes of software development.
These cost drivers are multiplied with the initial cost and effort estimates (obtained from the
basic COCOMO) to appropriately scale those up or down.
 Formula:

o EAF (Effort Adjustment Factor): Calculated based on the cost drivers.

 Use Case: Provides more accurate estimates by considering additional project-specific
factors.
3. Complete COCOMO (Detailed COCOMO)

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

 Overview: The most detailed version of COCOMO, breaking the project into smaller
components (modules) and applying the Intermediate COCOMO model to each
module separately.
 Key Features:
o Factors in the cost drivers for each module.
o Combines results to get a detailed project-wide estimate.
 Use Case: Used for large, complex projects where accurate estimation is critical.
4. COCOMO 2
 Overview: An updated version of COCOMO designed to handle modern software
development practices, including iterative and agile methodologies.
 Enhancements:
o Includes size estimation based on function points and object points (not just
lines of code).
o Supports reuse, reengineering, and maintenance effort estimation.
o Adjusted for rapid development tools and processes.
 Use Case: Best for modern, iterative development projects and when dealing with
reusable code and off-the-shelf components.
7. HALSTEAD’S SOFTWARE SCIENCE
 Halstead's Software Science is a method to analyze and measure software based on
the structure of the program code.
 It uses mathematical formulas to estimate things like code length, complexity, effort,
and time required for development and maintenance.
 Halstead’s software science is an analytical technique to measure size, development
effort, and development cost of software products.
 Halstead used a few primitive program parameters to develop the expressions for
overall program length, potential minimum volume, actual volume, language level,
effort, and development time.
For a given program, let:
 η1 be the number of unique operators used in the program,
 η2 be the number of unique operands used in the program,
 N1 be the total number of operators used in the program,
 N2 be the total number of operands used in the program.
Below are the key components:

Length and Vocabulary

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

 Length (N): The total number of operators and operands in the program.
 Vocabulary (n): The number of unique operators and operands in the program.
o Operators: Symbols like +, -, or keywords like if, while.
o Operands: Variables, constants, or data items used in the program.
Program Volume
 Program Volume (V): A measure of the size of the program in terms of the amount of
information it contains.


o N: Length of the program (total operators and operands).
o n: Vocabulary of the program (unique operators and operands).
Potential Minimum Volume
 Potential Minimum Volume (V):* The smallest possible program volume for the given
functionality.

o n₂: Number of unique operands.

Effort and Time
 Effort (E): The amount of work needed to write or understand the program.
E = V 2/V*
o V: Program Volume.
o L: Level of abstraction (a measure of how well the code is written).
 Time (T): The estimated time to develop or maintain the program.
T = E/S
 where S is the speed of mental discriminations. The value of S has been empirically
developed from psychological reasoning, and its recommended value for
programming applications is 18.
o Formula: T=E÷18T = E \div 18
Length Estimation
 Halstead provides a way to estimate the length of a program based on the unique
operators and operands:

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

 n₁: Number of unique operators.

 n₂: Number of unique operands.
Why Use Halstead's Software Science?
 Helps estimate effort and time required for development.
 Useful for analyzing and improving code maintainability.
8. RISK MANAGEMENT
Risk Management Approaches
Risk Identification
Risk Assessment
Risk Mitigation
Boehm’s Top 10 Risks and Counter Measures

Risk Management Approaches

Reactive approaches:
Reactive approaches take no action until an unfavourable event occurs. Once an unfavourable
event occurs, these approaches try to contain the adverse effects associated with the risk
and take steps to prevent future occurrence of the same risk events.

An example of such a risk management strategy can be the following. Consider a project in
which the server hosting the project data crashes. Once this risk event has occurred, the team
members may put best effort to recover the data and also initiate the practice of taking
regular backups, so that in future such a risk event does not recur.

Proactive approaches:
The proactive approaches try to anticipate the possible risks that the project is susceptible
to. After identifying the possible risks, actions are taken to eliminate the risks. If a risk
cannot be avoided, these approaches suggest making plans to contain the effect of the
risk.
For example, if man power turnover is anticipated (that is, some personnel may
leave the project), then thorough documentation may be planned. Also, more than one
developer may work on a work item and also some stand-by man power may be planned.

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

Obviously, proactive approaches incur lower cost and time overruns when risk events.
Risk Identification
The project manager needs to anticipate the risks in a project as early as
possible. As soon as a risk is identified, effective risk management plans are
made, so that the possible impact of the risks is minimised. So, early risk
identification is important.

Project risks: Project risks concern various forms of budgetary, schedule, personnel, resource,
and customer-related problems.

Since, software is intangible, it is very difÏcult to monitor and control a software project. It is
very difÏcult to control something which cannot be seen.

For any manufacturing project, such as manufacturing of cars, the project manager can see
the product taking shape. He can for instance, see that the engine is fitted, after that the
doors are fitted, the car is getÝng painted, etc. Thus he can accurately assess the progress of
the work and control it, if he finds any activity is progressing at a slower rate than what was
planned.

The invisibility of the product being developed is an important reason why many software
projects suffer from the risk of schedule slippage.
Technical risks: Technical risks concern potential design, implementation, interfacing, testing,
and maintenance problems. Technical risks also include ambiguous specification, incomplete
specification, changing specification, technical uncertainty, and technical obsolescence(not
using regularly). Most technical risks occur due the development team’s insufÏcient
knowledge about the product.
Business risks: This type of risks includes the risk of building an excellent product that no one
wants, losing budgetary commitments, etc.
Risk Assessment
The objective of risk assessment is to rank the risks in terms of their damage causing

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

potential. For risk assessment, first each risk should be rated in two ways:
 The likelihood(the probability that some thing would happen) of a risk becoming real
(r).
 The consequence of the problems associated with that risk (s).
Based on these two factors, the priority of each risk can be computed as follows:

p=r×s
where, p is the priority with which the risk must be handled, r is the probability of the
risk becoming real, and s is the severity of damage caused due to the risk becoming real.
Risk Mitigation
After all the identified risks of a project have been assessed, plans are made to contain the
most damaging and the most likely risks first. Different types of risks require different
containment procedures.
There are three main strategies for risk containment:
Avoid the risk: Risks can be avoided in several ways. Risks often arise due to project
constraints and can be avoided by suitably modifying the constraints. The different
categories of constraints that usually give rise to risks are:
Process-related risk: These risks arise due to aggressive work schedule, budget, and resource
utilisation.
Product-related risks: These risks arise due to commitment to challenging product features
(e.g. response time of one second, etc.), quality, reliability, etc.
Technology-related risks: These risks arise due to commitment to use certain technology (e.g.,
satellite communication).

Transfer the risk: This strategy involves getÝng the risky components developed by a third
party etc.
Risk reduction: This involves planning ways to contain the damage due to a risk. For
example, if there is risk that some key personnel might leave, new recruitment may be
planned. The most important risk reduction techniques for technical risks is to build a
prototype that tries out the technology that you are trying to use. For example, if you are
using a compiler for recognising user commands, you would have to construct a compiler
for a small and very primitive command language first.
There can be several strategies to cope up with a risk. To choose the most appropriate
strategy for handling a risk, the project manager must consider the cost of handling the
risk and the corresponding reduction of risk. For this we may compute the risk leverage
of the different risks. Risk leverage is the difference in risk exposure divided by the cost

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

of reducing the risk. More formally,

Boehm’s Top 10 Risks and Counter Measures

1. Personnel shortfall: This risk concerns shortfall of project personnel. The shortfall may show up
as either project personnel may lack some specific competence required for the project tasks or
personnel leaving the project (called manpower turnover) before project completion. The counter
measures suggested include stafÏng with top talent, job matching, team building, and cross
training of personnel.
2. Unrealistic schedules and budgets: The suggested counter measures include the project
manager working out the detailed milestones and making cost and schedule estimations based
on it. Other counter measures are incremental development, software reuse, and requirements
scrubbing. It may be mentioned that requirements scrubbing involves removing the overly
complex and unimportant requirements, in consultation with the customers.
3. Developing the wrong functions: The suggested counter measures include user surveys and
user participation, developing prototypes and eliciting user feedback, and early production users
manuals and getÝng user feedback on it.
4. Developing the wrong user interface: The counter measures suggested for this risk include
prototyping, scenarios and task analysis, and user participation.
5. Gold-plating: Gold-plating concerns development of features that the team members consider
nice to have and therefore decide to develop those even though the customer has not expressed
any necessity. The counter measures suggested for this risk include requirements scrubbing,
prototyping, and cost-benefit analysis.
6. Continuing stream of requirements changes: The counter measures suggested for this risk
include incremental development, high change threshold, and information hiding.
7. Shortfalls in externally-furnished components: This concerns the risk that the components
developed by third party are not up to the mark. The counter measures suggested for this risk
include benchmarking, inspections, reference checking, and
compatibility analysis.
8. Shortfalls in externally performed tasks: This concerns the risk that the work performed by the
contractors may not be up to the mark. The counter measures suggested for this risk include
reference checking, pre-award audits, award-fee contracts, competitive design or prototyping,
and team building.

Downloaded by Dr. KK ([email protected])

 lOMoARcPSD|29067427

9. Real-time performance shortfalls: The counter measures suggested for this risk include
simulation, benchmarking(companies best principles ), modelling, prototyping, instrumentation,
and tuning.
10. Training computer science capabilities: The counter measures suggested for this risk include
technical analysis, cost-benefit analysis, and prototyping.

Downloaded by Dr. KK ([email protected])