How to make estimates ?

According to several experts,there are two ways to estimate a development of a software project, here are the two:

1 -) by analogy – current project size estimates are based on estimates already developed on similar projects or the so-called historical bases of other projects or;

2 -) developing the technique of measurements of Product Characteristics and using a methodology and algorithm to convert the measurement into a size estimate.

Basic methodologies

Good in your case, I advise you to take a look in this article and in this article to know better how to design your own estimates based on your work and how long it takes you to do a certain task.

An interesting method would be to use on the basis of Planning Poker, which has already been cited, which is a consensus game mainly used to estimate the effort or size relative to the development goals of a software.I advise you to take a look here to know more about the subject and also to take a look here to be able to create your own Planning Poker online.

What can also help you make certain development time estimates is to create a Diagrama de Gantt.

The Gantt diagram is a graph used to illustrate the progress of the different stages of a project. The time intervals representing the beginning and end of each phase appear as colored bars on the horizontal axis of the chart.

Example of Diagrama de Gantt:

Complex methodologies

There are several methodologies for creating software development time estimates, which are:

COCOMO (Constructive cost Model) [COCOMOII]

Model developed to estimate development effort, timelines and size from the team to software projects. It uses equations developed by Boehm (BARRY,1981) to predict the number of programmers-month and development time; they can be calculated using measures of lines of code or function points. Adjustments should be made to the equations in order to represent the influences on the attributes , hardware and software during the project life cycle. A disadvantage of this technique is that the coefficients of the metric (a, b, c, d) are not applicable to size that is, productivity is different, which makes it difficult to make comparisons.

Lines of code - (LOC)

The line of code measurement technique is one of the oldest measures of software development project size. It consists of counting the amount of number of lines of code of a software program. In addition to being very simple it is also very easy to automate its implementation , but it has some disadvantages among which we cite: the dependence of the software language and the developer (PRESSMAN,1995); absence of counting pattern and the fact that it can only be applied in the coding phase.

Hasltead metrics

Is a set of metrics proposed by Maurice Halstead (HASLTEAD,1977). The principle of this method is in the analysis and quantification of operands and operators and in the concept that from the knowledge of the measures, it is possible to quantify the words and the extent of the study algorithm.

Puttnams Slim Model (PUTMAN,1978)

Is an estimation model that seeks to measure effort and time through the dynamics of multiple variables that presupposes distribution of specific efforts throughout the existence of a software project. Relates the number of lines of code to development time and effort. A disadvantage of the technique is its binding to the language used and the requirement of a certain time to obtain real values for the parameters of the formula.

Delphi

Is a technique that comes down to consulting experts from a certain area, in a certain language and/or a certain subject so that, using their experience and understanding of the proposed project, they make appropriate estimates. Several estimates of the same project should be made, as it is common for them to carry influences and trends from experts. It is an empirical method, based on professional experiences that can be subjective.(Boehm,1981)

PSP-Personal Software Process – (HUMPHREY,1995)

Is a technique derived from the SEI-CMM (Software Engineering Institute-capability Matutiry Model) that was developed with the function of empowering, improving and optimizing the individual work process. The technique is divided into seven stages, and in stages PSP0, PSP0.1 and PSP1 the size and time required for development is estimated of the product.

PCU-points per use case

Were created by Gustav Karner in 1993 as a specific adaptation of function points to measure the size of Object-Oriented Software projects. Explores the model and description of the use case, replacing some proposed technical features with function points. It is a simple and user-friendly method but it is still in the research phase and there are no standardized counting rules. Have if studied the joint application of the PCU and APF trying to explore the relationship between them.(EDMÉIA, 2004)

Function Point Analysis (ALBRECHT,1983)

Seeks to measure the complexity of the product by quantifying functionality expressed by the user's view of it. The model measures what the system is , its functional size and not how it will be, as well as measuring the relationship of the system with users and other systems. It is independent of technology used and measures an application by the functions performed to / and by end user request.; it can also be used in estimates.

Conclusion

Estimating the size of a software project is a critical activity because it has an impact both on the technical solution presented and on the management of the software project and should be carried out not only at the beginning of the project but during the life cycle of the project. The techniques presented above are only some of the many existing ones, each of which covers a certain area; there is no metric that completes the study alone, so it is recommended that the most appropriate technique be used to measure software design or the use of more than one technique together. Among the techniques described, the most popular currently is the technique of analysis by Function points. This technique is supported by Ifpug (International Function Point Users Group), which is responsible for, among others, by the elaboration and dissemination of a Counting Practices Manual (CPM), in addition to maintaining a certification program for professionals specialized in applying the APF technique. Function Point Analysis (APF) is one of the most sedimented size estimation metrics on the market and provides increasingly accurate results as artifacts from the analysis and design phase are generate.

