%%%%%% TEMPLATE.TEX for WISR'93, version 1.2.1, 10/3/93 %%%%%%
%%%%%% Updated by Jeffrey S. Poulin,  May 1993          %%%%%%
%%%%%% Updated by Larry J. Latour     and               %%%%%% 
%%%%%%            Steve L. Philbrick, October 1993      %%%%%%
%%%%%%
\markboth{Smith}{Smith}
\documentstyle[11pt]{article}
 
% Standard Spacing for WISR - do not change!!
%
% Page dimensions.
%
\oddsidemargin  0.26in % Leave enough for binding margin
\evensidemargin 0.26in %
\topmargin      -1.00in % (adjusted for printer bias)
\headheight      .00in  % (no headers)
\headsep         .75in  % (top margin + headers + skip)
\footheight     12.0pt  % ??? (seems to work ok)
\footskip       25.0pt  % ??? ( "   "  )
\textheight     9.425in % (instructions: 9 1/8" min, 9 7/16" max)
\textwidth      6.5in   %

\markboth{Smith}{Smith}
\pagestyle{myheadings}
%
% Paragraph changes.
%
\parindent=0pt
\parskip=10pt
%
% can make the title box even smaller
%
\def\@maketitle{\vbox to 2.6in{\hsize\textwidth
    \linewidth\hsize \vfil \centering
    {\large \@title \par}
    \vskip 2em
    {\normalsize
    \begin{tabular}[t]{c}\@author
    \end{tabular}\par}
    \vfil}
}
 
\begin{document}
 
\bibliographystyle{ieeetr}
 
\title{Reuse Insertion in Small Embedded Systems}

\author{Larry Smith\\
\\
United States Air Force\\
Software Technology Support Center\\
OO-ALC/TISEB\\
7278 4th Street\\
Hill Air Force Base, UT 84056-5205\\
Tel: (801) 777-9730\\
FAX: (801) 777-8069\\
Email:  smithl@stsc.hill.af.mil\\
\\
Vern Phipps\\
\\
SofTech, Inc\\
Layton, UT 84056\\
Tel: (801) 544-9200\\
FAX: (801) 777-8069\\
Email:  phipps@stsc.hill.af.mil\\
}
\date{}
 
\maketitle
 
\begin{abstract}

The Department of Defense has many large and well-funded projects         
investigating and inserting software reuse.  There is a tendency among those 
organizations to neglect reuse in small or embedded defense software        
projects.  The STSC has researched a typical small, embedded system and has
results of that study.  The STSC has also defined a reuse methodology that
can be applied to these systems with limited resources.                  

\vspace{0.2in}
\noindent
{\bf Keywords:} Reuse, process, process improvement, embedded systems                  

\vspace{0.2in}
\noindent
{\bf Workshop Goals:} Learn of actual reuse insertion projects, all lessons 
learned, reuse tools being used, and start-up reuse methodologies. Contribute 
information on embedded system reuse efforts and small software project reuse.          

\vspace{0.2in}
\noindent
{\bf Working Groups:} Reuse process models; reuse maturity models; reuse 
management, organization and economics; design guidelines for reuse; reuse 
and formal methods; useful and collectible metrics; tools and environments; 
reuse handbook.           
 
\end{abstract}
 

\newpage
\section{Background}
 
The Software Technology Support Center (STSC) is part of the Air Force   
Embedded Computers Software Improvement Program (ESIP).  The overall    
objective of the STSC is to improve the software process in the Department of
Defense (DoD).  The STSC's specific objective is to transfer technologies and
exchange information to satisfy its customers needs to continually improve  
software quality and life cycle productivity.  Special emphasis is given to 
tools and tool support.                                                    

The STSC has established an organization to investigate software reuse in the
Air Force and Department of Defense.  The STSC has contracted with SofTech, 
Inc., to provide support in this effort.  Efforts include researching the  
state-of-the-art in software reuse, determining STSC customer needs in    
software reuse, defining software reuse tools, cataloging and evaluating 
software reuse tools, and developing a software reuse prototype.        

 
\section{Position}
\subsection{Limitations of DoD Efforts}

The Department of Defense (DoD) has invested large quantities of money and 
personnel over many years to investigate software reuse with the intent of
reducing it to a viable approach \cite{DOD}.  
Software reuse has been envisioned as a
method of controlling software expenses that take up such a large portion of 
current and future budgets.  Programs such as STARS, RAPID and AdaNET have  
spent large amounts of resources directed towards necessary research and   
pilot  implementations.  The results have been important and useful but their
objectives have not always been in harmony with the software needs of the   
Department of Defense.                                                     

The emphasis in DoD reuse efforts has been towards large Management       
Information Systems (MIS).  This emphasis has left much of the software  
efforts in the DoD beyond the scope of reuse insertion.  This represents a
significant neglect since there is a significant amount of software in the
DoD that can not meet the parameters required by large reuse efforts.    

\subsection{Embedded Systems}

A large amount of software in the DoD is embedded into weapon systems. 
Missiles, aircraft, tanks, and command and control systems all rely nearly 
completely upon software for correct mission fulfillment.  Often the software
process for these types of systems is poorly defined and is implemented by a
small group of people.  Also, embedded systems are commonly written in     
assembly language and are comparatively small.  The systems have existed for
many years yet may be poorly documented and engineered.  In many           
circumstances, this software may be most critical to the national defense and
requires quick and accurate upgrades to be most effective.                  

\subsection{Smaller Projects}

