UNIT II

SOFTWARE PROJECT MANAGEMENT

The main goal of software project management is to enable a group of developers to
work effectively towards the successful completion of a project.
As can be inferred from the above definition, project management involves use of a set
of techniques and skills to steer a project to success. Before focusing on these project
management techniques, let us first figure out who should be responsible for managing a
project. A project manager is usually an experienced member of the team who essentially works
as the administrative leader of the team.
For small software development projects, a single member of the team assumes the
responsibilities for both project management and technical management. For large projects,
a different member of the team (other than the project manager) assumes the responsibility of
technical leadership. The responsibilities of the technical leader includes addressing issues such
as which tools and techniques to use in the project, high-level solution to the problem,
specific algorithms to use, etc.
2.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, as identified by the following:
o Invisibility: Until the development of a software project is complete, Software remains
invisible. Anything that is invisible, is difficult to manage and control. Software project
managers cannot view the progress of the project due to the invisibility of the software
until it is completely developed. The project manager can monitor the modules of the
software that have been completed by the development team and the documents that
have been prepared, which are rough indicators of the progress achieved. Thus
invisibility causes a major problem in the complexity of managing a software project.
o Changeability: Requirements of a software product are undergone various changes.
Most of these change requirements come from the customer during the software
development. Sometimes these change requests resulted in redoing of some work,
which may cause various risks and increase expenses. Thus frequent changes to the
requirements play a major role to make software project management complex.
o Interaction: Even moderate-sized software has millions of parts (functions) that
interact with each other in many ways such as data coupling, serial and concurrent runs,
state transitions, control dependency, file sharing, etc. Due to the inherent complexity
of the functioning of a software product in terms of the basic parts making up the
software, many types of risks are associated with its development. This makes
managing software projects much more difficult compared to many other kinds of
projects.
o Uniqueness: Every software project is usually associated with many unique features or
situations. This makes every software product much different from the other software
projects. This is unlike the projects in other domains such as building construction,
 bridge construction, etc. where the projects are more predictable. Due to this uniqueness
of the software projects, during the software development, a project manager faces
many unknown problems that are quite dissimilar to other software projects that he had
encountered in the past. As a result, a software project manager has to confront many
unanticipated issues in almost every project that he manages.
o The exactness of the Solution: A small error can create a huge problem in a software
project. The solution must be exact according to its design. The parameters of a function
call in a program are required to be correct with the function definition. This
requirement of exact conformity of the parameters of a function introduces additional
risks and increases the complexity of managing software projects.
o Team-oriented and Intellect-intensive work: Software development projects are
team-oriented and intellect-intensive work. The software cannot be developed without
interaction between developers. In a software development project, the life cycle
activities are not only intellect-intensive, but each member has to typically interact,
review the work done by other members, and interface with several other team members
creating various complexity to manage software projects.
o The huge task regarding Estimation: One of the most important aspects of
software project management is Estimation. During project planning, a project manager
has to estimate the cost of the project, the probable duration to complete the project,
and how much effort is needed to complete the project based on size estimation. This
estimation is a very complex task, which increases the complexity of software project
management.
2.2 Responsibilities of a software Project Manager
The principal job responsibilities of a project manager and the skills necessary to
accomplish those.
2.2.1)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.
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 the
responsibilities for project proposal writing, project cost estimation, scheduling, project
staffing, software process tailoring, 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 still broadly classify these activities into two major types—project planning and
project monitoring and control.
We can broadly classify a project manager’s varied responsibilities into the following
two major categories:
• Project planning, and
• Project monitoring and control.
 In the following subsections, we give an overview of these two classes of
responsibilities.
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. The initial project plans are
revised from time to time as the project progresses and more project data become available.
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.
As the project gets underway, the details of the project that were unclear earlier at the
start of the project emerge and situations that were not visualised earlier arise.
2.2.2 Skills Necessary for Managing Software Projects
A theoretical knowledge of various project management techniques is certainly
important to become a successful project manager.
However, a purely theoretical knowledge of various project management techniques
would hardly make one a successful project manager.
Effective software project management calls for good qualitative judgment and
decision taking capabilities.
In addition to having a good grasp of the latest software project management
techniques such as cost estimation, risk management, and configuration management, etc.,
project managers need good communication skills and the ability to get work done. Some skills
such as tracking and controlling the progress of the project, customer interaction,
managerial presentations, and team building are largely acquired through experience.
Never the less, the importance of a sound knowledge of the prevalent project
management techniques cannot be overemphasized. The objective of the rest of this chapter is
to introduce the reader to the same.
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
2.3 Project Planning
Once a project has been found to be feasible, software project managers undertake
project planning. Project planning is undertaken and completed before any development
activity starts.
Project planning requires utmost care and attention since commitment to unrealistic
time and resource estimates result in schedule slippage. Schedule delays can cause customer
dissatisfaction and adversely affect team morale. It can even cause project failure. For this
reason, project planning is undertaken by the project managers with utmost care and attention.
However, for effective project planning, in addition to a thorough knowledge of the
various estimation techniques, past experience is crucial.
During project planning, the project manager performs the following activities. Note
that we have given only a very brief description of the activities.
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.
Staffing: 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.
Observe that size estimation is the first activity that a project manager undertakes during project
planning. Size is the most fundamental parameter based on which all other estimations and
project plans are made
Based on the size estimation, the effort required to complete a project and the duration over
which the development is to be carried out are estimated.
Based on the effort estimation, the cost of the project is computed. The estimated cost forms
the basis on which price negotiations with the customer is carried out. Other planning activities
such as staffing, scheduling etc. are undertaken based on the effort and duration estimates made.

Precedence ordering among planning activities

i)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. As a result, during the span of the project, the project parameters, scope of the
project, project staff, etc., often change drastically resulting in the initial plans going haywire.
In order to overcome this problem, sometimes project managers undertake project planning
over several stages.
That is, after the initial project plans have been made, these are revised at frequent
intervals. Planning a project over a number of stages protects managers from making big
commitments at the start of the project. This technique of staggered planning is known as
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.

At the start of a project, the project manager has incomplete knowledge about the nitty-
gritty of the project. His information base gradually improves as the project progresses through
different development phases.

The complexities of different project activities become clear, some of the anticipated
risks get resolved, and new risks appear. The project parameters are re-estimated periodically
as understanding grows and also a periodically as project parameters change.

By taking these developments into account, the project manager can plan the
subsequent activities more accurately and with increasing levels of confidence.

ii)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
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
2.4 METRICS FOR PROJECT SIZE ESTIMATION
As already mentioned, accurate estimation of project size is central to satisfactory
estimation of all other project parameters such as effort, completion time, and total project cost.
Before discussing the available metrics to estimate the size of a project, let us examine what
does the term “project size” exactly mean. The size of a project is obviously not the number of
bytes that the source code occupies, neither is it the size of the executable code.
The project size is a measure of the problem complexity in terms of the effort and time
required to develop the product.
Currently, two metrics are popularly being used to measure size—
 lines of code (LOC) and
 function point (FP).
