MTAT.03.243 Software Engineering Management · ISO 12207: Standard for Information Technology-Software Life Cycle Processes •This standard officially replaced MIL-STD-498 for the

MTAT.03.243 / Lecture 04 / © Dietmar Pfahl 2015

MTAT.03.243

Software Engineering Management

Lecture 04:

Principles of Software

Process Modeling (Part B)

Dietmar Pfahl

email: [email protected] Spring 2015


Structure of Lecture 04

• Project

• Prescriptive Process Modelling

• Exercise 2

• Descriptive Process Modelling

• Process Modelling Languages and Tools


Project – Task

• Prepare a (realistic) software process improvement plan for a software/systems development organization

• The scope of the SPI plan could be (examples):

– complete process

– a sub-process of the complete process

– an activity of a sub-process

– a method/technique used in an activity

– …


Project – Topic Ideas

Examples of problems and related improvement goals:

Customers find too many defects – Improve software quality

Inaccurate planning / estimates – Improve planning methods/models

New technologies or standards make their way into the market (e.g., MDD, TDD, BDD, test

automation, cloud computing, green IT) – Adapt existing processes to accommodate the new

technology/standard

Software is hard to maintain / difficult to evolve – Improve software architecture and associated

processes

Increasing competition – Speed-up development, issue releases more frequently

Customer are dissatisfied with deliveries – More customer participation and more flexible process

“Old-fashioned", heavy development process – Modernize dev. processes, methods, and tools

Little diffusion of competence, low motivation – Improve training & enhance involvement of people

FIND A REALISTIC APPROACH TO SOLVING A REALISTIC PROBLEM.

MAKE USE Of YOUR KNOWLEDGE AND IMAGINATION.


Project – General Information

Some lecture time will be devoted to reflection about the project (report).

The system/software development organization may be real or fictitious.

Suggested improvement actions must be clearly related to identified

problems and defined goals.

You might contact a software development organization in order to

find a real-world problem/challenge/issue.

Note: It is not necessary to mention the organization’s name.

NB: If you happen to find (or even be involved in) a real-world

improvement project, you should not make yourself completely

dependent on the reality, because a real-world project might have a

longer time-frame than our course.


Project Report – Structure

(24 marks)

• Cover page (Title, Author, Date, Email, Course ID, ...)

• Table of content

• Content:

– Improvement context (Type of company, product, process)

– Improvement Goal(s) (What? How much? When?)

– Suggested changes of SW development process (What? / Scope,

Old process New process)

– Implementation of process changes (When? Who is responsible?)

– Monitoring/Control (How to measure success? By whom?)

– Discussion (Why? Improvement methods applied, rationale for

changes, risks)

• References

Template & Examples available


Short Presentation – At Start

(3 marks)

• Time: 3-5 min

• Purpose: To get approval and to share with others in class

• Content:








changes, risks)


Full Presentation – At End

(8 marks)

• Time: 12-15 min

• Purpose: To present the improvement plan

• Content:








changes, risks)


Project – Schedule and Delivery

• Short Presentation (3-5 min)

– Submit slides as PDF at the latest 24 hours before

presentation via submission button on course web

– Presentation dates: 25.03. (and 30.03. if needed)

• Project Presentation (12-15 min)

– Submit slides as PDF at the latest 24 hours before

presentation via submission button on course web

– Presentation dates: 11.05., 13.05. (and 18.05. if needed)

• Project Report

– Submit report as PDF via submission button on course web

– Submission deadline: Thursday, 7 May, at 20:00 (sharp!)


Project – First Steps

For you to do:

– Decide whether you want to work alone or in pairs

– Let me know what you decided within next two weeks, at

the latest during lecture 7 (March 16)

– Decide on topic

– Prepare short presentation (March 25)



• Project


• Exercise 2




Prescriptive Process Models

How is it done?

How should it be done?


Relationship between

Descriptive and Prescriptive Process Modeling


Abstraction

Levels of

Prescriptive

Process Models

Pre-defined process

models like Scrum, EVO,

RUP, XP, Cleanroom...

Organizational

Process model

Project (type) 1

process model Project (type) 2

process model

Project (type) n

process model

Inspires

Process models exist on

3 levels:

family/standard level,

organizational level,

and project level


Process Families, Standards and De-facto

Standards

Process

Models

Life Cycle

Models

Engineering Process Models

Technical Process Models

Managerial Process Models

Process Engineering

Proc. Models

Process Maturity Models

RUP

XP

Scrum

Kanban Lean

V-Model XT

IEEE 1074

Waterfall

Prototyping

Spiral

Incremental

ISO 12207

CMMI

SPICE

Life Cycle Models

describe (classes of)

activities of development

processes at a high level

of abstraction


Process Families

Process

Models

Life Cycle

Models




Process Engineering

Proc. Models


RUP

XP

Scrum

Kanban Lean

V-Model XT

IEEE 1074

Waterfall

Prototyping

Spiral

Incremental

ISO 12207

CMMI

SPICE

Life Cycle Models




of abstraction


Waterfall: Royce Model (1970)

SYSTEM

REQUIREMENTS

TESTING

CODING

PROGRAM

DESIGN

ANALYSIS

PRELIMINARY

PROGRAM

DESIGN

SOFTWARE

REQUIREMENTS

OPERATIONS

PRELIMINARY

DESIGN

ANALYSIS

PROGRAM

DESIGN

CODING

TESTING

USAGE

Idea:

Sequential creation of

products on different

levels of abstraction (e.g.,

precede code by design,

precede design by

requirements) and

integration in reverse

direction

Strictly sequential control

flow can be weakened by

controlled iterations

Prerequisites: Familiarity with

application domains,

methods, techniques,

tools, engineering

processes

Good understanding of

the requirements

Stable requirements

High capabilities for

effort estimation


Prototyping

‘An iterative process of creating quickly and inexpensively live

and working models to test out requirements and

assumptions’

(Sprague and McNurlin)

• Main types:

– ‘throw away’ prototypes

– evolutionary prototypes

• What is being prototyped?

– human-computer interface

– functionality

Prerequisites:

- Experience with development

technology

- Availability of technical infrastructure

(e.g., HW) for evaluation

Challenges:

- Risk that non-functional

requirements are not sufficiently well

explored


Boehm’s Spiral Model

Project

Start

The spiral model proposed by

Boehm (1988) is an iterative

model with focus on risk

resolution:

• Determine objectives and constraints

• Evaluate alternatives

• Identify risks

• Resolve risks after assigning priorities

to risks

• Develop a series of prototypes for the

identified risks starting with the highest

risk

• Use a waterfall model for each

prototype development (“cycle”)

• If a risk has successfully been

resolved, evaluate the results of the

“cycle” and plan the next round

• If a certain risk cannot be resolved,

terminate the project immediately


Iterative Enhancement (Incremental Delivery)

• Origin: Basili und Turner, 1975

• Idea:

– Split functionality into several increments

– Develop each increment (i.e., a product part that fulfills a subset of

requirements) in a Waterfall style; integrate increment by increment into

the product until delivery (release)

– The focus of the development of an increment might be completion of

functionality or structure, but it can also be refinement and improvement

– Strictly sequential control flow can be weakened by controlled iterations

• Prerequisites:

– Structure of the problem permits incremental development


Incremental delivery

design build install evaluate



increment 1

increment 2

increment 3

first incremental delivery

second incremental delivery

third incremental delivery

delivered

system

Requirements


Iterative Enhancement (Incremental Delivery)

Advantages:

• Efficient learning during the project; thus, experience level can be low

• Early availability of a product, with the essential properties of the final product.

• Allows for early customer involvement and feedback

• Applicable when parts of requirements are (still) unclear or unstable

• Supports integration testing

• Good applicability in case of fixed delivery dates (-> prioritize requirements with the customer)

Disadvantages:

• Risk that, by ignoring specific

requirements, the product will be

designed in such a way that fulfilling

future requirements becomes

difficult/expensive

– particularly problematic are

non-functional requirements

• Comprehensive version and

configuration management is

necessary


Process Standards

Process

Models

Life Cycle

Models




Process Engineering

Proc. Models


RUP

XP

Scrum

Kanban Lean

V-Model XT

IEEE 1074

Waterfall

Prototyping

Spiral

Incremental

ISO 12207

CMMI

SPICE

Life Cycle Models




of abstraction


ISO 12207: Standard for Information

Technology-Software Life Cycle Processes

• This standard officially replaced MIL-STD-498 for the development of DoD software systems in August 1998

• This standard defines a comprehensive set of processes that cover the entire life-cycle of a software system – from the time a concept is made to the retirement of the software

• The standard defines a set of processes, which are in turn defined in terms of activities. The activities are broken down into a set of tasks.

• The processes are defined in three broad categories:

– Primary Life Cycle Processes

– Supporting Life Cycle Processes

– Organisational Life Cycle Processes

http://en.wikipedia.org/wiki/MIL-STD-498





http://en.wikipedia.org/wiki/United_States_Department_of_Defense

http://en.wikipedia.org/wiki/Software_system


ISO 12207 Processes

• Primary life cycle

processes:

– Acquisition

process

– Supply process

– Development

process

– Operation

process

– Maintenance

process

• Organisational

processes:

– Management

process

– Infrastructure

process

– Improvement

process

– Training process

• Supporting life cycle

processes:

– Audit process

– Configuration

Management

– Joint review process

– Documentation process

– Quality assurance process

– Problem solving process

– Verification process

– Validation process


ISO 12207:

Development

Processes


IEEE Std 1074

• Standard for developing software life cycle processes (first

published in 1997)

• Directed primarily at the process engineer (called ‘architect’ in

the standard)

• Defines a process for creating a software life cycle process

(SLCP) in three steps:

– Select a (generic) software life cycle model (SLCM) to be used in

projects

– Define details based on selected SLCM and associated reference

activities

– Augment SLCM with Organizational Process Assets (OPAs) to

create the desired SLCP


IEEE Std 1074: Generic Software Lifecycle


Process De-facto Standards

Process

Models

Life Cycle

Models




Process Engineering

Proc. Models


RUP

XP

Scrum

Kanban Lean

V-Model XT

IEEE 1074

Waterfall

Prototyping

Spiral

Incremental

ISO 12207

CMMI

SPICE

Life Cycle Models




of abstraction


Rational Unified Process (RUP)

• Published by Jacobson, Booch,

and Rumbaugh in 1998 (UP)

• Refined by Kruchten (UP > RUP)

• A generic process framework for

software development

• Consists of generic description of

phases and activities that must

be adapted for different types of

organisations, application

domains, competence levels and

project sizes

• Component-based: system is

constructed from components

interconnected via interfaces

• Use-case-driven: focuses on the end

user during design, implementation,

test

• Architecture-centric: embodying the

most significant static and dynamic

aspects of the system (4+1)

• Iterative and incremental: divides

project into iterations, each iteration

resulting in an increment that is

added to the system


Rational

Unified

Process

(RUP)

Inception: creates a vision and business case for the final system

Elaboration: specifies system’s use cases and defines architecture

Construction: builds the system, evolves the architecture

Transition: system testing and debugging


RUP – Static Process

Static Structure of the Process

• A process defines who is doing

what, how, and when.

• The RUP is represented using

four primary modeling elements:

– Workers (Roles), the "who"

– Activities, the "how"

– Artifacts, the "what"

– Workflows, the "when"

Activities, Artifacts, and Workers


RUP – Resources and Workers (Roles)

• A worker defines the behavior and responsibilities of an individual, or a group of individuals working together as a team.

• You could regard a worker as a "hat" an individual can wear in the project.

• One individual may wear many different hats.

• The responsibilities we assign to a worker include both to perform a certain set of activities as well as being owner of a set of artifacts.


RUP Workflow – Example: Analysis & Design

Workflows • A workflow is a sequence of activities that produces a result of observable value.

• In UML terms, a workflow can be expressed as a sequence diagram, a collaboration diagram, or an activity diagram.


V-Modell® XT (XT = Extreme Tailoring)

• Published in January 2005

• Predecessor: V-Model (1997) for military authorities in Germany

• Structured in a modular way

• Mandatory for IT projects in public and military domains in Germany