Bibliographies

COCOMO-Constructive cost Model. Available in: http://sunset.usc.edu/research/COCOMOII /

DEMARCO, TOM. Control of Software projects. 9.ed. Rio de Janeiro: Editora Campus, 1991.

VAZQUEZ, Carlos Eduardo, SIMÕES, Guilherme Siqueira, ALBERT, Renato Machado-Function Point Analysis, measurement, estimates and Software Project Management, 13.ed. São Paulo: Editora Érica, 2013.

MACORATTI, José Carlos - software size estimates and APF. Available at:: http://www.macoratti.net/net_est1.htm

There are basically two methods of estimating the cost of software development:

A) Guess how much it will cost.

B) Measure how much it will cost.

All estimation methods are derived from these two basic ways there.

Supporters of method a are always trying to improve their divination techniques and supporters of method B are always trying to improve their divination techniques measurement.

A) Estimate by measurement

Is the oldest and most traditional way of estimating software.

One of the most popular techniques of this method is the counting of points by function, which works more or less like this:

• requirements are lifted
• use cases are drawn based on requirements
• details the use cases in the functions that compose it (there is a range of function types previously established)
• points of all functions (each type of function has a previously set amount of points)
• multiply the total points by a unit of value (time, money...)
• a fat is applied.

_{There may be more factors influencing the cost or price prediction of the project (management cost, Risk, Value Added, etc.).), but these other factors will be present depending on the nature and environment of the project and regardless of the method estimate chosen.}

The value of each function point is a management decision that is based on previous experiences (own or market) and other marketing interests.

This is an incredibly effective method.

It is difficult to miss the estimate because the measurement is made on very detailed documents of everything that will be implemented. Each function is a very elementary software resource, such as one of the CRUD letters, whether the object is an entity or a relationship, etc. And it's easy to hit the size of the effort to make such a small implementation.

The problem is that counting everything that will be done requires you to know in advance everything that will be done. That is, you have to make a good investment in understanding and detailing the scope even before you start making software.

In projects of this type, it is natural this phase take months and cost the work of various consultants, commercial and Technical, who they are usually the most experienced in the organization (the most expensive) because the premise is that this phase is completed with a lot of quality.

It is normal that this effort has other relevance in the project beyond the estimate, such as relying on the comprehensive documentation produced at this stage to ensure that the right software will be developed, relying on the documentation as a support for future maintenance, or receiving a customer signature on this documentation (a contract) and Shield against changes to secure margin or term.

These other relevance of the documentation bring a few more cons to this method: you have to design the entire system before learning everything necessary about it, because the learning, both from the client and from the team, happens during the implementation of the project and after the client starts to see the software that is delivered.

If you make changes difficult, the customer can be missing opportunity to get more value from this project. And if you open up to changes, you're throwing away the investment you made there in the beginning when you tried to predict everything that would be done and all the cost.

B) estimation by divination

This is the preferred method of Agile processes, since they value software running, early, than comprehensive documentation; more collaboration with the customer than contract negotiation; are open to change and even encourage it; believe that the best architecture and design emerge instead of being previously defined; etc.

Since the idea here is precisely to allow change, it makes no sense to invest a lot in closing a scope, so usually you build a macro view of the project and a rough estimate, which can only be guessed since there is nothing to measure because it is not yet known exactly what will be done.

There are several methods of divination. To define an overall cost of the project before starting it, it is common to define the capabilities or features, which are the mega requirements of the project, guess how much it will cost each and add up.

"guessing" is a correct term as it is admitted by the project that the future is uncertain, it is admitted that there is still no deep knowledge about each feature or ability to be sure of all the work that will be required, and there is no intention to acquire advance this knowledge-preference is given to start delivering software early and learn from it.

All estimates are based on previous experiences, and are difficult to get right precisely because they are made on a macro rather than detailed knowledge of the work that will be employed.

Still in thesis you can deliver the expected capabilities within the budget because while parts of the software are made and presented to the client, the learning increases and it allows you to stop performing work that previously seemed necessary.

The opposite can also happen and you identify that you made a very ugly mistake in divination, and that it will be impossible to deliver the capabilities at the predicted cost. In this case the new cost is assumed or the project is cancelled early before the loss is too great.

See that in the other method you can also make an ugly mistake-not the cost estimate but rather the prediction of what should be implemented because you predicted it not counting the knowledge acquired during the project. In this case, when the project is canceled, the entire cost of that initial phase is added to the loss. Or worse: because you already "knew" everything you needed to do and did not want changes to come, you did not deliver the software in parts but left everything pro final - that is: risk of total damage.