2.4.1)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.
Obviously, while counting the number of source instructions, comment lines, and
header lines are ignored. 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 difficult
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 sufficiently
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. In spite of its conceptual simplicity, LOC metric has several
shortcomings when used to measure problem size. We discuss the important shortcomings of
the LOC metric in the following subsections:
 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 efficiency 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 difficult to accurately estimate LOC of the final program from problem
specification

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 (i.e. specification, design, code, test, etc.) and not just the coding
effort. LOC, however, focuses on the coding activity alone it merely computes the number of
source lines in the final program.
The implicit assumption made by the LOC metric is that the overall product development
effort is solely determined from the coding effort alone is flawed.
The presumption that the total effort needed to develop a project is proportional to the
coding effort is easily countered by noting the fact that even when the design or testing issues
are very complex, the code size might be small and vice versa. Thus, the design and testing
efforts can be grossly disproportional to the coding effort. Code size, therefore, is obviously an
improper indicator of the problem size.
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.
By coding style, we mean the choice of code layout, the choice of the instructions in
writing the program, and the specific algorithms used. Different programmers may lay out their
code in very different ways.
For example, one programmer might write several source instructions on a single line,
whereas another might split a single instruction across several lines. Unless this issue is handled
satisfactorily, there is a possibility of arriving at very different size measures for essentially
identical programs.
This problem can, to a large extent, be overcome by counting the language tokens in a
program rather than the lines of code.
However, a more intricate problem arises due to the specific choices of instructions
made in writing the program.
For example, one programmer may use a switch statement in writing a C program and
another may use a sequence of if ... then ... else ... statements. Therefore, the following can
easily be concluded.
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.
Some programmers produce lengthy and complicated code as they do not make effective use
of the available instruction set or use improper algorithms.
In fact, it is true that a piece of poor and sloppily written piece of code can have larger
number of source instructions than a piece t h a t is efficient and has been thoughtfully written.
Calculating productivity as LOC generated per man-month may encourage programmers to
write lots of poor quality code rather than fewer lines of high quality code achieve the same
functionality.
LOC metric penalises use of higher-level programming languages and code reuse
A paradox is that if a programmer consciously uses several library routines, then the
LOC count will be lower. This would show up as smaller program size, and in turn, would
indicate lower effort!
Thus, if managers use the LOC count to measure the effort put in by different
developers (that is, their productivity), they would be discouraging code reuse by developers.
Modern programming methods such as object-oriented programming and reuse of components
makes the relationships between LOC and other project attributes even less precise.
LOC metric measures the lexical complexity of a program and does not address the more
important issues of logical and structural complexities
Between two programs with equal LOC counts, a program incorporating complex logic
would require much more effort to develop than a program with very simple logic.
To realise why this is so, imagine the effort that would be required to develop a program
having multiple nested loops and decision constructs and compare that with another program
having only sequential control flow.
It is very difficult to accurately estimate LOC of the final program from problem
specification
As already discussed, at the project initiation time, it is a very difficult task to accurately
estimate the number of lines of code (LOC) that the program would have after development.
The LOC count can accurately be computed only after the code has fully been developed. Since
project planning is carried out even before any development activity. starts, the LOC metric is
of little use to the project managers during project planning.

2.4.2) Function Point (FP) Metric

Function point metric was proposed by Albrecht in 1983. This metric overcomes many
of the shortcomings of the LOC metric.
Since its inception in late 1970s, function point metric has steadily gained popularity.
Function point metric has several advantages over LOC metric.
One of the important advantages of the function point metric over the LOC metric is
that it can easily be computed from the problem specification itself. Using the LOC metric, on
the other hand, the size can accurately be determined only after the product has fully been
developed.
The conceptual idea behind the function point metric is the following. The size of a
software product is directly dependent on the number of different high-level functions or
features it supports. This assumption is reasonable, since each feature would take additional
effort to implement.
Though each feature takes some effort to develop, different features may take very
different amounts of efforts to develop.
For example, in a banking software, a function to display a help message may be much
easier to develop compared to say the function that carries out the actual banking transactions.
This has been considered by the function point metric by counting the number of input and
output data items and the number of files accessed by the function.
The implicit assumption made is that the more the number of data items that a function
reads from the user and outputs and the more the number of files accessed, the higher is the
complexity of the function.
Now let us analyse why this assumption must be intuitively correct. Each feature when
invoked typically reads some input data and then transforms those to the required output data.
For example, the query book feature (see Figure ) of a Library Automation Software takes the
name of the book as input and displays its location in the library and the total number of copies
available.
Similarly, the issue book and the return book features produce their output based on the
corresponding input data. It can therefore be argued that the computation of the number of
input and output data items would give a more accurate indication of the code size compared
to simply counting the number of high-level functions supported by the system.

System function as a mapping of input data to output data.

 Albrecht postulated that in addition to the number of basic functions that a software
performs, size also depends on the number of files and the number of interfaces that are
associated with the software. Here, interfaces refer to the different mechanisms for data transfer
with external systems including the interfaces with the user, interfaces with external computers,
etc.
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 UFP 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.

The first step is to compute the unadjusted function point (UFP).

UFP = (Number of inputs)*4 + (Number of outputs)*5 + (Number of inquiries)*4 + (Number
of files)*10 + (Number of interfaces)*10
Number of inputs: Each data item input by the user is counted. Data inputs should be
distinguished from user inquiries. Inquiries are user commands such as print-account-balance.
Inquiries are counted separately. It must be noted that individual data items input by the user
are not considered in the calculation of the number of inputs, but a group of related inputs are
considered as a single input. For example, while entering the data concerning an employee to
an employee pay roll software; the data items name, age, sex, address, phone number, etc. are
together considered as a single input. All these data items can be considered to be related, since
they pertain to a single employee.

Number of outputs: The outputs considered refer to reports printed, screen outputs, error
messages produced, etc. While outputting the number of outputs the individual data items
within a report are not considered, but a set of related data items is counted as one input.

Number of inquiries: Number of inquiries is the number of distinct interactive queries which
can be made by the users. These inquiries are the user commands which require specific action
by the system.

Number of files: Each logical file is counted. A logical file means groups of logically related
data. Thus, logical files can be data structures or physical files.

Number of interfaces: Here the interfaces considered are the interfaces used to exchange
information with other systems. Examples of such interfaces are data files on tapes, disks,
communication links with other systems etc.

