Effort Estimation for Embedded Software Development PDF Print E-mail
Article Index
Effort Estimation for Embedded Software Development
Effort Estimation for Embedded Software Development
All Pages

By Gustavo Cubas, Software Engineering Manager, Avionyx.

Software cost estimation has been a subject of academic and practitioners research since the start of software engineering in the 1950s.  Considering the number of variables that affect software productivity, it is no surprise that today, sixty years later, most companies continue to rely on expert judgment to estimate software development costs.  The majority of the software estimation models have been developed and used mostly in the domain of business applications.  This article provides a brief introduction to the subject of software estimation and how to apply them to the development of embedded applications.  Follow-up articles will elaborate on the methods enumerated in this introductory article.

Introduction

In his classic paper “No Silver Bullet”[1] , Turing Prize winner Frederick Brooks identified four essential characteristics of software:

  • Complexity: because the interactions of components in a software program grow in a non-linear fashion with respect to its size.
  • Conformity: because software has to conform to an arbitrary complexity imposed by human institutions and the systems it has to interface with.
  • Changeability: because software is constantly subject to pressure of change.
  • Invisibility: because software is invisible and difficult to visualize, depriving developers from the most powerful conceptual tool for reasoning about it: a visual representation.

In the development process, the software engineer has to deal with these essential characteristics along with other challenges that affect productivity, such as environmental factors, tool and platform issues.

Software development can be seen as a construction process or as a problem-solving endeavor.  In the first case, software estimation would consist of sizing the software product and using a software-size/time productivity metric to determine the effort required.  If software development is seen as a problem solving activity, then we would need do measure product complexity and the team’s problem solving productivity to estimate effort.  In practice, software development effort is affected by both product size and product complexity.

In 1981 Barry Boehm[2] made us realize that the accuracy of the estimation improves as we progress through the software lifecycle.  The concept was later made more general and named the Cone of Uncertainty by Steve McConnell[3].  

From this point of view, the estimation of the verification tasks should be more accurate once the requirements and code of the system are already written.  Figure 1 shows how estimation accuracy improves as the project approaches completion.


Figure 1 Software estimation accuracy versus phase (Source: Boehm 81)

Software is an abstract product resulting from the conjunction of a number of variables that affect the software development process, all of which are very hard to characterize and to measure, much less predict.  Norman Fenton[4] identified three types of entities that intervene in the software process:

  • ProductProduct Process Resources
  • Process
  • Resources

The number of variables that can be included under any one of these categories can be overwhelming.  Multiple surveys and reports have identified numerous critical factors that make software projects overrun budgets and schedules.  While it is tempting to consider the possibility of developing a model that takes into consideration all of the possible factors, its complexity would make it unpractical.  Table 1 shows some of the most commonly referred factors that affect project performance.  Not only is it difficult to characterize and measure these variables, it is also difficult to identify critical factors that are unknown when preparing the estimate: these factors are commonly called risks.

In spite of all the uncertainty you have to deal with, customers and managers expect that you, as a software engineer, are able to provide an estimate within a reasonable degree of confidence.  Fortunately, there are several models you can keep in your toolbox to use depending on the problem at hand.

Process Factors
  • Project lifecycle
  • Process maturity
  • Criticality
  • Budgetary constraints
  • Schedule constraints

Resource Factors
  • Turnover
  • Developer and team experience
  • Developer capability
  • Team size
  • Team location
  • Team dynamics
  • Platform capabilities
  • Development tools
Product Factors
  • Requirements volatility
  • Requirements clarity
  • Component complexity
  • Concurrency
  • Timing constraints
  • Inter-component complexity
  • Reuse requirements
  • Usability requirement

Table 1.  Some factors that affect productivity


[1] Brooks, F. P. 1995.  The Mythical Man-Month (Anniversary Ed.). Addison-Wesley Longman Publishing Co., Inc.

[2] Boehm, B. W. 1981.  Software Engineering Economics.  Prentice Hall PTR.

[3] McConnell, S. 2006. Software Estimation: Demystifying the Black Art (Best Practices (Microsoft)). Microsoft Press.

[4] Fenton, N. 1994. Software Measurement: A Necessary Scientific Basis. IEEE Trans. Softw. Eng. 20, 3 (Mar. 1994), 199-206.



 
AddThis Social Bookmark Button