UNIT III

SOFTWARE EFFORT ESTIMATION:

Software effort estimation is an important process of system development life cycle, as it may affect
the success of software projects if project designers estimate the projects inaccurately. In the past of
few decades, various effort prediction models have been proposed by academicians and practitioners.

A realistic effort estimate requires you to have a clear understanding of certain elements of the project:

• The purpose and scope of the project (If working with a client, what are their expectations?)
• What needs to be done to achieve it
• What resources should be allocated
• Timeline

Major project estimation techniques

1. Top-down Estimate

Once more detail is learned on the project's scope, a top-down estimating technique assigns an overall
time for the project and divides the project into parts according to the work breakdown structure.

For example, let’s imagine a project that must be finalized in one year. By fitting the scope of the
project on the timeline, you can estimate how much time is available for each activity that needs to be
performed. The top-down method is best applied to projects similar to those you have completed
previously. If details are sketchy or unpredictable, the top-down approach is likely to be inefficient
and cause backlogs.

2. Bottom-up Estimate

The bottom-up method is the opposite of top-down. It approaches the project as a combination of
small workpieces. By making a detailed estimate for each task and combining them together, you can
build an overall project estimate.

Creating a bottom-up estimate usually takes more time than the top-down method but has a higher
accuracy rate. However, for the bottom-up method to be truly efficient, the project must be separated
at the level of work packages.

3. Expert judgement

The expert judgment technique requires consulting the expert who will perform the task to ask how
long it will take to complete. This method relies on your trust in the expert's insights and experience.

While it may seem like the most accurate estimation method, there are two points to consider:
 • The expert's estimates need to be objective. Estimates that are carried out very positively and
overlook possible disruptions can create difficulties in meeting deadlines.
• You can only get an accurate answer to specific questions. Detailing the task description,
framing it, and clarifying the requirements will allow the expert to understand the task fully
and provide an accurate estimate.

4. Analogous Estimating

Analogous estimating is a technique for estimating based on similar projects completed in the past. If
the whole project has no analogs, it can be applied by blending it with the bottom-up technique. In this
case, you compare the tasks with their counterparts, then combine them to estimate the overall project.

5. Three-point Estimating

Three-point estimating is very straightforward. It involves three different estimates that are usually
obtained from subject matter experts:

• Optimistic estimate
• Pessimistic estimate
• Most likely estimate

The optimistic estimate gives the amount of work and time that would be required if everything went
smoothly. A pessimistic estimate provides the worst-case scenario. The result will be most realistic
when the two are averaged with the most likely estimate.

Although it is similar to the expert judgment technique, the negative effect of the subjective point of
view is prevented by not relying on just one estimate.

Product requirements and specifications

Product requirements and specifications are two essential documents that guide the development and
delivery of a product. They define what the product should do, how it should perform, and what
standards it should meet.
Aside from the customer needs - the product's requirements include all functions, features and
behaviors that the product must possess, so that it will be efficient, ease to use, safe, low cost, etc. In
other words - any function, constraint or other property that is required in order to satisfy user's needs.

Important of Product Requirements

A product requirements document completely defines the purpose of a product or feature and explains
what the product should include. Without this very important document, your team is almost certain to
fail because they have no idea what will be considered a successful build.

Product Requirement Types

• Functionality. Each product is developed with its main purposes (goals). ...
• Quality. Quality is any element (feature), measureable or not, that gives things values beyond their
functionality and features. ...
• Usability. ...
• Reliability. ...
• Safety. ...
• Packaging. ...
• References.

Product Specifications

A product specification (also referred to as “product specs”) is a document with a set of

requirements that provides product teams the information they need to build out new features
or functionality.

A good product spec doesn’t micro-manage product development. Rather, it gives them
relevant context about users, business needs and other criteria to help them make informed
decisions as they design and build a solution.
Types of Specifications

• Requirement Specifications. Documentation of a business need. ...

• Design Specifications. Descriptions of how requirements will be realized. ...
• Material Specifications. ...
• Standard Specifications. ... • Interface Specifications. ...
• Test Specifications. ...
• Performance Specifications. ...
• Quality Specifications.