Once the unadjusted function point (UFP) is computed, the technical complexity factor
(TCF) is computed next.
TCF refines the UFP measure by considering fourteen other factors such as high
transaction rates, throughput, and response time requirements, etc.
Each of these 14 factors is assigned from 0 (not present or no influence) to 6 (strong
influence).
The resulting numbers are summed, yielding the total degree of influence (DI).
Now, TCF is computed as (0.65+0.01*DI).
As DI can vary from 0 to 70, TCF can vary from 0.65 to 1.35.
Finally, FP=UFP*TCF
Shortcomings of function point (FP) metric
LOC as a measure of problem size has several shortcomings
• LOC gives a numerical value of problem size that can vary widely with individual coding
style – different programmers lay out their code in different ways.
• A good problem size measure should consider the overall complexity of the problem and the
effort needed to solve it. That is, it should consider the local effort needed to specify, design,
code, test, etc. and not just the coding effort. LOC, however, focuses on the coding activity
alone; it merely computes the number of source lines in the final program.
• LOC measure correlates poorly with the quality and efficiency of the code. Larger code size
does not necessarily imply better quality or higher efficiency.
• LOC metric measures the lexical complexity of a program and does not address the more
important but subtle issues of logical or structural complexities. Between two programs with
equal LOC count, a program having complex logic would require much more effort to develop
than a program with very simple logic. To realize why this is so, consider the effort required to
develop a program having multiple nested loop and decision constructs with another program
having only sequential control flow.
• It is very difficult to accurately estimate LOC in the final product from the problem
specification. The LOC count can be accurately computed only after the code has been fully
developed. Therefore, the LOC metric is little use to the project managers during project
planning, since project planning is carried out even before any development activity has started.
This possibly is the biggest shortcoming of the LOC metric from the project manager’s
perspective

2.5 PROJECT ESTIMATION TECHNIQUES

Estimation of various project parameters is a basic project planning activity. The important
project parameters that are estimated include: project size, effort required to develop the
software, project duration, and cost. These estimates not only help in quoting the project cost
to the customer, but are also useful in resource planning and scheduling. There are three broad
categories of estimation techniques:
• Empirical estimation techniques
• Heuristic techniques
• Analytical estimation techniques
2.5.1 Empirical Estimation Techniques
Empirical estimation techniques are based on making an educated guess of the project
parameters. While using this technique, prior experience with development of similar products
is helpful. Although empirical estimation techniques are based on common sense, different
activities involved in estimation have been formalized over the years. Two popular empirical
estimation techniques are:
 Expert judgment technique and
 Delphi cost estimation.
2.5.2 Heuristic Techniques
Heuristic techniques assume that the relationships among the different project
parameters can be modelled using suitable mathematical expressions. Once the basic
(independent) parameters are known, the other (dependent) parameters can be easily
determined by substituting the value of the basic parameters in the mathematical expression.
Different heuristic estimation models can be divided into the following two classes: single
variable model and the multi variable model.
i) Single variable estimation models provide a means to estimate the desired
characteristics of a problem, using some previously estimated basic (independent)
characteristic of the software product such as its size. A single variable estimation model takes
the following form:
Estimated Parameter = c1 * ed 1
In the above expression,
e is the characteristic of the software which 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 basic COCOMO model is an example of single variable cost estimation model.
ii)A multivariable cost estimation model takes the following form:
Estimated Resource = c1*e1 d 1 + c2*e2 d 2 + ...
Where
e1, e2, … 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 constants c1, c2, d1, d2, … . Values of these constants are
usually determined from historical data.
The intermediate COCOMO model can be considered to be an example of a
multivariable estimation model.

2.5.3 Analytical Estimation technique

Analytical estimation is a type of technique that is used to measure work. In this
technique, firstly the task is divided or broken down into its basic component operations or
elements for analyzing. Second, if the standard time is available from some other source, then
these sources are applied to each element or component of work.
Third, if there is no such time available, then the work is estimated based on the
experience of the work. In this technique, results are derived by making certain basic
assumptions about the project. Hence, the analytical estimation technique has some scientific
basis. Halstead’s software science is based on an analytical estimation model.

2.6 EMPIRICAL ESTIMATION TECHNIQUES

Two popular empirical estimation techniques are:
 Expert judgment technique and
 Delphi cost estimation.

2.6.1 Expert Judgment Technique

Expert judgment is one of the most widely used estimation techniques. In this approach,
an expert makes an educated guess of the problem size after analyzing the problem thoroughly.
Usually, the expert estimates the cost of the different components (i.e. modules or subsystems)
of the system and then combines them to arrive at the overall estimate. However, this technique
is subject to human errors and individual bias. Also, it is possible that the expert may overlook
some factors inadvertently. Further, an expert making an estimate may not have experience and
knowledge of all aspects of a project. For example, he may be conversant with the database
and user interface parts but may not be very knowledgeable about the computer communication
part.
A more refined form of expert judgment is the estimation made by group of experts.
Estimation by a group of experts minimizes factors 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. However, the estimate made by a group of experts may
still exhibit bias on issues where the entire group of experts may be biased due to reasons such
as political considerations. Also, the decision made by the group may be dominated by overly
assertive members.

2.6.2 Delphi cost estimation

Delphi cost estimation approach tries to overcome some of the shortcomings of the
expert judgment approach. Delphi estimation is carried out by a team comprising of 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.
Estimators complete their individual estimates anonymously and submit to the coordinator.
In their estimates, the estimators mention any unusual characteristic of the product
which has influenced his estimation. The coordinator prepares and distributes the summary of
the responses of all the estimators, and includes any unusual rationale noted by any of the
estimators.
Based on this summary, the estimators re-estimate. This process is iterated for several
rounds. However, no discussion among the estimators is allowed during the entire estimation
process.
The idea behind this is that if any discussion is allowed among the estimators, then
many estimators may easily get influenced by the rationale of an estimator who may be more
experienced or senior. After the completion of several iterations of estimations, the coordinator
takes the responsibility of compiling the results and preparing the final estimate.

2.7 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. These three stages of estimation in the following
subsection.
i)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. Roughly speaking, the three product development classes correspond to
development of application, utility and system software.
 Normally, data processing programs are considered to be application programs.
 Compilers, linkers, etc., are utility programs.
 Operating systems and real-time system programs, etc.
 System programs interact directly with the hardware and programming complexities
also arise out of the requirement for meeting timing constraints and concurrent
processing of tasks.
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.
Thus according complexity for the three categories (application, utility and system
programs) of products are [Link].
Boehm’s [1981] definitions of organic, semidetached, and embedded software are
elaborated as follows:
Organic
It 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 a popular unit for effort measurement.
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.

Person-Month Curve
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 × (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).
 Thus, if a single instruction spans several lines (say n lines), it is considered to be
nLOC.
 The values of a1, a2, b1, b2 for different categories of products
 He derived these values by examining historical data collected from a large
number of actual projects.
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 development time
based on the effort are given 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

Observe that the effort is some what superlinear (that is, slope of the curve>1) in the size of
the software product.

Effort versus product size

 This is because the exponent in the effort expression is more than 1. Thus, the effort
