CHAPTER

1
Introduction

SYLLABUS

Software Engineering Process Paradigms, Process Models, Incremental and

Evolutionary models, Agile methodology, Process and Project Metrics, Software
estimation, Empirical estimation models, Cost/Effort estimation, Planning, Risk
analysis, Software project scheduling, Control and Monitoring.

Content Page No.

1.1 Software Characteristics 1-2
1.2 Classification of Software 1-3
1.3 Software Myths 1-6
1.4 Software Engineering Layers 1-8
1.5 The Software Engineering Approach 1-9
1.6 Software Process 1-13
1.7 Component Software Processes 1-14
1.8 A Process Step Specification 1-15
1.9 Software Development Process Models 1-17
1.10 Methodology and Tools 1-59
1.11 Selection Criteria for Software Process Models 1-62
1.12 Project Management Process 1-64
1.13 Agile Methodology 1-69
1.14 Process and Project Metrics 1-74
1.15 Software Estimation 1-79
1.16 Empirical Estimation Models 1-119
1.17 Planning 1-120
1.18 Project Scheduling 1-127
1.19 Risk Management Planning 1-150
1.20 Project Monitoring Plan 1-175
1.21 University Questions and Answers 1-187
 Software Engineering (MU) 1-2 Introduction

According to IEEE, software engineering is defined as

‘The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; that is, the application of engineering
to software.’
In a nutshell, software engineering can be defined as a technological and managerial
discipline concerned with systematic production and maintenance of software that is developed
and modified on time and within cost estimates.
Software engineering is a discipline which can be described as the combination of
techniques of engineering and all aspects of software development. This includes design,
implementation, and maintenance of software. It also involves a standardized approach to
program development, both in its managerial and technical aspects.
One of the main objectives of software
engineering is to help developers obtain
high-quality software. This quality is
achieved through use of Total Quality
Management, which enables continuous
process improvement custom that leads to
the development of more established
approaches to software engineering. Fig. 1.1 : Characteristics of Software

1.1 Software Characteristics

Different individuals judge software on different base. This is because they are involved
with the software in different ways. For example, users want the software to perform according
to their requirements. Similarly, developers involved in designing, coding and maintenance of
the software evaluate the software by looking at the internal characteristics of the products,
before delivering it to the user. Software characteristics are classified into six major
components, which are shown in Fig. 1.1.
 Functionality refers to the degree of performance of the software against its intended
purpose.
 Reliability refers to the ability of software to perform a required function under a given
condition for a specified period.
 Usability refers to the degree to which software is easy to use.
 Efficiency refers to the ability of software to use system resources in the most effective
and efficient manner.
 Maintainability refers to the ease with which a software system can be modified to add
capabilities, improve system performances, or correct errors,
 Software Engineering (MU) 1-3 Introduction

 Portability refers to the ease with which software developers can transfer software from
one platform to another, without (or with minimum) changes, In simple terms, it refers
to the ability of software to function properly on different hardware and software
platforms without making any changes in it.
In addition to the above-mentioned characteristics, robustness and integrity are also
important. Robustness refers to the extent to which software can continue to operate correctly
despite the introduction of invalid input, while integrity refers to the extent to which
unauthorized access or modification of software or data can be controlled in the computer
system.
1.2 Classification of Software
Software can be applied in countless situations, such as business, education, social
sector, and other fields. The only requirement is a defined set of procedural steps. That is,
software can be engaged in any field which can be described in logical and related steps. All
softwares are designed to suit some specific goals such as data processing, information
sharing, communication, and so on. Software is classified according to the range of potential
applications. These classifications are listed below.
1. System Software :
It is responsible for managing and controlling operations of a computer system. System
software is a group of programs rather than one program responsible for using computer
resources efficiently and effectively. For example, an operating system is system
software which controls the hardware, manages memory and multi-tasking functions,
and acts as an interface between applications programs and the computer.
2. Real-time Software :
This class of software observes, analyzes, and controls real world events as they occur.
Generally, a real-time system guarantees a response to an external event within a
specified period of time. For example, real-time software is used for navigation in which
the computer must react to a steady flow of new information without interruption. Most
of the defence organizations all over the world use real-time software to control their
military hardware.
3. Business Software :
This is widely used in areas where the management and control of financial activities is
of utmost importance. The fundamental component of a business system comprises
payroll, inventory, accounting, and software that permits the user to access relevant data
from the database. These activities are usually performed with the help of specialized
business software that facilitates efficient framework in the business operation and in
management decisions.
 Software Engineering (MU) 1-4 Introduction

4. Engineering and Scientific Software :

This one has emerged as a powerful tool in the research and development of next
generation technology. Applications, such as the study of celestial bodies, of under-
surface activities, and programming of an orbital path for space shuttles are heavily
dependent on engineering and scientific software. This software is designed to perform
precise calculations on complex numerical data that are obtained during real-time
environment.
5. Artificial Intelligence (Al) Software :
This particular software is used where the problem-solving technique is non-algorithmic
in nature. The solutions of such problems are generally non-agreeable to computation or
straightforward analysis. Instead, these problems require specific problem-solving
strategies that include expert system, pattern recognition, and game-playing techniques.
In addition, they involve different kinds of searching techniques including the use of
heuristics. The role of artificial intelligence software is to add certain degrees of
intelligence to the mechanical hardware in order to get the desired work done in an agile
manner.
6. Web-based Software :
This class of software acts as an interface between the user and the Internet. Data on the
Internet can be in the form of text, audio, or video format, linked with hyperlinks. Web
browser is a web-based software that retrieves web pages from the Internet. The
software incorporates executable instructions written in special scripting languages, such
as CGI or ASP. Apart from providing navigation on the web, this software also
supports additional features that are useful while surfing the Internet.
7. Personal Computer (PC) Software :
This class of software is used for official and personal use on a daily basis. The personal
computer software market has grown over the last two decades from normal text editor
to word processor and from simple paintbrush to advanced image-editing software. This
software is used predominantly in almost every field, whether it is database management
system, financial accounting package, or a multimedia-based software. It has emerged as
a versatile tool for daily applications.
Software can be also classified in terms of how closely software users or software
purchasers are associated with software development.
1. Commercial Off-the-Shelf (COTS) : The software in this category is one for which
there is no committed user before it is put up for sale. Software users have less or no
contact with the vendor during development. It is sold through retail stores or distributed
electronically. This software includes commonly-used programs such as word
processors, spreadsheets, games, income tax programs, as well as software development
tools such as software testing tools and object modelling tools.
 Software Engineering (MU) 1-5 Introduction

2. Customized or Bespoke : In this classification, software is developed for a specific

user, who is bound by some kind of formal contract. For example, software developed
for an aircraft is usually done for a particular aircraft-making company. It is not
purchased ‘off-the-shelf like any word processing software.
3. Customized COTS : In this classification, the user can enter into a contract with the
software vendor to develop a COTS product for a special purpose, that is, software can
be customized according to the needs of the user. Another growing trend is the
development of COTS software components : components that are purchased and used
to develop new applications. The COTS software component vendors are essentially
parts stores, which are classified according to their application types (see Fig. 1.2).
These types are listed below :
 Stand-alone Software resides on a single computer and does not interact with any
other software installed in a different computer.
 Embedded software is part of a unique application involving hardware like the
automobile controller.
 Real-time software comprises operations executed within very short time limits,
often microseconds; for example, radar software in an air traffic control system.
 Network software refers to the software and its components that interact across a
network.

(a) Stand-alone (b) Embedded

(c) Real-time (d) Network

Fig. 1.2 : Types of Customized COTS
 Software Engineering (MU) 1-6 Introduction

1.3 Software Myths

The development of software requires dedication and understanding on the developers’

part. Many software problems arise due to myths that are formed during the initial stages of
software development. Unlike ancient folklore that often provides valuable lessons, software
myths propagate false beliefs and confusion in the minds of management, users and
developers.

1.3.1 Management Myths

Managers, who own software development responsibility, are often under strain and
pressure to maintain a software budget, time slippage, improved quality, and many other
considerations. Common management myths are listed in Table 1.1.

1.3.2 User Myths

In most cases, users tend to believe myths about the software because software
managers and developers do not try to correct the false beliefs. These myths lead to false
expectations and ultimately develop dissatisfaction among the users. Common user myths are
listed in Table 1.2.
Table 1.1 : Management Myths

Myths Realities
 The members of an organization  Standards are rarely used.
can acquire all the information  Developers rarely know about them.
they require from a manual which
 Standards are often out-of-date and
contains standards, procedures,
incomplete.
and principles.
 State-of-the-art hardware is the  Software tools are usually more important
essential ingredient for successful than hardware tools for achieving quality and
software production productivity.
 If the project is behind schedule,  Adding more manpower to the project, which
increasing the number of is already behind schedule, further delays the
programmers can reduce the time project.
gap.  New workers take longer to learn about the
project as compared to those already working
on the project.
 Software Engineering (MU) 1-7 Introduction

Myths Realities
 If the project is outsourced to a  Outsourcing software to a third party does not
third party, the management can help the organization, which is incompetent
relax and let the other firm in managing and controlling the software
develop software for them project internally. The organization invariably
suffers when it outsources the software
project

Table 1.2 : User Myths

Myths Realities
 Brief requirement stated in the initial  Insufficient knowledge about requirements
process is enough to start is the major cause of software failure.
development; detailed requirement
 Formal and detailed descriptions of data,
can be added at the later stages.
functionality, design constraints, and
validation criteria are essential.
 Communication between user and
developer is vital.
 Software is flexible, hence software  The impact of change varies according to
requirement; changes can be added the time when it is introduced.
during any phase of the development
 Early requests for change can be
process.
accommodated easily and can be much
cheaper.
 Changes made during design,
implementation and installation have a
severe impact on cost.

1.3.3 Developer Myths

In the early days of software development, programming was viewed as an art, but now
software development has gradually become an engineering discipline. However, developers
still believe in some myths. Some of the common developer myths are listed in Table 1.3.
 Software Engineering (MU) 1-8 Introduction

Table 1.3 : Developer Myths

Myths Realities

Software development is considered 50% to 70% of all the efforts are expended
complete when the code is delivered. after the software is delivered to the user.

The success of a software project The success of a project does not depend only
depends on the quality of the product on the quality of programs. Documentation and
produced. software configuration are also essential.

Software engineering makes unnecessary Software engineering is about creating quality

documentation, which slows down the at every level of the software project. Enhanced
project. quality results in reducing the amount of
rework.

The only deliverable is the working A working program is only one part of a
program(s). software configuration, which includes
requirements and specification documents,
testing information and other developmental
and maintenance information.
Software quality can be assessed only One of the most effective software quality
after the program is executed. assurance mechanisms is the formal technical
review, which can be applied from the
inception of the project.

1.4 Software Engineering Layers

Software engineering can be viewed as a layered technology (see Fig. 1.3). The various
layers are listed below :
 The process layer is an adhesive that enables rational and timely development of
computer software. It defines an outline for a set of key process areas that must be
acclaimed for effective delivery of software engineering technology.
 The method layer provides technical knowledge for developing software. This layer
covers a broad array of tasks that include requirements, analysis, design, program
construction, testing, and support phases of the software development.
 Software Engineering (MU) 1-9 Introduction

 The tools layer provides computerized or semi-computerized support for the process
and method layer. Sometimes tools are integrated in such a way that other tools can use
information created by one tool. This multi-usage is commonly referred to as computer-
aided software engineering. CASE combines software, hardware, and software
engineering database to create software engineering analogous to computer-aided design
(CAD) for hardware. CASE helps in application development including analysis, design,
code generation, and debugging and testing. This is possible by using CASE tools,
which provide automated methods for designing and documenting traditional-structure
programming techniques. For example, the two prominent delivered technologies using
CASE tools are application generators and PC-based workstations that provide graphics-
oriented automation of the development process.

Fig. 1.3 : Layers of Software Engineering

1.5 The Software Engineering Approach

The key objectives of software engineering are :

 Consistency
 Low cost
 High quality
 Small cycle time and
 Scalability
So, for high quality and productivity good technology has to be used, good processes
or methods have to be used, and the people doing the job have to be properly trained.
 Software Engineering (MU) 1-10 Introduction

Fig. 1.4 : The iron triangle

The basic approach of software engineering is to separate the process for developing
software from the developed product (i.e., the software). The premise is that the software
development process (or software process) controls the quality, scalability, consistency, and
productivity.
Design of proper software processes and their control then becomes a key goal of
software engineering research.
The software process must necessarily have components of project management, in
addition to procedures for development. Otherwise, scalability will not be achieved.
To better manage the development process and to achieve consistency, it is essential
that the software development be done in phases.

1.5.1 Phased Development Process

 A development process consists of various phases, each phase ending with a defined
output.
 The phases are performed in an order specified by the process model being followed.
 Objective of a phased process is to break the problem of developing software into
successfully performing a set of phases, each handling a different concern of software
development to lower the cost.
 It allows proper checking for quality and progress at some defined points during the
development (end of phases).
Hence, for managing the complexity, project tracking, and quality, all the
development processes consist of a set of phases. Various process models have been
proposed for developing software. We will discuss some process models in section 2.5.
 Software Engineering (MU) 1-11 Introduction

In general, any problem solving in software must consist of

 Requirement specification for understanding and clearly stating the problem,
 Design for deciding a plan for a solution,
 Coding for implementing the planned solution, and
 Testing for verifying the programs.
Though different process models will perform these phases in different manner, they
exist in all processes.

Phase 1 : Requirements Analysis

Requirements analysis is done in order to understand the problem the software system
is to solve. The emphasis in requirements analysis is on identifying what is needed from the
system, not how the system will achieve its goals. For complex systems, even determining
what is needed is a difficult task. The goal of the requirements activity is to document the
requirements in a software requirements specification document.

Two major activities in this phase :

 Problem understanding (or analysis) : the aim is to understand the problem and its
context, and the requirements of the new system that is to be developed.
 Requirement specification : Once the problem is analyzed and the essentials
understood, the requirements must be specified in the requirement specification
document. A preliminary user manual that describes all the major user interfaces
frequently forms a part of the requirements document. The requirements document must
specify all
o Functional and Performance requirements;
o The formats of inputs and outputs; and
o All design constraints that exist due to political, economic, environmental, and
security reasons.

Phase 2 : Software Design

Starting with what is needed; design takes us toward how to satisfy the needs. The
purpose of the design phase is to plan a solution of the problem specified by the
requirements document. The design activity often results in three separate outputs :
 Software Engineering (MU) 1-12 Introduction

1. Architecture design : Focuses on looking at a system as a combination of many

different components, and how they interact with each other to produce the desired
results
2. High level design : Identifies the modules that should be built for developing the
system and the specifications of these modules. At the end of system design all the
major data structures, file formats, output formats, etc., are also fixed.
3. Detailed design : The internal logic of each of the modules is specified.
In architecture the focus is on what major components are needed, in high level design
the attention is on what modules are needed, while in detailed design how the modules can
be implemented in software is the issue.

Phase 3 : Coding

The goal of the coding phase is to translate the design of the system into code in a
given programming language. Well written code can reduce the testing and maintenance
effort.

Phase 4 : Testing

The goal of testing is to uncover requirement, design, and coding errors in the
programs.
It starts with a test plan that identifies all the testing-related activities that must be
performed and specifies the schedule, allocates the resources, and specifies guidelines for
testing. The test plan specifies conditions that should be tested, different units to be tested,
and the manner in which the modules will be integrated.
Then for different test units, a test case specification document is produced, which
lists all the different test cases, together with the expected outputs.
During the testing of the unit, the specified test cases are executed and the actual result
compared with the expected output.
The final output of the testing phase is the test report and the error report, or a set of
such reports. Each test report contains the set of test cases and the result of executing the
code with these test cases. The error report describes the errors encountered and the action
taken to remove the errors.

A development process does not specify

 How to allocate resources to the different activities in the process,

 Software Engineering (MU) 1-13 Introduction

 Schedule for the activities,

 How to divide work within a phase,
 How to ensure that each phase is being done properly, or
 What the risks for the project are and how to mitigate them.
These issues relating to managing the development process of a project are handled
through Project Management.

1.6 Software Process

Software Process is a set of activities, together with ordering constraints among them,
such that if the activities are performed properly and in accordance with the ordering
constraints, the desired result is produced.
The basic desired result is, as stated earlier, high quality and productivity.
Process that does not scale up or cannot produce good-quality software is not a
suitable process.

1.6.1 Processes, Projects and Products

Software Process : Specifies a method of developing software.

Software Project : Is a development project in which software process is used.
Software Product : Is the outcomes of a software project.
One can view the software process as an abstract type, and each project is done using
that process as an instance of this type. There can be many projects for a process, and there
can be many products produced in a project. This relationship is shown in Fig. 1.5.

Fig. 1.5 : Processes, projects, and products

 Software Engineering (MU) 1-14 Introduction

Q. If the sequence of activities is provided by the Process, what is the difficulty in following it in a
Project ?

 The sequence of activities specified by the process is typically at an abstract level

because they have to be usable for a wide range of projects.
 The process provides a “checklist”, with ordering constraints.
 The process specifies activities at an abstract level that are not project specific.
 It is a generic set of activities that does not provide a detailed roadmap for a particular
project. The detailed roadmap for a particular project is the project plan that specifies
what specific activities to perform for this particular project, when and how to ensure
that the project progresses smoothly.
 It is the process that drives a project. A process limits the degrees of freedom for a
project by specifying what types of activities must be done and in what order. Further
restrictions on the degrees of freedom for a particular project are specified by the project
plan. A project plan cannot include performing an activity that is not there in the
process.
As each project is an instance of the process it follows. It is essentially the process that
determines the expected outcomes of a project.

1.7 Component Software Processes

The three basic types of entities that software engineering deals with- processes,
project, and products require different processes.
 Many types of activities performed by different people in a software project.
 Better to view software process as comprising of many component processes.
 Two major processes
o Development : Focuses on development and quality steps needed to engineer the
software.
o Project management : Focuses on planning and controlling the development
process.
 Development process is the heart of software process; other processes revolve around it.
 These are executed by different people.
o Development activities are performed by programmers, designers, testing
personnels, librarians, writers, etc.
o Project manager executes the project management process;
 Software Engineering (MU) 1-15 Introduction

o Configuration control activities are performed by a group called the

configuration control board;
o Process management activities are performed by a group software engineering
process group (SEPG).
 Other processes
o Configuration management process : manages the evolution of artifacts.
o Change management process : how changes are incorporated.
o Process management process : management of processes themselves.
o Inspection process : How inspections are conducted on artifacts.

Fig. 1.6 : Software processes

Verification : The process of evaluating a system or component to determine whether

the products of a given development phase satisfy the conditions imposed at the start of that
phase.
Validation : The process of evaluating a system or component during or at the end of
the development process to determine whether it satisfies specified requirements.
As process consists of a sequence of steps, let us first understand what should be
specified for a step.

1.8 A Process Step Specification

.MU - May 04, June 05.
 A process has a set of phases (or steps), each phase performing a well-defined task.
 Most process models specify the steps that need to be performed and the order in which
they need to be performed.
 The output of a step must be a formal and tangible entity. Output of step is called as the
work products. In software, a work product can be the requirements document, design
document, code, prototype, etc.
 Software Engineering (MU) 1-16 Introduction

 The process should have a small number of steps. Having too many steps results in too
many work products or documents, each requiring V and V (Verification and
Validation), and can be very expensive.
 How to perform the activity of the particular step or phase is generally addressed by
methodologies for that activity rather than development process.
 The entry criteria of a phase specify the conditions that the input to the phase should
satisfy to initiate the activities of that phase.
 The exit criteria specify the conditions that the work product of this phase should
satisfy to terminate the activities of the phase.
 The entry and exit criteria specify constraints of when to start and stop an activity. It
should be clear that the entry criteria of a phase should be consistent with the exit criteria
of the previous phase.
 The inputs and outputs of a step also need to be clearly specified.
 As errors can be introduced in every stage, a stage should end with some verification of
its activities, and these should also be clearly stated.
 The specification of a step with its input, output, and entry and exit criteria is shown in
Fig. 1.7. This approach for process specification is called the ETVX (Entry criteria.
Task, Verification, and exit criteria) approach
 A step needs to produce some information to aid proper management of the development
process.
 Generally, the information flow from a step is in the form of summary reports describing
the amount of resources spent in the phase, schedule information, errors found in the V
and V activities, etc at each defined time intervals in the development process.
 It should be clear that entry and exit criteria and the nature of information flow depends
on how the process is implemented in an organization and on the project. Consequently,
process models typically do not specify these. However, they must be specified by an
organization, if it wishes to adopt a process model for software development.

Fig. 1.7 : A step in a development process

As now it’s very clear what a step is, let’s see some major process models used in
software development process.
 Software Engineering (MU) 1-17 Introduction

1.9 Software Development Process Models

.MU - Oct 04, June 05, May 09.
We are going to learn following process models :
 Waterfall  Prototyping
 Incremental  Iterative development
 Rapid Application Development (RAD)  Object oriented
 Spiral  Concurrent development
 Rational Unified Process  Time Boxing Model
 Extreme programming and Agile Process

Why use a Life Cycle Model ?

The primary advantage of adhering to a life cycle model is that it encourages

development of software in a systematic and disciplined manner. When a program is
developed by a single programmer, he has the freedom to decide the exact steps through
which he will develop the program. However when a software product is developed by a
team, it is necessary to have a precise understanding among the team members as to when to
do what. Otherwise it may lead to chaos and failure.

Fig. 1.8 : Life cycle phases and activities

 Software Engineering (MU) 1-18 Introduction

IEEE defines a process model as ‘a framework containing the processes, activities, and
tasks involved in the development, operation, and maintenance of a software product,
spanning the life of the system from the definition of its requirements to the termination of its
use’.
Process model for software engineering is chosen based on :
i) Nature of project and application.
ii) The methods and tools to be used.
iii) Controls and deliverables those are required.
1.9.1 Linear Sequential Model or Classic Life Cycle or Waterfall
.MU - Nov. 05, May 07.
This model represents the software life cycle using processes and products. Each
process transforms a product to produce a new product as output. Then the new product
becomes the input of the next process.

Fig. 1.9 : The waterfall model

 Software Engineering (MU) 1-19 Introduction

It’s a framework for software development in which development proceeds

sequentially through a series of phases, starting with system requirements analysis and
leading up to product release and maintenance. Feedback loops exist between each phase, so
that as new information is uncovered or problems are discovered, it is possible to “go back”
a phase and make appropriate modification. Progress “flows” from one stage to the next,
much like the waterfall that gives the model its name.
A number of variants of this model exist, with each one quoting slightly different
labels for the various stages. In general, however, the model may be considered as having six
distinct phases, described below :

1. Requirements analysis :

 It involves gathering information about what the customer needs and defining, in the
clearest possible terms, the problem that the product is expected to solve.
 Analysis includes understanding the customer’s business context and constraints, the
functions the product must perform, the performance levels it must adhere to, and the
external systems it must be compatible with.
 Techniques used to obtain this understanding include customer interviews, use cases,
and “shopping lists” of software features.
 The results of the analysis are typically captured in a formal requirements
specification, which serves as input to the next step.

2. Design :

 It is a multistep process that focuses on four distinct attributes of a program:-data

structure, software architecture, interface representation, and procedural
(algorithmic) detail.
 It involves defining the hardware and software architecture, specifying performance
and security parameters, designing data storage containers and constraints, choosing
the IDE and programming language, and indicating strategies to deal with issues
such as exception handling, resource management and interface connectivity.
 This is also the stage at which user interface design is addressed, including issues
relating to navigation and accessibility.
 The output of this stage is one or more design specifications, which are used in the
next stage of implementation.
 Software Engineering (MU) 1-20 Introduction

3. Implementation :

 Constructing the product as per the design specification(s) developed in the previous
step.
 It is performed by a development team consisting of programmers, interface
designers and other specialists, using tools such as compilers, debuggers, interpreters
and media editors.
 The output of this step is one or more product components, built according to a pre-
defined coding standard and debugged, tested and integrated to satisfy the system
architecture requirements.
 For projects involving a large team, version control is recommended to track changes
to the code tree and revert to previous snapshots in case of problems.

4. Testing :

 In this stage, both individual components and the integrated whole are methodically
verified to ensure that they are error-free and fully meet the requirements outlined in
the first step.
 An independent quality assurance team defines “test cases” to evaluate whether the
product fully or partially satisfies the requirements outlined in the first step.
 Three types of testing typically take place: unit testing of individual code modules;
system testing of the integrated product; and acceptance testing, formally conducted
by or on behalf of the customer.
 Defects, if found, are logged and feedback provided to the implementation team to
enable correction.
 This is also the stage at which product documentation, such as a user manual, is
prepared, reviewed and published.

5. Installation :

 This step occurs once the product has been tested and certified as fit for use, and
involves preparing the system or product for installation and use at the customer site.
 Delivery may take place via the Internet or physical media, and the deliverable is
typically tagged with a formal revision number to facilitate updates at a later date.
 Software Engineering (MU) 1-21 Introduction

6. Maintenance :

 This step occurs after installation, and involves making modifications to the system
or an individual component to alter attributes or improve performance.
 These modifications arise either due to change requests initiated by the customer, or
defects uncovered during live use of the system.
 Typically, every change made to the product during the maintenance cycle is
recorded and a new product release (called a “maintenance release” and exhibiting
an updated revision number) is performed to enable the customer to gain the benefit
of the update.
Table 1.4 : Processes and Products of the Waterfall Model

Input Product Process Output Product

Communicated Requirements Requirements Engineering Requirements Specification
Document
Requirements Specification Design Design Specification
Document Document
Design Specification Programming Executable Software Modules
Document
Executable Software Modules Integration Integrated Software
Product
Integrated Software Product Delivery Delivered Software Product
Delivered Software Product Maintenance Changed Requirements
Notice that as shown in Fig. 1.10 the output product on the right becomes the input
product on the left of the process at the next lowest level. The general formula for describing
the transformation of products by processes can be written as follows:

Fig. 1.10 : Transformation of the Products by the Process

 No phase is complete until the documents for the phase are complete and approved by
the Software Quality Assurance group.
 Each stage generates documents known as deliverables.
 Software Engineering (MU) 1-22 Introduction

Advantages of Waterfall Model

1. Stages and activities are well defined.

2. Helps to plan and schedule the project.
3. Verification at each stage ensures early detection of errors / misunderstanding.
4. Formal documentation ensures that system requirements can be traced back to stated
business needs.
5. Formal review of the end of each phase allows maximum management control.
6. Simple and easy to use.
7. Easy to manage due to the rigidity of the model – each phase has specific deliverables
and a review process.
8. Phases are processed and completed one at a time.
9. Works well for smaller projects where requirements are very well understood.

Why linear model does sometimes fails? (Disadvantages)

i) It leads to “blocking states” in which some project team members must wait for other
members of team to complete dependent task. In fact, time spent on waiting can
exceed the time spent on productive work.
ii) Real projects rarely follow sequential flow that the model process. Since, linear model
can accommodate iteration indirectly; changes can cause confusion as project team
proceeds.
iii) The waterfall model assumes that the requirements of a system can be frozen (i.e.
baseline) before the design begins. This is possible for systems designed to automate an
existing manual system. But for absolutely new system, determining the requirements is
difficult, as the user himself does not know the requirements. Therefore, having
unchanging (or changing only a few) requirements is unrealistic for such project.
iv) The customer must have patience. A working version of programs will not be available
until late in project time span. A major blunder (mistake), if undetected until the
working program is reviewed, can be disastrous.
v) Freezing the requirements usually requires choosing the hardware (since it forms a part
of the requirement specification). A large project might take a few years to complete. If
the hardware is selected early, then due to the speed at which hardware technology is
changing, it is quite likely that the final software will employ a hardware technology
that is on the verge of becoming obsolete. This is clearly not desirable for such
expensive software.
 Software Engineering (MU) 1-23 Introduction

vi) It is a document-driven process that requires formal documents at the end of each
phase. This approach tends to make the process documentation-heavy and is not
suitable for many applications, particularly interactive applications, where developing
elaborate documentation of the user interface is not feasible. Also, if the development
is done using fourth-generation languages or modern development tolls, developing
elaborate specifications before implementation is sometimes unnecessary.
vii) It encourages “requirements bloating”. Since all requirements must be specified at the
start and only what is specified will be delivered, it encourages the users and other
stakeholders to add even those features which they think might be needed (which
finally may not get used).
viii) It follows the “big bang” approach the entire software is delivered in one shot at the
end. This entails heavy risks, as the user does not know until the very end what they
are getting. Furthermore, if the project runs out of money in the middle, then there will
be no software. That is, it has the “all or nothing” value proposition.
Conclusion : If requirements are well understood, then this model is most suitable.

1.9.2 Prototyping Model .MU - May 06.

Fig. 1.11 : Types of Prototypes

 Reusable prototype : Prototype that will be transformed to the final product.

 Throwaway prototype : Prototype that will be thrown away as it completes its job.
 Input/output prototype : Prototype that was limited to the user interface.
 Software Engineering (MU) 1-24 Introduction

 Processing prototype : Prototype that covered the maintenance file the foundation and
processes of the transaction.
 System prototype : Prototype that took the form of the complete model from software.

Fig. 1.12 : Prototyping Model

A prototype usually exhibits limited functional capabilities, low reliability, and

inefficient performance compared to the actual software. A prototype is usually built using
several shortcuts. The shortcuts might involve using inefficient, inaccurate, or dummy
functions.

Fig 1.13 : General Workflow of Prototyping Model

 Software Engineering (MU) 1-25 Introduction

Prototype : ideally, prototype serves as a mechanism for identifying software

requirements.
Working of model
i) It begins with requirement gathering,
ii) Developer and customer both together define the overall objectives for software, identify
whatever requirements are known, and outline areas further definition is mandatory,
iii) A quick design then occurs, focuses on a representation of those aspects of software that
will be visible to customer/user (e.g. input approaches and output formats),
iv) The quick design leads to the construction of a prototype,
v) The prototype is evaluated by customer / user and used to refine requirements for
software to be developed. Iteration occurs as the prototype is turned to satisfy the needs
of the customer, while at same time enabling developer to better understand what need
to be done.

How cost gets reduced in prototyping ?

i) For prototyping for the purposes of requirement analysis to be feasible, its cost must be
kept low. Consequently, only those features are included in prototype that will have a
valuable return from the user experience. Exception handling, recovery, and
conformance to some standards and formats are typically not included in prototypes.
ii) In prototyping, as the prototype is to be discarded, there is no point in implementing
those part of requirements that are well understood. Hence, the focus of the development
is to include those features that are not properly understood with the focus on quick
development rather than quality.
iii) Because the prototype is to be thrown away, only minimal documentation needs to be
produced during prototyping. For e.g., design document, test plan, and a test case
specification are not needed during the development of prototype.
iv) Reduce testing because testing consumes a major part of development expenditure
during regular software development.

When to use prototype model ?

i) Often, customer defines a set of general objectives for software, but does not identify
detailed input, processing, or output requirements,
ii) In other case, the developer may be unsure of efficiency of an algorithm, the adaptability
of an operating system, or the form that human / machine interaction should take,
 Software Engineering (MU) 1-26 Introduction

iii) In these and many other situations, a prototyping paradigm (model) may offer the best
approach.

Reasons for prototyping can also be problematic

