View
242
Download
1
Category
Preview:
Citation preview
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
MTAT.03.243
Software Engineering Management
Lecture 03:
Principles of Software
Process Modeling (Part A)
Dietmar Pfahl
email: dietmar.pfahl@ut.ee Spring 2015
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
Announcements
• Full project description now available on course wiki:
- Short Presentations: Wednesday, 25 March
• Industry guest lecture on Monday, 23 March:
‘Increasing the predictability of software delivery with lean processes’ by
Marek Laasik (VP Engineering, Fortumo)
• Proposal for final exam dates:
- Exam 1: Wednesday, May 27, 14:15-16:00
- Exam 2: Monday, June 01, 12:15-14:00
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
Structure of Lecture 03
• Introduction to Process Modelling
• Exercise 2
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
What is a (Software Development) Process?
A Process …
• defines Who is doing What, When and How to reach a specific goal.
– In software engineering the goal is to build a software product or
to enhance an existing one
… and by the way …
An effective process … • facilitates efficient development of software with the required quality • reduces risk and increases predictability • promotes common vision and culture • …
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
Product Quality vs. Process Quality
• When software delivers incorrect results ...
... we do not modify the results but the
software that produces them.
• When a process delivers incorrect products ...
... then common practice is to (only) modify
the products, instead of the process.
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
Software Development Challenges
• Product quality poor – ... but what should we change to fix this?
– e.g., when/how do we introduce defects – and when/how should we find them?
• Deadlines missed – ... but where do we lose all that time?
– e.g., do we lose most time during requirements negotiation, or during testing?
(unit testing? system testing? regression testing?)
• Budget overruns – ... but what are the most expensive activities?
– e.g., are we spending most effort on coding or on rework/refactoring?
• Overhead – ... do we spend much effort on non-productive activities?
– e.g., how much effort is spent for collecting information (manually)?
• New employees – ... how should they learn how we work?
– e.g., through trial and error or by more efficient means?
• ...
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
Information Needs
• What information do we need to answer the questions on previous slide:
– Which activities are performed in which sequence?
– Which are the inputs and outputs of these activities?
– Who is involed in a specific activity?
– What techniques/tools should be used?
– How long does it (typically) take to complete an activity?
– ...
How can we gather and maintain this information?
• We can ask experienced professionals – or we need precise and concise
descriptions of the processes holding the required information!
Cf. Paper on Root-Cause-Analysis (on course wiki)
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
‘Perceived Causes of Software
Project Failures – An Analysis of
their Relationships’ by Timo O.A.
Lehtinen, Mika V. Mäntylä, Jari
Vanhanen, Juha Itkonen, Casper
Lassenius, Department of Computer
Science and Engineering, School of
Science, Aalto University
Causes and causal relationships in case ’Defect’
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
Questions
1. What’s the difference between
’Process’ and ’Process Model’?
2. Is it possible to have no process
in place?
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
’Process’ versus ’Process Description’
Lee Osterweil, ”Software are
Processes too” (ICSE 1986):
”While a process is a vehicle
doing a job, a process
description is a specification
of how the job is to be done.
Thus cookbook recipes are
process descriptions while the
carrying out of the recipes are
processes.”
A ’Process Model’ is a (semi-)
formal representation of a
’Process Description’
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
What are the Goals of Process Modeling?
• To enable effective understanding
and communication
– At one development site
(developers, teams, ...)
– Between development sites
(distributed development,
outsourcing, contractor-supplier
relations, ...)
• To support project management
– Transparency, tracking, ...
• To guide the developers
– Incorporating new employees
• To improve software development
practice
– Improving processes requires
measurement and measurement
requires defined processes
– Evolving processes
• To support reuse of process
knowledge
– Organsational learning
• To support automatic process
enactment
– Workflow support
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
Types of Process Models
Processes
Engineering Processes Non-Engineering Processes
Product-Engineering
Processes Process-Engineering
Processes Business
Processes Social
Processes
Development
Processes
Maintenance
Processes
Project Mgmt
Processes
Quality Mgmt
Processes
Conf Mgmt
Processes Product Line
Processes
Improvement
Processes
Process Modeling
Processes
Measurement
Processes
Process Taxonomy
Software
Knowledge
Process
Models
Product
Models
Quality
Models
Life Cycle
Models
Engineering Process Models
Business Process Models
Social Process Models
Technical Process Models
Managerial Process Models
Process Engineering
Proc. Models
. . .
. . .
Life Cycle Models
describe (classes of)
activities of development
processes at a high level
of abstraction
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
What is a (Software) Process Model?
• “Software Process Model: An abstract
software process description. It can be
more or less formal.” [Lonchamp 93]
• Key elements:
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
Characterization of Process Models
A Process Model defines:
• an identifiable activity or a group of activities or a hierarchy of activities
• the sequence/order of activities (-> control flow)
• the input/output products (artifacts) of activities (-> product flow)
• the resources (roles and tools/techniques/methods) needed
• the relations between activities, artifacts and resources
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
Definition: Process Performer, Owner, Engineer
• Process Performer or Agent (PA) :=
– Person/Agent who enacts/executes the process in order to achieve the process goal(s)
– Humans interpret process scripts, machines interpret process programs
– Process scripts and process programs are user-specific process descriptions
• Process Owner (PO) :=
– Person or organizational entity that sets the goals of a process and is responsible for its
achievement
– The PO provides resources for the enactment/execution of the process, but s/he is not
responsible for providing process definitions
• Process Engineer (PE) :=
– Person who has to fulfill one or several goals of process modeling (e.g., process
definition to guide developers)
– To that end, the PE uses process models, which s/he defines, extends, improves, and
manages
– The PE should pay attention to the accuracy of the model, i.e., the correspondence
between real-world process enactment/execution and process model
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
Example of a Process Script (textual representation)
Note:
Process descriptions for
humans can be
enhanced by graphical
representations and be
made accessible in the
form of:
• Handbooks,
• Electronic Process
Guides (web-guides
with hyperlinks) and
• Wikis.
(Excerpt taken from the ISPW-6 Software Process Example)
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
Descriptive vs. Prescriptive Process Models
How is it done?
How should it be done?
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
Prescriptive vs. Descriptive Process Models
• Prescriptive Models (theoretical)
– “Ideal” Process
– (Assumed) best practice
– Often requires instantiation
and detailing
– Deviations from real
processes are likely
– Examples: waterfall, V-
model, spiral model,
incremental, iterative,
evolutionary, agile process
models
• Descriptive Models (empirical)
– Accurate elicitation of actual,
real processes
– Basis for the revision of
existing (prescriptive)
process models based on
observation and experience
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
Relationship between
Descriptive and Prescriptive Process Modeling
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
The Four
Domains
Principle
[Source: Heidrich, Münch, Verlage:
Process Modeling, Lecture at Uni KL,
Summer 2012, Chapter 1]
(Model)
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
Structure of Lecture 03
• Introduction to Process Modelling
• Exercise 2
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2015
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)
Recommended