Figure 9: Peaks Cost Model Editor

this paper to provide the reader with some examples of how the process definition prepared for a project could be leveraged to support a number of important project planning, acquisition, and performance activities. To date we have practical field experience in process definition and process-driven project planning. We have positioned ourselves on the STARS program, through the efforts of the Loral STARS Team and Cedar Creek Process Engineering, to test all the concepts described in this paper on future projects at the U.S. Army's Picatinny Arsenal and on the Air Force/STARS Demonstration Project (SCAI Project) in Colorado Springs, Colorado. Our plans are to do just that, as well as to transition our process management concepts and technology into business units of Loral Federal Systems. From our work we have concluded that process-driven project planning can and does work and can become a driving force in the planning of projects that wish to employ the concepts of megaprogramming. Further, we have concluded that "quality" must be built into our process definitions, along with the activities required to support it, so that those activities will appear in our project plans, and thus ensure that both government and contractor personnel understand: 1) the process by which a product will be created; 2) the evaluation characteristics by which those products will be assessed; and 3) the project plan that addresses how the above will be satisfied. Our ultimate hope is that organizations will recognize that the project plan and the process definition from which it was derived can be leveraged to develop quality software within a plan that all parties understand and believe. ______________________________________________________________________________________ April 10, 1995 ..

Using UML Collaboration Diagrams for Static Checking and Test Generation

Software testing can only be formalized and quantified when a solid basis for test generation can be defined. Tests are commonly generated from program source code, graphical models of software (such as control flow graphs), and specifications/requirements. UML collaboration diagrams represent a significant opportunity for testing because they precisely describe how the functions the software provides are connected in a form that can be easily manipulated by automated means. This paper presents novel test criteria that are based on UML collaboration diagrams. The most novel aspect of this is that tests can be generated automatically from the software design, rather than the code or the specifications. Criteria are defined for both static and dynamic testing of specification-level and instance-level collaboration diagrams. These criteria allow a formal integration tests to be based on high level design notations, which can help lead to software that is significantly more reliable.