Unit III: SOFTWARE MODEL

COCOMO Model, Project Scheduling, Software Staff & Personnel Planning, Rayleigh Curve,
Software Team Organization & Control Structure. Project Monitoring & Control Techniques

COCOMO Model

Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e., the number of Lines
of Code. This article focuses on discussing the Cocomo Model in detail.

The Cocomo Model is a procedural cost estimate model for software projects and is often used as
a process of reliably predicting the various parameters associated with making a project such as
size, effort, cost, time, and quality. It was proposed by Barry Boehm in 1981 and is based on the
study of 63 projects, which makes it one of the best-documented models.

The key parameters that define the quality of any software products, which are also an outcome
of the Cocomo are primarily Effort and schedule:

1. Effort: Amount of labor that will be required to complete a task. It is measured in person-
months units.

2. Schedule: This simply means the amount of time required for the completion of the job,
which is, of course, proportional to the effort put in. It is measured in the units of time
such as weeks, and months.

1. Organic

A software project is said to be an organic type if the team size required is adequately small, the
problem is well understood and has been solved in the past and also the team members have a
nominal experience regarding the problem.

2. Semi-detached

A software project is said to be a Semi-detached type if the vital characteristics such as team size,
experience, and knowledge of the various programming environments lie in between organic and
embedded. The projects classified as Semi-Detached are comparatively less familiar and difficult
to develop compared to the organic ones and require more experience better guidance and
creativity. Eg: Compilers or different Embedded Systems can be considered Semi-Detached types.

3. Embedded

A software project requiring the highest level of complexity, creativity, and experience
requirement falls under this category. Such software requires a larger team size than the other
two models and also the developers need to be sufficiently experienced and creative to develop
such complex models.

The Six phases of detailed COCOMO are:

1. Planning and requirements

2. System design

3. Detailed design

4. Module code and test

5. Integration and test

6. Cost Constructive model

Importance of the COCOMO Model

1. Cost Estimation: To help with resource planning and project budgeting, COCOMO offers
a methodical approach to software development cost estimation.

2. Resource Management: By taking team experience, project size, and complexity into
account, the model helps with efficient resource allocation.

3. Project Planning: COCOMO assists in developing practical project plans that include
attainable objectives, due dates, and benchmarks.

4. Risk management: Early in the development process, COCOMO assists in identifying and
mitigating potential hazards by including risk elements.

5. Support for Decisions: During project planning, the model provides a quantitative
foundation for choices about scope, priorities, and resource allocation.

6. Benchmarking: To compare and assess various software development projects to

industry standards, COCOMO offers a benchmark.

7. Resource Optimization: The model helps to maximize the use of resources, which raises
productivity and lowers costs

Types of COCOMO Model

1. Basic Model

E = a(KLOC)^b

Time = c(Effort)^d
Person required = Effort/ time

The above formula is used for the cost estimation of the basic COCOMO model and also is used in
the subsequent models. The constant values a, b, c, and d for the Basic Model for the different
categories of the system:

Software Projects a b c d

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

1. The effort is measured in Person-Months and as evident from the formula is dependent
on Kilo-Lines of code. The development time is measured in months.

2. These formulas are used as such in the Basic Model calculations, as not much
consideration of different factors such as reliability, and expertise is taken into account,
henceforth the estimate is rough.

2. Intermediate Model

The basic Cocomo model assumes that the effort is only a function of the number of lines of code
and some constants evaluated according to the different software systems. However, in reality,
no system’s effort and schedule can be solely calculated based on Lines of Code. For that, various
other factors such as reliability, experience, and Capability. These factors are known as Cost
Drivers and the Intermediate Model utilizes 15 such drivers for cost estimation. Classification of
Cost Drivers and their Attributes:

Product attributes:

1. Required software reliability extent

2. Size of the application database

3. The complexity of the product

4. Run-time performance constraints

5. Memory constraints
 6. The volatility of the virtual machine environment

7. Required turnabout time

8. Analyst capability

9. Software engineering capability

10. Application experience

11. Virtual machine experience

12. Programming language experience

13. Use of software tools

14. Application of software engineering methods

15. Required development schedule

Advantages of the COCOMO Model

1. Systematic cost estimation: Provides a systematic way to estimate the cost and effort of
a software project.

2. Helps to estimate cost and effort: This can be used to estimate the cost and effort of a
software project at different stages of the development process.

3. Helps in high-impact factors: Helps in identifying the factors that have the greatest
impact on the cost and effort of a software project.

4. Helps to evaluate the feasibility of a project: This can be used to evaluate the feasibility
of a software project by estimating the cost and effort required to complete it.

Disadvantages of the COCOMO Model

1. Assumes project size as the main factor: Assumes that the size of the software is the
main factor that determines the cost and effort of a software project, which may not
always be the case.

2. Does not count development team-specific characteristics: Does not take into
account the specific characteristics of the development team, which can have a significant
impact on the cost and effort of a software project.

3. Not enough precise cost and effort estimate: This does not provide a precise estimate
of the cost and effort of a software project, as it is based on assumptions and averages.
Rayleigh Curve

The Lawrence Putnam model describes the time and effort requires finishing a software project
of a specified size. Putnam makes a use of a so-called The Norden/Rayleigh Curve to estimate
project effort, schedule & defect rate as shown in fig