i) From customer side : It is unaware that in rush to get working version of software no
one has been considered overall software quality or long-term maintainability.
ii) From developer side : an inappropriate operating system or programming language
may be used simply because it is available and known; an inefficient algorithm may be
implemented simply to demonstrate capability. After a time, the developer may
become familiar with these choices and forget all the reasons why they were
inappropriate.
iii) Resist pressure to extend a rough prototype into a production product. Quality almost
always suffers as a result.
iv) Prototyping can lead to false expectations. Prototyping often creates a situation
where the customer mistakenly believes that the system is “finished” when in fact it is
not. More specifically, when using the Prototyping Model, the pre-implementation
versions of a system are really nothing more than one-dimensional structures. The
necessary, behind-the-scenes work such as database normalization, documentation,
testing, and reviews for efficiency has not been done. Thus the necessary
underpinnings for the system are not in place.
v) Prototyping can lead to poorly designed systems. Because the primary goal of
Prototyping is rapid development, the design of the system can sometimes suffer
because the system is built in a series of “layers” without a global consideration of the
integration of all other components. While initial software development is often built
to be a “throwaway,” attempting to retroactively produce a solid system design can
sometimes be problematic.
Table 1.5 : Advantages and Disadvantages of Prototyping Model

Advantages Disadvantages
Users can try the system and provide Each iteration builds on the previous iteration and
constructive feedback during further refines the solution. The makes it difficult
development. to reject the initial solution as inappropriate and
start over. Thus, the final solution will be only
incrementally better than the first.
 Software Engineering (MU) 1-27 Introduction

Advantages Disadvantages

An operational prototype can be Formal end-of-phase reviews do not occur. Thus,

produced in weeks. it is very difficult to contain the scope of the
prototype, and the project never seems to end.

Users become more positive about System documentation is often absent or

implementing the system as they see a incomplete, since the primary focus is on
solution emerging that will meet their development of the prototype.
needs.

Prototyping enables early detection of System backup and recovery, performance and
errors and omissions. security issues can be overlooked in the haste to
develop a prototype.

1.9.3 Incremental Model

.MU - Nov. 07, May 08, May 09, June 10, June 10(Old).

Fig. 1.14 : Incremental Model

i) Combines elements of linear sequential model (applied repetitively) with iterative

philosophy of prototyping.
ii) Each linear sequence produces a deliverable “increment” of software.
 Software Engineering (MU) 1-28 Introduction

iii) Example of word processing software.

o Increment 1 : Deliver basic file management, editing and document products.
o Increment 2 : More sophisticated editing and document production capability.
o Increment 3 : Spelling and grammar checking.
o Increment 4 : Advanced page layout capability.
iv) It should be noted that process flow for any increments can incorporate the prototyping
paradigm.
v) First increment is often a core product, i.e. basic requirements are addressed, but many
supplementary features (some known, other unknown) remain undeliverable. Core
product is used by customer (or undergoes detailed review).
vi) As a result of use and/or evaluation, a plan is developed for the next increment. The
plan addresses the modification of core product to better meet the need of customer
and delivery of additional features and functionality.
vii) This process is repeated following the delivery of each increment, until the complete
product is produced.
viii) Early increments are stripped down (to open, release) versions of final product, but
they do provide capabilities that serves the user and also provide a platform for
evaluation by user.

When to use incremental model ?

i) Useful when staffing is unavailable for a complete implementation by business

deadline that has been established for project.
ii) Early increments can be implemented with fewer people.
iii) If core product is well received, then additional staff (if required) can be added to
implement next increment.
iv) Increments can be planned to manage technical risk.
Example : A major system might require availability of new hardware i.e. under
development and whose delivery date is uncertain. It might be possible to plan early
increments in a way that avoids the use of that hardware, thereby enabling partial
functionality to be delivered to end users without inordinate delay.
 Software Engineering (MU) 1-29 Introduction

Key point : The incremental model delivers software in small but usable pieces called
“increments”. In general, each increment builds on those that have already been delivered.
Advice : When you encounter difficult deadline that cannot be changed, the
incremental model is a good paradigm to consider.

Advantages of the incremental model

1. Avoids the problems resulting in risk-driven approach in the software.
2. Understanding of the problem increases through successive refinements.
3. Performs cost-benefit analysis before enhancing software with capabilities.
4. Incrementally grows in effective solution after each multiple iteration.
5. Does not involve a high complexity rate.
6. Early feedback is generated, because implementation occurs rapidly for a small sub-set
of the software.

Disadvantages of the incremental model

1. Requires planning at the management and technical level

2. Becomes invalid when there is time constraint in the project schedule or when the
users cannot accept the phased deliverables.

1.9.4 Iterative Enhancement Model

Fig. 1.15 : Iterative development model

An iteration consists of the application of the core disciplines of software development

to produce a demonstrable, executable release of the product under development and
ensuring that the product will be grown incrementally across a series of iterations, each
building on the product and lessons learned from the previous iteration.
Iterative development is, at its heart, a team-based approach to problem solving and
solution development. It requires all parties involved -- including the development team, the
customer team, and the management team -- to adopt collaborative techniques.
 Software Engineering (MU) 1-30 Introduction

Fig. 1.16 : An Iterative Development of project from the project manager’s perspective

From the perspective of the development team,

 Enable team members to actively and aggressively attack project risks and challenges in
whatever they judge to be the most appropriate manner.
 Managing iterations by setting clear objectives and objectively measuring results (and
not dictating activities) ensures that they are free to find the best way to deliver results.
From a customer and business team perspective,

 The introduction of clear, meaningful objectives, combined with the ability to review
demonstrable results, allows those who will ultimately use the new software to take an
active role in the project and share its ownership with the development team.

 Iteration has a profound and lasting impact upon all of the business people involved in
the project and fundamentally changes the way that they specify, pay for, and realize the
business benefits of software solutions.
From a management team perspective,

 Each project is decomposed into a series of smaller projects, called iterations, each of
which builds on the results of the previous one to incrementally achieve overall project
goals.
 Software Engineering (MU) 1-31 Introduction

 This segmentation of the project introduces regular, measurable milestones that keep the
project on track while empowering the development team to create innovative and
effective solutions, maximizing the project’s probability of success.

Why iterations ?

Purpose :

 Reduce project risk.

 Late risks identified early.
 Understand required quality early.

 Have something that runs very early in the project.

Iterative developments display these characteristics :

 Highest risk items are built first.

 Change is expected and accommodated, but controlled.
 Testing occurs early and often.

 Iterations are time-boxed not function-boxed.

 Deliver early, deliver often.
 Deliver production quality software each time.

Advantages of the Iterative enhancement model

 Early risk discovery and mitigation.

 Accommodates change and provokes earlier identification of change.

 Manageable complexity.
 Confidence from early, repeated success.
 Early partial product.
 Better progress tracking and predictability.
 Higher quality, fewer defects.
 Software better matches user needs.
 Software Engineering (MU) 1-32 Introduction

 Early and regular process improvement.

 Communication and engagement demanded.
 Prototyping and feedback encouraged.

Iterative vs. prototyping

 Iterative development is not prototyping :

o The output of an iteration is NOT an experimental or throw-away prototype.
o The output of an iteration is a production-grade subset of the final system.

 Each iteration tackles new requirements and incrementally extends the system.

Iterations vs. Increments

 When discussing iterative and incremental development, the terms iteration and
increment are often used freely and interchangeably. They are not, however, synonyms.
Iteration refers to the cyclic nature of a process in which activities are repeated in a
structured manner. And increment refers to the quantifiable outcome of each iteration.

 When you work incrementally you are adding piece by piece but expect that each piece
if fully finished.

 When you work iteratively you create rough product or product piece in one iteration,
then review it and improve it in next iteration and so on until its finished.

1.9.5 RAD (Rapid Application Development) Model

When to use RAD model ?

1. It is an incremental software development process model.
 Software Engineering (MU) 1-33 Introduction

2. It emphasizes on extremely short development cycle.

3. It is a high speed adaptation of linear sequential model in which rapid development
achieved using component based construction.
4. If requirements are well understood and project scope is constrained, RAD enables
project team to create a “fully functional system” within very short time like 30 to 60
days.

5. It used primarily for information system application.

The RAD approach encompasses following phases :

Business modeling

 The information among business function is modeled in a way that answers following
questions :
i) What information drives the business process ?
ii) What information is generated ?
iii) What information is generated ?
iv) Who generate it ?
v) Where the information does goes ?
vi) Who process it ?

Data modeling

i) Information flow is refined into a set of data object.

ii) The characteristics (attributes) of each objects are identified.
iii) Relationship between these objects defined.

Process modeling

i) The data objects are transformed to implement a business function to achieve the
information flow necessary.
ii) Processing descriptions are created for adding, modifying, deleting, or retrieving a
data object.
 Software Engineering (MU) 1-34 Introduction

Fig. 1.17 : RAD Model

 Application generation
i) RAD assumes the use of fourth generation technique.
ii) RAD process works to reuse existing program components (when possible) or
create reusable components (when necessary).
iii) In all cases automated tools are used to facilitate construction of software.
 Testing and Turnover
i) Since, RAD emphasizes reuse; many of program components have already been
tested.
ii) This reduces overall testing time.
 Software Engineering (MU) 1-35 Introduction

iii) However, new components must be tested, and all interfaces must be fully
exercised.
 Drawback
1. For large but scalable projects, RAD requires sufficient human resources to create
the right number of RAD teams.
2. RAD requires developers and customers who are committed to rapid fire activities
necessary to get a system complete in much abbreviated time frame. If
commitment is lacking from either side, RAD project will fail.
3. Not all types of applications are appropriate for RAD. If a system can not be
properly modularized, building the components necessary for RAD will
problematic. If high performance is an issue and performance is to be achieved
through tuning the interfaces to system component, the RAD approach may not
work.
4. RAD is not appropriate when technical risks are high. This occurs when a new
application makes heavy use of new technology or when new software requires
high degree of interoperability with existing computer program.
Advantages Disadvantages
For appropriate projects, this approach puts This intense SDLC can burn out systems
an application into production sooner than developers and other project participants.
any other approach.
Documentation is produced as a byproduct This approach requires systems analysts
of completing project tasks. and users to be skilled in RAD system
development tools and RAD techniques.
RAD forces teamwork and lots of RAD requires a larger percentage of
interaction between users and stakeholders. stakeholders’ and users’ time than other
approaches.

1.9.6 Object Oriented Model or Component Based Development Model (CBD)

.MU - June 05, Nov. 07, Dec. 08.

i) Object oriented technology provides technical framework for this model, which
emphasizes the creation of classes that encapsulates both data and algorithm used to
manipulate data.
 Software Engineering (MU) 1-36 Introduction

ii) CBD model incorporates many of the characteristics of spiral model. However,
component based development model composes application from pre-packaged
software components called classes.
iii) The engineering activity begins with identification of candidate classes. [This is
accomplished by examining the data to be manipulated by application and algorithm
that will be applied to accomplish the manipulation.]
iv) Corresponding data and algorithm are packaged into a class. Classes created in past SE
project are stored in a Class library or Repository.
v) Once candidate classes are identified, class library is searched to determine if they
already exists. If they do, they are extracted from library and reused. If no, it is
engineered using object oriented methods.
vi) The first iteration of application to be built is then composed using classes extracted
from library.
vii) Process flow then returns to spiral model and ultimately re-enter the component
assembly iteration during subsequent passes through engineering activity.

Fig. 1.18 : Object Oriented Model

 Advantages of OO model
i) Model leads to software reuse. Reusability provides software engineer with a
number of measurable benefits.
 Software Engineering (MU) 1-37 Introduction

ii) Based on study of reusability, QSM Associates, Inc reported component assembly
leads to
o 70% (↓) reduction in development cycle time.
o 84 %(↑) reduction in project class.
o Production index of 26.2 %(↑) compared to industry norm of 16.9%.
 Example
Unified software development process is representation of a number of component
based development models, using UML.
Demerit of OO model

 Risk involved with reusability may produce defects.

1.9.7 Spiral Model .MU - June 05, Nov. 06, May 07, May 08, Dec. 08, Dec. 09.

Fig. 1.19 : Spiral Model

i) Model that couples the iterative nature of prototyping with the controlled and
systematic aspects of linear sequential model.
ii) Software is developed in a series of incremental releases.
 Software Engineering (MU) 1-38 Introduction

iii) During early iterations, the incremental release might be a paper model or prototype.
During later iterations, increasingly more complete versions of engineered systems are
produced.
iv) A spiral model is divided into a number of framework activities also called as task
regions.

Six task regions

a) Customer communication

Task required to establish effective communication between developer and customer.

b) Planning

Task required to define resources, timelines and other project related information.
c) Risk analysis

Task required to assess (to estimate) both technical and management risk.
d) Engineering

Task required to build one or more representations of applications.

e) Construction and release

Task required to construct, test, install, and provide user support (e.g. documentation
and training).
f) Customer evaluation

Tasks required to obtain customer feedback based on evaluation of software

representation created during the engineering stage and implemented during installation
stage.
i) Each of regions is populated by a set of work task called a “task set”. In all cases
umbrella activities are applied.
ii) As evolutionary process begins, software engineering team moves around spiral
in a clockwise direction, beginning at the center.
iii) Unlike classical process models that end when software is delivered, spiral model
can be adapted to apply lifecycle of computer software.
iv) Each cube placed along project entry point axis can be used to represent starting
point for different types of projects.
 Software Engineering (MU) 1-39 Introduction

Advantages

1. Direct consideration of management/technical risk.

2. Maintains systematic stepwise and approach mentioned by classic lifecycle + iterative
framework.
3. Realistic approach to development of large scale system software.
4. Uses prototyping as a risk reduction mechanism.
5. Unlike prototyping as a risk reduction mechanism.
6. Unlike classical process models that ends when software is delivered.

Drawbacks

1. It may be difficult to convince customer’s (particularly in contract situations) that

evolutionary approach is controllable.
2. It demands considerable risk assessment expertise and relies on this expertise for
success.
3. If a major risk is not uncovered and managed, problems will undoubtedly occur.
4. Finally, the model has not been used as widely as linear sequential or prototyping
paradigm.

1.9.8 The Concurrent Development Model .MU - Nov. 05.

The concurrent development model, sometimes called concurrent engineering. The

concurrent process model can be represented schematically as a series of major technical
activities, tasks, and their associated states.
Fig. 1.20 provides a schematic representation of one activity with the concurrent
process model. The activity analysis may be in any one of the states noted at any given time.
Similarly, other activities (e.g., design or customer communication) can be represented in an
analogous manner. All activities exist concurrently but reside in different states. For
example, early in a project the customer communication activity (not shown in the Fig. 1.20)
has completed its first iteration and exists in the awaiting changes state. The analysis
activity (which existed in the none state while initial customer communication was
completed) now makes a transition into the under development state. If, however, the
customer indicates that changes in requirements must be made, the analysis activity moves
from the under development state into the awaiting changes state.
 Software Engineering (MU) 1-40 Introduction

The concurrent process model defines a series of events that will trigger transitions
from state to state for each of the software engineering activities.
For example, during early stages of design, an inconsistency in the analysis model is
uncovered. This generates the event analysis model correction which will trigger the
analysis activity from the done state into the awaiting changes state.

Fig. 1.20 : One element of the concurrent process model

The concurrent development model is often more appropriate for system engineering
projects where different engineering teams are involved.

1.9.9 Rational Unified Process (RUP)

The Unified Process (UP) (also called Rational Unified Process or RUP because they
are nearly identical) is currently one of the most famous development processes among with
the Agile methodology (which are more methodologies then a development process). It uses
an iterative approach and it is based on programming Best practices.
 Software Engineering (MU) 1-41 Introduction

All the Agile processes are more adapted for small or average teams projects, but they
can be grouped with RUP (which gives AUP). RUP remains by far more used and more
adapted for the very large projects, however it is possible to use it even in a one-person
team. I nevertheless invite you to rather use AUP (Agile Unified Process) if you’re alone.

Overview of the UP

Fig. 1.21 : The Iterative Model graph shows how the process is structured along two dimensions

Two Dimensions

The process can be described in two dimensions, or along two axes as shown in
Fig. 1.21.

 The horizontal axis represents time and shows the dynamic aspect of the process as it is
enacted, and it is expressed in terms of cycles, phases, iterations, and milestones.
 The vertical axis represents the static aspect of the process: how it is described in terms
of activities, artifacts, workers and workflows.
 Software Engineering (MU) 1-42 Introduction

Phases and Iterations - The Time Dimension

This is the dynamic organization of the process along time.

The software lifecycle is broken into cycles, each cycle working on a new generation
of the product. The Rational Unified Process divides one development cycle in four
consecutive phases :
 Inception phase

 Elaboration phase

 Construction phase

 Transition phase

Each phase is concluded with a well-defined milestone a point in time at which certain
critical decisions must be made and therefore key goals must have been achieved. Each
phase has a specific purpose.

1. Inception Phase

During the inception phase, you establish the business case for the system and delimit
the project scope. To accomplish this you must identify all external entities with
which the system will interact (actors) and define the nature of this interaction at a
high-level. This involves identifying all use cases and describing a few significant
ones. The business case includes success criteria, risk assessment, and estimate of the
resources needed, and a phase plan showing dates of major milestones.
The outcome of the inception phase is :
 A vision document: a general vision of the core project’s requirements, key features,
and main constraints.
 An initial use-case model (10% -20%) complete).
 An initial project glossary (may optionally be partially expressed as a domain
model).
 An initial business case, which includes business context, success criteria (revenue
projection, market recognition, and so on) and financial forecast.
 An initial risk assessment.
 A project plan, showing phases and iterations.
 A business model, if necessary.
 One or several prototypes.
 Software Engineering (MU) 1-43 Introduction

The project may be cancelled or considerably re-thought if it fails to pass this

milestone.

2. Elaboration Phase

 The purpose of the elaboration phase is to analyze the problem domain, establish a
sound architectural foundation, develop the project plan, and eliminate the highest
risk elements of the project.
 Architectural decisions have to be made with an understanding of the whole system :
its scope, major functionality and non-functional requirements such as performance
requirements.
 The elaboration phase activities ensure that the architecture, requirements and plans
are stable enough, and the risks are sufficiently mitigated, so you can predictably
determine the cost and schedule for the completion of the development.
 An executable architecture prototype is built in one or more iterations, depending on
the scope, size, risk, and novelty of the project.
The outcome of the elaboration phase is :
 A use-case model (at least 80% complete) all use cases and actors have been
identified and most use case descriptions have been developed.
 Supplementary requirements capturing the non functional requirements and any
requirements that are not associated with a specific use case.
 A Software Architecture Description.
 An executable architectural prototype.
 A revised risk list and a revised business case.
 A development plan for the overall project, including the coarse-grained project plan,
showing iterations” and evaluation criteria for each iteration.
 An updated development case specifying the process to be used.
 A preliminary user manual (optional).
 Software Engineering (MU) 1-44 Introduction

At the end of the elaboration phase is the second important project milestone, the
Lifecycle Architecture Milestone. At this point, you examine the detailed system objectives
and scope, the choice of architecture, and the resolution of the major risks.
The project may be aborted or considerably re-thought if it fails to pass this milestone.

3. Construction Phase

 All remaining components and application features are developed and integrated into
the product, and all features are thoroughly tested.
 The outcome of the construction phase is a product ready to put in hands of its end-
users. At minimum, it consists of :
o The software product integrated on the adequate platforms.
o The user manuals.
o A description of the current release.

 At the end of the construction phase is the third major project milestone (Initial
Operational Capability Milestone). At this point, you decide if the software, the sites,
and the users are ready to go operational, without exposing the project to high risks.
This release is often called a “beta” release.
 Transition may have to be postponed by one release if the project fails to reach this
milestone.

4. Transition Phase

 The purpose of the transition phase is to transition the software product to the user
community. Once the product has been given to the end user, issues usually arise that
require you to develop new releases, correct some problems, or finish the features
that were postponed.
 The transition phase is entered when a baseline is mature enough to be deployed in
the end-user domain.
 Software Engineering (MU) 1-45 Introduction

 This typically requires that some usable subset of the system has been completed to
an acceptable level of quality and that user documentation is available so that the
transition to the user will provide positive results for all parties.
 This phase includes several iterations, including beta releases, general availability
releases, as well as bug-fix and enhancement releases.
 Considerable effort is expended in developing user-oriented documentation, training
users, supporting users in their initial product use, and reacting to user feedback.
 This includes :
o “Beta testing” to validate the new system against user expectations.
o Parallel operation with a legacy system that it is replacing.
o Conversion of operational databases.
o Training of users and maintainers.
o Roll-out the product to the marketing, distribution, and sales teams.
The primary objectives of the transition phase include :
 Achieving user self-supportability.
 Achieving stakeholder concurrence that deployment baselines are complete and
consistent with the evaluation criteria of the vision.
 Achieving final product baseline as rapidly and cost effectively as practical.

 At the end of the transition phase is the fourth important project milestone, the Product
Release Milestone.
 At this point, you decide if the objectives were met, and if you should start another
development cycle. In some cases, this milestone may coincide with the end of the
inception phase for the next cycle.

Iterations

 Each phase in the Rational Unified Process can be further broken down into iterations.
 An iteration is a complete development loop resulting in a release (internal or external)
of an executable product, a subset of the final product under development, which grows
incrementally from iteration to iteration to become the final system.
 Software Engineering (MU) 1-46 Introduction

Benefits of an iterative approach

Compared to the traditional waterfall process, the iterative process has the following
advantages :
 Risks are mitigated earlier.
 Change is more manageable.
 Higher level of reuse.
 The project team can learn along the way.
 Better overall quality.

Static Structure of the Process

Fig. 1.22 : Workers, activities and artifacts

A process describes who is doing what, how, and when. The Rational Unified Process
is represented using four primary modeling elements :
 Workers, the ‘who’.
 Activities, the ‘how’.
 Artifacts, the ‘what’.
 Workflows, the ‘when’.

Worker

 A worker defines the behavior and responsibilities of an individual, or a group of

individuals working together as a team.
 Software Engineering (MU) 1-47 Introduction

 In the Unified Process the worker is more the role defining how he individuals should
carry out the work.

Fig. 1.23 : People and Workers

Activity

 An activity of a specific worker is a unit of work that an individual in that role may be
asked to perform.
 The activity has a clear purpose, usually expressed in terms of creating or updating some
artifacts, such as a model, a class, a plan.
 Every activity is assigned to a specific worker.
 The granularity of an activity is generally a few hours o a few days, it usually involves
one worker, and affects one or only a small number of artifacts.
 An activity should e usable as an element of planning and progress; if it is too small, it
will be neglected, and if it is too large, progress would have to be expressed in terms of
an activity’s parts.
Example of activities :
 Plan an iteration, for the Worker : Project Manager.
 Find use cases and actors, for the Worker : System Analyst.
 Review the design, for the Worker : Design Reviewer.
 Execute performance test, for the Worker : Performance Tester.

Artifact

An artifact is a piece of information that is produced, modified, or used by a process.

 Software Engineering (MU) 1-48 Introduction

Artifacts are used as input by workers to perform an activity, and are the result or
output of such activities.
Various Artifacts :

 A model, such as the Use-Case Model or the Design Model.

 A model element, i.e. an element within a model, such as a class, a use case or a
subsystem.
 A document, such as Business Case or Software Architecture Document.
 Source code.
 Executables.

Workflows

 A workflow is a sequence of activities that produces a result of observable value.

Fig. 1.24 : Example of workflow

 Software Engineering (MU) 1-49 Introduction

 In UML terms, a workflow can be expressed as a sequence diagram, a collaboration

diagram, or an activity diagram.

Core workflows

There are nine core process workflows in the Rational Unified Process, which
represent a partitioning of all workers and activities into logical groupings.
The core process workflows are divided into six core “engineering” workflows :
1. Business modeling workflow : In Business Modeling we document business
processes using so called business use cases. This assures a common understanding
among all stakeholders of what business process needs to be supported in the
organization.
2. Requirements workflow : The goal of the Requirements workflow is to describe what
the system should do and allows the developers and the customer to agree on that
description.
3. Analysis and Design workflow : The goal of the Analysis and Design workflow is to
show how the system will be realized in the implementation phase.
4. Implementation workflow : The purpose of implementation is :
 To define the organization of the code, in terms of implementation subsystems
organized in layers.
 To implement classes and objects in terms of components (source files, binaries,
executables, and others).
 To test the developed components as units.
 To integrate the results produced by individual implementers (or teams), into an
executable system.
5. Test workflow - The purposes of testing are :

 To verify the interaction between objects.

 To verify the proper integration of all components of the software.
 To verify that all requirements have been correctly implemented.
 To identify and ensure defects are addressed prior to the deployment of the software.
6. Deployment workflow : The purpose of the deployment workflow is to successfully
produce product releases, and deliver the software to its end users.
 Software Engineering (MU) 1-50 Introduction

And three core “supporting” workflows :

1. Project Management workflow.
2. Configuration and Change Management workflow.
3. Environment workflow : The purpose of the environment workflow is to provide the
software development organization with the software development environment both
processes and tools that are needed to support the development team.
Table 1.6 : Activity level of sub-processes in different phases of RUP

Inception Elaboration Construction Transition

Requirements High High Low Nil
Anal. and Low High Medium Nil
design
Implementation Nil Low High Low
Test Nil Low High Medium
Deployment Nil Nil Medium High
Proj. Mgmt Medium Medium Medium Medium
Config. Mgmt Low Low High High

Advantages of RUP

 It lets you take into account changing requirements which despite the best efforts of all
project managers are still a reality on just about every project.
 Integration is not one “big bang” at the end; instead, elements are integrated
progressively.
 Risks are usually discovered or addressed during integration. With the iterative
approach, you can mitigate risks earlier.
 Iterative development provides management with a means of making tactical changes to
the product. It allows you to release a product early with reduced functionality to counter
a move by a competitor, or to adopt another vendor for a given technology.
 Iteration facilitates reuse; it is easier to identify common parts as they are partially
designed or implemented than to recognize them during planning.
 When you can correct errors over several iterations, the result is a more robust
architecture. Performance bottlenecks are discovered at a time when they can still be
addressed, instead of creating panic on the eve of delivery.
 Software Engineering (MU) 1-51 Introduction

 Developers can learn along the way, and their various abilities and specialties are more
fully employed during the entire lifecycle. Testers start testing early, technical writers
begin writing early, and so on.
 The development process itself can be improved and refined along the way. The
assessment at the end of an iteration not only looks at the status of the project from a
product or schedule perspective, but also analyzes what should be changed in the
organization and in the process to make it perform better in the next iteration.

1.9.10 Time Boxing Model

 This model ensures that deliveries are made with a much greater frequency than once
every time box, thereby substantially reducing the cycle time for each delivery.
 How execution of a project proceeds when using the waterfall, iterative, or the
timeboxing process model proceeds is shown in Fig. 1.25.

Fig. 1.25 : Waterfall, Iterative, Timeboxing Models

The Timeboxing Model

1. A Time box and Stages

 In the timeboxing process model, the basic unit of development is a time box, which
is of fixed duration. Within this time box all activities that need to be performed to
successfully release the next version are executed. Since the duration is fixed, a key
factor in selecting the requirements or features to be built in a time box is what can
be “fit” into the time box.
 Software Engineering (MU) 1-52 Introduction

 Each time box is divided into a sequence of stages, like in the waterfall model. Each
stage performs some clearly defined task of the iteration and produces a clearly
defined output. The output from one stage is the only input from this stage to the
next stage. Furthermore, the model requires that the duration of each stage, that is,
the time it takes to complete the task of that stage, is approximately the same.
 There is a dedicated team for each stage. That is, the team for a stage performs only
tasks of that stage – tasks for other stages are performed by their respective teams.
This is quite different from many other models where the implicit assumption is that
the same team (by and large) performs all the different tasks of the project or the
iteration.
 As pipelining is to be employed, the stages must be carefully chosen. Each stage
performs some logical activity which may be communication intensive – that is, the
team performing the task of that stage needs to communicate and meet regularly.
However, the stage should be such that its output is all that is needed from this stage
by the team performing the task of the next stage. In other words, the output should
be such that it can be passed to the team for next stage, and the team needs to
communicate minimally with the previous stage team for performing their task. Note
that it does not mean that the team for a stage cannot seek clarifications with teams
of earlier stages – all it means is that the communication needs between teams of
different stages are so low that their communication has no significant effect on the
work of any of the teams.
2. Pipelined Execution

 In general, let us consider a time box with duration T and consisting of n stages – S1,
S2, …, Sn.
 Let the size of the team dedicated for stage Si be Ri, representing the number of
resources assigned to this stage.
 The team of each stage has T/n time available to finish their task for a time box, that
is, the duration of each stage is T/n.
 When the team of a stage i completes the tasks for that stage for a time box k, it then
passes the output of the time box to the team executing the stage i +1, and then starts
executing its stage for the next time box k +1.
 Using the output given by the team for Si, the team for Si+1 starts its activity for this
time box.
 Software Engineering (MU) 1-53 Introduction

 By the time the first time box is nearing completion, there are n-1 different time
boxes in different stages of execution. And though the first output comes after time
T, each subsequent delivery happens after T/n time interval, delivering software that
has been developed in time T.
 Example, consider a time box consisting of three stages: requirement specification,
build, and deployment. When the requirement team has finished requirements for
timebox-1, the requirements are given to the build-team for building the software.
Meanwhile, the requirement team goes on and starts preparing the requirements for
timebox-2. When the build for the timebox-1 is completed, the code is handed over to
the deployment team, and the build team moves on to build code for requirements
for timebox-2, and the requirements team moves on to doing requirements for
timebox-3. This pipelined execution of the timeboxing process is shown in Fig. 1.26.
 With a three-stage time box, at most three iterations can be concurrently in progress.
If the time box is of size T days, then the first software delivery will occur after T
days. The subsequent deliveries, however, will take place after every T/3 days.

Fig. 1.26 : Executing the timeboxing process model

3. Time, Effort and Team Size

Speedup - The reduction in the average completing time of iteration.

Throughput - The amount of output per unit time.
 In steady state, the throughput of a project using timeboxing is n times that of if serial
iterations were employed. In other words, n times more functionality is being
delivered per unit time.
 Software Engineering (MU) 1-54 Introduction

 If the size of the team executing the stage Si is Ri , then the effort spent in the stage
Si is E (Si) = Ri * T/n.
Note : The model only requires that the duration of the stages be approximately the same, which is
T/n in this case. It does not imply that the amount of effort spent in a stage is same. The effort
consumed in a stage Si also depends on Ri, the size of the team for that stage. And there is no
constraint from the model that the different Ri’s should be the same.

 The total effort consumed in iteration, i.e. in a time box, is

x
E(TB) =  E (Si )
i=1
 The total effort for iteration remains the same in timeboxing as in serial execution of
iterations.
 The total team size for the project, in which multiple time boxes may be running in
parallel, is
x
Project Team Size =  Ri
i=1
 The team size in timeboxing is n times the size of the team in serial execution of
iterations.
 Within a time box – we cannot reduce the size of a time box by more manpower.
However, through the timeboxing model, we have been able to use more manpower
in a manner such that by parallel execution of different stages we are able to deliver
software quicker
4. Unequal Stages and Exceptions

1) The stages are of unequal duration.

 In such a situation the output is determined by the slowest stage, that is, the
stage that takes the longest time. With unequal stages, each stage
effectively becomes equal to the longest stage and therefore the frequency
of output is once every time period of the slowest stage.
 Note that even with this, a considerable speedup is possible. For example,
let us consider a 3-stage pipeline of the type discussed above in which the
different stages are 2 weeks, 4 weeks, and 3 weeks – that is, the duration of
the time box is 9 weeks. In a serial iterative development, software will be
 Software Engineering (MU) 1-55 Introduction

delivered every 9 weeks. With timeboxing, the slowest stage will determine
the speed of execution, and hence the deliveries will be done every
4 weeks. This delivery time is less than half the delivery time of serial
iterations.
 Impact : It will result in “slack time” for the teams for the first and third
stage, resulting in under utilization of resources. So, the resource
utilization, which is 100% when all the stages are of equal duration, will
reduce resulting in underutilization of resources.
 Solution for this Problem : This wastage can easily be reduced by reducing
the size of the teams for the slower stages to a level that they take the same
time as the slowest stage. Note that elongating the cycle time by reducing
manpower is generally possible (even though the reverse is not possible.)
2) An exceptional condition arises during the execution of a stage of sometime
box, due to which the stage is not able to finish in its allotted time.

 The net effect of the exception is that it elongates that stage by ΔT.
 Clearly, if such an exception occurs, the execution of the later stages will