required to develop a product increases rapidly with project size. However, observe that the
increase in effort with size is not as bad as that was portrayed. The reason for this is that
COCOMO assumes that projects are carefully designed and developed by using software
engineering principles.

Observations from the development time—size plot

The development time versus the product size in KLOC is plotted
The development time is a sublinear function of the size of the product. That is, when
the size of the product increases by two times, the time to develop the product does not double
but rises moderately. For example, to develop a product twice as large as a product of size
100KLOC, the increase in duration may only be 20 per cent. It may appear surprising that the
duration curve does not increase superlinearly—one would normally expect the curves to
behave similar to those in the effort-size plots. This apparent anomaly can be explained by the
fact that COCOMO assumes that a project development is carried out not by a single person
but by a team of developers.
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, semidetached, or embedded type. (Please verify this using the basic
COCOMO formulas discussed in this section). However, according to the COCOMO formulas,
embedded programs require much higher effort than either application or utility programs. We
can interpret it to mean that there is more scope for parallel activities for system programs than
those in utility or application programs.

Development time versus size

Example 3.2 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 Rs. 15,000 per month. Determine the effort required to develop the software product,
the nominal development time, and the cost to develop the product.
From the basic COCOMO estimation formula for organic software: Effort = 2.4 × (32)1.05 =
91 PM Nominal development time = 2.5 × (91)0.38 = 14 months
Staff cost required to develop the product = 14 × Rs. 15, 000 = Rs. 210,000/
ii) Intermediate COCOMO
The basic COCOMO model assumes that effort and development time are functions of 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.
Therefore, in order to obtain an accurate estimation of the effort and project duration, the effect
of all relevant parameters must be taken into account. The intermediate COCOMO model
recognises this fact and refines the initial estimates.
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. For example, if modern programming practices are used,
the initial estimates are scaled downward by multiplication with a cost driver having a value
less than 1. If there are stringent reliability requirements on the software product, the initial
estimates are scaled upward. Boehm requires the project manager to rate 15 different
parameters for a particular project on a scale of one to three. For each such grading of a project
parameter, he has suggested appropriate cost drivers (or multipliers) to refine the initial
estimates. In general, the cost drivers identified by Boehm can be classified as being attributes
of the following items:
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.
iii) 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.
For example, some sub-systems may be considered as organic type, some semidetached, and
some even embedded. Not only may the inherent development complexity of the
subsystems be different, but for some subsystem the reliability requirements may be high, for
some the development team might have no previous experience of similar development, and
so on.
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. In other words, the cost to develop each sub-system is estimated
separately, and the complete system cost is determined as the subsystem costs. This approach
reduces the margin of error in the final estimate.
L e t us consider the following development project as an example application of the
complete COCOMO model. A distributed management information system (MIS) product for
an organisation having offices at several places across the country can have the following sub-
component:
• Database part
• Graphical user interface (GUI) part
• Communication part
Of these, the communication part can be considered as embedded software. The
database part could be semi-detached software, and the GUI part organic software.
The costs for these three components can be estimated separately, and summed up to
give the overall cost of the system. To further improve the accuracy of the results, the different
parameter values of the model can be fine-tuned and validated against an organisation’s
historical project database to obtain more accurate estimations. Estimation models such as
COCOMO are not totally accurate and lack a full scientific justification. Still, software cost
estimation models such as COCOMO are required for an engineering approach to software
project management.
Companies consider computed cost estimates to be satisfactory, if these are within about
80 per cent of the final cost. Although these estimates are gross approximations—without such
models, one has only subjective judgements to rely on.

2.8 HALSTEAD’S SOFTWARE SCIENCE

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 over all program length, potential minimum value,
actual volume, 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

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.
Halstead’s definition of the length of the program as the total number of operators and
operands roughly agrees with the intuitive notation of the program length as the total number
of tokens used in the program. The program vocabulary is the number of unique operators and
operands used in the program.
Thus, program vocabulary η = η1 + η2

PROGRAM VOLUME
The length of a program (i.e. 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. This type of
dependency would produce different measures of length for essentially the same problem when
different programming languages are used. Thus, while expressing program size, the
programming language used must be taken into consideration:
V = N log2 η
POTENTIAL minimum VOLUME
the potential minimum volume v* is defined as the volume of most succinct program
in which a problem can be coded. the minimum volume is obtained when the program can be
expressed using a single source code instruction., say a function call like foo( ) ;. in other words,
the volume is bound from below due to the fact that a program would have at least two operators
and no less than the requisite number of operands. thus, if an algorithm operates on input and
output data d1, d2, … dn, the most succinct program would be f(d1, d2, … dn); for which η1
= 2, η2 = n.
therefore, v* = (2 + η2)log2(2 + η2).
the program level l is given by l = v*/v.
the concept of program level l is introduced in an attempt to measure the level of
abstraction provided by the programming language. using this definition, languages can be
ranked into levels that also appear intuitively correct. the above result implies that the higher
the level of a language, the less effort it takes to develop a program using that language. this
result agrees with the intuitive notion that it takes more effort to develop a program in assembly
language than to develop a program in a high-level language to solve a problem.
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/L,
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 effort E = V²/V* (since L = V*/V) varies as the square of the volume.
Experience shows that E is well correlated to the effort needed for maintenance of an existing
program. The programmer’s time T = E/S,
where
S 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
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. Using this
method, the program parameters such as length, volume, cost, effort, etc. can be determined
even before the start of any programming activity. His method is summarized below

Example Let us consider the following C program:

main( )
{
int a, b, c, avg;
scanf(“%d %d %d”, &a, &b, &c);
avg = (a+b+c)/3;
printf(“avg = %d”, avg);
}
The unique operators are: main,(),{},int,scanf,&,“,”,“;”,=,+,/, printf
The unique operands are: a, b, c, &a, &b, &c, a+b+c, avg, 3, “%d %d %d”, “avg = %d”
Therefore, η1 = 12, η2 = 11
Estimated Length = (12*log12 + 11*log11) = (12*3.58 + 11*3.45) = (43+38) = 81
Volume = Length*log(23) = 81*4.52 = 366

2.9 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 hay ware.
We need to distinguish between a risk which is a problem that might occur from the
problems currently being faced by a project. If a risk becomes real, the anticipated problem
becomes a reality and is no more a risk. If a risk becomes real, it can adversely affect the project
and hamper the successful and timely completion of the project.
Therefore, it is necessary for the project manager to anticipate and identify different
risks that a project is susceptible to, so that contingency plans can be prepared beforehand to
contain each risk. In this context, risk management aims at reducing the chances of a risk
becoming real as well as reducing the impact of a risks that becomes real. Risk management
consists of three essential activities
 risk identification
 risk assessment, and
 risk mitigation.
2.9.1) 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 impacts of the
risks is minimised. So, early risk identification is important. Risk identification is somewhat
similar to the project manager listing down his nightmares.
For example, project manager might be worried whether the vendors whom you have asked
to develop certain modules might not complete their work in time, whether they would turn in
poor quality work, whether some of your key personnel might leave the organisation, etc. All
such risks that are likely to affect a project must be identified and listed.
A project can be subject to a large variety of risks. In order to be able to systematically
identify the important risks which might affect a project, it is necessary to categorise risks into
different classes. The project manager can then examine which risks from each class are
relevant to the project.
There are three main categories of risks which can affect a software project:
 project risks
 technical risks, and
 business risks.