Putnam noticed that software staffing profiles followed the well known Rayleigh distribution.
Putnam used his observation about productivity levels to derive the software equation:

The various terms of this expression are as follows:

K is the total effort expended (in PM) in product development, and L is the product estimate
in KLOC

td correlate to the time of system and integration testing. Therefore, td can be relatively
considered as the time required for developing the product.

Ck Is the state of technology constant and reflects requirements that impede the development of
the program.

Typical values of Ck = 2 for poor development environment

Ck= 8 for good software development environment

Ck = 11 for an excellent environment (in addition to following software engineering principles,

automated tools and techniques are used).

The exact value of Ck for a specific task can be computed from the historical data of the
organization developing it.

Putnam proposed that optimal staff develop on a project should follow the Rayleigh curve. Only
a small number of engineers are required at the beginning of a plan to carry out planning and
specification tasks. As the project progresses and more detailed work are necessary, the number
of engineers reaches a peak. After implementation and unit testing, the number of project staff
falls.

Software Team Organization & Control Structure

There are many ways to organize the project team. Some important ways are as follows

1. Hierarchical team organization

2. Chief-programmer team organization

3. Matrix team, organization

4. Egoless team organization

5. Democratic team organization

Hierarchical team organization:

In this, the people of organization at different levels following a tree structure. People at bottom
level generally possess most detailed knowledge about the system. People at higher levels have
broader appreciation of the whole project.

Benefits of hierarchical team organization :

 It limits the number of communication paths and stills allows for the needed
communication.
  It can be expanded over multiple levels.

 It is well suited for the development of the hierarchical software products.

 Large software projects may have several levels.

Limitations of hierarchical team organization :

 As information has to be travel up the levels, it may get distorted.

 Levels in the hierarchy often judges people socially and financially.

 Most technical competent programmers tend to be promoted to the management

positions which may result in loss of good programmer and also bad manager.

Chief-programmer team organization: This team organization is composed of a small team

consisting the following team members:

 The Chief programmer: It is the person who is actively involved in the planning,
specification and design process and ideally in the implementation process as well.

 The project assistant: It is the closest technical co-worker of the chief programmer.

 The project secretary: It relieves the chief programmer and all other programmers of
administration tools.

 Specialists: These people select the implementation language, implement individual

system components and employ software tools and carry out tasks.

Advantages of Chief-programmer team organization :

 Centralized decision-making

 Reduced communication paths

 Small teams are more productive than large teams

  The chief programmer is directly involved in system development and can exercise the
better control function.

Disadvantages of Chief-programmer team organization :

 Project survival depends on one person only.

 Can cause the psychological problems as the “chief programmer” is like the “king” who
takes all the credit and other members are resentful.

 Team organization is limited to only small team and small team cannot handle every
project.

 Effectiveness of team is very sensitive to Chief programmer’s technical and managerial

activities.

Matrix Team Organization: In matrix team organization, people are divided into specialist
groups. Each group has a manager. Example of Metric team organization is as follows:

Egoless Team Organization: Egoless programming is a state of mind in which programmer are
supposed to separate themselves from their product. In this team organization goals are set and
decisions are made by group consensus. Here group, ‘leadership’ rotates based on tasks to be
performed and differing abilities of members.

In this organization work products are discussed openly and all freely examined all team
members. There is a major risk which such organization, if teams are composed of inexperienced
or incompetent members.

Democratic Team Organization :It is quite similar to the egoless team organization, but one
member is the team leader with some responsibilities :

 Coordination

 Final decisions, when consensus cannot be reached.

Advantages of Democratic Team Organization :

 Each member can contribute to decisions.

 Members can learn from each other.

 Improved job satisfaction.

Disadvantages of Democratic Team Organization :

 Communication overhead increased.

  Need for compatibility of members.

 Less individual responsibility and authority.

Project Monitoring and Control

Monitoring and Controlling are processes needed to track, review, and regulate the progress and
performance of the project. It also identifies any areas where changes to the project management
method are required and initiates the required changes.

The Monitoring & Controlling process group includes eleven processes, which are:

1. Monitor and control project work: The generic step under which all other monitoring
and controlling activities fall under.

2. Perform integrated change control: The functions involved in making changes to the
project plan. When changes to the schedule, cost, or any other area of the project
management plan are necessary, the program is changed and re-approved by the project
sponsor.

3. Validate scope: The activities involved with gaining approval of the project's
deliverables.

4. Control scope: Ensuring that the scope of the project does not change and that
unauthorized activities are not performed as part of the plan (scope creep).

5. Control schedule: The functions involved with ensuring the project work is performed
according to the schedule, and that project deadlines are met.
6. Control costs: The tasks involved with ensuring the project costs stay within the
approved budget.

7. Control quality: Ensuring that the quality of the project?s deliverables is to the standard
defined in the project management plan.

8. Control communications: Providing for the communication needs of each project

stakeholder.

9. Control Risks: Safeguarding the project from unexpected events that negatively impact
the project's budget, schedule, stakeholder needs, or any other project success criteria.

10. Control procurements: Ensuring the project's subcontractors and vendors meet the
project goals.

11. Control stakeholder engagement: The tasks involved with ensuring that all of the
project's stakeholders are left satisfied with the project work.