be delayed resulting in the output being delivered late by ΔT. Similarly, due
to this delay, the output of earlier stages in later time boxes cannot be
consumed in time, resulting in the teams of these stages “waiting” for their
output to be consumed.
 The net result of this is that, one delivery gets delayed by ΔT, with a
corresponding slack time for each team for one time box. After that, all
future deliveries will come after every T/n time units (for a n-stage time
box of T duration.)
5. Scope of Applicability

 Timeboxing is well suited for projects that require a large number of features to be
developed in a short time around a stable architecture using stable technologies.
 Another example of projects that satisfy this are many web-site development
projects – generally some architecture is fixed early, and then the set of features to
be added iteratively is decided depending on what the competition is providing and
the perceived needs of the customer (which change with time).
 Software Engineering (MU) 1-56 Introduction

 The team size and composition is another critical parameter for a project using
timeboxing. Clearly the overall project team should be large enough that it can be
divided into sub-teams that are dedicated for performing the tasks of the different
stages. However, to keep the management complexity under control, it is desirable
that the team be not so large that coordination between different sub-teams and
different time boxes become too hard to manage.
 The model is not suitable for projects :
o Where it is difficult to partition the overall development into multiple
iterations of approximately equal duration.
o Where different iterations may require different stages,
o Whose features are such that there is no flexibility to combine them into
meaningful deliveries. Such a situation may arise, for example, if only a
few features are to be built, one (or a couple) in each iteration, each tied to
some business need. In this case, as there is only one feature to be built in
iteration, that feature will determine the duration of the iteration.
6. Handling Changes

 The change request comes as a new requirement in a future time box. Since the time
boxes are likely to be relatively short, deferring the requirement change request to
the next time box does not cause inordinate delay.
 The same can be done for the defects that are found after deployment. Such defects
are viewed as change requests. If the defect is such that it is hurting the business of
the organization and whose repair cannot be delayed, then it is fixed as soon as
possible. Otherwise, its fixing is treated like a change request and is fixed in the next
possible iteration.

1.9.11 Comparison of Models (Waterfall, Prototyping, Iterative)

Each process model is suitable for some context, and the main reason for studying
different models is to develop the ability to choose the proper model for a given project.
Using a model as the basis, the actual process for the project can be decided, which
hopefully is the optimal process for the project. To help select a model, we summarize the
strengths and weaknesses of the different models, along with the types of projects for which
they are suitable, in Table 1.6.
 Software Engineering (MU) 1-57 Introduction

Table 1.7 : Comparison of process models

Strengths Weaknesses Types of projects

Waterfall
 Simple.  All or nothing approach.  For well understood
 Easy to execute.  Requirements frozen problems, short duration
early. project, automation of
 Intuitive and logical. existing manual systems.
 Disallows changes.
 Cycle time too long.
 May choose outdated
hardware technology.
 User feedback not
allowed.
 Encourages requirements
bloating.
Prototyping
 Helps in  Front heavy process.  Systems with novice users,
requirements.  Possibly higher cost.  When uncertainties in
elicitation. requirements
 Disallows later changes.
 Reduces risk.  When UI very important.
 Leads to a better
system.
Interactive
 Regular/quick  Each iteration can have  For businesses where time is
deliveries. planning overhead. of essence.
 Reduces risk.  Cost may increase as  Where risk of a long project
 Accommodates work done in one iteration cannot be taken.
changes. may have to be undone  Where requirements are not
 Allows user later. known and will be known
feedback.  System architecture and only with
 Allows reasonable structure may suffer as
exit points. frequent changes are
 Avoids requirements made.
bloating.
 Prioritizes
requirements.
 Software Engineering (MU) 1-58 Introduction

1.10 Methodology and Tools

.MU - May 06.
We need to distinguish between a methodology and a process. A process covers all the
activities beginning from product inception though delivery and retirement. Additionally, it
addresses the broader issue of reuse, documentation, testing, parallel work carried out by
team members and coordination with the customer and so forth. In contrast, a methodology
covers only a single activity or at best a few individual steps in the development. For e.g.,
both testing methodology and design methodology address only a single activity in their
respective areas in a lifecycle. Thus a process scales up a methodology to the entire life
cycle.
 Methodology defined : The way something gets done. The strategy, steps, directions,
or actions.
 Methodologies can be :
o purchased
o created
o combination of both
 Classifications of Methodologies :
o Traditional
o Structured Analysis and Design
o Information Modeling/Engineering
o Object-Oriented
 Prototyping is a technique : (some say that it is a methodology)

What is a methodology ?

 Integrates tools and techniques.

 Usually an underlying philosophy.
 Justified by experience.
 A methodology may or may not prescribe a Life Cycle Model.

Methodology is not a life cycle method

 A LCM specifies and orders the development activities.

 A methodology offers the tools.
 Although most methodologies specify a LCM, some don’t.
 Software Engineering (MU) 1-59 Introduction

Why use a methodology ?

 Distilled experience/best practice.

 Ensures user involvement.
 Helps inexperienced analysts.
 Provides planning and control.

1. The Traditional Methodology (1950s - now)

 Applicable for small teams on small projects.

 Functional perspective of problem domain.
 Informal, unstructured, unrepeatable, unmeasurable, ad-hoc way.
 Tools used to support it are okay.
Traditional methodology tools

TECHNIQUES and TOOLS REPRESENTING

System flow Data Communication Process Logic

With users
System Flowcharts Forms, Layouts, Interviews English Narrative,
Grid Charts Play script, Program
Flowcharts, HIPO Charts

2. Structured Analysis and Design Methodology (mid-1970s - now)

 Data Flow methodology (synonym).

 Compliments Structured Programming.

 Very popular - perhaps the leading one.

 Can be repeatable, measurable, and automated.
 CASE brought significant assistance : 1) Yourdon, and 2) Gane and Sarson.

 Functional perspective of problem domain.

 Describes the real world as data flowing through the information system, being
transformed from inputs to outputs.
 Software Engineering (MU) 1-60 Introduction

Structured Analysis and Design Methodology Tools

Techniques and Tools Representing

System flow Data Communication Process Logic

With users
Data Flow Data Dictionary, Interviews, User Reviews, Decision Tree/Table,
Diagram Data Structure JAD sessions Structured English,
Diagrams, Structure Charts,
Entity-Relationship Warnier/Orr Diagram
Diagrams

3. Information Modeling Methodology (early-1980s - now)

 Data modeling and information engineering (synonyms).
 Describes the real world by its data, the data’s attributes, and the data relationships.
 Can be repeatable, measurable, and automated.
 Data perspective of the problem domain.
Information Modeling Methodology Tools
Techniques and Tools Representing

System flow Data Communication Process Logic

With users
Business Area Analysis, Business Area Interviews, Business Systems
Process Analysis, User Reviews, Design
Model Entity-Relationship JAD Sessions,
Diagrams Brainstorming

4. Object-Oriented Methodology (mid/late-1980s - now)

 Object modelling.
 Compliments object-oriented programming.
 Can be repeatable, measurable, and automated.
 Object perspective of the problem domain.
 Describes the real world by its objects, the attributes, services, and relationships.
 Data and functions are encapsulated together.
 Software Engineering (MU) 1-61 Introduction

Object-Oriented Methodology Tools

Techniques and Tools Representing

System flow Data Communication Process Logic

With users
Object Model Object Model Attributes Interviews, User Object Models
Reviews, JAD Services, Scenarios,
Sessions,
Decision Tree/Tables,
Brainstorming
Structured English

Object technology principles

 Abstraction
 Encapsulation (Information Hiding)
 Inheritance
 Message Communication
 Associations
 Polymorphism
 Common Methods of Organization
 Reuse

1.11 Selection Criteria for Software Process Models

 Project type and associated risks : One of the key features of selecting a process
model is to understand the project in terms of size, complexity, funds available, and so
on. In addition, the risks which are associated with the project should also be considered.
Note that only a few process models emphasize risk assessment.
 Requirements of the project : The most essential feature of any process model is to
understand the requirement of the project. In case the requirements are not clearly
defined by the user or poorly understood by the developer, the developed software leads
to ineffective systems. Thus, the requirements of the software should be clearly
understood before selecting any process models.
 Users : Software is developed for the user. Hence, the users should be consulted while
selecting the process model. The comprehensibility of the project increases if users are
Software Engineering (MU) 1-62 Introduction

involved in selecting the process model. It is possible that a user is aware of the
requirements or has a rough idea of the requirements. It is also possible that a user wants
the project to be developed in a sequential manner or an incremental manner (where a
part is delivered to the user for use).
Table 1.8 : Selections on the basis of project type and associated risks

Project type and associated risks Waterfall Prototype Spiral

Reliability requirements No No Yes

Stable funds Yes Yes No

Reuse components No Yes Yes

Tight project schedule No Yes Yes

Scarcity of resources No Yes Yes

Table 1.9 : Selections on the basis of requirements of the project

Requirements of the Waterfall Prototype Spiral

project

Requirements are defined Yes No No

early in SDLC

Requirements are easily Yes No No

defined and understandable

Requirements are changed No Yes Yes

frequently

Requirements indicate No Yes Yes

complex system
Table 1.10 : Selections on the basis of the user

User Involvement Waterfall Prototype Spiral

Requires limited user involvement Yes No Yes
User participation in all phases No Yes No
No experience of participating in similar projects No Yes Yes
 Software Engineering (MU) 1-63 Introduction

1.12 Project Management Process

Development process decides

 The phases and

 Tasks to be done.

Development process does not specify

 How long each phase should last ?

 How many resources should be assigned to a phase ?
 How a phase should be monitored ?

Project management process activities

1) Project Planning,

2) Project Monitoring and Control Phase,

3) Project Termination Analysis

Fig. 1.27 : Project Management Process

 Software Engineering (MU) 1-64 Introduction

1) Project Planning :

 A software plan is usually produced before the development activity begins and is
updated as development proceeds and data about progress of the project becomes
available.
 The major activities are :
o Cost estimation,
o Schedule and milestone determination,
o Project staffing,
o Quality control plans, and
o Controlling and monitoring plans.

2) Project Monitoring and Control Phase :

 As cost, schedule, and quality are the major driving forces, most of the activity of
this phase revolves around monitoring factors that affect these.
 Monitoring potential risks for the project
 Based on the monitoring information if objectives are not met, necessary control
actions are taken on the development activities.
 The development process provides the information to the management process.
However, interpretation of the information is part of monitoring and control.

3) Project Termination Analysis :

 It is performed when the development process is over.

 A project is an instantiation of the process. To understand the properties of the
process, data from many projects that used the process will be needed.
 Using the predictability property of the process, this data about the process can be
used to make predictions and estimations about future projects.
 The data about the project is also needed to analyze the process to have continuous
process improvement.
 Software Engineering (MU) 1-65 Introduction

Fig. 1.28 : Temporal relationship between development and management process

As the Fig. 1.28 shows, during the development, from the various phases of the
development process, quantitative information flows to the monitoring and control phase of
the management process, which uses the information to exert control on the development
process.
A brief description of each step of Project Management Process follows :

1. Assemble Team

The project planning team will be assembled, including appropriate representation

from customers/clients, and sometimes subcontractors and vendors. Initial roles and
responsibilities will be defined.
Deliverables : Initial project setup documentation.
2. Define Project Objective

With the project team in place, the overall project purpose will be verified and detailed
project objectives developed. A phase-exit review will be conducted to ensure that the
project is ready to move into the next phase, which is planning.
Deliverables : project charter, phase-exit review checklist.
3. Define Project Scope

An appropriately detailed Work Breakdown Structure (WBS) will be developed to

ensure the project scope is properly agreed to and understood by all stakeholders. This
also allows the complete project to be split into appropriate sub-projects and/or
phases.
Deliverables : Project work breakdown structure.
 Software Engineering (MU) 1-66 Introduction

4. Construct an Initial Plan

Once tasks of an appropriate level have been identified in the WBS, they will be
organised by the project team into logical network diagrams, with estimated durations.
This allows the project manager to predict when activities will be complete, assess the
feasibility of target dates, and identify the critical path for the project.
Deliverables : Initial work plan.
5. Add Resources, Costs, Risks, etc.

Certain project resources may be defined as critical resources. In particular, the project
manager may suspect that key project staff may be faced with too much work. If so,
estimated resource usage information can be added to the project plan to allow
resource forecasting. Cost is obviously also critically important, and expenditures can
be added to the plan to create estimated cash-flow requirements. Risk management can
also be utilised on projects to provide a framework to better manage events that occur
beyond the control of the project team.
Deliverables : Resource availability and commitment profiles, risk identification and
control strategies, cash-flow forecasts.
6. Obtain Stakeholder Buy-in

To ensure the project is implemented as smoothly as possible, with the support of the
involved parties, it will be necessary to review the initial plans with all the major
project stakeholders and to solicit buy-in from each one. A phase-exit review will be
conducted to ensure that the project is ready to move into the next phase, which is
control.
Deliverables : Approved final plan, phase-exit review checklist.
7. Publish the Plan

Once the plans are agreed to, they must be effectively communicated to all
stakeholders. This can be done in hard copy or via electronic media, depending on the
resources available. On most projects, a communications plan will be developed, and
distribution of the plans will follow the guidelines laid out in the communications
plan.
Deliverables : Plan published to all stakeholders.
 Software Engineering (MU) 1-67 Introduction

8. Collect Progress Information

On a regular basis, the project manager will collect progress information that has been
reported by the project team. This will allow the compilation of progress reports, such
as :
 Activities completed within the past two weeks.
 Activities forecast for the next two weeks with a focus on activities on the critical
path.
 Funds expended vs. fund expenditure forecast.
 Prioritised issues report.
Metrics can also be developed to measure project progress in other ways, such as
earned value, or activity float statistics. If the project manager reviews the progress
data and concludes that the project is complete, a phase-exit review will be completed
to confirm that all the objectives have been met before moving into the final closure
phase.
Deliverables : Set of progress reports, set of exception reports, metrics report, (phase-
exit review checklist).
9. Analyse Current Status

By analysing the progress information received, the project manager will be able to
augment the above reports with information about which areas of the project are of
concern and where problems are likely to occur in the future. This allows managers to
focus on the important/critical areas of the project.
Deliverables : Project evaluation report(s).
10. Adjust the Plan, and Manage Project Change

Based on the analysis, and with the support of the project team, the project manager
will make plan adjustments to help reduce risks, accommodate scope changes, or to
compensate for activities that have not occurred on schedule. Once this has happened,
the plan will re-publish and the cycle repeated until the project is complete.
Deliverables : Change request forms, updated plan.
 Software Engineering (MU) 1-68 Introduction

11. Close Project

When the objectives of the project have been achieved, the project manager will close
down the project. This will involve some financial closure tasks, as well as archiving
of the project materials. A lessons-learned document will be developed to benefit
future projects, and if possible a project team celebration will be held.
Deliverables : Final project report including lessons learned.

1.13 Agile Methodology

1.13.1 Introduction

Agile development methodologies have been designed to address the problem of

delivering high quality software on time under constantly and rapidly changing requirements
and business environment. Agile development processes are characterized by extensive
coding practice, intensive communication between key stakeholders, small and flexible
teams and fast iterative cycles.

1.13.2 Where to use Agile Development ?

Agile development methods are used in the following circumstances :

 There is no ‘Requirement Freezing’. Change in requirements is acted upon.
 Incremental and iterative approach is used for modeling.
 Clients are actively take part in modeling.
 Prioritization of tasks is being done by key stakeholders and the team works on the
highest priority requirement.
 Every one in the team is an active participant and everyone’s input is welcome.
 The content of the model is being recognized as being more significantly important than
the representation or format.

1.13.3 Where not to use Agile Development ?

Agile methods are not used under the following circumstances :

 Customers have limited involvement in the development efforts.
 Your have to prepare documents at each stage which would be signed off by key
stakeholders.
 Software Engineering (MU) 1-69 Introduction

 You hand over documents at each stage the next team then takes care of your
developing the system further.
 Case tool is used to specify the design of the software but not for generating the
software.

1.13.4 Advantages of Agile Development

 Shortened development cycles

 Higher stability of deliverables
 Improved utilization of resources
 Better quality of deliverables due to the involvement of the customer

1.13.5 Limitations of Agile Development

 Agile development approach works well for small to medium sized teams
 Agile development methods do not scale. Due to the number of iterations involved it
would be difficult to understand the current project status.
 This approach requires highly motivated and skilled individuals which would not always
be existent.

1.13.6 Various Agile Development Processes

Table 1.11 : Various Agile Development Process

Approach Characteristics Features

Scrum Small teams, sprints 7-30 days Daily scrums.
cycles.
Extreme programming Customer driven, frequent Constant testing.
release, pair programming.
Dynamic systems Controlled rapid application Use of prototyping, several
development method development. small teams (2-6 people).
Feature driven Five basic process steps, feature- Scalable, combining features
development centric, short iterations. and object modelling.
Adaptive software Adaptive organization culture, Component based.
development collaborative teamwork.
 Software Engineering (MU) 1-70 Introduction

1.13.7 Generic Agile Life cycle

Fig. 1.29 : Generic Agile Life Cycle

 All software development methods, including the Agile ones, have some sort of
underlying project life cycle.
 Some of the Agile methods don’t make a big deal of it, and others do. Some have such
abstract life cycles that it is actually hard to know what activities to schedule.
 The key elements are a Project Initiation and Project Plan followed by one or more
Releases made up on one or more timeboxes (although usually 3).
 There are also more or less optional phases to Elaborate Requirements and for the
Architecture - often done in parallel with the Project Plan.
 Perhaps not so strangely, this life cycle looks pretty conventional.
a) Project initiation

Set up and justify the project. Determine initial high level requirements.
b) Project plan

 Plan out the project, everything after Project Initiation, including whether you’re
going to have the optional phases.
 If you’re using the optional phase to Elaborate the Requirements you’re likely to
have a draft plan after the Project Initiation and then a more complete plan after the
Requirements are complete.
 Software Engineering (MU) 1-71 Introduction

 DSDM makes this explicit and mandatory with its “Outline Plan” (created in Project
Initiation) and “Development Plan” (created after the Requirements have been
fleshed out).
 XP has something similar in the “Big Plan” done to justify a project, which evolves
into a Release plan.
c) Elaborate requirements (optional)

 Very high level requirements are gathered during Project Initiation. These can
optionally be expanded during an phase to Elaborate Requirements. Even is the
requirements are “elaborated” they are still high level.
 There is no separate Elaboration phase in XP and Scrum, although the Customer is
expected to elaborate as much as necessary at the start of an XP Iteration (Timebox).
 Crystal Orange and DSDM have a separate Elaboration phase. Facilitated
workshop(s) to identify “High level requirements” which are then collated into a
document (Requirements Document / Business Area Definition (BAD)) that contains
use Cases and non-functional requirements.
d) Architecture (optional)

 The Agile approach is generally design for today and refactor tomorrow (at least in
XP). An Architecture Phase is optional in XP and Crystal Orange.
 However, In DSDM An architecture phase is compulsory and results in a “System
Architecture Document”. The SAD is created in parallel to the BAD, i.e.
requirements elaboration and architecture occur at the same time.
e) Release

 A Release is a piece of development where the customer gets some new software.
Releases can be from 2 weeks to 6 months, but are usually 3 months long.
 Release have one or more timeboxes. Unlike other methods, in DSDM one Release
is the norm, i.e. there is only one release to the customer in the entire project.
f) Time box
 A Timebox is 1 – 6 weeks long, but usually 3 – 4 weeks. The most important thing
about a timebox is that the delivery date is fixed.
 Software Engineering (MU) 1-72 Introduction

1.13.8 Different Agile Methodologies

Table 1.12 : Distinguishing factors of different Agile methodologies

Agile Distinguishing Factors

Methodology

1. XP  Intended for 10-12 co-located, object-oriented programmers

 Four values
 12 highly-specified, disciplined development practices
 Minimal archival documentation
 Rapid customer and developer feedback loops

2. Crystal  Customizable family of development methodologies for small to

very large teams
 Methodology dependent on size of team and criticality of project
 Emphasis of face-to-face communication
 Consider people, interaction, community, skills, talents, and
communication as first-order effects
 Start with minimal process and build up as absolutely necessary

3. Scrum  Project management wrapper around methodology in which

developer practices are defined
 30-day sprints in which priorities are not changed
 Daily Scrum meeting of Scrum team
 Burn down chart to display progress

4. FDD  Scalable to larger teams

 Highly-specified development practices
 Five sub-processes, each defined with entry and exit criteria
 Development are architectural shape, object models and sequence
diagrams (UML models used throughout)
 Two-week features
 Software Engineering (MU) 1-73 Introduction

1.13.9 Roles and Responsibilities

Table1.13 : Team composition and roles in the agile methods
Small cross-functional teams
Team Composition and Roles in the Agile Methods

Concept XP Scrum Crystal Orange DSDM

Variable; up to 40
Number 1 team per
1 – 4 or more people so probably 1–6
of teams project
1 – 10 or so.
Team size 3 – 16 5–9 4–8 2–6
Scrum master, Business Analyst- Team Leader,
Customer,
Team Experienced Designer, Ambassador User,
Programmer,
Members / Engineer, Junior Designer- [Advisor User],
Tester, Tracker,
Roles Engineer, [QA Programmer, UI Senior Developer,
Coach
Tester], [Writer] Designer, [Tester ] Developer, Scribe
Sponsor, Project Visionary,
Manager, Executive Sponsor,
Project Manager/
Project Architect, Project Manager,
Big Boss Scrum master,
Roles Technical Technical
Product Owner
Facilitator, Design Co-ordinator,
Mentor Facilitator

1.14 Process and Project Metrics

.MU - May 08, May 09, June 10.

1.14.1 Why do we Measure Software Processes, Products and Resources ?

 To characterize
 To evaluate
 To predict
 To improve
Characterize to gain understanding of processes, products, resources, and
environments, and to establish baselines for comparisons with future assessments.
Evaluate to determine status with respect to plans. Measures are the sensors that let us
know when our projects and processes are drifting off track, so that we can bring them back
 Software Engineering (MU) 1-74 Introduction

under control. We also evaluate to assess achievement of quality goals and to assess the
impacts of technology and process improvements on products and processes.
Predict so that we can plan. Measuring for prediction involves gaining understandings
of relationships among processes and products and building models of these relationships, so
that the values we observe for some attributes can be used to predict others. We do this
because we want to establish achievable goals for cost, schedule, and quality - so that
appropriate resources can be applied. Predictive measures are also the basis for extrapolating
trends, so estimates for cost, time, and quality can be updated based on current evidence.
Projections and estimates based on historical data also help us analyze risks and make
design/cost trade-offs.
Measure to improve when we gather quantitative information to help us identify
roadblocks, root causes, inefficiencies, and other opportunities for improving product quality
and process performance.
 The IEEE Standard Glossary of Software Engineering Terms [IEE93] defines metric as
“a quantitative measure of the degree to which a system, component, or process
possesses a given attribute.”

A measure provides a quantitative indication of the extent, amount, dimensions,

capacity, or size of some attribute of a product or process (e.g., the number of errors
uncovered in the review of a single module would be a measurement of a single data point;
multiple data points might be collected)
Software metric relates the individual measures in some way (e.g., the average
number of errors found per review or the average number of errors found per person-hour
expended in reviews)
An indicator is a metric or combination of metrics that provide insight into the
software process, a software project, or the product itself. An indicator provides insight that
enables the project manager or software engineer to adjust the process, the project, or the
product, to make things better.
Product metrics are used to quantify characteristics of the product being developed,
i.e., the software. Process metrics are used to quantify characteristics of the process being
used to develop the software. Process metrics aim to measure such considerations as
productivity, cost and resource requirements, effectiveness of quality assurance measures,
and the effect of development techniques and tools.
 Software Engineering (MU) 1-75 Introduction

1.14.2 Process Metrics

How do I measure the effectiveness of a software process ?

 We measure the efficacy of a software process indirectly. That is, we derive a set of
metrics based on the outcomes that can be derived from the process.
 Outcomes include measures of errors uncovered before release of the software, defects
delivered to and reported by end-users, work products delivered (productivity), human
effort expended, calendar time expended, schedule conformance, and other measures.
 We also derive process metrics by measuring the characteristics of specific software
engineering tasks.

Private process metrics

 Examples include defects reported for major software functions (that have been
developed by a number of practitioners), errors found during formal technical reviews,
and lines of code or function points per module and function.
 These data are reviewed by the team to uncover indicators that can improve team
performance.

Public metrics

 Public metrics generally assimilate information that originally was private to individuals
and teams.
 Project level defect rates (absolutely not attributed to an individual), effort, calendar
times, and related data are collected and evaluated in an attempt to uncover indicators
that can improve organizational process performance.

1.14.3 Project Metrics

 The first application of project metrics on most software projects occurs during
estimation.
 Metrics collected from past projects are used as a basis from which effort and time
estimates are made for current software work.
 As a project proceeds, measures of effort and calendar time expended are compared to
original estimates (and the project schedule).
 The project manager uses these data to monitor and control progress.
 Software Engineering (MU) 1-76 Introduction

 As technical work commences, other project metrics begin to have significance.

Production rates represented in terms of pages of documentation, review hours, function
points, and delivered source lines are measured. In addition, errors uncovered during
each software engineering task are tracked.
 As the software evolves from specification into design, technical metrics are collected to
assess design quality and to provide indicators that will influence the approach taken to
code generation and testing.

How should we use metrics during the project itself ?

1. These metrics are used to minimize the development schedule by making the
adjustments necessary to avoid delays and mitigate potential problems and risks.
2. Project metrics are used to assess product quality on an ongoing basis and, when
necessary, modify the technical approach to improve quality.
As quality improves, defects are minimized, and as the defect count goes down, the
amount of rework required during the project is also reduced. This leads to a reduction in
overall project cost.

Project metrics

 Effort/time per SE task

 Errors uncovered per review hour
 Scheduled vs. actual milestone dates
 Changes (number) and their characteristics
 Distribution of effort on SE tasks

1.14.4 What is the Difference between Direct and Indirect Measures ?

 Direct measures of the software engineering process include cost and effort applied.
 Direct measures of the product include lines of code (LOC) produced, execution speed,
memory size, and defects reported over some set period of time. Indirect measures of
the product include functionality, quality, complexity, efficiency, reliability,
maintainability, and many other “– abilities”.
 Software Engineering (MU) 1-77 Introduction

 The cost and effort required to build software, the number of lines of code produced, and
other direct measures are relatively easy to collect, as long as specific conventions for
measurement are established in advance.
 However, the quality and functionality of software or its efficiency or maintainability are
more difficult to assess and can be measured only indirectly.

Indirect measures

 Functionality
 Quality

 Complexity
 Efficiency
 Reliability
 Maintainability

Direct measures

 Lines of code (LOC) produced

 Execution speed
 Memory size
 Defects reported over some set period of time

1.14.5 Two Types of Metrics

1. Size oriented metrics

Size-oriented software metrics are derived by normalizing quality and/or productivity
measures by considering the size of the software that has been produced.
In order to develop metrics that can be assimilated with similar metrics from other
projects, we choose lines of code as our normalization value. From the rudimentary data
contained in the table, a set of simple size-oriented metrics can be developed for each
project :
 Errors per KLOC (thousand lines of code).
 Defects per KLOC.
 Software Engineering (MU) 1-78 Introduction

 $ per LOC.
 Page of documentation per KLOC.
In addition, other interesting metrics can be computed :
 Errors per person-month.
 LOC per person-month.
 $ Per page of documentation.
Size-oriented metrics are not universally accepted as the best way to measure the
process of software development.

2. Function oriented matrices

Function-oriented software metrics use a measure of the functionality delivered by the

application as a normalization value. Since ‘functionality’ cannot be measured directly, it
must be derived indirectly using other direct measures.
Once function points have been calculated, they are used in a manner analogous to
LOC as a way to normalize measures for software productivity, quality, and other attributes :
 Errors per FP.
 Defects per FP.
 $ Per FP.
 Pages of documentation per FP.
 FP per person-month

1.15 Software Estimation

.MU - June 05, Nov. 05, May 08, June 10.

Estimation the Problems

 Lack of historical data

 Estimates done hurriedly
 Complete specifications not available
 Characteristics of software development
 Rapid changes in methodologies
 Lack of experience (how many projects do you actually manage?)
 Optimism of developers
 Software Engineering (MU) 1-79 Introduction

 Difference in experience levels (who are you estimating for?)

 No linear relation in development (if 1 developer takes 1 year, 2 developers must only
take 6 mo)
 Estimate modification for low bid.
The primary reason for cost and schedule estimation is

 Cost-benefit analysis, and

 Project monitoring and control.
A more practical use of these estimates is in bidding for software projects, where cost
estimates must be given to a potential client for the development contract.
Cost in project is due to

 Hardware and software costs including maintenance.

 Travel and training costs- needed when a project is developed at different sites, the
travel costs are usually a small fraction of the effort costs.
 Effort costs (the costs of paying software engineers).

Hardware Resources

 Computer time,
 Terminal time,
 Memory required for the project, etc.

Software Resources

 Software tools,
 Compilers needed during development.

Effort Cost (the costs of paying software engineers).

1. Costs of providing, heating and lighting office space.

2. Costs of support staff such as accountants, administrators, system managers, cleaners
and technicians.
3. Costs of networking and communications.
4. Costs of central facilities such as a library or recreational facilities.
5. Costs of Social Security and employee benefits such as pensions and health insurance.
 Software Engineering (MU) 1-80 Introduction

The bulk of the cost of software development is due to the human resources needed,
and therefore most cost estimation procedures focus on estimating effort in terms of person-
months (PM). By properly including the “overheads” (i.e., the cost of hardware, software,
office space, etc.) in the cost of a person-month, effort estimates can be converted into cost.
Estimates can be based on subjective opinion of some person or determined through
the use of models.
Boehm (1981) discusses seven techniques of software cost estimation :
(1) Algorithmic cost modeling
A model is developed using historical cost information which relates some software
metric (usually its size) to the project cost. An estimate is made of that metric and the
model predicts the effort required.
(2) Expert judgement
One or more experts on the software development techniques to be used and on the
application domain are consulted. They each estimate the project cost and the final
cost estimate is arrived at by consensus.
(3) Estimation by analogy
This technique is applicable when other projects in the same application domain have
been completed. The cost of a new project is estimated by analogy with these
completed projects.
(4) Parkinson’s Law
Parkinson’s Law states that work expands to fill the time available. In software
costing, this means that the cost is determined by available resources rather than by
objective assessment. If the software has to be delivered in 12 months and 5 people are
available, the effort required is estimated to be 60 person-months.
(5) Pricing to win
The software cost is estimated to be whatever the customer has available to spend on
the project. The estimated effort depends on the customer’s budget and not on the
software functionality.
(6) Top- down estimation
A cost estimate is established by considering the overall functionality of the product
and how that functionality is provided by interacting sub-functions. Cost estimates are
 Software Engineering (MU) 1-81 Introduction

made on the basis of the logical function rather than the components implementing
that function.
(7) Bottom- up estimation

The cost of each component is estimated. All these costs are added to produce a final
cost estimate.
 Each technique has advantages and disadvantages.
 For large projects, several cost estimation techniques should be used in parallel and their
results compared.
 If these predict radically different costs, more information should be sought and the
costing process repeated. The process should continue until the estimates converge.
 Cost models are based on the fact that a firm set of requirements has been drawn up and
costing is carried out using these requirements as a basis.
 However, sometimes the requirements may be changed so that a fixed cost is not
exceeded.

1.15.1 Building Effort Estimation Models

The primary factor that controls the effort is the size of the project, that is, the larger
the project, the greater the effort requirement.