Project risks
Project risks concern various forms of budgetary, schedule, personnel, resource, and
customer-related problems. An important project risk is schedule slippage. Since, software is
intangible, it is very difficult to monitor and control a software project. It is very difficult 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 getting 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. Most
technical risks occur due the development team’s insufficient 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.
Classification of risks in a project
What if the project cost escalates and estimated?: Project risk.
What if the mobile phones that are developed become too bulky in size to conveniently carry?:
Business risk.
What if it is later found out that the level of radiation coming from the phones is harmful to
human being?: Business risk.
What if call hand-off between satellites becomes too difficult to implement?: Technical risk.
In order to be able to successfully foresee and identify different risks that might affect
a software project, it is a good idea to have a company disaster list. This list would contain all
the bad events that have happened to software projects of the company over the years including
events that can be laid at the customer’s doors. This list can be read by the project mangers in
order to be aware of some of the risks that a project might be susceptible to. Such a disaster list
has been found to help in performing better risk analysis.
2.9.2) 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=rs
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.
If all identified risks are prioritised, then the most likely and damaging risks can be
handled first and more comprehensive risk abatement procedures can be designed for those
risks.
2.9.3) 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
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).
A few examples of risk avoidance can be the following: Discussing with the
customer to change the requirements to reduce the scope of the work, giving
incentives to the developers to avoid the risk of manpower turnover, etc.
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. 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 of reducing the risk.
More formally,

Even though we identified three broad ways to handle any risk, effective risk handling
cannot be achieved by mechanically following a set procedure, but requires a lot of ingenuity
on the part of the project manager.

Requirements Analysis and Specification

All plan-driven life cycle models prescribe that before starting to develop a software,
the exact requirements of the customer must be understood and documented.
● Starting development work without properly understanding and documenting the
requirements increases the number of iterative changes in the later life cycle phases, and
thereby alarmingly pushes up the development costs.
● A good requirements document not only helps to form a clear understanding of various
features required from the software, but also serves as the basis for various activities carried
out during later life cycle phases.
Overview of requirements analysis and specication:
● The requirements analysis and specication phase starts after the feasibility study stage is
complete and the project has been found to be nancially viable and technically feasible.
● The requirements analysis and specication phase ends when the requirements specication
document has been developed and reviewed.
● The requirements specication document is usually called the software requirements
specication (SRS) document.
● The goal of the requirements analysis and specication phase is to clearly understand the
customer requirements and to systematically organize the requirements into a document called
the Software Requirements Specication (SRS) document.
Who performs requirements analysis
● Requirements analysis and specication activity is usually carried out by a few experienced
members of the development team.
● It normally requires them to spend some time at the customer site.
● The engineers who gather and analyze customer requirements and then write the
requirements specication document are known as system analysts.
What are the main activities carried out during
requirements analysis and specification phase?

Requirements analysis and specication phase mainly involves carrying out the
following two important activities:
● Requirements gathering and analysis.
● Requirements specication.

2.10 REQUIREMENTS GATHERING AND ANALYSIS

The complete set of requirements are almost never available in the form of a single document
from the customer.

● Complete requirements are rarely obtainable from any single customer representative.
● We can conceptually divide the requirements gathering and analysis activity into two
separate tasks:
i. Requirements gathering and
ii. Requirements Analysis

2.10.1)Requirements gathering
● Requirements gathering 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 are concerned with the software.
● It is very dicult to gather all the necessary information from a large number of stakeholders
and from information scattered across several pieces of documents.
● Gathering requirements turns out to be especially challenging if there is no working model
of the software being developed.
● Important ways in which an experienced analyst gathers requirements:
 Studying existing documentation:
○ The analyst usually studies all the available documents regarding the system to be
developed before visiting the customer site.
○ Customers usually provide a statement of purpose (SoP) document to the developers.
● 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. Refer to: Delphi method
● 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 software is also called a task.
○ The analyst tries to identify and understand the different tasks to be performed by the
software. ○ For each identied task, the analyst tries to formulate the different steps
necessary to realize the required functionality in consultation with the users.
● 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 types of scenarios of a task, the behavior of the software can be different.

● Form analysis:
○ Form analysis is an important and effective requirements gathering activity that is
undertaken by the analyst, when the project involves automating an existing manual system.
○ In form analysis the existing forms and the formats of the notications produced are
analyzed to determine the data input to the system and the data that are output from the system.
2.10.2) 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.
● During requirements analysis, the analyst needs to identify and resolve three main types of
problems in the requirements:
• Anomaly
• Inconsistency
• Incompleteness
○ Anomaly:
■ An anomaly is an ambiguity in a requirement. When a requirement is anomalous,
several interpretations of that requirement are possible.
■ Example: While gathering the requirements for a process control application, the
following requirement was expressed by a certain stakeholder: “When the temperature
becomes high, the heater should be switched off”. Please note that words such as “high”, “low”,
“good”, “bad” etc. are indications of ambiguous requirements as these lack quantication and
can be subjectively interpreted.
○ Inconsistency:
■ Two requirements are said to be inconsistent, if one of the requirements contradicts
the other.
■ Example: Consider the following two requirements that were collected from two
different stakeholders in a process control application development project.
● The furnace should be switched-off when the temperature of the furnace rises above
500℃.
● When the temperature of the furnace rises above 500℃, the water shower should be
switched-on and the furnace should remain on.
○ Incompleteness:
■ An incomplete set of requirements is one in which some requirements have been
overlooked. The lack of these features would be felt by the customer much later, possibly while
using the software.
■ Example: In a chemical plant automation software, suppose one of the requirements
is that if the internal temperature of the reactor exceeds 200℃ then an alarm bell must be
sounded. However, on an examination of all requirements, it was found that there is no
provision for resetting the alarm bell after the temperature has been brought down in any of the
requirements. This is clearly an incomplete requirement.

2.11 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 [Link] document is probably the most important document and is the toughest to
write.
● One reason for this difficulty is that the SRS document is expected to cater to the needs of a
wide variety of audience.
● A well-formulated SRS document finds a variety of usage:
○ Forms an agreement between the customers and the developers.
○ Reduces future reworks.
○ Provides a basis for estimating costs and schedules
○ Provides a baseline for validation and verification
○ Facilitates future extensions
2.11.1)Users of SRS document:

● 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 it contains all the information
required to plan the project.
● Maintenance engineers:
The SRS document helps the maintenance engineers to under- stand the functionalities
supported by the system.

2.11.2)Characteristics of a Good SRS Document:

● IEEE Recommended Practice for Software Requirements Specifications 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.
○ 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.

○ 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. To cope up with the requirements changes, the SRS document
should be easily modifiable. For this, an SRS document should be well-structured.
○ 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.

2.11.3 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 problems that a
specification document might suffer from. By knowing these problems, one can try to avoid
them while writing an SRS document. 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. For example, in the library automation problem, one should not specify whether the
library membership records need to be stored indexed on the member’s first name or on the
library member’s identification (ID) number. Over-specification restricts the freedom
of the designers in arriving at a good design solution.
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.
Over-specification: It occurs when the analyst tries to address the “how to”
aspects in the SRS document. For example, in the library automation problem, one should not
specify whether the library membership records need to be stored indexed on the me mber’s
first name or on the library member’s identification (ID) number. Over-specification restricts
the freedom of the designers in arriving at a good design solution.
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
difficult to implement.
Noise: The term noise refers to presence of material not directly relevant to the software
development process. For example, in t h e register customer function, suppose the analyst
writes that customer registration department is manned by clerks who report for work between
8am and 5pm, 7 days a week. This information can be called noise as it would hardly be of any
use to the software developers and would unnecessarily clutter the SRS document, diverting
the attention from the crucial points.
Several other “sins” of SRS documents can be listed and used to guard against writing a bad
SRS document and is also used as a checklist to review an SRS document.

2.11.4 Categories of Customer requirements:

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:
● The functional requirements capture the functionalities required by the users from the system.
● Consider a software as offering a set of functions {fi} to the user.
● These functions can be considered similar to a mathematical function f : I → O, meaning that
a function transforms an element (i i) in the input domain (I) to a value (oi) in the output (O).
● 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.
● Each high-level function is an instance of use of the system (use case) by the user in some
way.
● A high-level function is one using which the user can get some useful piece of work done.
● Each high-level requirement typically involves accepting some data from the user through
a user interface, transforming it to the required response, and then displaying the system
response in proper format.
● A high-level function transforms certain input data to output data.
● Except for very simple high- level functions, a function rarely reads all its required data in
one go and rarely outputs all the results in one shot.
● A high-level function usually involves a series of interactions between the system and one or
more users.
● Functional requirements form the basis for most design and test methodologies.
● Unless the functional requirements are properly identified and documented, the design and
testing activities cannot be carried out satisfactorily.
● Once all the high-level functional requirements have been identified and the requirements
problems have been eliminated, these are documented.
● A function can be documented by identifying the state at which the data is to be input to the
system, its input data domain, the output data domain, and the type of processing to be carried
on the input data to obtain the output data.
(Withdraw cash from ATM): An initial informal description
of a required functionality is usually given by the customer as a statement of
purpo s e (SoP). An SoP serves as a starting point for the analyst and he
proceeds with the requirements gathering activity after a basic understanding
of the SoP. How ever, the functionalities of withdraw cash from ATM is
intuitively obvious to any one who has used a bank ATM. So, we are not
including an informal description of withdraw cash functionality here and in
the following, we documents this functional requirement.
R.1: Withdraw cash
Description:The withdraw cash function first determines the type of
account that the user has and the account number from which the user
wishes to withdraw cash. It checks the balance to determine whether
the requested amount is available in the account. If enough balance is
available, it outputs the required cash, otherwise it generates an error
message.
R.1.1: Select withdraw amount option
Input: “Withdraw amount” option selected Output: User prompted to enter the
account type
R.1.2: Select account
I n p u t : User selects option from any one of the followings—
savings/checking/deposit.
Output: Prompt to enter amount
R.1.3: Get required amount
Input: Amount to be withdrawn in integer values greater than 100 and less
than 10,000 in multiples of 100.
Output: The requested cash and printed transaction statement.
Processing: The amount is debited from the user’s account if sufficient balance
is available, otherwise an error message displayed.
Non-functional Requirements:
● The non-functional requirements are non-negotiable obligations that must be supported by
the software.
● The non-functional requirements capture those requirements of the customer that cannot be
expressed as functions.
● Aspects concerning external interfaces, user interfaces, maintainability, portability, usability,
maximum number of concurrent users, timing, and throughput.
● The non-functional requirements can be critical in the sense that any failure by the developed
software to achieve some minimum defined level in these requirements can be considered as a
failure and make the software unacceptable by the customer.
● Design and implementation constraints:
○ Design and implementation constraints are an important category of non-functional
requirements describing any items or issues that will limit the options available to the
developers.
○ Some of the example constraints can be—corporate or regulatory policies that need
to be honored; hardware limitations; interfaces with other applications; specific
technologies, tools, and databases to be used; specific communications protocols to be
used; security considerations etc.
● External interfaces required:
○ Examples of external interfaces are - hardware, software and communication
interfaces, user interfaces, report formats, etc.
○ To specify the user interfaces, each interface between the software and the users must
be described.
○ One example of a user interface requirement of a software can be that it should be
usable by factory shop floor workers who may not even have a high school degree
● Other non-functional requirements:
○ This section contains a description of non- functional requirements that are neither design
constraints nor are external interface requirements.
○ An important example is a performance requirement such as the number of transactions
completed per unit time.
Goals of implementation:
● The ‘goals of implementation’ part of the SRS document offers some general suggestions
regarding the software to be developed.
● A goal, in contrast to the functional and non functional requirements, is not checked by the
customer for conformance at the time of acceptance testing.
● The goals of the implementation section might document issues such as easier revisions to
the system functionalities that may be required in the future, easier support for new devices to
be supported in the future, reusability issues, etc.
Organization of the SRS Document:
● The organization of an SRS document is prescribed by the IEEE 830 standard.
● IEEE 830 standard has been intended to serve only as a guideline for organizing a
requirements specification document into sections and allows the flexibility of tailoring it.
● Depending on the type of project being handled, some sections can be omitted, introduced,
or interchanged.
● The three basic issues that any SRS document should discuss are—functional requirements,
non-functional requirements, and guidelines for system implementation.
● The introduction section should describe the context in which the system is being developed,
and provide an overall description of the system, and the environmental characteristics.
Various Sections of SRS:
Introduction
● Purpose:
This section should describe where the software would be deployed and how the software
would be used.
● Project scope: This section should briefly describe the overall context within which the
software is being developed.

