software project estimation
 In Software Engineering, accurately estimating the size of a project is key to its success.
Understanding how big a project will be helps predict the resources, time, and cost
needed,
 Accurate project size estimation is important for effective and efficient project planning,
management, and execution.
 Software cost and effort estimation will never be an exact science. Too many variables—
human, technical, environmental, political—can affect the ultimate cost of software and
effort applied to develop it.
To achieve reliable cost and effort estimates, a number of options arise:
1 Delay estimation until late in the project (obviously, we can achieve 100 per
cent accurate estimates after the project is complete!).
2. Base estimates on similar projects that have already been completed.
3. Use relatively simple decomposition techniques to generate project cost and
effort estimates.
4. Use one or more empirical models(practical experience) for software cost and effort
estimation.
Importance of Project Size Estimation
Here are some of the reasons why project size estimation is critical in project
management:
 Financial Planning: Project size estimation helps in planning the financial aspects
of the project, thus helping to avoid financial shortfalls.
 Resource Planning: It ensures the necessary resources are identified and
allocated accordingly.
 Timeline Creation: It facilitates the development of realistic timelines and
milestones for the project.
 Identifying Risks: It helps to identify potential risks associated with overall project
execution.
 Detailed Planning: It helps to create a detailed plan for the project execution,
ensuring all the aspects of the project are considered.
 Planning Quality Assurance: It helps in planning quality assurance activities and
ensuring that the project outcomes meet the required standards.
Who Estimates Projects Size?
Here are the key roles involved in estimating the project size:
• Project Manager: Project manager is responsible for overseeing the estimation process.
• Subject Matter Experts (SMEs): SMEs provide detailed knowledge related to the specific areas of
the project.
• Business Analysts: Business Analysts help in understanding and documenting the project
requirements.
• Technical Leads: They estimate the technical aspects of the project such as system design,
development, integration, and testing.
• Developers: They will provide detailed estimates for the tasks they will handle.
• Financial Analysts: They provide estimates related to the financial aspects of the project including
labor costs, material costs, and other expenses.
• Risk Managers: They assess the potential risks that could impact the projects' size and effort.
Clients: They provide input on project requirements, constraints, and expectations
Decomposition techniques
Software project estimation is a form of problem solving, and in most cases, the problem to be
solved (i.e., developing a cost and effort estimate for a software project) is too complex to be
considered in one piece.
For this reason, you should decompose the problem, recharacterizing it as a set of smaller
(and hopefully, more manageable) problems.
Project scheduling
Although there are many reasons why software is delivered late, most can be traced
to one or more of the following root causes:
• An unrealistic deadline established by someone outside the software team and
forced on managers and practitioners
• Changing customer requirements that are not reflected in schedule changes
• An honest underestimate of the amount of effort and/or the number of resources
that will be required to do the job.
• Predictable and/or unpredictable risks that were not considered when the project
commenced
• Technical difficulties that could not have been foreseen in advance
• Human difficulties that could not have been foreseen in advance.
• Miscommunication among project staff that results in delays.
• A failure by project management to recognize that the project is falling behind
schedule and a lack of action to correct the problem.
I recommend the following steps in this situation:
• Perform a detailed estimate using historical data from past projects. Deter mine the
estimated effort and duration for the project
• Using an incremental process model (Chapter 2), develop a software engi neering
strategy
Defining task network(A task network, also called an activity network, is a graphic
representation of the task flow for a project. )
• Individual tasks and subtasks have interdependencies based on their sequence
• In addition, when more than one person is involved in a software engineering project,
it is likely that development activities and tasks will be performed in parallel.
• When this occurs, concurrent tasks must be coordinated so that they will be complete
when later tasks require their work product(s).
• Figure 27.2 shows a schematic task network for a concept development project.
What are the following projects should be encountererd during the defining task set
for software product.
1. Concept development projects that are initiated to explore some new business
concept or application of some new technology.
2.
New application development projects that are undertaken as a consequence of a
specific customer request.
3. Application enhancement projects that occur when existing software under goes
major modifications to function, performance, or interfaces that are observable by
the end user.
4. Application maintenance projects that correct, adapt, or extend existing soft ware
in ways that may not be immediately obvious to the end user.
5.
Reengineering projects that are undertaken with the intent of rebuilding an
existing (legacy) system in whole or in part.
Even within a single project type, many factors influence the task set to be chosen.
These include [Pre05]: size of the project, number of potential users, mission criti cality,
application longevity, stability of requirements, ease of customer/developer
communication, maturity of applicable technology, performance constraints, em bedded
and nonembedded characteristics, project staff, and reengineering factors.
What are the different ways to track the schedule.
If it has been properly developed, the project schedule becomes a road map that
defines the tasks and milestones to be tracked and controlled as the project proceeds.
Tracking can be accomplished in a number of different ways:
• Conducting periodic project status meetings in which each team member reports
progress and problems
• Evaluating the results of all reviews conducted throughout the software engineering
process
• Comparing the actual start date to the planned start date for each project task listed
in the resource table (Figure 27.4)
Define risk management? Explain reactive versus proactive strategies.
Risk Management is a systematic process of recognizing, evaluating, and handling
threats or risks that have an effect on the finances, capital, and overall operations of an
organization.
These risks can come from different areas, such as financial instability, legal issues,
errors in strategic planning, accidents, and natural disasters
Reactive RCA is a root cause analysis that is performed after the occurrence of failure
or defect.
It is simply done to control, implemented to reduce the impact and severity of defect
that has occurred.
It is also known as reactive risk management. It reacts quickly as soon as problem
occurs by simply treating symptoms.
Proactive RCA is a root cause analysis that is performed before any occurrence of
failure or defect.
It is simply done to control, implemented to prevent defect from its occurrence. As
both reactive and proactive RCAs are is important, one should move from reactive to
proactive RCA.
It is better to prevent issues from its occurrence rather than correcting it after its
occurrence.
In simple words, Prevention is better than correction
Write a short note on Software Risks.
risk always involves two character istics: uncertainty—the risk may or may not happen;
that is, there are no 100 percent probable risks1—and loss—if the risk becomes a reality,
unwanted consequences or losses will occur
1 Project risks threaten the project plan. That is, if project risks become real, it is likely
that the project schedule will slip and that costs will increase.
2 Technical risks threaten the quality and timeliness of the software to be produced.
3 Business risks threaten the viability of the software to be built and often jeopard ize
the project or the product. Candidates for the top five business risks are
(1) build ing an excellent product or system that no one really wants (market risk),
(2) building a product that no longer fits into the overall business strategy for the
company (strategic risk),
(3) building a product that the sales force doesn’t understand how to sell (sales risk), (4)
losing the support of senior management due to a change in focus or a change in people
(management risk), and
(5) losing budgetary or personnel commitment (budget risks).
What are the generic subcategories of risk identification.
following generic subcategories:
• Product size—risks associated with the overall size of the software to be built or
modified.
• Business impact—risks associated with constraints imposed by management or the
marketplace
• Stakeholder characteristics—risks associated with the sophistication of the stakeholders
and the developer’s ability to communicate with stakeholders 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.