Guessing during the project

Well, so far I've only talked about the divination that happens at the beginning of project. But during the project, how are the tasks estimated(small requirements that will constitute the mega requirement - the capacity/feature)?

Here happens the same kind of divination based on empirical knowledge. Agile methods generally discourage estimating in hours, as they admit that one cannot predict with such a level of accuracy how much even a small requirement will cost.

So it was invented story points which are an estimate of effort or size or complexity of the task, but are not directly related to cost in hours. The idea is that over time one learns how many points one can make in a period and that this helps to estimate the tasks that can be completed, according to their amount of points, in a subsequent period of equal size.

In an effort to further decouple Agile estimates from hourly estimates, fibonacci scales or the sizes "P", " M " and " G "( type sizes T-shirt) to discourage the association with hours (the immediate association becomes more difficult because the conversion calculation is more difficult or abstract).

To pursue a more promising divination, there is also planning poker, which relies on the experience of several professionals at the same time to avoid deviations too big for more or less. You can read How Planning poker works out there or ask a specific question because that alone already gives some paragraphs.

Below the divinations

Finally, the latest fashion in the agile universe is to look for alternatives so that you don't even have to try to guess estimates.

The reasoning is as follows: if measuring the project (presented here as "Method A") does not serve the client well and if we are not so good at guessing ("method b"), How about forgetting this stop of estimating?

The name of this movement is #NoEstimates and the idea, of course, is not simply to stop estimate software, but rather seek alternatives to it. Type " we can not estimate, so what can we do instead to ensure the cost/value/term for the customer?".

It is also considered that although the client needs to know how much he will spend and how much time it will take, the estimate itself has no value for him, and what does not have value, according to lean thinking, should be eliminated from the process (ok, ok, this is another story, even longer, so stay for another hour).

Estimates for whom?

As I commented lightly, there is a lot of question about the value of the estimates for the client.

Somehow he needs to know how much it's going to cost and when it's ready, ok. According to Agile Methods, this can be solved with macro estimation of capabilities / features, interactive deliveries and open scope.

And how much will each task cost? How much will it cost each of those 10 small requirements you plan to develop in the next two weeks? Do you even need to calculate this? Will you sell this measurement to whom? Who will pay for this effort? What is the value in nailing a fibonacci number in each post-it of the board?

So if you are working alone or if your project allows, if there is no manager charging you for it, try to free yourself from short-term estimates as your actual value for the project so far has not been demonstrated.

Comments finals

As we have already talked in the comments, the relationship between fibonacci and pomodoro does not exist.

Pomodoro is a technique for keeping focus.

And using fibonacci sequence numbers in estimates is precisely an effort to decouple estimates from cost in hours.

A reference to give value to the answer

Ron Jeffries, one of the guys who signed the Agile Manifesto, who created Extreme Programming and who helped invent these things from "story points" and "team speed", is engaged in the movement #NoEstimates. Even he has already apologized for having invented this business of estimating in points. Next:

" there are a number of ideas on how to estimate using something other than time [hours]. Points, Gummi Bears, Fibonacci Numbers, T-shirt sizes. They were originally invented to obscure the aspect of time, so that management would not be tempted to misuse estimate. (I know: I was there when they were invented. Actually I must have invented the dots. If I made it up, I'm sorry now.)"

See this apology and many interesting things at: https://pragprog.com/magazines/2013-02/estimation-is-evil

Software estimation is critical to any project. Cost, effort and time estimates are often demanded by clients and the project manager needs to have a basis for planning and making decisions in the course of the project. Estimation also contributes to a greater understanding of the problem and provides a horizon for the completion of the project or iteration.

Planning requires you to make an initial commitment, even if later it comes if show wrong. Whenever estimates are made one must look to the future and accept a certain degree of uncertainty.

...our estimation techniques are very poorly developed. And, more serious still reflect a somewhat false assumption does not declare that everything will be fine...how are we not sure about our estimates, software managers often do not have the necessary firmness to making people wait for a good product (Brooks)

An estimate it is nothing more than an estimate. Mathematical processes can give the false impression of truthfulness, but the basis is subjectivity based on an abstract definition of the system.

Estimate is to provide a clear enough view of the project that the management can make good decisions of how to manage the project to May it achieve its goals (McConnell)

Uncertainty in the estimate. Basically, know what has to be done, otherwise your estimate it'll probably be wrong.

At the beginning of the project uncertainty reaches its peak, but decreases as tasks are completed. The earlier the estimate occurs, the worse the estimates will be. The early estimation of all software tends to generate worse estimates than in cases where they are made at later stages of the project.

