1、ECMA Technical Report TR/69December 1994Standardizing Information and Communication SystemsPhone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http:/www.ecma.ch - Internet: helpdeskecma.chReference Model for ProjectSupport Environments.ECMA Technical Report TR/69December 1994Standardizing Informa
2、tion and Communication SystemsPhone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http:/www.ecma.ch - Internet: helpdeskecma.chPC-5 - TR-069.DOC - 10.02.99 11:31Reference Model for ProjectSupport EnvironmentsThis report is also published as NIST Special Publication 500-213 by the NationalInstitut
3、e of Standards and Technology of the United States Department of Commerce.Brief HistoryThis Technical Report is complementary to the Reference Model for Frameworks of Software Engineering Environments,ECMA TR/55. The second and third editions of TR/55, published jointly by ECMA and NIST, were the pr
4、oduct of the jointworking groups ECMA TC33-TGRM (Task Group for the Reference Model) and NIST/ISEE (Integrated Software EngineeringEnvironment Working Group), and provided a basis for many other environment activities.One of these, the U.S. Navys Next Generation Computer Resources (NGCR) Project Sup
5、port Environment Standards WorkingGroup (PSESWG) had the goal of establishing standards for interfaces in the particular domain of project supportenvironments. As an initial step toward this goal, the working group produced this reference model for a project supportenvironment. As a point of departu
6、re, the PSESWG chose the ECMA/NIST Frameworks Reference Model, which is essentiallycontained as a subset of the PSE model. A brief precis of the Frameworks Reference Model, and its relation to the overall PSEmodel, is described in chapter 7 of this document.The working group that produced this model
7、 met as part of the NGCR program. In addition, however, the working group metjointly with both NIST/ISEE and ECMA TC33-TGRM, and members of both of those groups participated in its development.The third edition of ECMA TR/55 was expanded and modified to ensure that TR/55 and this Technical Report, E
8、CMA TR/69,are in harmony.This ECMA Technical Report has been adopted by the ECMA General Assembly of December 1994.- i -Table of contents1 Background 11.1 Project Support Environment Standards Working Group 11.2 Approach 11.3 Domain of Interest 11.4 Scope of the Model 21.5 Types of Project Support 2
9、2 Description of the Model 32.1 Key Concepts and Terms 32.2 The Reference Model 42.2.1 Description of End-User Services 62.2.2 Description of Framework Services 62.3 Discussion of the Model 62.3.1 Conceptual Models vs. Actual Environments 62.3.2 Rationale for the Groupings in the Model 72.3.3 Place
10、of the Target System in the Model 83 Notes on Reading the Service Descriptions 83.1 On the Relationships Dimension 93.2 On Other Aspects of PSE Services 94 Technical Engineering Services 94.1 System Engineering Services 104.1.1 System Requirements Engineering Service 104.1.2 System Design and Alloca
11、tion Service 114.1.3 System Simulation and Modeling Service 114.1.4 System Static Analysis Service 124.1.5 System Testing Service 134.1.6 System Integration Service 134.1.7 System Re-engineering Service 144.1.8 Host-Target Connection Service 144.1.9 Target Monitoring Service 154.1.10 Traceability Se
12、rvice 154.2 Software Engineering Services 164.2.1 Software Requirements Engineering Service 164.2.2 Software Design Service 164.2.3 Software Simulation and Modeling Service 174.2.4 Software Verification Service 184.2.5 Software Generation Service 194.2.6 Compilation Service 194.2.7 Software Static A
13、nalysis Service 20- ii -4.2.8 Debugging Service 204.2.9 Software Testing Service 214.2.10 Software Build Service 214.2.11 Software Reverse Engineering Service 224.2.12 Software Re-engineering Service 234.2.13 Software Traceability Service 234.3 Life-Cycle Process Engineering Services 244.3.1 Process
14、 Definition Service 244.3.2 Process Library Service 254.3.3 Process Exchange Service 254.3.4 Process Usage Service 255 Technical Management Services 265.1 Configuration Management Service 265.2 Change Management Service 275.3 Information Management Service 285.4 Reuse Management Service 285.5 Metric
15、s Service 296 Project Management Services 306.1 Planning Service 306.2 Estimation Service 316.3 Risk Analysis Service 326.4 Tracking Service 327 Support Services 337.1 Common Support Services 337.1.1 Text Processing Service 337.1.2 Numeric Processing Service 347.1.3 Figure Processing Service 357.1.4
16、 Audio and Video Processing Service 357.1.5 Calendar and Reminder Service 367.1.6 Annotation Service 367.2 Publishing Service 377.3 User Communication Services 397.3.1 Mail Service 397.3.2 Bulletin Board Service 397.3.3 Conferencing Service 407.4 PSE Administration Services 407.4.1 Tool Installation
17、 and Customization Service 407.4.2 PSE User and Role Management Service 417.4.3 PSE Resource Management Service 427.4.4 PSE Status Monitoring Service 427.4.5 PSE Diagnostic Service 427.4.6 PSE Interchange Service 43- iii -7.4.7 PSE User Access Service 437.4.8 PSE Instruction Service 448 Framework Se
18、rvices 448.1 Object Management Services 458.2 Process Management Services 478.3 Communication Service 478.4 Operating System Services 488.5 User Interface Services 488.6 Policy Enforcement Services 49Appendix A - Extended Definitions of Key Terms 51Appendix B - Common Project Activities and their Re
19、lation to Reference Model Services 55Appendix C - Rationale 59Appendix D - Abbreviations and Acronyms 63Appendix E - References 65Index 67- iv -.1 BackgroundThe U.S. Navy has embarked on the Next Generation Computer Resources (NGCR) program to fulfill its need forstandard computing resources. The pr
20、ogram revolves around the selection of interface standards in six areas. Theinterface standards will be based on existing industry standards with multi-vendor support. The objective is torestructure the Navys approach to take better advantage of commercial advances and to reduce cost and duplication
21、 ofcomputer resources. This document is part of the NGCR program.1.1 Project Support Environment Standards Working GroupOne of the areas chosen by NGCR for interface standardization is that of project support environments (PSEs). Theinitial focus for the PSE Standards Working Group (PSESWG) is to id
22、entify areas in support environments that arein need of standardization and for which industry accepted standards may be available within the NGCRstimeframe. The primary goal of the PSESWG is to provide an interface standard that can be used by projectmanagers as an aid in procuring or assembling a
23、Project Support Environment (PSE) for a particular project ororganization. This standard will itself consist of several interface standards that have been chosen for theircompatibility and consistency and their ability to support a wide range of project support environment needs. Thisstandard will u
24、se industry standards where possible, promoting use of commercial off-the-shelf (COTS) andgovernment off-the-shelf (GOTS) products.The first step towards this goal for PSESWG is the establishment of a reference model that describes the full scopeof functionality that is expected of a PSE. This refer
25、ence model will provide the basis for: Determination of and examination of interfaces for which standards might be included in the final PSESWGstandard. Identification of requirements for interfaces which might be beneficial to standardize but for which no industrystandardization activity can be ide
26、ntified. Consensus throughout the environments community.While there are several other reference model activities that are relevant to this goal, none individually has the scopethat is required nor provides a definition of the concepts at a suitable level of abstraction. Thus the reference modelpres
27、ented in this document is new, although it builds on those other reference models. The PSESWG activity isbeing coordinated with those other activities whenever possible.1.2 ApproachPrior to developing this reference model, a large collection of existing environment efforts and models wasinspected. T
28、his included (but was not limited to) the Software Technology for Adaptable, Reliable Systems(STARS) program, the National Institute of Standards and Technology (NIST) Integrated Software EngineeringEnvironment (ISEE) working group, the European Computer Manufacturers Association (ECMA) TC33 TaskGro
29、up on the Reference Model, the Ada Joint Program Office Evaluation and Validation Team, the Air ForceSoftware Life Cycle Support Environment (SLCSE) project, Honeywells Engineering Information Systems (EIS)program, the Conceptual Environment Architecture Reference Model (CEARM) effort, and the stand
30、ardizationcommittees within IEEE and ANSI for POSIX and for CASE Tool Integration Models (CTIM). The products ofthose efforts have been analyzed and many valuable aspects have been combined and abstracted.1.3 Domain of InterestThe approach of this model is most directly comparable to the approach ev
31、idenced in the POSIX Open SystemsEnvironment and the NIST/ECMA Reference Model for Frameworks of Software Engineering Environments.However, while both of these have a similar approach, they have different domains of interest. For POSIX thatdomain is Open Systems Environments1, and for the NIST/ECMA
32、reference model it is the domain of PSEframeworks that support software engineering. The domain of the PSESWG reference model encompasses both thePOSIX and NIST/ECMA domains. Because their approaches are so similar, PSESWG has made direct use of bothmodels as components of our reference model. This
33、approach led to the realization that since both efforts developedrelatively independently of each other, there are numerous small (but at times critical) inconsistencies between them1Note that this use of the term environment is quite different from the sense in which it is used in the phrase softwa
34、re engineeringenvironment.- 2 -that must be addressed. Members of NGCR PSESWG have been active in helping the two communities to resolvethese inconsistencies.The domain of the PSESWG reference model also encompasses domains of interest that are not addressed in thework of either POSIX or NIST ISEE.
35、Numerous specifications and technical reports, describing actual or proposedproducts, tools and standards, were examined. While some of these provided valuable ideas for the writing of thisdocument, PSESWGs need for greater breadth and scope required the development of a different model for acomplet
36、e, populated PSE. Thus the majority of the ideas presented in this model are original and are not derivedfrom any earlier efforts.Finally, the approach is explicitly aimed at establishing a conceptual basis for an environment, not at standardizingany particular environment product; our model must be
37、 viewed in this light. This approach is in contrast to manycurrent users of a given environment who, if confronted with the question What is your environment like?, wouldreply by listing the available tools. The basic premise of the NGCR program is to standardize on interfaces ratherthan products. T
38、hus, while tools can help to understand the interfaces on which they depend, they are not central tothis reference model, and there is no part of the intended results of the PSESWG activities that involves choosing astandard toolset.1.4 Scope of the ModelThe purpose of the reference model is to desc
39、ribe environments that support projects that engineer, develop andmaintain computer-based systems. There are many varieties of such projects. They can comprise the work of severaldozens of people or can be a solitary effort. They can be geographically dispersed or concentrated. They also can beinsti
40、tutionally dispersed, sharing people and facilities of several organizations, or concentrated within a singleorganization. Projects can have widely divergent degrees of automated support. Lastly, the nature of projects may beessentially exploratory, developmental, or maintenance, or may encompass al
41、l of these. Yet common to projects ofinterest to PSESWG is a set of important characteristics: Their province is the exploration, engineering, development, or enhancement of a computer-based system. They require some mature form of management. There is computer-based support for the project. There i
42、s computer-based support for communication during the projects execution. There are several stages within the life of the project, often encompassing various engineering activities.These characteristics do not uniquely apply to software engineering projects, but include projects involvinghardware an
43、d firmware, systems engineering, etc. These characteristics are also not peculiar to Navy or to DoDprojects, but are typical of engineering projects in general.Although a project support environment can be either automated or manual, the scope of this reference model is acomputer-based support envir
44、onment. This scope can be further articulated by distinguishing between differentaspects of the automation. For instance, various project support capabilities alluded to above can be provided onPCs, on workstations, on mainframe computers, or on networks involving these. The scope of this reference
45、modelencompasses all these. To the greatest extent possible the concentration has been on capabilities that are common toall, not applicable to only one.1.5 Types of Project SupportProjects require many types of support. Examination of the processes that projects use provides importantinformation on
46、 the PSE support that may be required. The functions of projects that can be supported by PSEs canbe grouped within four major categories: technical engineering functions (e.g., system design, simulation) technical management functions (e.g., reuse management, configuration management) project manag
47、ement functions (e.g., resource scheduling, project tracking) support functions (e.g., editing, maintenance of the support facility)- 3 -While details about these categories might be debated2, there is probable agreement that they represent the types ofsupport functions that projects may require. An
48、d given the extent and complexity of this area, it is probablyimpossible to find any set of categories that will find universal agreement. The Working Group has therefore chosena set of categories that will be most useful as a means toward its principal goal, namely, selecting interface areas forsta
49、ndardization.2 Description of the ModelThis chapter first establishes the basic premise of the reference model, then describes the model itself, and lastlydiscusses several concepts central to an understanding of it.The reference model is a conceptual description of the functionality provided by a project support environment. Thisdescription is general and is bounded neither by a particular application domain nor by any specific lifecycle paradigmfor a development project. This is in contrast to an actual implemented environment that is constructed of partic
