Time And Effort Estimations As Software Project example essay topic

TABLE OF CONTENTS 1. ACKNOWLEDGEMENTS 2. ABSTRACT 3. INTRODUCTION 4. S / W PROJECT ESTIMATION Size Estimation Effort Estimation Time Estimation Cost Estimation 5. RISK & TEAM DYNAMICS IN S / W ESTIMATION Risk Team Dynamics 6.

SOME ESTIMATION TERMINOLOGY 7. CASE STUDY 8. CONCLUSION 9. APPENDIX 10. REFERENCES ACKNOWLDEGEMENTS We are very thankful to our lecturer Mr. Anand and tutor Mr. Vivek Handa for their support in doing this assignment. We are also thankful to our library staff for providing course books and good reference books to us.

ABSTRACT The main aim of this essay is to provide a good understanding on project estimation. Improving the estimation techniques is as equally important as improving the development techniques. This document proposes a perfect estimation process for project size, effort, cost and time especially when considered in relation to project progress. This document contains the estimates used at various stages in a project with estimating techniques used, and the variety of messages communicated and the effect on the project including risk and team dynamics. Based on the size estimates obtained from the size models, this document presents the practical application in conducting software cost, time and effort estimation techniques to estimate the project schedule, effort and the development cost of the software project. Finally this paper demonstrates and practically imposed all of the tools and techniques in the online student registration database case study.

INTRODUCTION An estimate is a projection from past to future, suitably adjusted to account for differences between past and future. - past: history of past projects - future: requirements - adjustment factors: locally determined Our Project Estimation Practice covers a range of services including: validating existing plans, implementing automated estimation tools, implementing function point sizing techniques, linking project estimation to project management initiatives, and collecting historical project data to improve future estimation efforts. For large development projects, the estimation step should really be regarded as a mini project. Few organizations have established formal estimation processes, despite evidence that suggests organizations without formal estimation are four times more likely to experience cancelled or delayed projects. The main goals of Estimation process are o Consistency o Documentation and History of Estimates o Continuing effort to bring estimates closer to actual Project estimation is one of the most important portions in providing a software solution due to the following reasons - It states the effort required implementing the solution, which in turn results in to financial requirements for the implementation. - It includes the implementation schedules, which can be used for future planning and marketing, if necessary. "A study by the Standish Group in 1995 showed that on average only 16% of projects are completed successfully, 31% were cancelled and 53% were over budget and schedule".

This failure is basically because of bad estimates. SOFTWARE PROJECT ESTIMATION Effective software project estimation is one of the most challenging and important activities in software development. Proper project planning and control is not possible without a sound and reliable estimate. As a whole, the software industry doesn't estimate projects well and doesn't use estimates appropriately. We suffer far more than we should as a result and we need to focus some effort on improving the situation. Under-estimating a project leads to under-staffing, under scoping quality assurance, and setting too short a schedule leads to low quality deliverables and loss of credibility.

Over-estimating a project can be just about as bad for the organization! If you give a project more resources than it really needs without sufficient scope controls it will use them. The project is then likely to cost more than it should. For those who figure on avoiding this situation by generously padding the estimate. The four basic steps in software project estimation are: 1) Estimate the size of the development product. 2) Estimate the effort in person-months or person-hours.

3) Estimate the schedule in calendar months. 4) Estimate the project cost in dollars (or local currency) SIZE ESTIMATION An accurate estimate of the size of the software to be built is the first step. Sources of information regarding the scope of the project should be used as a start. The main approaches to estimate product sizes are: By analogy - Having done a similar project in the past and knowing its size, it is then possible to estimate each piece of the new project, as a percentage of the size of a similar piece in a previous project. The total project size can be estimated by adding up the size of the individual pieces. It is possible to produce a reasonably good size estimate by this method if accurate values are available for the previous project and if the new project is sufficiently similar.

By counting product features and using an algorithmic approach such as Function Points to convert the count into an estimate of size. Macro-level "product features" may include the number of subsystems, classes / modules, and methods / functions. More detailed "product features" may include the number of screens, dialogs, files, database tables, reports, messages, and so on. EFFORT ESTIMATION Once the size estimation process finishes, we can derive the effort estimate.

This conversion from software size to total project effort can only be done if we have a defined software development lifecycle and development process that you follow to specify, design, develop, and test the software. Writing and reviewing documentation, implementing prototypes, designing the deliverables, and reviewing and testing the code take up the larger portion of overall project effort. The project effort estimate requires identifying and estimating, and then sum up all the activities we need to build a product of the estimated size. The two main ways to derive effort from size are: 1) Using organization's own historical data to determine how much effort previous projects of the estimated size have taken. This, of course, assumes (a) Our organization has been documenting actual results from previous projects (b) That we have at least one past project of similar size (c) That we will follow a similar development lifecycle, use a similar development methodology, use similar tools, and use a team with similar skills and experience for the new project.

2) If we don't have historical data from our own organization because we haven't started collecting it yet or because our new project is very different in one or more key aspects. We can use a mature and generally accepted algorithmic approach such as Barry Bohemia's CO COMO model or the Putnam Methodology to convert a size estimate into an effort estimate. Studying a significant number of completed projects from various organizations to see how their project sizes mapped into total project effort has derived these models. NOTE: These "industry data" models may not be as accurate as our own historical data, but they can give us useful ballpark effort estimates. TIME ESTIMATION Good time estimation is a very important success factor in a project. Time estimation in software projects is not an easy task.

Most software projects fail because the project is not finished on time. There are no mathematical algorithms that will calculate the exact number of hours that is required to finish our project. But there are good practices, rules of thumb and advises that can help us to make good time estimations. Basically this is the third step in estimating a software development project to determine the project schedule from the effort estimate. This generally involves estimating the number of people who will work on the project, what they will work on (the Work Breakdown Structure), when they will start working on the project and when they will finish (this is the "staffing profile"). Once we have this information, we need to lay it out into a calendar schedule.

Again, historical data from our organization's past projects or industry data models can be used to predict the number of people we will need for a project of a given size and how work can be broken down into a schedule. If we have nothing else, a schedule estimation rule of thumb [McConnell 1996] can be used to get a rough idea of the total calendar time required: Schedule in months = 3.0 (effort-months) 1/3 Opinions vary as to whether 2.0 or 2.5 or even 4.0 should be used in place of the 3.0 value - only by trying it out will you see what works for us. COST ESTIMATE Cost estimating involves developing an approximation (estimate) of the costs of the resources needed to complete project activities. Inputs to the cost estimating are Work Breakdown Structure, Resource requirements, Resource rates, Activity duration estimates, Estimating publications, Historical information, Chart of accounts, Risks. Tools and Techniques for Cost Estimating Analogous Estimating: Analogous estimating, also called top-down estimating.

This means, using the actual cost of a previous, similar project as the basis for estimating the cost of the current project. It is frequently used to estimate total project costs when there is a limited amount of detailed information about the project (e.g. in the early phases). Parametric modeling: It involved using project characteristics (parameters) in a mathematical model to predict project costs. Models may be simple or complex. Bottom-up estimating: It involves estimating the cost of individual activities or work packages, then summarizing or rolling up the individual estimates to get t a project total.

The size and complexity of the individual activity or work package drive the cost and accuracy of bottom-up estimating. Computerized tools: Computerized tools like software spreadsheets are widely used to assist with cost estimating. Software cost estimation is a major task. It must be well planned, carefully reviewed and continually updated. Good estimation comes from a good understanding of the requirements. A well thought project plan helps an estimator to better understand the requirements.

Hence, a well thought project plan helps to obtain a good cost estimation. SCE is an iterative process, WBS must be updated constantly to reflect the up-today status of the project There are many factors to consider when estimating the total cost of a project. These include labor, hardware and software purchases or rentals, travel for meeting or testing purposes, telecommunications, training courses, office space, and so on. RISK AND TEAM DYNAMICS IN SOFTWARE ESTIMATION RISK Though a suite of estimation techniques is available, cost and schedule overruns still and will continue to exist. The problem stems from an inability to accurately assess risks associated with various software development projects.

Actually running away from the risk is non-working strategy. We need to run towards it by developing ways to discover the lurking risks, estimate their impact, optimize our response, and monitor for change. These are the essential skills of Risk Management. The risks can be summarized into the following three areas: 1. The size and schedule are not correctly estimated. This results in poor implementations, emergency staffing and cost overrun caused by underestimating project needs.

2. The improper assessment of staff skill levels. This result in misalignment of skills to task and ultimately miscalculations of schedules and level of effort required, as well as either underestimating or overestimating project staffing requirements. 3.

The lack of well defined objectives, requirements and specifications or unconstrained requirements growth during the software development life cycle. This results in forever changing project goals, frustration, and of course, cost overrun. TEAM DYNAMICS: Team dynamics is also an important factor for the project success. 1. Team-building techniques Recognize and apply the basic steps in team building: goals, roles and responsibilities, introduction's, and both stated and hidden agendas. (synthesis) 2. Team facilitation techniques Apply coaching, mentoring, and facilitation techniques to guide a team and overcome problems such as overbearing, dominant, or reluctant participants etc. (application) 3.

Team performance evaluation Measure team progress in relation to goals, objectives, and metrics that support team success. (analysis) 4. Team tools Define, select, and apply team tools such as nominal group technique, force field analysis, cultivating, and conversion / diversion. (application) All potential risks and team building principles must be carefully defined and the impact to project estimation must be determined. This should be part of the software cost estimation. Thus, it is important to integrate risk impact into the cost, Time and effort estimations as software project is bound to have surprises.