Other factors that affect the cost include :

 Programmer ability,
 Experience of the developers in the area,
 Complexity of the project, and
 Reliability requirements.
The goal of cost model is to determine which of these many parameters have a
“significant” effect on the cost and then to discover the relationships between the cost and
these characteristics.
The most common approach for determining the significant parameters and their
relationship to cost is to build models through regression analysis, where cost is the
dependent variable and the parameters are the independent variables.
 Software Engineering (MU) 1-82 Introduction

The most common approach therefore for estimating effort is to make it a function of
a single variable of project size and the equation of effort is considered as
b
Effort = a*size
where a and b are constants, and project size is generally in KLOC or function points.
Values for these constants for a particular process are determined through regression
analysis, which is applied to data about the projects that has been performed in the past.

1.15.1.1 Top- Down approach

The approach of determining total effort from the total size is what we refer to as the
top-down approach, as overall effort is first determined and then from this the effort for
different parts are obtained.
In a top-down estimation model by using size as the main input to the model, we have
replaced the problem of effort estimation by size estimation.

Why not directly do effort estimation rather than size estimation ?

 Size estimation is often easier than direct effort estimation.

 For estimating size, the system is generally partitioned into components it is likely to
have.
 Once size estimates for components are available, to get the overall size estimate for the
system, the estimates of all the components can be added up.
 Similar property does not hold for effort estimation, as effort for developing a system is
not the sum of effort for developing the components (as additional effort is needed for
integration and other such activities when building a system from developed
components).
 This is the main reason that size estimation is considered easier than effort estimation.

1.15.1.2 A Bottom-Up Estimation Approach

 In this approach, the project is first divided into tasks and then estimates for the different
tasks of the project are first obtained.
 The overall estimate of the project is derived from the estimates of its parts.
 Software Engineering (MU) 1-83 Introduction

 The bottom-up approach lends itself to direct estimation of effort; once the project is
partitioned into smaller tasks, it is possible to directly estimate the effort required for
them, especially if tasks are relatively small.
The procedure for bottom-up estimation can be summarized as the following sequence
of steps :
1. The major programs (or units or modules) in the software being built are first
determined.
2. Each program unit is then classified as simple, medium, or complex based on certain
criteria.
3. For each classification unit, an average effort for coding (and unit testing) is decided.
4. This standard coding effort can be based on past data from a similar project, from
some guidelines, or some combination of these.
5. Once the number of units in the three categories of complexity is known and the
estimated coding effort for each program is selected, the total coding effort for the
project is known.
6. From the coding effort, the effort required for the other phases and activities is
determined as a percentage of coding effort.
7. From information about the past performance of the process, the likely distribution of
effort in different phases of this project is decided, and then used to determine the
effort for other phases and activities.
8. From these estimates, the total effort for the project is obtained.
Both the top-down and the bottom-up approaches require information about the
project :
 Size (for top-down approaches) or
 A list of tasks (for bottom-up approaches).
In many ways, these approaches are complementary, and often it may be desirable to
determine the effort using both the approaches and then using these estimates to obtain the
final estimate.
 Software Engineering (MU) 1-84 Introduction

1.15.2 LOC based Technique

.MU - Oct. 04, Nov. 06, Nov. 07, Dec. 08, Dec. 09.
Let us consider a software package to be developed for a computer-aided design
application for mechanical components. Using the System Specification as guide, a
preliminary statement of scope can be developed.

Salient features

 Simple yet useful.

 At the beginning of a project.
 Based on previous experience of the similar type of project.

Example : CAD software

Statement of software scope

The CAD software will accept 2D and 3D geometric data from an engineer through a
user interface that exhibits good HCI. All geometric data will be maintained in a database.
Design analysis modules will be developed to produce the required output, which will be
displayed on a variety of graphics devices. The software will interact with peripheral devices
including a mouse, digitizer, laser printer and plotter.
This statement of scope is preliminary it is not bounded. Every sentence would have to
be expanded to provide concrete detail and quantitative bounding. For example, before
estimation can begin the planner must determine what “characteristics of good
human/machine interface design” means or what the size and sophistication of the “CAD
database” are to be.
For our purpose, we assume that further refinement has occurred and that the
following major software functions are identified :

Functional decomposition

 User interface and control facilities (UICF)

 Two-dimensional geometric analysis (2DGA)
 Three-dimensional geometric analysis (3DGA)
 Database management (DBM)
 Computer graphics display facilities (CGDF)
 Software Engineering (MU) 1-85 Introduction

 Peripheral control function (PCF)

 Design analysis modules (DAM)
Step 1 : Three LOC estimates (optimistic Sopt, most likely Sm, and pessimistic Spess) are
developed for each function.

Functionality Sopt Sm Spess

UICF 4600 6900 8600
2DGA 4800 7300 9200
3DGA 5200 8400 9600
DBM 2400 4200 6200
CGDF 3200 5000 7400
PCF 5600 8200 9800
DAM 3200 4500 5600

Step 2 : Each final function estimate is :

E = (Eopt + 4 Em + Epess) / 6

Functionality S = (Sopt+4Sm+Spess)
UICF 5650
2DGA 7200
3DGA 8066
DBM 4233
CGDF 5100
PCF 8033
DAM 4466
Total LOC 42748

Step 3 : Use historical data for projects of this type (LOC/pm and R/LOC) to obtain effort
and cost estimates.

 From the historical data assume the following :

o A review of historical data indicates that the organizational average productivity
for system of the project type is 420 LOC/PM
 Software Engineering (MU) 1-86 Introduction

o Cost for a person-month, α = Rs. 20,000/

o Cost per line of code, β = Rs.50/
 We can estimate
Effort = LOC/ α = 101.7 Person-months “ 102 Person-months
Cost = LOC * β = Rs. 21, 37,400 “ Rs. 21 lakhs
Shortcomings in LOC calculation
 Cannot address coding style
For e.g., one programmer might write several source instructions on a single line
whereas another might split a single instructions across several lines of course, this
problem can be easily overcome by counting the languages tokens in the program
rather than the lines of code. However more intricate problem arises because the
length of the program depends on the choice of instructions used in writing the
program. Therefore, even for the same problem, different LOC counts. This situation
does not improve even if the language tokens are counted instead of the Lines of code.
 Coding activity only, not measure analysis, design, testing, documentation etc.
It merely computes the number of source lines in the final program. Coding is only a
small part of the overall software development activities. It is also wrong to argue that
the overall product development effort is proportional to the effort required to write
the program code. This is because even though the design might be very complex, the
code might be straightforward and vice versa. Thus the code size is a grossly improper
indicator of the problem size.

 Does not correlates with quality and efficiency

A larger code size does not necessarily imply better quality or higher efficiency. Some
programmer produce lengthy and complicated code as they do not make effective use
of the available instruction set.

 Does not proper for 4GL, Library based, or HLL

LOC metric penalizes use of higher-level programming languages, code reuse, etc.
The paradox is that if a programmer consciously uses several library routines, then the
LOC count will be lower. This would show up as a smaller program size. Thus, if the
managers use the LOC count as a measure of the effort put in by different engineers!
 Software Engineering (MU) 1-87 Introduction

 Does not address structural, logical complexities (only lexical)

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, compare the efforts required to develop a program having multiple
nested loop and decision constructs with that of another program having only
sequential control flow.

 Difficult to accurately estimate LOC in final product from problem specification

The LOC count can be accurately computed only after the code has been fully
developed. Therefore, the LOC metric is of little use to the project managers during
project planning, since project planning is carried out much before any development
activity is started. This possibly is the biggest shortcoming of the LOC metric from the
project manager’s perspective.

1.15.3 FP based Estimation .MU - Oct. 04, June 05, Nov. 06, Nov. 07, Dec. 08, Dec.09.

FP can be used to

 Estimate the cost or effort required to design, code and test the software.
 Predict the number of errors that will be encountered during testing.
 Forecast the number of components and/or the number of projected source lines in the
system under implementation.
Note : For Oral examination knowledge point of view only, not in syllabus

 Terms used in FPA

o Data functions : = Relates to holding different types of data complexity.
Relates to nature of Data Structure.
o Transaction function : = Considers all processes relating to acquiring data
and processing and offer to users. The complexity of transaction relates to how
cumbersome the process is due to rules, checks, and controls. This function
provides a method to process the data.
o Data file types : = Data is stored in files. The files are internal logical files and
external interface files. The difference between the internal and external is
done through finding ‘who creates the files and maintains it?’
 Software Engineering (MU) 1-88 Introduction

If software generates a file (Record file) in the system then it is internal. If

software needs a file (Master file) created by another system (which is meant
for many other software applications) it is termed external. An invoice records
file is internal and customer Master file is external.
o Data Elements and Record Elements: = Files are determined by nature of
Data Elements and Record Elements. The number of data elements and record
elements together suggests the complexity.
For e.g., date, doc. Number, Customer name, amount, rate, quantity, tax code
are data element doc. Number, date, customer name, mount together is a
record.
Files contain different sets of records.
o Complexity of Data and File := complexity of file is judged by the number of
data element types and record element types in each file, be it internal logical
file, or external interface file.
Files containing data element Complexity Unadjusted Function Point
types/ record element types (UFP)
Less than 20/Less than 2 Simple 5
Less than 50/Less than 5 Normal 8
More than 50/More than 5 Complex 15

A) Identify data functions

Some rules / guidelines for identifying ILF’s and EIF’s are :

 A file cannot be identified as an ILF as well as EIF in the same system. It can be either
an ILF or an EIF,
 An EIF for a system is necessarily an ILF for some other system, where it is maintained,
 The same file may be identified as an ILF in more than one system, provided is
maintained in more than system,
 We need to consider the user’s view of the data rather than the developer’s view of the
data. Hence the file “invoice” will typically be considered as a single ILF or EIF, even
though invoice data may finally be stored in multiple tables after design,
 Also, files like checkpoint files, index files, recovery log, etc, will not be considered as
ILF’s or EIF’s as they are not user identifiable.
 Software Engineering (MU) 1-89 Introduction

Determine complexity of data function

 To determine the complexity of ILF’s and EIF’s, the number of Data Element Types
(DET) and Record Element Types (RET) in each ILF and EIF are identified,
 A DET is a user recognizable unique and non-recursive field also called column,
attribute, data item, and data field in the ILF/EIF,
 RET : A user recognizable logical group of fields.
While identifying RET’s look for a group of :

 DET’s that are typically updated at the same time,

 DET’s that are interest to different departments in the user organization,
 DET’s that are repeating groups,
 DET’s that describe a sub-entity.
Determine complexity of data function

 The number of DET’s and RET’s determine the complexity of an ILF or EIF.
 The higher the number of DET’s or RET’s, the higher is the complexity.

B) Identify transaction functions

 Transaction function types represent the functionality provided to the user to process
data by the application and comprise External Input (EI), External Outputs (EO),
and External Inquiries (EQ)
 An External Input (EI) is a unique business event that needs to update the data in
the system.
 For e.g., placing a purchase order would be considered an EI,
 Modification of the purchase order would be another EI, and cancellation of a
purchase order would be considered as a third EI
 An EI has to be unique, and not just an extension,
 If all the fields of a business transaction cannot fit on one screen and are therefore
split into two screens count as a single EI,
 EI may be input to the system through screens, or a electronic files created by some
other system,
 To determine the complexity of EI, the number of Data Element Types (DET) and
File Types Referenced (FTR) are identified,
 Software Engineering (MU) 1-90 Introduction

 An EI may reference ILF’s (read / insert / update / delete),

 EIF’s (read only),
 An FTR is counted for each ILF maintained by an EI,
 An FTR is also counted for each ILF or EIF read while processing an EI,
 A file i.e. both read and maintained by the same EI is counted as one FTR for that EI.

Determine complexity of EI

1-4 DET 5-15 DET  16 DET

0-1 FTR Simple Simple Average
2 FTR Simple Average Complex
 3 FTR Average Complex Complex

C) Identify transaction functions

 An External Output (EO) is a unique data or control output that crosses the
boundary to go out of a system,
 Typically, reports would be identified as External Outputs,
 An output form which is too long to fit on one screen or one page width and is
therefore split into two, is still counted as one EO,
 EO excludes responses to external inquiries as these are a separate category.

Determine complexity of EO

1-5 DET 6-19 DET  20 DET

0-1 FTR Simple Simple Average
2-3 FTR Simple Average Complex
 4 FTR Average Complex Complex
 An External Inquiry (EQ) is a unique combination of an input and an output where
the input causes the immediate generation of the output,
 An EQ implies data retrieval,
 For e.g., a request to view the list of employees, is an EQ,
 Software Engineering (MU) 1-91 Introduction

 Here,
An EQ is a unique input / output combination
o No change is made to any internal data,
o The processing and output generation resulting from the input is immediate.
o An EQ should not be counted in the EI and EO. Multiple screen queries
count as a single EQ,
o EQ complexity is based on FTR referenced while processing for the EQ,
and DET which is a user recognizable data item appearing on the output of
the EQ.
1-5 DET 6-19 DET  20 DET
0-1 FTR Simple Simple Average
2-3 FTR Simple Average Complex
 4 FTR Average Complex Complex

Since the ‘functionality’ cannot be measured directly, it must be derived indirectly

using other direct measures. Function point metric can be derived using an empirical
relationship based on countable (direct) measures of software information domain and
assessment of software complexity which are defined in following manner.
 Number of User Input : The number of user inputs that provide distinct application
oriented data to the software. It is distinguished from user inquires
 Number of User Output : e.g. reports, screens, error messages, etc.
 Number of External User Inquires (EQ) : e.g. client info inquire, price inquire, etc.
 Number of Internal and External Logical Files (ILF and ELF) : In common sense.
 Number of External Interface : The number of all machine readable interfaces that are
used to transmit info to another system. E.g. data file on storage media.
 To compute function points (FP), the following empirical relationship is used.

FP = CountTotal  [0.65 + 0.01  (Fi)]

Here CountTotal is the sum of all FP entries.

The Fi (i = 1 to 14) are value adjustment factor (VAF) ranging from (0 to 5).
 Software Engineering (MU) 1-92 Introduction

CountTotal in FP-Based Metric

VAF in FP-Based Metric

Value Adjustment Factor Implication

1. Backup and Recovery Does the system require reliable backup and
recovery ?
2. Data Communication Are specialized data communications required to
transfer information to or from the application ?
3. Distributed Processing Are there distributed processing functions ?
4. Performance Critical Is performance critical ?
5. Existing Operating Will the system run in an existing, heavily utilized
Environment operational environment ?
6. Online Data Entry Does the system require online data entry ?
7. Input Transaction over Does the online data entry require the input
Multiple Screen transaction to be built over multiple screens or
operations ?
8. ILFs Updated Online Are the ILFs updated online ?
9. Information Domain Value Are the inputs, outputs, files or inquiries complex ?
Complex
10. Internal Processing Complex Is the internal processing complex ?
11. Code Designed for Reuse Is the code designed to be reusable ?
 Software Engineering (MU) 1-93 Introduction

Value Adjustment Factor Implication

12. Conversation/Installation in Are the conversion and installation included in the
Design design ?
13. Multiple Installation Is the system designed for multiple installations in
different organizations ?
14. Application Designed for Is the application designed to facilitate change and for
Change ease of use by the user ?

Rate on 14 General System Characteristics (GSC)

GSC No. Name Explanation

1. Data Communications Look for interface of the application with
communication facilities and diverse
communication protocols. Stand alone applications
or pure batch systems will get a rating of 0.
Applications, which support multiple
teleprocessing protocols, will get a rating of 5.
2. Distributed Data The rating is based on extent to which distributed
Processing data or processing functions are a characteristic of
the application within the application boundary.
Applications that do not transfer data or processing
between components of the system will get a rating
of 0.
3. Performance Look for performance objectives, stated or implied
by the user, in either response or throughput, that
will influence the design, development, installation,
and support of the application. Applications with
no special performance or throughput requirements
will get a rating of 0.
Applications, which require benchmarking of the
design, may require optimazation of the design at
system test and installation and may also require
performance analysis tools to help in delivering the
required performance, get a rating of 5.
 Software Engineering (MU) 1-94 Introduction

GSC No. Name Explanation

4. Heavily used This GSC is related to the extent of expected use of
configuration the operational configuration, requiring special
design considerations.
For example, if the user wants to run the
application on existing or committed equipment
that will be heavily used or stretched to its limit or
will become a bottleneck, then this GSC will get a
higher rating.
5. Transaction rate Look for high volumes of transactions (EIs, EOs
and EQs). Give a high rating if the transaction
volumes are high and it will influence the design,
development, installation, and support of the
application. Assign a higher rating if the transaction
rates are not only high but also unpredictable.
6. On-line Data Entry The rating on this GSC depends on the extent of
on-line data entry and control functions to be
provided in the application. Guidelines for the
rating is as follows :
0 – All transactions are batch
1 – Upto 7% are interactive data entry
2 – Upto 15% are interactive data entry
3 – Upto 23% are interactive data entry
4 – Upto 30% are interactive data entry
5 – More than 30% are interactive data entry
7. End-user efficiency Look for requirement of “user-friendlines” in terms
of on-line function keys, jumps, menus, on-line
help, list boxes, drop downs, mouse, etc.
8. On-line Update Assign a high rating if the application provides on-
line update of the internal logical files and
automated recovery procedures with minimum
operator intervention are included. Consider the
security implications also.
 Software Engineering (MU) 1-95 Introduction

GSC No. Name Explanation

9. Complex processing Look for extensive logical and mathematical
processing and use your judgement in providing the
rating.
10. Reusability Give a high rating if the application and the code in
the application are to be specifically designed,
developed, and supported to be usable in other
applications.
11. Installation Ease Look for the need for installation utilities,
installation manuals and the extent of automation
expected in the installation.
12. Operational Ease This GSC is related to features to be provided in
the system for effective start-up, shut down, backup
and recovery. A high rating is indicated if the
application attempts to minimize the need for
manual activities, such as tape mounts and direct
on-location manual intervention.
13. Multiple sites Assign a high rating if the application has been
specifically designed, developed and supported for
multiple sites in multiple organizations. Diversity
of these sites in terms of variations in the
requirement and the hardware and software
platform should also be given consideration.
14. Facilitate change Look for the requirement of pseudo-programming
features like :
Report layout changes
Definition of new reports
User definable queries
User customization of screens

Values in FP-Based Metric

 Each of the VAF is evaluated in scale of range from 0 (not important or applicable) to 5
(absolute essential)
 Software Engineering (MU) 1-96 Introduction

 The constant values in the equation for FP is decided empirically

 The values for weighting factors that are applied to information domain counts are also
determined empirically

An Example of FP-Based Estimation

Fig. 1.30 : Safe Home Information System

An Example of FP-Based Estimation

Fig. 1.31 : Applying FP based estimation on Safe Home Information System

 Software Engineering (MU) 1-97 Introduction

An example of FP-Based estimation

VAF Value
1. Backup and Recovery 4
2. Data Communication 2
3. Distributed Processing 0
4. Performance Critical 4
5. Existing Operating Environment 3
6. Online Data Entry 4
7. Input Transaction over Multiple Screen 5
8. ILFs Updated Online 3
9. Information Domain Value Complex 5
10. Internal Processing Complex 5
11. Code Designed for Reuse 4
12. Conversation/Installation in Design 3
13. Multiple Installation 5
14. Application Designed for Change 5
Total VAF 62
 Software Engineering (MU) 1-98 Introduction

 The estimated number of FP can be derived as

= 50  [0.65 + 0.01  62]
= 63.5
 Suppose the organizational average productivity for system of this type = 1.2 FP/PM
Cost of a PM = Rs. 20,000/-
Effort = FP / Productivity
= 63.5 / 1.2 = 53 PM
Cost = 53  20,000 = Rs. 10, 60,000  11 lakhs
Relation between LOC and FP
Programming Language LOC/FP (average)
Assembly language 320
C 128
COBOL 106
FORTRAN 106
PASCAL 90
C++ 64
Ada95 53
Visual Basic 32
Smalltalk 22
Powerbuilder (code generator) 16
SQL 12

Advantages of FPC

 FPC is independent of the technology, that is, OS, programming language, database,
developer productivity and methodology.
 The FPC concept is simple to understand; hence, it becomes a good quick measure for
any comparative analysis. Companies use FPCs to compare between software, or
between the productivity of different groups.
 Software Engineering (MU) 1-99 Introduction

Disadvantages of FPC

 Estimation is based on subjective judgment of the software designer. It therefore varies

from person to person; the choice of design and architecture also subjective
 Since the software system is decomposed in various components, and then into data and
functions, the estimate does not cater to integration requirement of these components. It
therefore needs subjective adjustment to arrive at the FPC for the whole software system
 Identification of files is tricky, and number of files is uncertain
 The system may have more than 14 characteristics that have not been considered.
 The internal processing complexity due to the use of complex business rules,
algorithms, calculations etc. is not weighed adequately.

1.15.4 COCOMO Model .MU - May 06, June 10(Old).

A top-down model can depend on many different factors, instead of depending only
on one variable, giving rise to multivariable models.
One approach for building multivariable models is to start with an initial estimate
determined by using the static single-variable model equations, which depend on size, and
then adjusting the estimates based on other variables. This approach implies that size is the
primary factor for cost; other factors have a lesser effect.
COCOMO model also estimates the total effort in terms of person-months. The basic
steps in this model are :
1. Obtain an initial estimate of the development effort from the estimate of thousands of
delivered lines of source code (KLOC).
2. Determine a set of 15 multiplying factors from different (cost driver) attributes of the
project.
3. Adjust the effort estimate by multiplying the initial estimate with all the multiplying
factors.
The original COCOMO model was a set of models;
 3 development modes (organic, semi-detached, and embedded) and
 3 levels (basic, intermediate, and advanced).

1.15.4.1 COCOMO Model Levels

COCOMO, COnstructive COst MOdel is static single-variable model. There is a

hierarchy of these models.
 Software Engineering (MU) 1-100 Introduction

 Model 1 : Basic COCOMO model is static single-valued model that computes software
development effort (and cost) as a function of program size expressed in estimated lines
of code.
The basic COCOMO equations take the form :
Effort Applied = ab  (KLOC) b [ man-months ]
b

Development Time = cb  (Effort _ Applied)

db
[months]
People required = Effort Applied / Development Time [count]
Where,
 E is the effort applied in person-month,
 D is the development time in chronological month,
 KLOC is the estimated number of delivered lines ( expressed in thousands ) of code for
project,
 The ab and cb and the exponent’s bb and db are given in the Table 1.14 below.
Example :
KLOC = 10.9
ab  (KLOC)
bb
E =
1.05
= 2.4 * (10.9)
= 29.5 person-month
Cb  (E)
db
D =
0.38
= 2.5 * (29.5)
= 9.04 months
Table 1.14 : Constants for Effort and Duration for Basic COCOMO

Software project ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Basic COCOMO is good for quick estimate of software costs. However it does not
account for differences in hardware constraints, personnel quality and experience, use of
modern tools and techniques, and so on.
 Software Engineering (MU) 1-101 Introduction

 Model 2 : Intermediate COCOMO model computes software development effort as a

function of program size and a set of “cost drivers” that include subjective assessments
of product, hardware, personnel, and project attributes.
The intermediate COCOMO model takes the following form.

ai  (LOC) i  EAF
b
E =
Cb  (EffortApplied) b [months]
d
Development Time =

Where,
 E is the effort applied in person-months,
 LOC is the estimated number of delivered lines of code for the project.
 The coefficient ai and the exponent bi are given in the table below.
 EAF- Effort Adjustment Factor which is obtained by multiplying all 15 cost drivers.
The Development time D calculation uses E in the same way as in the Basic
COCOMO.
Table 1.15 : Constants for Effort and Duration for Intermediate COCOMO

Development Mode ai bi ci di
Organic : 3.2 1.05 2.5 0.38
Semidetached : 3.0 1.12 2.5 0.35
Embedded : 2.8 1.20 2.5 0.32
Each of the 15 attributes receives a rating on a six-point scale that ranges from “very
low” to “extra high” (in importance or value). An effort multiplier from the table 1.16 below
applies to the rating. The product of all effort multipliers results in an effort adjustment
factor (EAF). Typical values for EAF range from 0.9 to 1.4.
Table 1.16 : Effort multipliers for different cost drivers

Ratings
Cost Drivers Very Low Nominal High Very Extra
Low High High
Product Attribute
RELY, required reliability 0.75 0.88 1.00 1.15 1.40
DATA, database size 0.94 1.00 1.08 1.16
CPLX, product complexity 0.70 0.85 1.00 1.15 1.30 1.65
 Software Engineering (MU) 1-102 Introduction

Ratings
Cost Drivers Very Low Nominal High Very Extra
Low High High
Computer Attributes
TIME, execution time 1.00 1.11 1.30 1.66
constraints
STOR, main storage constraint 1.00 1.06 1.21 1.56
VITR, virtual memory 0.87 1.00 1.15 1.30
volatility
TURN, computer turn around 0.87 1.00 1.07 1.15
time
Personnel Attributes
ACAP, analyst capability 1.46 1.19 1.00 0.86 0.71
AEXP, application experience 1.29 1.13 1.00 0.91 0.82
PCAP, programmer capability 1.42 1.17 1.00 0.86 0.70
VEXP, virtual machine 1.21 1.10 1.00 0.90
experience
LEXP, programming language 1.14 1.07 1.00 0.95
experience
Project Attributes
MODP, modern programming 1.24 1.10 1.00 0.91 0.82
practices
TOOL, use of SW tools 1.24 1.10 1.00 0.91 0.83
SCHED, development schedule 1.23 1.08 1.00 1.04 1.10
Table 1.17 : Phase Distribution of Effort : Organic Mode

Phase Small Intermediate Medium Large

( 2 KLOC) (8 KLOC) ( 32 KLOC ) ( 128 KLOC )
Product Design 16 16 16 16
Detailed Design 26 25 24 23
Software Engineering (MU) 1-103 Introduction

Phase Small Intermediate Medium Large

( 2 KLOC) (8 KLOC) ( 32 KLOC ) ( 128 KLOC )
Code and Unit Test 42 40 38 36
Integration and Test 16 19 22 25
Total : 100 100 100 100
Table 1.18 : Phase Distribution of Schedule : Oraganic Mode

Phase Small Intermediate Medium Large

(2 KLOC) (8 KLOC) ( 32 KLOC ) ( 128 KLOC )
Product Design 19 19 19 19
Detailed Design and
Code and Unit Test 63 59 55 51
Integration and Test 18 22 26 30
Total : 100 100 100 100
Table 1.19 : Phase Distribution of Effort : Semidetached Mode

Phase Small Intermediate Medium Large

( 2 KLOC) (8 KLOC) ( 32 KLOC ) ( 128 KLOC )
Product Design 17 17 17 17
Detailed Design 27 26 25 24
Code and Unit Test 37 35 33 31
Integration and Test 19 22 25 28
Total : 100 100 100 100
Table 1.20 : Phase Distribution of Schedule : Semidetached Mode

Phase Small Intermediate Medium Large

( 2 KLOC) (8 KLOC) ( 32 KLOC ) ( 128 KLOC )
Product Design 24 25 26 27
Detailed Design and 56 52 48 44
Code and Unit Test
Integration and Test 20 23 26 29
Total : 100 100 100 100
 Software Engineering (MU) 1-104 Introduction

Table 1.21 : Phase Distribution of Effort: Embedded Mode

Phase Small Intermediate Medium Large

( 2 KLOC) (8 KLOC) ( 32 KLOC ) ( 128 KLOC )
Product Design 18 18 18 18
Detailed Design 28 27 26 25
Code and Unit Test 32 30 28 26
Integration and Test 22 25 28 31
Total : 100 100 100 100
Table 1.22 : Phase Distribution of Schedule: Embedded Mode

Phase Small Intermediate Medium Large

( 2 KLOC) (8 KLOC) ( 32 KLOC ) ( 128 KLOC )
Product Design 30 32 34 36
Detailed Design and
Code and Unit Test 48 44 40 36
Integration and Test 22 24 26 28
Total : 100 100 100 100
By comparing tables 6.4 through 6.9 we can see some differences between the effort
and schedule distribution of the products developed in different modes. The main differences
are :
1. The embedded-mode project consumes considerably more effort in the integration and
test phase. This results from the need to follow and verify software requirements and
interface specifications more carefully in the embedded and semidetached mode.
2. The embedded-mode project consumes proportionally less effort in the code and unit
test phase. This result from the proportionally higher effort required for the other
development phases.
3. The embedded-mode project consumes considerably more schedule in both the plans
and requirement phase and the product design phase. This is because of the project’s
need for more thorough, validated requirements and design specifications, and the
greater need to perform these phases with a relatively small number of people.
4. The embedded-mode project consumes considerably less schedule in the programming
phase. This results from the strategy of employing a great many people programming
in parallel, in order to reduce the project’s overall schedule.
 Software Engineering (MU) 1-105 Introduction

 Model 3 : Advanced COCOMO model incorporates all characteristics of the

intermediate version. The difference is that, with the advanced model, the cost drivers
are weighted differently across four major stages of the development lifecycle. These
four stages are specified as: requirements planning and product design (RPD), detailed
design (DD), code and unit test (CUT), and integration and test (IT). Each cost driver
now has a new value depending on which phase it is in. Below is an example of the
analyst capability cost driver for the advanced COCOMO model.

Cost Driver Rating RPD DD CUT IT

Very low 1.80 1.35 1.35 1.50

ACAP Low 0.85 0.85 0.85 1.20

Nominal 1.00 1.00 1.00 1.00

High 0.75 0.90 0.90 0.85

Very High 0.55 0.75 0.75 0.70

COCOMO can be applied to the following software project’s categories.

1.15.4.2 COCOMO Development Modes

Organic :

 In the organic mode the project is developed in a familiar, stable environment and the
product is similar to previously developed products.
 The product is relatively small, and requires little innovation.
 Most people connected with the project have extensive experience in working with
related systems within the organization and therefore can usefully contribute to the
project in its early stages, without generating a great deal of project communication
overhead.
 An organic mode project is relatively relaxed about the way the software meets its
requirements and interface specifications.
 If a situation arises where an exact correspondence of the software product to the
original requirements would cause an extensive rework, the project team can generally
negotiate a modification of the specifications that can be developed more easily.
 A thermal analysis program developed for a heat transfer group is an example of this.
 Software Engineering (MU) 1-106 Introduction

Embedded :

 In this development mode Project is characterized by tight, inflexible constraints and

interface requirements.
 The product must operate within a strongly coupled complex of hardware, software,
regulations, and operational procedures.

 The embedded-mode project does not generally have the option of negotiating easier
software changes and fixes by modifying the requirements and interface specifications.

 The project therefore needs more effort to accommodate changes and fixes.
 The embedded mode project is generally charting its way through unknown territory to a
greater extent than the organic mode project.
 This lead the project to use a much smaller team of analyst in the early stages, as a large
number of people would get swamped in communication overhead.

 Once the embedded mode project has completed its product design, its best strategy is to
bring on a very large team of programmers to perform detailed design, coding and unit
testing in parallel.
 Otherwise the project would take much longer to complete.
 This strategy as we will see leads to the higher peaks in the personnel curves of
embedded-mode projects, and to the greater amount of effort consumed compared to an
organic mode project working to the same total development schedule.

For example, flight control software for aircraft.

Semi-detached :

In this mode project’s characteristics are intermediate between Organic and

Embedded. “Intermediate” may mean either of two things :
 An intermediate level of project characteristics.
 A mixture of the organic and embedded mode characteristics.
Therefore in a Semidetached mode project, it is possible that :
 The team members all have an intermediate level of experience with related systems.
 The team has a wide mixture of experienced and inexperienced people.
 Software Engineering (MU) 1-107 Introduction

 The team members have experience related to some aspects of the system under
development, but not others.
The size of a Semidetached mode product generally extends up to 300 KDSI.
A transaction processing system with fixed requirements for terminal hardware and
database software is an example of this.
Table1.23 : Different development modes and their characteristics

