Page 49 - The Art of Designing Embedded Systems
P. 49

36 THE ART OF  DESIGNING EMBEDDED SYSTEMS


                           COCOMO Data
                           Barry Boehm codified this concept in his Constructive Cost Model
                       (COCOMO). He found that
                                    Effort to create a project  = C  x  KLOC‘.

                       (KLOC means “thousands of lines of code.”)
                           Though the exact values of C and M vary depending on a number of
                      factors (e.g., real-time code is harder than that for the user interface), both
                      are always greater than 1.
                           A bit of  algebra shows that, since M > 1, effort grows much faster
                      than the size of the program.
                           For real-time projects managed with the very best practices, C is typ-
                       ically 3.6 and M around  1.2. In embedded systems, which combine the
                      worst problems  of  real time with hardware dependencies,  these coeffi-
                      cients are higher. Toss in the typical poor software practices of the em-
                      bedded industries and the M exponent can climb well above 1.5.
                           Suppose C = 1 and M = 1.4. At the risk of oversimplifying Boehm’s
                      model, we can still get an idea of the nonlinear growth of complexity with
                      program size as follows:
                           Lines of   Effort   Comments
                           code
                           10,000      25.1
                           20,000      66.3   Double size of code; effort goes up by 2.64
                           100,000    63  1   Size grows by factor of  10; effort grows by 25

                           So, in doubling the  size of the program  we incur  32% additional
                       overhead.
                           The human analogy of this phenomenon is the one so colorfully il-
                      lustrated by Fred Brooks in his The Mythical Man-Month (a must read for
                      all software folks). As projects grow, adding people has a diminishing re-
                      turn. One reason  is the  increased number of communications channels.
                      Two people can only talk to each other; there’s only a single comm path.
                      Three workers have three communications paths; four have six. In fact, the
                       growth of links is exponential: given n workers, there are (n2  - n)/2 links
                      between team members.
                           In other words, add one worker and suddenly he’s interfacing in n2
                      ways with the others. Pretty soon memos and meetings eat up the entire
                      work day.
                           The solution is clear: break teams into smaller, autonomous, and in-
                      dependent units to reduce these communications links.
   44   45   46   47   48   49   50   51   52   53   54