• Goals:

– Enhance support for adaptability, scaleability, changeability, and

expandability of V-Model 97

– Consider state of the art and adapt to current regulations and

standards

– Expand application range considering the complete system lifecycle

of development projects

– Introduce a process of organizational process improvement

Somewhat

comparable to

the role of

PS 2000 in

Norway


V-Modell® XT: Model Elements


V-Modell® XT: The Big Picture

The German V-Model comprises

four sub-models:

System Development (SD)

Quality Assurance (QA)

Configuration Management (CM)

Project Management (PM)


V-Modell® XT

System

Development (SD)

Sub-Model

SD 2


V-Modell® XT:

System

Development (SD)

Sub-Model

SD2:

System

Design

“Handling”

(Refinement)


V-Modell® XT:

System

Development (SD)

Sub-Model

SD2:

System

Design


V-Modell® XT: The Big Picture

The German V-Model comprises

four sub-models:

System Development (SD)

Quality Assurance (QA)

Configuration Management (CM)

Project Management (PM)


V-Modell® XT:

Project

Management (PM)

Sub-Model

Activity Types:

• Management-related

– Initialization/Finalization

– Periodically Required

• Placement/Procurement-related

• Planning-related

• Resource-related


The Role Concept

• Role

– A role is in charge of one or

more activities defined in one

or more processes

– A role has defined

competences &

responsibilities

– Possible relationships

between agents and roles

1 : 1

1 : m

n : 1

n : m M

od

ule

de

ve

lop

er

Mo

de

rato

r

Qu

ali

ty

as

su

rer

Te

ste

r

Module

design

Module

coding

Module

review

Module

testing

Roles

Activities

R = Responsible

A = Approve

S = Support

C = Consult

I = Inform

R

R

R

A

I

S S, R

RASCI Matrix

Examples of Role – Activity Relations



• Project


• Exercise 2




Exercise 2

• Task:

– Read the textual description of the process of surveying

“Customer Satisfaction” using the Kano-Model

– Form a pair with a student sitting next to you and create a

process model of the process of surveying “Customer

Satisfaction” using the Kano-Model, i.e.

• Identify activities, artifacts, roles, tools/techniques/methods,

and the relations between these entities

• Use either the graphical or the table notation shown on the

next slide

– Give the resulting model to the course instructor

Handout


Exercise 2 (cont’d)

Process Model representations:

• Using product-flow notation

• Using table notation

Activity Artifact Role

Method / Tool

Implement

Design

Code

Programmer

Java Development Environment

uses

uses consumes

produces


The Kano-Model

Five dimensions of quality:

• ”Basic quality” – satisfies basic “must-

have” needs which probably do not

even need to be specified.

• ”Competitive quality” - satisfies

expressed needs (usually in

requirement specification).

• ”Excitement quality” - satisfies latent

needs, needs which are there but which

the user hasn’t expressed and/or is

himself/herself aware of

--

• ”Indifference quality” - needs which are

covered but which user is indifferent to

• ”Reverse quality” - qualities which the

customer do not want

Customer

Satisfaction

Performance

high

high

Excitement

(Differentiation)

Linear

(Competitive)

Basic

(Cost of Entry)


The Kano-Model – Surveying Customers

• To assess whether a feature is basic, linear, or exciting we can:

– Sometimes guess

– Survey a small set of users (20-30)

• We ask two questions:

– A functional question:

How do you feel if a feature is present?

– A dysfunctional question:

How do you feel if that feature is absent?


Functional and Dysfunctional Questions

If your editor

includes a

voice recognition

function, how do

you feel?

I like it that way X

I expect it to be that way

I am neutral

I can live with it that way

I dislike it that way

If your editor

does not include a

voice recognition

function, how do

you feel?

Functional form

of question

Dysfunctional form

of question

I like it that way

I expect it to be that way X

I am neutral

I can live with it that way

I dislike it that way


Categorizing Requirement via Answer Pair

B: Basic (Mandatory)

L: Linear

E: Excitement

R: Reverse

I: Indifferent

Q: Questionable

Like

Expect

Neutral

Live with

Dislike

Q

R

R

R

R