Development Mode Project characteristics

Size Innovation Deadline / Dev. Environment

Constraints

Organic Small Little Not tight Stable

Semi- Medium Medium Medium Medium

detached

Embedded Large Greater Tight Complex hardware /

Customer interfaces

1.15.4.3 Steps to estimate phase-wise effort (Cost Estimation or Effort

Estimation)

1) The initial estimate Ei (also called nominal estimate) is determined by an equation of

the form used in the static single-variable models, using KLOC as the measure of size.
Using basic COCOMO

ab  (KLOC) b [ man-months ]
b
Ei =

2) EAF (effort adjustment factor) = The multiplication of factors for all 15 cost drivers
using Table 1.16.

3) The final effort estimate, E, is obtained by multiplying the initial estimate by the EAF.

E = EAF *Ei
 Software Engineering (MU) 1-108 Introduction

Example :

The system will comprise a few different modules. The modules and their expected
sizes are :
Login 200 LOC
Payment 200 LOC
Administrator interface 600 LOC
Seller functions 200 LOC
Buyer functions 500 LOC
View and bookkeeping 300 LOC
-------------------------------------------------------
TOTAL 2000 LOC
The total size of this software is estimated to be 2 KLOC.
Suppose we expect that
 The complexity of the system is high,
 The programmer capability is low, and
 The application experience of the team is low.
 All other factors have a nominal rating.
From these, the effort adjustment factor (EAF) is,
EAF = 1.15 * 1.17 * 1.13 = 1.52
The initial effort estimate for the project is,
Ei = 3.9 * 2.91 = 7.3 PM.

Using the EAF, the adjusted effort estimate is,

E = 1.52 * 7.3 = 11.1 PM

4) By this method, the overall cost of the project can be estimated. For planning and
monitoring purposes, estimates of the effort required for the different phases are
also desirable. In COCOMO, effort for a phase is a defined percentage of the overall
effort. The percentage of total effort spent in a phase varies with the type and size of
the project. The percentages for an organic, semi-detached, embedded software project
are given in Table 1.14 to Table 1.15.
 Software Engineering (MU) 1-109 Introduction

Using this table, the estimate of the effort required for each phase can be determined
from the total effort estimate.

Example :

 If the total effort estimate for an organic software system is 20 PM and

 The size estimate is 20KLOC,
An estimate of percentages for project sizes different from the one specified in the
table can be obtained by linear interpolation. Using interpolation to get the appropriate
percentage use following formula,
% effort for phase = Phase (L) + [((Phase (U) – Phase (L)) / (U – L))
*given effort estimate]

Where,
 Phase is one of the rows of table,
 L- Lower Bound Column value,
 U- Upper Bound Column value,
 Phase (L) - row of phase and column of L intersection cell value
 Phase (U) - row of phase and column of U intersection cell value
For Example :
Locate lower and upper bound in table 1 given effort estimate 20PM.
For 20 PM, it is in between 8KLOC and 32KLOC.
L = 8 KLOC
U = 32 KLOC
Phase = Coding and Unit testing
Phase (L) = 40
Phase (U) = 38
Then the percentage effort for phase coding and unit testing will be
40 + (38 - 40)/ (32 - 8) * 20 = 39%.
The estimate needed for this phase is calculated as,
(Given effort estimate) * (% effort of phase) = 20 * 0.39 = 7.8 PM
 Software Engineering (MU) 1-110 Introduction

Example :

Suppose a system for office automation has to be designed. From the requirements, it
is clear that there will be four major modules in the system: data entry, data update, query,
and report generator. It is also clear from the requirements that this project will fall in the
organic category. The sizes for the different modules and the overall system are estimated
to be :
Data entry 0.6 KLOC
Data update 0.6 KLOC
Query 0.8 KLOC
Reports 1.0 KLOC
Total 3.0 KLOC
From the requirements, the ratings of the different cost driver attributes are assessed.
These ratings, along with their multiplying factors, are :
Complexity High 1.15
Storage High 1.06
Experience Low 1.13
Programmer capability Low 1.17
All other factors had a nominal rating. From these, the effort adjustment factor (EAF)
is
EAF = 1.15 * 1.06 * 1.13 * 1.17 = 1.61.
The initial effort estimate for the project is obtained from the relevant equations.
We have
Ei = 3.2 * 31.05 = 10.14PM.
Using the EAF, the adjusted effort estimate is
E = 1.61 * 10.14 = 16.3PM
Using the phase wise distribution table listed earlier, we obtain the percentage of the
total effort consumed in different phases.
The office automation system’s size estimate is 3 KLOC, so we will have to use
interpolation to get the appropriate percentage (the two end values for interpolation will be
the percentages for 2 KLOC and 8 KLOC).
Note : Type of interpolation technique used to calculate % effort for phase can be varied as per policy
of organization.
 Software Engineering (MU) 1-111 Introduction

The percentages for the different phases are :

 design 16%,
 detailed design 25.83%,
 code and unit test 41.66%, and
 integration and testing 16.5%.
With these, the effort estimates for the different phases are :
System design 0.16 * 16.3 = 2.6 PM
Detailed design 0.258 * 16.3 = 4.2 PM
Code and unit test 0.4166 * 16.3 = 6.8 PM
Integration 0.165 * 16.3 = 2.7 PM
These effort estimates will be used later during personnel planning.

1.15.5 Introduction to COCOMO II

The original COCOMO model became one of the most widely used and discussed
software cost estimation models in the industry. It has evolved into a more comprehensive
estimation model, called COCOMO II. COCOMO II is tuned to modern software life cycles,
such as business software, object-oriented software, and software that uses more modern
development models like the spiral or evolutionary models. The original COCOMO model
has been very successful, but it doesn’t apply to newer software development practices as
well as it does to traditional practices. COCOMO II targets the software projects of the
1990s and 2000s, and will continue to evolve over the next few years.
The primary objectives of the COCOMO II effort are :
 To develop a software cost and schedule estimation model tuned to the life cycle
practices of the 1990’s and 2000’s.
 To develop software cost database and tool support capabilities for continuous model
improvement.
COCOMO II is actually a hierarchy of estimation models that address the following
areas :
 Model 1 : Application composition model : Used during the early stages of software
engineering, when prototyping of user interfaces, consideration of software and system
interaction, assessment of performance, and evaluation of technology maturity are
paramount.
 Software Engineering (MU) 1-112 Introduction

 Model 2 : Early design stage model : Used once requirements have been stabilized and
basic software architecture has been established.
 Model 3 : Post-architecture-stage model : Used during the construction of the
software. Like all estimation models for software, the COCOMO II models require
sizing information. Three different sizing options are available as part of the model
hierarchy :
Object points, function points, and lines of source code.

Model 1 : Application Suite Model (or Application composition model)

This model is used where software can be decomposed into several components and
each component can be described in the object points. Objects are screen, reports, and
3GL components, which are easy to identify and count when the software system is split
into different sub-system components.
Object points are alternative to function points when 4GLs or similar languages are
used for software development. It should be noted that object points are not object classes.
Objects are given object points as under, depending on the level of complexity.

Simple Complex Very Complex

Screen 1 2 3
Reports 2 5 8
3GL Modules 4 10 –
Advantage of using object points is that they can be estimated from the high level of
design of the software and they are only numbers of screens, reports and 3GL modules.
The object points count needs modification by way of reduction as the software may
use reusable components and libraries. Therefore :

(100 – % reuse)
ROP = OP  100

Where , ROP = Revised Object Point, OP = Object Point

For this ROP, the effort in man months is computed using productivity constant based
on the software development team’s experience and capability. COCOMO II prescribes a
productivity constant expressed as the number of object points per man month.
 Software Engineering (MU) 1-113 Introduction

Developer’s level of experience and maturity Very low Low Nominal High Very high
Productivity Constant 4 7 13 25 50
(NOP* per Month)

*Number of object points

ROP
MME (Man_Month_Effort) =
Productivity_Constant

For e.g., object points, say, are 40 and the re-use possibility is 10%, then
ROP = 40 * ((100 – 10)/100) = 40 * 0.90 = 36

Further, if the development team’s experience and maturity is at level Normal, then
productivity constant is 13. Hence
MME = (ROP)/ Productivity Constant = 36/13 ≈ 3 Man months.

This model is also used to estimate the effort at the prototype level when requirements
are not clear.

Model 2 : Early Design Level Model : COCOMO II

The COCOMO II models use the base equation

MME (Man_Month_Effort) = A* (Size)B

where MME = Man Month Effort A

= Constant representing nominal productivity
B = Factor indicating economies / diseconomies of scale. ‘B’ is known
as the scaling factor
Size = KLOC

It should be understood that if B = 1, then software does not have an impact on MME.
So, if B is less than 1, the impact on man month effort will have a positive impact and if B is
greater than 1, the impact on man month effort is negative. That is, man month effort is
either less or more than the man month effort required when B = 1.
 Software Engineering (MU) 1-114 Introduction

‘B’ the value of scaling factors (also known as drivers) is computed as below
5 
B = 0.91 + 0.01  Ratings
 
1 
The rating for each of the factors is based on the organization’s level on each of these
factors

Factor Very low Low Nominal High Factor name

Precedence 6.20 4.96 3.72 2.48 Precedentness

Flexibility 5.07 4.05 3.04 2.03 Flexibility

Risk Resolution 7.07 5.65 4.24 2.83 Risk Resolution

Team Cohesion 5.48 4.38 3.29 2.19 Team Cohesion

Process Maturity 7.80 6.24 4.68 3.12 Process Maturity

Let us assume that in a given software development, the organization’s level on these
five factors is very low. Then
B = 0.91+ 0.01 * (6.20 + 5.07 + 7.07 + 5.48 + 7.80) = 1.2262
A = 13, size based on FPA is 10 KLOC
Then MME = 13 * (10)1.2262 = 220 man month
For the same software, if we say that organization’s scores ‘high’ on all factors,
Then B = 0.91 + 0.01 * (2.48 + 2.03 + 2.83 + 2.19 + 3.12) = 1.0365 ≈ 1.04
Then MME = 13  (14)1.04 = 142 man months.

Model 3 : Post Architectural Stage Model : COCOMO II

In addition to these factors that affect development efforts, there are also other factors
that are relevant, as they have a large impact on MME. If these factors are considered, the
MME (Modified) is calculated.

COCOMO II equation for

MME (Modified)= MME* (Product_of_ratings_of_16) factors)

 Software Engineering (MU) 1-115 Introduction

COCOMO II describes following factors :

Sr. Factor Sub factors Description

No.
1 SOFTWARE Reliability Failure does not cause any inconvenience,
Rating = very low. Failure is fatal,
Rating = High
2 Database size Database size is measured as (D) Database
in bytes divided by (P) Lines of Code (D/P)
If D/P < 10, Rating is low. If D/P > 1000,
Rating is high.
3 SOFTWARE Complexity Few control options, simple, few
calculations, simple data management, then
Product Rating = V. low.
Factors
If all these are high, Rating = high
4 Required Reusability No requirement of reusability, i.e., custom
software then Rating = V. low. If reusability
is required of substantial nature then
Rating = High
5 Documentation Documentation need is standard but low
then Rating = V. low.
Documentation need is very high both
pre and post-development, Rating = High
6 Time Constraint on No constraint, Rating = V. low
Execution. Available time is almost equal to execution
time, Rating = High
7 Main storage constraint No constraint due to available very high
storage. Rating = Very low.
Platform
Factors Available storage is almost equal to
required storage,
Rating = High
8 Platform Volatility If platform is stable, Rating = V. low.
Else Rating = High
 Software Engineering (MU) 1-116 Introduction

Sr. Factor Sub factors Description

No.
9 Analyst Capability Inexperience and lack of knowledge etc.;
then capability is low and Rating = V. low
else Rating = High.

10 Programmer Capability Same as Analyst Capability

11 Personnel Personnel Continuity Very low turn over, Rating = High.
Factors 50% or more would leave, Rating = V. low.
12 Analyst Experience Minimum experience, Rating = V. low
More than adequate experience
Rating = V. high
13 Programmer Experience Same as 12
14 Language and Tools Same as 12
Experience
15 Use of software tools No use or occasional use, Rating=V. low
Sustained usage of a variety of tools,
Project Rating = High
16 Factors Site Environment - Single site, single location, not more
than 1 or 2 sponsors, Rating = V. low.
- Multiple site, multiple partners, number
of locations, but supported by good
communication infrastructure,
Rating = High
- If problems of communication are not
there, Rating = V. low.
 Software Engineering (MU) 1-117 Introduction

The value of the rating is as per the guidelines given in following table :

Levels and ratings

Factor
Very low Low Nominal High
1 0.82 0.92 1.0 1.0
2 0.80 0.90 1.0 1.14
3 0.73 0.87 1.0 1.17
4 0.85 0.95 1.0 1.07
5 0.81 0.91 1.0 1.11
6 NRA NRA 1.0 1.11
7 NRA NRA 1.0 1.05
8 NRA NRA 1.0 1.15
9 1.42 1.19 1.0 0.85
10 1.34 1.15 1.0 0.88
11 1.22 1.10 1.0 0.88
12 1.19 1.09 1.0 0.91
13 1.20 1.09 1.0 0.91
14 1.29 1.12 1.0 0.90
15 1.17 1.09 1.0 0.90
16 1.22 1.09 1.0 0.93
NRA*= No Rating Applied.

Let us evaluate two possibilities of an extreme nature.

Possibility 1 : All ratings are ‘very low’

Hence, product of all 16 ratings value from table

0.82*0.80*1.73*0.85*1.42*1.34*1.22*1.99*1.20*1.29*1.17*1.22 = 2.0

Possibility 2 : All ratings are ‘High’

Hence, product of all 16 ratings value from table

1.10*1.14*1.17*1.07*1.11*1.11*1.05*1.15*0.85*0.88*0.88*0.91*0.91*0.90*0.90*0.93 = 0.98
 Software Engineering (MU) 1-118 Introduction

So MME 1= 220 * 2.01= 442 man months possibility 1

MME 2= 142 * 0.98= 139 man months possibility 2
The man month cost is estimated by multiplying man months by man month rate.

1.16 Empirical Estimation Models

.MU - May 04, Oct. 04, May 07, June 10.
An estimation model for computer software uses empirically derived formulas to
predict effort as a function of LOC or FP. The empirical data that support most estimation
models are derived from a limited sample of projects.
An estimation model should be calibrated for local conditions. The model should be
run using the results of completed projects. Data predicted by the model should be compared
to actual results and the efficacy of the model (for local conditions) should be assessed. If
agreement is not good, model coefficients and exponents must be recomputed using local
data.

The structure of estimation models

A + B  (ev)
C
E =
Where, A, B, C are empirically derived constants, E is effort in person-months and ev
is estimation variable (either LOC or FP)
Two popular empirical estimation techniques are :
1. Expert judgment
2. Delphi estimation technique

1.16.1 Delphi Method of Cost Estimation

 Estimated by a team (composed with a group of experts) and a coordinator

 Individual team member estimates based on SRS supplied by the coordinator
 Estimator points out typical characteristic (s) by which s/he has been influenced while
estimating
 Based on the input from all estimators, coordinator prepared a summary sheet and
distributes the same to all estimators emphasizing the important things noted by others
 Based on the summary, estimators re-estimate and the process may be iterated
depending on the satisfaction of the coordinator. Coordinator is responsible for
compiling final results and preparing the final estimates.
 Software Engineering (MU) 1-119 Introduction

 The 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.
Note : An estimator is opaque to any other estimators.

1.17 Planning
.MU - June 05, May 07, Nov. 07, May 08, Dec. 08, Dec. 09, June 10.
The objective of software project planning is to provide a framework that enables the
manager to make reasonable estimates of resources, cost, and schedule. These estimates are
made within a limited time frame at the beginning of a software project and should be
updated regularly as the project progresses. In addition, estimates should attempt to define
best case and worst case scenarios so that project outcomes can be bounded.
The other objectives of project planning are :
 It defines the roles and responsibilities of the project management team members.
 It ensures that the project management team works according to business objectives.
 It checks feasibility of schedule and user requirements.
 It determines project constraints.

1.17.1 Principles of Project Planning

 Planning is necessary : Planning should be done before ea project begins. For effective
planning, objectives and schedules should be clear and understandable.
 Risk analysis : Before starting the project, senior management and the project
management teams should consider the risks that may affect the project. For example,
the user may desire changes in requirements while the project is in progress. In such a
case, the estimation of time and cost should be done according to those requirement
(new requirements).
 Tracking of project plan : Once the project plan is prepared, it should be tracked and
modified accordingly.
 Meet quality standards and produce quality deliverables : The project plan should
identify processes by which the project management team can ensure quality in
software. Based on the process selected for ensuring quality , the time and cost for the
project is estimated.
 Software Engineering (MU) 1-120 Introduction

 Description of flexibility to accommodate changes : The result of project planning is

recorded in the form of a project plan, which should allow new changes to be
accommodated when the project is in progress.
Project planning comprises project purpose, project scope, project planning process
and project plan.

A) Project purpose

A software project is carried out to accomplish a specific purpose, which is classified

into two categories, namely, project objectives and business objectives. The commonly
followed project objectives are :
 Meet user requirements : Develop the project according to user requirements after
understanding them.
 Meet Schedule Deadlines : Complete the project milestones as described in the project
plan on time in order to complete the project according to schedule.
 Be within Budget : Manage the overall project cost so that the project is within budget.
 Produce Quality Deliverables : Ensure that quality is considered for accuracy and
overall performance of the project.
Business objectives ensure that the organizational objectives and requirements are
accomplished in the project. Generally, these objectives are related to business process
improvements, customer satisfaction, and the quality improvements. The commonly
followed business objectives are as follows :
 Evaluate Processes : Evaluate the business processes and make changes when and
where required as the project progresses.
 Renew Policies and Processes : Provide flexibility to renew the policies and processes
of the organization in order to perform the task effectively.
 Keep the Project on Schedule : Reduce the downtime (period when no work is done)
factors, such as an unavailability of resources during software development.
 Improve Software : Use suitable processes in order to develop software that meets
organizational requirements and provide competitive advantage to the organization.

B) Project scope

A statement of software scope must be bounded.

 Software Engineering (MU) 1-121 Introduction

Software scope describes the data and control to be processed, function, performance,
constraints, interfaces, and reliability. Functions described in the statement of scope are
evaluated and in some cases refined to provide more detail prior to the beginning of
estimation. Because both cost and schedule estimates are functionally oriented, some degree
of decomposition is often useful. Performance considerations encompass processing and
response time requirements. Constraints identify limits placed on the software by external
hardware, available memory, or other existing systems.

C) Project planning process

The project planning process comprises the following :

 Objectives and scope of the project
 Techniques used to perform project planning
 Effort (in time) of individuals involved in the project
 Project schedule and milestones
 Resources required for the project
 Risk associated with the project.

Fig. 1.32 : Project planning activities

 Software Engineering (MU) 1-122 Introduction

Above figure shows several activities, which can be performed both in a sequence and
in a parallel manner. Project planning consists of various activities.
 Identification of project requirements : Before starting a project, it is essential to
identify the project requirements as the identification of project requirements helps in
performing the activities in a systematic manner. These requirements comprise
information such as project scope, data and functionality required in the software, and
roles of the project management team members.
 Identification of cost estimates : Along with the estimation of effort and time, it is
necessary to estimate the cost that is to be incurred on a project. The cost estimation
includes the cost of hardware, network connections, and the cost required for the
maintenance of hardware components. In addition, cost is estimated for the individuals
involved in the project.
 Identification of risks : Risks are unexpected events that have an advance effect on the
project. A software project involves several risks (like technical risks and business risks)
that affect the project schedule and increase the cost of the project. Identifying risks
before a project begins helps in understanding their probable extent of impact on the
project.
 Identification of critical success factors : For making a project successful, critical
success factors are followed. These factors refer to the conditions that ensures greater
chances of success of a project. Generally, these factors include support from
management, appropriate budget, appropriate schedule, and skilled software engineers.
 Preparation of project charter : A project charter provides a brief description of the
project scope, quality, time, cost, and the resource constraints as described during
project planning. It is prepared by the management for approval from the sponsor of the
project.
 Preparation of project plan : A project plan provides information about the resources
that are available for the project, individuals involved in the project, and the schedule
according to which the project is to be carried out.
 Commencement of the project : Once the project planning is complete and resources
are assigned to team members, the software project commences.
Once the project objectives and business objectives are determined, the project end
date is fixed. The project management team prepares the project plan and schedule according
to the end date of the project. After analyzing the project plan, the project manager
communicates the project plan and end date to the senior management. The progress of the
project is reported to the management from time to time. Similarly, when the project is
complete, senior management is informed about it. In case of delay in completing the
project, the project plan is re-analyzed and corrective action is taken to complete the project.
The project is tracked regularly and when the project plan is modified, the senior
management is informed.
 Software Engineering (MU) 1-123 Introduction

D) Project plan

Document templates

Software project plan

1.0 Introduction

This section provides an overview of the software engineering project.

1.1 Project scope
A description of the software is presented. Major inputs, processing functionality
and outputs are described without regard to implementation detail.
1.2 Major software functions
A functional decomposition of the software (for use during estimation and
scheduling) is developed here.
1.3 Performance/Behavior issues
Any special requirements for performance or behavior are noted here.
1.4 Management and technical constraints

Any special constraints that affect the manner in which the project will be
conducted (e.g., limited resources or ‘drop dead’ delivery date) or the technical
approach to development are noted here.

2.0 Project estimates

This section provides cost, effort and time estimates for the projects
2.1 Historical data used for estimates

Describes the historical data that is relevant to the estimates presented.

2.2 Estimation techniques applied and results

A description of each estimation technique and the resultant estimates are

presented here.
2.2.1 Estimation technique m

Tables or equations associated with estimation technique m are presented.

Section 2.2.1 is repeated for each of m techniques.
 Software Engineering (MU) 1-124 Introduction

2.2.2 Estimate for technique m

Estimate generated for technique m.

2.3 Reconciled estimate

The final cost, effort, time (duration) estimate for the project (at this point in time)
is presented here.
2.4 Project resources

People, hardware, software, tools, and other resources required to build the
software are noted here.

3.0 Risk management

This section discusses project risks and the approach to managing them.
3.1 Project risks

Each project risk is described. The CTC format may be used.

3.2 Risk table

The complete risk table is presented. Name of risk, probability, impact and RM3
pointer are provided.
3.3 Overview of risk mitigation, monitoring, management

An overview of RM3 is provided here. The Complete RM3 is provided as a

separate document or as a set of Risk Information Sheets.

4.0 Project schedule

This section presents an overview of project tasks and the output of a project
scheduling tool.
4.1 Project task set

The process model, framework activities and task set that have been selected for
the project are presented in this section.
4.2 Functional decomposition

A functional breakdown to be used for scheduling is presented here.

 Software Engineering (MU) 1-125 Introduction

4.3 Task network

Project tasks and their dependencies are noted in this diagrammatic form.
4.4 Timeline chart

A project timeline chart is presented. This may include a time line for the entire
project or for each staff member.

5.0 Staff organization

The manner in which staff are organized and the mechanisms for reporting are noted.
5.1 Team structure

The team structure for the project is identified. Roles are defined.
5.2 Management reporting and communication

Mechanisms for progress reporting and inter/intra team communication are

identified.

6.0 Tracking and control mechanisms

Techniques to be used for project tracking and control are identified.

6.1 Quality assurance and control

An overview of SQA activities is provided. Note that an SQA Plan is developed

for a moderate to large project and may be a separate document or included as an
appendix.
6.2 Change management and control

An overview of SCM activities is provided. Note that an SCM Plan is developed

for a moderate to large project and may be a separate document or included as an
appendix.

7.0 Appendix

Supplementary information is provided here.

 Software Engineering (MU) 1-126 Introduction

1.18 Project Scheduling

.MU - May 04, June 05, May 06, May 07, Nov. 07, Dec. 08, Dec. 09, June 10(Old) .
Schedule estimation and staff requirement estimation may be the most important
activities after cost estimation.
The goal of schedule estimation is to determine :
 The total duration of the project and
 Duration of different phases.
It is essential to perform project scheduling to effectively manage the tasks of the
project. Project scheduling provides details, such as start date and end date of the project,
milestones, and tasks for the project. In addition, it specifies the resources (such as people,
equipment, and facilities) required to complete the project and the dependencies of tasks of
the project on each another. An appropriate project schedule prepared according to project
plan not only aims to complete the project on time but also helps to avoid the additional cost
incurred when the project is delayed.

1.18.1 Various Factors Delaying Project Schedule

The commonly noticed factors are :

 Unrealistic deadlines : Project schedule is affected when the time allocated for
completing a project is impractical and not according to the effort required for it.
Generally, this situation arises when the deadline is established by inexperienced
individual(s) or without the help of project management team. Here, the project
management team is constrained to work according to the deadline. The project is
delayed if the deadline is not achieved.
 Changing user requirements : Sometimes, project schedule is affected when user
requirements are changed after the project has started. This affects the project schedule,
and thus more time is consumed both in revision of project plan and implementation of
new requirements.
 Under estimation of resources : If the estimation of the resources for the project is not
done according to its requirement, the schedule is affected. This under-estimation of
resource leads to delay in performing task of the project.
 Lack of consideration of risks : Risks should be considered during project planning
and scheduling; otherwise it becomes difficult for project management team to prevent
their effect during software development.
 Software Engineering (MU) 1-127 Introduction

 Lack of proper communication among team members : Sometimes, there is no

proper communication among the project management team members to resolve the
problem occurring during the software development. This in turn makes it difficult for
the project management team to understand and develop the software according to user
requirements and schedule.
 Difficulties of team members : Software projects can also be delayed due to unforeseen
difficulties of the team members. For example, some of the team members may require
leave for personal reasons.
 Lack of action by project management team : Sometime, project management team
does not recognize that the project is getting delayed. Thus, they do not take the
necessary actions to speed up the software development process and complete it on time.
Generally, the task of assigning the end date is done by the project sponsor or the user.
While preparing the project schedule, the project manager assists the project sponsor by
providing information about the project scope, deliverables and resources. In addition, the
project manager provides an estimate of the time to be consumed to complete project tasks.
Preparing an accurate project schedule is a difficult task and requires thorough knowledge
about the processes and time consumed to perform them. Once the project schedule is fixed,
the project manager is responsible for monitoring the progress of the project. If there is a
need to revise the project schedule, the project manager communicates with the project
management team members

1.18.2 Principles of Project Scheduling

To carry out project scheduling appropriately, some principles are followed. These
principles help the project management team to prepare the project schedule. The commonly
followed principles are :
 Compartmentalization : Divides the project into several tasks. The purpose of
compartmentalization is to make the project manageable. Thus, it becomes easier to
prepare the project schedule according to these tasks.
 Interdependency : Determines the interdependency of one or more activities or tasks on
each other. All the activities of the project are not interdependent. There are various
activities that are performed sequentially, whereas some of the activities are executed
together with other activities. On the other hand, some activities cannot begin until the
activity on which they are dependent to complete.
 Software Engineering (MU) 1-128 Introduction

 Time allocation : Determines the time to be allocated to each project management team
member for performing specified activities. However, before allocating time, it is
important to estimate the effort required by them to complete the assigned task. In
addition, the project management team members should.
 Effort validation : Ensures that the effort required to perform the assigned tasks are
valid. In other words, it should verify that the task allocated to one or more project
management team members is according to the effort required for each task. This is
because every project management team has a defined number of team members. Hence,
the project manager should allocate the tasks according to the effort and time required to
complete task.
 Defined responsibilities : Specify the roles and responsibilities of every project
management team member. Hence, the tasks should be allocated according to the skills
and abilities of team members to perform the assigned task.
 Defined outcomes : Specify the outcomes of every task performed by the project
management team members. The outcome is achieved after completion of a task.
Generally, then outcome of a task is in the form of a product and these products are
combined in deliverables.
 Defined milestone : Specify the milestones when work products are compete and
reviewed for quality.

1.18.3 Milestones

Milestones are formal representations of the progress of a project. Generally,

milestones are planned when the deliverables are provided. Milestones describe the end-
point when software process activity is completed. After completion of a milestone, its
output is described in the form of document. This document comprises information about the
completion of a phase of the project. Note that these documents are used as references for
the project management tea only and are not delivered to the user.
It is difficult o keep in mind all the tasks being performed during software
development. Hence, each task is recorded in documents, which describe the work being
done in that phase. With the help of thee documents, it becomes easy for project manager to
check the status of the project. In addition, milestones have several advantages :
 They avoid losing control of the project according to schedule.
 They help in completing the project according to allocated budget.
 They report status of the project to the management.
 Software Engineering (MU) 1-129 Introduction

Fig. 1.31 shows examples of milestones in requirements and design phases of the
project. ‘Milestone 1’, ‘Milestone 2’, and ‘Milestone 3’ represent the completion of tasks in
requirements phase. Similarly, ‘Milestone 4’, ‘Milestone 5’, ‘Milestone 6’, and ‘Milestone
7’ represent completion of tasks in design phase. Each milestone represents the completion
of a specific task. For example, ‘Milestone 1’ represents completion of feasibility study and
‘Milestone 2’ represents completion of requirement definition. Similarly, in the design
phase, ‘Milestone 4’ represents completion of architectural design and so on.
Requirements Design
Feasibility study Architectural design
Milestone 1 Milestone 4
Outline requirements Interface design
definition
Milestone 2 Milestone 5
Design study Formal specification
Milestone 3 Milestone 6
Requirements Detailed design
specification
Milestone 7
Implementation
Fig.1.33 : Milestones

In project scheduling, there are several aspects that are important to be considered.
These include techniques of project scheduling, task network, and tracking the schedule.
Techniques of project scheduling focus on checking the activities that re completed
according to project schedule. In addition, these techniques describe the information about
activities in graphical form so that it is easy for a project management team to understand the
time and effort required for each activity. Task network focuses on how the entire software
project can be broken into several manageable tasks, which are understandable by the project
management team. Tracking the schedule focuses on finding ways to complete the project
according to the schedule.
1. Define a set of task to be completed - WBS TOOL
2. Build a task network - CPM TOOL
 Software Engineering (MU) 1-130 Introduction

3. Identify the critical path- use CPM

4. Determine completion date from Gannt chart
5. Track the schedule with a project table
6. Conclusion
7. Review
We will see study some of them in section 1.18.7

Project table format

Sr. Activities Planned Actual Planned Actual Name of Effort Any

No. that need to start start completed completed the team they additional
be time time members allocated notes
completed

Why the schedule is independent of the person-month cost ?

 A schedule cannot be simply obtained from the overall effort estimate by deciding on
average staff size and then determining the total time requirement by dividing the total
effort by the average staff size.
 Person and months (time) are not interchangeable.
In a project, the scheduling activity can be broken into two subactivities :
 Determining the overall schedule (the project duration) with major milestones,and
 Developing the detailed schedule of the various tasks.

1.18.4 Overall Scheduling (Average Duration Estimation)

Schedule is modeled as depending on the total effort (which, in turn depends on size).
The constants for the model are determined from the historical data.
In COCOMO, the schedule is determined as,
d
Development Time M = C b ( Effort _ Applied ) b [months] ]

The equation for organic type of software is

0.38
M = 2.5 * E
It should be clear that schedule is not a function solely of effort.
 Software Engineering (MU) 1-131 Introduction

One rule of thumb, called the square root check, is sometimes used to check the
schedule of medium-sized projects. The proposed schedule can be around the square root of
the total effort in person-months. For example, if the effort estimate is 50 person-months, a
schedule of about 7 to 8 months will be suitable.
The duration or schedule of the different phases is obtained in the same manner as in
effort distribution. The percentages for the different phases are given in Tables 1.18, 1.20
and 1.22.
Once we have the estimates of the effort and time requirement for the different phases,
a schedule for the project can be prepared. This schedule will be used later to monitor the
progress of the project. Look the following sample “Summary milestone schedule”
Table 1.24 for a better understanding of this :
Table 1.24 : Summary milestone schedule