● Environmental characteristics:
This section should briefly outline the environment (hardware and other software) with which
the software will interact. Overall description of organization of SRS document
● Product perspective:
This section needs to briefly state as to whether the software is intended to be a replacement
for a certain existing system, or it is a new software.
● Product features:
This section should summarize the major ways in which the software would be used.
● User classes:
Various user classes that are expected to use this software are identified and described here.
● Operating environment:
This section should discuss in some detail the hardware platform on which the software would
run, the operating system, and other application software with which the developed software
would interact.
● Design and implementation constraints:
In this section, the different constraints on the design and implementation are discussed.
● User documentation:
This section should list out the types of user documentation, such as user manuals, on-line help,
and trouble-shooting manuals that will be delivered to the customer along with the software.
External interface requirements
● User interfaces:
This section should describe a high-level description of various interfaces and various
principles to be followed.

● Hardware interfaces:
This section should describe the interface between the software and the hardware components
of the system.
● Software interfaces:
This section should describe the connections between this software and other specific software
components, including databases, operating systems, tools, libraries, and integrated
commercial components, etc.
● Communications interfaces:
This section should describe the requirements associated with any type of communications
required by the software, such as e-mail, web access, network server communications
protocols, etc. Other non-functional requirements for organization of SRS document
● Performance requirements:
Aspects such as number of transactions to be completed per second should be specified here.
● Safety requirements:
Those requirements that are concerned with possible loss or damage that could result from the
use of the software are specified here.
● Security requirements:
This section should specify any requirements regarding security or privacy requirements on
data used or created by the software.

2.12 Formal System Specification

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 the specification language.
Formal Specification Language
A formal specification language consists of two sets syn and sem, and a relation sat between
them. The set syn is called the syntactic domain, the set sem is called the semantic domain, and
the relation sat is called the satisfaction relation. For a given specification syn, and model of
the system sem, if sat (syn, sem), then syn is said to be the specification of sem, and sem is said
to be the specificand of syn.

Syntactic Domains
The syntactic domain of a formal specification language consists of an alphabet of symbols
and 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. Programming
languages are used to specify functions from input to output values. Concurrent and distributed
system specification languages are used to specify state sequences, event sequences, state
transition sequences, synchronization trees, partial orders, state machines, etc.
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. The semantic abstraction function maps the elements
of the semantic domain into equivalent classes. There can be different specifications describing
different aspects of a system model, possibly using different specification languages. Some of
these specifications describe the system’s behavior and the others describe the system’s
structure. Consequently, two broad classes of semantic abstraction functions are defined: those
that preserve a system’s behavior and those that preserve a system’s structure.
Model-oriented vs. property-oriented approaches
Formal methods are usually classified into two broad categories –
 model – oriented and
 property – oriented approaches.
In a model-oriented style, one defines a system’s behavior 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 behavior is defined indirectly by
stating its properties, usually in the form of a set of axioms that the system must satisfy.
Example:- Let us consider a simple producer/consumer example.
In a property-oriented style, it is probably started by listing the properties of the system
like: the consumer can start consuming only after the producer has produced an item; the
producer starts to produce an item only after the consumer has consumed the last item, etc. A
good example of a producer-consumer problem is CPU-Printer coordination. After processing
of data, CPU outputs characters to the buffer for printing. Printer, on the other hand, reads
characters from the buffer and prints them. The CPU is constrained by the capacity of the
buffer, whereas the printer is constrained by an empty buffer. Examples of property-oriented
specification styles are axiomatic specification and algebraic specification.
In a model-oriented approach, we start by defining the basic operations, p (produce) and c
(consume). Then we can state that S1 + p → S, S + c → S1. Thus the model-oriented approaches
essentially specify a program by writing another, presumably simpler program. Examples of
popular model-oriented specification techniques are Z, CSP, CCS, etc.
Model-oriented approaches are more suited to use in later phases of life cycle because here
even minor changes to a specification may lead to drastic changes to the entire specification.
They do not support logical conjunctions (AND) and disjunctions (OR).
Property-oriented approaches are suitable for requirements specification because they can
be easily changed. They specify a system as a conjunction of axioms and you can easily replace
one axiom with another one.
Operational Semantics
Informally, the operational semantics of a formal method is the way computations are
represented. There are different types of operational semantics according to what is meant by
a single run of the system and how the runs are grouped together to describe the behaviour of
the system. Some commonly used operational semantics are as follows:
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
inter leavings of the automatic actions. For example, a concurrent activity a║b is represented
by the set of sequential activities a;b and b;a. This is simple but rather unnatural representation
of concurrency. The behavior of a system in this model consists of the set of all its runs. To
make this model realistic, usually justice and fairness restrictions are imposed on computations
to exclude the unwanted interleavings.
Branching Semantics:-
In this approach, the behavior of a system is represented by a directed graph. The nodes
of the graph represent the possible states in the evolution of a system. The descendants of each
node of the graph represent the states which can be generated by any of the atomic actions
enabled at that state. Although this semantic model distinguishes the branching points in a
computation, still it represents concurrency by interleaving.
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). The partial order represents a precedence
ordering among events, and constraints some events to occur only after some other events have
occurred; while the occurrence of other events (called concurrent events) is considered to be
incomparable. This fact identifies concurrency as a phenomenon not translatable to any
interleaved representation.
Formal methods possess several positive features, some of which are discussed below.
 Formal specifications encourage rigor. Often, the very process of construction of a rigorous
specification is more important than the formal specification itself. The construction of a
rigorous specification clarifies several aspects of system behaviour that are not obvious in an
informal specification.
 Formal methods usually have a well-founded mathematical basis. Thus, formal specifications
are not only more precise, but also mathematically sound and can be used to reason about the
properties of a specification and to rigorously prove that an implementation satisfies its
specifications.
 Formal methods have well-defined semantics. Therefore, ambiguity in specifications is
automatically avoided when one formally specifies a system.
 The mathematical basis of the formal methods facilitates automating the analysis of
specifications. For example, a tableau-based technique has been used to automatically check
the consistency of specifications. Also, automatic theorem proving techniques can be used to
verify that an implementation satisfies its specifications. The possibility of automatic
verification is one of the most important advantages of formal methods.
 Formal specifications can be executed to obtain immediate feedback on the features of the
specified system. This concept of executable specifications is related to rapid prototyping.
Informally, a prototype is a “toy” working model of a system that can provide immediate
feedback on the behavior of the specified system, and is especially useful in checking the
completeness of specifications.
Limitations of formal requirements specification
It is clear that formal methods provide mathematically sound frameworks within large,
complex systems can be specified, developed and verified in a systematic rather than in an ad
hoc manner. However, formal methods suffer from several shortcomings, some of which are
the following:
 Formal methods are difficult to learn and use.
 The basic incompleteness results of first-order logic suggest that it is impossible to
check absolute correctness of systems using theorem proving techniques.
 Formal techniques are not able to handle complex problems. This shortcoming results
from the fact that, even moderately complicated problems blow up the complexity of formal
specification and their analysis. Also, a large unstructured set of mathematical formulas is
difficult to comprehend.