Requirement Engineering
Requirements engineering (RE) refers to the process of defining, documenting, and maintaining
requirements in the engineering design process. Requirement engineering provides the appropriate
mechanism to understand what the customer desires, analyzing the need, and assessing feasibility,
negotiating a reasonable solution, specifying the solution clearly, validating the specifications and
managing the requirements as they are transformed into a working system. Thus, requirement
engineering is the disciplined application of proven principles, methods, tools, and notation to
describe a proposed system's intended behavior and its associated constraints.

Requirement Engineering Process. It is a four-step process, which includes - Feasibility Study

Requirement Elicitation and Analysis
Software Requirement Specification
Software Requirement Validation
Software Requirement Management
1. Feasibility Study:
The objective behind the feasibility study is to create the reasons for developing the software that is
acceptable to users, flexible to change and conformable to established standards.
3.1M
358
Features of Java - Javatpoint Types
of Feasibility:
Technical Feasibility - Technical feasibility evaluates the current technologies, which are needed to
accomplish customer requirements within the time and budget.
Operational Feasibility - Operational feasibility assesses the range in which the required software
performs a series of levels to solve business problems and customer requirements.
Economic Feasibility - Economic feasibility decides whether the necessary software can generate
financial profits for an organization. 2. Requirement Elicitation and Analysis:
This is also known as the gathering of requirements. Here, requirements are identified with the help
of
Getting all, and only, the right people involved. Stakeholders often don't know what they want
Stakeholders express requirements in their terms. Stakeholders may have conflicting requirements.
Requirement change during the analysis process. Organizational and political factors may influence
system requirements.
3. Software Requirement Specification:
Software requirement specification is a kind of document which is created by a software analyst after
the Data Flow Diagrams: Data Flow Diagrams (DFDs) are used widely for modeling the
requirements. DFD shows the flow of data through a system. The system may be a company, an
organization, a set of procedures, a computer hardware system, a software system, or any combination
of the preceding. The DFD is also known as a data flow graph or bubble chart.
Data Dictionaries: Data Dictionaries are simply repositories to store information about all data items
defined in DFDs. At the requirements stage, the data dictionary should at least define customer data
items, to ensure that the customer and developers use the same definition and terminologies. Entity-
Relationship Diagrams: Another tool for requirement specification is the entity-relationship diagram,
often called an "E-R diagram." It is a detailed logical representation of the data for the organization
and uses three main constructs i.e. data entities, relationships, and their associated attributes.

4. Software Requirement Validation: against

the following conditions -
If they can practically implement If they are correct and as per the functionality and specially of
software If there are any ambiguities If they are full If they can describe. Requirements
Validation Techniques
Project Planning

Project planning is an essential part of project management. Discover more in this guide to what it is
and how to create a plan.
Project planning refers to the phase in project management in which you determine the actual steps to
complete a project. This includes laying out timelines, establishing the budget, setting milestones,
assessing risks, and solidifying tasks and assigning them to team members.
Project planning is the second stage of the project management lifecycle. The full cycle includes
initiation, planning, execution, and closing.

Components of a project planning

During the planning phase of the project management lifecycle, you'll determine the steps to achieve
your project goals. This is the "how" of completing the project.
The components of project planning are: tasks, milestones, people, documentation, and time. This step
involves outlining your project scope, objectives, and timeline to make sure all stakeholders are on the
same page.

Tasks: Tasks are activities that need to be accomplished within a set period of time. These are
assigned to different members of the team according to their role and skill set.
Milestones: To go along with tasks, milestones are important points within the schedule that indicate
progress. They tend to signify the completion of a deliverable or phase of the project.
People: A project plan also includes the people working on your team and their roles. It's important
that each team member understands their role and the tasks they're responsible for completing.
Ensuring that everyone is clear on their assigned tasks frees you up to focus on managing the project,
ultimately creating a sense of personal responsibility for team members.
Documentation: During the project planning phase, it is a good idea to draft a project plan that links
to relevant documentation. Besides your project plan, you can include documents like a RACI chart
(Responsibility Assignment Matrix), which defines roles and responsibilities for individuals on your
team. Another document is your charter which defines the project and outlines the details needed to
reach your goals. You can include a budget and risk management plan, if relevant.
Time: Project plans should include the estimated duration of the project. How much time will be spent
on each part? The schedule will be the anchor of your project plan. It includes dates for starting and
completing tasks, and dates (deadlines) for reaching specific milestones. Indicating the project's start
and end dates will help situate this project among competing priorities, and helps determine resources
(including people) needed and when you'll need them.

