Software Process Modeling with UML and SPEM

Slides:



Advertisements
Similar presentations
Writing Good Use Cases - Instructor Notes
Advertisements

Requirements Engineering Processes – 2
Overview: Guide for applying RM-ODP with UML Profile for EDOC
© 2005 by Prentice Hall Appendix 3 Object-Oriented Analysis and Design Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George.
Chapter 7 System Models.
Copyright © 2003 Pearson Education, Inc. Slide 1 Computer Systems Organization & Architecture Chapters 8-12 John D. Carpinelli.
Object-Oriented Analysis and Modeling Using the UML
Chapter 1 The Study of Body Function Image PowerPoint
1 Copyright © 2013 Elsevier Inc. All rights reserved. Chapter 1 Embedded Computing.
Author: Graeme C. Simsion and Graham C. Witt Chapter 8 Organizing the Data Modeling Task.
Copyright © 2011, Elsevier Inc. All rights reserved. Chapter 6 Author: Julia Richards and R. Scott Hawley.
Author: Julia Richards and R. Scott Hawley
1 Copyright © 2013 Elsevier Inc. All rights reserved. Appendix 01.
1 Copyright © 2013 Elsevier Inc. All rights reserved. Chapter 3 CPUs.
Copyright: SIPC From Ontology to Data Model: Choices and Design Decisions Matthew West Reference Data Architecture and Standards Manager Shell International.
Introduction to Product Family Engineering. 11 Oct 2002 Ver 2.0 ©Copyright 2002 Vortex System Concepts 2 Product Family Engineering Overview Project Engineering.
UNITED NATIONS Shipment Details Report – January 2006.
Armstrong Process Group, Inc. Copyright © , Armstrong Process Group, Inc., and others All rights reserved Armstrong Process.
10 Copyright © 2005, Oracle. All rights reserved. Reusing Code with Inheritance and Polymorphism.
Projects in Computing and Information Systems A Student’s Guide
Week 2 The Object-Oriented Approach to Requirements
Intel VTune Yukai Hong Department of Mathematics National Taiwan University July 24, 2008.
Chapter 5 – Enterprise Analysis
Object-Oriented Software Engineering Visual OO Analysis and Design
OOAD – Dr. A. Alghamdi Mastering Object-Oriented Analysis and Design with UML Module 3: Requirements Overview Module 3 - Requirements Overview.
Testing Workflow Purpose
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 31 Slide 1 Service-centric Software Engineering.
By Waqas Over the many years the people have studied software-development approaches to figure out which approaches are quickest, cheapest, most.
Use Case Diagrams.
Factor P 16 8(8-5ab) 4(d² + 4) 3rs(2r – s) 15cd(1 + 2cd) 8(4a² + 3b²)
© 2012 National Heart Foundation of Australia. Slide 2.
Lecture 6: Software Design (Part I)
Systems Analysis and Design with UML Version 2.0, Second Edition
Understanding Generalist Practice, 5e, Kirst-Ashman/Hull
آزمایشگاه مهندسی نرم افزار
Executional Architecture
Requirements Analysis 1. 1 Introduction b501.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Introduction.
Chapter 2 Entity-Relationship Data Modeling: Tools and Techniques
Chapter 10: The Traditional Approach to Design
Analyzing Genes and Genomes
Systems Analysis and Design in a Changing World, Fifth Edition
©Brooks/Cole, 2001 Chapter 12 Derived Types-- Enumerated, Structure and Union.
Intracellular Compartments and Transport
PSSA Preparation.
Chapter 11 Describing Process Specifications and Structured Decisions
Chapter 11 Component-Level Design
Essential Cell Biology
1Model Driven Architecture – 3. März 2008 – Siegfried Nolte 1.UML – What is it and what is it good for ? 2.MDA – What is it and what is it good for ? 3.MDA.
Modeling Main issues: What do we want to build How do we write this down.
From Model-based to Model-driven Design of User Interfaces.
© Copyright 2011 John Wiley & Sons, Inc.
1 IBM Software Group ® PRJ270: Essentials of Rational Unified Process Module 3: RUP Structure and Navigation.
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Practical Business Modeling in the Unified Process Tom Morgan Software Architect, Fidelity National Information Services
Static Structure: Process Description
IBM Business Consulting Services © Copyright IBM Corporation 2006 Unified Process March 27, 2006 Chris Armstrong.
Rational Unified Process Fundamentals Module 4: Disciplines II.
Copyright 2001 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Appendix A Object-Oriented.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
 The need for a formal methodology description  SPEM for describing an agent oriented methodology  PASSI: an example  The needed extension  Discussion.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Rational.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
Systems Analysis and Design in a Changing World, Fourth Edition
Object-Oriented Analysis and Design
Chapter 20 Object-Oriented Analysis and Design
Copyright © 2015, 2012, 2009 Elsevier Inc. All rights reserved.
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Presentation transcript:

Software Process Modeling with UML and SPEM Chris Armstrong Armstrong Process Group www.aprocessgroup.com

Module Objectives Introduce the Software Process Engineering Metamodel (SPEM) specification Discuss fundamental process building blocks Work product, process role, activity, guidances Discipline, process component, work definition Discuss the process adoption process Discuss how to apply UML® diagrams for process modeling Activity diagrams Class diagrams

What Is SPEM? Specification from the Object Management Group for how to describe software engineering processes Described as a UML profile Provide basis for capturing process models in SPEM-compliant tools Create base process libraries and components in any tool Customize organization- and project-specific processes Current version is 1.0; version 2.0 underway

Process Model Hierarchy M3: Meta- Object Facility OMG “meta” metamodel; modeling language for modeling languages M2: Process Metamodel SPEM specification identifying elements required to describe processes Specific process model for domain or vendor; includes out-of-the-box and customized versions M1: Process Model abstraction Actual process enacted by a project M0: Enacted Process # of elements

Relationship of SPEM to UML SPEM is defined as a UML profile Defines the subset of UML to use Identifies special stereotypes to existing UML elements Use packages for organizing process model Most SPEM elements are described using UML classes Process behavior described using Activity diagrams (workflow diagrams) Statechart diagrams (work product state models) Process structure described using class diagrams

Core SPEM Elements Process roles responsible for work products Each work product responsibility of single role Process roles perform activities Each activity only performed by single role Work products used as inputs to activities and outputs from activities “Somebody does something that changes something” 1 process role responsible for 1 0..* performs input work product 0..* 0..* output 0..* 0..* used by activity 0..* produced by

Process Structure work definition process performer work product 1 work definition process performer parent 0..* performer 0..* 0..* 0..* 0..* produced by subwork used by 0..* output 0..* work product input 0..* responsible for 1 0..* 1 activity step process role 0..* 0..* assistant

Work Product Anything produced, consumed, or modified by a process Known as artifacts or deliverables in certain processes Work products can be composed of other work products Represent using UML aggregation or composition Represent responsible role using association between role and work product Work products can be of various “kinds” Document, model, source code, executable Work products may have an associated state model Represented as UML class stereotyped as «work product» Instances of work products shown as object flow states on activity diagrams

Work Product States Key factor in modeling adaptive processes is to identify and describe the multiple states an individual work product goes through in its lifetime Most useful when states represent how work product gets more and more complete Provides objective criteria for determining “done-ness” Traditional processes have work products with a single state Work product is either completely done or not done at all No intermediate stopping points for review and assessment Draw UML statechart diagram to identify states and allowable transitions Show work products as object flows with states on activity diagrams

Example Work Product States – Use Case Identified (Level 1) Identified with name Described (Level 2) Described with sentence or two Basic flow steps identified; alternate flows identified by name Outlined (Level 3) Detailed (Level 4) Basic and alternate flows detailed; special requirements

Work Definition Describes work performed in process Main subclass is activity Phase, iteration, and lifecycle are also subclasses of work definition Can be composed of smaller work definitions Recommend using work definitions to group related activities Can be related to a use case – leads to useful results Has input and output work products Can have pre-conditions and goals (post-conditions) Responsibility of specific process performer (usually a process role) Represented as UML class stereotyped as «work definition»

Activity Main subclass of work definition Discrete task, relatively short in duration, assignable to one individual playing role Represented as operation (on a class) stereotyped as «activity» Has input and output work products Represented as parameters on activity operation Recommend that activities should either create new work products or change state of existing work product Otherwise, how do you know if the activity occurred? Activities can be optionally decomposed into smaller, atomic steps

Process Role Defines a role that one or many people may play on project Software architect, project manager, developer Known as role, worker, or agent in certain processes Represented as UML actor stereotyped as «process role» Often represented as class instead Responsible for one or many work products May modify other work products Responsible for performing specific activities May assist with other activities Subclass of process performer Superclass occasionally used for work definitions not assignable as activities to process roles

Guidances Can be associated with any SPEM model element to provide more detailed information about the element to the practitioner Most often associated with activities and work products SPEM comes with a set of built-in guidance types Checklist Template Example Tool mentor Guideline

Process Components and Packages Process elements should be organized using packages Package groupings of process elements suitable for reuse into process components Packages stereotyped as «process component» A discipline is a set of activities, work products, and roles related to one “theme” A process is considered to be a “stand-alone” component Show dependencies between components package process component discipline process

