Summary of PWG RFI Response

1
Summary of PWG RFI Response

• Alan Birchenough
• Chief Methodologist
• PLATINUM Process Library Team

2
Agenda

• Response Document Structure
• Short Answers
• Supporting Discussion
• Key Points in the Response

3
Response Document Structure

• Short Answers
• One-to-one mapping with RFI Questions
• Supporting Material
• Need for SPE/CBPD
• Scope of SPE
• SPE Model
• SPE Facility
• Boostrap Glossary
• Existing Implementations
• Some Standards

4
Summary of Answers 4.1.1

• Is this something the OMG should be doing?
• YES. OMG is well placed at present.
• And...
• Support for SPE should be automated (to some
  degree)
• CBPD based on process frameworks
• (Open/closed principle)
• Establish a process component architecture
• like a mini-OMA for process
• Even the less stable workflow dimension can be
  addressed by frameworks

5
White Paper WP Concept(s)
Figure describes the Software Process Engineering
Concept as noted in the OMG/ADTF/PWG/RFI
6
Validating the WP Concept(s)

• Broadly, yes, a
• Meta-model
• Models
• Facility
• But we think this is model/user data rather
  than meta model/model

7
The Scope of SPE Questions

• Questions
• 4.1.2 Whole Process?
• 4.1.3 Work Products?
• 4.1.4 Other Aspects
• minimum set of work products
• version management
• ensuring traceability
• phasing

8
The Scope of SPE Answers (1)

• THE PURPOSE OF PROCESS IS TO INTEGRATE DIVERSE
  ACTIVITIES
• Therefore include
• Project Types
• Operational Processes
• Viewpoints and Abstraction Levels
• RM-ODP Standard
• Catalysis Process

9
Viewpoints and Abstraction Levels RM-ODP

• Viewpoints
• Enterprise
• Information
• Computational
• Engineering
• Technology

10
Viewpoints and Abstraction Levels Catalysis
Process
11
Viewpoints and Abstraction Levels Keywords and
Workflows

• In Process Continuum, Components belonging to a
  particular Viewpoint/abstraction Level are tagged
  with Keywords
• Calls out technically coherent Threads of
  Activity, with Roles, Products and Techniques
• Analogous to the grouping in Rational Unified
  Process (RUP) called a Workflow

12
The Scope of SPE Answers (2)

• Minimal set of work products?
• Model must be able to support definition
• RFP should solicit actual definitions
• Version Management
• Yes. Part of the CASE/CAPE story.
• Traceability
• Need well-founded definition of refinement,
  e.g., in Catalysis
• Good opportunity to integrate CASE and CAPE
• Leverage UML model management constructs

13
The Scope of SPE Answers (3)

• Phasing
• IN OUR EXPERIENCE
• Very Important
• Most Project Managers work this way
• Must be supported
• however,
• not a Fundamental Problem
• just one (very important) Way of allocating Time
  to Activities and predicting the Outcome

14
SPE Model Scope Typical Types

• Products
• Organizations, Teams, Projects
• Roles
• Phases, Activities, Tasks
• Techniques, Design Patterns
• Tools
• Estimates
• Metrics
• Process Patterns and Frameworks

15
SPE Facility What Services?

• Parameter-Driven Process Assembly
• Incremental Institutionalize then Adapt
• Process Instantiation for a Project
• Process, Process Component, Process Framework
  Development
• Monitoring of Project Peformance
• Capture of Actual Project Metrics
• Process Improvement

16
SPE Facility Tools, Languages, Formalisms?

• Question 4.2.7 was interpreted to mean the
  following.
• Should there be a written Language (concrete
  syntax) for Process Definitions?
• Is there a need for new Graphical Notations to
  define Process? If so, indicate what the need
  might be.
• Should the Facility support those Graphical
  Notations?

17
SPE Facility Tools, Languages, Formalisms

• Facility should primarily be interactive
• Must support Textual Forms for all Elements
  e.g., XML
• Could be supported via Import and Export
• Should be round-trip
• Existing Graphical Notations are probably
  adequate, but could be strengthened, .e.g, UML
  Activity Diagram
• Also map to other established Notations, e.g.,
  IDEF0 FIPS 183

18
4.2.4 Is there a need for Registration/Certificati
on?

• YES!!
• A Meta Model will never be sufficient to ensure
  Plug Compatibility
• especially if only defined to a low standard of
  formality as tends to be the case today
• should aim for high level of formality, e.g.,
  using OCL
• there will always be reliance on human-readable
  Architecture rules and Guidelines
• Define Certification Process using the
  Newly-standardized Model

19
Some Features 4.2.5 Support for Patterns

• Design Patterns
• Complementary to Techniques
• Process Patterns
• Determine the Layering and Composition of
  Processes
• Some could/can be formalized and even automated
  using Catalysis-style Frameworks

20
4.2.10 Binding CAPE and CASE

• Prompt, support and help the CASE User
• Prescribe permissible UML Usage(s)
• Support Traceability
• Constrain inter-product Dependencies
• Prescribe traceability modeling activities
• E.g., compliance matrix, Catalysis Refinement
  Model
• Support Configuration Management/Version Control
• of products
• of process itself!

21
Glossary

• Only as a Bootstrap
• Related to other Standard(s) de facto or de
  jure
• PMI Body of Knowledge
• OPEN process meta model

22
Future Needs

• CBPD provides Flexibility, Adaptability and
  Control into the Future!
• Process Simulation
• Often used by Organizations mature in their
  approach to SPE as part of their Process
  Improvement Mechanism

23
Road Map

• At least one RFP
• SPE Model and Concepts
• Glossary (in Catalysis, type model)
• Prototypes
• Example Applications
• Catalysis
• Fusion
• RUP
• Starter Pack
• Institutionalization and Tailoring Guidelines
• and then?