This article proposes a tool and user manual that updates the estimation models proposed by Barry Boehm (Constructive Cost Model or COCOMO) in 1981 and Alan Albrecht (Function Points) in 1979.
I know it does not make us look younger, but these mathematical models keep their interest in estimating software projects, Agile or not.
Having had the opportunity to work on a tool commissioned by Computer Associates at MIT in 1991, which implemented these two techniques, I took a close interest in these models, as well as the link that could be made between them. Function points and CoCoMo.
The Computer Associates tool already offered higher-level quantitative criteria than those used by the function points and CoCoMo, criteria found in the project / product context diagram at the end of the Project / Release inception phase.
After a first version on Multiplan, I quickly adapted my first tool to Excel, and made it evolve with the new tools and methods of development, while testing it on many projects of respectable size.
The Excel tool, which you will find the link below, offers this end-of-scale evaluation (Agile or not), and can be very useful as a basis or complement of your usual estimation tools:
The strengths of Barry Boehm’s formulas: They take into account the effects of scale, and make it possible to calculate the size of the teams according to the constraints of delay which are imposed on you (between the two limits which are indicated to you in the tool ): The more people you add, the more coordination you need.
Note: This tool is effective for projects over 300 men*days
Let us now turn to the concepts used, and the granularity of the quantitative elements to be entered.
The context Diagram of a project, a release:
The context diagram is a graphical representation of the relationship between the analyzed application domain and the outside world.
This is a level 0 chart used to determine high level interfaces. The detailed analysis phase will use the context diagram as a basis for breaking down features and flows.
The context diagram is co-built with the business and is a valid representation of the project view from the user.
The actors are specified in an exhaustive way. An actor is not part of the project in the sense that one does not model his tasks, but he exchanges information with the applications and products modified by the project / release. We will indicate (in the actor’s description) what are the responsibilities of this persona in relation with the various processes / tasks implemented.
Note: The context diagram of an application accurately reflects its application flow map, in the Archimate modelization (in contrast to its functional mapping and technical mapping).
Estimate by the context diagram: Principles of operation
Saisie des éléments quantitatifs et des facteurs correctifs
Quantification of the context diagram
Number of incoming flows created or modified by the Project / Release:
- How many input groups, unique and logical, will the system have to deal with?
- We count the number of main types of information coming from outside that will enter the system.
- Information from internal databases is therefore excluded from this total.
- It is necessary to think in terms of main transactions, of necessary communications for the activity of the studied area.
- An input information unit is considered to be unique when it requires a different processing logic than other information units.
- The complexity of a flow depends on the size of the data sub-model it carries and the related rules to process that flow.
Example :
Number of outgoing flows created or modified by the Project / Release:
- How many documents (paper documents, files, tables, emails for the outside world) will the system generate as output?
- Take into account only the major flows and not the minor flows that are derived from them.
- An output information unit is considered unique when it requires a different processing logic than the other information units.
- The complexity of a flow depends on the size of the sub-model of data that it carries and the related rules to process that flow.
Macro Entities created or modified by the Project / Release:
- Entities are grouped according to their management goals.
- For example: command = command header + command line.
- For example, if a macro entity contains less than 3 “tables” the macro entity is simple, from 3 to 5 its complexity is average, beyond its complexity is strong
Example :
Other IT Services, Products and Apps Created or Modified by the Project / Release:
- Web App, or Mobile app
- Application server (ESB, APIs)
- Monolithic application
- ERP
- Mass reporting, Electronic document management
- Other IT service referenced within your CMDB
- …
Use cases based on a user experience, created or modified by the Project / Release:
- User journey experience within an App, Web App, heavy client, mainframe, …
- User experience to perform a business transaction.
- …
Distribution of quantitative elements by complexity
Simple:
Average:
The data model of induced / carried by the item, has 3 to 5 entities each having about 15 attributes and 3 relations towards other entities. The management rules applied to these entities are less trivial, and can pose problems of response time for example.
Complex:
The data model induced / carried by the element, includes many entities, some of which have a large number of attributes. There are a few multiple to multiple relationships and the rules governing the model are complex.
Apply a time constraint
Here is how to apply a time constraint on your project / release and see the impact of this constraint on the necessary staffing:
Function Points and KPIs
The number of function points can also be used to measure indicators for monitoring quality and velocity.
Indeed the number of function points is a dimensionless number representing the ‘weight’ of the project irrespective of how it will be achieved:
