Author Topic: Applied Software Project Management Software Project Planning Estimation Techni  (Read 3252 times)

0 Members and 1 Guest are viewing this topic.

IJSER Content Writer

  • Sr. Member
  • ****
  • Posts: 327
  • Karma: +0/-1
    • View Profile
Quote
Author : T.Rajani Devi
International Journal of Scientific & Engineering Research Volume 3, Issue 1, January-2012
ISSN 2229-5518
Download Full Paper : PDF

Abstract - Most critical activities in the modern software development process is without a realistic and objective software project plan, the software development process cannot be managed in an effective way. The purpose of project planning is to identify the scope of the project, estimate the work involved, and create a project schedule. Project planning begins with requirements that define the software to be developed. The project plan is then developed to describe the tasks that will lead to completion. software and project estimation techniques existing in industry and literature, it has strengths and weaknesses. Usage, popularity and applicability of such techniques are elaborated. In order to improve estimation accuracy, such knowledge is essential. Many estimation techniques, models, methodologies exists and applicable in different categories of projects. None of them gives 100% accuracy but proper use of them makes estimation process smoother and easier. Organizations should automate estimation procedures, customize available tools and calibrate estimation approaches as per their requirements.

Key Words- Black art, business domain, fair estimate, granularity, magnitude, magnitude estimate, quibble, rough estimate, starved, weighing factors.

1  Introduction
 
SOFTWARE project management begins with a set of activities that are collectively called project planning. Before the project can begin, the manager and the software team must estimate the work to be done, the resources that will be required, and the time that will elapse from start to finish. Whenever estimates are made, we look into the future and accept some degree of uncertainty as a matter of course. Software project planning actually encompasses several activities planning involves estimation—the attempt to determine how much money, how much effort, how many resources, and how much time it will take to build a specific software-based system or product. The appropriate software is for everyone in the project to understand and agree on both why and how that software will be built before the work begins. That’s the purpose of project planning process cannot be managed in an effective way. Project planning is an aspect of Project Management that focuses a lot on Project Integration. The project plan reflects the current status of all project activities and is used to monitor and control the project. The Project Planning tasks ensure that various elements of the Project are coordinated and therefore guide the project execution.
Project Planning helps in - Facilitating communication - Monitoring/measuring the project progress, and - Provides overall documentation of assumptions/planning decisions.
The Project Planning Phases can be broadly classified as follows: -Development of the Project Plan - Execution of the Project Plan - Change Planning is an ongoing effort throughout the Project Lifecycle.
 
Fig 1: project life cycle

2  Objectives
The objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule.
These estimates are made within a limited time frame at the beginning of a software project and should be updated regularly as the project progresses.
In addition, estimates should attempt to define best case and worst case scenarios so that project outcomes can be bounded.
The planning objective is achieved through a process of information discovery that leads to reasonable estimates.

3 Useful Estimation Techniques for Software Projects

3.1 The Importance of Good Estimation
Software projects are typically controlled by four major variables; time, requirements, resources (people, infrastructure/materials, and money), and risks. Unexpected changes in any of these variables will have an impact on a project. Hence, making good estimates of time and resources required for a project is crucial. Underestimating project needs can cause major problems because there may not be enough time, money, infrastructure/materials, or people to complete the project. Overestimating needs can be very expensive for the organization because a decision may be made to defer the project because it is too expensive or the project is approved but other projects are "starved" because there is less to go around.
In my experience, making estimates of time and resources required for a project is usually a challenge for most project teams and project managers. It could be because they do not have experience doing estimates, they are unfamiliar with the technology being used or the business domain, requirements are unclear, there are dependencies on work being done by others, and so on. These can result in a situation akin to analysis paralysis as the team delays providing any estimates while they try to get a good handle on the requirements, dependencies, and issues. Alternatively, we will produce estimates that are usually highly optimistic as we have ignored items that need to be dealt with. How does one handle situations such as these?

3.2 We provide reliable estimates
Programmers often consider estimating to be a black art—one of the most difficult things they must do. Many programmers find that they consistently estimate too low. To counter this problem, they pad their estimates (multiplying by three is a common approach) but sometimes even these rough guesses are too low.
Are good estimates possible? Of course! You just need to focus on your strengths.

3.3 What Works (and Doesn't) in Estimating
Part of the reason estimating is so difficult is that programmer can rarely predict how they will spend their time. A task that requires eight hours of uninterrupted concentration can take two or three days if the programmer must deal with constant interruptions. It can take even longer if the programmer works on another task at the same time.
Part of the secret to good estimates is to predict the effort, not the calendar time that a project will take. Make your estimates in terms of ideal engineering days (often called story points): the number of days a task would take if you focused entirely on it and experienced no interruptions.
Ideal time alone won't lead to accurate estimates. I've asked some of the teams I've worked with to measure exactly how long each task takes them. One team gave me 18 months of data, and even though we estimated in ideal time, the estimates were never accurate.
Still, they were consistent. For example, one team always estimated their stories at about 60% of the time they actually needed. This may not sound very promising. How useful can inaccurate estimates are, especially if they don't correlate to calendar time? Velocity holds the key.

Read More: Click here...