UNIT - 2

SOFTWARE PROCESS

Software processes are the activities for designing,

implementing, and testing a software system. The software
development process is complicated and involves a lot more
than technical knowledge.
That’s where software process models come in handy. A
software process model is an abstract representation of the
development process.
In this article, we will introduce you to the top seven software
process models and discuss when to use them.

What is a software process model?

A software process model is an abstraction of the software
development process. The models specify the stages and order
of a process. So, think of this as a representation of the order of
activities of the process and the sequence in which they are
performed.
A model will define the following:

 The tasks to be performed

 The input and output of each task
 The pre and post-conditions for each task
 The flow and sequence of each task

The goal of a software process model is to provide

guidance for controlling and coordinating the tasks to
achieve the end product and objectives as effectively
as possible.
There are many kinds of process models for meeting different
requirements. We refer to these as SDLC models (Software
Development Life Cycle models). The most popular and
important SDLC models are as follows:
 Waterfall model
 V model
 Incremental model
 RAD model

 Agile model
 Iterative model
 Prototype model
 Spiral model

Factors in choosing a software process

Choosing the right software process model for your project can
be difficult. If you know your requirements well, it will be
easier to select a model that best matches your needs. You need
to keep the following factors in mind when selecting your
software process model:

Project requirements
Before you choose a model, take some time to go through the
project requirements and clarify them alongside your
organization’s or team’s expectations. Will the user need to
specify requirements in detail after each iterative session? Will
the requirements change during the development process?

Project size
Consider the size of the project you will be working on. Larger
projects mean bigger teams, so you’ll need more extensive and
elaborate project management plans.
Project complexity
Complex projects may not have clear requirements. The
requirements may change often, and the cost of delay is high.
Ask yourself if the project requires constant monitoring or
feedback from the client.

Cost of delay
Is the project highly time-bound with a huge cost of delay, or
are the timelines flexible?

Customer involvement
Do you need to consult the customers during the process? Does
the user need to participate in all phases?

Familiarity with technology

This involves the developers’ knowledge and experience with
the project domain, software tools, language, and methods
needed for development.

Project resources
This involves the amount and availability of funds, staff, and
other resources.

Types of software process models

As we mentioned before, there are multiple kinds of software
process models that each meet different requirements. Below,
we will look at the top seven types of software process models
that you should know.

Waterfall Model
The waterfall model is a sequential, plan driven-process where
you must plan and schedule all your activities before starting the
project. Each activity in the waterfall model is represented as a
separate phase arranged in linear order.
It has the following phases:

 Requirements
 Design
 Implementation
 Testing
 Deployment
 Maintenance

Each of these phases produces one or more documents that need

to be approved before the next phase begins. However, in
practice, these phases are very likely to overlap and may feed
information to one another.
The software process isn’t linear, so the documents
produced may need to be modified to reflect
changes.
The waterfall model is easy to understand and follow. It doesn’t
require a lot of customer involvement after the specification is
done. Since it’s inflexible, it can’t adapt to changes. There is no
way to see or try the software until the last phase.
The waterfall model has a rigid structure, so it should be used in
cases where the requirements are understood completely and
unlikely to radically change.
V Model
The V model (Verification and Validation model) is an
extension of the waterfall model. All the requirements are
gathered at the start and cannot be changed. You have a
corresponding testing activity for each stage. For every phase in
the development cycle, there is an associated testing phase.
The V model is highly disciplined, easy to understand, and
makes project management easier. But it isn’t good for complex
projects or projects that have unclear or changing requirements.
This makes the V model a good choice for software where
downtimes and failures are unacceptable.

Incremental Model
The incremental model divides the system’s functionality
into small increments that are delivered one after the other in
quick succession. The most important functionality is
implemented in the initial increments.
The subsequent increments expand on the previous ones until
everything has been updated and implemented.
Incremental development is based on developing an initial
implementation, exposing it to user feedback, and evolving it
through new versions. The process’ activities are interwoven by
feedback.

The incremental model lets stakeholders and developers see

results with the first increment. If the stakeholders don’t like
anything, everyone finds out a lot sooner. It is efficient as the
developers only focus on what is important and bugs are fixed
as they arise, but you need a clear and complete definition of
the whole system before you start.
The incremental model is great for projects that have
loosely coupled parts and projects with complete and clear
requirements.

