The impact of software architecture reuse on development processes and standards

Abstract We have developed an architecture for distributed simulations with reuse in mind from the start. During the past six years, two teams on five projects at US Army Tank-Automotive and Armaments Command (TACOM) have used it. We found that in order to reuse the architecture, it was not only necessary to design it for reuse but also to develop and provide associated development processes and standards for reuse. Not only its functionality for the task to be performed, but also its resultant impact on the software development process determine acceptance of an architecture for reuse. Software reuse is similar to both software tool assessment/technology transfer and requirements analysis in that in all three cases one needs to assess not only product functionality but also its resultant impact on the way that the users of the product work. The DoD is now mandating the use of the High Level Architecture Standard (HLA) for distributed military simulations. Because of our experience in architecture reuse, we realize that HLA adoption will impact not only our product, but also the way we work. In addition to examining HLA functionality, we are assessing HLA's impact on our existing development processes and standards.

[1]  F. A. Cioch,et al.  Using the spiral model to assess, select and integrate software development tools , 1994, Proceedings of 3rd Symposium on Assessments of Quality Software Development Tools.

[2]  Karen Holtzblatt,et al.  Making customer-centered design work for teams , 1993, CACM.

[3]  Stephen J. Andriole.  Storyboard prototyping: a new approach to user requirements analysis , 1989 .

[4]  Douglas C. Schmidt,et al.  Lessons learned building reusable OO frameworks for distributed software , 1997, CACM.

[5]  Alan M. Davis,et al.  Operational prototyping: a new development approach , 1992, IEEE Software.

[6]  Karen Holtzblatt,et al.  Apprenticing with the customer , 1995, CACM.

[7]  Effy Oz,et al.  When professional standards are lax: the CONFIRM failure and its lessons , 1994, CACM.

[8]  D. Leonard-Barton,et al.  Implementation as mutual adaptation of technology and organization , 1988 .

[9]  Ivar Jacobson,et al.  Making the Reuse Business Work , 1997, Computer.

[10]  Luqi,et al.  Status report: computer-aided prototyping , 1992, IEEE Software.

[11]  Ali Mili,et al.  Reusing Software: Issues and Research Directions , 1995, IEEE Trans. Software Eng..

[12]  John M. Carroll,et al.  Making use: a design representation , 1994, CACM.

[13]  Ivar Jacobson,et al.  Object-Oriented Software Engineering , 1991, TOOLS.

[14]  David Garlan,et al.  Architectural Mismatch: Why Reuse Is So Hard , 1995, IEEE Softw..

[15]  Kevin Benner,et al.  Managing Object-Oriented Framework Reuse , 1996, Computer.

[16]  David G. Novick,et al.  Participatory conversation in PD , 1993, CACM.

[17]  Alan C. Gillies,et al.  Managing Software Engineering , 1994 .

[18]  D. Conner,et al.  Building commitment to organizational change. , 1982 .

[19]  Watts S. Humphrey,et al.  CASE planning and the software process , 1991, J. Syst. Integr..

[20]  Will Tracz,et al.  DSSA (Domain-Specific Software Architecture): pedagogical example , 1995, SOEN.

[21]  Gerhard Fischer,et al.  Cognitive View of Reuse and Redesign , 1987, IEEE Software.

[22]  Barry W. Boehm,et al.  A spiral model of software development and enhancement , 1986, Computer.

[23]  Peter Smith,et al.  Managing Software Engineering: Case Studies And Solutions , 1994 .

[24]  Frank A. Cioch,et al.  A documentation suite for maintenance programmers , 1996, 1996 Proceedings of International Conference on Software Maintenance.