DoD Reuse efforts do not provide suggestions and methods that are applicable
to smaller software projects.  There is a tendency to imply that a software
project must be large in order to support reuse. We are often told that   
successful reuse can occur only if a high level language is used, there is a 
defined process, a domain analysis is performed, and a formal repository is 
supported.  This necessitates a degree of formality and sophistication to  
software development that may not exist in practice in small or embedded  
existing systems.  The expected approach also necessitates a large and well
funded effort with strong management support and understanding.           

\subsection{Experiences}

Reuse may occur without all of these expectations being met, although not in
as large a scale.  An example is the F-16 software 
\cite{SofTech92a,SofTech92b,SofTech92c}.  There is a high degree
of functional reuse between various versions of the Operational Flight    
Program (OFP), yet there is no formal attempt at reuse.  It occurs as a result 
of a small group of software engineers trying to do the most effective job.

Significant savings can be realized within the DoD by introducing reuse to 
small, embedded systems.  The savings may not be as measurable or as dramatic
as other larger and more visible systems.  Yet more people can accomplish   
more work in less time, and this is a necessary goal in the era of reduced 
defense budgets.                                                          

We can learn from the experiences of organizations who have been forced into
reuse by constraints such as time or resource availability:  They simply had
to get the job done with less resources and implemented reuse methods as their 
approach.  Examples of this are the Navy's RNTDS project and ICBM software.

\subsection{RNDTS}

The RNTDS project \cite{Aridis92}
has a very high degree of successful reuse and was   
implemented before methods were developed by such organizations as the
Software Engineering Institute (SEI) or the Software Technology for  
Adaptable, Reliable Systems (STARS) Project.  The project engineers were
faced with the reality of not enough resources to do their job and developed
a reusable software system as a result.                                    

\subsection{ICBM Software}

There were two significant cases of reuse in the ICBM:  The development of
Minuteman III from Minuteman II technology and the development of Peacekeeper
from Minuteman III technology.  This reuse was the result of critical       
national need where the luxury of re-developing software was not available.
No formal analysis of ICBM software reuse has occurred, but it is a fertile
field for determining methods and successes.                              

\subsection{STSC's Contribution}

The STSC has conducted a pilot program into a small, embedded system
\cite{STSC92,STSC93}.  The F-16 A/B Head-Up Display (HUD) 
software (and the supporting process) was      
analyzed from a reuse perspective.  It was found that some reuse occurred as
a natural result of engineers doing the best job they could.  Many         
opportunities for reuse were identified that were not currently being     
utilized, especially in non-code assets.  There is a process in place that
generally supports reuse, but a higher degree of emphasis would result in
measurable savings.                                                     

\subsection{Conclusions}

Reuse will occur if it must be done to meet external forces.   A formal,
repeatable process as defined by the major DoD reuse efforts does not have to
be present in order to have success.  The reuse-oriented organizations need 
to realize this and offer help to those that are currently not being noticed.
The types of software reuse described in this section has often been        
dismissed as ad hoc and thus not interesting.  Yet this type of reuse has had
and can continue to have a significant benefits on software cost in the DoD.

\subsection{Recommended modifications}

DoD reuse efforts should take smaller and embedded systems more seriously in
their research into software process improvement.  Much ground can be gained
by simply educating organizations involved in small and embedded systems in
the principles of reuse.  There needs to be an attitude change that these 
systems are not important or interesting enough to be considered when it 
comes to software reuse.                                                

\subsection{STSC Efforts}

Much was learned from the STSC's review of the F-16 A/B HUD software.  These
experiences can be extrapolated into other F-16 OFPs and other embedded    
systems.  The experience demonstrates that there are viable possibilities for
improving the software process with a reuse emphasis in small, embedded     
systems.                                                                   

The STSC has also produced a reuse methodology that can be applicable to any
sort of system, whether small, large, embedded or MIS.  This methodology   
takes into accounts the funding and resource limitations that may exist in
small projects and deals with concerns of existing embedded system projects. 


\section{Comparison}                                                                
The DoD efforts in software reuse have a tendency to support the concept that
reuse can only be successful in large projects with well-defined domains and
software processes.  This implies also that the projects must be well-financed
and visible.  The STSC contends that this unnecessarily leaves a significant 
portion of the DoD software community out of the reuse technology.                                                             
 
\bibliography{smith}



\section{Biography}

{\bf Larry W. Smith} is a Software Engineer at the Air Force Software 
Technology Support Center (STSC).  He is the Project Lead for Software Reuse.
Additionally, he works closely with other software technology domains to 
assist Air Force and DoD Software Development and Maintenance Activities
(SDSA) with software process improvement.  He received a Bachelors of Science 
in Electrical Engineering from the University of Utah, and is currently 
working towards a M.S. degree in Computer Science from Utah State University.
Vern Phipps is a Software Consultant with the Ogden, Utah SofTech Office.  He
is currently the Ogden Office Reuse Project Lead Engineer.  Mr. Phipps      
previously worked for TRW, Inc. where he supported the analysis and MODE 
maintenance of Minuteman and Peacekeeper software and performed nuclear 
safety analysis.  Previous to TRW, Mr. Phipps was employed by the National
Computer Security Center and was assigned as the NSA Liaison Officer for 
Computer Security for the I-S/A AMPE program at Gunter AFB, AL.  He received
a Bachelors of Science degree in Computer Science from Brigham Young       
University in 1983.                                                       
 
\end{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

