MTAT.03.243 Software Engineering Management - Kursused · MTAT.03.243 / Lecture 03 / © Dietmar...

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: [email protected] Spring 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


Structure of Lecture 03

• Introduction to Process Modelling

• Exercise 2


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


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.


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?

• ...


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)


‘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’


Questions

1. What’s the difference between

’Process’ and ’Process Model’?

2. Is it possible to have no process

in place?


’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’


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


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


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:


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


Process Model Notation (Graphical)


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


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)


Typical Contents

of Process Model

Representations


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


Descriptive vs. Prescriptive Process Models

How is it done?

How should it be done?


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


Relationship between

Descriptive and Prescriptive Process Modeling


The Four

Domains

Principle

[Source: Heidrich, Münch, Verlage:

Process Modeling, Lecture at Uni KL,

Summer 2012, Chapter 1]

(Model)


Structure of Lecture 03

• Introduction to Process Modelling

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


Next Lecture

• Topic: Principles of Process Modeling (Part B)

• For you to do:

– Send me the result of Exercise 2 (if not yet done) as

soon as possible

– Read Project Description (cf. course wiki)

MTAT.03.243 Software Engineering Management - Kursused · MTAT.03.243 / Lecture 03 / © Dietmar...

Documents

Transcript of MTAT.03.243 Software Engineering Management - Kursused · MTAT.03.243 / Lecture 03 / © Dietmar...