Iterative Model
The iterative development model develops a system by building
small portions of all the features. This helps to meet the initial
scope quickly and release it for feedback.
In the iterative model, you start off by implementing a small set
of software requirements. These are then enhanced
iteratively in the evolving versions until the system is
completed. This process model starts with part of the software,
which is then implemented and reviewed to identify further
requirements.
Like the incremental model, the iterative model allows you to
see the results at the early stages of development. This makes it
easy to identify and fix any functional or design flaws. It also
makes it easier to manage risk and change requirements.
The deadline and budget may change throughout the
development process, especially for large complex projects. The
iterative model is a good choice for large software that can
be easily broken down into modules.

RAD Model
The Rapid Application Development (RAD model) is based on
iterative development and prototyping with little planning
involved. You develop functional modules in parallel for faster
product delivery. It involves the following phases:

1. Business modeling
2. Data modeling
3. Process modeling
 4. Application generation
5. Testing and turnover

The RAD concept focuses on gathering requirements using

focus groups and workshops, reusing software components, and
informal communication.

CHOICE OF PROCESS MODEL

  The word process is sometimes used to emphasize the idea
of a system in action. In order to achieve an outcome, the
system will have to execute one or more activities: this is
its process. 
 This idea can be applied to the development of computer-
based systems where a number of interrelated activities
have to be undertaken to create a local product. These
activities can be organized in different ways and we can
call these process models.
 A major part of the planning will be the choosing of the
development methods to be used and the slotting of these
into an overall process model.
 The planner needs not only to select methods but also to
specify how the method is to be applied. With methods
such as SSADM, there is a considerable degree of choice
about how it is to be applied: not all parts of SSADM are
compulsory. Many student projects have the rather basic
failing that at the planning stage they claim. say. SSADM
is to be used: in the event, all that is produced are a few
SSADM fragments such as a top level data flow diagram
and a preliminary logical data structure diagram. If this is
all the particular project requires, it should be stated at the
outset.

RAPID APPLICATION DEVELOPMENT

MODEL(RAD)

The Rapid Application Development Model was first proposed

by IBM in the 1980s. The RAD model is a type of incremental
process model in which there is extremely short development
cycle.
 When the requirements are fully understood and the
component based construction approach is adopted then the
RAD model is used. Various phases in RAD are Requirements
Gathering, Analysis and Planning, Design, Build or
Construction and finally Deployment.
The critical feature of this model is the use of powerful
development tools and techniques. A software project can be
implemented using this model if the project can be broken
down into small modules wherein each module can be assigned
independently to separate teams. These modules can finally be
combined to form the final product. Development of each
module involves the various basic steps as in the waterfall
model i.e analyzing, designing, coding, and then testing, etc. as
shown in the figure. Another striking feature of this model is a
short time span i.e the time frame for delivery(time-box) is
generally 60-90 days.

Multiple teams work on developing the software system using

RAD model.
This model consists of 4 basic phases:
1. Requirements Planning – It involves the use of various
techniques used in requirements elicitation like
brainstorming, task analysis, form analysis, user scenarios,
FAST (Facilitated Application Development Technique),
etc. It also consists of the entire structured plan describing
the critical data, methods to obtain it, and then processing it
to form a final refined model.
2. User Description – This phase consists of taking user
feedback and building the prototype using developer tools.
In other words, it includes re-examination and validation of
the data collected in the first phase. The dataset attributes are
also identified and elucidated in this phase.
3. Construction – In this phase, refinement of the prototype
and delivery takes place. It includes the actual use of
powerful automated tools to transform process and data
models into the final working product. All the required
modifications and enhancements are too done in this phase.
4. Cutover – All the interfaces between the independent
modules developed by separate teams have to be tested
properly. The use of powerfully automated tools and
subparts makes testing easier. This is followed by
acceptance testing by the user.
The process involves building a rapid prototype, delivering it to
the customer, and taking feedback. After validation by the
customer, the SRS document is developed and the design is
finalized. 

When to use RAD Model?

When the customer has well-known requirements, the user is

involved throughout the life cycle, the project can be time
boxed, the functionality delivered in increments, high
performance is not required, low technical risks are involved
and the system can be modularized. In these cases, we can use
the RAD Model.
Advantages:

 The use of reusable components helps to reduce the cycle

time of the project.
 Feedback from the customer is available at the initial stages.
 Reduced costs as fewer developers are required.
 The use of powerful development tools results in better
