[S1-A&D] Estimating your software project from scratch

Estimating your software project from scratch

Why estimation?

Estimation is the process which is applicable in every corner of personal and professional life. Estimation is one of the most important qualifying criteria which enables buyers (any individual or group-entity) to take an appropriate decision on buying the products-or-services from the respective seller.

During my career, I have seen many occasions when people were struggling in doing estimation for any software project. Many-a-times projects are underestimated and sellers of the products-or-services have to bear the losses. Buyers also apply the shrewd tactics in negotiations, sharing only abstract level information, creating pressure to submit the commercial urgently in a day or two and many other distracting & negotiating tactics. Under these circumstances this is quite obvious that the team from the seller side will not get much time for deep thinking and high-level thinking brings the opportunity to miss some of the normal or exceptional scenarios which will increase the project cost at the later stage.

#softwareprojectestimation #developmentcost #wbsbasedestimation #projectcommercial #softwarearchitecture #functionalarchitecture

Objective of the article

Whole objective of this article is simplified-learning, ready-to-use and almost-correct-estimation. In this article, my focus would be to explain estimation approach & template how one can apply the same in any relevant opportunity.

Software-project estimation template

One can refer the estimation template available on this link[Estimation-Model-Framework-Template]. Same template has been explained in this article as well.?

Outcome of estimation-process?

Usually from the estimation-process people think that the estimation talks about only cost-estimation, while the estimation process is beyond that.?

Key outcome of estimation-process are?

• Effort estimation : which will explain how many person-days would be required to roll-out the software project.
• Resource estimate : which will explain how many human-resources for the duration of estimated person-days would be required to roll-out the software project.
• Cost estimation : which will explain the required monetary-expenses on human-resources to develop & deliver the software project as buyer’s expectation.?Another point to note is that monetary-expenses are not just the labor-cost of software-development. There are other expenses which may-be tangible or intangible by virtue. Examples are physical-infrastructure cost (server, desktop, laptops, printers, scanners, memory, storage, other peripherals etc.), Other expense-fees are like software-license one-time-cost or recurring-cost, travel-expenses, accommodation-expenses, and many more.Bill-of-material (BoM) : BoM is the document which consolidates the list of all expense items. Expense-items listed in BoM documents are called bill-of-quantity (BoQ).Costing methodology for each BoQ may be common or specific to BoQ e.g. RedHat operating-system license fee is different from Windows server, RedHat Openshift cluster, Oracle weblogic, Oracle database, etc. all have different costing formulas.?Costs for infrastructural BoQs are properly planned as per agreed milestones e.g. partial infrastructure can be requested to be available after 3 months before project-rollout, and remaining infrastructure can be requested with the gap of 4-4 months after project-rollout.

In order to keep the learning simple, the objective of this article I will keep the focus limited to development cost of software-project. Explanation of complete BoM can be taken later some other time as continuation of this article.

What is the WBS approach?

WBS i.e. work-breakdown-structure is the most natural way of doing cost-estimation for any software-project.?

Before WBS, let’s understand the various project estimation techniques as follows

1. Bottom-up : break the entire big project into smaller functional-components, these functional-components are also called functional-application, domains or subdomains. Please refer to the diagram as given in section [Reference functional architecture].
2. Top-down : In this approach the deadline as per business needs comes first, the required team is allocated and then the project is executed to achieve the deadline.
3. Analogous : in this approach, project estimation is referred from a similar project which is already implemented.?
4. Parametric : in this project also, project estimation is referred from a similar project and differences are parameterized to reach ro estimation of current project.
5. Three-point : in this approach, there are three outcomes that’s why this is called 3-point approach. 3 outcomes from 3-point technique are [the most optimistic, the most pessimistic and the most likely]. Stakeholders can sit together to review these 3 references and pick either of one or average-out of all three.
6. Expert judgment : in this approach, experts (individuals or groups or individuals) arrive at some estimation number, completely based on knowledge & experience.?

Readers of this article would have seen many different situations in their career and any of the above different estimation techniques can be applied, but WBS is the base of all techniques. Most of the occasions, we all would have fallen in TOP-DOWN approach, in this article we would learn how the WBS will be used to calculate the project development cost.

Reference functional architecture

Other estimation approaches or models

Function point

Function Point Analysis was introduced by Allan J. Albrecht in 1979 at IBM, further International Function Point Users Group (IFPUG) maintains the FP standards

The Intention of this article is not to explain Function Point Analysis (FPA). This may be covered later some other time as a new or continuation of this article.

COCOMO model