E

I

R

I

I

E

I

R

I

I

E

I

R

I

I

L

B

Q

B

B

Dysfunctional

Question


Solution Example: Kano-Model Process

• Artifacts:

– (At1) List of all customers

– (At2) List of selected customers

– (At3) List of requirements

– (At4) Answers from customers

– (At5) Categorized requirements

• Roles:

– (R1) Marketing

– (R2) Customers

• Activities:

– (Ac1) Select Customers

for Interviews

– (Ac2) Ask functional &

dysfunctional questions

per requirement

• Methods/Techniques/Tools:

– (MTT1) Categorization

scheme

– (MTT2) Interview

Textual process description

../Exercise-2015/L03_2014-Exercise02-v1-process-marked.pdf


Solution Example:

Kano-Model Process

Ask functional and dysfunctional questions

per requ.

List of selected Customers

Answers from Customers

Marketing, Customers

Categorisation Scheme, Interview

Categorised Requirements

Select Customers for Interviews

List of all Customers

Marketing

List of Requirements

Caution: This is only an example solution – it is not necessarily ’correct’!


8 Student

Solutions


2015: 8 Student Solutions

Number of ...

• Activities: 1 (1x) 2 (2x), 3 (4x), 4 (1x) – range: 1-4 / median: 3

• Artifacts: 2 (1x) 3 (2x), 4 (3x), 5 (1x) 6 (1x) – range: 2-6 / median: 4

• Roles: 1 (3x), 2 (3x), 3 (2x) – range: 1-3 / median: 2

• MMT: 0 (1x), 1 (2x), 2 (3x), 3 (2x) – range: 0-3 / median: 2

Entities that were always mentioned (conceptually – not literally):

• Activities: -

• Artifacts: -

• Roles: -

• MMT: - !


In 2014: 7 Student Solutions

Number of ...

• Activities: 2 (2x), 3 (3x), 4 (2x) – range: 2-4 / median: 3

• Artifacts: 3 (1x), 4 (3x), 5 (3x) – range: 3-5 / median: 4

• Roles: 1 (2x), 2 (4x), 3 (1x) – range: 1-3 / median: 2

• MMT: 0 (1x), 1 (2x), 2 (2x), 3 (2x) – range: 0-3 / median: 2


• Activities: Interview (or similar)

• Artifacts: -

• Roles: Marketing (Mgr., Dept., Dept. Employee)

• MMT: - !


In 2013: 10 Student Solutions

Number of ...

• Activities: 3 (3x), 4 (5x), 5 (1x), 6 (1x) – range: 3-6 / median: 4

• Artifacts: 4 (1x), 5 (4x), 6 (3x), 7 (2x) – range: 4-7 / median: 5.5 (mode: 5)

• Roles: 0 (1x), 2 (3x), 3 (2x), 4 (4x) – range: 0-4 / median: 3 (mode: 4)

• MMT: 0 (1x), 2 (2x), 3 (5x), 4 (1x), 7 (1x) – range: 0-7 / median: 3


• Activities: -

• Artifacts: -

• Roles: -

• MMT: - !


Your Solutions (1): Kano-Model Process

Marketing?

Not good names (too generic)

Name of technique?

Requirements?



Not a proper product-flow !!! Not good names (too generic) Are ’Questions’ really products?

Requirements?



Products? Customer representatives == List of chosen representatives ??

Roles?

Requirements?



?

Technique ?




Same?

Marketing? Requirements?



Requirements?

?


Artifact or Role?



?

Kano?

Requirements?





?

Same?

Same?


Lessons Learnt

• 8 solutions -> less overlap than in

2014 / same as 2013

– Lesson: Feedback from process

agents is essential (but wasn’t

available in our exercise)

• Notation (Table vs. Diagram):

– Diagram easier to read / easier

to check by humans

– Table more compact

– BUT: Beware that table notation

might become even more

difficult to read in the presence

of activity and artifact

hierarchies

• Sometimes, entities not mentioned in

the textual description were modeled:

– Lesson: In a descriptive model,

don’t speculate – stick to what you

observe/hear/read – listen carefully

• Artifacts never produced or never

consumed:

– Lesson: This can be ok (at the

model boundaries) but otherwise

suggests an incomplete/incorrect

model

• Activities directly connected:

– Lesson: Incomplete product-flow –

suggests an incomplete/incorrect

model

• Difficulty distinguishing product (artifact)

and tool (and sometimes activity)

– Lesson: No easy answer available



• Project


• Exercise 2




Descriptive Process Models

How is it done?

How should it be done?


Goals of Descriptive Process Modeling

• Understand the process

– Explicit documentation

– Analyses (consistency, completeness, complexity)

• Communicate (about) the process

– Find agreement in case of conflicting opinions

– Propagation of ‘Best Practices’

• Support measurement

– Describe, who can measure what and when

– Collect quantitative information about processes, products and resources

• Manage the process (and products)

– Define goals (target values) and control the adherence to these goals.


Steps of Descriptive Process Modeling

1. Formulate goals and scope of the task

2. Choose a conceptual schema (meta-model)

3. Choose a process modeling language / notation

4. Select or adapt tools

5. “Elicitation”

6. Create process model

7. Analyze process model

8. Analyze process Information Information

Process

model

Role 1 Role n

SPEM* UML, BPMN, ... Bizagi, Spearmint, ARIS,...

*SPEM = Software & Systems Process Engineering Meta-model


How to do it?

• Structured interview, 1-2

Hours

• 2 interviewers

• Separated by roles

– no large groups

– clear focus

– manageable process

models

– no mutual interaction

(horizontal and vertical

hierarchic relations)

• Perform interviews one after

another, however not more

than 3 interviews per day

Information Information

Process

model

Role 1 Role n

Process Elicitation


Scope

Project

Activity Name

Integration-Test (Target)

Responsibility

PL

Input Products

- TSPA - Customer Data (by Customer Data Delta) - APS - Conformance Test Cases - Regression Test Cases

Entry Criteria

- Possibly Integration Test (Host) - Input complete - Hardware available - APS and Customer Data loaded - Test time available

Activity Description

- Conduct Integration Test on target according to TSPA Case A: Old Features (upgrade):

- Regression Test (Tool: A8619 (PORIS) for SSW / USR for ASW) - Possibly, update of TSPA Test Cases

Case B: New Features: - Manually co nducted TSPA Test Cases - Recorded with A8619 (Poris) for SSW / USR for ASW

- Conduct Conformance Test according to Standards with test tool K1197 - Defect correction

Output Products

- Test Protocol (Part of TSPA) - Regression Test Cases (updated)

Exit Criteria

- Feature runs correctly on host - No more test time available (Rem. by QM: this

criterium is not permitted!!)

Resources

- Developers - Support team of TK Systems etc. - A8619 (PORIS) - USR für ASW - K1197 - TK Systems - CSTA Test tool - CSTA-Spy

Project, process name,

role (responsible for this process/activity)

Input products and

entry conditions

Output products

and exit conditions

Description of the process/activity

Resources: additional roles,

methods/techniques/tools

Example Form for Structured Interview


Rules for Process Elicitation – Interview

• Opening of Interview

– Summary

– Explain goal and purpose

– Stress confidentiality

– General questions about the process, and existence of variants

• Main part of Interview

– Behave neutral

– At first ask about the products

– Then ask about processes

– What are typical (known) deviations from the prescribed processes?

– Which other roles participate in the processes? (Cross-Check)

– Always be precise

– Try to identify process variants


Rules for Process Elicitation – Interview

• Closing of Interview

– Explain future steps

– Agree on time for the review

– Thank your interview partner

• Ask questions even when a noticed ambiguity seems to be small, often big problems are hidden behind it

• Don't try to solve all ambiguities and conflicts (during the interview) – but follow-up on observed inconsistencies afterwards

• After the interview: give a quick feedback to the interview-partner about what you did with his/her information


Example:

Process Analysis

process

30 Processes

66 Products

42 Resources

• The number of products is higher (approx. twice as high) than the number of processes.

• The complexity of product flow interfaces of processes is relatively high (most of the processes access more then a dozen of products).

• Most of processes are undertaken by several roles (partly over five roles).