08- 09- 10- 11- 12- 01- 02- 03- Post

2010 2010 2010 2010 2010 2010 2010 2010 project

Project Management
Meeting
Project Steering Group
Meeting
Agree piloting and
evaluation criteria
Early trial of functions
and feature sets with
pilot group
Develop initial version
of V-MAP desktop tool
for alpha testing
Trial functions and
alpha test with pilot
groups
Feedback to Developer
alpha
Consultancy with
Standards expert
 Software Engineering (MU) 1-132 Introduction

08- 09- 10- 11- 12- 01- 02- 03- Post

2010 2010 2010 2010 2010 2010 2010 2010 project

Consultancy with
moodle.com
Develop beta version of
desktop tools
Trial functions and beta
code with pilot groups
Feedback to Developer
beta
Produce release
candidate code
including
documentation
Final testing of code
before release to
community
Piloting of tools
Evaluation of Project
Dissemination of tools
through workshop and
other channels
Production and
maintenance of website
Production of reports as
required by JISC

Example Continued

We continue with the office automation example. Recall that the overall size estimates
for the project is 3KDLOC, and the final effort estimate obtained was 16.34 PM.
As this is an organic system, the overall duration will be determined by equation
0.38
2.5 * E .
Using this we get the project duration D as,
0.38
D = 2.5 * 16.34 = 7.23 months
 Software Engineering (MU) 1-133 Introduction

Using the preceding table, which gives the duration of the different phases as a
percentage of the total project duration, we can obtain the duration of the different phases.
The duration of the different phases is :
System Design : 0.19 * 7.23 = 1.37 M
Programming : 0.623 * 7.23 = 4.5 M
Integration : 0.1866 * 7.23 = 1.35 M
If the project is to start on January 1, then according to this, the project will end in the
middle of August.
The system design phase will terminate in the middle of February,
The programming activity will end in late June, and
Rest of the time will be spent in integration and testing.
Using these techniques, an overall schedule for the project can be decided.

Staffing and Personnel planning

From the cost and overall duration of the project, the average staff size for the project
can be determined by dividing the total effort (in person-months) by the overall project
duration (in months)
The staff requirement for a project is small during requirement and design, the
maximum during implementation and testing, and drops again during the final phases of
integration and testing.
Using the COCOMO model, average staff requirement for the different phases can be
determined as the effort and schedule for each phase are known. This presents staffing as a
step function with time as shown in Fig 1.34.

Fig. 1.34 : Manpower ramp-up in a typical project

 Software Engineering (MU) 1-134 Introduction

1.18.5 Detailed Scheduling

 For detailed schedules, the major tasks fixed while planning the milestones are broken
into small schedulable activities in a hierarchical manner. For example, the detailed
design phase can be broken into tasks for developing the detailed design for each
module, review of each detailed design, fixing of defects found, and so on.
 For each detailed task, the project manager estimates the time required to complete it
and assigns a suitable resource so that the overall schedule is met.
 If this detailed schedule is not consistent with the overall schedule and effort estimates,
the detailed schedule must be changed.
 If it is found that the best detailed schedule cannot match the milestone effort and
schedule, then the earlier estimates must be revised. Thus, scheduling is an iterative
process.
 For detailed scheduling, tools like Microsoft Project or a spreadsheet can be very useful.
 For each lowest-level activity, the project manager specifies the effort, duration, start
date, end date, and resources.
 Dependencies between activities, due either to an inherent dependency (for example,
you can conduct a unit test plan for a program only after it has been coded) or to a
resource-related dependency (the same resource is assigned two tasks) may also be
specified.
 A detailed project schedule is never static - Changes are done as and when the need
arises.
 The detailed schedule becomes the main document that tracks the activities and
schedule.

1.18.6 An Example

 The overall effort estimate for this project is 501 person-days, or about 24 person-
months.
 This estimation was done using the bottom-up approach discussed earlier.
 The customer gave approximately 5.5 months to finish the project.
 Because this is more than the square root of effort in person-months, this schedule was
accepted.
 Table 1.25 shows the high level schedule of the project.
 Software Engineering (MU) 1-135 Introduction

 This project uses a process in which initial requirement and design is done in two
iterations and the development is done in three iterations. The overall project duration
with these milestones is 140 days.
 This high-level schedule is not suitable for assigning resources and detailed planning.
 During detailed scheduling, these tasks are broken into schedulable activities.
 Table 1.26 shows part of the detailed schedule of the construction-iteration 1 phase of
the project.
 For each activity, the table specifies the activity by a short name, the module to which
the activity is contributing, and the duration and effort.
 For each task, how much is completed is given in the % complete column. This
information is used for activity tracking.
 The detailed schedule also specifies the resource to which the task is assigned (specified
by initials of the person.)
 Sometimes, the predecessors of the activity (the activities upon which the task depends)
are also specified. This information helps in determining the critical path and the critical
resources.
Table 1.25 : High-level schedule for the project

Task Duration Work (Person- Start End

(days) days) date date
Project initiation 33.78 24.2 5/4/00 6/23/00
Regular activities 87.11 35.13 6/5/00 10/16/00
Training 95.11 49.37 5/8/00 9/29/00
Knowledge sharing tasks 78.22 19.56 6/2/00 9/30/00
Inception phase 26.67 22.67 4/3/00 5/12/00
Elaboration Iteration 1 27.56 55.16 5/15/00 6/23/00
Elaboration Iteration 2 8.89 35.88 6/26/00 7/7/00
Construction Iteration 1 8.89 24.63 7/10/00 7/21/00
Construction Iteration 2 6.22 28.22 7/20/00 7/28/00
Construction Iteration 3 6.22 27.03 7/31/00 8/8/00
Transition phase 56 179.62 8/9/00 11/3/00
Back-end work 4.44 6.44 8/14/00 8/18/00
 Software Engineering (MU) 1-136 Introduction

Table 1.26 : Portion of the detailed schedule

Module Task Duration Effort Start End % Resource

(days) (days) date date done
– Requirements 8.89 1.33 7/10 7/21 100 bb, bj
– Design review 1 0.9 7/11 7/12 100 bb, bj, sb
– Rework 1 0.8 7/12 7/13 100 bj, sb
History Coding 2.67 1.87 7/10 7/12 100 hp
History Review UC17 0.89 0.27 7/14 7/14 100 bj, dd
History Review UC19 0.89 0.27 7/14 7/14 100 bj, dd
History Rework 0.89 2.49 7/17 7/17 100 dd, sb, hp
History Test UC17 0.89 0.62 7/18 7/18 100 sb
History Test UC19 0.89 0.62 7/18 7/18 100 hp
History Rework 0.89 0.71 7/18 7/18 100 bj, sb, hp
Config. Reconciliation 0.89 2.49 7/19 7/19 100 bj, sb, hp
Mgmt. Tracking 7.11 2.13 7/10 7/19 100 bb
Quality Analysis 0.89 0.62 7/19 7/19 100 bb

1.18.7 Techniques used in Scheduling

1.18.7.1 What is a WBS chart ?

WBS-Work Breakdown Structure

One of the first tasks is to break the large tasks into small tasks. It means identifiable
parts of the tasks. It also means finding deliverables and milestones that can be used to
measure progress.
The work breakdown structure (WBS) should be a tree structure. The top level
breakdown usually matches the life cycle model (LCM) used in organization. The next level
break down can match the progress in the task into smaller, more manageable tasks.
The following are rules for constructing a proper work breakdown structure :
1. The WBS must be a tree structure : There should be no loops or cycles in the WBS.
Iterative actions will be shown in the process model and/or the life cycle model.
 Software Engineering (MU) 1-137 Introduction

2. Every task and deliverable description must be understandable and

unambiguous : The purpose of a WBS is communication with team members
misinterpret what the task or deliverable is supposed to be, there will be problem.
3. Every task must have a completion criterion (often a deliverable) : There must be
a way to decide when a task is completed, because sub tasks that have no definite
ending encourage false expectations of progress. This description is called a
completion criterion. It may be a deliverable, for example, a complete design for
project, and then a peer review can decide if it is complete.
4. All deliverables (artifacts) must be identified : A deliverable must be produced by
some task or it won’t be produced.
5. Positive completion of the whole task : The purpose of the work break down
schedule is to identify the subtask necessary to complete the whole task. If important
tasks or deliverables are missing, the whole task will not be accomplished.

Fig. 1.35 : Work Breakdown Structure

1.18.7.2 Sequence the Work Activities .MU - Dec. 08, Dec. 09.

 Milestone Chart
 Gantt chart
 Software Engineering (MU) 1-138 Introduction

 Network Techniques
o CPM (Critical Path Method)
o PERT (Program Evaluation and Review Technique)

A. Gantt Chart

 Gantt chart is a means of displaying simple activities or events plotted against time or
dollars.
 Most commonly used for exhibiting program progress or for defining specific work
required to reach an objective.
 Gantt charts may include listing of activities, activity duration, scheduled dates, and
progress-to-date.

Fig. 1.36 : Gantt Chart

Advantages

 Easy to understand.
 Easy to change.
 Software Engineering (MU) 1-139 Introduction

Disadvantages

 Only a vague description of the project.

 Does not show interdependency of activities.
 Cannot show results of an early or late start of an activity.

B. Network techniques

 A precedence network diagram is a graphic model portraying the sequential relationship

between key events in a project.
 Initial development of the network requires that the project be defined and thought out.
 The network diagram clearly and precisely communicates the plan of action to the
project team and the client.

B.1 Activity Networks

In order to be able to use Critical Path Analysis, you first need to be able to form what
is called an activity network. This is essentially a way of illustrating the given project data
concerning the tasks to be completed, how long each task takes and the constraints on the
order in which the tasks are to be completed. As an example, consider the activities shown
below for the construction of a garage.
Activity Duration (in days)
A Prepare foundations 7
B Make and position door frame 2
C Lay drains, floor base and screed 15
D Install services and fittings 8
E Erect walls 10
F Plaster ceiling 2
G Erect roof 5
H Install door and windows 8
I Fit gutters and pipes 2
J paint outside 3
 Software Engineering (MU) 1-140 Introduction

Clearly, some of these activities cannot be started until other activities have been
completed. For example
Activity G – erect roof

cannot begin until

activity E – erect walls

The following table shows which activities must precede which has been completed.

D must follow E

E must follow A and B

F must follow D and G

G must follow E

H must follow G

I must follow C and F

J must follow I.
We call these the precedence relations.
All this information can be represented by the network shown below

In this network each activity is represented by a vertex; joining vertex X to vertex Y

shows that activity X must be completed before Y can be started.
 Software Engineering (MU) 1-141 Introduction

The number marked on each are shows the duration of the activity from which they
starts.
Note the use of ‘arc’ here to mean a directed edge. Sometimes we can easily form the
activity network, but not always, so we need to have a formal method. First try the following
activity.

B.1.1 Algorithm for constructing activity networks

For simple problems it is often relatively easy to construct activity networks but, as
the complete project becomes more complex, the need for a formal method of constructing
activity networks increase. Such an algorithm is summarised below.
Start Write down the original vertices and then a second copy
of them alongside, as illustrated on the right. If activity
Y must follow activity X draw an arc from original
vertex Y to shadow vertex X. (In this way you construct
a bipartite graph.)
Step 1 Make a list of all the original vertices which have no
arcs incident to them.
Step 2 Delete all the vertices found in step 1 and their
corresponding shadow vertices and all arcs incident to
these vertices.
Step 3 Repeat step 1 and 2 until all the vertices have been used.
The use of this algorithm will be illustrated using the first case study, constructing a
garage, from Section B.1.
The precedence relations are :
D must follow E
E must follow A and B
F must follow D and G
G must follow E
H must follow G
I must follow C and F
J must follow I
These are illustrated opposite.
 Software Engineering (MU) 1-142 Introduction

Applying the algorithm until all vertices have been chosen is shown below

Step 1 : Original vertices with no arcs

Step 2 : Delete all arcs incident on A, B , C and redraw as shown
Step 3 : Repeat iteration

Step 1 : Original vertices with no arcs

Step 2 : Delete all arcs incident on E and redraw as shown
Step 3 : Repeat iteration

Step 1 : Original vertices with no arcs

Step 2 : Delete all arcs incident on D, G and redraw as shown
Step 3 : Repeat iteration

Step 1 : Original vertices with no arcs

Step 2 : Delete all arcs incident on F, H and redraw as shown
Step 3 : Repeat iteration

Step 1 : Original vertices with no arcs

Step 2 : Delete all arcs incident on I and redraw as shown

Step 3 : Step as all vertices have been chosen

So the vertices have been chosen in the following order :

A
D F
B E I J
G H
C
 Software Engineering (MU) 1-143 Introduction

The activity diagram as shown below can now be drawn.

From the ‘start’ vertex, draw arcs to A, B and C, the first iteration vertices, putting
zero on each arc. In the original bipartite graph the shadow vertex A was joined to the
original vertex E – so join A to E. Similarly join B to E and C to I.
Indicate the duration of the activity on any arc coming from the vertex representing
the activity.
Continue in this way and complete the activity network with a ‘finish’ vertex into
which any free vertices lead, again indicating the duration of the activity on the arc.
Note that the duration of the activity is shown on every arc coming from the vertex
representing the activity. (So, for example, arc ED and arc EG are both given 10.)

Fig. 1.37 : PERT Chart

 Software Engineering (MU) 1-144 Introduction

B.2 PERT Chart

The program evaluation and review technique (PERT) chart is used to schedule,
organize, and coordinate tasks within the project. The objective of PERT chart is to
determine the critical path, which comprises critical activities that should be completed on
schedule. This chart is prepared with the help of information generated in project planning
activities, such as estimation of effort, selection of suitable process model for software
development, and decomposition of tasks into subtasks. The advantages of using PERT chart
are :
 It represents the project in graphical form.
 It provides information about the expected completion time of the project.
 It describes the probability of completion of project before the specified date.
 It specifies the activities that form the critical path.
 It specifies the start and end dates of activities involved in project.
 It describes the dependencies of one or more tasks on each other.
Figure shows example of PERT chart. The milestones are numbered as 1, 2, 3, 4,
and 5 and are represented either by circles or rectangles. When a milestone is completed, it
is assigned a greater number than the previous milestones. Each milestone is linked with one
or more arrows. The activities of the projects are represented by A, B, C, D, E, and F.
The direction of arrows determines the sequence of activities. When activities are completed
in sequence, they are known as serial activities. Here activities A, C, F are performed in a
sequence. Similarly, activities B, E are serial activities. On the other hand when two or
more activities are being performed simultaneously, they are known as concurrent activities
or parallel activities. Here, activities A, B and activities C, D are performed concurrently.
Each activity is allocated a specific amount of time, which is depicted by t. Here activity A
requires three week to get completed, activity B requires for weeks, and so on.

Fig. 1.38(a) : Pert chart Fig. 1.38(b) : PERT Chart

 Software Engineering (MU) 1-145 Introduction

To create PERT chart follow the steps listed below :

1. Identify activities and milestones : In this step, the activities and milestones that are
required to complete the project are described. Once the tasks and milestones are
specified, it is easy to understand the sequence and duration of each activity.
2. Identify sequence of activities : In this step, the sequence of activities is determined.
The sequence describes the dependency of one activity on another. These activities
can either be serial or concurrent. Based on the sequence and dependency of activities,
the relationships among activities are depicted. Note that this step is sometimes
combined with step 1.
3. Prepare PERT chart : In this step, the PERT chart is prepared.
4. Estimate the time consumed in activities : In this step, the amount of time consumed
in carrying out each activity is specified. The time can be estimated in months, weeks,
or days. Generally, the time estimates followed to determine the time consumed in
activities are :
a) Optimistic time : It is the shortest time in which an activity can be completed.
b) Most likely time : It is the completion time having the highest probability.
c) Pessimistic time : It is the longest time that an activity may require for
completion.
5. Determine critical path : In this step, the critical path for completion of activities is
specified. Critical path determines the calendar time required to complete a series of
activities according to the project schedule. Note that the speed-up or delays in
activities that are outside the critical path do not affect the total project time.
6. Update PERT chart : In this step, the PERT char is modified as changes takes place
in the project and on completion of each activity. This chart is also updated when
there is delay in completion of activities or when additional resources are required to
complete the project on time.

B.3 CPM

Critical Path Method (CPM) tries to answer the following questions :

1. What is the duration of the project ?
2. By how much (if at all) will the project be delayed if any one of the activities takes N
days longer ?
3. How long can certain activities be postponed without increasing the total project
duration ?
 Software Engineering (MU) 1-146 Introduction

Critical Path Method (CPM)

Critical path method is a technique that determines those activities, which have the
least scheduling flexibility (that is, critical activities). Note that if the critical activities are
delayed, the entire project is delayed. After determining these activities, CPM specifies the
project schedule according to the activities that lie on the critical path.
The advantages of using the critical path method are :
 It represents the project in graphical form.
 It predicts the time required to complete the project.
 It specifies the critical activities.
 It specifies how to speed up the project so that it is completed on schedule.
 It specifies the optimal plan for speeding up the project.
You have seen how to construct an activity network. In this section you will see how
this can be used to find the critical path. This will first involve finding the earliest possible
start for each activity, by going forwards through the network. Secondly, the latest possible
start time for each activity is found by going backwards through the network. Activity
which have equal earliest and latest start time are on the critical path. The technique will be
illustrated using the ‘garage construction’ problem from section B.1 and B.1.1.

The activity network for this problem is shown below, where sufficient space is made
at each activity node to insert two numbers.
The numbers in the top half of each circle will indicate the earliest possible starting
time. So, for activities A, B and C, the number zero is inserted.
 Software Engineering (MU) 1-147 Introduction

Moving forward through the network, the activity E is reached next. Since both A and
B have to be completed before E can be started, the earliest start time for E is 7. This is put
into the top half of the circle at E. The earliest times at D and G are then both 17, and for H
22. Since F cannot be started until both D and G are completed, its earliest start time is 25
and consequently 27 for I. The earliest start time for J is then 29, which gives an earliest
completion time of 32.

Since 32 is the earliest possible completion time, it is also assumed to be the

completion time in order to find the latest possible start time. So 32 is also put in the lower
half of the ‘finish’ circle. Now working backwards through the network, the latest start times
for each activity are as follows :
J 32 – 3 = 29
I 29 – 2 = 27
F 27 – 2 = 25
H 32 – 8 = 24
D 25 – 8 = 17
G the minimum of 25 – 5 = 20 and 24 – 5 = 19
E the minimum of 17 – 10 = 7 and 19 – 10 = 9
A 7–7=0
B 7–2=5
C 27 – 15 = 12
This gives a completed network as shown below.
 Software Engineering (MU) 1-148 Introduction

The vertices with equal earliest and latest starting times define the critical path. This
is clearly seen to be
AEDFIJ
Another way of identifying the critical path is to define the
Float time = latest start time – earliest start time
The information for the activities can now be summarised in the table below.
Start time
Activity Earliest Latest Float
A 0 0 0 
B 0 5 5
C 0 12 12
E 7 7 0 
D 17 17 0 
G 17 19 2
F
25
25
0 
H 22 24 2
I 27 27 0 
J 29 29 0 
So now you know that if there are enough workers the job can be completed in
32 days. The activities on the critical path (i.e. those with zero float time) must be started
punctually; for example. A must start immediately, E after 7 days, F after 25 days etc. For
 Software Engineering (MU) 1-149 Introduction

activities with a non zero float time there is scope for varying their start times; for example
activity G can be started any time after 17, 18 or 19 days work. Assuming that all the work is
completed on time, you will see that this does indeed give a working schedule for the
construction of the garage in the minimum time of 32 days.

1.18.7.3 PERT vs. CPM

 The difference between CPM and PERT are not fundamental, but merely of viewpoint
 CPM emphasizes activities; PERT is event oriented
 CPM uses arcs to represent activities; PERT uses node to specify events
 PERT permits explicit treatment of probability for its time estimated; CMP does not
 PERT is better suited to projects of high uncertainty; CPM is better suited to well
defined project with little uncertainty
1.19 Risk Management Planning
.MU - May 04, Oct. 04, June 05, Nov. 05, Nov. 06,
May 07, Nov. 07, May 08, Dec. 08, Dec. 09, June 10(Old).

Fig. 1.39 : Risk management activities

Risk management deals with events that are infrequent, somewhat out of the control of
the project management, and which can have a major impact on the project.
It should be clear that risk management has to deal with identifying the undesirable
events that can occur, the probability of their occurring, and the loss if an undesirable event
does occur. Once this is known, strategies can be formulated for either reducing the
probability of the risk materializing or reducing the effect of risk materializing. So the risk
management revolves around risk assessment and risk control. For each of these major
activities, some subactivities must be performed. A breakdown of these activities is given in
Fig. 1.39.

1.19.1 Risk Analysis .MU - May 08.

Risk = probability that some adverse circumstances will actually occur.

 Software Engineering (MU) 1-150 Introduction

Reactive vs. Proactive Risk

1. Reactive risk strategies

a) Software team does nothing about risks until something goes wrong.
b) Then team flies into action in an attempt to correct the problem rapidly. This is
often called as “Fire fighting mode”.
c) When this fails, “Crisis management” takes over and the project is in real
jeopardy.
2. Proactive risk strategies
a) Begins long before technical work is initiated. Potential risks are identified, their
probability and impact are assessed, and they are ranked by their importance.
b) Then software team establishes a plan for managing risk.
Risk always involves two characteristics
1. Uncertanity : The risk may or may not happen, i.e. there are no 100% probable risks.
2. Loss : If risk becomes a reality, unwanted consequences or losses will occur. The loss
is not only the direct financial loss that might be incurred but also any loss in terms of
credibility, future business, and loss of property or life.
A risk i.e. 100% probable is a constraint on software project.
Risk analysis in the planning phase is the part of risk management of the whole
project. It consist of four activities :
1. Threat identification
2. Assessment of the risk value (probability of the threat and its consequences)
3. Risk prioritizing
4. Risk proceeding with several strategies
Threat here means some unwanted situation with negative consequences to the
project. The examples may be the budget overdrive or the impossibility to hold the schedule.
The threat identification may be based on :
 Objectives analysis : The threats are concerned with impossibility to reach the project
goals
 Scenario analysis : It may determine the bottleneck stages in the development process.
 Taxonomy analysis : The whole software taxonomy is divided into three classes:
Product Engineering, Development Environment and Program Constraints. These
classes are further divided into elements and each element is characterized by its
attributes. The Taxonomy-Based Questionnaire (TBQ) is used to determine the issues
with some elements and their attributes.
 Software Engineering (MU) 1-151 Introduction

 Common-risk checking : When lists with known risks are available.

What types of risks are we likely to encounter as software is built ?

Risk Threats Identify Consequences

1. Project Project plan Potential budgetary, schedule, Project schedule will
personnel (staffing and slip and that costs will
organization), resource, increase
customer, and requirement
problems and their on an
software project.
2. Technical Quality and Potential design Implementation may
or timeliness of implementation, interface, become difficult or
Product software to be verification, and maintenance impossible;
produced problems; Quality or
Specification ambiguity, performance of
technical uncertainty, technical product decrease.
obsolescence
3. Business Viability of (i) Market Risk : Building a Often jeopardize the
software to be excellent product or system that project or product.
built no one really wants.
(ii)Strategic Risk : Building a
product that no longer fits into
overall business strategy for
company.
(iii)Management Risk : Losing
support of senior management
due to a change in focus or a
change in focus or a change in
people.
(iv) Budget Risk : Losing
budgetary or personnel
commitment.
(v) Building a product that the
sales force doesn’t understand
how to sell.
 Software Engineering (MU) 1-152 Introduction

Another classification of Risk

 Known : That can be uncovered after careful evaluation of project plan, business and
technical environment in which project is being developed and other reliable
information sources.
o e.g. : Unrealistic delivery date, lack of documentations, requirements or software
scope, poor development environment.

 Predictable : Are extrapolated from past project experience.

o e.g. : Staff turnover, poor communication with customer.
 Unpredictable : Extremely difficult to identify in advance.

What is a risk ?

 You’ve carefully planned out a project :

o The customer supplied you the user’s requirements.

o Estimated 5 developers could develop the software in 6 months.
o Placed subcontractor on contract to deliver the test environment.
 What could go wrong ?
o All 5 developers may not be available.
o May get assigned developers than expected (and take longer than you expected).
o Developed may not be as productive as expected(and take longer than you
expected).

o The subcontractor may deliver later.

o The subcontractor may not deliver what you expected.
o The requirements may not be complete or consistent.
o The customer may not have supplied the real user’s requirements, etc….
Note : The main sources of risks came from Pressman 1997 and construx.com.
 Software Engineering (MU) 1-153 Introduction

Proactive approach to risk

A series of activities :
 Identification of risks using checklists and corporate databases.
o e.g. Pressman’s checklists
 Analysis of risks to see how they affect the project
o Impact - Catastrophic, critical, marginal, negligible
o Driver - performance, support, cost, schedule
 Risk prioritisation by rating
o Probability
o Impact
 Planning for the likely, high impact risks :
o Avoid
o Control - plan, monitor, resolve

1.19.2 Risk Identification

Risk identification is a systematic attempt to specify threats to the project plan

(estimates, schedule, resource loading, etc.). By identifying known and predictable risks, the
project manager takes a first step toward avoiding them when possible and controlling them
when necessary.
There are two distinct types of risks for each of the categories that have :
Generic risks and product-specific risks.
Generic risks are a potential threat to every software project.
Product-specific risks can be identified only by those with a clear understanding of
the technology, the people, and the environment that is specific to the project at hand.
To identify product-specific risks, the project plan and the software statement of scope
are examined and an answer to the following question is developed : “What special
characteristics of this product may threaten our project plan ?”
One method for identifying risks is to create a risk item checklist. The checklist can
be used for risk identification and focuses on some subset of known and predictable risks in
the following generic subcategories :
 Product size : Risks associated with the overall size of the software to be built or
modified.
 Software Engineering (MU) 1-154 Introduction

 Business impact : Risks associated with constraints imposed by management or the

marketplace.
 Customer characteristics : Risks associated with the sophistication of the customer and
the developer’s ability to communicate with the customer in a timely manner.
 Process definition : Risks associated with the degree to which the software process has
been defined and is followed by the development organization.
 Development environment : Risks associated with the availability and quality of the
tools to be used to build the product.
 Technology to be built : Risks associated with the complexity of the system to be built
and the “newness” of the technology that is packaged by the system.
 Staff size and experience : Risks associated with the overall technical and project
experience of the software engineers who will do the work.
The risk item checklist can be organized in different ways. Questions relevant to each
of the topics can be answered for each software project. The answers to these questions
allow the planner to estimate the impact of risk. A different risk item checklist format simply
lists characteristics that are relevant to each generic subcategory. Finally, a set of “risk
components and drivers” are listed along with their probability of occurrence. Drivers for
performance, support, cost, and schedule are discussed in answer to later questions.

Risk item checklist

Product size risks

 Estimated size of the product in LOC or FP ?
 Degree of confidence in estimated size estimate ?
 Estimated size of product in number of programs, files, transactions ?
 Percentage deviation in size of product from average for previous products ?
 Size of database created or used by the product ?
 Number of users of the product ?
 Number of projected changes to the requirements for the product ? Before delivery ?
After delivery ?
 Amount of reused software ?
Business impact risks
 Affect of this product on company revenue ?
 Visibility of this product by senior management ?
 Software Engineering (MU) 1-155 Introduction

 Reasonableness of delivery deadlines ?

 Number of customers who will use this product and the consistency of their needs
relative to the product ?
 Number of other products/systems with which this product must be interoperable ?
 Sophistication of end users ?
 Amount and quality of product documentation that must be produced and delivered to
the customer ?
 Governmental constraints on the construction of the product ?
 Costs associated with late delivery ?
 Costs associated with a defective product ?
Customer related risks
 Have you worked with the customer in the past ?
 Does the customer have a solid idea of what is required ?
 Has the customer taken the time to write this down ?
 Will the customer agree to spend time in formal requirements gathering meetings to
identify project scope ?
 Is the customer willing to establish rapid communication links with the developer ?
 Is the customer willing to participate in reviews ?
 Is the customer technically sophisticated in the product area ?
 Is the customer willing to let your people do their job that is, will the customer resists
looking over your shoulder during technically detailed work ?
 Does the customer understand the software engineering process ?
Development environment risks
 Is a software project management tool available ?
 Is a software process management tool available ?
 Are tools for analysis and design available ?
 Do analysis and design tools deliver methods that are appropriate for the product to be
built ?
 Are compilers or code generators available and appropriate for the product to be built ?
 Are testing tools available and appropriate for the product to be built ?
 Are software configuration management tools available ?
 Does the environment make use of a database or repository ?
 Software Engineering (MU) 1-156 Introduction

 Are all the software tools integrated with one another ?

 Have members of the project teams received training in each of the tools ?
 Are local experts available to answer questions about the tools ?
 Is on-line help and documentation for the tools adequate ?
Process issue risks
 Does your senior management support a written policy statement that emphasizes the
importance of a standard process for software development ?
 Has your organization developed a written description of the software process to be used
on this project ?
 Are staff members signed-up to the software process as it is documented and willing to
use it ?
 Is the software process used for other projects ?
 Has your organization developed or acquired a series of software engineering training
courses for managers and technical staff ?
 Are published software engineering standards provided for every software developer and
software manager ?
 Have document outlines and examples been developed for all deliverables defined as
part of the software process ?
 Are formal technical reviews of the requirements specification, design, and code
conducted regularly ?
 Are formal technical reviews of test procedures and test cases conducted regularly ?
 Are the results of each formal technical review documented, including defects found and
resources used ?
 Is there some mechanism for ensuring that work conducted on a project conforms with
software engineering standards ?
 Is configuration management used to maintain consistency among system/software
requirements, design, code, and test cases ?
 Is a mechanism used for controlling changes to customer requirements that impact the
software ?
 Is there a documented statement of work, software requirements specification, and
software development plan for each subcontract ?
 Is a procedure followed for tracking and reviewing the performance of subcontractors ?
Staff size and experience

 Are the best people available ?

 Software Engineering (MU) 1-157 Introduction

 Do the people have the right combination of skills ?

 Are enough people available ?
 Are staff committed for entire duration of the project ?
 Will some staff be working only part time on this project ?
 Do staff have the right expectations about the job at hand ?
 Have staff received necessary training ?
 Will turnover among staff be low enough to allow continuity ?
Technical issue risks
 Are facilitated application specification techniques used to aid in communication
between the customer and developer ?
 Are specific methods used for software analysis ?
 Do you use a specific method for data and architecture designs ?
 Is more then 90% of your code written in a high order language ?
 Are specific conventions for code documentation defined and used ?
 Do you use a specific method for test case design ?
 Are software tools used to support software planning and tracking activities ?
 Are configuration management software tools used to control and track change activity
throughout the software process ?
 Are software tools used to support the software analysis and design process ?
 Are tools used to create software prototypes ?
 Are software tools used to support the testing process ?
 Are software tools used to support the production and management of documentation ?
 Are quality metrics collected for all software projects ?
 Are productivity metrics collected for all software projects ?
Technology risks
 Is the technology to be built new to your company ?
 Do the customer requirements demand the creation of new algorithms, input or output
technology ?
 Does the software interface with new or unproven hardware ?
 Does the software to be built interface with a database system whose function and
performance have not been proven in this application area ?
 Software Engineering (MU) 1-158 Introduction

 Does the software to be built interface with vendor supplied software products that are
unproven ?
 Is a specialized user interface demanded by product requirements ?
 Do requirements for the product demand the creation of program components that are
unlike any previously developed by your organization ?
 Do requirements demand the use of new analysis, design, or testing methods ?
 Do requirements demand the use of unconventional software development methods,
