Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwm.edu!bionet!apple!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!rsd From: rsd@sei.cmu.edu (Richard S D'Ippolito) Newsgroups: comp.software-eng Subject: Re: Information Systems is an Engineering Discipline Message-ID: <4330@ae.sei.cmu.edu> Date: 4 Oct 89 21:41:38 GMT References: <1142@svx.SV.DG.COM> <34399@regenmeister.uucp> <5296@eos.UUCP> Reply-To: rsd@sei.cmu.edu (Richard S D'Ippolito) Distribution: comp.edu Organization: Software Engineering Institute, Pittsburgh, PA Lines: 142 This discussion began with an article by Bill Wolfe highlighting a September CACM letter by Philip Lewis of SUNY. My only comment on the letter itself is that there is no reason to limit the application of engineering software to information systems -- all software systems should be truly engineered. The discussion has strayed into the typical dead-end concerns of who should manage software and how it should be managed, instead of properly focusing on how it should be engineered. Ed Prochak has brought the discussion back to the real issue. Ed writes in article : > We need a rule for scaling software so that we can test > small, cheap models of the software system. I think this is what > top-down design, structured design and object oriented design all are > striving for. We need to be able to build the model based on the > design, test it, if it doesn't work throw it away, if it does work then > build the real thing. > The problem has been that we don't build models. > There has been proposals that we build prototypes instead. > This may be okay as long as the prototype never leaves the > development lab. Prototypes have to be treated as throw-aways, > especially when they work! > My personal opinion is that prototypes are not good enough, > and that models of software systems are possible. What the techniques > will be, I don't know. I agree that verbal descriptions cannot be good > enough. Pictures are better (data flow diagrams and the like) but they > aren't models, they can't be easily tested. There must be something > we can use. Suggestions? Opinions? Ed, we (Richard D'Ippolito, Kenneth Lee, Charles Plinta, Michael Rissman, Roger Van Scoy, and Jeffrey Stewart) have spent over three years here doing exactly what you suggest. Last spring I posted an article describing our efforts and successes with engineering modeling of software. I have updated the article to reflect more recent publications and conferences and have reposted it below. In article <1014@afit-ab.arpa> William A. Bralick writes: >It seems to me that architecture (as in buildings, not computer systems :-) >should provide a useful set of lessons for software engineers. The parallels >between software engineering and architecture (especially for a large, unique >building) are striking -- both are labor intensive, lengthy, expensive, >prone to schedule slippages and cost overruns, require not only a sound >design but also good management practices, both can benefit from standardized >parts, etc. Has any formal attempt been made to draw on (this pun >is intentionally left blank) architecture as a model for solving some >of the problems in software engineering? I am currently the project leader of a group here at the SEI called Software Architectures Engineering. Our primary focus for the last three years has been to apply traditional engineering practices and techniques to the development of software. Most notable among these techniques is the practice of modeling. I have found building design (architectural engineering) to be a particularly fruitful source of examples, parallels, and metaphors when describing the uses and value of software models. We have been able to show improvements in the software design process in several large-scale Ada projects by developing and applying engineering models. These models are just what you'd think they are -- architectural components representing solutions to the recurring patterns encountered in the various domains. As modeled solutions, they have known performance characteristics and structural style, and can be applied with other models of the same style to create the system architecture. In effect, one obtains reuse at the design level, as opposed to the component level. For example, in the flight-simulator domain, we developed a model (Object Connection and Update, or OCU) for connecting and updating the objects that comprise a system[1,2]. This model was used as the architectural base for the electrical and engine systems within the simulator. It has been successfully used on other flight simulator systems (C-17, MV-22, UH-1 and others), and is being considered as the model to be used in a tri-service agreement to train engineers, acquisition agents, and program managers in simulator development issues. In the C3I domain, we have produced a model for translating and validating incoming messages[3]. This model, the MTV (Message Translator and Validator), is being used on one large-scale project and is being considered for another. Preliminary reports by the customer indicate that by using the MTV model, they have achieved over a two-fold increase in productivity and an order of magnitude reduction in errors. Additionally, we are developing models for Ada real-time embedded systems and are presenting general papers on the uses of models for software development. One, in particular, that I have already presented discusses the models using examples from building architecture[4]. Another will be presented at the upcoming Tri-Ada conference here in Pittsburgh. So, to summarize an answer to Mr. Bralick's question, yes, we have made formal attempts to introduce the design practices of architects and other engineers to software development, and have already achieved successes. We invite you to come to the Tri-Ada conference to hear the following reports: Using Models in Software Engineering. Richard D'Ippolito, SEI. A Model Solution for the C3I Domain. Charles Plinta, Ken Lee, SEI. The Software Life-cycle With Ada: A Command & Control Application. Major Mike Goyden, USAF. Millimeter Wave Ada Shadow Program. Steven Pate, Hercules Defense Electronics, Inc. The first presentation is a general discussion of the models and techniques we used to create them. The second is a discussion in detail of the MTV model. The third, presented by the manager of the project that used the MTV model, gives the customer's experience with it. The fourth is a presentation by a customer who successfully used the OCU model, originally developed to solve the synchronizing and updating problems in flight simulators, to structure the executive in a missile seeker. If you can not make it to the conference, you can obtain these papers in the proceedings. Richard S. D'Ippolito rsd@sei.cmu.edu 412/268-6752 [1] An OOD Paradigm for Flight Simulators, 2nd ed. CMU/SEI-88-TR-30. [2] An Object-Oriented Solution Example: A Flight Simulator Electrical System Example. CMU/SEI-89-TR-5. [3] A Model Solution for C3I Message Translation and Validation. CMU/SEI-89-TR-12. Due November, 1989. [4] Software Development Using Models. International Workshop on Software Specification and Design, Pittsburgh, May, 1989. -- It is not the possible that determines what to hope for -- it is hope that determines what is possible. Richard J. Oman rsd@sei.cmu.edu -----------------------------------------------------------------------------