quality products in comparatively shorter time spans.
 The progress and development of the project can be
measured through the various stages.
 It is easier to accommodate changing requirements due to
the short iteration time spans.

Disadvantages:

 The use of powerful and efficient tools requires highly

skilled professionals.
 The absence of reusable components can lead to the failure
of the project.
 The team leader must work closely with the developers and
customers to close the project in time.
 The systems which cannot be modularized suitably cannot
use this model.
 Customer involvement is required throughout the life cycle.
 It is not meant for small-scale projects as in such cases, the
cost of using automated tools and techniques may exceed the
entire budget of the project.

Applications:

1. This model should be used for a system with known

requirements and requiring a short development time.
2. It is also suitable for projects where requirements can be
modularized and reusable components are also available for
development.
3. The model can also be used when already existing system
components can be used in developing a new system with
minimum changes.
4. This model can only be used if the teams consist of domain
experts. This is because relevant knowledge and the ability
to use powerful techniques are a necessity.
5. The model should be chosen when the budget permits the
use of automated tools and techniques required.

Drawbacks of rapid application development:

1. It requires multiple teams or large number of people to work

on the scalable projects.
 2. This model requires heavily committed developer and
customers. If commitment is lacking then RAD projects will
fail.
3. The projects using RAD model requires heavy resources.
4. If there is no appropriate modularization then RAD projects
fail. Performance can be problem to such projects.
5. The projects using RAD model find it difficult to adopt new
technologies

AGILE MODEL vs WATERFALL MODEL

Agile Model Waterfall Model
 Agile methodology definition: Agile  Waterfall Model: D
methodologies propose incremental and software flows sequ
iterative approach to software design point to end point.

 The Agile process in software engineering is

 The design process
broken into individual models that designers
an individual models
work on

 The customer has early and frequent

 The customer can on
opportunities to look at the product and make
at the end of the proj
Decision and changes to the project

 Agile model is considered unstructured  Waterfall model

compared to the waterfall model because they are so p

 Small projects can be implemented very

 All sorts of project
quickly. For large projects, it is difficult to
and completed.
estimate the development time.

 Only at the end, the

tested. If the require
 Error can be fixed in the middle of the project.
or any changes hav
project has to start fr

 The development p
 Development process is iterative, and the
and the phase is
project is executed in short (2-4) weeks
iteration. Every pha
iterations. Planning is very less.
detailed description o

 Documentation is a t
 Documentation attends less priority than
even use for training
software development
the software with ano

 Every iteration has its own testing phase. It  Only after the deve
allows implementing regression testing every testing phase is
time new functions or logic are released. separate parts are no

 In agile testing when an iteration end,  All features develop

 shippable features of the product is delivered
to the customer. New features are usable right once after the lon
after shipment. It is useful when you have phase.
good contact with customers.

 Testers work
 Testers and developers work together
developers

 At the end of every sprint, user acceptance is  User acceptance is

performed end of the project.

 Developer does
 It requires close communication with
requirement and
developers and together analyze requirements
Usually, time delays
and planning
coding

DYNAMIC SYSTEM DEVELOPMENT

METHOD (DSDM)

The Dynamic Systems Development technique (DSDM) is an

associate degree agile code development approach that
provides a framework for building and maintaining systems.
The DSDM philosophy is borrowed from a modified version of
the sociologist principle—80 % of An application is often
delivered in twenty percent of the time it’d desire deliver the
entire (100 percent) application.
DSDM is An iterative code method within which every
iteration follows the 80% rule that simply enough work is
needed for every increment to facilitate movement to the
following increment. The remaining detail is often completed
later once a lot of business necessities are noted or changes are
requested and accommodated.
The DSDM tool (www.dsdm.org) could be a worldwide cluster
of member companies that put together tackle the role of
“keeper” of the strategy. The pool has outlined AN Agile
Development Model, known as the DSDM life cycle that
defines 3 different unvarying cycles, preceded by 2 further life
cycle activities:
1. Feasibility Study:
It establishes the essential business necessities and
constraints related to the applying to be designed then
assesses whether or not the application could be a viable
candidate for the DSDM method.
2. Business Study:
It establishes the use and knowledge necessities that may
permit the applying to supply business value; additionally, it
is the essential application design and identifies the
maintainability necessities for the applying.

3. Functional Model Iteration:

It produces a collection of progressive prototypes that
demonstrate practicality for the client.
(Note: All DSDM prototypes are supposed to evolve into the
deliverable application.) The intent throughout this
unvarying cycle is to collect further necessities by eliciting
feedback from users as they exercise the paradigm.
4. Design and Build Iteration:
It revisits prototypes designed throughout useful model
iteration to make sure that everyone has been designed
during a manner that may alter it to supply operational
business price for finish users. In some cases, useful model
iteration and style and build iteration occur at the same time.
5. Implementation:
It places the newest code increment (an “operationalized”
prototype) into the operational surroundings. It ought to be
noted that:
 (a) the increment might not 100% complete or,
 (b) changes are also requested because the increment is
placed into place. In either case, DSDM development work
continues by returning to the useful model iteration activity.
DSDM is often combined with XP to supply a mixed approach
that defines a solid method model (the DSDM life cycle) with
the barmy and bolt practices (XP) that are needed to create
code increments. additionally, the ASD ideas of collaboration
and self-organizing groups are often tailored to a combined
method model.

BASICS OF SOFTWARE ESTIMATION

Estimation is the process of finding an estimate, or
approximation, which is a value that can be used for some
purpose even if input data may be incomplete, uncertain, or
unstable.
Estimation determines how much money, effort, resources, and
time it will take to build a specific system or product. Estimation
is based on −
 Past Data/Past Experience
 Available Documents/Knowledge
 Assumptions
 Identified Risks

The four basic steps in Software Project Estimation are −

 Estimate the size of the development product.
 Estimate the effort in person-months or person-hours.
 Estimate the schedule in calendar months.
 Estimate the project cost in agreed currency.

Observations on Estimation

Estimation need not be a one-time task in a project. It can

take place during −

 Acquiring a Project.
 Planning the Project.
 Execution of the Project as the need arises.

1. Project scope must be understood before the estimation

process begins. It will be helpful to have historical Project
Data.

2. Project metrics can provide a historical perspective and

valuable input for generation of quantitative estimates.
 3.Planning requires technical managers and the software
team to make an initial commitment as it leads to
responsibility and accountability.

3. Past experience can aid greatly.

General Project Estimation Approach

The Project Estimation Approach that is widely used

is Decomposition Technique. Decomposition techniques take a
divide and conquer approach. Size, Effort and Cost estimation
are performed in a stepwise manner by breaking down a Project
into major Functions or related Software Engineering Activities.
Step 1 − Understand the scope of the software to be built.
Step 2 − Generate an estimate of the software size.

Start with the statement of scope.


Decompose the software into functions that can each be
estimated individually.


Calculate the size of each function.


Derive effort and cost estimates by applying the size values
to your baseline productivity metrics.


Combine function estimates to produce an overall estimate
for the entire project.

Step 3 − Generate an estimate of the effort and cost. You can
arrive at the effort and cost estimates by breaking down a
project into related software engineering activities.

Identify the sequence of activities that need to be
performed for the project to be completed.


Divide activities into tasks that can be measured.


Estimate the effort (in person hours/days) required to
complete each task.


Combine effort estimates of tasks of activity to produce an
estimate for the activity.


Obtain cost units (i.e., cost/unit effort) for each activity
from the database.


Compute the total effort and cost for each activity.


Combine effort and cost estimates for each activity to
produce an overall effort and cost estimate for the entire
project.


Step 4 − Reconcile estimates: Compare the resulting values

from Step 3 to those obtained from Step 2. If both sets of
estimates agree, then your numbers are highly reliable.
Otherwise, if widely divergent estimates occur conduct further
investigation concerning whether −

 The scope of the project is not adequately understood or
has been misinterpreted.


The function and/or activity breakdown is not accurate.


Historical data used for the estimation techniques is
inappropriate for the application, or obsolete, or has been
misapplied.


Step 5 − Determine the cause of divergence and then reconcile

the estimates.

Estimation Accuracy

Accuracy is an indication of how close something is to reality.

Whenever you generate an estimate, everyone wants to know
how close the numbers are to reality. You will want every
estimate to be as accurate as possible, given the data you have at
the time you generate it. And of course you don’t want to
present an estimate in a way that inspires a false sense of
confidence in the numbers.
Important factors that affect the accuracy of estimates are −

The accuracy of all the estimate’s input data.


The accuracy of any estimate calculation.