Although it is often necessary to estimate the entire software, it is important to re-estimate when you want to get an updated position on the stage of development. The software is changeable, the requirements change over time.

Some techniques and pet models:

Planning Poker

Some agile processes, such as Scrum, view software design as a game. In this line, some authors consider the best way to estimate a kind of poker with backlog user stories (Cohn, 2006, P.55). No Planning Poker, all members of the development team get together. First, each member receives letters. Each card contains a story point scale value defined for the project. For each User Story, members secretly choose the letter with the value they consider to be the size of that story. So everyone shows their cards at the same time. When there is consensus, the estimate would be reliable. If one or more values are inconsistent, the members discuss with each other the reason because the user story would be more or less complex. After entering into a consensus, a new round of Cards is held. This is done until everyone is in accordance with the estimate. The "agilists" claim that this technique has worked well for the following reasons (Cohn, 2006, P. 59):

* those who know how to do the work are those who make the estimates;

* dialogue makes estimators have to justify their estimates, so they think well in what they are doing;

* group discussion, according to some studies, leads to better estimates.

Planning Poker is usually done more intensively, but less in detail, at the beginning of the project in order to generate the initial estimates needed for the overall planning and number of iterations. At the beginning of each iteration, it is suggested to take something around an hour to detail the estimates of the user stories that will be implemented, which, which at this point, they are divided into tasks. The time to estimate varies according to the size of the iteration.

Object-oriented estimation

Object-oriented systems can be estimated through Object-Oriented modeling, such as UML (Unified Modeling Language). Values are assigned to each object in the system and thus a general estimate can be reached. Some measures suggested by Pressman (2009, p. 506) are:

* number of scenario scripts interaction between user and System;

* number of important, system-independent classes;

* number of non-domain related support classes (database, user interface);

* number of domain-related support classes;

• number of subsystems.

Use Case oriented estimation

You can use use cases to estimate a software. The estimates for each use case they would make it possible to plan the project with a whole.

However, as use cases are very abstract and different people work on different levels of abstraction. There are no parameters to define a standard measure for the effort required to implement a given use case (Pressman, 2009, p.507). As a result, the estimation with use cases is not recommended, being little used.

You can delve much deeper into this universe, I recommend:

O blog state of the art (a lot was taken from la)

Software Engineering-8th Edition

Mythical Man Month

Scrum in action ....

I just don't give -1 your question because it's worth thousands of dollars to the software industry :-) and certainly the answers you read above are compilations of what is taught in universities in the disciplines of Software Engineering. But now, I'm going to take off my teacher's hat and put on my pro's to answer. Use my own experience to answer and not quotes from what I do not use anymore and one day it worked out, but today for my projects and customer profiles not they work more.

If this subject were easy it would not take so many books on software engineering that is not Engineering (as we know it). In the same way as I do not like to call a method that does not have well defined and predictable behavior and the possibility of always having the same results if applied in certain conditions. Like Fred says. Brooks:"there is no silver bullet." But one thing I really like to defend is the famous PMI triangle: term, cost and effort that are variables strongly coupled to requirements. Simple and easy to understand: fiddled with the requirements, will affect one or more of these variables. Example: shortened the deadline will have to cut requirements. Increased scope? It will stretch the deadline on account of effort (and here comes the classic error: increase the team I have no problems with Deadline - Mongolian horde).

If you are a mathematician by training or deeply familiar with linear programming methods such as Simplex, I would understand that, for complex problems, there are possible solutions to arrive at what is called an optimal solution (not said correct). I assure you, there is no single complete method capable of measuring with certainty what you want, because they are ideas, not formal methods. They work with interpretation of requirements.

If you are going to use an estimate to apply a price to your work, I affirm, forget it. Extremely fallible because they estimate requirements that cannot be frozen to long design. They change. So Sfw Engineering is not Engineering. No use. price for the commitment effort , never just considering the scope of the frozen requirements. Large software factories mix approaches to align project price, adjusting according to time / effort tempering with profit and risk analysis.

There are companies selling sprints. I find this approach very interesting. Do not give a final price than not see or what can change a lot. It sounds surreal but there are mature enough customers to understand that this is an interesting and functional model. For your case, to be practical estimate your month effort what you can deliver that month and sell to sprint based on your cost / profit. From an approximate idea of amount of sprints and ready. Forget unit hours, Man/month (in your situation) to estimate term. I will not suggest you a complex thing to be applied in a software factory by several professionals since you will work alone in this project and there is no way to have a Q&A area to ensure success (in short).

Always remember that quality does not come from the correct fulfillment of methods. It goes way beyond that. It is not because we adopt a method or Model A or B that we will have a Quality Guarantee in estimation, development or delivery.

I hope I helped you find a starting point.