COCOMO or Constructive Cost Estimation Model, which is based on line-of-code (LOC) to be written.?

Static, Single Variable Models

In this model, one primary variable is identified as a key element for calculating the cost and effort.

Static, Multivariable Models

In this model, there is no single primary variable rather all variables are connected with each other, which participates in cost & effort calculation.

Let’s do estimation for your real software-project

Step-1 : Identify your project requirements

1. This will be exhaustive list of requirements which shall be shared by customer
2. Many reputed customers (tier-1 telecom operators, tier-1 bankers, etc.) share a detailed list of requirements with expectations of compliance status by software-vendor
3. Sometimes software-vendors do not get the exhaustive requirement list from the customer, in that case software-vendors should prepare the list themselves and get it aligned with the?

**These are just sample requirements, you can rename the requirements and append more requirements as per your project need.customer.

Step-2 : Define your complexities & t-shirt size for efforts

1. Define t-shirt size of complexity for your requirements?
2. One can add or remove or modify t-shirt sizes as per project need
3. Once your t-shirt size is aligned with all stakeholders, this needs to be mapped with each requirement.

Step-2(a) : Identify impacted layers from each project requirement

So far we learned the t-shirt size at each requirement level, while we all understand that each functional requirement will be implemented at various layers. Estimators can foresee the efforts due to impact on these layers, estimators can define their own t-shirt size of each layer. It is quite obvious that estimation done using t-shirt size of each layer will be more accurate than the requirement-level t-shirt size.

?

Common layers for requirement implementation

1. Frontend Layer
2. Backend Layer
3. Database Layer
4. Overall E2E impact (requirement-level)

** in order to keep things simplified, we shall consider only overall-complexity. The model can be granularized for each layer if required to be more accurate.

Step-3 : Assess & assign the complexity of each project requirement

**T-shirt size mapping with each requirement is random, you can change complexity t-shirt size as per your assessment at ground.

Step-3(a) : Granular complexity mapping for each project requirement

** One can continue with granular complexity mapping if there is a need to discover more closure estimation and sufficient time is available to do this exercise.

** In order to keep things simplified, we shall consider only overall-complexity. The model can be granularized for each layer if required to be more accurate.

?

Step-4 : Have a look on project requirements complexity summary

** Number of requirements should be almost properly distributed among complexities.?

** This table has sample data, in real life requirements distribution among complexities will vary.

Since in this article, we consider overall-complexity instead of taking granular-layered-complexity, the following would be the requirement summary from the above table.

Step-5 : Get complexity wise development effort

** PD = person day

In the above table, the last column shows total functional development effort which is the outcome of (requirement count x t-shirt size).?

Step-6 : Consider additional development efforts of non-functional components?

In the above table one can check that the first & second row are actual coding efforts of function & non-functional components or requirements. Development effort for functional components is the same as mentioned in the previous section.

Step-7 : Get ready to arrive on overall project effort for corresponding SDLC phases of your project

For the readers who have not done estimation before, small organization, startup entity, they usually lack standard processes and consider only software-coding effort project-costing and add some factor for margin.?

This table is very useful for those kind of readers, they need to understand that overall-project-effort should also consider for effort burnt during requirement discussion, analysis & assessment of requirement, project management, coordination with multiple stakeholders, aligning decisions with stakeholder, preparing various kinds of documents, writing unit-test, performing functional-test, get user-acceptance through UAT and so on.

Step-8 : Consider additional non-development efforts in overall project efforts on top of regular SDLC components (extension)

Just like we considered efforts for other SDLC phases in overall project efforts, same way there are some additional non-development activities which are burnt during the project-execution.

These activities are completely project dependent, if your project does not require performance engineering, security scan and likewise other non-development activities, one can ignore these activities from the effort calculation approach.

In the last row, one will notice that 75% efficient-factor is considered i.e. 25% efforts are expected to be burnt in non-productive works like discussion, meeting, follow-up and so on. Hene 75% efficient-factor is considered on top of overall development + non-development efforts. Again this factor will depend completely on your effort calculation approach & negotiation strategies.

?

Step-9 : Get the overall project costing for proposal

This is a table whose outcome everybody is interested in including customer and vendor’s management. This is the table which becomes the part of the actual proposal except the information regarding average salary of resources.?

Let’s understand how this table is prepared

