-------------------------------------------------------------------------------- SDE - Software Development Environment - version 97 - 28-APR-1989 -------------------------------------------------------------------------------- [Editor's note: The SDE.BCK file was compressed using LZW compress. Use LZW Decompress (LZDCMP.EXE) from [VAXLT_89A.TOOLS] to decompress the saveset.] Brief Description: ------------------ A software development methodology. Submitted by: ------------- Kevin Angley Memorex Telex 3301 Terminal Drive Raleigh, N.C. 27604 (919) 890-1416 Brief Abstract: -------------- DEC/CMS and DEC/MMS are useful tools for software development. But, they are only tools and do not constitute a procedure. At Memorex Telex, we saw the need to build a general model software development methodology that incorporates DEC/CMS and DEC/MMS. SDE - Software Development Environment - is the result. Built around VMS features (access control, logical names, DEC/CMS, and DEC/MMS), SDE provides an efficient, controlled process for software implementation. Our particular application is cross-development of microprocessor software, but SDE is flexible enough to work with virtually any set of software development tools (assemblers, compilers, linkers, etc.). We also find it useful for native VAX/VMS development. System Requirements: -------------------- The current version of SDE requires at least VMS 5.0 and CMS version 3.0 or better. At the moment, we are running SDE under VMS version 5.1 using CMS version 3.1 and MMS version 2.4. Much of SDE is written in PASCAL, but you won't need the compiler unless you plan to make some changes. SDE can be used either on a standalone system or in a cluster. Installation Instructions: -------------------------- Installation instructions can be obtained by using DSR (Runoff) to process SDE_INSTALLATION.RNO and printing the output file. Verbose Abstract: ----------------- The Memorex Telex Software Development Environment is a collection of tools built around DEC/CMS and DEC/MMS for the purpose of source, module, and configuration management. The formalization of the SDE is to insure efficient and timely progress in the circle of design, promote intraproject communication, provide necessary documentation standards, require a methodology in which the engineer works "smarter", implement effective source code control and configuration management, and secure the ability to maintain software after release. The SDE is built around several concepts. One such is the generalization that a FACILITY (assembler, compiler, etc.) is used to produce a TARGET from a SOURCE. The relationship of the target to the source is a DEPENDENCY. Another concept of the SDE is the manner in which the software engineers see the software components. In determining this, SDE introduces the concept of viewpoints. The SDE defines two working viewpoints: developer and integrator. The developer is an individual with an individual vision. He or she is concerned only with one module, one function, or one small atomic aspect of the overall system. There may be many of these functional areas for which he or she is responsible, but the viewpoint at a given point in time is that of a single module or subsystem. The integrator on the other hand is far-sighted. This individual's responsibility is for the whole software system and is concerned about how the pieces fit together. While not aware of the details of the individual modules, the integrator is cognizant of the ability of the functional pieces to interface together and perform as a system. The integrator gauges the overall functionality of the system and has the responsibility of declaring publicly (to the developers) that given levels of operation are available to support their individual development concerns. This gives rise to the concept of an integration level - a level of all the project's software that offers some degree of known functionality upon which individual developers may depend. Declared by the integrator, there may be many integration levels during the course of development (maybe hundreds). It is not important what the software can do at the various integration levels; what is important is that it does what it does correctly, or at least be dependable enough to support the developer's viewpoint. Integration levels are considered as a unit, complete and independent of other levels. There are integration levels which are declared or fixed by the integrator, meaning that no further changes can be made to this level. There may be many fixed levels in existence, the most recent level of which is called the latest or current level. Using the current integration level as a base, developers make contributions. The set of the most recent file versions for all components is called the contribution level. An easy corollary to the concept of the integration level is the release level. This is simply a given integration level with sufficient functionality and confidence level to warrant release as a production level. After the initial release, further functionality may be added and corrections made in a manner similar to the initial development cycle, with intervening integration levels until the next release level is produced. SDE controls access to projects with project identifiers, not UIC's. Thus, a developer may have vision rights to any number of projects, activated by the SDEVIEW command. Project logical names are kept in a shared project logical name table.