MTAT.03.243 Software Engineering ManagementThus cookbook recipes are process descriptions while the...

MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014

MTAT.03.243

Software Engineering Management

Lecture 03:

Principles of Software

Process Modeling (Part A)

& Rich Processes Dietmar Pfahl

email: [email protected] Spring 2014


Structure of Lecture 03

• Introduction to Process Modelling

• Exercise 2

• Prescriptive Process Models


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 a precise and

concise descriptions of the processes holding the required information!


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


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

activities

– Improving real 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


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)




• 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




• Exercise 2



Prescriptive Process Models

How is it done?

How should it be done?


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




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




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


Next Lecture

• Topic: Principles of Process Modeling (Part B) & Tools

• For you to do:

– Finish Homework 1 (if not yet done): deadline is today

at 17:00 (sharp!)

– 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 ManagementThus cookbook recipes are process descriptions while the...

Documents

Transcript of MTAT.03.243 Software Engineering ManagementThus cookbook recipes are process descriptions while the...