MTAT.03.243 Software Engineering Management...Software Engineering Management Lecture 19:...

MTAT.03.243 / Lecture 19 / © Dietmar Pfahl 2015

MTAT.03.243

Software Engineering Management

Lecture 19:

Organisational Learning /

Global Software

Development Dietmar Pfahl

email: [email protected] Spring 2015


Structure of Lecture 19

• Homework 4

• Project

• Organisational Learning

• Global Software Development


Homework 4 Assignment

• 3 Tasks

• 10 Points max

• Up to 2.5 Bonus

Points

• Could work in pairs

• Task 1 (3+1.5p):

– Value Stream Mapping

• Task 2 (4p):

– Assess the quality of article

A1 or A2 (pick only one!)

• Task 3 (3+1p):

– Produce 3 SPC charts


Homework 4 – Task 1 – Question 1


Homework 4 –

Task 1 –

Question 2

Q2 [1.4 marks]: With regards to the reporting of errors (better: failures) and the analysis of test results in activity ‘Test Execution and Reporting’:



See paragraph on ’Waste in sub-process area 10’ in Sub-

Section 6.1, page 21:


Homework 4 – Task 1 – Bonus Task


Homework 4 – Task 2

• 13 reviews received (12 could be used for summary analysis)

– 6 (5) for article 1

– 7 for article 2

• 4 reviews didn’t state what paper was analysed

– Could find out based on answers which paper was meant (in 1 case,

however, it was very difficult to do this due to the little and very

generic justifications provided)

• 1 review used the checklist incorrectly

– checked more than 1 answer option per question


HW4 – Task 2

Results A1

• Article A1: ‘Experimental

evaluation of an object-

oriented function point

measurement procedure’

by Silvia Abraha and

Geert Poels

• Received 5 (out of 12)

evaluations


HW4 – Task 2

Results A2

• Article A2: ‘A Controlled

Experiment to Assess the

Benefits of Procedure

Argument Type Checking’

by Lutz Prechelt and

Walter F. Tichy

• Received 7 (out of 12)

evaluations


HW4 – Task 2: Comparison of your results

regarding A1 with those of ’Experts’

Your data 3.6 3.4 4 3.4 4 3 3.8 4 3.2 32.2


Homework 4 – Task 3

• Apply Statistical Process Control (SPC) to defect data from a continuing

inspection/test process in an organization. The data is provided on the course

wiki (lecture 14).

• Use the data and construct the following charts:

– p-Chart

– c-Chart

– u-Chart

• Provide the charts and show how you calculated the plotted data, the control

line (CL), and the upper and lower control limits (UCL, LCL).

• Bonus point:

– You can get up to 1 Bonus Point, if you pick one of the three charts and

discuss whether there are any patterns that hint to some problem in the

process.


Task 3

– Data


Control Charts for Attributes

• p-Charts

– Controls ‘portion defective’ in a sample (usually, sample

size is constant)

• c-Charts

– Uses number of defects in an item (sample size = 1)

• u-Charts

– If data is collected for sample size >1 (e.g., using LOC of the code tested/inspected per day as sample), then the u-Chart should be used (allows for varying sample size n)


p-Chart

UCL = p + zp

LCL = p - zp

z = number of standard deviations from

process average

p = sample proportion defective; an

estimate of process average

p = standard deviation of sample

proportion

n = sample size

m = number of samples


p-Chart Example

20 samples of 100 newly developed code units

NUMBER OF PROPORTION

SAMPLE DEFECTIVES DEFECTIVE

1 6 .06

2 0 .00

3 4 .04

: : :

: : :

20 18 .18

200

Note: This example uses constant sample sizes n. There exist versions of the p-Chart for varying sample sizes.


p-Chart Example (cont.)

UCL = p + z = 0.10 + 3 p(1 - p)

n

0.10(1 - 0.10)

100

UCL = 0.190

LCL = 0.010

LCL = p - z = 0.10 - 3 p(1 - p)

n

0.10(1 - 0.10)

100

= 200 / (20*100) = 0.10 total defectives

total sample observations p =