1. [Product duration in months], one will get this number from [Overall effort (A + B) after 75% efficiency], divide this number by [number of working days in a month]. Number of days could be any of 21 or 22, or use this number as per your negotiation strategy.
2. [Average team size], this number one will arrive based on experience and expected resource loading. For the sake of explanation, [Average team size = 40] is considered
3. [Project duration in months] = [Product duration in months]/[Average team size]
4. [Average resource salary (Lakh per annum in INR)], one will consider this number based on working location and country standard or resource availability.
5. Finally the [Total project cost in INR (tax excluded)] is [team size] x [average salary (LPA)]

Step-10 : Plan your roles and prepare the resource loading as per roles required for the complete project implementation

** Template for resource-loading.

Roles mentioned in the above table are more-less standard roles, one would need in any software-project development. One can customize as per project need and effort-estimation & cost-estimation arrived in earlier sections.?

One can define the resource profile as per the project expectation, budget, criticality, value-add from the experience, let me share some situations which might help you to find the right resource

1. Enterprise architecture (EA) can play an important role if application-or-platform is large-complex-long (LCL), EA will provide the architecture-vision and approach to achieve the architecture-vision. EA will define the foundation-architecture and related artifacts as explained in earlier article Whitepaper : Software-architecture-as-code (SAaC) and will ensure any modification to these master architecture artifacts. So having this idea in mind, one can plan a dedicated or shareable EA and if shared then what % of allocation should be beneficial for the project.
2. Cloud architect (CA), this role would be required only when the cloud is going to be the deployment platform of your project. CA will define the cloud-strategy and prepare the artifacts related to cloud-infrastructure-setup, scripts for infrastructure-as-code, automated scripts for CI/CD pipeline creation for applicable repositories and so on. Once the IaC scripts are ready for all the entire cloud-infrastructure, applicable architecture-building-blocks (ABB), CI/CD pipeline for all functional repositories, utilization/allocation of CA can be lower down for simple & medium projects, but for LCL kind of projects there should be a dedicated CA and may-be a team of CAs would be required.
3. Security Architect (Sec-A), this role will be to define the security guideline and may-be one can seek advice from EA. Sec-A will perform security vulnerability-scan on expected major software-releases and will make the development-team understand the vulnerability-scan report along with the expected approach to mitigate the vulnerability. Engagement of Sec-A will start a few weeks-or-months earlier than the first major release of a software-project into the QA or UAT environment, so that before deployment into the production environment all security-risks have been fixed or mitigated. Post deployment of the first major release, in agile there will be continuous sprint delivery, there can be automated scripts which can run along with CI/CD pipeline to produce the vulnerability-reports, these scripts will require changes based on changes in EP-URLs or new integration or new ABB introduced. Utilization/allocation of Sec-As can be lower down for simple & medium projects, but for LCL kind of projects there should be a dedicated Sec-A and may-be a team of Sec-As would be required.
4. Performance Architect (PA), similar principle like Sec-A is applied for the engagement of PA. Based on the reports produced by PA, changes in architecture or functional optimization can be performed.
5. So far the above explanation gives a fair idea about each role. One should think about each role considered in the project’s team based on importance, expectation from the role and probable contribution to the project. One can apply this criteria while building the overall project team.

Important reference links

1. 6 Types of Estimation You Can Use in Project Management
2. Software Cost Estimation
3. How to Estimate the Cost of Software Development
4. Cost Estimation Models in Software Engineering
5. Estimation Techniques - WBS
6. Functional Point (FP) Analysis
7. Function Points To Optimize Efforts & Cost
8. COCOMO model by NASA
9. COCOMO Model Template

About author

Profile : Rajesh Verma - Brief profile

Source : link for this article here

Series : S1 (Architecture & design)

Episode : S1E3 ([S1-A&D] Estimating your software project from scratch)

Author’s approach : Rajesh wants to share his learning & experience gained throughout his career from various sources. Author started the series on architectural topics and this article is one of the episodes in that attempt. Author feels that lots of information is available on various forums, but scattered here & there. Episodes in this series will be designed for most of the relevant topics in architecture-&-design, published gradually and organized in logical sequence. Principally episodes will have linkage with other episodes, so that readers can have proper connection among the topics and would be able to correlate with ongoing activities in their software life. Topics for example will be related to functional architecture, integration architecture, deployment architecture, microscopic view of mostly architecture-building-blocks (ABBs), security guidelines & approach to comply, performance KPIs & engineering, git branch & DevOps enabled automation strategy, NFR aspects (e.g. scalability, high-availability, stability, resiliency, etc.), commonly used architecture styles & design patterns, cloudification approaches, multi-tenancy approach, data migration, channel-cutover & rollout strategy, process standardization & simplification, greenfield rollout & brownfield transformation journeys, etc.

Thank you for reading the post, please stay connected.