CASE STUDY Project Estimation This section will illustrate methods used to estimate an approximate size, time, cost and effort needed to build an Online Student Registration System. There are three types of data that will be stored: student, administrator, and course data in our database. Student Data contains name, address, phone, date of birth etc and requires about 77 070 000 bytes or 77 Mbytes (For 10,000 Students). Administrator Data have name, date of birth, PIN, SSN etc and requires about 67 000 bytes or 67 Kbytes (For 1,000 faculty). Course Database contains course title, section, units, room and time etc requires about 29 400 000 bytes or 29 Mbytes. The total database size is: 77 Mbytes + 29 Mbytes + 67 Kbytes = 106 Mbytes This size total is relatively small and can be easily accommodated in a database server environment.

Resources From the scope we can derive the following major functions. For each of these functions we can estimate how many lines of code (LOC) will be needed. Lines of Code Estimation: Major Function / Task Estimated Lines of Code (LOC) Student Login 400 Search Catalog 300 Check Academic History 300 Register for Classes 300 Pay Balance 1200 Administrator Login 400 Update Catalog 300 Update Student Accounts 300 Total 3500 Effort, Cost and Time: A team of five engineers will develop the product for the customer. Each engineer costs about $40.00 per hour plus the manager who costs $80.00 per hour. Engineer Estimated Hours Estimated Cost Naveen 291 $11,640 Surendra 222 $8,880 Ramesh 261 $10,440 Shiva 167 $7,000 Phani 136 $10,880 Total Estimated Cost $48,840 Off-The-Shelf Products This project will make use of off-the-shelf products to cut project costs and time down to a minimum. For the database, Microsoft's SQL Server software will be needed.

Microsoft licenses their software based on the number of processors in your system at $5,000 per processor. Since we will have three servers each having 4 processors, there will be a total of 12 processors totaling $60,000. Total miscellaneous cost to hold and access severs: $2873 An estimate of the total cost of all required resources sums ups to $193,474. Team dynamics: For this case, we will organize the five-member team as a CD (Controlled Decentralized) team structure.

A CD structure will yield a higher quality product for the customer. Although a CD structure is good for addressing very large project, we will apply this structure to a smaller group in order to keep the scope in focus. Online student registration system consists of four people: Naveen, Surendra, Ramesh, Shiva and Phani. Naveen is the manager and will coordinate specific tasks including assigning tasks to other engineers and placing controlling and tracking mechanisms for the project. Surendra, Ramesh have responsibilities in implementation, software testing. Shiva and Phani did operation maintenance.

This team structure will allow problems to be solved horizontally. The team leader will communicate vertically with each engineer, thus keeping the project in focus. Vertical Communication CONCLUSION Hopefully the above will help but there are too many unknowns for any hard and fast rules or concrete assurance that what is predicted will eventually be. The estimates obtained are used best for planning with regular feedback and re-estimation as the project progresses. At regular points throughout the project lifecycle revisit all the estimates and assumptions and re-calculate them using the latest information available. The realities of life are: i.

It is impossible to predict the future 100% ii. We will have a better idea of what to expect if you try to predict the future rather than if you don't bother at all. Our predictions will be more accurate if they apply to the short term rather than to the long term. APPENDIX SOME ESTIMATION TERMINOLOGY or GLOSSARY A Activity - An element of work normally found on the WBS, that has an expected duration, cost, and resource requirements; also called task. Activity duration estimation - Estimating the number of work periods that are needed to complete individual activities.

B Base line - The original project plans plus approved changes. C Cost of quality - The cost of conformance plus the cost of nonconformance. Cost of variance - The earned value minus the actual cost. D Duration - The actual amount of time worked on an activity plus elapsed time. G Gantt chart - A standard format for displaying project schedule information by listing project activities and their corresponding start and finish dated in a calendar format. L Lesson learned - Reflective statements written by project managers and their team members.

M Mile stone - A significant event on a project with zero duration. P Project Temporary endeavor undertaken to create or provide service or product. Project schedule (a. k. a., work-breakdown-structure) - Hierarchical decomposition of project into phases, activities, and tasks with resources and dependencies. S Stake holders - People involved in or affected by project activities. T Test subproject: The subset of the project performed by the test team to provide test services to the project.

Bibliography

BOOKS: 1. PMI (2000) A Guide to the Project Management Body of Knowledge (PM BOK guide) 2000, 2nd ed.
PMI 2. Schwalbe, K (2001) Information Technology Project Management, 2nd edition, Course Technology, Cambridge 3.
Kendall & Kendall, Systems analysis and Design, 4th edition, Prentice hall, Inc WEBSITES AND MAGAZINES: 1. Accessed from web on 14/09/2003, copyright (c) 2001 Business.
com, Inc. All Rights Reserved 2. Accessed from web on 15/09/2003, copyright (c) 1998-2003 Richard Brenner 3.
Accessed from web on 1/09/2003, copyright (c) 2000 Trinity College, Dublin.
All Rights Reserved 4. Accessed from web on 16/09/2003, copyright (c) DSI OJ 2002.
All Rights Reserved 5. Accessed from web on 20/09/2003, copyright (c) 2003 by Carnegie Mellon University.