Task 3

- P-Chart

p-value = defective/5


c-Chart

UCL = c + 3c

LCL = c - 3c

where

c = number of defects per sample (e.g., code tested per day)

c = c


c-Chart (cont.)

Number of defects in 15 days

1 12

2 8

3 16

: :

: : 15 15

190

SAMPLE

c = = 12.67 190

15

UCL = c + zc

= 12.67 + 3 12.67

= 23.35

LCL = c + zc

= 12.67 - 3 12.67

= 1.99

NUMBER

OF

DEFECTS


Task 3

- c-Chart

c-value = defects/day


c-Chart vs. u-Chart

UCL = c + 3c

LCL = c - 3c

where

c = number of defects per sample (e.g., code tested per day)

c = c

Note: If data is collected for sample size >1 (e.g., using LOC of the code tested/inspected per day as sample), then the u-Chart should be used (allows for varying sample size n). Plot/control defect density (d/n) instead of defects (d).

Ci

i

i

Note: Control limits change if sample sizes ni change.


Task 3

- u-Chart

u-value = defects/kloc


Detecting out-of-control situations

Source: Western Electric (1958)



• Homework 4

• Project




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


Project Consultancy – Deadlines

Doodle for

• Wednesday (06.05.) 13:00-16:00 – 9 slots

Deadlines:

• Project Report: Thursday (07.05.) at 20:00 (sharp!) - Penalties apply for

late submission!

• Project Presentation:

– Please check out course wiki for your presentation time slot

• Presentation Slides:

– Ideally, submit slides as PDF at the latest 24 hours before

presentation via submission button on course web


Project Presentation – Schedule

Date: Monday, 11 May

12:15-12:30 Team 01: Vitalii Peretiatko & Tatevik Ishikyan

12:30-12:45 Team 02: Ijlal Hussain & Khalil ur Rehman

12:45-13:00 Team 03a: Israel Cuautle & Anmol Gautam

13:00-13:15 Team 03b: Anastasiia Okhrimenko & Alena Ignatyeva

13:15-13:30 Team 04: Madhu Tipirishetty & Margus Sellin

15 min



Date: Wednesday, 13 May

14:15-14:30 Team 05: Triin Samuel & Sunday Ayandokun

14:30-14:45 Team 06: Gustav Amer

14:45-15:00 Team 07: Silver Samarütel & Siim Plangi

15:00-15:15 Team 08: Andres Randmaa & Andres Nirk

15:15-15:30 Team 09: Prashanth Parthiban & Veronika Prokopova

15 min



Date: Wednesday, 20 May

14:15-14:30 Team 10: Taleb Ayham & Kostiantyn Popov

14:30-14:45 Team 11: Henri Trees & Suido Valli

14:45-15:00 Team 12: Vinod John & Shubham Bharadwaj

15 min



• Homework 4

• Project




Terminology

• Data:

– Symbols organized according to syntactic rules (Syntax)

• Information:

– Data interpreted in a certain context (Semantics)

• Knowledge:

– Information, when related to the human mind in order to

solve problems; i.e., it is human expertise stored in a

person’s mind, gained through experience and interaction

with a person’s environment (Pragmatics)


A Layered Model of Knowledge Transfer

Source: Kurt Schneider, Univ. Hannover


Terminology

• Experience:

– The type of knowledge a person acquires by being involved;

observation + emotion (with respect to the observed event) + conclusion (derived from the observed event and emotion)

• Know-how:

– Procedural knowledge

• Skill:

– Talent and/or ability to perform a task (thus, knowledge is a prerequisite of skill)


Terminology

• Knowledge Worker:

– Knowledge workers contribute to company success mainly

by gathering, organizing, and applying knowledge

• Knowledge Management (KM):

– KM addresses the following tasks:

• Acquiring new knowledge

• Transforming it from tacit into explicit knowledge and back

again

• Systematically storing, disseminating, and evaluating it

• Treating it as an asset and its infrastructure as a resource

• Applying knowledge in new situations


Tacit (silent) versus Explicit Knowledge

• Tacit knowledge refers to knowledge that people use every day to

