When you are the project manager of a complicated software project, you have to constantly be on your toes to manage dual expectations. On one hand senior management expects you to maintain the schedule and budget of the project, while on the other hand your team would be de-motivated if the pressures of meeting delivery schedules turned out to be unreasonable. In actuality this is a very common situational irony, to which a project manager is subjected to. You will find yourself being pulled into this situation most of the time and the pressures to handle and resolve this is through realistic software estimation.
This lands us to the next question – How can we estimate realistically? Irrespective of the technology category of the software project, estimation is a challenging subject to deal with. This is owed to the dynamism in goal setting as the requirements, and hence the scope remains flexible up till the final delivery. This results in time and budgetary overruns.
A Java project is developed to provide solutions to enterprise issues, any overruns (time and cost) would weaken the enterprise objective. The focus of estimation should be to strengthen the enterprise through the particular project. For estimation of a Java project, doing a granular level requirement analysis –based on use cases should be the initial step. Studying the system from a user’s action perspective would truly define the use cases, since every action would trigger the system in some form or the other and estimation in its true sense would be to take notice of every user action to define implementation types.
Step 1 – Assess and document as many use cases as you can think of as a link to a user story.
Accurate description of a use case is essential. To create an accurate description, list the actors and their goals as per priority of release. Sketching success scenarios should be based on actual usability to the stakeholders. Drafting failure conditions should be prior to analysis of failure handling techniques. An important consideration here is that a failure handling procedure can surprise you with the revelation of either a new goal or a new actor which needs to be included in use case analysis and description.
Step 2: Accurately describe the use case in terms of actors, goals, success scenarios, failure conditions and failure handling techniques.
An exact use case description would read something like this – The system would support 500 concurrent users to bid for an item with the goal of winning the auction and paying for the item on an auction website. Also list down failure conditions and create an alternate flow of events associated with it. So when a user places a bid, the system may fail due to credit card failure, session time out or failure of other monetary services (ATM machine runs out of receipt). An additional error flow should be created. Doing so would help estimate not just for the use case development, but also for the alternate flow in case of failure.
It is essential for you to review and partition related use cases which depict similarity of behavior. The use case sets identified should be measured for their contribution in significant terms to the actors and stakeholders. All similar use cases, based on behavior (e.g. All sales related use case in an order management system) should be reviewed early in the estimation process. Reviewing the description of use cases ensures accuracy of behavior description with respect to intended solution (feature). In agile development, you should be clear about which portion of the use case has to be complete at the time of the review. 
Step 3: Review description of use case and consider analysis of use case behavior for accuracy of description – so involve developers and testers for use case reviews.
The greater the accuracy of the description and listing, the greater is the estimation accuracy.
A detailed description would enable assigning points to use cases based on formula. As per Karner’s formula, assign points based upon the number of transactions (steps in use case) within the use case. It is essential to include extensions (failure)/alternate flow parts of the use case as it accounts for significant effort too. Counting transactions and the extensions requires great caution. An example of a use case is to count total transactions:
Use Case: Buyer buying a product on a retail website
Primary Actor: Buyer
Level: Actor Goal
Precondition: The buy option clicked but the product is still not sold
Success Guarantee: Product Sold; Credit/Debit Card Charged
1. Buyer provides credit card number, date , authentication number
2. System validates credit card
3. System charges full amount
4. Product added to purchased list
5. Buyer given a unique confirmation no./confirmation mail sent
Alternate Flow /Extensions
2a. Card type not acceptable to system
2a1. System notifies the user to use another card
2b. Card is expired
2b1. System notifies the user to use another card
2c. Card number invalid
2c1. System notifies to re-enter the number
3a. Card has insufficient money/credit limit
3a1. System charges as much possible as it can to the card
3a2. User is notified about insufficient limit and asked to provide another card for remaining charge.
The use case then further continues from Step 2.
For the example above, the total transactions would be ten. Estimation of effort should take notice of this. The points assigned for each use case depend on the number of transactions as simple (3-5), average (4-7) and complex (more than 7). Similarly, weights and points are assigned to other variables – the actor, technical complexity, and environmental complexity to put it all together and arrive at a final use case point to estimate size. Each variable is defined and computed based on perceived values and weight and the product of all the variables are then computed. Your organization’s historical average from past project can be applied to calculate duration – depending upon how many hours were taken to develop a particular number of use case points. 
The real time and effort of estimating this manually is too laborious of a task. Besides, it would not be very compatible for an agile model.
Consider the Basic Estimation Issues
The estimation process has some inherent demands which create issues if you consider estimating your project manually. It requires someone who is technically trained to carry out a formalized estimation with adequate knowledge of business and technology domain of the project. It is essential to know effects of technological issues and technology architecture over development time. The choice of tools and framework for the software project requires analysis as each tool has its own level of applicability and impact on development time. Estimation should consider choices of tools and framework made for the specific Java project. Estimation of effort should be sufficient based on system complexity and communication protocol and on integration with third party systems. Existing re-usable enterprise components can be included in the present design, however separate effort and time is required to understand their complexity and relevance of usability in present design. Estimation of time and effort for this ‘understanding’ should be included in final estimation hours as additional enhancements might be required for using the re-usable component. Similarly, the existing architectural standards can reduce effort; however their standard can pose issues to actual design and implementation which could be a ‘big effort’. So standards should be evaluated for applicability for estimation. Testing has evolved tremendously, so creating and running a JUnit test as compared to unit testing requires extra development and learning time – the testing methodology needs to be specified for estimating testing time accurately.
Solution – Use Estimation Software for Performing Quick Estimation
The inbuilt template for estimating a Java agile project through standardized mechanism which considers all categories of complexity, environment, technology and platforms can be through Quick FPA to produce reliable estimates in the shortest amount of time. The program is built to include implementation types (based on use cases) and to involve all implementation platforms, technologies and variable testing environments. There is scope to adjust your re-use factor, apply variable levels of project complexity, and apply version control effort to arrive at the final estimate hours. It can be done even by a non-technical member of the team with great ease and precision as Quick FPA handles the entire complexity at its end.
We understand estimation is indispensable and challenging. You can either use the software by yourself or we can guide you. Estimate your complex Java project in the shortest amount of time through Quick FPA. Register and receive an invitation for a demo.
“Warm Up With A Usage Narrative.” Cockburn, Alistair. Writing Effective Use Cases.Pearson Education India 2001. 17. 
Kurt Bittner, Ian Spence.
“What To Review, and When to Review It.” Kurt Bittner, Ian Spence. Use Case Modeling. Addison-Wesley Professional, 2003. 281.
“Estimating With Use Case Points.” 2012. Carnegie Mellon University, School of Computer Science. 12 28 2015 
“Avoid common pitfalls during Java EE project estimation.” 3 April 2006. Java World. 28 December 2015