It is necessary to have a plan to do something, though there is a rule all plans should follow: Begin at the beginning, and go on till you come to the end: then stop[1]. In other words, the plan serves the engineer and not the opposite.
There are two approaches to planning: Bottom-up and Top-down Planning. In top-down planning the manager defines a complete plan for the whole development lifecycle estimating its cost. Afterwards it uses the plan the manage the development. Being plan-centred, the top-down approach tends to spend a significative amount of resources for planning. These resources are used to ensure that all the variables associated with the development are known and controlled. However, being software development a human and social activity, it is not easy to control all the variables. For instance, as we have seen, in P- and E-system the software requirements change not because the team was not capable to gather and specify requirements but because the understanding of the problem changes during development if not the problem itself. Top-down approaches deal with this situation using a contract. In some early point of development the client signs a contract which states what are the requirements. Although this may protect the vendor it does not necessarily guarantee that the final artefact will fulfil the client needs. Ultimately, it also does not even benefit the software developer because the client may not want to continue to deal with them. Another drawback associated with plan-centred development is that managers resists to change the plan due to the effort spent in its conception and the compromises that followed.
No one is comfortable to have a business relationship without a contract. However, bottom-up planning approaches defend that the relation between the client and the software developer should be of trust and acceptance of changes, because it is not possible to control change, only to react to it. Clients are invited to replace not implemented functionality which accommodates changes in the requirements and in the client’s priorities. In the lack of a contract the relationship between the development team and the client can be more fluid and adapt to changes in the benefit of the client. Bottom-up approaches pragmatically reduce the investment in planning to the strictly necessary to define the goals that will drive the project. This is done in a couple of days maximum and due to the reduced effort spent changes to plan are easily taken and accepted.
Estimation of effort and, ultimately, of cost is one the most challenging parts in planning. Actually, this is the final goal of a plan. All the existing approaches to estimation are based on empirical data: the experience of managers, algorithmic formulae that are based on publicly available data about finished projects, and the yesterday’s weather approach that estimates the effort based on what occurred in the last development iteration.
The main difficulty associated with estimation in software development results from the variety in software. Programming in assembler has a different cost than programming in Java, a small team is more productive than a large one, a line of code of real-time system is more expensive than a line of code of a web application. Therefore, it is necessary to classify the empirical data according to several dimensions. Additionally, it is also necessary that the manager accurately classifies her own project according to the same dimensions and using the same criteria. This classification, both of the finished projects and of the one to estimate is subjective. The last yesterday’s weather approach minimizes the subjective interpretation because the used empirical data is of the same project.
[1] Alice’s Adventures in Wonderland. Lewis Carroll. 1865