perform tasks but which they find hard to express or do not even know

about.

• Explicit knowledge is documented knowledge. Others may access and

reuse this knowledge.

Tacit knowledge

Explicit

knowledge

Externalizing

Internalizing

(Nonaka Model)

http://www.cyberartsweb.org/cpace/ht/thonglipfei/nonaka_seci.html

http://www.cyberartsweb.org/cpace/ht/thonglipfei/nonaka_seci.html


A Layered Model of Knowledge Transfer


Question: What are pre-requisites for knowledge reuse?


Pre-Requisites for Knowledge Re-Use

• Experience must be “cleaned” and validated

• Knowledge must be

– evaluated and organised ( structured and linked)

– transformed into readily usable material ( conclusions)

• Several pieces of experience and knowledge could be

– combined

– reworked (“engineered”)

– re-phrased ( guidelines, recommendations)


Levels of Learning

• Individual

• Group

• Organization

• (Society)



Approaches to Organisational Learning

• Organisations may have different approaches to learning:

– Develop own knowledge versus infusing extern knowledge

– Planned (formalized, tested) versus ad-hoc competence development

– Dedicated training courses versus "on-the-job-training"

– Evolutionary versus revolutionary approach

– Systematic versus ad-hoc experience transfer

– Focus on what is most important in the value chain vs. treating

everything as equally important

– Focus on the individual versus the group

– Focus on product versus process

– …


Approaches to Organisational Learning

• Organisations may have different approaches to learning:

– Develop own knowledge versus infusing extern knowledge

– Planned (formalized, tested) versus ad-hoc competence development

– Dedicated training courses versus "on-the-job-training"

– Evolutionary versus revolutionary approach

– Systematic versus ad-hoc experience transfer

– Focus on what is most important in the value chain vs. treating

everything as equally important

– Focus on the individual versus the group

– Focus on product versus process

– …

Experience Factory


The Core of any Systematic Approach to SPI:

PDCA Cycle

• PLAN what you want to accomplish

over a period of time and what you

might do, or need to do, to get there

• DO what you planned to do

• CHECK the results of what you did

to see if the objective was achieved

• ACT on the information –

standardize or plan for further

improvement [Deming, Sheward]


PROFES


Process Improvement Processes – QIP

QIP – Quality Improvement

Paradigm, Victor Basili,

University of Maryland


QIP – Focus on Learning

QIP – Also included: project

level and local feedback

meetings.

Learning on three levels!


Project Organization Experience Factory

1. Characterize 2. Set Goals 3. Choose Process

Execution plans

4. Execute Process

Project Support

5. Analyze

products, lessons learned, models

6. Package

Generalize

Tailor

Formalize

Disseminate

Experience Base

environment

characteristics

tailorable

knowledge,

consulting

project analysis, process

modification

data, lessons learned

The Experience Factory Organization

Project Learning Organizational Learning


Learning in Single- and Double Loops

Action /

process

Consequence /

result

OK

NOT OK

Repair

Organization /

experience

Cause analysis

Organizational learning: A theory of action perspective

Chris Argyris & Donald A. Schön, 1978

• We get a better product when we correct a fault, but if we don’t eliminate the root-cause of the defect there is always a risk that the same fault is injected over and over again.

• By seeking the cause of the fault, we are able to

– Remove systematic faults once and for all

– Get the opportunity to improve the process which caused the fault(s)

– Nurture innovation


SEL: An Example Experience Factory

Structure DEVELOPERS

(SOURCE OF EXPERIENCE) (PACKAGE EXPERIENCE FOR REUSE)

DATA BASE SUPPORT (MAINTAIN/QA EXPERIENCE INFORMATION)

Development measures for each

project

Refinements to development

process

STAFF 275-300 developers

TYPICAL PROJECT SIZE 100-300 KSLOC

ACTIVE PROJECTS 6-10 (at any given time)

PROJECT STAFF SIZE 5-25 people

TOTAL PROJECTS (1976-1994) 120

STAFF 10-15 Analysts

FUNCTION • Set goals/questions/metrics - Design studies/experiments