2.13) 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. In essence, the pre-conditions capture the requirements on the input parameters of a
function. The post-conditions are the conditions that must be satisfied when a function
completes execution for the function to be considered to have executed successfully. Thus, the
post conditions are essentially constraints on the results produced for the function execution to
be considered successful.
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. Also
find out other constraints on the input parameters and write it in the form of a predicate.
 Specify a predicate defining the conditions 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.
Example1: - Specify the pre- and post-conditions of a function that takes a real number
as argument and returns half the input value if the input is less than or equal to 100, or
else returns double the value.
f (x : real) : real
pre : x ∈ R
post : {(x≤100) ∧ (f(x) = x/2)} ∨ {(x>100) ∧ (f(x) = 2∗x)}
Example2: - Axiomatically specify a function named search which takes an integer array
and an integer key value as its arguments and returns the index in the array where the
key value is present.
search(X : IntArray, key : Integer) : Integer
pre : ∃ i ∈ [Xfirst….Xlast], X[i] = key
post : {(X′[search(X, key)] = key) ∧ (X = X′)}
Here the convention followed is: If a function changes any of its input parameters and
if that parameter is named X, and then it is referred to as X′ after the function completes
execution faster.

2.14 ALGEBRAIC SPECIFICATION

Essentially, algebraic specifications define a system as a heterogeneous algebra. A
heterogeneous algebra is a collection of different sets on which several operations are defined.
Traditional algebras are homogeneous. A homogeneous algebra consists of a single set and
several operations defined in this set; e.g. { I, +, -, *, / }. In contrast, alphabetic strings S
together with operations of concatenation and length {S, I , con, len}, is not a homogeneous
algebra, since the range of the length operation is the set of
integers.
Each set of symbols in a heterogeneous algebra is called a sort of the algebra. To define
a heterogeneous algebra, besides defining the sorts, we need to specify the involved operations,
their signatures, and their domains and ranges. Using algebraic specification, we define the
meaning of a set of interface procedure by using equations. An algebraic specification is
usually presented in four sections.
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 andthe sort where the output is produced are
called the signature of the operator. 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. By convention each equation is implicitly universally quantified over
all possible values of the variables. This means that the equation holds for all possible values
of the variable. Names not mentioned in the syntax section such r or e are variables. The first
step in defining an algebraic specification is to identify the set of required operations. After
having identified the required operators, it is helpful to classify them as either basic constructor
operators, extra constructor operators, basic inspector operators, or extra inspection operators.
The definition of these categories of operators is as follows:
Basic construction operators: These operators are used to create or modify entities of a type.
The basic construction operators are essential to generate all possible element of the type being
specified.
For example,‘create’ and ‘append’ are basic construction operators
Extra construction operators: These are the construction operators other than the basic
construction operators. For example, the operator ‘remove’ in is an extra construction operator,
because even without using ‘remove’ it is possible to generate all values of the type being
specified.
Basic inspection operators: These operators evaluate attributes of a type without modifying
them, e.g., eval, get, etc. Let S be the set of operators whose range is not the data type being
specified—these are the inspection operators. The set of the basic operators S1 is a subset of
S , such that each operator from S -S 1 can be expressed in terms of the operators from S 1.
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. If the type being specified
appears on the right hand side of the expression then it is a constructor, otherwise it is an
inspection operator. , create is a constructor
because point appears on the right hand side of the expression and point is the data type being
specified. But, xcoord is an inspection operator since it does not modify the point type.
A good rule of thumb while writing an algebraic specification, is to first establish which
are the constructor (basic and extra) and inspection operators (basic and extra). Then write
down an axiom for composition of each basic construction operator over each basic inspection
operator and extra constructor operator. Also, write down an axiom for each of the extra
inspector in terms of any of the basic inspectors. Thus, if there are m1 basic constructors, m2
extra constructors, n1 basic inspectors, a n d n2 extra inspectors, we should have m1 × (m2 +
n1) + n2 axioms. However, it should be clearly noted that these m1 × (m2 + n1) + n2 axioms
are the minimum required and many more axioms may be needed to make the specification
complete. Using a complete set of rewrite rules, it is possible to simplify an arbitrary sequence
of operations on the interface procedures.

Example 4.13 Let us specify a data type point supporting the operations create, xcoord, ycoord,
isequal; where the operations have their usual meaning.
Types:
defines point
uses boolean, integer
Syntax:
1. create : integer × integer → point
2. xcoord : point → integer
3. ycoord : point → integer
4. isequal : point × point → boolean
Equations:
1. xcoord(create(x, y)) = x
2. ycoord(create(x, y)) = y
3. isequal(create(x1, y1), create(x2, y2)) = ((x1 = x2)and(y1 = y2))
In this example, we have only one basic constructor (create), and three basic inspectors (xcoord,
ycoord, and isequal). Therefore, we have only 3 equations.
The rewrite rules let you determine the meaning of any sequence of calls on the point
type. Consider the following expression: isequal (creat e (xcoord (create(2, 3)), 5),create
(ycoord (create(2, 3)), 5)). By applying the rewrite rule 1, you can simplify the given
expression as isequal (create (2, 5), create (ycoord (create(2, 3)), 5)). By using rewrite rule 2,
you can further simplify this as isequal (create (2, 5),create (3, 5)). This is false by rewrite rule
3.
2.14.2) Properties of algebraic specifications
Three important properties that every algebraic specification should
possess are:
Completeness: This property ensures that using the equations, it should be possible to reduce
any arbitrary sequence of operations on the interface procedures. When the equations are not
complete, at some step during the reduction process, we might not be able to reduce the
expression arrived at that step by using any of the equations. There is no simple procedure to
ensure that an algebraic specification is complete.
Finite termination property: This property essentially addresses the following question: Do
applications of the rewrite rules to arbitrary expressions involving the interface procedures
always terminate? For arbitrary algebraic equations, convergence (finite termination) is
undecidable. But, if the right hand side of each rewrite rule has fewer terms than the left, then
the rewrite process must terminate.
Unique termination property: This property indicates whether application of rewrite rules
in different orders always result in the same answer. Essentially, to determine this property,
the answer to the following question needs to be checked—Can all possible sequence of
choices in application of the rewrite rules to an arbitrary expression involving the interface
procedures always give the same answer? Checking the unique termination property is a very
difficult problem.
Auxiliary Functions
Sometimes while specifying a system, one needs to introduce extra
functions not part of the system to define the meaning of some
interface procedures. These are called auxiliary functions. In the
following, we discuss an example where it becomes necessary to use an auxiliary function to
be able to specify a system.
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. Therefore, they are unambiguous and precise. Using an algebraic
specification, the effect of any arbitrary sequence of operations involving the interface
procedures can automatically be studied. A major shortcoming of algebraic specifications is
that they cannot deal with side effects. Therefore, algebraic specifications are difficult to
integrate with typical programming languages. Also, algebraic specifications are hard to
understand.

2.15) 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. However, executable specifications are
usually slow and inefficient, 4GLs4 (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 been 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 ten folds.