• Most of roles are involved in execution of more then a third of the whole process.



• Project


• Exercise 2




Modeling Languages (suitable for PM)

• Flowchart is a schematic representation of an algorithm or a stepwise process,

• IDEF is a family of modeling languages, the most notable of which include IDEF0 for functional modeling, IDEF1X for information modeling, and IDEF5 for modeling ontologies.

• Business Process Modeling Notation (BPMN, and the XML form BPML) is an example of a Process Modeling language.

• Extended Enterprise Modeling Language (EEML) is commonly used for business process modeling across a number of layers.

• Unified Modeling Language (UML) is a general modeling language to describe software both structurally and behaviorally. It has a graphical notation and allows for extension with a Profile (UML).

http://en.wikipedia.org/wiki/Flowchart

http://en.wikipedia.org/wiki/IDEF

http://en.wikipedia.org/wiki/IDEF0

http://en.wikipedia.org/wiki/IDEF1X

http://en.wikipedia.org/wiki/IDEF5

http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation

http://en.wikipedia.org/wiki/XML

http://en.wikipedia.org/wiki/Process_Modeling

http://en.wikipedia.org/wiki/Extended_Enterprise_Modeling_Language

http://en.wikipedia.org/wiki/Unified_Modeling_Language

http://en.wikipedia.org/wiki/Profile_(UML)


Process Modeling Tools

• Commercial tools not dedicated to

process modeling

– E.g., UML tools, ABC Flowcharter,

Microsoft Visio, Statemate

• Workflow Management Systems

– E.g., ARIS Toolset (event-driven

process chains, EPC)

• Open Source:

– Bizagi Process Modeler

– Eclipse Process Framework (EPF)

• Research prototypes

– E.g., Spearmint EPF Wiki

EPC Example

http://www.bizagi.com/index.php/products/bizagi-process-modeler

http://www.eclipse.org/epf/

http://epf.eclipse.org/


Process Modeling Tools

• Commercial tools not dedicated to

process modeling

– E.g., UML tools, ABC Flowcharter,

Microsoft Visio, Statemate

• Workflow Management Systems

– E.g., ARIS Toolset (event-driven

process chains, EPC)

• Open Source:

– Bizagi Process Modeler

– Eclipse Process Framework (EPF)

• Research prototypes

– E.g., Spearmint EPF Wiki

BPMN Example

http://www.bizagi.com/index.php/products/bizagi-process-modeler

http://www.eclipse.org/epf/

http://epf.eclipse.org/


Example SPM Tool SpearmintTM

• SPEARMINTTM

– Software Process Elicitation, Analysis,

Review, and Management in an inTegrated Environment

• Assists a process engineer in creating and maintaining complex

process models.

• Allows for efficient modeling of different views of the process

model

• Generates EPG (Electronic Process Guide)

Demo version available on course web: Spearmint Tool


Views


Entire Process Model


Views

Spearmint supports efficient modeling by supporting different views

• A view is a part of the process model

– Spearmint describes not the whole process, but only parts of it in pre-defined and

user-defined views.

• A view highlights certain aspects

– Working with views reduces the complexity of the process model.

– Only those aspects of a model are contained, which are relevant for specific tasks.

• SPEARMINT checks consistency of all views

– Process elements in a certain view always reference to the whole process model.

Entire processmodel

viewview

view

view

view


Views

Artifacts view

Activities view

Process view

Properties and Attributes views


Product-Flow View

Refinement


Process View


Attributes View


Generation of Hypertext View (EPG)

Feedback, e.g. via

annotations


Hypertext-View (EPG)


Annotations


Consistency Checking

• Process models should be complete and correct

representations of reality

• Consistency checking has been partly automated in

SPEARMINTTM

• Methodological prerequisites:

– Process meta-model

– Consistency rules


Next Lecture

• Topic: Agile Principles and Processes – Part A

• For you to do:

– Have a look at the Bizagi and SPEARMINT

tools (cf. course web for more info)

Documents

MTAT.03.243 Software Engineering Management · ISO 12207: Standard for Information Technology-Software Life Cycle Processes •This standard officially replaced MIL-STD-498 for the