How closely the historical data or industry data used to
calibrate the model matches the project you are estimating.


The predictability of your organization’s software
development process.
 

The stability of both the product requirements and the
environment that supports the software engineering effort.


Whether or not the actual project was carefully planned,
monitored and controlled, and no major surprises occurred
that caused unexpected delays.


Following are some guidelines for achieving reliable estimates −

 Base estimates on similar projects that have already been
completed.
 Use relatively simple decomposition techniques to generate
project cost and effort estimates.
 Use one or more empirical estimation models for software
cost and effort estimation.
Refer to the section on Estimation Guidelines in this chapter.
To ensure accuracy, you are always advised to estimate using at
least two techniques and compare the results.

Estimation Issues

Often, project managers resort to estimating schedules skipping

to estimate size. This may be because of the timelines set by the
top management or the marketing team. However, whatever the
reason, if this is done, then at a later stage it would be difficult
to estimate the schedules to accommodate the scope changes.
While estimating, certain assumptions may be made. It is
important to note all these assumptions in the estimation sheet,
as some still do not document assumptions in estimation sheets.
Even good estimates have inherent assumptions, risks, and
uncertainty, and yet they are often treated as though they are
accurate.
The best way of expressing estimates is as a range of possible
outcomes by saying, for example, that the project will take 5 to
7 months instead of stating it will be complete on a particular
date or it will be complete in a fixed no. of months. Beware of
committing to a range that is too narrow as that is equivalent to
committing to a definite date.

You could also include uncertainty as an accompanying
probability value. For example, there is a 90% probability
that the project will complete on or before a definite date.


Organizations do not collect accurate project data. Since
the accuracy of the estimates depend on the historical data,
it would be an issue.


For any project, there is a shortest possible schedule that
will allow you to include the required functionality and
produce quality output. If there is a schedule constraint by
management and/or client, you could negotiate on the
scope and functionality to be delivered.


Agree with the client on handling scope creeps to avoid
schedule overruns.


Failure in accommodating contingency in the final estimate
causes issues. For e.g., meetings, organizational events.


Resource utilization should be considered as less than
80%. This is because the resources would be productive
only for 80% of their time. If you assign resources at more
than 80% utilization, there is bound to be slippages.


Estimation Guidelines
One should keep the following guidelines in mind while
estimating a project −

During estimation, ask other people's experiences. Also,
put your own experiences at task.


Assume resources will be productive for only 80 percent of
their time. Hence, during estimation take the resource
utilization as less than 80%.


Resources working on multiple projects take longer to
complete tasks because of the time lost switching between
them.


Include management time in any estimate.


Always build in contingency for problem solving, meetings
and other unexpected events.


Allow enough time to do a proper project estimate. Rushed
estimates are inaccurate, high-risk estimates. For large
development projects, the estimation step should really be
regarded as a mini project.


Where possible, use documented data from your
organization’s similar past projects. It will result in the
most accurate estimate. If your organization has not kept
historical data, now is a good time to start collecting it.


 Use developer-based estimates, as the estimates prepared
by people other than those who will do the work will be
less accurate.


Use several different people to estimate and use several
different estimation techniques.


Reconcile the estimates. Observe the convergence or
spread among the estimates. Convergence means that you
have got a good estimate. Wideband-Delphi technique can
be used to gather and discuss estimates using a group of
people, the intention being to produce an accurate,
unbiased estimate.


Re-estimate the project several times throughout its life
cycle.

What is Effort Estimation?

Effort estimation is the process of forecasting how much effort is

required to develop or maintain a software application. This effort
is traditionally measured in the hours worked by a person, or the
money needed to pay for this work. 

Effort estimation is used to help draft project plans and budgets in

the early stages of the software development life cycle. This
practice enables a project manager or product owner to accurately
predict costs and allocate resources accordingly.
Effort estimation in Agile
Though effort estimation can be used in a traditional software
development approach, it is more commonly associated with
the Agile methodology. Here, the product owner must manage a
list of project deliverables, known as a backlog. They will
estimate the effort required to complete each item. Rather than
using time or cost estimates, they will look at user stories and
story points. 

 A user story is a tool used to describe a software feature

from the perspective of the consumer 
 A story point is a unit that measures the amount of work in

implementing a user story, taking into account the level of

difficulty involved and the potential risk
A product owner will compare the features of their new project
with a previous one to determine the complexity of their user
story and assign suitable story points.

