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, as identified by Brooks [1975], are the following:
Invisibility: Software remains invisible, until its development is complete and it is
operational. Anything that is invisible, is difficult to manage and control.
Invisibility of software makes it difficult to assess the progress of a project and is a
major cause for the complexity of managing a software project.
Changeability: Because the software part of any system is easier to change as
compared to the hardware part, the software part is the one that gets most
frequently changed. This is especially true in the later stages of a project.
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, serial and concurrent runs,
stale transitions, control dependency, file sharing, etc.
Uniqueness: Every software project is usually associated with many unique
features o situations. This makes every project much different from the others.
Exactness of the solution: Mechanical components such as nuts and bolts
typically work satisfactorily as long as they are within a tolerance of 1 per cent or
so of their specified sizes.
Team-oriented and intellect-intensive work: Software development projects are
akin to research projects in the sense that they both involve team-oriented,
intellect-intensive work.
RESPONSIBILITIES OF A SOFTWARE PROJECT MANAGER
In this section, we examine the principal job responsibilities of a project manager
and the skills necessary to accomplish those.
Job Responsibilities for Managing Software Projects:
A software project manager takes the overall responsibility of steering a
project to success. This surely is a very hazy job description. In fact, it is very
difficult to objectively describe the precise job responsibilities of a project
manager.
We can broadly classify a project manager's varied responsibilities into the
following two major categories:
 Project planning, and
 Project monitoring and control
Project planning: Project planning is undertaken immediately after the feasibility
study phase and before the starting of the requirements analysis and specification
phase.
Project planning involves estimating several characteristics of a project and
then planning the project activities based on these estimates made.
Project monitoring and control: Project monitoring and control activities are
undertaken once the development activities start.
The focus of project monitoring and control activities is to ensure that the
software development proceeds as per plan.
Skills Necessary for Managing Software Projects:
A theoretical knowledge of various project management techniques is
certainly important to become a successful project manager.
Three skills that are most critical to successful project management are the
following:
 Knowledge of project management techniques.
 Decision taking capabilities.
 Previous experience in managing similar projects.
PROJECT PLANNING:
Once a project has been found to be feasible, software project managers
undertake project planning. Project planning requires utmost care and attention
since commitment to unrealistic time and resource estimates result in schedule
slippage.
Initial project planning is undertaken and completed before any development
activity starts.
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?
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.

Sliding Window Planning

