We just completed a series of articles detailing how to use Use Case Points for software cost estimation. In this article we have a free MS Excel Spreadsheet for calculating use case points. Download it today to make it easier to do your project cost estimations.
Business Analysis / Product Management / Project Management / Requirements / Requirements Models / Use Cases
Posted on:
Software Cost Estimation With Use Case Points – Final Calculations
The final step in project cost estimation with use case points is to do the math. First you identify the technical and environmental factors that influence your environment and describe your team. Then you analyze the use cases and actors that describe the expectations of the software and who has them. Finally, you bring it all together to do the math.
Business Analysis / Product Management / Project Management / Requirements / Requirements Models / Use Cases
Posted on:
Software Cost Estimation With Use Case Points – Actor Analysis
Software project cost estimation using use case points takes the approach of estimating the amount of effort based upon what the software is being asked to do – not an analysis of how someone chooses to do it. We’ve looked at technical and environmental factors that influence our estimate. And we’ve done a use case analysis to quantify how much work the software is being asked to do. The last area of analysis focuses on the users of the software.
Business Analysis / Product Management / Project Management / Requirements / Requirements Models / Use Cases
Posted on:
Software Cost Estimation With Use Case Points – Use Case Analysis
Software cost estimation with use case points is primarily driven by use case analysis. You take into account environmental and technical factors, but they are ultimately only modifiers of the analysis done on the use cases. Each use case contributes to the project cost estimate, and use cases of varying complexity have a varying influence on the cost estimate.
Business Analysis / Project Management / Requirements / Requirements Models / Use Cases
Posted on:
Software Cost Estimation With Use Case Points – Environmental Factors
The environmental factors that describe your development team and environment are the second thing you assess when doing project cost estimation with use case points. Environmental factors primarily focus on the capabilities of your team, but also touch on your process.
Business Analysis / Product Management / Project Management / Requirements / Requirements Models / Use Cases
Posted on:
Software Cost Estimation With Use Case Points – Technical Factors
The technical factors are the first thing you assess when doing a use case point analysis. Technical factors describe the expectations of the users for the delivered software. Generally, it is an assessment of non-functional requirements. There are 13 technical factors that you have to analyze. Read on to see how.
Business Analysis / Product Management / Project Management / Requirements / Requirements Models / Use Cases
Posted on:
Software Cost Estimation With Use Case Points – Introduction
Estimating the amount of work required to deliver software is hard. Estimating the amount of work in the very early stages of a project is even harder. A method was developed to estimate the amount of work required by analyzing what the system will allow its users to do. That method is called Estimating With Use Case Points. This article is an introduction to the concept.
Project Management
Posted on:
Failing to Plan is Planning to Fail
From Bobby Knight, paraphrased by Mark Cuban, via Marcus Ting-A-Kee:
Everyone has got the will to win, it’s only those with the will to prepare, that do win.
Agile / Communication / Process Improvement / Project Management / Software development / Testing
Posted on:
Crossing The Desert With Bad Project Planning
Johanna Rothman recently wrote an article with a poignant introduction: “A project team focuses on an interim milestone, works like the devil to meet that milestone. They meet the milestone, look up, and realize they’re not at the end of the project–they still have to finish the darn thing. They’re living the Crossing the Desert syndrome.” Fixing it isn’t enough – how do we prevent it from happening?