COC

COST ESTIMATION

Cost estimation simply means a technique that is used to find

out the cost estimates. The cost estimate is the financial spend
that is done on the efforts to develop and test software
in Software Engineering . Cost estimation models are some
mathematical algorithms or parametric equations that are used
to estimate the cost of a product or a project.
Various techniques or models are available for cost estimation,
also known as Cost Estimation Models as shown below :

Empirical Estimation Technique –

Empirical estimation is a technique or model in which
empirically derived formulas are used for predicting the data
that are a required and essential part of the software project
planning step. These techniques are usually based on the data
that is collected previously from a project and also based on
some guesses, prior experience with the development of similar
types of projects, and assumptions. It uses the size of the
software to estimate the effort.
In this technique, an educated guess of project parameters is
made. Hence, these models are based on common sense.
However, as there are many activities involved in empirical
estimation techniques, this technique is formalized. For
example Delphi technique and Expert Judgement technique
2. Heuristic Technique –
Heuristic word is derived from a Greek word that means
“to discover”. The heuristic technique is a technique or
model that is used for solving problems, learning, or
 discovery in the practical methods which are used for
achieving immediate goals. These techniques are flexible
and simple for taking quick decisions through shortcuts
and good enough calculations, most probably when
working with complex data. But the decisions that are
made using this technique are necessary to be optimal.
In this technique, the relationship among different project
parameters is expressed using mathematical equations. The
popular heuristic technique is given by Constructive Cost
Model (COCOMO). This technique is also used to increase or
speed up the analysis and investment decisions.

3. Analytical Estimation Technique –

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

COSMIC Full Function Points:

 COSMIC function points are a unit of measure of software
functional size.
 The size is a consistent measurement (or estimate) which
is very useful for planning and managing software and
related activities. 
 The process of measuring software size is called functional
size measurement (FSM).
 Function points are used to compute a functional size
measurement (FSM) of software. The cost (in dollars or
hours) of a single unit is calculated from past projects.
 In the context of the COSMIC FFP measurement method,
which is aimed at measuring the functional size of
software, only those functional user requirements allocated
to software are considered. 
 For instance:the functional user requirements in this
example are allocated to three distinct pieces, each
exchanging data with another through a specific
organization:
o  One piece of the software lies at the application
level and exchanges data with the software's users,
and the second piece lies at the operating system
level. 
o In turn, this second piece of the software exchanges
data with a third piece lying at the device driver
level.
o  This last piece then exchanges data directly with the
hardware. 
 The COSMIC FFP measurement method associates the
functional user requirements for each piece with a specific
layer. Each layer possesses an intrinsic boundary for which
specific users are identified.

COCOMO II MODEL
COCOMO-II is the revised version of the original Cocomo
(Constructive Cost Model)  and is developed at University of
Southern California. It is the model that allows one to estimate
the cost, effort and schedule when planning a new software
development activity.
It consists of three sub-models:

 End User Programming:

Application generators are used in this sub-model. End user
write the code by using these application generators.
Example – Spreadsheets, report generator, etc.

. Intermediate Sector:

 (a).Application Generators and Composition Aids –

This category will create largely prepackaged capabilities
for user programming. Their product will have many
reusable components. Typical firms operating in this sector
 are Microsoft, Lotus,
Oracle, IBM, Borland, Novell.
 (b). Application Composition Sector –
This category is too diversified and to be handled by
prepackaged solutions. It includes GUI, Databases, domain
specific components such as financial, medical or industrial
process control packages.
 (c). System Integration –
This category deals with large scale and highly embedded
systems.
.

Infrastructure
Sector:
This category provides infrastructure for the software
development like Operating System, Database Management
System, User Interface Management System, Networking
System, etc.
Stages of COCOMO II:

1. Stage-I:
It supports estimation of prototyping. For this it
uses Application Composition Estimation Model. This model
is used for the prototyping stage of application generator and
system integration.
2. Stage-II:
It supports estimation in the early design stage of the project,
when we less know about it. For this it uses Early Design
Estimation Model. This model is used in early design stage
of application generators, infrastructure, system integration.
3. Stage-III:
It supports estimation in the post architecture stage of a
project. For this it uses Post Architecture Estimation Model.
This model is used after the completion of the detailed
architecture of application generator, infrastructure, system
integration.