mtat.03.243 software engineering managementthus cookbook recipes are process descriptions while the...
Post on 22-May-2020
4 Views
Preview:
TRANSCRIPT
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: dietmar.pfahl@ut.ee Spring 2014
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
Structure of Lecture 03
• Introduction to Process Modelling
• Exercise 2
• Prescriptive Process Models
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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 2014
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 2014
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 2014
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!
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
’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 2014
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 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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 2014
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 2014
Process Model Notation (Graphical)
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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 2014
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 2014
Typical Contents
of Process Model
Representations
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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 2014
Descriptive vs. Prescriptive Process Models
How is it done?
How should it be done?
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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 2014
Relationship between
Descriptive and Prescriptive Process Modeling
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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 2014
Structure of Lecture 03
• Introduction to Process Modelling
• Exercise 2
• Prescriptive Process Models
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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 2014
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 2014
Structure of Lecture 03
• Introduction to Process Modelling
• Exercise 2
• Prescriptive Process Models
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
Prescriptive Process Models
How is it done?
How should it be done?
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
Process Families
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
Incremental delivery
design build install evaluate
design build install evaluate
design build install evaluate
increment 1
increment 2
increment 3
first incremental delivery
second incremental delivery
third incremental delivery
delivered
system
Requirements
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
Process 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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
ISO 12207:
Development
Processes
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
IEEE Std 1074: Generic Software Lifecycle
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
Process 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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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.
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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.
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
V-Modell® XT: Model Elements
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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)
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
V-Modell® XT
System
Development (SD)
Sub-Model
SD 2
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
V-Modell® XT:
System
Development (SD)
Sub-Model
SD2:
System
Design
“Handling”
(Refinement)
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
V-Modell® XT:
System
Development (SD)
Sub-Model
SD2:
System
Design
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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)
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
V-Modell® XT:
Project
Management (PM)
Sub-Model
Activity Types:
• Management-related
– Initialization/Finalization
– Periodically Required
• Placement/Procurement-related
• Planning-related
• Resource-related
MTAT.03.243 / Lecture 03 / © Dietmar Pfahl 2014
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)
top related