• Analysis/Research • Refine software process

- Produce reports/findings

PRODUCTS (1976-1994) 300 reports/documents

SEL DATA BASE

FORMS LIBRARY

REPORTS LIBRARY

160 MB

220,000

• SEL reports • Project documents • Reference papers

STAFF 3-6 support staff

FUNCTION • Process forms/data

• QA all data

• Record/archive data

• Maintain SEL data base

• Operate SEL library

NASA + CSC + U of MD NASA + CSC

NASA + CSC

PO PROCESS ANALYSTS

EF


Using Baselines to Demonstrate Improvement: 1987 vs 1991

Error Rates (development)

0

2

4

6

8

10

Early Baseline 8 similar systems

Current 7 similar systems

Err

ors

/KL

OC

(d

ev

elo

pe

d)

Average ~4.5

Average ~1Low 1.7

Low 0.2

High 2.4

High 8.9

0

200

400

600

800

Cost (staff months)


supporting 4 projects


supporting 4 projects

Sta

ff m

on

ths

Average ~490

Average ~210

Low 357

High 755

Low 98

High 277

Reuse



% R

eu

se

FORTRAN (3 systems)

Ada (5 systems)

0

20

40

60

80

100

Average ~79%

61

90

IEE

E39

Average ~20%

Early Baseline = 1985-1989 Current = 1990-1993

Decreased 75% Reduced 55%

Increased 300%

Defect


Continuous Improvement in the SEL Decreased Development Defect rates by 75% (87 - 91) 37% (91 - 95) Reduced Cost by 55% (87 - 91) 42% (91 - 95) Improved Reuse by 300% (87 - 91) 8% (91 - 95) Increased Functionality five-fold (76 - 92) CSC officially assessed as CMM level 5 and ISO certified (1998), starting with SEL organizational elements and activities Fraunhofer Center for Experimental Software Engineering - 1998 CeBASE Center for Empirically-based Software Engineering - 2000 BUT: Experience Factory dissolved within NASA after 2000!

Using Baselines to Show Improvement: 1987 vs 1991 vs 1995


How to find similar projects in the EB?

Case-Based Reasoning (CBR):

– Involves:

1. Matching the new case (= problem, project)

against cases (= problems, projects)

encountered in the past, and

2. Adapting the solutions (= characteristics) of

the past cases (= problems, projects) to the

current context.

– It can be represented as a cyclical process that

is divided into the four following sub-processes

as depicted in the figure on the left:

• retrieve the most similar past case(s) from the

case base

• reuse retrieved case(s) to solve the current

case with an adaptation rule

• revise the proposed solution – if necessary

• retain the solution for future problem solving


Example: Estimation by Analogy


– Involves:






current context.





case base




• retain the solution for future problem solving

Similarity Function


Example: Estimation by Analogy


– Involves:






current context.





case base




• retain the solution for future problem solving Adaptation Rule


Effort Estimation Model – Example (1)

Case-Based Reasoning (CBR) Example:

Attributes New Case Retrieved Case 1 Retrieved Case 2 Project Category Real Time Real Time Simulator

Language C++ C++ C++

Team Size 10 10 9

System Size 150 200 175

Effort ? 1000 950

Similarity 90% ~50%

Adaptation rule 1:

7501000200

150Effort_edictedPr

Possibilities to predict effort: • adapted effort based on 1 project • average effort of 2 projects • weighted average effort of 2 projects

Effort=f (System_Size)






Team Size 10 10 9


Effort ? 1000 950

Similarity 90% ~50%

Adaptation rule 2: Possibilities to predict effort: • adapted effort based on 1 project • average effort of 2 projects • weighted average effort of 2 projects

782950175

1501000

200

150

2

1_

EffortedictedPr







Team Size 10 10 9


Effort ? 1000 950

Similarity 90% ~50%

Adaptation rule 3: Possibilities to predict effort: • adapted effort based on 1 project • average effort of 2 projects • weighted average effort of 2 projects

77314

5*950

175

150

14

9*1000

200

150_Pr Effortedicted