such as formal methods, AI-based approaches, artificial neural networks ?
 Do requirements put excessive performance constraints on the product ?
 Is the customer uncertain that the functionality requested is “do-able” ?
Other potential risks
 Schedule, resources, and product definition have all been dictated by the customer or
upper management and are not in balance.
 Schedule is optimistic, “best case”, rather than realistic, “expected case”.
 Schedule omits necessary tasks · Schedule was based on the use of specific team
members, but those team members were not available.
 Cannot build a product of the size specified in the time allocated.
 Product is larger than estimated (in lines of code, function points, or percentage of
previous project’s size).
 Effort is greater than estimated (per line of code, function point, module, etc.).
 Re-estimation in response to schedule slips is overly optimistic or ignores project
history.
 Excessive schedule pressure reduces productivity.
 Target date is moved up with no corresponding adjustment to the product scope or
available resources.
 A delay in one task causes cascading delays in dependent tasks, etc.

1.19.3 Assessing Overall Project Risk

Is the software project we’re working on at serious risk ?

The following questions have derived from risk data obtained by surveying
experienced software project managers. The questions are ordered by their relative
importance to the success of a project.
1. Have top software and customer managers formally committed to support the project ?
 Software Engineering (MU) 1-159 Introduction

2. Are end-users enthusiastically committed to the project and the system/product to be

built ?
3. Are requirements fully understood by the software engineering team and their
customers ?
4. Have customers been involved fully in the definition of requirements ?
5. Do end-users have realistic expectations ?
6. Is project scope stable ?
7. Does the software engineering team have the right mix of skills ?
8. Are project requirements stable ?
9. Does the project team have experience with the technology to be implemented ?
10. Is the number of people on the project team adequate to do the job ?
11. Do all customer/user constituencies agree on the importance of the project and on the
requirements for the system/product to be built ?
If any one of these questions is answered negatively, mitigation, monitoring and
management steps should be instituted without fail. The degree to which the project is at risk
is directly proportional to the number of negative responses to these questions.

1.19.4 Risk Components and Drivers

The project manager identify the risk drivers that affect software risk components
performance, cost, support, and schedule. In the context of this discussion, the risk
components are defined in the following manner :
 Performance risk : the degree of uncertainty that the product will meet its requirements
and be fit for its intended use.
 Cost risk : the degree of uncertainty that the project budget will be maintained.
 Support risk : the degree of uncertainty that the resultant software will be easy to
correct, adapt, and enhance.
 Schedule risk : the degree of uncertainty that the project schedule will be maintained
and that the product will be delivered on time.
The impact of each risk driver on the risk component is divided into one of four
impact categories negligible, marginal, critical, or catastrophic
 Software Engineering (MU) 1-160 Introduction

USAF risk components and drivers

Fig. 1.40 : Impact assessment

Referring to Fig. 1.40 a characterization of the potential consequences of errors (rows

labeled 1) or a failure to achieve a desired outcome (rows labeled 2) are described. The
impact category is chosen based on the characterization that best fits the description in the
table.

1.19.5 Risk Projection

Risk projection, also called risk estimation, attempts to rate each risk in two ways : the
likelihood or probability that the risk is real and the consequences of the problems associated
with the risk, should it occur. The project planner, along with other managers and technical
 Software Engineering (MU) 1-161 Introduction

staff, performs four risk projection activities :

(1) Establish a scale that reflects the perceived likelihood of a risk,
(2) Delineate the consequences of the risk,
(3) Estimate the impact of the risk on the project and the product, and
(4) Note the overall accuracy of the risk projection so that there will be no
misunderstandings.

1.19.6 Developing a Risk Table

Table 1.27 : Sample Risk Table

Risk Probability Severity Score Action to Manage Risk

(1-5) (1-5) (P×S)
Staffing
Project manager 1 2 2 Management documented,
leaves during Goldsmiths to manage risk.
lifetime of project Project manager part of team
within CELT, possibility of
simple handover within
Goldsmiths or consortium.
Long notice period likely to
limit risk and maximise
opportunities for managing
changeover
Project team leave 2 2 4 Activities shared within
or withdraw from Project team, to minimise risk.
Project activities Project not at risk from
individual withdrawal. Project
members subcontracted for
individual deliverables.
Software 2 4 8 Development using java means
Developer large pool of developers to
withdraws from draw from. Use of known
Project developers with excellent track
record likely to minimise risk.
Possible to sub-contract
 Software Engineering (MU) 1-162 Introduction

Risk Probability Severity Score Action to Manage Risk

(1-5) (1-5) (P×S)
development work out, or to
use alternative staff within
consortium (from Computer
Science Department).
Organisational
Project team fail to 2 4 8 Project evaluator involved
manage project from start to monitor project
effectively. processes and advise on
organisational failures. Project
members subcontracted for
individual deliverables.
Technical

Software fails 1 5 5 Tools built on existing

software licensed under open
source, using well established
technologies. Alpha and Beta
testing to minimise risk of
project failure. Development
using Java means large pool of
developers to draw from.

Software not IMS 2 4 8 Draw on expertise from CETIS

compliant SIG to advise on compliance
of software tools developed
External Suppliers
Fail to provide 1 3 3 Exposure to external suppliers
appropriate is for consultancy on linking
consultancy with institutional systems only.
The systems are built on well
documented open source
projects, that should limit the
 Software Engineering (MU) 1-163 Introduction

Risk Probability Severity Score Action to Manage Risk

(1-5) (1-5) (P×S)
impact of failure of delivery of
appropriate advice.
Legal
Software breaches 1 5 5 Tools built on existing
licensing software licensed under open
agreements source.
Table 1.28 : Risk Table

Risk Category Probability Impact RMMM

Customer will change requirements PS 80% 2 3.1
Lack of training on tools DE 80% 3 3.2
Less reuse than planned PS 70% 2
Size estimate may be significantly low PS 60% 2
Staff turnover will be high ST 60% 2
Delivery deadline will be tightened BU 50% 2
End users resist system BU 40% 3
Funding will be lost CU 40% 1
Technology will not meet expectations TE 30% 1
Staff inexperienced ST 30% 2
Large number of users than planned PS 30% 3
PS-Project size risk BU-business risk CU-customer etc.
Impact 1-catastrophic 2-critical 3-marginal 4-negligible
RMMM – Risk mitigation, monitoring and management plan
 The risk table should be implemented as a spreadsheet model. This enables easy
manipulation and sorting of the entries as shown in Table 1.28.
 A project team begins by listing all risks (no matter how remote) in the first column of
the table.
 This can be accomplished with the help of the risk item checklists. Each risk is
categorized in the second column (e.g., PS implies a project size risk, BU implies a
business risk).
 The probability of occurrence of each risk is entered in the next column of the table. The
probability value for each risk can be estimated by team members individually.
 Software Engineering (MU) 1-164 Introduction

Individual team members are polled in round-robin fashion until their assessment of risk
probability begins to converge.
 Next, the impact of each risk is assessed. Each risk component is assessed, and an
impact category is determined. The categories for each of the four risk components
performance, support, cost, and schedule are averaged to determine an overall impact
value.
 Once the first four columns of the risk table have been completed, the table is sorted by
probability and by impact. High-probability, high-impact risks percolate to the top of the
table, and low-probability risks drop to the bottom. This accomplishes first-order risk
prioritization.
 The project manager studies the resultant sorted table and defines a cutoff line. The
cutoff line (drawn horizontally at some point in the table) implies that only risks that lie
above the line will be given further attention. Risks that fall below the line are
re-evaluated to accomplish second-order prioritization.
 All risks that lie above the cutoff line must be managed. The column labeled RMMM
contains a pointer into Risk Mitigation, Monitoring and Management Plan or
alternatively, a collection of risk information sheets developed for all risks that lie above
the cutoff.
 Risk probability can be determined by making individual estimates and then developing
a single consensus value. Risk drivers can be assessed on a qualitative probability scale
that has the following values: impossible, improbable, probable, and frequent.
Mathematical probability can then be associated with each qualitative value (e.g., a
probability of 0.7 to 1.0 implies a highly probable risk).

1.19.7 Assessing Risk Impact

How do we assess the consequences of a risk ?

1. Determine the average probability of occurrence value for each risk component.
2. Determine the impact for each component based on the criteria shown.
3. Complete the risk table and analyze the results as described in the preceding sections.
The overall risk exposure (or sometimes called impact), RE, is determined using the
following relationship :
RE = PC
 Software Engineering (MU) 1-165 Introduction

where P is the probability of occurrence for a risk, and C is the cost to the project
should the risk occur.
Because both factors are difficult to estimate, only the discrete scale (e.g. five-point)
may be used. The effect of the assessment may be presented in the XY diagram, where one
axis stands for probability and the other stands for potential loss (Fig.1.41).

Fig. 1.41 : Risk assessment. (1 to 8) – identified threats, (I to V) – risk priorities

The RE is the expected value of the loss due to a particular risk. For risk prioritization
using RE, the higher the RE, the higher the priority of the risk item.
For example, assume that the software team defines a project risk in the following
manner :
 Risk identification : Only 70 percent of the software components scheduled for reuse
will, in fact, be integrated into the application. The remaining functionality will have to
be custom developed.
 Risk probability : 80% (likely).
 Risk impact : 60 reusable software components were planned. If only 70 percent can be
used, 18 components would have to be developed from scratch (in addition to other
custom software that has been scheduled for development). Since the 100 LOC and local
data indicate that the software engineering cost for each LOC is $14.00, the overall cost
(impact) to develop the components would be 18  100  14 = $25,200.
 Risk exposure : RE = 0.80  25,200 ~ $20,200.
 Software Engineering (MU) 1-166 Introduction

 Risk exposure can be computed for each risk in the risk table, once an estimate of the
cost of the risk is made. The total risk exposure for all risks (above the cutoff in the risk
table) can provide a means for adjusting the final cost estimate for a project. It can also
be used to predict the probable increase in staff resources required at various points
during the project schedule.
The project team should revisit the risk table at regular intervals, re-evaluating each
risk to determine when new circumstances cause its probability and impact to change. As a
consequence of this activity, it may be necessary to add new risks to the table, remove some
risks that are no longer relevant, and change the relative positions of still others.

1.19.8 Risk Assessment

At this point in the risk management process, we have established a set of triplets of
the form : [ri, li, xi] where ri is risk, li is the likelihood (probability) of the risk, and xi is the
impact of the risk.

Fig. 1.42 : risk referent level

In the context of software risk analysis, a risk referent level has a single point, called
the referent point or break point, at which the decision to proceed with the project or
terminate it (problems are just too great) are equally weighted.
Therefore, during risk assessment, we perform the following steps :
1. Define the risk referent levels for the project.
 Software Engineering (MU) 1-167 Introduction

2. Attempt to develop a relationship between each (ri, li, xi) and each of the referent
levels.
3. Predict the set of referent points that define a region of termination, bounded by a
curves or area of uncertainty.
4. Try to predict how compound combinations of risks will affect a referent level.

1.19.9 Risk Refinement

What is a good way to describe a risk ?

Represent the risk in condition-transition-consequence (CTC) format. That is, the risk
is stated in the following form :
Given that <condition> then there is concern that (possibly) <consequence>.
Using the CTC format for the reuse risk, we can write :
Given that all reusable software components must conform to specific design
standards and that some do not conform, then there is concern that (possibly) only 70 percent
of the planned reusable modules may actually be integrated into the as-built system,
resulting in the need to custom engineer the remaining 30 percent of components.
This general condition can be refined in the following manner :
 Subcondition 1 : Certain reusable components were developed by a third party with no
knowledge of internal design standards.
 Subcondition 2 : The design standard for component interfaces has not been solidified
and may not conform to certain existing reusable components.
 Subcondition 3 : Certain reusable components have been implemented in a language
that is not supported on the target environment.
The consequences associated with these refined subconditions remains the same
(i.e., 30 percent of software components must be customer engineered), but the refinement
helps to isolate the underlying risks and might lead to easier analysis and response.

1.19.10 Risk Mitigation, Monitoring and Management

A basic risk management plan has five components. These are :

1. Why the risk is important and why it should be managed,
2. What should be delivered regarding risk management and when,
 Software Engineering (MU) 1-168 Introduction

3. Who is responsible for performing the different risk management activities,

4. How will the risk be abated or the approach be taken, and
5. How many resources needed ?
RMMM : Risk Mitigation, Monitoring and Management
 Mitigation - how can we avoid the risk ?
 Monitoring - what factors can we track that will enable us to determine if the risk is
becoming more or less likely ?
 Management - what contingency plans do we have if the risk becomes a reality ?
Risk : High staff turnover is noted as a project risk, r1. Based on past history and
management intuition, the likelihood, l1, of high turnover is estimated to be 0.70
(70 percent, rather high) and the impact, x1, is projected at level 2. That is, high turnover
will have a critical impact on project cost and schedule.

1.19.10.1 Risk Mitigation

To mitigate this risk, project management must develop a strategy for reducing
turnover. Among the possible steps to be taken are :
 Meet with current staff to determine causes for turnover (e.g., poor working conditions,
low pay, and competitive job market).
 Mitigate those causes that are under our control before the project starts.
 Once the project commences, assume turnover will occur and develop techniques to
ensure continuity when people leave.
 Organize project teams so that information about each development activity is widely
dispersed.
 Define documentation standards and establish mechanisms to be sure that documents are
developed in a timely manner.
 Conduct peer reviews of all work (so that more than one person is “up to speed”).
 Assign a backup staff member for every critical technologist.

1.19.10.2 Risk Monitoring

As the project proceeds, risk monitoring activities commence. The project manager
monitors factors that may provide an indication of whether the risk is becoming more or less
likely. In the case of high staff turnover, the following factors can be monitored :
 General attitude of team members based on project pressures.
 Software Engineering (MU) 1-169 Introduction

 The degree to which the team has jelled.

 Interpersonal relationships among team members.
 Potential problems with compensation and benefits.
 The availability of jobs within the company and outside it.

1.19.10.3 Risk Management and Contingency Plan

Risk management and contingency planning assumes that mitigation efforts have
failed and that the risk has become a reality. Continuing the example, the project is well
underway and a number of people announce that they will be leaving. If the mitigation
strategy has been followed, backup is available, information is documented, and knowledge
has been dispersed across the team. In addition, the project manager may temporarily refocus
resources (and readjust the project schedule) to those functions that are fully staffed,
enabling newcomers who must be added to the team to “get up to speed.” Those individuals
who are leaving are asked to stop all work and spend their last weeks in “knowledge transfer
mode.” This might include video-based knowledge capture, the development of
“commentary documents,” and/or meeting with other team members who will remain on the
project.
RMMM Plan : Documents all work performed as part of risk analysis, and is used by
the project manager as part of the overall project plan alternatively, each risk is documented
individually using a risk information sheet (RIS).
Risk information sheet
Risk ID : P02-4-32 Date : 5/9/02 Prob : 80% Impact : high
Description :
Only 70 percent of the software components scheduled for reuse will, in fact, be integrated
into the application. The remaining functionality will have to be custom developed.
Refinement / context :
Subcondition 1 : Certain reusable components were developed by a third party with no
knowledge of integral design standards.
Subcondition 2 : The design standard for component interfaces has not been solidified and
may not conform to certain existing reusable components.
Subcondition 3 : Certain reusable components have been implemented in a language that is
not supported on the target environment.
 Software Engineering (MU) 1-170 Introduction

Mitigation / monitoring :
1. Contact third party to determine conformance with design standards.
2. Press for interface standards completion; consider component structure when deciding
on interface protocol.
3. Check to determine number of components in subcondition 3 category; check to
determine if language support can be acquired.
Management / contingency plan/trigger :
RE computed to be $20,200. Allocate this amount within project contingency cost.
Develop revised schedule assuming that 18 additional components will have to be custom
built; allocate staff accordingly.
Trigger : Mitigation steps unproductive as of 7/1/02
Current status :
5/12/02 : Mitigation steps initiated.
Originator : Asmita T. Assigned : Vaishali Wadghare.
Fig. 1.43 : Risk information sheet (RIS)

1.19.10.4 Risk Mitigation, Monitoring and Management (RMMM) Plan

The RMMM Plan may be developed in the form of a document. Alternatively, an

organization may create a set of Risk Information Sheets (RIS) [often in electronic form]
that contain all pertinent information outlined below. IMPORTANT note: Like most
software engineering documents, the RMMM Plan evolves over time.

1.0 Introduction

This section provides an overview of the RMMM Plan.

1.1 Scope and intent of RMMM activities

A description of the overall RMMM focus including objectives, organizational

responsibilities.
1.2 Risk management organizational role

Description of who has responsibility for risk management.

 Software Engineering (MU) 1-171 Introduction

2.0 Project risks

This section describes all known project risks.

2.1 Risk table

A presentation of all risks, probabilities and impact.

2.1.1 Description of risk m

Risk m is described along with relevant subconditions. Section2.1.1 is repeated

for each of m risks.
2.1.2 Probability and impact for risk m

Probability and impact for risk m is described Section 2.1.2 is repeated for each of
m risks.
2.2 Risk refinement

High probability/high impact risks are refined using the CTC approach.

3.0 Risk mitigation, monitoring and management

This section discusses RMMM for each risk.

3.1 Risk mitigation for risk m

How do we avoid risk m? Section 3.1 is repeated for each of m risks.

3.2 Risk monitoring for risk m

What conditions do we monitor to determine whether risk m is becoming more or

less likely ? Section3.2 is repeated for each of m risks.
3.3 Risk management for risk m

What contingency plans should we put into plan under the assumption that risk m
will occur ? Section 3.3 is repeated for each of m risks.

4.0 Special conditions

A discussion of special conditions that may trigger project critical risks and the
actions required should these conditions occur.
 Software Engineering (MU) 1-172 Introduction

1.19.10.5 Examples of Different Risk and RMMM actions

1. Risk : Late Delivery

 Mitigation
The cost associated with a late delivery is critical. A late delivery will result in a late
delivery of a letter of acceptance from the customer. Without the letter of acceptance,
the group will receive a failing grade for the course. Steps have been taken to ensure a
timely delivery by gauging the scope of project based on the delivery deadline.
 Monitoring
A schedule has been established to monitor project status. Falling behind schedule
would indicate a potential for late delivery. The schedule will be followed closely
during all development stages.
 Management
Late delivery would be a catastrophic failure in the project development. If the project
cannot be delivered on time the development team will not pass the course. If it
becomes apparent that the project will not be completed on time, the only course of
action available would be to request an extension to the deadline from the customer.

2. Risk : End Users Resist System

 Mitigation
In order to prevent this from happening, the software will be developed with the end
user in mind. The user-interface will be designed in a way to make use of the program
convenient and pleasurable.
 Monitoring
The software will be developed with the end user in mind. The development team will
ask the opinion of various outside sources throughout the development phases.
Specifically the user-interface developer will be sure to get a thorough opinion from
others.
 Management
Should the program be resisted by the end user, the program will be thoroughly
examined to find the reasons that this is so. Specifically the user interface will be
investigated and if necessary, revamped into a solution.
 Software Engineering (MU) 1-173 Introduction

3. Risk : Changes in Requirements

 Mitigation
In order to prevent this from happening, meetings (formal and informal) will be held
with the customer on a routine business. This insures that the product we are
producing, and the requirements of the customer are equivalent.
 Monitoring
The meetings with the customer should ensure that the customer and our organization
understand each other and the requirements for the product.
 Management
Should the development team come to the realization that their idea of the product
requirements differs from those of the customer, the customer should be immediately
notified and whatever steps necessary to rectify this problem should be taken.
Preferably a meeting should be held between the development team and the customer
to discuss at length this issue.

4. Risk : Lack of Development Experience

 Mitigation
In order to prevent this from happening, the development team will be required to
learn the languages and techniques necessary to develop this software. The member
of the team that is the most experienced in a particular facet of the development tools
will need to instruct those who are not as well versed.
 Monitoring
Each member of the team should watch and see areas where another team member
may be weak. Also if one of the members is weak in a particular area it should be
brought to the attention by that member, to the other members.
 Management
The members who have the most experience in a particular area will be required to
help those who don’t out should it come to the attention of the team that a particular
member needs help.

5. Risk : Poor Comments in Code

 Mitigation
Poor code commenting can be minimized if commenting standards are better
expressed. While standards have been discussed informally, no formal standard yet
exists. A formal written standard must be established to ensure quality of comments in
all code.
 Software Engineering (MU) 1-174 Introduction

 Monitoring
Reviews of code, with special attention given to comments will determine if they are
up to standard. This must be done frequently enough to control comment quality. If
they are not done comment quality could drop, resulting in code that is difficult to
maintain and update.
 Management
Should code comment quality begin to drop, time must be made available to bring
comments up to standard. Careful monitoring will minimize the impact of poor
commenting. Any problems are resolved by adding and refining comments as
necessary.

1.20 Project Monitoring Plan

.MU - May 04, May 06, May 07, Nov. 07, Dec. 08, Dec. 09, June 10(Old).
 Monitoring requires measurements to be made to assess the development progress status
of a project.
 Measurement planning is a key element in project planning.
 How the measurement data will be analyzed and reported must be planned in advance ?

1.20.1 Measurements

The basic purpose of measurements in a project is to provide data to project

management about the project’s current state, such that they can effectively monitor and
control the project and ensure that the project goals are met.
As project goals are established in terms of software to be delivered, cost, schedule,
and quality, for monitoring the state of a project, size, effort, schedule, and defects are the
basic measurements that are needed.
The basic measurements :

 Schedule : By monitoring the actual schedule can we properly assess if the project is on
time or if there is a delay.
 Effort : Generally effort is recorded through some on-line system (like the weekly
activity report system) which allows a person to record the amount of time spent against
a particular activity in a project. At any point, total effort on an activity can be
aggregated.
 Software Engineering (MU) 1-175 Introduction

 Defects : If defects found are being logged, monitoring can focus on how many defects
have been found so far, what percentage of defects are still open, and other issues.
 Size : The size of delivered software can be measured in terms of LOC or function
points. At a more gross level, just the number of modules or number of features might
suffice.

1.20.2 Project Monitoring

Different levels of monitoring :

 Activity level,

 Status reporting, and

 Milestone analysis

Activity-level monitoring :

This type of monitoring may be done daily in project team meetings or by the project
manager checking the status of all the tasks scheduled to be completed on that day.

Status reports :

 Prepared weekly to take stock of what has happened and what needs to be done.
 Status reports typically contain a summary of the activities successfully completed since
the last status report, any activities that have been delayed, any issues in the project that
need attention, and if everything is in place for the next week.

Milestone analysis :

 It is done at each milestone or every few weeks, if milestones are too far apart, and is
more elaborate.
 Analysis of actual versus estimated for effort and schedule.
 If the deviation, project managers try to understand the reasons for the variation and
apply corrective and preventive actions.
 Defects found by different quality control tasks, and the numbers of defects fixed are
reported.
 Software Engineering (MU) 1-176 Introduction

1.20.3 Tracking the Schedule

As the project progresses, the project manager understands the activities to be

completed and milestones to be tracked and controlled with the help of project schedule.
Tracking the project schedule is done in several ways.
 Conducting periodic meetings with team members : By conducting periodic
meetings, the project manager is able to distinguish between completed and uncompleted
activities or those that are yet to start. In addition, the project manager considers the
problems in the project as reported by the team members.
 Assessing the results of reviews : Software reviews are conducted when one or more
activities of the project are complete or when a particular development phase is
complete. The purpose of conducting reviews is to check whether the software is
developed according to user requirements or not.
 Determining the milestones : Milestones indicating the expected output are described.
These milestones check the status of a project by comparing progress of activities with
the estimated end date of the project.
 Using Earned Value Analysis to determine the progress of the project : the progress
of the project is determined quantitatively by earned value analysis technique. This
technique provides an estimate for every task without considering its type and the total
hours required to accomplish the project. Based on the estimation, each activity is given
an earned value , which is a measure of progress and describes the percentage of the
activities that have been completed

1.20.4 Control and Monitoring

Once the project gets underway, the project manager has to monitor the project
continuously to ensure that it progresses as per the plan. The project manager designates
certain key events such as completion of some important activities as milestones. For
example, a milestone can be the completion and review of the SRS document, completion of
the coding and unit testing, etc. once a milestone is reached, the project manager can assume
that some measurable progress has been made. If any delay or deviation is noticeable, then
corrective actions might have to be taken. This may entail reworking all the schedules and
producing a fresh schedule.
 Software Engineering (MU) 1-177 Introduction

As already mentioned, the PERT charts are especially useful in project monitoring and
control. A path in this graph is any set of consecutive nodes and edges from the stating node
to the last node. A critical path in this graph is a path along which every milestone is
critical to meeting the project timeline. In other words, if any delay occurs along a critical
path, the entire project would get delayed. It is therefore necessary to identify all the critical
paths in a schedule – adhering to the schedules of the task appearing on the critical paths is
of prime importance to meet the delivery date. The readers may note that there may be more
than one critical path in a schedule. The tasks along a critical path are called critical tasks. If
necessary, a manager may switch resources from a non critical task to a critical task so that
all milestones along the critical path are met.
Earned Value Analysis : One approach to measuring progress in a software project is
to calculate how much has been accomplished. This is called earned value analysis. It is
basically the percentage of the estimated time that has been completed. Additional measures
can be calculated.
Although this is based on estimated effort, it could be based on any quantity that can
be estimated and is related. It is basically the percentage of the estimated time that has been
completed. Additional measures can be calculated.
Although this is based on estimated effort it could be based on any quantity that can
be estimated and is related.

Basic measures

 Budgeted Cost of Work (BCW) : The estimated effort for each work task.
 Budgeted Cost of Work Scheduled (BCWS) : The sum of the estimated effort for each
work task that was scheduled to be completed by the specified time.
 Budget at Completion (BAC) : The total of BCWS and thus the estimate of the total
effort for the project.
 Planned Value (PV) : The percentage of the total estimated effort that is assigned to a
particular work task; PV=BCW/BAC.
 Budgeted Cost of Work Performed (BCWP) : The sum of the estimated efforts for the
work tasks that have been completed by the specified time.
 Actual Cost of Work Performed (ACWP) : The sum of the actual efforts for the work
tasks that have been completed.
 Software Engineering (MU) 1-178 Introduction

Progress indicators

 Earned Value(EV) = BCWP/BAC

= The sum of the PVs for all completed work tasks
= PC : Percent complete
 Schedule Performance Index(SPI) = BCWP/BCWS
 Schedule Variance(SV) = BCWP – BCWS
 Cost Performance Index(CPI) = BCWP/ACWP
 Cost Variance(CV) = BCWP – ACWP

Earned value analysis

One approach to measuring progress in a software project is to calculate how much

has been accomplished.
Using the following job log, calculate all of the basic measures and the progress
indicators. Is the project on schedule? Assume that it is currently 5/1/2001.
Work Estimated Effort Actual Effort So Far Estimated Actual
Task (programmer-days) (programmer-days) Completion Date
Date Completed
1 50 70 1/15/2001 2/1/2001

2 35 20 2/15/2001 2/15/2001

3 20 40 2/25/2001 3/1/2001

4 40 40 4/15/2001 4/1/2001
5 60 10 6/1/2001

6 80 20 7/1/2001

Soln. :

The BCWS is 50 + 35 + 20 + 40 = 145 programmer-days. The BAC is

50 + 35 + 20 + 40 + 60 + 80 = 285 programmer-days. The planned values (PVs) for the work
tasks are 17.5 percent,12.3 percent,7.0percent,14.0 percent,21.1 percent, 28.1 percent. The
earned value is 17.5 percent + 12.3 percent + 7 percent + 14 percent = 50.7 percent. The
 Software Engineering (MU) 1-179 Introduction

BCWP for 5/1/2001 is the same as BCWS in this example because the scheduled work has
been completed. Thus SPI = 145/145 = 1.
The schedule variance is 145 – 145 = 0. The cost performance index = 145/170=0.853
percent. This indicates that the actual effort is greater than the estimated effort. The cost
variance is 145 – 170 = – 25. This also indicates that more effort has been required than was
estimated.
The project appears to be on schedule but is costing more than was planned.

Ex. 1 : The project started on January 1 and should be finished by June 1. It is now
March 1. Complete the following table. Calculate EV, SPI, SV and CV. Determine
whether the project is on time. Justify your answer. Show your work.

Job# Est.time Actual time spent PV Due Date Completed

1 30 10 0.15

2 20 30 0.10 Yes

3 50 30 0.25 Yes

4 100 5 0.50
Soln. :
BAC = 200 BCWS = 50 BCWP = 70 ACWP = 60
EV = 70/200 = 0.35 SV = 70 – 50 = 20 SPI = 70/50 = 1.4 CV = 70 – 60 = 10
The project is ahead of schedule.

Ex. 2 : Use a spreadsheet to calculate the PV and the progress indicators for the
following project at half-month intervals from January 1 through September 1.

Work Estimated Effort Actual Effort Estimated Actual Date

Task (programmer-days) (programmer-days) Completion Date Completed

1 30 37 1/1 2/1

2 25 24 2/15 2/15

3 30 41 3/1 3/15

4 50 47 4/15 4/1

5 60 63 5/1 4/15

6 35 31 5/15 6/1
 Software Engineering (MU) 1-180 Introduction

Work Estimated Effort Actual Effort Estimated Actual Date

Task (programmer-days) (programmer-days) Completion Date Completed

7 55 58 6/1 6/1

8 30 28 6/15 6/15

9 45 43 7/1 7/15

10 25 29 8/1 8/15

11 45 49 8/15 9/1

Soln. :
Bcw Pv Acw Sched Actual
1 30 0.070 37 1-Jan 1-Feb
2 25 0.058 24 15-Feb 15-Feb
3 30 0.070 41 1-Mar 15-Mar
4 50 0.116 47 15-Apr 1-Apr
5 60 0.140 63 1-May 15-Apr
6 35 0.081 31 15-May 1-Jun
7 55 0.128 58 1-Jun 1-Jun
8 30 0.070 28 15-Jun 15-Jun
9 45 0.105 43 1-Jul 15-Jul
10 25 0.058 29 1-Aug 15-Aug
11 45 0.105 49 15-Aug 1-Sep
BAC 430
bcws bcwp acwp ev spi sv cpi cv
1-Jan 30 0 0 0.00 0 – 30 0 0
15-Jan 30 0 0 0.00 0 – 30 0 0
1- Feb 30 30 37 0.07 1.00 0 0.81 –7
15- Feb 55 55 61 0.13 1.00 0 0.90 –6
1-Mar 85 55 61 0.13 0.65 – 30 0.90 –6
15-Mar 85 85 102 0.20 1.00 0 0.83 – 17
1-Apr 85 135 149 0.31 1.59 50 0.91 – 14
15- Apr 135 195 212 0.45 1.44 60 0.92 – 17
 Software Engineering (MU) 1-181 Introduction

bcws bcwp acwp ev spi sv cpi cv

1-May 195 195 212 0.45 1.00 0 0.092 – 17
15-May 230 195 212 0.45 0.85 – 35 0.92 – 17
1-Jun 285 285 301 0.66 1.00 0 0.95 – 16
15- Jun 315 315 329 0.73 1.00 0 0.96 – 14
1-Jul 360 315 329 0.73 0.88 – 45 0.96 – 14
15- Jul 360 360 372 0.84 1.00 0 0.97 – 12
1-Aug 385 360 372 0.84 0.94 – 25 0.97 – 12
15-Aug 430 385 401 0.90 0.90 – 45 0.96 – 16
1-Sep 430 430 450 1.00 1.00 0 0.96 – 20

Exercise

Q. 1 An extension is to be built to a sports hall. Details of the activities and given below.
Activity Time (in days)

A Lay foundations 7

B Build walls 10
C Lay drains and floor 15

D Install fittings 8

E Make and fit door frames 2

F Erect roof 5

G Plaster ceiling 2

H Fit and paint doors and windows 8

I Fit gutters and pipes 2

J Paint outside 3