It is usually very difficult to make accurate plans for large projects at project
initiation. A part of the difficulty arises from the fact that large projects may take
several years to complete.
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 organization of the SPMP document.
Organization 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
5. Staff Organization
(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
METRICS FOR PROJECT SIZE ESTIMATION
The project size is a measure of the problem complexity in terms of the
effort and time required to develop the product.
As already mentioned, accurate estimation of project estimation of all other
project parameters such as effort, completion time, and total project cost.
Lines of Code (LOC):
LOC is possibly the simplest among all metrics available to measure project
size. Consequently, this metric is extremely popular. This metric measures the size
of a project by counting the number of source instructions in the developed
program.
LOC is a measure of coding activity alone. A good problem size measure should
consider the total effort needed to carry out various life cycle activities (Le
specification, design, code, test, etc.) and not just the coding effort.
The implicit assumption made by the LOC metric that the overall product
development effort is solely determined from the coding effort alone is flawed,
LOC count depends on the choice of specific instructions: LOC gives a
numerical value of problem size that can vary widely with coding styles of
individual programmers.
 Even for the same programming problem, different programmers might
come up with programs having very different LOC counts. This situation does not
improve, even if language tokens are counted instead of lines of code.
LOC measure correlates poorly with the quality and efficiency of the code:
Larger code size does not necessarily imply better quality of code or higher
efficiency.
LOC metric penalizes use of higher-level programming languages and code
reuse: paradox is that if a programmer consciously uses several library routines,
then the LOC count will be lower.
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 difficult to accurately estimate LOC of the final program from
problem specification.
Function Point (FP) Metric
Function point metric was proposed by Albrecht and Gaffney in 1983. This
metric overcomes many of the shortcomings of the LOC metric. Since its
inception, function point metric has steadily gained popularity Function point
metric has several advantages over LOC metric.
Conceptually, the function point metric is based on the idea that a software
product supporting many features would certainly be of larger sixe than a product
with less number of features.

FIGURE: System function as a mapping of input data to output data

Function point (FP) metric computation:
The size of a software product (in units of function points or FPs) is computed
using different characteristics of the product identified in its requirements
specification. It is computed using the following three steps:
Step 1: Compute the unadjusted function point (UFP) using a heuristic expression.

Step 2: Refine UTP to reflect the actual complexities of the different parameters
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.
We discuss these three steps in more detail in the following.
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. The weights
associated with the fie characteristics were determined empirically by Albrecht
through data gathered from many projects.

UFP= (Number of inputs) *4 + (Number of outputs)*5 + (Number of inquiries)*4+

10 (Number of files) *10 + (Number of interfaces)*10
The meanings of the different parameters of Eq. (3.1) are as follows:
1. Number of inputs: Each data items input by the user is counted.
2. Number of outputs: The outputs considered include reports printed, screen
outputs, error messages produced, etc.
3. Number of inquiries: An inquiry is a user command (without any data input)
and only requires some actions to be performed by the system.
4. Number of files: The files referred to here are logical files. A logical file
represents a group of logically related data. Logical files include data structures as
well as physical files.
5. Number of interfaces: Here the interfaces denote the different mechanisms that
are used to exchange information with other systems Examples of such interfaces
are data files on tapes, disks, communication links with other systems, etc.
Step 2: Refine parameters:
UFP computed at the end of step 1 is a gross indicator of the problem size. This
UFP needs to be refined by taking into account various peculiarities of the project.
Step 3: Refine UFP based on complexity of the overall project:
In the final step, several factors that can impact the overall project size are
considered to refine the UFP computed in step 2.
PROJECT ESTIMATION TECHNIQUES:
Estimation of various project parameters is an important project planning
activity. The different parameters of a project that need to be estimated include-
project size, effort required to complete the project, project duration, and cost.
These can broadly be classified into three main categories:

 Empirical estimation techniques

 Heuristic techniques
 Analytical estimation techniques
Empirical Estimation Techniques:
Empirical estimation techniques are essentially based on making an educated
guess of the project parameters. While using this technique, prior experience with
development of similar products is helpful.
Heuristic Techniques:
Heuristic techniques assume that the relationships that exist among the different
project parameters can be satisfactorily modelled using suitable mathematical
expressions. Once the basic (independent) parameters are known, the other
(dependent) parameters can be easily determined by substituting the values of the
independent parameters in the corresponding mathematical expression.
Estimated Parameter=c1xed1
Estimated Resource=c1xpd1+ c2xed2+…..
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.
EMPIRICAL ESTIMATION TECHNIQUES:
We have already pointed out that empirical estimation techniques have, over
the years, been formalized to a certain extent. Yet, these are still essentially
euphemisms for pure guess work.
Expert Judgment:
Expert judgment is a widely used size estimation technique. In this
technique, an expert makes an educated guess about the problem size after
analyzing the problem thoroughly.
A more refined form of expert judgment is the estimation made by a group
of experts. Chances of errors arising out of issues such as individual oversight, lack
of familiarity with a particular aspect of a project, personal bias, and the desire to
win contract through overly optimistic estimates is minimized when the estimation
is done by a group of experts.
Delphi Cost Estimation:
Delphi cost estimation technique tries to overcome some of the
shortcomings of the expert judgment approach. Delphi estimation is carried out by
a team comprising a group of experts and a coordinator. In this approach, the
coordinator. Provides each estimator with a copy of the software requirements
specification (SRS) document and a form for recording his cost estimate.

COCOMO-A HEURISTIC ESTIMATION TECHNIQUE:

Constructive COst estimation MOdel (COCOMO) was proposed by Boehm
[1981]. COCOMO prescribes a three stage process for project estimation. In the
first stage, an initial estimate is arrived at. Over the next two stages, the initial
estimate is refined to arrive at a more accurate estimate. COCOMO uses both
single and multivariable estimation models at different stages of estimation.
 The three stages of COCOMO estimation technique are-basic COCOMO,
intermediate COCOMO, and complete COCOMO. We discuss these three stages
of estimation in the following subsection.
Basic COCOMO Model:
Boehm postulated that any software development project can be classified
into one of the following three categories based on the development complexity-
organic, semidetached, and embedded. Based on the category of a software
development project, he gave different sets of formulas to estimate the effort and
duration from the size estimate.
Three basic classes of software development projects
In order to classify a project into the identified categories, Boehm requires
us to consider not only the characteristics of the product but also those of the
development team and development environment.
Brooks [1975] states that utility programs are roughly three times as difficult
to write as application programs and system programs are roughly three times as
difficult as utility programs.
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.
One person month is the effort an individual can typically put in a month.
The person- month estimate implicitly takes into account the productivity losses
that normally occur due to time lost in holidays, weekly offs, coffee breaks, etc.
General form of the COCOMO expressions:
The basic COCOMO model is a single variable heuristic model that gives an
approximate estimate of the project parameters. The basic COCOMO estimation
model is given by expressions of the following forms:

Effort=a1(KLOC)a2 PM
Tdev = b1 x (Effort)b2 months
Where,
 KLOC is the estimated size of the software product expressed in Kilo Lines
Of Code
 A1,a2,b1,b2 are constants for each category of software product.
 Tdev is the estimated time to develop the software, expressed in months.
 Effort is the total effort required to develop the software product, expressed
in person-months (PMs).
Estimation of development effort: For the three classes of software products, the
formulas for estimating the effort based on the code size are shown below.
Organic : Effort =2.4(KLOC)1.05 PM
Semi-detached: Effort =3.0(KLOC)1.12 PM
Embedded : Effort =3.6(KLOC)1.20 PM
Estimation of development time: For the three classes of software products, the
formulas for estimating the time based on the code size are shown below.
Organic : Tdev=2.5(Effort)0.38 Months
Semi-detached : Tdev=2.5(Effort) 0.35 Months
Embedded : Tdev=2.5(Effort) 0.32 Months
Observations from the effort-size plot:
From Figure 3.4, we can observe that the effort is somewhat superlinear (that is,
slope of the curve>1) in the size of the software product.
Observations from the development time-size plot:
The development time versus the product size in KLOC is plotted in Figure 35.
From Figure 35, we can observe the following:

 The development time is a sublinear function of the size of the product

 From Figure 3.5 we can observe that for a project of any given size, the
development time is roughly the same for all the three categories of
products. For example, a 60 KLOC program can be developed in
approximately 18 months, regardless of whether it is of organic, semi-
detached, or embedded type.

Cost estimation:
From the effort estimation, project cost can be obtained by multiplying the (in
man-month) by the manpower cost per month.
Implications of effort and duration estimate:
An important implicit implication of the COCOMO estimates are that if you try to
complete the project in a time shorter than the estimated duration, then the cost will
increase drastically. But, if you complete the project over a longer period of time
than that estimated, then there is almost no decrease in the estimated cost value.
The effort and duration values computed by COCOMO are the values for
completing the work in the shortest time without unduly increasing manpower
cost,
Staff-size estimation:
Given the estimations for the project development effort and the nominal
development time, can the required staffing level be determined by a simple
division of the effort estimation by the duration estimation? The answer is "No".
Intermediate COCOMO:
The basic COCOMO model assumes that effort and development time are
functions ef the product size alone. However, a host of other project parameters
besides the product size affect the effort as well as the time required to develop the
product. For example the effort to develop a product would vary depending upon
the sophistication of the development environment
The intermediate COCOMO model refines the initial estimate obtained
using the basic COCOMO expressions by scaling the estimate up or down based
on the evaluation of a set of attributes of software development.
Product: The characteristics of the product that are considered include the inherent
complexity of the product, reliability requirements of the product, etc.
Computer: Characteristics of the computer that are considered include the
execution speed required, storage space required, etc.
Personnel: The attributes of development personnel that are considered include
the experience level of personnel, their programming capability, analysis
capability, etc.
Development environment: Development environment attributes capture the
development facilities available to the developers. An important parameter that is
considered is the sophistication of the automation (CASE) tools used for software
development,
Complete COCOMO:
A major shortcoming of both the basic and the intermediate COCOMO models is
that they consider a software product as a single homogeneous entity. However,
most large systems are made up of several smaller sub-systems. These sub-systems
often have widely different characteristics.
The complete COCOMO model considers these differences in
characteristics of the subsystems and estimates the effort and development time as
the sum of the estimates for the individual sub-systems.
 Database part
 Graphical user interface (GUI) part
 Communication part
COCOMO 2:
Since the time that COCOMO estimation model was proposed in the early
1980s, the software development paradigms as well as the characteristics of
development projects have undergone a sea change.

Application composition model:

The application composition model is based on counting the number of screens,
reports, and modules (components). Each of these components is considered to be
an object (this has nothing to do with the concept of objects in the object-oriented
paradigm). These are used to compute the object points of the application.
Effort is estimated in the application composition model as follows:
 1. Estimate the number of screens, reports, and modules (components) from an
analysis of the SRS document.
2. Determine the complexity level of each screen and report, and rate these as
either simple, medium, or difficult. The complexity of a screen or a report is
determined by the number of tables and views it contains.
3. Use the weight values in Tables 1 to 3 below.

The weights have been designed to correspond to the amount of effort

required to implement an instance of an object at the assigned complexity
class.
TABLE 1: SCREEN Complexity Assignments for the Data Tables
Number of series Tables<4 Tables<8 Tables>=8
<3 Simple Simple Medium
3-7 Simple Medium Difficult
>8 Medium Difficult Difficult

TABLE 2 : Report Complexity Assignments for the Data Tables

Number of series Tables<4 Tables<8 Tables>=8
0 or 1 Simple Simple Medium
2 or 3 Simple Medium Difficult
4 or more Medium Difficult Difficult

4. Add all the assigned complexity values for the object instances together to
obtain the object points.
TABLE 3 : Table of Complexity Weights for Each Class for Each Object Type:
Object type Simple Medium Difficult
Screen 1 2 3
Report 2 5 8
3GL component 10
 5. Estimate percentage of reuse expected in the system. Note that reuse refers
to the amount of pre-developed software that will be used within the system.
Then, evaluate New Object-Point count (NOP) as follows,

NOP= ((Object-Point) (100-% of reuse))/ 100

6. Determine the productivity using Table 4. The productivity depends on the

experience of the developers as well as the maturity of the CASE
environment used.

7. Finally, the estimated effort in person-months is computed as E =NOP/

PROD
TABLE 3.6 Productivity Table
Developers Very low low Nominal High Very High
experience
CASE maturity Very low low Nominal High Very High
PRODUCTIVITY 4 7 13 25 50

Early design model:

The unadjusted function points (UFP) are counted and converted to source Iines of
code (SLOC) In a typical programming environment, each UFP would correspond
to about 128 lines of C. 29 lines of C++, or 320 lines of assembly code. Of course,
the conversion from UFP to LOC is environment specific, and depends on factors
such as extent of reusable libraries supported.
The effort is calculated using the following formula:
Effort KSLOC × Пi/ cost driver i
Post-architecture model:
The effort is calculated using the following formula, which is similar to the
original COCOMO model.
Effort=a x KSLOCb x Пi cost driver i
The post-architecture model differs from the original COCOMO model in the
choice of the set of cost drivers and the range of values of the exponent b.
HALSTEAD'S SOFTWARE SCIENCE-AN ANALYTICAL TECHNIQUE:
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:

 n1 be the number of unique operators used in the program,
 n2 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.
Operators and Operands for the ANSI C language
The following is a suggested list of operators for the ANSI C language:
( [ . , → * + - ~ ! ++ -- / % << >> < > <= >= != == & ^ | && || = *= /= %= += -=
<<= >>= &= |= ^= : ? { ; CASE DEFAULT IF ELSE SWITCH WHILE DO FOR
GOTO CONTINUE BREAK RETURN and a function name in a function call.
Length and Vocabulary:
The length of a program as defined by Halstead, quantifies total usage of all
operators and operands in the program. Thus, length N = N1+ N2.
The program vocabulary is the number of unique operators and operands used in
the program. Thus, program vocabulary eta = eta_{1} + eta_{2}
Program Volume:
The length of a program (te., the total number of operators and operands used in
the code) depends on the choice of the operators and operands used. In other
words, for the same programming problem, the length would depend on the
programming style.
V = N * log_2(eta)
Potential Minimum Volume:
The potential minimum volume V is defined as the volume of the most succinct
program in which a problem can be coded.
Effort and Time:
The effort required to develop a program can be obtained by dividing the program
volume with the level of the programming language used to develop the code.
Thus, effort E-V where E is the number of mental discriminations required to
implement the program and also the effort required to read and understand the
program. Thus, the programming effor E= V2 /V^ * since L =V^ * /V) varies as
the square of the volume.
Length Estimation:
Even though the length of a program can be found by calculating the total number
of operators and operands in a program, Halstead suggests a way to determine the
length of a program using the number of unique operators and operands used in the
program.
Halstead assumed that it is quite unlikely that a program has several identical parts-
in formal language terminology identical substrings of length greater than eta (eta
being the program [Link], of
N/eta <= eta ^ eta
N <= eta ^ (n + 1)
NORDEN’S WORK:
Norden concluded that the staffing pattern for any R&D project starting from a low
level, increases until it reaches a peak value. It then starts to diminish. This pattern
can be approximated by the Rayleigh distribution .
RISK MANAGEMENT:
Every project is susceptible to a large number of risks. Without effective
management of the risks, even the most meticulously planned project may go
haywire.
We need to distinguish between a risk which might occur from the risks that
have already become real and are currently being faced by a project.
A risk is any anticipated unfavourable event or circumstance that can occur
while a project is underway
Risk Management Approaches:
Risk management approaches can broadly be classified into reactive and proactive
approaches. The later approach is much more effective in risk handling and
therefore used wherever possible. In the following, we briefly discuss these two
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.
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.
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 minimized. So, early risk identification is
important. Risk identification is somewhat similar to the project manager listing
down his nightmares.
Project risks: Project risks concern various forms of budgetary, schedule,
personnel, resource, and customer-related problems. An important project risk is
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 .
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 potential. For risk assessment, first each risk should be rated in two ways:

 The likelihood 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=rxs
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. In fact, most risks require considerable
ingenuity on the part of the project manager in tackling the risks.
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 utilization.
(Product-related risks. These risks arise due to commitment to challenging product
features (eg. response time of one second, etc.), quality, reliability, etc.
Technology-related risks. These risks arise due to commitment to use certain
technology (eg. satellite communication)
Transfer the risk: This strategy involves getting the risky components developed
by a third party, buying insurance cover, 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.
risk leverage=( risk exposure before reduction -risk exposure after reduction)/ cost
of reduction
An example of handling schedule slippage risk
Risks relating to schedule slippage arise primarily due to the intangible nature of
software. For a project such as building a house, the progress can easily be seen
and assessed by the project manager.
Boehm's Top 10 Risks and Counter Measures:
Boehm has identified the top 10 risks that a typical project suffers from and has
recommended a set of counter measures for each of them. We briefly review these
in the following.
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 staffing 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 getting 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.
9. Real-time performance shortfalls: The counter measures suggested for this
risk include simulation, benchmarking, modelling, prototyping,
instrumentation, and tuning
10. Straining computer science capabilities: The counter measures suggested for
this risk include technical analysis, cost-benefit analysis, and prototyping.
REQUIREMENTS GATHERING AND ANALYSIS:
Requirements Gathering:
Requirements gathering activity is also popularly known as requirements
elicitation. The primary objective of the requirements gathering task is to collect
the requirements from the stakeholders.
A stakeholder is a source of the requirements and is usually a person, or a
group of persons who either directly or indirectly is concerned with the software.
1. Studying existing documentation:
The analyst usually studies all the available regarding the system to be
developed before visiting the customer site.
2. Interview: Typically, there are many different categories of users of a software.
Each category of users typically requires a different set of features from the
software. Therefore, it is important for the analyst to first identify the different
categories of users and then determine the requirements of each.
3. Task analysis: The users usually have a black-box view of a software and
consider the software as something that provides a set of services (functionalities).
A service supported by a software is also called a task.
Task analysis helps the analyst to understand the nitty-gritty of various user
tasks and to represent each task as a hierarchy of subcasks
4. Scenario analysis: A task can have many scenarios of operation. The different
scenarios of a task may take place when the task is invoked under different
situations. For different scenarios of a task, the behaviour of the software can be
different. For example, the possible scenarios for the book issue task of a library
automation software may be:

 Book is issued successfully to the member and the book issue slip is printed.
 The book is reserved, and hence cannot be issued to the member.
Requirements Analysis:
After requirements gathering is complete, the analyst analyses the gathered
requirements to form a clear understanding of the exact customer requirements and
to weed out any problems in the gathered requirements.
 The main purpose of the requirements analysis, activity is to analyze the
gathered requirements to remove all ambiguities, incompleteness, and
inconsistencies from the gathered customer requirements and to obtain a clear
understanding of the software to be developed.
During requirements analysis, the analyst needs to identify and resolve three
main types of problems in the requirements.
• Anormaly
• Inconsistency
• Incompleteness
SOFTWARE REQUIREMENTS SPECIFICATION (SRS):
After the analyst has gathered all the required information regarding the
software to be developed, and has removed all incompleteness, inconsistencies,
and anomalies from the specification, he starts to systematically organize the
requirements in the form of an SRS document. The SRS document usually contains
all the user requirements in a structured though an informal form
Users of SRS Document:
Usually a large number of different people need the SR5 document for very
different purposes. Some of the important categories of users of the SRS document
and their needs for use are as follows:
Users, customers, and marketing personnel: These stakeholders need to refer to
the SRS document to ensure that the system as described in the document will
meet their needs.
Software developers: The software developers refer to the SRS document to make
sure that they are developing exactly what is required by the customer
Test engineers: The test engineers use the SRS document to understand the
functionalities, and based on this write the test cases to validate its working,
User documentation writers: The User documentation writers need to read the
SRS document to ensure that they understand the features of the product well
enough to be able to write the users' manuals.
Project managers: The project managers refer to the SRS document to ensure that
they can estimate the cost of the project easily by referring to the SRS document
and that contains all the information required to plan the project

Maintenance engineers: The SRS document helps the maintenance engineers to

understand the functionalities supported by the system.
Why Spend Time and Resource to Develop an SRS Document?
A well-formulated SRS document finds a variety of usage other than the primary
intended usage as a basis for starting the software development work. In the
following subsection, we identify the important uses of a well-formulated SRS
document:
Forms an agreement between the customers and the developers: A good SRS
document sets the stage for the customers to form their expectation about the
software and the developers about what is expected from the software.
Reduces future reworks: The process of preparation of the SRS document forces
the stakeholders to rigorously think about all of the requirements before design and
development get underway.
Provides a basis for estimating costs and schedules: Project managers usually
estimate the size of the software from an analysis of the SRS document
Characteristics of a Good SRS Document:
The skill of writing a good SRS document usually comes from the experience
gained from writing SRS documents for many projects. However, the analyst
should be aware of the desirable qualities that every good SRS document should
[Link] Recommended Practice for Software Requirements Specifications
[IEEE, 1998) describes the content and qualities of a good software requirements
specification (SRS). Some of the identified desirable qualities of an SRS document
are the following:
 Concise: The SRS document should be concise and at the same time
unambiguous, consistent, and complete. Verbose and irrelevant descriptions
reduce readability and also increase the possibilities of errors in the
document.
  Implementation-independent: The SRS should be free of design and
implementation decisions unless those decisions reflect actual requirements.
It should only specify what the system should do and refrain from stating
how to do these.
The SRS document should describe the system (to be developed) as a black
box. and should specify only the externally visible behaviour of the system. For
this reason, the SRS document is also called the black-bar specification of the
software being developed.
Traceable: It should be possible to trace a specific requirement to the design
elements that implement it and vice versa. Similarly, it should be possible to trace
a requirement to the code segments that implement it and the test cases that test
this requirement and vice versa.
Modifiable: Customers frequently change the requirements during the software
development due to a variety of reasons. Therefore, in practice the SRS document
undergoes several revisions during software development.
Identification of response to undesired events: The SRS document should
discuss the system responses to various undesired events and exceptional
conditions that may arise.

Verifiable: All requirements of the system as documented in the SRS document

should be verifiable. This means that it should be possible to design test cases
based on the description of the functionality as to whether or not requirements have
been met in an implementation. A requirement such as "the system should be user
friendly" is not verifiable. On the other hand, the requirement--"When the name of
a book is entered, the software should display whether the book is available for
issue or it has been loaned out is verifiable. Any feature of the required system that
is not verifiable should be listed separately in the goals of the implementation
section of the SRS document.
Attributes of Bad SRS Documents:
SRS documents written by novices frequently suffer from a variety of problems.
As discussed earlier, the most damaging problems are incompleteness, ambiguity,
and contradictions. There are many other types of problems that a specification
document might suffer from.
 Some of the important categories of problems that many SRS documents suffer
from are as follows:
Over-specification: It occurs when the analyst tries to address the "how to"
aspects in the SRS document.
Forward references: One should not refer to aspects that are discussed much later
in the SRS document. Forward referencing seriously reduces readability of the
specification.
Wishful thinking: This type of problems concern description of aspects which
would be dificult to implement.
Noise: The term noise refers to presence of material not directly relevant to the
software development process .
Important Categories of Customer Requirements:
A good SRS document, should properly categorize and organise the
requirements into different sections [TEEE 830]. As per the IEEE 830 guidelines,
the important categories of user requirements are the following:
In the following subsections, we briefly describe the different categories of
requirements.
Functional requirements:
The functional requirements capture the functionalities required by the users
from the system.
Non-functional requirements:
The non-functional requirements are non-negotiable obligations that must be
supported by the software.
An SRS document should clearly document the following aspects of a software:
 Functional requirements
 Non-functional requirements
Design and implementation constraints
External Interfaces required
Other non-functional requirements
 Goals of implementation.
Functional Requirements:
In order to document the functional requirements of a system, it is necessary to
first learn to identify the high-level functions of the systems by reading the
informal documentation of the gathered requirements.
A high-level function is one using which the user can get some useful piece
of work done.
Are high-level functions of a system similar to mathematical functions?
For any given high-level function, there can be different interaction
sequences or scenarios due to users selecting different options or entering different
data items.
FORMAL SYSTEM SPECIFICATION:
In recent years, formal techniques have emerged as a central issue in software
engineering. This is not accidental, the importance of precise specification,
modelling, and verification is recognized to be important in most engineering
disciplines.
What is a Formal Technique?
A formal technique is a mathematical method to specify a hardware and/or
software system, verify whether a specification is realizable, verify that an
implementation satisfies its specification, prove properties of a system without
necessarily running the system, etc. The mathematical basis of a formal method is
provided by its specification language.
Syntactic domains:
The syntactic domain of a formal specification language consists of an
alphabet of symbols and a symbol and a set of formation rules to construct well-
formed formulas from the alphabet. The well-formed formulas are used to specify
a system.
Semantic domains:
Formal techniques can have considerably different semantic domains.
Abstract data type specification languages are used to specify algebras, theories,
and programs.
Satisfaction relation:
Given the model of a system, it is important to determine whether an
element of the semantic domain satisfies the specifications. This satisfaction is
determined by using a homomorphism known as semantic abstraction function.
Model versus property-oriented methods
Formal methods are usually classified into two broad categories-the so-
called model-oriented and the property-oriented approaches. In a model-oriented
style, one defines a system's behaviour directly by constructing a model of the
system in terms of mathematical structures such as tuples, relations, functions, sets,
sequences, etc. In the property-oriented style, the system's behaviour is defined
indirectly by stating its properties, usually in the form of a set of axioms that the
system must satisfy.
Operational Semantics:
Informally, the operational semantics of a formal method is the way computations
represented. There are different types of operational semantics according to what is
meet by a single run of the system and how the runs are grouped together to
describe the behaviour of the system. In the following subsection we discuss some
of the commonly used operational semantics.
Linear semantics: In this approach, a run of a system is described by a sequence
(possibly infinite) of events or states. The concurrent activities of the system are
represented by non-deterministic interleavings of the atomic actions
Branching semantics: In this approach, the behaviour of a system is represented
by a directed graph. The nodes of the graph represent the possible states in the
evolution of a system.
Maximally parallel semantics: In this approach, all the concurrent actions
enabled at any state are assumed to be taken together. This is again not a natural
model of concurrency since it implicitly assumes the availability of all the required
computational resources.
Partial order semantics: Under this view, the semantics ascribed to a system is a
structure of states satisfying a partial order relation among the states (events).
AXIOMATIC SPECIFICATION:
In axiomatic specification of a system, first-order logic is used to write the
pre- and post- conditions to specify the operations of the system in the form of
axioms. The pre-conditions basically capture the conditions that must be satisfied
before an operation can successfully be invoked
How to develop an axiomatic specifications?
The following are the sequence of steps that can be followed to systematically
develop the axiomatic specifications of a function:
 Establish the range of input values over which the function should behave
correctly Establish the constraints on the input parameters as a predicate.
 Specify a predicate defining the condition which must hold on the output of
the function if it behaved properly.
 Establish the changes made to the function's input parameters after execution
of the function. Pure mathematical functions do not change their input and
therefore this type of assertion is not necessary for pure functions.
 Combine all of the above into pre- and post-conditions of the function
ALGEBRAIC SPECIFICATION:
In the algebraic specification technique, an object class or type is specified
in terms of relationships existing between the operations defined on that type. It
was first brought into prominence by Guttag [1980, 1985] in specification of
abstract data types Various notations of algebraic specifications have evolved,
including those based on OBJ and Larch languages.
Types section: In this section, the sorts (or the data types) being used is specified.
Exception section: This section gives the names of the exceptional conditions that
might occur when different operations are carried out, These exception conditions
are used in the later sections of an algebraic specification.
Syntax section: This section defines the signatures of the interface procedures.
The collection of sets that form input domain of an operator and the sort where the
output is produced are called the signature of the operator. For example, PUSH
takes a stack and an element as its input and returns a new stack that has been
created
Equations section: This section gives a set of rewrite rules (or equations) defining
the meaning of the interface procedures in terms of each other. In general, this
section is allowed to contain conditional expressions.
Basic construction operators: These operators are used to create or modify
entities of a ype! The basic construction operators are essential to generate all
possible element of the ype being specified. For example, 'create' and 'append' are
basic construction operators.
Extra construction operators: These are the construction operators other than the
banc construction operators.
Basic inspection operators: These operators evaluate attributes of a type without
modifying them, eg, eval get, etc.
Extra inspection operators: These are the inspection operators that are not basic
inspectors. A simple way to determine whether an operator is a constructor (basic
or extra) or an inspector (basic or extra) is to check the syntax expression for the
operator
Structured Specification:
Developing algebraic specifications is time consuming. Therefore efforts
have been made to devise ways to ease the task of developing algebraic
specifications The following are some of the techniques that have successfully
been used to reduce the effort in writing the specifications.
Incremental specification: The idea behind incremental specification is to first
develop the specifications of the simple types and then specify more complex types
by using the specifications of the simple types.
Specification instantiation: This involves taking an existing specification which
has been developed using a generic parameter and instantiating it with some other
sort

Pros and Cons of algebraic specifications:

Algebraic specifications have a strong mathematical basis and can be viewed
as heterogeneous algebra.
EXECUTABLE SPECIFICATION AND 4GL:
When the specification of a system is expressed formally or is described by
using a programming language, then it becomes possible to directly execute the
specification without having to design and write code for implementation.
Specifications are usually slow and inefficient, 4GLs (4th Generation Languages)
are examples of executable specification languages. 4GLs are successful because
there is a lot of large granularity commonality across data processing applications
which have berm identified and mapped to program code. 4GLs get their power
from software reuse, where the common abstractions have been identified and
parameterized. Careful experiments have shown that rewriting 4Gl. programs in
3GLs results in up to 50 per cent lower memory usage and also the program
execution time can reduce up to tenfold.