ZeePedia buy college essays online

Software Project Management

<<< Previous Estimation - Concepts Next >>>
Software Project Management (CS615)
Estimation - Concepts
Watts Humphrey in his book, Managing the Software process, has said, "If you
don't know where you are, a map won't help." This saying is very relevant while
dealing with software project estimation. In a software project, unless you are sure
that your estimation is accurate, you cannot make much progress.
Estimation of factors such as cost, effort, risks, and resources is crucial. It gives
you a fair idea of the size of the project. You can use the information about size to
estimate the cost, effort, and duration of the project. This further helps plan for
resources and schedule the project.
In the early days of computing, software costs constituted a small percentage of
the overall computer-based system cost. An order of magnitude error in estimates
of software cost had relatively little impact.
Today, software is the most expensive element of virtually all computer-based
systems. For complex, custom systems, a large increased cost estimation error can
make the difference between profit and loss. Cost overrun can be disastrous for
the developer.
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.
However, software project estimation can be transformed from a black art to a
series of systematic steps that provide estimates with acceptable risk.
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%
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 for software cost and effort estimation.
Unfortunately, the first option, however attractive, is not practical. Cost estimates
must be provided 'up front.' However, we should recognize that the longer we
Software Project Management (CS615)
wait, the more we know, and the more we know, the less likely we are to make
serious errors in our estimates.
The second option can work reasonably well, if the current project is quite similar
to past efforts and other project influences (e.g., the customer, business
conditions, the SEE, deadlines) are equivalent. Unfortunately, past experience has
not always been a good indicator of future results.
The remaining options are viable approaches to software project estimation.
Ideally, the techniques noted for each option should be applied in tandem; each
used as a cross-check for the other.
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, we
decompose the problem, re-characterizing it as a set of smaller (and hopefully,
more manageable) problems.
Following are some points related to project estimation:
Estimation is very difficult to do, but is often needed
It is created, used or refined during
Strategic planning
Feasibility study and/or SOW
Vendor and sub-contractor evaluation
Project planning (iteratively)
Basic process involves:
Estimate the size of the product
Estimate the effort (man-months)
Estimate the schedule
NOTE: Not all of these steps are always explicitly performed
Estimation ­ A Critical factor
In a software project, unless you are sure that your estimation is accurate, you
cannot make much progress.
Estimation of following factors are essential:
Software Project Management (CS615)
Estimation gives you a fair idea of the size of the project. You can use the
information about size to estimate the cost, effort, and duration of the project.
This further helps plan for resources and schedule the project.
Estimation of resources, cost, and schedule for a software engineering effort
Access to good historical information
Courage to commit to quantitative predictions when qualitative
information is all that exists
Estimation carries inherent risk and this risk leads to uncertainty.
Project complexity
Project size
The degree of structural uncertainty
The availability of historical information
a) Project complexity has a strong effect on the uncertainty, inherent in planning.
Complexity, however, is a relative measure that is affected by familiarity with
past effort. The first-time developer of a sophisticated e-commerce application
might consider it to be exceedingly complex. However, a software team
developing its tenth e-commerce Web site would consider such work run of the
mill. A number of quantitative software complexity measures can be applied as
per the need of project. Such measures are applied at the design or code level and
are therefore difficult to use during Software planning (before a design and code
exist). However, other, more subjective assessments of complexity (e.g., the
function point complexity adjustment factors) can be established early in the
planning process.
b) Project size is another important factor that can affect the accuracy and efficacy
of estimates. As size increases, the interdependency among various elements of
the software grows rapidly. Problem decomposition, an important approach to
estimating, becomes more difficult because decomposed elements may still be
alarming. To paraphrase Murphy's Law: "What can go wrong will go wrong"- and
if there are more things that can fail, more things will fail.
c) The degree of structural uncertainty has an effect on estimation risk. In this
context, structure refers to the degree to which requirements have been solidified,
the ease with which functions can be compartmentalized and the hierarchical
nature of the information that must be processed.
Software Project Management (CS615)
d) The availability of historical information has a strong influence on estimation
risk. By looking back, we can emulate things that worked and improve areas
where problems arose.
e) When comprehensive software metrics are available for past projects, estimates
can be made with greater assurance, schedules can be established to avoid past
difficulties, and overall risk is reduced.
f) Risk is measured by the degree of uncertainty in the quantitative estimates
established for resources, cost, and schedule. If project scope is poorly
understood or project requirements are subject to change, uncertainty and risk
become dangerously high.
The software planner should demand completeness of function, performance, and
interface definitions (contained in a System Specification). The planner, and more
important, the customer should recognize that variability in software requirements
means instability in cost and schedule.
Table of Contents:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration