figure 1.doc

RFP: Software Process Engineering (SPE) Management ad/99-11-04

Object Management Group

Framingham Corporate Center492 Old Connecticut Path

Framingham, MA 01701-4568

Telephone: +1-508-820 4300Facsimile: +1-508-820 4303

Software Process Engineering (SPE) Management

Request for Proposal

(AD PTF RFP)OMG Document: ad/99-11-04

Submissions due: May 12, 2000

Objective of this RFP

This RFP solicits proposals for specifications of a Software Process Engineering (SPE) metamodel or UML Profile for SPE, with the longer-term aim of providing interoperability and repository facilities in the software process-engineering field. For further details see Chapter 6 of this document.

1.0

AD PTF RFP November 18, 1999 1


1.0 Introduction

1.1 Goals of OMG

The Object Management Group (OMG) is the world's largest software consortium with a membership of over 800 vendors, developers, and end users. Established in 1989, its mission is to promote the theory and practice of Object Technology (OT) for the development of distributed computing systems.

A key goal of OMG is to create a standardized object-oriented architectural framework for distributed applications based on specifications that enable and support distributed objects. Objectives include the reusability, portability, and interoperability of object-oriented software components in heterogeneous environments. To this end, the OMG adopts interface and protocol specifications, based on commercially available object technology, that together define an Object Management Architecture (OMA).

1.2 Organization of this document

The remainder of this document is organized as follows:

Chapter 2 - Architectural Context - background information on OMG’s Object Management Architecture.

Chapter 3 - Adoption Process - background information on the OMG specification adoption process.

Chapter 4 - Instructions for Submitters - explanation of how to make a submission to this RFP.

Chapter 5 - General Requirements on Proposals - requirements and evaluation criteria that apply to all proposals submitted to OMG.

Chapter 6 - Specific Requirements on Proposals - problem statement, scope of proposals sought, mandatory and optional requirements, issues to be discussed, evaluation criteria, and timetable that apply specifically to this RFP.

Additional RFP-specific chapters may also be included following Chapter 6.



1.3 References

The following documents are referenced in this document:

Richard Soley (ed.), Object Management Architecture Guide, Third Edition, Wiley, June 1995. OMG Document ab/97-05-05, or successor.

The Common Object Request Broker: Architecture and Specification, Revision 2.1, August 1997. OMG Document formal/97-09-01, or successor.

CORBAservices: Common Object Services Specification, Revised Edition, July 1997. OMG Document formal/97-07-04, or successor.

CORBAfacilities Architecture, Revision 4.0, November 1995.

Business Committee RFP Attachment, OMG Document omg/97-10-01.

Policies and Procedures of the OMG Technical Process, OMG Document pp/97-06-01 or successor.