Effort Estimation Model – Similarity (1)


Distance Measure (Euclidean Distance) Similarity = 1 – Distance

n

)P,P(

)P,P(cetandis

n

k

jkik

ji

1

jkik

jkik

kk

jkik

jkik

PPANDlcategoricakif,


continuouskifminmax

PP

)P,P(

1

0

2

P.,k Pnew,k P1,k (Pnew,k, P1,k) Project Category Real Time Real Time 0

Language C++ C++ 0

Team Size 10 10 0

System Size 150 200 0.04=(50/250)2

Assume that smallest system in DB has 100 KLOC and largest system has 350 KLOC max – min = 250 KLOC

similarity(Pnew, P1) = 1 – distance(Pnew, P1) = 1 – sqrt(0.04/4) = 0.1


Effort Estimation Model – Similarity (2)


Distance Measure (Euclidean Distance) Similarity = 1 – Distance

n

)P,P(

)P,P(cetandis

n

k

jkik

ji

1

jkik

jkik

kk

jkik

jkik



continuouskifminmax

PP

)P,P(

1

0

2

P.k Pnew,k P2,k (Pnew,k,P2,k) Project Category Real Time Simulator 1

Language C++ C++ 0

Team Size 10 9 0.01=(1/10)2

System Size 150 175 0.01=(25/250)2

Assume that smallest system in DB has 100 KLOC and largest system has 350 KLOC max – min = 250 KLOC

similarity(Pnew, P2) = 1 – sqrt(1.02/4) ≈ 0.5


EF Discussion

• What are potential obstacles for

a functioning EF?

• What could be done to overcome

the obstacles?


Research done by SINTEF/NTNU

• Focus: Knowledge Management in mid-sized companies

• 3 KM tools investigated in case studies:

– Electronic Project Guide: Description of common processes

and work roles in project work, with templates, checklists

and examples.

– Well of Experience: A knowledge repository ("collective

yellow stickers"). Contains everything from bugfixes to

telephone numbers.

– Skills Manager: An overview of the skill levels of all

employees on about 250 different skills that are considered

important for the company.

Torgeir Dingsøyr, Emil Røyrvik: An Empirical Study of an Informal Knowledge Repository in a Medium-Sized Software Consulting Company, ICSE 2003



• Homework 4

• Project




Global Software Development

Main issue:

distance matters


Co-located versus global/multi-site

• Co-located: housed within walking distance

– People re-invent the wheel if they have to walk more than

30 meters, or climb the stairs

• Main question: How to bridge distance in global projects?

– Communication

– Coordination

– Control


Arguments for global software development

• Cost savings (salary)

• Faster delivery (“follow the sun”)

• Larger pool of developers

• Better modularization (of responsibilities)

BUT: Little empirical evidence that these advantages materialize


Challenges

communication

coordination

control

temporal geographical sociocultural

distance

X

X

X

X

X

X

X

(X)

(X)


Temporal distance challenges

• Communication:

– Being effective (asynchronous is less effective,

misunderstandings, …)

• Coordination:

– Cost is larger (travels, infrastructure cost, …)

• Control:

– Delays (wait for next teleconference meeting, send email

and wait, search for contact, …)


Geographical distance challenges

• Communication:

– Effective information exchange (less informal exchange, different

languages, different domain knowledge, …)

– Build a team (cohesiveness, “them and us” feelings, trust, …)

• Coordination:

– Task awareness (shared mental model, …)

– Sense of urgency (perception, …)

• Control:

– Accurate status information (tracking, blaming, …)

– Uniform process (but different tools and techniques, …)


Geographical distance: awareness

• Activity awareness:

– What are the others doing?

• Availability awareness:

– When can I reach them?

• Process awareness:

– What processes are they using?

• Perspective awareness:

– What are the others thinking, and why?

• Improving awareness and familiarity with other members helps!


Sociocultural distance challenges

• Communication:

– Cultural misunderstandings (corporate, technical, national,

…)

• Coordination:

– Effectiveness (vocabulary, communication style, …)

• Control:

– Different control/feedback styles (more or less hierarchical;

more or less formal)


National culture

• American managers have a hamburger style of management.

– They start with sweet talk – the top of the bun.

– Then the criticism is slipped in – the meat.

– Finally, some encouraging words – the bottom bun.

• With the Germans, all one gets is the meat.

• With the Japanese, all one gets is the bun; one has to smell

the meat.


Hofstede’s dimensions

• Power distance

– status is important versus individuals are equal

• Collectivism versus individualism

– Individuals are part of a group, or everyone looks after himself

• Uncertainty avoidance

– Strict rules that mitigate uncertainty versus flexibility/pragmatism

• Femininity versus masculinity

– Challenges, recognition, materialism (masculine) versus good relationships, cooperation, security , quality of life (feminine)

• Long-term versus short-term orientation

– Persistence in pursuing goals, order, capacity for adaptation (LT) versus protecting one’s face, tradition, fulfilling social obligations, rewarding past and present behavior (ST)


Power distance

• In cultures that endorse

high power distance, less

powerful accept power

relations that are more

autocratic and paternalistic.

– Subordinates acknowledge

the power of others simply

based on where they are

situated in certain formal,

hierarchical positions

• Cultures that endorse low

power distance expect and

accept power relations that

are more consultative or

democratic.

– People relate to one another

more as equals regardless

of formal positions.

Power Distance Index (PDI) for countries

http://www.targetmap.com/viewer.aspx?reportId=6648

http://www.targetmap.com/viewer.aspx?reportId=6648


Collectivism versus individualism

The degree to which individuals are integrated into groups.

• In individualistic societies,

the stress is put on personal

achievements and individual

rights.

– People are expected to stand

up for themselves and their

immediate family, and to

choose their own affiliations.

• In collectivist societies,

individuals act predominantly

as members of a lifelong and

cohesive group or

organization.

– People have large extended

families, which are used as a

protection in exchange for

unquestioning loyalty.


Uncertainty avoidance

• Low uncertainty avoidance (UAI):

– can better cope with uncertainty: they can deal with agile

approaches, ill-defined requirements, etc.

• High uncertainty avoidance:

– favor waterfall, contracts, etc.

• Latin America, Japan: high UAI

• North America, India: low UAI


How to overcome distance?

• Common ground

• Coupling of work

• Collaboration readiness

• Technology readiness


Common ground

• How much common knowledge members have, and are aware

of

• Common ground has to be established:

– Traveling, especially at start of project

– Socialization (kick-off meetings)

• Intense interaction is more important for success than CMM

level


Coupling of work

• Tasks that require much collaboration:

– at same site

• Little interaction required:

– different sites

• Example: testing or implementing relatively independent

subsystems


Collaboration readiness

• Transition to global development organization:

– Requires changing work habits

– People must embrace difference as an opportunity

– Learning new tools

– Needs incentives for individuals to cooperate


Technology readiness

• Project management tools (workflow management)

• Web-enabled versions of tools

• Remote control of builds and tests

• Web-based project repositories

• Real-time collaboration tools (simple media for simple

messages, rich media for complex ones)

• Knowledge management technology (codification AND

personalization)


Organizing work in global software

development

• Reduce the need for informal communication

– Usually through organizational means, e.g.:

• Put user interface people together

• Use gross structure (architecture) to divide work

– Conway’s Law: “Organizations which design systems ...

are constrained to produce designs which are copies of

the communication structures of these organizations.”

[1968]

• Split according to life cycle phases

• Provide technologies that ease informal communication


Summary

• Distance matters

• Main challenges:

– Deal with lack of informal communication

– Handle cultural differences


Next Lecture

• Next Wednesday:

– Project counsultancy (still 7 free time slots!)

• Next 2 weeks:

– Project Presentations

– Course wrap-up, review and exam preparation

• For you to do:

– Finish project report

– Prepare project presentation

– Start preparing for exam

MTAT.03.243 Software Engineering Management...Software Engineering Management Lecture 19:...

Documents

Transcript of MTAT.03.243 Software Engineering Management...Software Engineering Management Lecture 19:...