Some of these activities cannot be started until others have been completed :

B must be after C

C must be after A

D must be after B
 Software Engineering (MU) 1-182 Introduction

E must be after C

F must be after D and E

G must be after F

H must be after G

I must be after F

J must be after H

Complete an activity network for this problem.

Q. 2 Find the critical paths for each of the activity networks shown below

(a)

(b)
 Software Engineering (MU) 1-183 Introduction

(c)

Q. 3 Your local school decide to put on a musical. These are the many jobs to be done by
the organizing committee and the times they take :

A Make the costumes 6 weeks

B Rehearsals 12 weeks

C Get posters and tickets printed 3 weeks

D Get programmers printed 3 weeks

E Make scenery and props 7 weeks

F Get rights to perform the musical 2 weeks

G Choose cast 1 weeks

H Hire hall 1 weeks

I Arrange refreshments 1 weeks

J Organize make up 1 weeks

K Decide on musical 1 weeks

L Organize lighting 1 weeks

M Dress rehearsals 2 days

N Invite local radio/press 1 days

P Choose stage bands 1 days

Q Choose programme sellers 1 days

 Software Engineering (MU) 1-184 Introduction

R Choose performance dates 1

2 days

S Arrange seating 1
2 days

T Sell tickets Last 4 weeks

V Display posters Last 3 weeks

(a) Decide on the precedence relationships.

(b) Construct the activity network.

(c) Find the critical path and minimum completion time.

Q. 4 A project consists of ten activities. A-J. The duration (in days) of each activity and the
activities preceding each of them are as follows.

Activity Duration Preceding activities

A 10 -

B 4 -

C 8 B

D 6 C

E 8 I

F 5 -

G 10 A, D

H 2 G

I 4 -

J 10 D, F, I

(a) Construct an activity network for this project;

(b) Find a critical path in this activity network.

(c) Find the latest starting time for each activity.

Q. 5 A project consists of eight activities whose durations are as follows :

Activity A B C D E F G H

Duration 4 4 3 5 4 1 6 5
 Software Engineering (MU) 1-185 Introduction

The precedence relations are as follows :

B must follow A

D must follow A and C

F must follow C and E

G must follow C and E

H must follow B and D.

(a) Draw an activity network in which the activities are represented by vertices.

(b) Find a critical path by inspection and write down the earliest and latest starting
times for each activity.

Q. 6 The eleven activities A to K which makes up a project are subject to the following
precedence relations.

Preceding activities Activity Duration

C, F, J A 7

E B 6

- C 9

B, H D 7

C, J E 3

- F 8

A, I G 4

J H 9

E, F I 9

- J 7

B, H, I K 5

(a) Construct an activity network for the project.

(b) Find :

(i) The earliest starting time of each activity in the network;

(ii) The latest starting time of each activity.

(c) Calculate the float of each activity and hence determine the critical path.
 Software Engineering (MU) 1-186 Introduction

Review Questions

Q. 1 What is IEEE definition of Software Engineering ? (Section 1.1)

Q. 2 What are software characteristics ? (Section 1.1)

Q. 3 How software products are classified according to the range of potential application
areas ? (Section 1.1)

Q. 4 How software products are classified according to how closely software users or
software purchasers are associated with software development ? (Section 1.1)

Q. 5 Justify whether true or false following

1. The members of an organization can acquire all the information they require from a manual
which contains standards, procedures, and principles.
2. State-of-the-art hardware is the essential ingredient for successful software production
3. If the project is behind schedule, increasing the number of programmers can reduce the
time gap.
4. If the project is outsourced to a third party, the management can relax and let the other firm
develop software for them
5. Brief requirement stated in the initial process is enough to start development; detailed
requirement can be added at the later stages.
6. Software is flexible, hence software requirement; changes can be added during any phase
of the development process.
7. Software development is considered complete when the code is delivered.
8. The success of a software project depends on the quality of the product produced.
9. Software engineering makes unnecessary documentation, which slows down the project.
10. The only deliverable is the working program(s).
11. Software quality can be assessed only after the program is executed. (Section 1.3)

Q.6 What are the key objectives of software engineering are? Explain Phased development
process. (Section 1.5)

Q. 7 Why Project Management process is required in addition to Development Process in

SDLC ? (Sections 1.5 and 1.12)

Q. 8 Relate Software process, project, and product (Section 1.6.1)

Q. 9 If the sequence of activities is provided by the Process, what is the difficulty in following
it in a Project? (Section 1.6.1)

Q. 10 What is process ? What are different types of processes ? What do you mean by
verification and validation ? (Section 1.7)

Q. 11 Explain Process Step (Section 1.8)

 Software Engineering (MU) 1-187 Introduction

Q. 12 Why to use a Life Cycle Model in SDLC ? (Section 1.9)

Q. 13 Process model for software engineering is chosen based on what factors ?

(Section 1.9)

Q. 14 What are different Processes and Products of the Waterfall Model? Discuss
advantages and disadvantages of waterfall model ? (Section 1.9.1)

Q. 15 Why linear model does sometimes fails ? (Section 1.9.1)

Q. 16 When it is suitable to adopt waterfall model for SDLC ? (Section 1.9.1)

Q. 17 What do you mean by Prototype ? Enlist different types of prototypes ? Discuss merits
and limitation of prototype model (Section 1.9.2)

Q. 18 How cost gets reduced in prototyping ? (Section 1.9.2)

Q. 19 When to use prototype model ? What are the reasons for prototyping can also be
problematic ? (Section 1.9.2)

Q. 20 When to use incremental model ? (Section 1.9.3)

Q. 21 When to use Iterative enhancement model ? How it is different from prototyping and
incremental development approach ? (Section 1.9.4)

Q. 22 Explain RAD model. Discuss its advantages and disadvantages. (Section 1.9.5)

Q. 23 Explain component based development model. (Section 1.9.6)

Q. 24 Explain concurrent development model (Section 1.9.8)

Q. 25 What are different types of projects are supported in spiral model. Discuss advantages
and limitations of spiral model ? (Section 1.9.7)

Q. 26 Explain Rational Unified Process (RUP) (Section 1.9.9)

Q. 27 What are the outcomes of different stages in RUP ? (Section 1.9.9)

Q. 28 Explain static structure of the process in RUP (Section 1.9.9)

Q. 29 What are different process workflows in RUP ? (Section 1.9.9)

Q. 30 Explain Time Boxing model? How it is different from waterfall and iterative approach ?
(Section 1.9.10)

Q. 31 Explain Time, Effort, and Team Size in timeboxing model (Section 1.9.10)

Q. 32 How stages having unequal durations are managed in timeboxing model ? How
exceptional conditions are handled in timeboxing model ? (Section 1.9.10)

Q. 33 Timeboxing model is suitable for what type of projects ? (Section 1.9.10)

Q. 34 Timeboxing model is not suitable for what type of projects ? (Section 1.9.10)
 Software Engineering (MU) 1-188 Introduction

Q. 35 How change request is handled in timeboxing model ? (Section 1.9.10)

Q. 36 Compare waterfall, prototyping, and iterative models. (Section 1.9.11)

Q. 37 What is a methodology ? Why to use a methodology ? Discuss classifications of

methodologies. (Section 1.10)

Q. 38 What are selections Criteria for Software Process Models ? (Section 1.11)

Q. 39 Discuss Project Management Process. (Section 1.12)

Q. 40 Explain steps involved in project management process. Also mention deliverables

produces at the end of each step. (Section 1.12)

Q. 41 Where to use / not use Agile Development ? (Sections 1.13.2 and 1.13.3)

Q. 42 What is Agile Methodology? List various Agile Development Processes.

(Sections 1.13.6 and 1.13.8)

Q. 43 Explain Generic Agile Lifecycle. (Section 1.13.7)

Q. 44 Explain Team Composition and Roles in the Agile Methods. (Section 1.13.9)

Q. 45 Why do we Measure Software Processes, Products and Resources ? (Section 1.14.1)

Q. 46 How do we measure the effectiveness of a software process ? (Section 1.14.2)

Q. 47 Explain process matrices. What are private and public metrics ? (Section 1.14.2)

Q. 48 How should we use metrics during the project itself ? (Section 1.14.3)

Q. 49 What is the Difference between Direct and Indirect Measures ? (Section 1.14.4)

Q. 50 Explain size oriented and function oriented metrics. (Section 1.14.5)

Q. 51 What are the problems in software estimation ? (Section 1.15)

Q. 52 What are the primary reasons for cost and schedule estimation ? Cost in project is due
to what factors ? (Section 1.15)

Q. 53 What are several techniques of software cost estimation ? (Section 1.15)

Q. 54 Explain Top down and Bottom up software estimation approach.

(Sections 1.15.11 and 1.15.12)

Q. 55 Explain LOC based Technique. What are Shortcomings in LOC calculation ?

(Section 1.15.2)

Q. 56 Explain Function Point estimation technique alongwith its advantages and

disadvantages.. (Section 1.15.3)

Q. 57 Explain how COCOMO model is used to estimate software. (Section 1.15.4)

 Software Engineering (MU) 1-189 Introduction

Q. 58 Explain different development modes of COCOMO model. (Section 1.15.4.1)

Q. 59 Explain different levels of COCOMO model. (Section 1.15.4.2)

Q. 60 Compare different development modes of COCOMO model with respect to their

characteristics. (Table 1.23)

Q. 61 Explain different steps that are carried out to estimate phase-wise effort.
(Section 1.15.4.3)

Q. 62 Why COCOMO II Model is developed despite of original COCOMO model has been
very successful in software estimation. (Section 1.15.5)

Q. 63 Explain different estimation models of COCOMO II model (Section 1.15.5)

Q. 64 Explain Empirical estimation models. (Section 1.16)

Q. 65 Write short note on following Delphi method of cost estimation model

(Section 1.16.1)

Q. 66 What are objectives and principles of Project Planning ? (Section 1.17)

Q. 67 What are the project & business objectives ? (Section 1.17.1.A)

Q. 68 What is project scope ? (Section 1.17.1.B)

Q. 69 Explain project planning process. (Section 1.17.1.C)

Q. 70 What are various factors delaying project schedule ? (Section 1.18.1)

Q. 71 Explain principles of project scheduling. (Section 1.18.2)

Q. 72 Define Milestone. (Section 1.18.3)

Q. 73 Why the schedule is independent of the person-month cost ? (Section 1.18.3)

Q. 74 Write short note on Detailed Scheduling. (Section 1.18.5)

Q. 75 Explain the Scheduling activity. (Sections 1.18.4 and 1.18.5)

Q. 76 What techniques are used in scheduling ? (Section 1.18.7)

Q. 77 Explain the rules for constructing a work breakdown structure (WBS).

(Section 1.18.7.1)

Q. 78 Explain Gantt chart. (Section 1.18.7.2)

Q. 79 Write short note on PERT Chart. (Section 1.18.7.2)

Q. 80 Explain CPM. State advantages of CPM. Compare CPM with PERT.

(Sections 1.18.7.2 and 1.18.7.3)

Q. 81 Explain risk management activities. (Section 1.19)

 Software Engineering (MU) 1-190 Introduction

Q. 82 What is risk analysis? Define threat. Explain how threats are identified.
(Section 1.19.1)

Q. 83 What types of risks are we likely to encounter as software is built ?

(Section 1.19.1)

Q. 84 Explain risk components and risk drivers. (Section 1.19.4)

Q. 85 What are activities carried out in risk projection ? (Section 1.19.5)

Q. 86 How the risk table is created? How do we assess the consequences of a risk ?
(Sections 1.19.7 and 1.19.8)

Q. 87 What is a good way to describe a risk ? (Section 1.19.9)

Q. 88 What are components of risk management plan? Explain RMMM activities.

(Section 1.19.10)

Q. 89 Suggest RMMM actions for following risks

1. Risk : Late Delivery
2. Risk : End Users Resist System
3. Risk : Changes in Requirements
4. Risk : Lack of Development Experience
5. Risk : Poor Comments in Code (Section 1.19.10)

Q. 90 What are basic measurements involved in SDLC ? (Section 1.20.1)

Q. 91 What are different levels of project monitoring ? (Section 1.20.2)

Q. 92 What are various ways to track the project schedule ? (Section 1.20.3)

Q. 93 Explain Earned Value Analysis technique. (Section 1.20.4)

Q. 94 The software used to control a scanner requires 32,000 of C and 42,000 lines of
smalltalk. Estimate the number of function points for software inside the copier.
(Sections 1.15.2 and 1.15.3)

1.21 University Questions and Answers :

May 2004

Q. 1 Explain the approach used by SEI (Software Engineering Institute) to determine the
current state of process maturity of an organization. (10 Marks)
 Software Engineering (MU) 1-191 Introduction

Soln. :

Fig. Q. 1.1 : Elements of SPI framework

Software Process Improvement (SPI) implies a defined software process, an

organizational approach, and a strategy for improvement
A maturity model defines levels of software process competence and implementation.
 A maturity model is applied within the context of an SPI framework.
 The intent of the maturity model is to provide an overall indication of the "process
maturity, exhibited by a software organization. That is,
 An indication of the quality of the software Process,
 The degree to which practitioner’s understand and apply the process, and
 The general state of software engineering group practice.
 This is accomplished using some type of ordinal scale.
The software Engineering Institute's capability Maturity Model suggests five levels of
maturity.

Level 5, optimized
 Quantitative feedback systems in place to identify process weaknesses and strengthen
them.
 Project teams analyze defects to determine their causes.
 Software processes are evaluated and updated to prevent known types of defects.

Level 4, Managed

 Detailed software process and product quality metrics establish the quantitative
evaluation foundation.
 Software Engineering (MU) 1-192 Introduction

 Trends in process and product qualities can be predicted.

Level 3, Defined

 Processes for management and engineering are documented, standardized, and

integrated into a standard software process for the organization.
 All projects use an approved, tailored version of the organization's standard software
process for developing software.

Level 2, Repeatable

 Basic project management processes are established to track cost, schedule, and
functionality.
 Planning and managing new products is based on experience with similar projects.

Level 1, Initial

 Few processes are defined, and

 Success depends more on individual efforts than on following a process and using a
synergistic team effort
Table Q. 1.1 : Process areas required to achieve a maturity level

Level Focus Process Areas

Optimizing Continuous process Organizational innovation and deployment
improvement causal analysis and resolution
Quantitatively Quantitative management Organizational process performance
managed Quantitative project management
Defined Process standardization Requirements development
Technical solution
Product integration
Verification
Validation
Organizational process focus
Organizational process definition
Organizational training
 Software Engineering (MU) 1-193 Introduction

Level Focus Process Areas

Integrated project management
Integrated supplier management
Risk management
Decision analysis and resolution
Organizational environment for integration
Integrated teaming
Managed Basic project Requirements management
management Project planning
Project monitoring and control
Supplier agreement management
Measurement and analysis
Process and product quality assurance
configuration management
The results of improved process and practice must lead to
 reduction in software "problems" that cost time and money.
 reduce the number of defects that are delivered to end users,
 reduce the amount of rework due to quality problems,
 reduce the costs associated with software maintenance and support , and
 reduce the indirect costs that occur when software is delivered late
Note- This is model answer. Elaborate further based on marks.

Q. 2 Write short notes on :

(a) “Empirical Estimation Models”. (Section 1.16) (10 Marks)
(b) CMM (c) CMM and key Process Areas

Q. 3 Explain how ‘Project Scheduling and Tracking’ is done for a software development
project. (Sections 1.18 and 1.20) (10 Marks)

Q. 4 Discuss how ‘Risk identification and Risk projection’ is carried out.

(Section 1.19) (10 Marks)

Q. 5 Explain the steps involved in the ‘Implementation’ of a Software Project.

(Sections 1.8 and 1.9) (10 Marks)

Q. 5(a) Explain CMM and the Key Process Areas at each level. (10 Marks)
 Software Engineering (MU) 1-194 Introduction

Oct. 2004

Q. 6 Explain in detail life cycle model, with advantages and disadvantages.

(Section 1.9) (10 Marks)

Q. 7 Discuss the limitations of FP based and LOC based estimation.

(Sections 1.15.2 and 1.15.3) (10 Marks)

Q. 8 What is risk projection ? Explain how a risk table is developed. What is the importance
of the data entered in risk table ? (Section 1.19) (10 Marks)

Q. 9 Write notes on : Empirical estimation models. (Section 1.16) (10 Marks)

June 2005

Q. 10 Explain in detail ‘Spiral Model’ with advantages and disadvantages. What is the
difference between the ‘Spiral Model’ and ‘Object Oriented Model’ ? Discuss in detail
(Sections 1.9.6 and 1.9.7) (8 Marks)

Q. 11 Explain how FP base cost estimation is carried out. (Section 1.15.3) (7 Marks)

Q. 12. Explain how process based cost estimation is carried out (Section 1.15) (5 Marks)

Q. 13 Write short note on any one of the following : (10 Marks)

(i) Risk identification and Risk Projection. (Section 1.19)
(ii) Scheduling of a software development project. (Section 1.18)

Q. 14 Write notes of the following : (10 Marks)

(a) Software Implementation (Sections 1.8 and 1.9)
(b) Software Project Planning (Section 1.17)

Nov. 2005

Q. 15 Explain in detail the water fall model with advantages and disadvantages.
(Section 1.9.1) (10 Marks)

Q. 16 Discuss the different types of cost estimation model.

(Section 1.15) (10 Marks)

Q. 17 Discuss how ‘Risk identification and Tracking’ is done for a software development
project. (Section 1.19) (10 Marks)

Q. 18 Write note on concurrent development model.

(Section 1.9.8) (10 Marks)
 Software Engineering (MU) 1-195 Introduction

May 2006

Q. 19 What is prototyping ? How is the prototype model useful in software engineering.

Discuss it’s advantages and disadvantages ? (Section 1.9.2) (10 Marks)

Q. 20 Enlist and explain the steps requires to perform a cost estimation using COCOMO
model ? (Section 1.15.4) (10 Marks)

Q. 21 What are milestones ? How are they set, achieved and reviewed ? How are they used
in project monitoring ? (Sections 1.18 and 1.20) (10 Marks)

Q. 22 Compare conventional approach and object oriented approach to software

development. What are the advantage of OOAD ? (Section 1.10) (10 Marks)

Q. 23 What are the advantages of the object oriented software engineering ?

(Refer Q. 28 of Nov. 2006) (10 Marks)

Q. 24 Write notes on : Feasibility Study. (10 Marks)

Ans. :

Definition of Feasibility Studies

 A feasibility study looks at the viability of an idea with an emphasis on identifying

potential problems and attempts to answer one main question: Will the idea work and
should you proceed with it?
 Before you begin writing your business plan you need to identify how, where , and to
whom you intend to sell a service or product.
 You also need to assess your competition and figure out how much money you need to
start your business and keep it running until it is established.
 Feasibility studies address things like where and how the business will operate. They
provide in-depth details about the business to determine if and how it can succeed, and
serve as a valuable tool for developing a winning business plan.

Why Are Feasibility Studies so Important ?

The information you gather and present in your feasibility study will help you:
 List in detail all the things you need to make the business work;
 Identify logistical and other business-related problems and solutions;
 Develop marketing strategies to convince a bank or investor that your business is worth
considering as an investment; and
 Serve as a solid foundation for developing your business plan.
 Software Engineering (MU) 1-196 Introduction

Even if you have a great business idea you still have to find a cost-effective way to
market and sell your products and services. This is especially important for store-front retail
businesses where location could make or break your business.
For example, most commercial space leases place restrictions on businesses that can
have a dramatic impact on income. A lease may limit business hours/days, parking spaces,
restrict the product or service you can offer, and in some cases, even limit the number of
customers a business can receive each day.

The Components of a Feasibility Study

Description of the Business : The product or services to be offered and how they will be
delivered.

Market Feasibility : Includes a description of the industry, current market, anticipated

future market potential, competition, sales projections, potential buyers, etc .
Technical Feasibility : Details how you will deliver a product or service (i.e., materials,
labor, transportation, where your business will be located, technology needed, etc.).
Financial Feasibility : Projects how much start -up capital is needed, sources of capital,
returns on investment, etc.
Organizational Feasibility : Defines the legal and corporate structure of the business (may
also include professional background information about the founders and what skills they
can contribute to the business).

Conclusions : Discusses how the business can succeed. Be honest in your assessment
because investors won’t just look at your conclusions they will also look at the data and will
question your conclusions if they are unrealistic.

Nov. 2006

Q. 25 Discuss in detail spiral model, with advantages and disadvantages.

(Section 1.9.7) (10 Marks)

Q. 26 Explain the FP based and LOC based estimation. Give its limitation.
(Section 1.15.3 and 1.15.2) (10 Marks)

Q. 27 Explain in detail Risk identification and Risk projection. (Section 1.19) (10Marks)
 Software Engineering (MU) 1-197 Introduction

Q. 28 What are the advantages of Object Oriented Software Engineering. (10 Marks)
Ans. :

Object-oriented programming (OOP) is a programming paradigm that uses "objects"

and their interactions to design applications and computer programs.
Object Oriented Development (OOD) has been touted as the next great advance in
software engineering. It promises to reduce development time, reduce the time and resources
required to maintain existing applications, increase code reuse, and provide a competitive
advantage to organizations that use it.

The key ideas of the object oriented approach are

 Encapsulation
 Objects
 Class and Inheritance
 Instances and Instantiation
 Methods and Messages

Some important features of Object Oriented programming are as follows

 Emphasis on data rather than procedure

 Objects can communicate with each other through functions
 Programs are divided into Objects
 New data and functions can be easily added whenever necessary
 Data is hidden and cannot be accessed by external functions
 Follows bottom-up approach

Advantages of Object Oriented Development (OOD)

 Simplicity : software objects model real world objects, so the complexity is reduced and
the program structure is very clear.
 Reusability : Reusability is a desired goal of all development and is based on the
reluctance of reinventing something when it has already been invented. Objects contain
both data and functions that act on data, objects can be thought of as self-contained
"boxes" (encapsulation). This feature makes it easy to reuse code in new systems.
Messages provide a predefined interface to an object's data and functionality. If you
 Software Engineering (MU) 1-198 Introduction

know this interface, you can make use on an object in any context you want. OOP
languages, such as C# , make it easy to expand on the functionality of these "boxes",
even if you don't know much about their implementation.
 Increased Quality : Increases in quality are largely a by-product of this program reuse.
If 90% of a new application consists of proven, existing components, then only the
remaining 10% of the code has to be tested from scratch. That observation implies an
order-of-magnitude reduction in defects.
 Faster Development : OOD (Object oriented development) leads to faster development.
Many of the claims of potentially reduced development time are correct in principle.
 Maintainable : OOP methods make code more maintainable. Objects can be maintained
separately, making locating and fixing problems easier. The principles of good OOP
design contribute to an application's maintainability.
 Scalable : Object oriented applications are more scalable then structured approach. As
an object's interface provides for reusing the object in new software, it also provides all
the information needed to replace the object without affecting other code. This makes it
easy to replace old and aging code with faster algorithms and newer technology.
 Modularity : Object-oriented systems have a natural structure for modular design:
objects, subsystems, framework, and so on. Thus, OOD systems are easier to modify.
OOD systems can be altered in fundamental ways without ever breaking up since
changes are neatly encapsulated.
 Modifiability : It is easy to make minor changes in the data representation or the
procedures in an OO program. For example, the year 2000 (Y2K) problem may have
been eliminated by identifying a date object within a system and accessing this object
when you needed to date an operation. If the date object had the state variables of month,
day and year with each defined as two-character variables, the only change that would
be necessary to correct the Y2K problem was to change the year state variable of only
the date object.
 Client/Server Architecture : Client/server applications involve transmission of messages
back and forth over a network, and the object-message paradigm of OOD meshes well
with the physical and conceptual architecture of client/server applications.
Q. 29 Write notes on : Feasibility Study.
(Refer Q. 24 of May 2006) (10 Marks)
 Software Engineering (MU) 1-199 Introduction

May 2007

Q. 30 College is planning to computerize the student admission system. Write System

Requirements specification, System Design Document using SDLC steps.
(Section ***) (20 Marks)

Q. 31 Compare Spiral Model with Water Fall Model of SDLC.

(Sections 1.9.1 and 1.9.7) (10 Marks)

Q. 32 Explain how project scheduling and tracking is done for a software development
project. (Sections 1.18 and 1.20) (10 Marks)

Q. 33 What is Risk Projection ? Explain Methods of Risk Mitigation and Risk Management.
(Section 1.19) (10 Marks)

Q. 34 Advantages of object Oriented Software Engineering.

(Refer Q. 28 of Nov. 2006) (10 Marks)

Q. 35 Write notes on :
(a) Empirical Estimation Model (Section 1.16) (10 Marks)
(b) Software Project Planning. (Section 1.17) (10 Marks)

Nov. 2007

Q. 36 Explain in detail the Incremental model with advantages and disadvantages.

(Section 1.9.3) (10 Marks)

Q. 37 Explain the FP based and Loc based estimation. Give its limitation.
(Sections 1.15.2 and1.15.3) (10 Marks)

Q. 38 Explain in detail Risk identification and Risk projection.

(Section 1.19) (10 Marks)

Q. 39 Explain in detail concurrent development model. (Section 1.9.6) (10 Marks)

Q. 40 Explain how project scheduling and tracking is done for a software development
project. (Sections 1.18 and 1.20) (10 Marks)

Q. 41 Compare Conventional approach and Object oriented approach to software

development. What are the advantages of OOAD ?
(Refer Q. 22 of Nov. 2006) (10 Marks)

Q. 42 Write short notes on any two : (20 Marks)

(a) CMM <Ch1 May 2004>

(b) Software Project Planning (Section 1.17)

 Software Engineering (MU) 1-200 Introduction

May 2008

Q. 43 Define process. Explain incremental model of software development give example

where the model can be applied and justify your example.
(Sections 1.6 and 1.9.3) (10 Marks)
Q. 44 Draw activity diagram and Gantt-chart for the following :
Activity Predecessor Duration (in weeks)
A – 2
B A 3
C – 2
D A, C 3
E D 4
F A, D 3
G B, E 2
H G 3

Find minimum duration required to complete the project. (10 Marks)

Ans. :

Fig. Q. 1.44(a) : Activity diagram

A 2
B 3
NODES C 2
D 3
E 4
F 3
G 2
H 3
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Duration in Weeks
Fig. Q. 1.44(b) : Gantt Chart
 Software Engineering (MU) 1-201 Introduction

Q. 45 When does the project planning activity start and end in a software life cycle ? What
the important activities software project managers perform during project planning.
(Section 1.17) (10 Marks)
Q. 46 Suppose you are developing a software product in the organic mode. You have
estimated the size of the product to be 70695 lines of code, compute effort and
development time. Assuming cost of 25,000 person month calculate total cost of
product (constants ba = 2.4. bb = 1.05, bc = 2.5, bd = 0.38) (10 Marks)
Ans. :

From the basic COCOMO estimation formula for organic software:

Effort = 2.4  (70.695)
1.05
= 202.92 PM
Nominal_Development _Time = 2.5  (202.92) = 19.06  20 months
0.38

Cost_Required_to_develop_the_product = 20  25000 = Rs. 500000

Q. 47 Explain different metrics for size estimation. What are their advantages and
disadvantages. (Sections 1.14 and 1.15) (10 Marks)

Q. 48 Based on the following statements, identify whether this is a project, product, process
risk. Justify your identification. (10 Marks)
(i) Size of software is estimated wrong by 15%.
(ii) Critical functions and features did not get communicated to the system analyst.
(iii) Report generator’s capabilities did not conform to the promised capabilities in the product
literature.
(iv) RAD Model is selected instead of incremental.
(v) Due to work pressure, prototype not developed. (Section 1.19.1)

Q. 49 Explain different activities performed during Risk Management. Which process Model
includes Risk analysis as it’s activity. (Sections 1.19 and 1.9.7) (10 Marks)

Dec. 2008

Q. 50 Differentiate between FP based and LOC based cost estimation techniques.

(Section 1.15.2 and 1.15.3) (10 Marks)

Q. 51 Explain the difference between : (10 Marks)

Component Based Model and Spiral Model. (Section 1.9.6 and 1.9.7)

Q. 52 Explain risk identification, risk projection, RMMM plan in detail

(Section 1.19) (10 Marks)

Q. 53 Explain how Gantt-chart can be used for planning and controlling small projects with
suitable example ? What are the limitations of Gantt-Chart ?
(Section 1.18.7.2.A) (10 Marks)
 Software Engineering (MU) 1-202 Introduction

Q. 54 What is feasibility study. Explain its types, contents and purpose.

(Refer Q. 24 of May 2006) (10 Marks)
Q. 55 Explain in detail Software project plan with examples. (Section 1.17) (10 Marks)
Q. 56 Write short note on : Project Scheduling and Tracking.
(Sections 1.18 and 1.20) (10 Marks)

May 2009

Q. 57 Explain in detail the incremental model with the advantages and disadvantages.
(Section 1.9.3) (10 Marks)
Q. 58 What are different size oriented metrics ? Give limitations of LOC.
(Sections 1.14 and 1.9.3) (10 Marks)
Q. 59 What are different types of Feasibility Studies conducted ? Give e.g. of each when it is
not feasible. (Refer Q. 24 of May 2006) (10 Marks)
Q. 60 Draw Gantt-chart and Activity Diagram for the following task set.
Activity Dependency Duration (in Weeks)
Al — 1
A2 A 2
A3 -— 5
A4 A1, A3 2
A5 A2, A3 3
A6 A5 7
A7 A4, A6 4
Ans. :

(a) Activity diagram :

Fig. Q. 1.60(a)
 Software Engineering (MU) 1-203 Introduction

(b) Gantt-chart :

Fig. Q. 1.60(b)

Dec. 2009

Q. 61 Differentiate between FP based and LOC based cost estimation techniques.

(Sections 1.15.2 and 1.15.3) (10 Marks)

Q. 62 Explain how Gantt-chart can be used for planning and controlling small projects with
example ? What are the limitations of Gantt-chart ? (Section 1.18.7.2.A) (10 Marks)

Q. 63 What is feasibility study ? Explain its types, contents and purpose.

(Refer Q. 24 of May 2006) (10 Marks)

Q. 64 Explain risk identification, risk projection, RMMM plan. (Section 1.19) (10 Marks)

Q. 65 Explain the difference between :RAD Model and Spiral Model.

(Sections 1.9.5 and 1.9.7) (5 Marks)

Q. 66 Explain in detail software project plan with examples. (Section 1.17) (10 Marks)

Q. 67 Write short note on : Project Scheduling and tracking.

(Sections 1.18 and 1.20) (10 Marks)

June 2010

Q. 68 Discuss the different types of cost estimation model.

(Section 1.15) (10 Marks)
 Software Engineering (MU) 1-204 Introduction

Q. 69 Explain in detail the Increamental model with advantage and disadvantages.

(Section 1.9.3) (10 Marks)

Q. 70 Write short note on : (20 Marks)

(a) Empirical Estimation Model (Section 1.16)
(b) Software Project Planning. (Section 1.17)

Q. 71 What are the advantages of Object Oriented Software Engineering.

(Refer Q. 23 of Nov-2006) (10 Marks)

June 2010 (Old)

Q. 72 Explain in detail the incremental model with advantages and disadvantages.

(Section 1.9.3) (10 Marks)

Q. 73 Explain how size-oriented metrics differ from function-oriented metrics. Discuss the
pros and cons of each. (Section 1.14) (10 Marks)

Q. 74 Explain how project scheduling and tracking is done for a software development
project. (Sections 1.18 and 1.20) (10 Marks)

Q. 75 Explain COCOMO Model in detail. (Section 1.15.4) (10 Marks)

Q. 76 Explain risk identification, risk projection, RMMM plan in detail.

(Section 1.19) (10 Marks)

Q. 77 What is feasibility study ? Explain its type, contents and purpose.

(Refer Q. 24 of May 2006) (10 Marks)