These documents can be obtained by contacting OMG at [email protected]. Many OMG documents, including this document, are available electronically from OMG’s document server. Send a message containing the single line “help” to [email protected] for more information, or visit the OMG Web page (URL http://www.omg.org/), which also has more information about OMG in general. If you have general questions about this RFP send email to [email protected].



2.0 Architectural Context

2.1 Object Management Architecture

The Object Management Architecture Guide (OMAG) describes OMG’s technical objectives and terminology and provides the conceptual infrastructure upon which supporting specifications are based. The guide includes the OMG Object Model, which defines common semantics for specifying the externally visible characteristics of objects in a standard implementation-independent way, and the OMA Reference Model.

The Reference Model identifies and characterizes the components, interfaces, and protocols that compose the OMA. This includes the Object Request Broker (ORB) component that enables clients and objects to communicate in a distributed environment, and four categories of object interfaces:

• Object Services are interfaces for general services that are likely to be used in any program based on distributed objects.

• Common Facilities are interfaces for horizontal end-user-oriented facilities applicable to most application domains.

• Domain Interfaces are application domain-specific interfaces.

• Application Interfaces are non-standardized application-specific interfaces.

A second part of the Reference Model introduces the notion of domain-specific Object Frameworks. An Object Framework component is a collection of cooperating objects that provide an integrated solution within an application or technology domain and which is intended for customization by the developer or user.

Through a series of RFPs, OMG is populating the OMA with detailed specifications for each component and interface category in the Reference Model. Adopted specifications include the Common Object Request Broker Architecture (CORBA), CORBAservices, and CORBAfacilities.

The wide-scale industry adoption of OMG's OMA provides application developers and users with the means to build interoperable software systems distributed across all major



hardware, operating system, and programming language environments.

2.2 CORBA

The Common Object Request Broker Architecture defines the programming interfaces to the OMA ORB component. An ORB is the basic mechanism by which objects transparently make requests to - and receive responses from - each other on the same machine or across a network. A client need not be aware of the mechanisms used to communicate with or activate an object, how the object is implemented, nor where the object is located. The ORB thus forms the foundation for building applications constructed from distributed objects and for interoperability between applications in both homogeneous and heterogeneous environments.

The OMG Interface Definition Language (IDL) provides a standardized way to define the interfaces to CORBA objects. The IDL definition is the contract between the implementor of an object and the client. IDL is a strongly typed declarative language that is programming language-independent. Language mappings enable objects to be implemented and sent requests in the developer's programming language of choice in a style that is natural to that language.

CORBA 2.0 is an extension and restructuring of the earlier CORBA 1.2 specification. CORBA 2.0 is a family of specifications consisting of the following components:

• Core (including IDL syntax and semantics)

• Interoperability

• An expanding set of language mappings, including:

CC++SmallTalkAda95COBOL

Each component is a separate compliance point. The minimum required for a CORBA-compliant implementation is adherence to the core and one language mapping.



2.3 CORBA/Interoperability

Interoperability between CORBA-compliant ORBs is provided by OMG's Internet Inter-ORB Protocol (IIOP). Adopted in December 1994 as the mandatory CORBA 2.0 protocol for “out of the box” interoperability, IIOP is the TCP/IP transport mapping of a General Inter-ORB Protocol (GIOP). IIOP enables requests to be sent to networked objects managed by other ORBs in other domains.

The OMG interoperability architecture also accommodates communication using optional Environment-Specific IOPs (ESIOPs), the first of which is the DCE-CIOP.

2.4 CORBAservices

Object Services are general purpose services that are either fundamental for developing useful CORBA-based applications composed of distributed objects, or that provide a universal - application domain-independent - basis for application interoperability.

Object Services are the basic building blocks for distributed object applications. Compliant objects can be combined in many different ways and put to many different uses in applications. They can be used to construct higher level facilities and object frameworks that can interoperate across multiple platform environments.

Adopted OMG Object Services are collectively called CORBAservices and include Naming, Events, LifeCycle, Persistent Object, Relationships, Externalization, Transactions, Concurrency Control, Licensing, Query, Properties, Security, Time, Collections, and Trading Services.

2.5 CORBAfacilities

Common Facilities are interfaces for horizontal end-user-oriented facilities applicable to most domains. Adopted OMG Common Facilities are collectively called CORBAfacilities and include an OpenDoc-based Distributed Document Component Facility.

A specification of a Common Facility or Object Service typically includes the set of interface definitions - expressed in OMG



IDL - that objects in various roles must support in order to provide, use, or participate in the facility or service. As with all specifications adopted by OMG, facilities and services are defined in terms of interfaces and their semantics, and not a particular implementation.

2.6 Object Frameworks and Domain Interfaces

Unlike the interfaces to individual parts of the OMA “plumbing” infrastructure, Object Frameworks are complete higher level components that provide functionality of direct interest to end-users in particular application or technology domains. They are vertical slices down the OMG “interface stack”.

Object Frameworks are collections of cooperating objects categorized into Application, Domain, Facility, and Service Objects. Each object in a framework supports (through interface inheritance) or makes use of (via client requests) some combination of Application, Domain, CORBAfacilities, and CORBAservices interfaces.

A specification of an Object Framework defines such things as the structure, interfaces, types, operation sequencing, and qualities of service of the objects that make up the framework. This includes requirements on implementations in order to guarantee application portability and interoperability across different platforms.

Domain Task Force RFPs are likely to focus on Object Framework specifications that include new Domain Interfaces for application domains such as Finance, Healthcare, Manufacturing, Telecom, Electronic Commerce, and Transportation.



3.0 Adoption Process

3.1 Introduction

OMG adopts specifications for interfaces and protocols by explicit vote on a technology-by-technology basis. The specifications selected each fill in a portion of the OMA Reference Model. OMG bases its decisions on both business and technical considerations. Once a specification is adopted by OMG, it is made available for use by both OMG members and non-members.

For more detailed information on the adoption process see the Policies and Procedures of the OMG Technical Process.

3.2 Role of Board of Directors

The OMG Board of Directors votes to formally adopt specifications on behalf of OMG. The OMG Technology Committees (Domain and Platform TCs) and Architecture Board (AB) provide technical guidance to the Board of Directors. In addition, the Business Committee of the Board provides guidance to ensure that implementations of adopted specifications are made commercially available.

3.3 Role of Technology Committees and Architecture Board

Submissions to RFPs are evaluated by the TC Task Force (TF) that initiated the RFP. Selected specifications are recommended to the parent TC after being reviewed by the Architecture Board for consistency with the OMA. The full TC then votes to recommend adoption to the OMG Board.

3.4 Role of Task Forces

The role of the initiating TF is to technically evaluate submissions and select one or more specifications that satisfy the requirements of the RFP. The process typically takes the following form:

• Voter Registration

Interested TF members may register to participate in specification selection votes for an RFP. Registration ends



on a specified date 6 or more weeks after the announcement of the registration period. The registration closure date is typically around the time of initial submissions. Companies who have submitted an LOI are automatically registered to vote.

• Initial Submissions

Initial submissions are due by a specified deadline. Submitters normally present their proposals at the next following meeting of the TF. Initial submissions are expected to be full and complete proposals and working implementations of the proposed specifications are expected to exist at the time of submission.

• Evaluation Phase

A period of approximately 120 days follows during which the TF evaluates the submissions. During this time submitting companies have the opportunity to revise and/or merge their initial submissions, if they so choose.

• Revised Submissions

Final revised submissions are due by a specified deadline. Submitters again normally present their proposals at the next following meeting of the TF. Finalists may be requested to demonstrate implementations of their proposal.

• Selection Vote

When the registered voters of the TF believe that they sufficiently understand the relative merits of the revised submissions, a specification selection vote is taken.

3.5 Goals of the evaluation

The primary goals of the TF evaluation process are to:

• Provide a fair and open process

• Force a critical review of the submissions and discussion by all members of the TF

• Give feedback to allow submitters to address concerns in their revised submissions

• Build consensus on acceptable solutions



• Enable voting members to make an informed selection decision

Submitters are expected actively to contribute to the evaluation process.

4.0 Instructions for Submitters

4.1 OMG Membership

Submissions to this RFP may only be made by Contributing or Domain Contributing members of the OMG. To submit to an RFP issued by the Platform Technology Committee an organisation must be a Contributing member at the date of the submission deadline, while for Domain Technology RFPs the submitter or submitters must be either Contributing or Domain Contributing members. Submitters sometimes choose to name other organisations that support a submission in some way; however, this has no formal status within the OMG process, and for OMG’s purposes confers neither duties nor privileges on the organisations concerned.

4.2 Submission Effort

Unlike a submission to an OMG Request For Information (RFI), an RFP submission may require significant effort in terms of document preparation, presentations to the initiating TF, and participation in the TF evaluation process. Several staff months of effort might be necessary. OMG is unable to reimburse submitters for any costs in conjunction with their submissions to this RFP.

4.3 Letter of Intent

A Letter of Intent (LOI) must be submitted to the OMG Business Committee signed by an officer of your organization signifying your intent to respond to the RFP and confirming your organization’s willingness to comply with OMG’s terms and conditions, and commercial availability requirements. These terms, conditions, and requirements are defined in the Business Committee RFP Attachment and are reproduced verbatim in section 4.4 below.

The LOI should designate a single contact point within your organization for receipt of all subsequent information



regarding this RFP and your submission. The name of this contact will be made available to all OMG members. The LOI is typically due 60 days before the deadline for initial submissions. LOIs must be sent by fax or paper mail to the “RFP Submissions Desk” at the main OMG address shown on the first page of this RFP.

Here is a suggested template for the Letter of Intent:

This letter confirms the intent of <___organisation required___> (the organisation) to submit a response to the OMG <___RFP name required___> RFP. We will grant OMG and its members the right to copy our response for review purposes as specified in section 4.7 of the RFP. Should our response be adopted by OMG we will comply with the OMG Business Committee terms set out in section 4.4 of the RFP and in document omg/98-03-01.

<____contact name and details required____> will be responsible for liaison with OMG regarding this RFP response.

The signatory below is an officer of the organisation and has the approval and authority to make this commitment on behalf of the organisation.

<___signature required____>

4.4 Business Committee RFP Attachment

This section contains the text of the Business Committee RFP attachment concerning commercial availability requirements placed on submissions. This attachment, available separately as document omg/98-03-01, was approved by the OMG Board in February 1998.

__________________________________________

Commercial considerations in OMG technology adoption

A1 Introduction

OMG wishes to encourage rapid commercial adoption of the specifications it publishes. To this end, there must be neither technical, legal nor commercial obstacles to their implementation. Freedom from the first is largely judged



through technical review by the relevant OMG Technology Committee; the second two are the responsibility of the OMG Business Committee. The BC also looks for evidence of a commitment by a submitter to the commercial success of products based on the submission.

A2 Business Committee evaluation criteria

A2.1 Viable to implement across platforms

While it is understood that final candidate OMG submissions often combine technologies before they have all been implemented in one system, the Business Committee nevertheless wishes to see evidence that each major feature has been implemented, preferably more than once, and by separate organisations. Pre-product implementations are acceptable. Since use of OMG specifications should not be dependant on any one platform, cross-platform availability and interoperability of implementations should be also be demonstrated.

A2.2 Commercial availability

In addition to demonstrating the existence of implementations of the specification, the submitter must also show that products based on the specification are commercially available, or will be within 12 months of the date when the specification was recommended for adoption by the appropriate Task Force. Proof of intent to ship product within 12 months might include:

• A public product announcement with a shipping date within the time limit.

• Demonstration of a prototype implementation and accompanying draft user documentation.

Alternatively, and at the Business Committee's discretion, submissions may be adopted where the submitter is not a commercial software provider, and therefore will not make implementations commercially available. However, in this case the BC will require concrete evidence of two or more independent implementations of the specification being used by end-user organisations as part of their businesses.



Regardless of which requirement is in use, the submitter must inform the OMG of completion of the implementations when commercially available.

A2.3 Access to Intellectual Property Rights

OMG will not adopt a specification if OMG is aware of any submitter, member or third party which holds a patent, copyright or other intellectual property right (collectively referred to in this policy statement as "IPR") which might be infringed by implementation of such specification, unless OMG believes that such IPR owner will grant a license to implementers (whether OMG members or not) on non-discriminatory and commercially reasonable terms which wish to implement the specification. Accordingly, the submitter must certify that it is not aware of any claim that the specification infringes any IPR of a third party or that it is aware and believes that an appropriate non-discriminatory license is available from that third party. Except for this certification, the submitter will not be required to make any other warranty, and specifications will be offered by OMG for implementation "as is". If the submitter owns IPR to which an implementation of a specification based upon its submission would necessarily be subject, it must certify to the Business Committee that it will make a suitable license available to any implementer on non-discriminatory and commercially reasonable terms, to permit development and commercialisation of an implementation that includes such IPR.

It is the goal of the OMG to make all of its specifications available with as few impediments and disincentives to adoption as possible, and therefore OMG strongly encourages the submission of technology as to which royalty-free licenses will be available. However, in all events, the submitter shall also certify that any necessary license will be made available on commercially reasonable, non-discriminatory terms. The submitter is responsible for disclosing in detail all known restrictions, placed either by the submitter or, if known, others, on technology necessary for implementation of the specification.



A2.4 Publication of the specification

Should the submission be adopted, the submitter must grant OMG (and its sublicensees) a world-wide, royalty-free licence to edit, store, duplicate and distribute both the specification and works derived from it (such as revisions and teaching materials). This requirement applies only to the written specification, not to any implementation of it.

A2.5 Continuing support

The submitter must show a commitment to continue supporting the technology underlying the specification after OMG adoption, for instance by showing the BC development plans for future revisions, enhancement or maintenance.

__________________________________________

4.5 Responding to RFP items

4.5.1 Separate proposals

Unless otherwise indicated in Chapter 6, independent proposals are solicited for each separate item in the RFP. Each item is considered a separate architectural entity for which a proposal may be made. A submitter may respond to any or all items. Each item will be evaluated independently by the initiating TF. Submissions that do not present clearly separable proposals for multiple items may therefore be at a disadvantage.

It should be noted that a given technology (e.g. software product) may support two or more RFP items. So long as the interfaces for each item are separable, this is not precluded.

4.5.2 Complete proposals

Proposals for each separate RFP item must be complete. A submission must propose full specifications for each item and address all the relevant general and specific requirements detailed in this RFP.



4.5.3 Additional specifications

Submissions may include additional specifications for items not covered by the RFP which they believe to be necessary and integral to their proposal. Information on these additional items should be clearly distinguished.

Submitters must give a detailed rationale as to why these specifications should also be considered for adoption. However submitters should note that a TF is unlikely to consider additional items that are already on the roadmap of an OMG TF, since this would pre-empt the normal adoption process.

4.5.4 Alternative approaches

Submitters may provide alternative RFP item definitions, categorizations, and groupings so long as the rationale for doing so is clearly stated. Equally, submitters may provide alternative models for how items are provided within the OMA if there are compelling technological reasons for a different approach.

4.6 Confidential and Proprietary Information

The OMG specification adoption process is an open process. Responses to this RFP become public documents of the OMG and are available to members and non-members alike for perusal. No confidentiality or proprietary information of any kind will be accepted in a submission to this RFP.

4.7 Copyright Waiver

If a submitted document is copyrighted, a waiver of copyright for unlimited duplication by the OMG is required to be stated in the document. In addition, a limited waiver of copyright is required that allows each OMG member to make up to fifty (50) copies of the document for review purposes only.

4.8 Proof of Concept

Submissions must include a “proof of concept” statement, explaining how the submitted specifications have been demonstrated to be technically viable. The technical viability has to do with the state of development and maturity of the



technology on which a submission is based. This is not the same as commercial availability. Proof of concept statements can contain any information deemed relevant by the submitter, for example:

“This specification has completed the design phase and is the process of being prototyped.”

“An implementation of this specification has been in beta-test for 4 months.”

“A named product (with a specified customer base) is a realization of this specification.”

It is incumbent upon submitters to demonstrate to the satisfaction of the TF the technical viability of their proposal. OMG will favour proposals based on technology for which sufficient relevant experience has been gained in CORBA-based or comparable environments.

4.9 Format of RFP Submissions

This section provides guidance on how to structure your RFP submission.

4.9.1 General

• Submissions that are concise and easy to read will inevitably receive more consideration.

• Submitted documentation should be confined to that directly relevant to the items requested in the RFP. If this is not practical, submitters must make clear what portion of the documentation pertains directly to the RFP and what portion does not.

• The models and terminology in the Object Management Architecture Guide and CORBA should be used in your submission. Where you believe this is not appropriate, describe and provide a rationale for the models and terminology you believe OMG should use.

4.9.2 Suggested Outline

A three part structure for submissions is suggested:



PART I

• Copyright Waiver (see 4.5)

• Submission contact point (see 4.2)

• Overview or guide to the material in the submission

• Overall design rationale (if appropriate)

• Statement of proof of concept (see 4.6)

• Resolution of RFP mandatory and optional requirements

Explain how your proposal satisfies the mandatory and (if applicable) optional requirements stated in Chapter 6. References to supporting material in Part II should be given.

In addition, if your proposal does not satisfy any of the general requirements stated in Chapter 5, provide a detailed rationale.

• Responses to RFP issues to be discussed

Discuss each of the “Issues To Be Discussed” identified in Chapter 6.

PART II

• Proposed specification

PART III

• Summary of optional versus mandatory interfaces

Submissions must clearly distinguish interfaces that all implementations must support from those that may be optionally supported.

• Proposed compliance points

Submissions should propose appropriate compliance points for implementations.

• Changes or extensions required to adopted OMG specifications

Submissions must include a full specification of any changes or extensions required to existing OMG specifications. This should be in a form that enables “mechanical” section-by-section revision of the existing specification.



• Complete IDL definitions

For reference purposes and to facilitate electronic usage, submissions should reproduce in one place a complete listing in a compilable form of the IDL definitions proposed for standardization.

4.10 How to Submit

Submitters should send an electronic version of their submission to the RFP Submissions Desk ([email protected]) at OMG by 5:00 PM U.S. Eastern Standard Time (22:00 GMT) on the day of the submission deadline. Acceptable formats are Postscript, ASCII, PDF, FrameMaker, Word, and WordPerfect. However, it should be noted that a successful submission must be supplied to OMG’s technical editors in Framemaker source format, using the most recent available OMG submission template (document ab/97-06-02 at the time of writing). The AB will not endorse adoption of any submission for which appropriately-formatted Framemaker sources are not available; it may therefore be convenient to prepare all stages of a submission using this template.

Submitters should make sure they receive electronic or voice confirmation of the successful receipt of their submission. Submitters should also send, within three (3) working days after the submission deadline, a single hardcopy version of their submission to the attention of the “RFP Submissions Desk” at the main OMG address shown on the first page of this RFP.

In addition, submitters are responsible for making available 100 paper copies to attendees of the TF meeting immediately following a submission deadline. There are normally two such presentation meetings, one for the initial and one for the revised submissions.



5.0 General Requirements on Proposals

5.1 Mandatory Requirements

5.1.1 Proposals shall express interfaces in OMG IDL. Proposals should follow accepted OMG IDL and CORBA programming style. The correctness of the IDL shall be verified using at least one IDL compiler (and preferably more than one). In addition to IDL quoted in the text of the submission, all the IDL associated with the proposal shall be supplied to OMG in compiler-readable form.

5.1.2 Proposals shall specify operation behavior, sequencing, and side-effects (if any).

5.1.3 Proposals shall be precise and functionally complete. There should be no implied or hidden interfaces, operations, or functions required to enable an implementation of the proposed specification.

5.1.4 Proposals shall clearly distinguish mandatory interfaces and other specification elements that all implementations must support from those that may be optionally supported.

5.1.5 Proposals shall reuse existing OMG specifications including CORBA, CORBAservices, and CORBAfacilities in preference to defining new interfaces to perform similar functions.

5.1.6 Proposals shall justify and fully specify any changes or extensions required to existing OMG specifications. This includes changes and extensions to CORBA inter-ORB protocols necessary to support interoperability. In general, OMG favours upwards compatible proposals that minimize changes and extensions to existing OMG specifications.

5.1.7 Proposals shall factor out functions that could be used in different contexts and specify their interfaces separately. Such minimality fosters re-use and avoids functional duplication.



5.1.8 Proposals shall use or depend on other interface specifications only where it is actually necessary. While re-use of existing interfaces to avoid duplication will be encouraged, proposals should avoid gratuitous use.

5.1.9 Proposals shall specify interfaces that are compatible and can be used with existing OMG specifications. Separate functions doing separate jobs should be capable of being used together where it makes sense for them to do so.

5.1.10 Proposals shall preserve maximum implementation flexibility. Implementation descriptions should not be included, however proposals may specify constraints on object behaviour that implementations need to take into account over and above those defined by the interface semantics.

5.1.11 Proposals shall allow independent implementations that are substitutable and interoperable. An implementation should be replaceable by an alternative implementation without requiring changes to any client.

5.1.12 Proposals shall be compatible with the architecture for system distribution defined in ISO/IEC 10746, Reference Model of Open Distributed Processing (ODP). Where such compatibility is not achieved, the response to the RFP must include reasons why compatibility is not appropriate and an outline of any plans to achieve such compatibility in the future.

5.1.13 In order to demonstrate that the service or facility proposed in response to this RFP, can be made secure in environments requiring security, answers to the following questions shall be provided:

• What, if any, are the security sensitive objects that are introduced by the proposal?

• Which accesses to security-sensitive objects must be subject to security policy control?

• Does the proposed service or facility need to be security aware?

• What CORBAsecurity level and options are required to protect an implementation of the proposal? In answer to this question, a reasonably complete description of how the



facilities provided by the level and options (e.g. authentication, audit, authorization, message protection etc.) are used to protect access to the sensitive objects introduced by the proposal shall be provided.

• What default policies should be applied to the security sensitive objects introduced by the proposal?

• Of what security considerations must the implementers of your proposal be aware?

5.2 Evaluation criteria

Although the OMG adopts interface specifications, the technical viability of implementations will be taken into account during the evaluation process. The following criteria will be used:

5.2.1 Performance

Potential implementation trade-offs for performance will be considered.

5.2.2 Portability

The ease of implementation on a variety of ORB systems and software platforms will be considered.

5.2.3 Securability

The answer to questions in section 5.1.13 shall be taken into consideration to ascertain that an implementation of the proposal is securable in an environment requiring security.

5.2.4 Compliance: Inspectability and Testability

The adequacy of proposed specifications for the purposes of compliance inspection and testing will be considered. Specifications should provide sufficient constraints on interfaces and implementation characteristics to ensure that compliance can be unambiguously assessed through both manual inspection and automated testing.



6.0 Specific Requirements on Proposals

6.1 Problem Statement

The Process Working Group (PWG) is a coordinated effort within the OMG to produce a series of RFPs for the adoption of technologies of particular interest to the Software Process Engineering (SPE) community. The goal of the PWG is to adopt technologies that will be the basis of SPE facilities, and which will lead to a degree of automated support for SPE. The adoption of technologies, and of facilities based on those technologies, will have the effect of enabling convergence in the industry on unified SPE concepts, and of providing interoperability between the various tools that will be used in the SPE domain. This RFP focuses on interoperability among tools to support a user-defined process and does not address standardization of the process itself.

Software Process Engineering (SPE) is the development of the roadmap or approach for undertaking a software development project. Examples of SPE activities include: selecting the specific software development activities required, sequencing the activities, defining the work products and deliverables, and identifying the roles and techniques involved in a project.

Software Process Engineering in the software development industry is not a universal, well-defined or standardized activity. It has a high degree of variability due to causal factors operating at a number of levels.

(1)There is no agreed model of what a software engineering process definition should comprise.

(2)There is no standardized approach to the design of software engineering processes based on their requirements, which mainly exist in the form of a number of organizational and project-specific drivers.

(3)These drivers are themselves numerous and varied. Examples include: organization and team culture; established practices and habits; type of project; size; critical aspects; novelty; cost of failure; organization size; commitment to standards; technology to be used; quality constraints; and problem domain.



In addition to the major problem of lack of consensus regarding the practice of SPE, there is a major opportunity, afforded by the successful adoption of common modeling notations. The Unified Modeling Language (UML) version 1.3 has been adopted by the OMG as a modeling language and has received wide recognition and acceptance in the industry. The UML addresses modeling with associated diagrams, notation, semantics, etc. However, it does not address process, nor was that its intention.1 In fact, notation by its nature provides only the bottom level of a hierarchy of practices which, at the top level, comprises fully-defined software engineering processes. Intermediate levels are typically embodied in techniques, which prescribe how to construct models using the adopted notations, and tasks, which prescribe what is to be accomplished by using the techniques.

Project Managers, Analysts, Architects, Designers and Developers need these higher levels of guidance on how to use the UML. In addition, they need help with answering all the other process-related questions such as: which work products need to be produced; what kind of resources are needed to generate those products; when the tasks to generate those products should be undertaken, and so forth. It is therefore timely for the OMG to adopt a definition of SPE so that the full benefits of the uniformity of practice promised by the UML can be realized.

Finally, by taking advantage of the technical infrastructure adopted by OMG (CORBA, MOF, UML metamodel, XMI, etc.), and the various standards and knowledge that exist in the SPE area, this RFP provides a unique opportunity to enable interoperability between tools in the SPE market. This RFP will also raise the maturity of the SPE industry and place its activities on a unified non-proprietary platform.

6.2 Scope of Proposals

It is intended that several RFPs will be issued over time, with the purpose of eventually providing a complete set of adopted technologies for the SPE domain. The current RFP addresses the need to adopt an SPE metamodel or a UML Profile for SPE. It will be followed by several further RFPs that will adopt

1 Process was specifically excluded from the RFP in response to the feedback received in the original RFI which said that there was not, and may never be, convergence in the industry on process.



specific SPE component types such as processes, work products, or roles, and the service or facility for the adaptation of individual projects.

In Figure 1, the SPE metamodel or UML Profile for SPE is placed at the level “M2”. It will specify the necessary process engineering elements such as “Work Product” or “Task”. At the model level (M1), process engineers will be able to define or adapt their own process model, by for example specifying which kind of activity or work product (such as “Analysis Document”) will exist during a software development. At the object level (M0), will exist concrete realizations of the process models, such as a specific activity (createUseCase ”Credit Account”) or a specific Work Product.

Figure 1: Integrating the SPE Metamodel or UML Profile for SPE in the Four-layer OMG Metamodel Architecture

It will not be appropriate, in responses to the current RFP, to define actual process components, such as work products (e.g. Analysis Document), that may be part of a particular process, unless the examples presented are provided purely in order to explain and validate the metamodel concepts.

It is strongly recommended that respondents use packages to structure their submissions, both to aid understanding and to make dependencies between parts of the submission explicit.


M e ta M etaM o d el (M 3 )

M e ta m od e l (M 2)

M o de ls (M 1 )

Ob jects (M 0 )

M OF

U M L SPE w orkf lo w ...

(Example : Metaclasses Class,UseCase)

(Example : Metaclasses Activity ,WorkProduct)

(Example : Class BankAccount, UseCase CreditAccount)

(Example : Activity «CreateUseCase»,WorkProduct «AnalysisDocument»)

(Example : Account1321) (Example : CreateUseCase «CreditAccount»,AnalysisDocument «BankingSystem»

Or a “UML Profile”

M e ta M etaM o d el (M 3 )

M e ta m od e l (M 2)

M o de ls (M 1 )

Ob jects (M 0 )

M OF

U M L SPE w orkf lo w ...

(Example : Metaclasses Class,UseCase)

(Example : Metaclasses Activity ,WorkProduct)

(Example : Class BankAccount, UseCase CreditAccount)

(Example : Activity «CreateUseCase»,WorkProduct «AnalysisDocument»)

(Example : Account1321) (Example : CreateUseCase «CreditAccount»,AnalysisDocument «BankingSystem»

Or a “UML Profile”


The Software Process Engineering problem to be solved by this RFP is different in scope than the analysis and design problem solved by the UML metamodel. That is the reason for showing the SPE metamodel as a peer to the UML metamodel in Figure 1. Also, a UML Profile for SPE is a valid structure for a response to this RFP.

6.3 Relationship to Existing OMG Specifications

References in this RFP to ‘UML’ mean UML as specified in OMG Document(s) ad/99-06-09 (June 1999): OMG UML v. 1.3 (UML RTF's proposed final revision). Responses to this RFP should also be based on this (these) specification(s) for UML.

There is a current activity going on within the OMG to specify UML Profiles for Enterprise Distributed Object Components (EDOC). Precise references to this work cannot be made in this RFP since it will continue after this RFP is released. Work done on advancing the definition of “UML Profile” as part of EDOC should be taken into account by responses to this RFP.

The following OMG specifications are referenced in Section 6.5:

OMG Document ad/98-07-12 (29 July 1998) : Process Working Group White Paper on Analysis & Design Process Engineering

OMG Document ad/98-10-08 (13 November 1998) : Analysis & Design PTF Software Process Engineering Request for Information

OMG Document ad/99-09-05: MOF 1.3 document

OMG Document ad/99-10-02 and ad/99-10-03: XMI 1.1 document

OMG Document ad/99-04-07: White Paper on the Profile mechanism

OMG Document bom/98-06-07 : Joint Workflow Submission

OMG Document bom/98-07-15 : Errata to bom/98-06-07



OMG Document bom/99-03-01 : Convenience Document combining bom/98-06-07 and bom/98-07-15

Please refer to the OMG technology adoption index for further information: (http://www.omg.org/library/schedule/Technology_Adoptions.htm)

6.4 Related Documents and Standards

This RFP is not intended to adopt new software engineering process models and technologies without regard to standards already existing in the industry today, but to encourage interaction between communities like those of the SEI and OMG.

6.4.1 SEI CMM

The Software Engineering Institute’s Software Capability Maturity Model (CMM-SW) is relevant to this RFP in that it defines a set of guidelines to assist users in assessing and improving the maturity of their software engineering processes. The CMM-SW was published in 1991 and has been in use by many organizations throughout the world. As such, it is a good source for standard terminology and concepts. Proposals should reference the CMM-SW as appropriate in the response to designate terminology or concepts that are compatible with those from the CMM-SW, and also to justify claims that their proposals support the achievement of process maturity. The full reference for the current version of CMM-SW is:

Paulk, Mark C., et al. Capability Maturity Model for Software. CMU/SEI-93-TR-24. Software Engineering Institute, Carnegie Mellon University, 1993.

This document in turn references the other documents in the full official CMM-SW set.

For more information, see:

http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf





6.4.2 Workflow Management Coalition (WfMC) documents

Where there is overlap, proposals should be compatible with the following Workflow Management Coalition standards:

WfMC-TC-1003 Workflow Reference Model

WfMC-TC-1016 Workflow Process Definition Interchange

For more information, see: http://www.aiim.org/wfmc/mainframe.htm

6.4.3 The Project Management Institute Body of Knowledge (PMIBOK)

The Project Management Institute (PMI) is a good source of standard terminology, concepts and expertise in the area of project management, and hence, controlled process enactment. Proposals should either comply with PMI terminology where appropriate, or explain the mapping between their terms and the PMI's terms. The reference for the PMIBOK is:

PMI Standards Committee. A Guide to the Project Management Body of Knowledge. Upper Darby, PA: Project Management Institute, 1996.

This document can be downloaded at no charge from: http://www.pmi.org/

6.4.4 IEEE Documents

Proposals should be guided by IEEE Standard 1074, IEEE Standard for Developing Software Life Cycle Processes, in describing an SPE facility in which processes can be developed to be compliant with the requirements of IEEE/EIA 12207 (see Annex I of IEEE/EIA 12207.0-1996).

For more information, see: http://www.software.org/quagmire/descriptions/ieee-1074.html

Proposals should also follow or explain divergence from requirements and terminology in ISO/IEC 12207: Information Technology—Software Life-Cycle Processes and IEEE/EIA


http://www.software.org/quagmire/descriptions/ieee-1074.html

http://www.software.org/quagmire/descriptions/ieee-1074.html

http://www.pmi.org/

http://www.aiim.org/wfmc/mainframe.htm


12207: Industry Implementation of International Standard ISO/IEC 12207: 1995: Information technology—software life cycle processes.

For more information see: http://www.software.org/quagmire/descriptions/US-12207.html

6.4.5 Some Other Relevant Standards

This section summarizes some other references of importance in the SPE arena.

RM –ODP: Reference Model for Open Distributed Processing (ISO/IEC 10746-1 to 4 and ITU-T Rec. X.901 to X.904)

To download copies (OMG members only) refer to: ftp://ftp.omg.org/pub/docs/ISO-stds/99-08-01.doc

ISO/IEC TR 15504: Software Process Assessment

For more information, see: http://www.esi.es/Projects/SPICE.html

6.4.6 A Map of other Standards

There are many other process-related standards, which are owned by a wide variety of different organizations. The following diagram gives an overview of many of these, and their inter-relationships. The diagram was obtained from the Software Productivity Consortium’s web site at http://www.software.org. The reader is referred there for more overview information on these standards, many of which have considerable influence on process models, levels of abstraction, viewpoints, permissible notations and methods, and documentation structure. Respondents are encouraged to reference potentially applicable standards in their proposals, since compliance with these external standards is an important and common requirement on software processes.


http://www.esi.es/Projects/SPICE.html

ftp://ftp.omg.org/pub/docs/ISO-stds/99-08-01.doc

http://www.software.org/quagmire/descriptions/US-12207.html


Figure 2: A Map of the Standards ("Frameworks") "Quagmire"

(c) 1999: Reproduced by Permission of the Software Productivity Consortium

Legend:

arrows indicate derivation from (via information or people) colors are used for categorization red = a capability maturity model green = a U.S. Government or military document purple = international standard blue = commercial, professional or industrial association document (mostly U.S.)

6.5 Mandatory Requirements

6.5.1 Specification of the SPE Metamodel or UML Profile

Submissions shall conform to the four layered architecture defined by the OMG (see Figure 1). Metamodels shall be clearly positioned in relation to the UML metamodel, and built using the MOF meta-metamodel. Relationships between these metamodels shall be identified, and specified. A submission shall include an XMI DTD for a submitted metamodel.



The SPE metamodel or UML Profile shall address at least the following process engineering concepts. The names for these concepts in this RFP are examples. Responses to this RFP are not required to use these exact names.

Tasks

A unit of work that must be engaged in order to produce products.

Techniques

Descriptions of how the tasks should be carried out in order effectively to produce the desired products.

Roles

Roles played by resources that perform the tasks and produce the products.

Products

The artifacts that are consumed and produced by role-playing resources as they execute tasks.

Phases

Significant segments of the complete life cycle, usually with defined entrance and exit criteria, milestones, and work products. Phases are used as units of management funding and authorization.



6.5.2 Submissions shall submit two or more examples of processes that use the submitted SPE Metamodel or UML Profile. Complete process models are not expected, but examples shall be used to illustrate and validate submitted metamodel or UML profile concepts. In particular, providing examples from several processes (BOAD, Catalysis, Macroscope, RM-ODP/G851, RUP, etc.) will be considered as valuable proof of concepts. Such examples will not be considered as part of the OMG adopted technology specifications resulting from this RFP.

6.5.3 Process Patterns and/or Components

This RFP calls for the ability to define process patterns and/or process components, i.e. collections of process elements that solve specific process engineering problems and are reusable, in a "plug-and-play" sense, in multiple different process definitions. Submissions are therefore required to define constructs that enable the creation and use of reusable process patterns and/or components, and to show how these constructs are used.

6.5.4 Definition of Terms

In this RFP, a provisional set of terms has been used on an informal basis. However, no glossary has been provided. This was the result of a deliberate decision. The terminology in this RFP is illustrative and provisional rather than formal.

Submitters to this RFP shall include a full glossary of SPE terms. These terms shall have a clearly defined relationship to the constructs defined in the submitted SPE metamodel or UML Profile.

6.5.5 Providing SPE Support particularly suited to UML

Proposals shall describe an SPE facility that supports the use of UML for software engineering modeling and process modeling.

In particular, a specification of relationships between SPE constructs and UML constructs is required, wherever such relationships exist.



Facilities providing help in UML usage, depending on the activity and on the development context, shall also be defined.

See also section 6.6.1, which requests proposals optionally to consider the use of the UML Profile concept during the development process, and to define relationships between UML Profiles and SPE constructs.

6.5.6 Taxonomy Support

A submission shall

provide the facility to define a standardized set of categories and

provide the ability to classify all process elements using these categories.

6.5.7 National language support

A submission shall be organized so that the conceptual structure is separated from all textual description aspects, so that a given process can readily be translated into different national languages without losing its structure.

6.5.8 Notation

Responses to this RFP shall include graphical notations for new concepts or shall default to UML notations for process modeling. Where a response to this RFP does make notation recommendations other than UML notations, it shall show the relationship between those recommendations and other established process modeling notations, for example, the IDEF0 standard. The reference for that standard is:

National Institute of Standards and Technology. Integration Definition for Function Modeling (IDEF0). FIPS Publication 183, 1981.

If a recommended notation is not UML-based, responses to this RFP shall explain why a different notation is better.



6.6 Optional Requirements

6.6.1 Using UML Profiles to define the SPE Metamodel

If a submission defines an SPE metamodel, then it may also define a corresponding UML profile using recognized UML extensibility mechanisms (i.e., stereotypes, tagged values, and constraints). Such an approach would be consistent with the technologies adopted by the OMG (and those in the process of OMG adoption, e.g. EDOC) and ensure a strong UML/SPE alignment.

6.6.2 Process patterns

It is a mandatory requirement of this RFP (see section 6.5.2) that submissions shall support the definition of process patterns and/or process components. Optionally, submissions may in addition define actual process patterns or process components as examples.

6.6.3 Modeling Profiles as a part of a Process Definition

UML Profiles allow process engineers to specialize and constrain the UML in order to adapt it to their specific processes. As an example, a profile intended to specify how the UML language should be used during analysis may be defined. The UML 1.3 adopted technology already provides examples of process related profiles.

Submitters may reify the UML profile concept itself in their submissions, thereby making it possible to express the relationship between profiles and other process definition elements. The ways in which profiles may constrain the development process, notations or tools are of particular importance and may be emphasized. Relationships between profiles and activities and between profiles and [work] products or deliverables may be clarified.

6.7 Issues to be Discussed

6.7.1 The Nature of [Work] Products and Deliverables

There are many ways of defining terms such as "product", "work product" and "deliverable". There is currently no



consensus on the meaning of such terms in the industry. Submissions should discuss the usefulness of their particular definitions in terms of:

the distinctions between terms that are used in the submission, such as "product", "work product" and "deliverable";

the ways in which products may be combined or aggregated to form composite products;

rules that may be defined in order to constrain such product combinations or aggregations;

the modeling of dependencies between products;

the modeling of trace or derivation relations between products.

6.7.2 Evolution of Products through the Life Cycle

The concept of a life history for a product should also be discussed; life history in this sense meaning the evolution of the product during its development. For example, a class diagram may be a product, and it will evolve through the development process. Proposals may clarify the nature of such evolution, and provide a scheme for resolving it into its separate aspects. Examples of three such aspects are:

A product may "evolve" into another one in the sense that a later product is derived from an earlier one, e.g., by refinement. For instance, a design class diagram would be derived by refinement from an analysis class diagram.

A product may "evolve" in the sense that it can go through "promotion levels" that model its quality status.

A product's ultimate fate might be to be subsumed into some larger and more formal work product or deliverable. For example, an analysis class diagram may eventually be incorporated into a larger specification product.



6.7.3 Configuration and Version Management of Processes

Proposals should discuss, in terms of a well-defined model of configuration management (which may be referenced rather than developed within the proposal), sensible choices for the granularity of the versionable objects and inter-object links in their submissions.

Submitters should bear in mind that configuration and version management of large composite artifacts such as processes pose particular challenges, and that the ability to meet those challenges is an important feature of a submission. Support for the ability to merge processes has therefore been mentioned as an evaluation criterion in section 6.8.10 on Process Improvement.

6.8 Evaluation Criteria

In addition to being evaluated simply on their satisfaction of the requirements stated earlier in this document, submissions will be evaluated on the basis of the following criteria.

6.8.1 Metamodel Leveling, Scope and Structuring

Submissions will be evaluated according to:

their fidelity to the four-level metamodeling architecture

the breadth of coverage of their process lifecycle

Non-redundancy between SPE metaclasses and UML metaclasses

the elegance with which the modeling concepts are described and the clarity with which related levels of abstraction are explained.

6.8.2 Understandability

In addition to the above, submissions will be evaluated on their understandability. It is hoped that the adopted submission will be widely accepted within the industry, so good, clear presentation will be an important adjunct to technical soundness.



The following rules of thumb governing the construction of optimally usable models are offered by way of guidance and help to submitters.

The submitted documentation should strike a judicious balance between textual and graphical material, and between formality and informality.

In particular, natural language descriptions should be clarified by relating them to formal elements, while formal elements should be saved from inscrutability by natural language descriptions. The result should be optimal readability in both the formal and informal content.

The submitted documentation should be arranged according to a clear structure, which preferably should follow - at least in part - the chosen package (model management construct) structure.

Terms should be defined as needed within the flow of the document as well as being collected together into their own section of the document.

A refinement-based leveling of the proposal will allow the reader to zoom in and out, choosing to treat many objects or operations as one, or vice versa, as appropriate to the level of description required. A strong concept of refinement and the use of that concept in structuring proposals are therefore recommended. (Note: This is not a euphemism for a lax top-down approach to modeling.)

It should be clear at every point in the submission what problem is being addressed, and in what way the proposed solution matches that problem. Where helpful, submitters should explain their choice of solution options by contrast with other, rejected choices. Where this is done, it must be clear which option was finally selected, and which others rejected.

As a rule of thumb, it is poor style to rely on the names of model elements to convey their meaning. Semantics should be communicated using supporting textual elements such as predicates defined in OCL, or natural language.



6.8.3 Separation of Formally Submitted from Illustrative Material

Submissions will normally need to include a certain amount of illustrative or exemplary material that will not be part of the formally adopted specification, but will be useful in helping readers to understand the proposal. Submissions that clearly make this distinction, and that make appropriate and full use of the opportunity to provide examples without obscuring the overall content of the proposal, will be assessed more favorably than those that do not.

6.8.4 Generality and Descriptive Power of the Submission

A submitted SPE metamodel or UML Profile for SPE should be general enough, and contain a sufficient range of metamodel types and relationships to be able to describe a wide range of well-known software engineering processes and process models. Submissions in which such generality is demonstrated by the description of examples of particular widely known processes in metamodel terms will be assessed more favorably than submissions that lack such validation.

6.8.5 Proof of Concept

Submissions should demonstrate the workability of the concepts introduced by means of some proof of concepts. Submissions that do this will be considered more favorably than those that rely solely on reviewer interpretation.

The proof of concept may take one or more of a variety of forms, including, but not limited to the following.

A working prototype process instantiated from the metamodel.

A paper prototype worked through in enough detail to show how users would instantiate and use one or more different process models specialized from the submitted metamodel or UML profile.

A paper prototype could take the form of a number of different type (classifier) descriptions such as use cases or classes, and sequencing diagrams and state models. In addition, in order to be an effective proof of concept, it would typically need to



include instance descriptions such as instance diagrams and scenarios.

6.8.6 Support for Multi-level Process Institutionalization and Customization

In the real world of process engineering, best practices need to be definable and adaptable at all levels of the enterprise, from the highest - or most centralized - to the most local, right down to the creation of a unique process definition for each project. A particular acceptance criterion for submissions will be whether they will be capable of supporting these multiple levels of institutionalization, customization, or adaptation in a realistic and workable manner.

6.8.7 Basis for a Usable SPE Facility

A submission will not only be evaluated on its ability to capture all software engineering process components and to assemble a customized process for a particular project context. It will also be evaluated on its suitability as a basis for the creation of a usable SPE facility.

6.8.8 Tool interoperability

Submissions will be evaluated according to how well they enable the use and interoperation of CAPE (Computer-Aided Process Engineering), CASE (Computer-Aided Software Engineering), Workflow and other (e.g., planning and scheduling) tools during development. This is within a single defined process and not interoperability across different process models that can be instantiated from the submitted SPE metamodel or UML Profile.

In particular, submissions that provide a concrete definition of the way - or ways - in which users and tools will interoperate using the constructs specified in the submission will be more favorably assessed than those that do not.

Topics to be discussed within such a definition may include but are not limited to: the connections between the UML metamodel and the SPE

metamodel or UML Profile for SPE



task support : how to use a tool to carry out part or all of a technique. Task support includes tool usage guidance, which can be supported by tool specific techniques such as tool usage rules, predefined examples, or specific automations.

which notations the technique calls for how several techniques can be applied to complete a task or

higher level activity the purpose of work with the tool in the context of the whole

process the recommended structuring, version control and content of

higher-level products traceability between work products

6.8.9 Coverage

Submissions will be evaluated in accordance with how well they support the following areas of process content:

task, role and resource definition textual description of elements checklists work product definition versioning and configuration of work products work schedules: estimated, planned and actual; relationship

with external scheduling programs risk estimation and management metrics project organization techniques tools work breakdown structure traceability and refinement context-specific help and guidelines Quality aspects, such as integration of performance

information with functional models

6.8.10 Process improvement

Submissions will be evaluated according to how well they support improvement and evolution of the defined processes across multiple software development projects. In particular, submissions that address the following topics will be assessed more favorably than those that do not:

development of the process



institutionalization of the process by adaptation at different organizational levels

deployment and customization of the process monitoring of project performance capture of project metrics analysis of metrics realization of benefits to stakeholders management of reuse merging of processes from different sources configuration management and version control of processes

and process parts.

6.8.11 Relationship to workflow standards

It is expected that submissions will distinguish between those processes that fit within the OMG Workflow model and those that do not.

In addition, submissions will be evaluated on the clarity of the mapping of Work Products or other artifacts into the OMG Workflow concepts of process context, process results and Workflow Resource.

6.9 Other Information Unique to This RFP

None.



6.10 RFP Timetable

The timetable for this RFP is given below. Note that the TF may, in certain circumstances, extend deadlines while the RFP is running, or may elect to have more than one revised submission step. The latest timetable can always be found in the Member Services section of OMG’s Web page (URL http://www.omg.org/)

ApproxDay

Event or Activity Actual Date

Preparation of RFP by TFApproval of RFP by Architecture Board Review by TC (“Three week rule”)

TC votes to issue RFP November 19, 199961 LOI to submit to RFP due January 19, 2000175 Initial submissions due May 12, 2000189 Voter registration closes May 26, 2000201 Initial submission presentations June 7, 2000

Preliminary evaluation by TF266 Revised submissions due August 11, 2000292 Revised submission presentations September 6, 2000

Final evaluation and selection by TFRecommendation to AB and TCApproval by Architecture Board Review by TC (“Three week rule”)

392 TC votes to recommend specifications December 15, 2000417 BOD votes to adopt specifications January 9, 2001


http://www.omg.org/