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 / smith.ascii < prev    next >
Text File  |  1993-10-19  |  12KB  |  318 lines
  1.  
  2.  
  3.  
  4.  
  5.                Reuse  Insertion  in  Small  Embedded  Systems
  6.  
  7.  
  8.  
  9.                                                 Larry Smith
  10.  
  11.  
  12.  
  13.                                         United States AirForce
  14.  
  15.                                Software Technology Support Center
  16.  
  17.                                             OO-ALC/TISEB
  18.  
  19.                                              7278 4th Street
  20.  
  21.                                Hill Air Force Base, UT 84056-5205
  22.  
  23.                                            Tel:  (801) 777-9730
  24.  
  25.                                           FAX: (801) 777-8069
  26.  
  27.                                     Email: smithl@stsc.hill.af.mil
  28.  
  29.  
  30.  
  31.                                                 Vern Phipps
  32.  
  33.  
  34.  
  35.                                                 SofTech, Inc
  36.  
  37.                                            Layton, UT 84056
  38.  
  39.                                            Tel:  (801) 544-9200
  40.  
  41.                                           FAX: (801) 777-8069
  42.  
  43.                                     Email:  phipps@stsc.hill.af.mil
  44.  
  45.  
  46.  
  47.                                                   Abstract
  48.  
  49.  
  50.     The Department of Defense has many large and well-funded projects investigating and in-
  51. serting software reuse. There is a tendency among those organizations to neglect reuse in small
  52. or embedded defense software projects.  The STSC has researched a typicalsmall,  emb edded
  53. system and has results of that study. The STSC has also defined a reuse methodology that can
  54. be applied to these systems with limited resources.
  55.  
  56.  
  57. Keywords: Reuse, process, process improvement, embedded systems
  58.  
  59.  
  60. Workshop Goals:  Learn of actual reuse insertion projects,  all lessons learned,  reuse tools
  61. being used,  and start-up reusemetho dologies.   Contribute information on embedded system
  62. reuse efforts and small software project reuse.
  63.  
  64.  
  65. Working Groups: Reuse process models; reuse maturity models; reuse management, organiza-
  66. tion and economics; design guidelines for reuse; reuse and formal methods; useful and collectible
  67. metrics; tools and environments; reuse handbook.
  68.  
  69.  
  70.  
  71.                                                   Smith- 1
  72.  
  73.  
  74. 1      Background
  75.  
  76.  
  77.  
  78. The  Software  Technology  Support  Center  (STSC) is  part  of  the  Air  Force  Embedded  Comput-
  79. ers Software Improvement Program (ESIP). The overall objective of the STSC is to improve the
  80. software process in the Department of Defense (DoD). The STSC's specific ob jective is to trans-
  81. fer  technologies  and  exchange  information  to satisfy  its  customers  needs  to  continually  improve
  82. software quality and life cycle productivity.  Sp ecial emphasis is given to tools and tool support.
  83.  
  84.  
  85. The  STSC has  established  an  organization  to  investigate  software  reuse  in  the  Air  Force  and
  86. Department of Defense. The STSC has contracted with SofTech, Inc., to provide support in this
  87. effort. Efforts include researching the state-of-the-art in software reuse, determining STSC customer
  88. needs in software reuse, defining software reuse tools, cataloging and evaluating software reuse tools,
  89. and developing a software reuse prototype.
  90.  
  91.  
  92.  
  93. 2      Position
  94.  
  95.  
  96.  
  97. 2.1     Limitations of DoD Efforts
  98.  
  99.  
  100.  
  101. The Department of Defense (DoD) has invested large quantities of money and personnel over many
  102. years to investigate software reuse with the intent of reducing it to a viable approach [1]. Software
  103. reuse has been envisioned as a method of controlling software expenses that take up such a large
  104. portion of current and future budgets. Programs such as STARS, RAPID and AdaNET have spent
  105. large  amounts  of  resources  directed  towards  necessary  research  and  pilot  implementations.  The
  106. results have been important and useful but their objectives have not always been in harmony with
  107. the software needs of the Department ofDefense.
  108.  
  109.  
  110. The emphasis in DoD reuse efforts hasb een towards large Management Information Systems (MIS).
  111. This emphasis has left much of the software efforts in the DoD beyond the scope of reuse insertion.
  112. This represents a significant neglect since thereis a significant amount of software in the DoD that
  113. can not meet the parameters required by large reuse efforts.
  114.  
  115.  
  116.  
  117. 2.2     Embedded Systems
  118.  
  119.  
  120.  
  121. A large  amount  of  software  in  the  DoD is  embedded  into  weapon  systems.   Missiles, aircraft,
  122. tanks,  and command  and  control  systems  all  rely  nearly  completely  upon  software  for  correct
  123. mission  fulfillment.  Often  the  software  process  for  these types  of  systems  is  poorly  defined  and
  124. is  implemented  by  a  small  group  of  people.  Also, embedded  systems  are  commonly  written  in
  125. assembly language and are comparatively small. The systems have existed for many years yet may
  126. be poorly documented and engineered. In many circumstances, this software may be most critical
  127. to the national defense and requires quick and accurate upgrades to b emost effective.
  128.  
  129.  
  130.  
  131. 2.3     Smaller Pro jects
  132.  
  133.  
  134.  
  135. DoD Reuse efforts do not provide suggestions and methods that areapplicable to smaller software
  136. projects.  There is a tendency to imply thata software project must be large in order to support
  137. reuse. We are often told that successful reuse can occur only if a high level language is used, there
  138.  
  139.  
  140.                                                          Smith- 2
  141.  
  142.  
  143. is a defined process, a domain analysis is performed, and a formal repository is supported.  This
  144. necessitates a degree of formality and sophistication to software development that may not exist in
  145. practice in small or embedded existing systems. The expected approach also necessitates a large
  146. and well funded effort with strong management support and understanding.
  147.  
  148.  
  149.  
  150. 2.4     Experiences
  151.  
  152.  
  153.  
  154. Reuse may occur without all of these expectations being met, although not in as large ascale.  An
  155. example is the F-16 software [2, 3 , 4 ].  There is a highdegree of functional reuse between various
  156. versions  of  the  Operational  Flight  Program  (OFP),  yet  there  is  no  formal  attempt  at  reuse.  It
  157. occurs as a result of a small group of software engineers trying to do the most effective job.
  158.  
  159.  
  160. Significant savings can be realized within the DoDby introducing reuse to small, embedded systems.
  161. The savings may not be as measurable or as dramatic as otherlarger and more visible systems.
  162. Yet more people can accomplish more work in less time, and this is a necessary goal in the era of
  163. reduced defense budgets.
  164.  
  165.  
  166. We can learn from the experiences of organizationswho have been forced into reuse by constraints
  167. such as time or resource availability:  They simply had to getthe job done with less resources and
  168. implemented reuse methods as their approach. Examples of this are the Navy's RNTDS project
  169. and ICBM software.
  170.  
  171.  
  172.  
  173. 2.5     RNDTS
  174.  
  175.  
  176.  
  177. The RNTDS project [5 ] has a very high degree of successful reuse and was implemented before
  178. methods were developed by such organizations as the Software Engineering Institute (SEI) or the
  179. Software Technology for Adaptable, Reliable Systems (STARS)Project.  The project engineers were
  180. faced with the reality of not enough resources to do their job and developed a reusable software
  181. system as a result.
  182.  
  183.  
  184.  
  185. 2.6     ICBM Software
  186.  
  187.  
  188.  
  189. There were two significant cases of reuse in the ICBM: The development of Minuteman III from
  190. Minuteman  II technology  and  the  development  of  Peacekeep er  from  Minuteman  III  technology.
  191. This reuse was the result of critical national need where theluxury of re-developing software was
  192. not available. No formal analysis of ICBM software reuse has occurred, but it is a fertile field for
  193. determining methods and successes.
  194.  
  195.  
  196.  
  197. 2.7     STSC's Contribution
  198.  
  199.  
  200.  
  201. The STSC has conducted a pilot program into a small, embedded system [6, 7].  The F-16 A/BHead-
  202. Up Display (HUD) software (and the supporting process) was analyzed from a reuse perspective. It
  203. was found that some reuse occurred as a natural result of engineers doing the b est job they could.
  204. Many opportunities for reuse were identified thatwere not currently being utilized, especially in
  205. non-code assets.  There is a process in place that generally supports reuse, but a higher degree of
  206. emphasis would result in measurable savings.
  207.  
  208.  
  209.  
  210.                                                          Smith- 3
  211.  
  212.  
  213. 2.8     Conclusions
  214.  
  215.  
  216.  
  217. Reuse will occur if it must be done to meet external forces. A formal, repeatable process as defined
  218. by the major DoD reuse efforts does not have to be present in order to have success.  The reuse-
  219. oriented  organizations  need  to  realize  this  and  offer help  to  those  that  are  currently  not  being
  220. noticed.  The types of software reuse described in this section has often been dismissed as ad hoc
  221. and thus not interesting.  Yet this type of reuse has had and can continue to have a significant
  222. benefits on software cost in the DoD.
  223.  
  224.  
  225.  
  226. 2.9     Recommended modifications
  227.  
  228.  
  229.  
  230. DoD reuse efforts should take smaller and embedded systems more seriously in their research into
  231. software  process  improvement.   Much  ground  can  be  gained  by  simply  educating  organizations
  232. involved in small and embedded systemsin the principles of reuse.  There needs to be an attitude
  233. change that these systems are not important or interesting enough to be considered when it comes
  234. to software reuse.
  235.  
  236.  
  237.  
  238. 2.10      STSC Efforts
  239.  
  240.  
  241.  
  242. Much was learned from the STSC's review of the F-16 A/B HUD software. These experiences can
  243. be extrapolated into other F-16 OFPs and other embedded systems. The experience demonstrates
  244. that there are viable possibilities for improving the software process with a reuse emphasis in small,
  245. embedded systems.
  246.  
  247.  
  248. The STSC has also produced a reuse methodology that can be applicable to any sort of system,
  249. whether small,  large,  embedded or MIS. This methodology takes into accounts the funding and
  250. resource limitations that may exist in small projects and deals with concerns of existing embedded
  251. system projects.
  252.  
  253.  
  254.  
  255. 3      Comparison
  256.  
  257.  
  258.  
  259. The DoD efforts in software reuse have a tendency to support the concept that reuse can only be
  260. successful  in  large  projects  with  well-defined  domains  and  software  processes.  This  implies  also
  261. that the projects must be well-financed and visible.  The STSC contends that this unnecessarily
  262. leaves a significant portion of the DoD software community out of the reuse technology.
  263.  
  264.  
  265.  
  266. References
  267.  
  268.  
  269.  
  270. [1]  "DOD Software Reuse Initiative: Vision and Strategy."
  271.  
  272.  
  273. [2]  "Domain Reviewof the F-16 HUD OFP," tech. rep., SofTech, Inc, April 1992.
  274.  
  275.  
  276. [3]  "Review of theF-16 A/B HUD OFP C5 Document," tech. rep., SofTech, Inc, April 1992.
  277.  
  278.  
  279. [4]  "Review of theF-16 HUD OFP B5 Document," tech. rep., SofTech, Inc, April 1992.
  280.  
  281.  
  282.  
  283.                                                          Smith- 4
  284.  
  285.  
  286. [5]  J. Aridis, "Deriving and managing functional commonality for software reuse: An rntds expe-
  287.      rience," CrossTalk, February 1992.
  288.  
  289.  
  290. [6]  "STSC Reuse State-of-the-Art Report," tech. rep., STSC, August 1992.
  291.  
  292.  
  293. [7]  "STSC Reuse Metho dologyRep ort," tech. rep., STSC, July 1993.
  294.  
  295.  
  296.  
  297. 4      Biography
  298.  
  299.  
  300.  
  301. Larry  W.  Smith is a Software Engineer at the AirForce Software Technology Support Center
  302. (STSC).  He  is  the  Project  Lead  for  Software  Reuse.  Additionally, he  works  closely  with  other
  303. software technology domains to assist Air Force and DoD Software Development and Maintenance
  304. Activities (SDSA) with software process improvement.  He received a Bachelors of Science in Elec-
  305. trical Engineering from the University of Utah, and is currently working towards a M.S. degree
  306. in Computer Science from Utah State University.  Vern Phipps is a Software Consultant with the
  307. Ogden, Utah SofTech Office. He is currently the Ogden Office Reuse Project Lead Engineer. Mr.
  308. Phipps previously worked for TRW, Inc.  where he supported the analysis and MODE maintenance
  309. of Minuteman and Peacekeeper software and performed nuclear safety analysis. Previous to TRW,
  310. Mr.  Phipps  was  employed  by  the  National  Computer  Security  Center  and  was  assigned  as  the
  311. NSA Liaison Officer for Computer Security for the I-S/A AMPEprogram at Gunter AFB, AL.
  312. He received a Bachelors of Science degree in Computer Science from Brigham Young University in
  313. 1983.
  314.  
  315.  
  316.  
  317.                                                          Smith- 5
  318.