Top-down and Bottom-up planning

Planning is one of the most important aspects of a successful, enterprise-wide performance

management process. Two of the most common planning approaches are top-down planning and
bottom-up planning methods. Although these two models represent two opposing strategies, they
share similarities in the way a company identifies its key objectives. At a very basic level, the
topdown approach attempts to move from the general to the specific, while the bottom-up approach
finds its way from the specific to the general. In companies, both approaches are often combined to
form a countercurrent process.

What is top-down and bottom-up planning?

Top-down and bottom-up planning is bidirectional planning. It is a combination of top-down and

bottom-up approaches. Planning takes place from top to bottom as well as from bottom to top.
Differences between the two directions are continuously coordinated and coordinated. In detail, these
are methods for integrated business planning as well as for the definition of goals and possibilities for
their achievement.

Top-down
In top-down planning, the first global (framework) objectives are defined and ways of achieving them
are determined. They are gradually moved to the lower levels of the organizational hierarchy to be
developed and specified. This is a divergent approach.

Bottom-Up
With the bottom-up planning method, relatively narrow goals are initially set at the lower levels of the
organizational hierarchy. They are then gradually integrated into the framework of the global goals
and strategy at higher levels. It is therefore a convergent approach.

Top-down vs. Bottom-up?

Top-down planning traditionally involves the definition of corporate goals and their subdivision into
specific goals, which are then dealt with in phases.

• Top-down planning or retrograde planning is an approach that aims to gradually move from
the top to the bottom level of a particular hierarchy. The organization’s management
provides a framework plan with company goals, for example, based on the expected market
development and growth targets, which is broken down into subplans and specified in detail
in the subordinate levels of planning. These subplans in turn serve as outline plans and goals
for the subsequent planning levels.
• The aim of bottom-up planning, or progressive planning, is to create a plan at a lower,
meaningful classification level and then develop it to the higher level. For example,
bottomup planning focuses on specific products or services of a company in a particular
 region and is based on sales forecast data and other information such as production capacity,
department specific costs, and a subjective assessment of market trends by the planner.

Which model is the best fit for my company?

Determining the best model ultimately depends on the nature of the specific business and the resources
available. As an entrepreneur, you need to decide how much control you want over the
implementation of the strategies you need to achieve the key objectives. Top-down and bottom-up
planning techniques each have their own advantages and disadvantages.
Advantages and disadvantages of top-down planning

• The advantage of top-down planning is that the objectives of the subplans across all
hierarchical levels largely correspond to the objectives of the entire company. In addition,
complex and time-consuming coordination tasks are eliminated so that the plan can be created
more quickly.
• The biggest disadvantage of the top-down planning approach results from the fact that
management is only familiar with the opportunities and problems of individual departments in
unique cases. Unrealistic and therefore unattainable targets can be the result.

Advantages and disadvantages of bottom-up planning

• The advantage of bottom-up planning, on the other hand, is that due to the decentralized
approach, planning starts directly from the employees involved. A higher motivation and
identification with the created plan is the result. Employees are directly involved in the
planning process. The plans are generally more realistic.
• A decisive disadvantage of the bottom-up planning approach is the high expenditure of time
and coordination. It can also happen that subplans contradict each other in terms of content
and the bar is set low for organizational goals.

Project scheduling

IT consists of assigning start and end dates to individual tasks and allocating appropriate resources
within an estimated budget. This is what allows you to make sure the team can complete their tasks on
time. It only focuses on the tasks, their deadlines and project dependencies.
the steps in the project scheduling process?
• Plan schedule management. ...
• Define the project activities. ...
• Determine dependencies. ...
• Sequence activities. ...
• Estimate resources. ...
• Estimate durations. ...
• Develop the project schedule. ...
• Monitor and control.