Process Lifecycle Subclass of work definition Lifecycle Phase Really should be subclasses of something other than work definition, such as a time element (not in SPEM 1.0) Lifecycle Sequence of phases that achieve a specific goal Governed by a process Phase Sequential chunks of time during process enactment Iteration Smaller chunk of time with minor milestone

Process Adoption Process Like UML, SPEM only defines a language for how to describe software processes It does not prescribe any particular process or method for assembling the model Also does not provide guidance on model organization and tool support In the Rapid Iterative Process (RIP), there is a separate process adoption discipline that addresses much of this Also separate process enactment and process audit disciplines

SPEM UML diagrams Process component dependency diagram Discipline workflow diagram Work definition workflow diagram Process role activity diagram Process role work product diagram Work product relationship diagram Work product state diagram

Process Component Dependency Diagram «discipline» Object-Oriented Analysis Discipline «import» «import» «discipline» «discipline» Architecture Discipline Requirements Discipline

Discipline Workflow Diagram Shows general ordering of high-level work definitions for single discipline One discipline usually should between three and six work definitions Show “major” input and output work products and states work definition decision with guard output work product (in this case, same instance but in different state) input work product

Work Definition Workflow Diagram Analyze Use Case Behavior Shows general ordering of activities that compose a more coarse-grained work definition Usually more and finer-grained work products shown as inputs and outputs One work definition workflow diagram per work definition Coarse-grained input and output work products should be consistent with discipline workflow diagram activity

Process Roles and Activities Diagram Shows roles in discipline and which activities are responsibility of each role System Analyst Leader of all analysis activities for the project Use Case Analyst Develops the piece of the analysis model associated with one or many use cases

Process Roles and Work Products Diagram Assisted Work Products analysis class analysis event flow assists with assists with responsible for «UML transition» responsible for system analyst entity state change responsible for analysis model responsible for «report» analysis realization report responsible for responsible for «UML state» responsible for entity state responsible for analysis realization «UML package» «UML statechart diagram» Responsible analysis pattern analysis package entity event model Work Products

Work Product Dependency Diagram Shows work products in discipline and their relationships Can be supplemented with additional diagrams to establish traceability between work products in different disciplines

Work Product State Diagram Analysis Class Create a statechart diagram to show the different states of a work product Not all work products may have more than one state Textually describe what it means for the work product to be at each state Usually do not put additional notation on this diagram Use activity diagrams to show how work product changes its state throughout the process identified described outlined

Process Model Organization – Discipline Process model organized into discipline packages Each discipline has three sub-packages Guidances Roles Work products Single class diagram showing component dependencies Single activity graph for workflow model

Process Model Organization – Workflow Workflow activity graph has a single activity diagram for overall discipline Create UML activity for each work definition and place on discipline workflow diagram Describe details of work definition using a nested activity diagram that shows each SPEM activity for the work definition

Process Model Organization – Roles Create a separate class for each role in the Roles package Create a class diagram for role activities inside the class Create a class diagram for role work products inside the class Create operations on role class for SPEM activities Can optionally define operation parameters (input/output work products)

Process Model Organization – Work Products Create package for work product guidance diagrams Create one or many class diagrams to show which guidances are related to which work products Create package for work product dependency diagrams Create one or many class diagrams to show relationships between work products Create class for each work product Optionally define state models

Process Model Organization – Guidances Create sub-packages for each guidance type Checklists Examples Guidelines Templates Create class diagram to show each guidance type Create classes for each guidance

Process Adoption Discipline – Workflow Start with aligning the process engineering environment with business objectives Identify the key process elements (activities, work products, and workflows) Refine the process model with input/output work product states, identify roles and assign activities and work products, identify guidances Develop textual content of process model Manage and organize process components <<work definition>> align process environment <<work definition>> design process <<work definition>> refine process design <<work definition>> develop process content <<work definition>> manage process model

Design Process – Work Definition Workflow organization : process Identify the activities for the discipline to be designed Group activities and identify work definitions Model discipline workflow Identify output work products Model outlined work definition workflow assessment identify discipline : process : discipline library [identified] identify activities : discipline workflow discipline : process diagram assessment [outlined] identify work definition : work definition : activity [identified] [identified] assign activities to work definitions : work definition [described] : activity : work identify output product [described] work products [identified] : work definition diagram [outlined] : discipline model workflow [identified] : activity : work definition [identified] [outlined]

Conclusions SPEM 1.0 provided opportunity to demonstrate proof-of-concept SPEM 2.0 will address shortcomings UML suitable for process modeling SPEM provides significant depth to define precise process models suitable for most development organizations SPEM process modeling tools are important Need to define tool usage guidelines Must have a proven practical process for adoption

Thanks for your attention and participation! Q&A Thanks for your attention and participation!