Use System-Based Software Design

Software and software development have received a great deal of attention within both industry and the Department of Defense during the last decade. This attention has mostly been the result of failure-the inability of developers to consistently deliver software products on- time and within budget. With the focus on software, it is easy to ignore the system, the larger context in which software fits.

Software in isolation provides no benefit; similarly, hardware alone is useless, except possibly as a paperweight. However, together they form a powerful team, but this tandem relationship is not sufficient. The Joint Command and Control Staff Officers Course defines a system as an integrated unit made up of people, procedures, facilities, and equipment. While the hardware/software tandem relationship fits the "equipment" part of this definition, the remaining elements are just as important. Unless all components of a system are integrated in an effective manner, the system will likely fail to accomplish its mission.

As a result, effective software design starts on a higher plane-at the systems level. It is at this level that the interaction of the system with its environment is defined, and the interaction of each of the system components is delineated. One of these elements is software. This context is extremely important and must be ever present during the software development process. Poor systems engineering creates much more risk in software development than is necessary.

For this reason planning for software activities should begin at the same time as system planning activities.  The CM process should be exploited to keep these parallel efforts consistent.  This coordinated planning activity should continue throughout the project life.  As part of the coordinated planning a software lifecycle that supports the system objective and schedule will be agreed to and documented.  Planning should include direct and support activities (e.g. SQA).  All plans should be reviewed and agreed to by all participants and impacted parties.

Systems development is inevitably an iterative process. As each of the interacting system elements are implemented, shortfalls may occur in functionality. However, if the system is to be effective, the impact on other elements must be constantly assessed to accommodate implementation realities.

The process of breaking a system into smaller, interacting components is called partitioning. In this process, components are defined, their functionality identified, and interfaces delineated. The description of the components, their responsibilities, and their interaction is called the system architecture. The system architecture is the highest level partitioning of the system. It is during the process of partitioning that each system requirement is addressed, decisions are made on how the components will work together to satisfy the requirement, and responsibilities of individual components are developed. The system and software architectures should be developed from the same partitioning perspective to minimize the complexity of requirements allocation/traceability. For example, system architecture based on a functional composition should not have an object-oriented (OO) software architecture.

Selection of system and software architecture design methods needs to be made independent of any automated tool. Adapting design methods to an automated tool usually results in an unsatisfactory product and a frustrated, dissatisfied work force.

top

---