•
1. Plan schedule management
The groundwork for a good project schedule is to establish the procedures, company policies, and
documentation guidelines that will govern your project. The plan for schedule management outlines
resources available for the project and the contingencies that may arise.
It also lists project stakeholders, itemizes individuals who must approve the schedule, and lists others
who need to receive a copy.
This document also establishes who has the authority to make schedule changes, the process team
members should follow in order to request a change, and a project communication plan to alert the
team of changes made during the course of the project. 2. Define the project activities
This can be as simple as creating a list of tasks that must be completed in order to deliver your
project. In the case of complex projects, it may be helpful to organize these tasks in the form of at, a
chart visualizing project tasks and their sub-tasks and to stay organized at work.
One challenge in this part of the project scheduling process is knowing how to divide activities.
Consider the 8/80 rule, which states that a single activity should take between eight and eighty work
hours. In team task management, tasks requiring fewer than eight hours could be grouped with others
and tasks over eighty hours are likely too cumbersome and should be broken down further. Activities
should also be measurable, easily estimated, and related to both a project deliverable and a budgeted
cost. 3. Determine dependencies
Once you have all the project activities listed, think through each one carefully to identify which tasks
rely on others to be completed. If you’re building a house, for example, you can’t put the roof on until
the frame is completed. It’s important to correctly define all your project dependencies so you can
schedule accurately and avoid project delays.
You can use the best project management software to tackle project task dependencies by engaging
with stakeholders, brainstorming constraints related to dependencies. 4. Sequence activities
After you’ve established dependencies among your activities, you can sequence them. At this point,
you aren’t assigning any time to your activities in terms of work hours or due dates. Instead, you’re
focusing on the order in which all project activities should be done so that the most efficient flow is
created. 5. Estimate resources
Each activity in your project will require resources in the form of personnel, subcontractor costs,
tools (physical and/or digital tools like software programs), and workspace. Make sure to consider
other resources that are specific to your industry or project. Estimate the resources needed for
each project activity.

6. Estimate durations
This step is pretty obvious but very important. How long will each project activity take?
Underestimating will, of course, put you behind schedule and ultimately frustrate your customer.
Overestimating could leave team members or other resources sitting idle as they wait for antecedent
tasks to be completed. The best way to estimate duration is to use data from similar previous jobs. If
you don’t have any data to work from and there’s no industry standard to which you can refer, an
estimate based on the average of the best, worst, and most likely scenarios. 7. Develop the project
schedule
At this point, you should have all the information you need to develop your project schedule. Taking
into consideration the duration and resource requirements of each activity, as well as their
dependencies and proper sequence, you can assign start dates and due dates for each activity.
There are multiple models and formulas for developing the project schedule, including critical path,
critical chain, and resource leveling among others. Each of those methods is worthy of an article in
itself, so we won’t cover them here. Take the time to find a method that works well for you.
For example, Don’t ignore the calendar! Check vacation requests from team members. Don’t forget to
include factors like national holidays, corporate functions, stakeholder events, and other occasions that
may affect your schedule. If the whole company shuts down for a holiday week, you’ll need to add
that time to your due dates and manage customer expectations accordingly.
8. Monitor and control
Unlike the rest of the project scheduling steps, Step 8 is ongoing. As a project manager, you’ll be
monitoring and controlling your project schedule for the duration of the project. This step
involves running project reports and assessing the progress of a project against the schedule,
managing performance, and communicating with the team.
When schedule changes must be made, you ensure they are carried out and communicated according
to the plan laid out in Step 1. Throughout the project, you will ensure that each activity is on schedule
and determine whether corrective action needs to be taken if delays occur., how long each task will
last, task dependencies, and where there are overlaps.

Work Breakdown Structure (WBS).

Dividing complex projects to simpler and manageable tasks is the process identified as Work
Breakdown Structure (WBS).
Usually, the project managers use this method for simplifying the project execution. In WBS, much
larger tasks are broken down to manageable chunks of work. These chunks can be easily supervised
and estimated.
WBS is not restricted to a specific field when it comes to application. This methodology can be used
for any type of project management.
Following are a few reasons for creating a WBS in a project:
• Accurate and readable project organization.
• Accurate assignment of responsibilities to the project team.
• Indicates the project milestones and control points.
• Helps to estimate the cost, time and risk.
• Illustrate the project scope, so the stakeholders can have a better understanding of the
same.
Construction of a WBS
Identifying the main deliverables of a project is the starting point for deriving a work breakdown
structure.
This important step is usually done by the project managers and the subject matter experts (SMEs)
involved in the project. Once this step is completed, the subject matter experts start breaking down the
high-level tasks into smaller chunks of work.
In the process of breaking down the tasks, one can break them down into different levels of detail. One
can detail a high-level task into ten sub-tasks while another can detail the same high-level task into 20
sub-tasks.
Therefore, there is no hard and fast rule on how you should breakdown a task in WBS. Rather, the
level of breakdown is a matter of the project type and the management style followed for the project.
In general, there are a few "rules" used for determining the smallest task chunk. In "two weeks" rule,
nothing is broken down smaller than two weeks worth of work.
This means, the smallest task of the WBS is at least two-week long. 8/80 is another rule used when
creating a WBS. This rule implies that no task should be smaller than 8 hours of work and should not
be larger than 80 hours of work.
One can use many forms to display their WBS. Some use tree structure to illustrate the WBS, while
others use lists and tables. Outlining is one of the easiest ways of representing a WBS.
Following example is an outlined WBS:

There are many design goals for WBS. Some important goals are as follows:
• Giving visibility to important work efforts.
• Giving visibility to risky work efforts.
• Illustrate the correlation between the activities and deliverables.
• Show clear ownership by task leaders.
WBS Diagram
In a WBS diagram, the project scope is graphically expressed. Usually the diagram starts with a
graphic object or a box at the top, which represents the entire project. Then, there are sub-components
under the box.
These boxes represent the deliverables of the project. Under each deliverable, there are sub-elements
listed. These sub-elements are the activities that should be performed in order to achieve the
deliverables.
Although most of the WBS diagrams are designed based on the deliveries, some WBS are created
based on the project phases. Usually, information technology projects are perfectly fit into WBS
model.
Therefore, almost all information technology projects make use of WBS.
In addition to the general use of WBS, there is specific objective for deriving a WBS as well. WBS is
the input for Gantt charts, a tool that is used for project management purpose.
Gantt chart is used for tracking the progression of the tasks derived by WBS.
Following is a sample WBS diagram:

Conclusion
The efficiency of a work breakdown structure can determine the success of a project.
The WBS provides the foundation for all project management work, including, planning, cost and
effort estimation, resource allocation, and scheduling.
Therefore, one should take creating WBS as a critical step in the process of project management.

COCOMO MODEL

Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines of
Code. It 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 which define the quality of any software products, which are also an outcome of
the Cocomo are primarily Effort & Schedule:
• Effort: Amount of labor that will be required to complete a task. It is measured in person-
months units.
• Schedule: 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.
Different models of Cocomo have been proposed to predict the cost estimation at different levels,
based on the amount of accuracy and correctness required. All of these models can be applied to a
variety of projects, whose characteristics determine the value of the constant to be used in
subsequent calculations.
These characteristics pertaining to different system types are mentioned below. Boehm’s definition of
organic, semidetached, and embedded systems:
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
environment lie in between that of 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 and 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 fall 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.
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Detailed COCOMO Model
1. Basic Model –

The above formula is used for the cost estimation of for 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

The effort is measured in Person-Months and as evident from the formula is dependent on KiloLines
of code. The development time is measured in months. 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.
Effort = 10.289 Person-Month
Development Time = 6.06237 Months
Average Staff Required = 2 Persons
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 on the
basis of 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:
(i) Product attributes –
• Required software reliability extent
• Size of the application database
• The complexity of the product
• Run-time performance constraints
• Memory constraints
• The volatility of the virtual machine environment
• Required turnabout time
• Analyst capability
• Software engineering capability
• Applications experience
• Virtual machine experience
• Programming language experience
• Use of software tools
• Application of software engineering methods
• Required development schedule
•
3. Detailed Model – Detailed COCOMO incorporates all characteristics of the intermediate version
with an assessment of the cost driver’s impact on each step of the software engineering process. The
detailed model uses different effort multipliers for each cost driver attribute. In detailed cocomo, the
whole software is divided into different modules and then we apply COCOMO in different modules to
estimate effort and then sum the effort. 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
Advantages of the COCOMO model:
1. Provides a systematic way to estimate the cost and effort of a software project.
2. Can be used to estimate the cost and effort of a software project at different stages of the
development process.
3. Helps in identifying the factors that have the greatest impact on the cost and effort of a
software project.
4. 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 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 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. Does not provide a precise estimate of the cost and effort of a software project, as it is
based on assumptions and averages.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^