home *** CD-ROM | disk | FTP | other *** search
/ ftp.umcs.maine.edu / 2015-02-07.ftp.umcs.maine.edu.tar / ftp.umcs.maine.edu / pub / WISR / wisr6 / proceedings / ascii / abdel-hamid.ascii next >
Text File  |  1993-10-19  |  19KB  |  373 lines

  1.  
  2.  
  3.  
  4.  
  5. Modeling  The  Dynamics  of  Software  Reuse:  An  Integrating System
  6.  
  7.  
  8.                                            Dynamics Perspective
  9.  
  10.  
  11.  
  12.                                                Tarek K. Abdel-Hamid
  13.  
  14.  
  15.  
  16.                                  Associate Professor of Information Systems
  17.  
  18.                                              Naval Postgraduate School
  19.  
  20.                                                       Code AS/AH
  21.  
  22.                                                  Monterey, CA 93943
  23.  
  24.                                                   Tel:  (408) 656-2686
  25.  
  26.                                        Email: 3991p@vm1.cc.nps.navy.mil
  27.  
  28.                                                  Fax: (408) 656-3407
  29.  
  30.  
  31.  
  32.                                                          Abstract
  33.  
  34.  
  35.            An integrating System Dynamics approach for modeling software reuse is proposed. The ap-
  36.        proach has three unique features. First, it integrates the multiple functionsof the software reuse
  37.        process,  includingb oth themanagerial activities (e.g., setting reuse production/consumption
  38.        goals, allocating resources, staffing, etc.) as well as the technical activities (reusable component
  39.        identification, generation, consumption, etc.).  Second, themo del usesthe feedback principles
  40.        of system dynamics as a conceptual lens to view and analyze the complex web of dynamically
  41.        interacting variables. Third, computer simulation is utilized to handle the dynamic complexity
  42.        of the model and to conduct controlled experimentation.
  43.            The model serves as a "learning laboratory" to study the software reuse phenomenon and
  44.        gain a better understanding of the interactions and trade-offs that characterize reuse policy
  45.        decisions, as well as serve as a management support tool to evaluate/design organizational reuse
  46.        policies.
  47.  
  48.  
  49.        Keywords: reuse modeling, reuse management, system dynamics
  50.  
  51.  
  52.        Workshop Goals: Advancing state of the art in reuse dynamic modeling; Learning.
  53.  
  54.  
  55.        Working Groups:  Reuse management, organization, and economics; reuse process models;
  56.        education.
  57.  
  58.  
  59.  
  60.                                                      Abdel-Hamid- 1
  61.  
  62.  
  63. 1      Background
  64.  
  65.  
  66.  
  67. My work on modeling the dynamics of software reuseis an extension of an ongoing research pro-
  68. gram to study, gain insight into,  and make predictions about the dynamics of the entire software
  69. development  process.  This  is  being  accomplished  through  the  development  of  dynamic pro cess
  70. models using the techniques of System Dynamics. System Dynamics is the application of feedback
  71. control  systems  principles  to  model,  analyze,  and  understand  the dynamic  behavior  of  complex
  72. systems. Its origins trace back to the pioneering work of Jay W. Forrester [1 ].
  73.  
  74.  
  75. To-date, the focus of my work has been on the study ofsoftware project management [2 , 3].  For
  76. example, my colleagues and I have modelled/investigated the dynamics of software project staffing
  77. [4 ]; cost/schedule estimation [5 ]; quality assurance economics [4 ]; and organizational learning [6 ].
  78.  
  79.  
  80. The current research effort extends the application of the System Dynamics technique to model
  81. the dynamics of software reuse. In contrast to our project management models which focus on the
  82. individual  project  lifecycle, the  scope  here  is  broadened  to  capture  the  operations  of  a  software
  83. development organization as multiple software products are developed, placed into operation, and
  84. maintained over a long period of time.
  85.  
  86.  
  87.  
  88. 2      Position
  89.  
  90.  
  91.  
  92. Experience from working with managers in many environments indicates that they are generally
  93. able to specify the detailed relationships and interactions among managerial p olicies, resources, and
  94. performance. However, managers are usually unable to determine accurately the dynamic behavior
  95. implied by these relationships.  Human intuition,  studies have shown, is ill-suited for calculating
  96. the consequences of a large number of interactionsover time, especially when cause and effect are
  97. distant in time and space [7].  This can, and often does, lead to the adoption of policies that prove
  98. dysfunctional in the long run.
  99.  
  100.  
  101. Thus, one  motivation  for  developing  computer-based  models  of  complex  socio-technical  systems
  102. (such as software reuse), is to havea capability to reliably and efficiently trace through time the
  103. implications of a complex web of system interactions.  By utilizing computer simulation techniques
  104. we, thus, combine, the strengths of thesoftware manager with the strengths of the computer. The
  105. manager aids by specifying relationships within his/her software reuse environment (e.g., effect of
  106. staff experience on reuse rate), the computer then calculates the long-term dynamic consequences
  107. of these relationships (e.g., on productivity, quality, etc.).
  108.  
  109.  
  110. A second reason for constructing computer-based models, is for experimentation. Engineers turn
  111. to laboratory experiments to learn about the behavior of complex engineering systems. Our social
  112. systems  are  far  more  complex  and  harder  to  understand  than  our technological  systems.  Why,
  113. then, do we not use the same approach of making computer models of social systems, such as a
  114. software development organization, and conduct laboratory experiments on these models?
  115.  
  116.  
  117.  
  118.        (quote) The answer is often stated that our knowledge of social systems is insufficient
  119.        for constructing useful models.  But what justification can there be for the apparent
  120.        assumption that we do not know enough to construct models but believe we do know
  121.        enough  to  directly  design  new  social  systems?   ...   I am  suggesting  that  we  now  do
  122.        know  enough  to  make  useful  models  of  social  systems.  Conversely, we  do  not  know
  123.  
  124.  
  125.  
  126.                                                      Abdel-Hamid- 2
  127.  
  128.  
  129.        enough to design the most effective social systems directly without first going through
  130.        a model-building experimental phase [8 ].
  131.  
  132.  
  133.  
  134. Indeed, over  the  last  three  decades  the  work  of  Forrester  and  others  in  the  System  Dynamics
  135. field demonstrated both the feasibility and utility of constructing computer-based models to study
  136. complex social systems. More recently, the technique has been successfully applied to the software
  137. project domain [2 ]. Using these tools, the software reuse manager, like the engineer, can have a
  138. laboratory in which he/she can simulate organizational behavior and learn quickly and at low cost
  139. the answers that would seldom be obtainable from trials on real pro jects.
  140.  
  141.  
  142. Characteristic features of proposed modeling approach. The proposed approach has three unique
  143. features.  First, the model integrates the multiple functions of the software reuse process, includ-
  144. ing  both  the  managerial  functions  (e.g., setting  reuse  production/consumption  goals, allocating
  145. resources, staffing, etc.) as well as the technical activities of reuse (e.g., reusable component iden-
  146. tification,  generation,  consumption,  etc.).  This  contrasts  with  most  of  the  research  to-date  on
  147. software  reuse  which  tended  to  emphasize  one  aspect  or  problem  area  in  isolation  e.g., domain
  148. analysis,  organizational rewards,  identification/ qualification of reusablecomp onents,  economics,
  149. etc. Clearly such micro-oriented research does make a useful contribution to our understanding of
  150. the software reuse phenomenon. However, before we cansay that we have a complete understand-
  151. ing, it is necessary to show that our knowledge of the individual components can be put together
  152. in a total system i.e., an organization can be synthesized, which allows for the interactions of all
  153. the relevant variables and of all the structural components [9 ].
  154.  
  155.  
  156.  
  157.        There  is  a  need  to  learn  what  the  relationships  are  between  the  technical  and  non-
  158.        technical  aspects,  how  one  influences  the  other,  and  what  makes  a  reuse  program  a
  159.        success  or  a  failure.  Reuse  should  be  seen  as  a  whole,  as  an  integrated  system  and
  160.        therefore addressed as such.  To see reuse as a separate and independent collection of
  161.        tools, techniques, or methods will only perpetuate the current status [10 ].
  162.  
  163.  
  164.  
  165. The second unique feature of the proposed modeling approach is the use of the feedback principles
  166. of system dynamics to structure and clarify the complex set of dynamically interacting variables.
  167. Feedback is the process in which an action taken by a person or thing will eventually affect that
  168. person or thing. A feedback loop is the closed sequence of causes and effects, from an initial cause,
  169. its series of ripples through an entire chain of causes and effects, until the initial cause eventually
  170. becomes an indirect effect of itself. Circular feedback processes are universal in social systems, the
  171. software engineering domain being no exception [2].
  172.  
  173.  
  174. The third feature, is the reliance on computer simulation to handle the dynamic complexity of such
  175. a model, and to serve as a "laboratory" for controlled experimentation.
  176.  
  177.  
  178.  
  179.        By using a (simulation) model of a complex system, more can be learned about internal
  180.        interactions than would ever be possible through manipulation of the real system. In-
  181.        ternally, the model provides complete control of the system's organizational structure,
  182.        its policies, and its sensitivities to various events [1].
  183.  
  184.  
  185.  
  186. Overview of model structure and behavior. The model is quite detailed, containing more than 200
  187. difference equations. Providing a full description of the model's structure is, thus, beyond the scop e
  188. of this paper.  Instead, I provide an overview of the model's five ma jor sectors, which are shown
  189.  
  190.  
  191.                                                      Abdel-Hamid- 3
  192.  
  193.  
  194. in Figure 1.  At the top of the figure is the software development and maintenance sector.  The
  195. function of this sector is to provide the overall organizational setting within which software reuse
  196. is conducted and managed.  It provides a characterization of the mo deledorganization's unique
  197. software development environment (e.g., size of project portfolio, average size of projects, type of
  198. software, maintenance backlog, etc.).
  199.  
  200.  
  201. Having defined a particular organizational setting, we can next model the specific software reuse
  202. activities of interest. These are captured in two highly interdependent sectors, a reusable compo-
  203. nents production sector, and a reusable components consumption sector.  The production sector
  204. models the reusable components repository and the production process that populates it. Factors
  205. affecting the reusable component deposition rate include the degree of functionaloverlap between
  206. applications in the domain,  organizational reuse support,  learning,  schedule pressures,  perceived
  207. costs, and  organizational  goals.  Two  things  to  note  here.  First, that  most  of  these  factors  are
  208. dynamic, that is, they can change overtime.  And second, the distinction between reality and the
  209. perception of reality (e.g., as in "perceived" costs).
  210.  
  211.  
  212. Similarly, the reuse consumptionsector captures the reuse consumption rate and its determinants.
  213. These include: perceived benefits of reuse, repository size, reuse support, learning, overlap between
  214. applications, and schedule pressure.
  215.  
  216.  
  217. The software production, maintenance, and reuse activities are all very much affected, and they
  218. themselves affect, the size and characteristics of the organization's human resource.  The human
  219. resource sector captures the hiring and firing of staff, staff resourceallo cation, training, turnover,
  220. etc.
  221.  
  222.  
  223. Finally, the  management  policy  sector  provides  the  leverage  p oints  in  the  model  through  which
  224. management can affect the software reuse pro cess. Possible managerialinterventions include setting
  225. reuse goals, allocating resources, organization, etc.
  226.  
  227.  
  228. As suggested above, the software reuse process, like mostorganizational systems, is characterized
  229. by a complex network of interconnected feedback loops.  As an example, two simple feedback loops
  230. are  depicted  in  Figure  2.  The  lower  loop  is  a  positive  self-reinforcing  feedback  loop.  It  shows
  231. how reuse can increase an organization's software development productivity, which would increase
  232. the organization's software delivery rate,  this inturn can lead to the generation of more reusable
  233. components, which ultimately can lead to even higher reuse rates.
  234.  
  235.  
  236. This  self-reinforcing  loop  is  counterbalanced  by  the  negative  feedback  loop  that  is  also  shown.
  237. This  second  loop  shows  that  a  high  level  of  reuse  would  decrease  the  amount  of  new/original
  238. software components developed, which, in turn, decreases the opportunities for developing reusable
  239. components. A reduction in the production of reusable components could then slow down or even
  240. decrease reuse.
  241.  
  242.  
  243. Which of the two loops is dominant? To answer this question, we rely on the simulation capability
  244. of  the  model.  A simulation  run  is  shown  in  Figure  3.  It  shows  that  the  two  feedback  lo ops of
  245. Figure 2 interact in a non-linear fashion. A  linear-typ e interaction would have led to constantly
  246. increasing or decreasing reuse consumption and production rates (depending on which of the two
  247. loops is more dominant).  Instead, the simulation shows that initially the p ositive feedback loop
  248. dominates. That is, in the early phases of a software reuse effort, when the reuse rate is relatively
  249. low, the reuse process "feeds on itself" to produce a period of accelerating growth.
  250.  
  251.  
  252. Eventually,  however,  growth  slows  down.  In  this  simulation  run, this  happens  way  before  the
  253. organization reaches its theoretical reuse potential (which in this particular case is 60the balancing
  254.  
  255.  
  256.  
  257.                                                      Abdel-Hamid- 4
  258.  
  259.  
  260. influence of the negative feedback loop. For as the reuse rate goes higher and higher, the amount
  261. of new/original code being developed decreases. This leads to smaller and smaller depositions to
  262. the repository.  And because older reusable components are continuously being retired from the
  263. repository, the  repository's  size  levels  off, and  even  starts  decreasing  slightly  (as  shown  in  the
  264. figure). As this happens, the reuse rate follows.
  265.  
  266.  
  267. Model Utility.  The mo del willserve as a "learning laboratory" to study the software reuse phe-
  268. nomenon and gain a better understanding of the interactions and trade-offs that characterize reuse
  269. policy decisions, as well as servs as a management support tool to evaluate/design organizational
  270. reuse policies.
  271.  
  272.  
  273.  
  274. 3      Comparison
  275.  
  276.  
  277.  
  278. Most of the research to-date on software reuse has tended to emphasize one aspect or problem area
  279. e.g.,  domain analysis [11 ],  incentives [12, 13  ],  identification/qualification of reusable components
  280. [14 ],  economics [15 ],  etc.  In this research effort I build upon and extend what has been learned
  281. about the "pieces" of the software reuse phenomenon to construct a holistic dynamic model of the
  282. software reuse process that would allowus to study the complex set of interactions and trade-offs
  283. that characterize the process.
  284.  
  285.  
  286.  
  287. References
  288.  
  289.  
  290.  
  291.   [1] J. Forrester, Industrial Dynamics. The MIT Press, Cambridge, Mass, 1961.
  292.  
  293.  
  294.   [2] T. Abdel-Hamid and Madnick, SoftwareProject Dynamics: An Integrated Approach. Prentice-
  295.       Hall, Inc., Englewood Cliffs, New Jersey, 1991.
  296.  
  297.  
  298.   [3] T. Abdel-Hamid and S. Madnick, "Lessons learned from modeling the dynamics of software
  299.       development," Communications of theACM, 1989.
  300.  
  301.  
  302.   [4] T. Abdel-Hamid, "The dynamics of software project staffing: A system dynamics based sim-
  303.       ulation approach.," IEEE Transactions on Software Engineering, Feb. 1989.
  304.  
  305.  
  306.   [5] T.  Abdel-Hamid,  "Adapting,  correcting,  and  perfecting  software  estimates:  A  maintenance
  307.       metaphor," IEEE Computer, Mar. 1993.
  308.  
  309.  
  310.   [6] T. Abdel-Hamid and S. Madnick, "The elusive silver lining:  How we fail to learn from software
  311.       development failures," Communications of the ACM, 1990.
  312.  
  313.  
  314.   [7] G. Richardson and G. I. Pugh, Introduction to System Dynamics Modeling with Dynamo. The
  315.       MIT Press, Cambridge, Mass., 1981.
  316.  
  317.  
  318.   [8] J. Forrester, "Counterintuitive behavior of social systems," Technology Review, vol. 73, Jan.
  319.       1971.
  320.  
  321.  
  322.   [9] M. L. Griss, "A multi-disciplinary software reuse research program," in Proceedings of the 5th
  323.       Annual Workshop on Software Reuse, Palo Alto, CA., 1992 (M. Griss and L. Latour, eds.),
  324.       pp. Griss-1:8, Department of Computer Science, University of Maine, Nov. 1992.
  325.  
  326.  
  327. [10]  R. Prieto-Diaz, "Making software reuse work:  An implementation model," Software Engineer-
  328.       ing Notes, vol. 16, July 1991.
  329.  
  330.  
  331.                                                      Abdel-Hamid- 5
  332.  
  333.  
  334. [11]  R.  Prieto-Diaz,  "Domain  analysis:  An  introduction,"  Software  Engineering  Notes,  vol. 15,
  335.       no. 2, pp. 47-54, 1990.
  336.  
  337.  
  338. [12]  W. Tracz, "Software reuse:  Motivators and inhibitors," in COMPCON87, San Francisco, CA,
  339.       Feb. 1987.
  340.  
  341.  
  342. [13]  R. Holibaugh and J. Morin, "A reuse incentive model," in The 5th Annual Software Technology
  343.       Conference, HQ USAF/SC-USAF STSC, Apr. 1993.
  344.  
  345.  
  346. [14]  G. Caldiera and V. Basili, "Identifying and qualifying reusable software components," IEEE
  347.       Computer, Feb. 1991.
  348.  
  349.  
  350. [15]  J. Gaffney and R. Cruickshank, "A general model of software reuse," in Proceedings of The
  351.       1992 International Conference on Software Engineering, Melbourne, Australia, May 1992.
  352.  
  353.  
  354.  
  355. 4      Biography
  356.  
  357.  
  358.  
  359. Dr.  Tarek K.Ab del-Hamid is an Associate Professor of Information Systems at the Naval Post-
  360. graduate  School.  Before  joining  NPS,  he  spent  two  and  a  half  years  at  the Stanford  Research
  361. Institute. He is an advisor to NASA's Jet Propulsion Laboratory (since 1988) on the development
  362. of computer-based tools for software project management.  He received the B.S. degree in aero-
  363. nautical engineering from Cairo University, Cairo, Egypt, in 1972, and the Ph.D. in management
  364. information systems from MIT in 1984.  Hisresearch interests focus on software project manage-
  365. ment, software reuse, and system dynamics.  He has authored or coauthored more than 30 papers on
  366. these topics and is the coauthor of Software Project Dynamics: An Integrated Approach (Prentice-
  367. Hall, 1991).  Dr.  Abdel-Hamid is a member of the ACM, SIM, IEEE-CS, and the System Dynamics
  368. Society.
  369.  
  370.  
  371.  
  372.                                                      Abdel-Hamid- 6
  373.