OMG Software Process Engineering Management

1
OMG Software Process Engineering Management

• From Software Process Engineering (SPE)
  Management
• Request for Proposal ad/99-11-04
• IBM, Rational et al. response ad/2000-05-05
• Fujitsu DMR Consulting response ad/2000-05-01
• Joint SPEM Update ad/00-12-02

2
Request for Proposals

• Software Process Engineering (SPE)
• The development of the roadmap or approach for
  undertaking a software development project
• select the specific software development
  activities required
• sequence the activities
• define the work products and deliverables
• identify the roles and techniques involved in a
  project
• Issues
• There is no agreed model of what a software
  engineering process definition should comprise.
• Diverse requirements/drivers
• Product size, domain, novelty, technology,
  critical aspects, quality constraints
• Organization culture, habits, size, commitment
  to standards, maturity
• Project type, cost of failure

3
Request for Proposals (continued)

• Opportunity enable interoperability of SPEM
  tools
• Acceptance of UML and support tools
• But need guidance on how to use UML
• Convergence of technology standards
  infrastructure
• CORBA, MOF, UML metamodel, XMI, etc.
• Various standards and knowledge that exist in the
  SPE area

4
SPE is a Metamodel

• Process Engineers define and adapt their process
  models (M1)

5
Related Documents and Standards

• SEI Software Capability Maturity Model (CMM-SW)
• Workflow Management Coalition (WfMC)
• Project Management Body of Knowledge (PMBOK)
• IEEE Standard for Developing Software Life Cycle
  Processes (IEEE Standard 1074)
• RM ODP Reference Model for Open Distributed
  Processing (ISO/IEC 10746-1 to 4 and ITU-T Rec.
  X.901 to X.904)
• ISO/IEC TR 15504 Software Process Assessment

6
(No Transcript)
7
SPEM Required Contents

• 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.

8
Required Contents (continued)

• Ability to define Process Patterns and/or
  Components
• Collections of process elements
• solve specific process engineering problems
• reusable, in a "plug-and-play" sense, in multiple
  different process definitions
• SPE Facility that supports the use of UML for
  software engineering modeling and process
  modeling
• Taxonomy support
• Facility to define a standardized set of
  categories
• Ability to classify all process elements using
  these categories
• Graphical Notation UML or alternative

9
Issues to Discuss

• Nature of Work Products and Deliverables
• Distinctions between terms
• Composites or aggregates (and constraints)
• Dependencies
• Trace or derivation relationships
• Evolution of Products through the Life Cycle
• Refinement (e.g., analysis class diagram to
  design class diagram)
• Quality levels
• Subsumed into larger work product (e.g., analysis
  class diagram into specification product)
• Configuration and version management of processes

10
Evaluation Criteria

• Metamodel leveling, scope and structuring
• Understandability, generality, descriptive power
• Proof of concept
• Support for multi-level process
  institutionalization and customization
• Basis for a usable SPE Facility
• Tool interoperability
• Process Engineering (CAPE)
• Software Engineering (CASE)
• Workflow definition and enactment
• Planning and scheduling
• Relation to OMG Workflow standards (from WfMC)
• Process context, process results, workflow
  resource

11
Evaluation Criteria (continued)Coverage of
Process Content

• Task, role, resource definition
• Textual description of elements
• Checklists
• Work product definition
• Versioning and configuration of work products
• Work schedules estimate, plan, actual
• Risk estimation and management
• Metrics

• Project organization
• Techniques
• Tools
• Work breakdown structure
• Traceability and refinement
• Context-specific help and guidelines
• Quality aspects
• e.g., integration of performance information with
  functional models

12
Evaluation Criteria (continued)Support Process
Evolution/Improvement Across Projects

• Process development
• Institutionalization of the process by adaptation
  in different organizations and organization
  levels
• Deployment and customization
• Monitoring of project performance
• Capture of project metrics

• Analysis of metrics
• Realization of benefits to stakeholders
• Management of reuse
• Merging processes from different sources
• Configuration management and version control of
  processes and process parts

13
Initial Submissions

• Unified Process Model
• IBM
• Rational Software
• SofTeam
• Unisys
• Nihon
• Alcatel
• Q-Labs (ex-Objectif Technologies)
• Valtech
• Toshiba

• Fujitsu DMR Consulting
• Solution-oriented Development Engineering
  Methodology 21 (SDEM 21)
• Application/Architecture / Business Rule Modeling
  AD Method
• DMR Macroscope

14
Fujitsu DMR Submission

• Purpose
• What activities are performed? When?
• What resources are required to perform the
  activities?
• What are the desired results?
• What should one know to accomplish the above in
  an effective manner, in a variety of
  circumstances?
• For all of the above why?

15
Fujitsu DMR Submission (continued)

• Characteristics / Capabilities
• Understandability
• Sequencing of activities
• Concurrent activities
• Inputs required for and the outputs produced from
  each activity.
• Including the status of the resources prior to
  consumption and following production by an
  activity
• Complex events that occur during a process and
  cause transitions between activities
• Hierarchical decomposition of activities
• The ability to define an activity once, and reuse
  the definition in composing several different
  activities
• Use process models as process patterns which
  can be copied and modified to fit specific
  situations

16
Fujitsu DMR Submission (continued)

• Metamodel approach
• UML activity diagrams for process modeling
• Associations that link the appropriate SPE
  metaclasses to the UML activity diagram semantics

17
UML Activity Diagrams
Object in state
Consumed Object
Produced Object
Activity
Transition
Fork/Join
18
Activity Diagrams for SPE Modeling
19
Packages
20
Fundamentals Package
21
Process Model Package
22
Resource Model Package
23
UML Metamodel Package
24
A RUP Activity Diagram
25
A Macroscope Activity Diagram
26
Unified Process Model

• Rational Rose model
• http//cs.ua.edu/hawker/process
  components/report/UPM link.htm

27
Current Status

• Developing Joint submission
• Expected end of February, 2001
• See here
• http//cs.ua.edu/630/Notes, etc./OMG SPEM/SPEM
  update ad-00-12-02.pdf

http//cs.ua.edu/630/Notes, etc/OMG SPEM/SPEM
update ad-00-12-02.pdf