product-focused engineering process analysis and improvement · tool mec.. tool aelec. workflow...

Product-Focused Engineering

Process Analysis and Improvement

Stefan Biffl

Christian Doppler Laboratory CDL-Flex

Institute of Software Technology and Interactive Systems (ISIS) Vienna University of Technology

http://cdl.ifs.tuwien.ac.at

Te

ch

. In

tero

p.Tool Mec.

Tool Elec.

Workflow

Analysis

SCADA

Tool SW

Model Mec.

Model

SW

Model

Elec.

2

CDL-Flex Research Background and Agenda

TU Wien CDL-Flex: application-oriented basic research

with industry partners in line with

industry trends Enterprise 2.0,

the Industry 4.0 initiative in Germany, and

the European Union “Horizon 2020” program.

Context

Engineering organizations, business information systems

Product development, often systems of systems

Similar products with variations (towards product lines)

Industry partners usually work on CMMI levels 2 to 3.

Challenges regarding product and process improvement

Case Studies and Lessons Learned

Hydroelectric power plant in Foz do Iguaçú, Brazil Steel mill

3

Product-Focused Engineering Aspects

Typical Product examples

– Industrial production system automation

– Engineering tools and information systems

– Business application, services

Links between product quality

and development processes

Stakeholders

around a product development environment

M. Foehr, A. Köhlein, J. Elger, T. Schäffler, A. Lüder: Optimization of the information chain within the engineering process of production systems,

IEEE International Systems Conference (SysCon), Orlando, Florida, USA, April 2013, Proceedings.

4

Stakeholder Value in an Ecosystem Context

Repeatable product/service development and delivery in core business areas.

Better cost, quality, or schedule of software and systems engineering processes.

– Effort and risk of development and Quality Assurance processes.

– Improvements in sub-processes and process steps: quality, effort, duration, risk.

Identifying and securing mission-critical engineering know-how.

– Elicit the most relevant candidates for elicitation and sharing engineering know-

how on best practices in the context of an organization.

VDE 3695 part 2 „Engineering of industrial plants – evaluation and optimization; subject processes“, Association of German Engineers,

November 2010.

5

Product-Focused Engineering

Stakeholders in the Organization and their Goals

Common goal: repeatable successful product development and delivery.

Success-critical stakeholders and their goals

1. Client: Timely and reliable rollout of useful and affordable software.

2. Software Manager: Repeatable successful product evolution and delivery.

3. Quality Manager: Testable and assessable products and processes.

4. Software & Systems Team: effective development environment & processes.

4

3

1

2

1 2

3

4 1

6

Software and Systems Engineering Companies

Selected Challenges at Industry Partnes

Scope: family of products or product line, often systems of systems.

Business-level challenges

A1 Domain-specific business definition and scope of product-focused process

A2 Product line parameters: fixed and variable parameters, and their impact

A3 Ecosystem stakeholders and their interests, value streams

Process-level challenges

B1 Continuous data collection in a heterogeneous project environment

B2 Reuse organization of software artifact asset candidates

B3 Engineering know-how: continuous elicitation during a project & across projects

A2

A3

A1


November 2010.

B2

B3

B1 B3 VDE 3695 process model

Project C

Project B

Project A

Analysis Planning RealizationTest/

Approval

Acquisition Planning RealizationCommis-sioning

Market

orders

Strategic

Constraints

Client/

market

project

requirements

Project-independent Activities

Project-dependent Activities

Reusable

Artifacts / Standard

Analysis Planning RealizationAnalysis Planning

Project C

Project B

Project A

Analysis Planning RealizationTest/

Approval



Market

orders

Strategic

Constraints

Client/

market

project

requirements

Project-independent Activities

Project-dependent Activities

Reusable

Artifacts / Standard

Analysis Planning RealizationAnalysis Planning

7

Software and Systems Engineering Companies

Process Challenges at Industry Partners

B1 Continuous data collection in a heterogeneous project environment

B2 Reuse organization of software artifact asset candidates

B3 Engineering know-how: continuous elicitation during a project & across projects

B2

B3

B1 B3


November 2010.

VDE 3695 process model

B2

8

Popular Software Process Approaches

Matching to Challenges of Industry Partners

Legend:

+ … good match

+/- … partial match

- … poor match

See references for the software process approaches in the reference section.

A1 A2 A3 B1 B2 B3

Software process assessment approaches

e.g., CMMI, Spice, MPS-SW/SV

+/-

- - - +/- -

Systematic software process models

e.g., Waterfall, RUP, Spiral model, V-Modell XT

+/- +/- - - +/- -

Software management approaches

e.g., Agile, Lean, Kanban

+/- - - - +/- +/-

Software process improvement approaches

e.g., QIP, PDCA, VDE 3695, QATAM

+/- +/- +/- + + +/-

MPS-SV Maturity Levels CMMI-SVC Maturity Levels

A – In Optimization 5 – In Optimization

B – Quantitatively Managed 4 – Quantitatively Managed

C – Defined

D – Largely Defined

E – Partially Defined

3 – Defined

F – Managed

G – Partially Managed

2 – Managed

VDE 3695 process improvement process

Software process assessment levels

9

B1: Continuous Data Collection From Engineering

Environments – The Heterogeneity Issue

Data sources in engineering environments are often heterogeneous, .e.g.

1. Tool chains and disciplines in systems engineering,

2. Business software development project consortium,

3. Disciplines in game development process.

2

1

3

Challenges from Heterogenity in the Engineering

Process of Industrial Production Plants

Engineering

Tools & Systems

Pipe &

Instrumentation

Electrical Plan

Software Dev.

Environment

Other Tool

Domains

Process Engineer

Software Engineer

Tool Data

Tool Data

Elec. Engineer

Tool Data

Tool Domain X User Customer Rep.Tool Data

Project

Participants

Project

Manager

Project-Level

Processes & Applications

?2

Design Document

After Milestone

B

Start

Approved?

Change & Notify

Change

Approve

End

Ticketing

Yes No

Customer Rep.

Project

Participants

Project

Manager1

3

1. “Engineering Polynesia”: tool islands with interfaces that do not fit seamlessly.

2. “Engineering Babylon”: engineers use project-level concepts, tools do not.

10 Biffl St., Mordinyi R., Moser T., „Anforderungsanalyse für das integrierte Engineering – Mechanismen und Bedarfe aus der Praxis“,

atp edition 5/2012.

11

CDL “Flex Improvements” Contributions Overview

Scope: family of products or product line; systems of systems

A1 Stakeholder interest elicitation and negotiation;

A2 Software product lines in an organization (VDE 3695);

A3 Software ecosystems in a business domain (SECO).

Engineering process analysis and improvement

according to VDE 3695.

B1 Data integration for process support and analysis;

B2 Organization of reusable semi-finished products;

B3 Eliciting and sharing engineering know-how with collective intelligence.

Lessons learned from case studies with research and industry partners

TI&SEC

Au

tom

ati

on

Se

rvic

e B

us

(O

ffs

ite

)

En

gin

ee

rin

g S

erv

ice

Bu

s

Requirements

Management

Pipe &

Instrumentation

Electrical Plan

Engineering

Knowldge Base

Engineering

Workflow Rules

Software Dev.

Environment

Data Analysis/

Simulation

SCADAC

C

C

C

C

C

Tool Data

Tool Data

Tool Data

Tool Data

Tool Data

Tool Data

Tool Data

SCADA & Sim

Model Mec.

Model

SW

Model

Elec.

QM

Design Document

After Milestone

B

Start

Approved?

Change & Notify

Change

Approve

End

Ticketing

Yes No

Process Definition & Analysis

Project Monitoring & Control

0%

20%

40%

60%

80%

100%

Phase 1.1 Phase 1.2 Phase 1.3

Sh

are

of C

ha

ng

es b

ase

d o

n C

he

ck-I

n D

ata

[%

]

Check-in Phases

- Rejected Signals - Accepted Changes - Similar Signals

QM & Defect Detection

B1

A1

A2

A3

B2

B3

Automation Service Bus ©

B2

B3

12

CDL “Flex Improvements” Case Studies

with Focus On Process-Level Challenges

B1 Data integration for process support and analysis

B2 Organization of reusable semi-finished products

B3 Eliciting and sharing engineering know-how

1. Quality-Assured Tool Chains: Semantic Dropbox

2. Project Overview with the Engineering Cockpit

3. Early Defect Detection

4. Engineering Process Analysis

5. Reuse of Software Artifacts and Expert Know-How

B1 B2 B3

B1 B2 B3

B1 B2 B3

B1 B2 B3

B1 B2 B3

B1

B1

Automation Service Bus and Data Integration Environment

Typical common concepts in industrial plant engineering. Partial views on selected tool chains across disciplines.

Case Study: Quality-Assured Tool Chains:

Semantic Dropbox – Context & Issues

Tool chains link engineering process activities

Multitude of models and tools used by engineers, management, and customers

Implementation often only as manual activities or fragile constructs, e.g., scripts.

Issues: version management, work culture in systems of systems environments.

Issue: visibility of process information from heterogeneous data sources.

Effort and user friendliness for quality-controlled propagation of changes

in heterogeneous software data models needs to be improved.

13

Semantic Dropbox scenario


Semantic Dropbox – Approach

The Semantic Dropbox

provides traceable and automated propagation of changes

between engineering tools.

enables project participants to create work space folders, and share and

synchronize files in these folders with other project participants.

transforms data between local representations of common

concepts, so each project participant sees the representations

of common concepts in his local representation format.

14 Typical common concepts in industrial plant engineering. Mapping of local tool concepts to common project team concepts.

„Pump flow“

Real (l/min)

0 to 1,200

%I20.5.3

Information

Analog

0 to 10 V

X.22.2.1

Software

Engineer

Process Engineer

Electrical

Engineer

Tool A Data Model Tool B Data Model

Domain/project data model

Mechanical

equipment properties

Transmission lines

Terminal points

Data Types

Logical Behavior

Requirements

Location IDs

Components

Interfaces

Tool C Data Model

Signals (I/O)

Machine vendor

catalogue

Model Mapping

Tool A – Domain

Derived Mapping

Tool A – Tool B

Models

Common

concept

Signals (I/O)

Change propagation in a heterogeneous environment.


Semantic Dropbox – Contribution & Improvement

Process improvements at software and systems engineering organizations

1. Domain experts can produce traceable and secure tool chains easily (in a few days instead of weeks).

2. Practitioners can propagate changes to engineering objects efficiently (in seconds instead of minutes).

3. Quality managers can evaluate activities on engineering objects (e.g., changes to library code blocks) automatically, even across several projects.

4. Project management: Clear traceability of changes to engineering plans coming from external project partners.

15 Semantic Dropbox scenario

1 2

3 4

Change propagation between Excel and XML representations. Semantic Dropbox scenario


Semantic Dropbox – Lessons Learned

Process support must be simple and efficient to be used regularly.

The reduction of effort for the synchronization of signals in engineering systems of systems enables a change in the work culture.

Data integration is the foundation for change process support and analysis.

The more accurate data basis for progress and risk management facilitates engineering process analysis and improvement.

Easy and reliable change propagation can have a profound impact on the work culture, the engineering process, and product quality.

Electrical Eng.

Electrical Plan

Eng. CenterC

Tool Data

Project Manager

Software Eng.

Software Dev.

EnvironmentC

Tool Data

Automation

Service Bus

Project-level

concepts

Engineering

Cockpit

Semantic

Dropbox

Comprehensive View on

Engineering Data

Semantic Data

Synchronization16

Heterogeneous data sources without effective data integration

Case Study: Project Overview with the

Engineering Cockpit – Context & Issues

Data sets of systems-of-systems engineering groups evolve concurrently, often without project-wide version management and progress tracking.

Lead engineers and managers get a clear picture only shortly before project milestones, seeing risks unnecessarily late.

In particular, late changes to plans are insufficiently visible to enable the engineering process analysis for improvements.

Project managers need to see between milestones the overview on project progress based on current and systematically integrated data.

17

Integrated view on heterogeneous data sources with the Engineering Cockpit.


Engineering Cockpit – Approach

Collect and integrate data from engineering teams and processes

Web application „Engineering Cockpit” provides

– role-specific views for participants in the engineering team

– relevant information on current and historic project activities.

Users specify queries in SQL to the common data basis which the „Automation Service Bus“ provides and which contains all relevant changes of data from software tools and systems in the project.

Project participants can configure all relevant views on queries in the Engineering Cockpit and therefore always have the current view on the relevant aspects of the project status.

Evaluation with concepts from real-world projects.

Pipe &

Instrumentation

Electrical Plan

C

C

Tool Data

Tool Data

Project Manager

Software Dev.

EnvironmentC

Tool Data

Automation

Service Bus

Project-level

concepts

Engineering

Cockpit

E

C

o

18


Engineering Cockpit – Contribution & Improvement

The Engineering Cockpit provides engineers and managers with

a platform to organize and perform specific tasks across domain and tools.

means to collaborate efficiently within the engineering team.

integrated data on project progress and risks as soon as the engineering groups check in their local data sets to allow adjustments early.

View on data and process states across domains:

Which safety variables are not connected correctly to sensors across tools?

Which artifacts in status „approved“ were changed in the last week?

Who changed signals of the artifact „Generator“ in the last two weeks?

19

20

Engineering Cockpit: Project Management Overview

Project Status Overview

Signal Overview

Role-based

Project View Role-based

Events

Project Related

Stakeholders

Role-based

Status & Applications


Engineering Cockpit – Lessons Learned

Engineering Cockpit: role-oriented dashboard and activity options, in particular, for project and quality management, on recent and integrated data.

Project management: View on engineering project and process status across domains in a distributed engineering project.

Claim management: trace changes back to internal or external sources.

Quality management: engineering process risk analysis, e.g., an unexpectedly large number of changes to engineering objects late in the project.

Engineering Process Analysis is basis for Engineering Process Improvement

21

Project progress and risk indicators based on integrated data from engineering teams and tools.

Case Study: Early Defect Detection in

Heterogeneous Environments – Context & Issues

Collaboration of engineers in a heterogeneous engineering environment,

e.g., electrical, mechanical, software, and process engineers.

Use case in the Automation Systems Domain, e.g., Hydro Power Plants. Challenge of identifying defects across several scopes of planning.

Loosely coupled tools (technical heterogeneity of tools) and data models (semantic heterogeneity of data models) hinder efficient change management and defect detection.

Need for linking heterogeneous data models, e.g., sensors, configuration, and software variables, to improve engineering product quality, e.g. “end-to-end” consistency checks.

22 Challenge of identifying defects across several scopes of planning.

Winkler D., Biffl S.: “Improving Quality Assurance in Automation Systems Development Projects”, In "Quality Assurance and Management",

Book Chapter, Intec Publishing, ISBN 979-953-307-494-7, 2012.


Heterogeneous Environments – Approach

Early defect detection with integrated data from heterogeneous data sources.

The mapping of common concepts of the domain experts in a project to their local representations in software tools facilitates the analysis of changes and conflicts.

Reviews focus on changes in engineering plans (“Change-Driven Inspection”).

Automated “end-to-end” consistency checking and system testing based on early defect detection approaches and “test-first” development.

23

Reviews of changes.

End-to-end test.

Automated test run.


Heterogeneous Environments – Improvement

Engineering Process Improvement with defect detection and data collection.

Early defect detection based on integrated data from heterogeneous data sources.

Data mapping enables analyses across engineering data models.

– Basis for deriving the review scope.

– Basis for automated end-to-end consistency checks.

Efficient defect detection in early phases of systems development based on semantic technologies.

24

SELECT ?Electric_ID, el:desc, el:type,

?Config_ID, ?SW_ID, sw:desc, sw:type

WHERE {

el:E_short ekb:mapsTo ?Electric_ID.

….

Example Query Result

(S1, “pressure”, “mbar”, C1,

V_A, “pressure”, “mbar”)

(S4, “pressure”, “mbar”, C3,

V_B, “temperature”, “kelvin”)

(S2, “level”, “cm”, C5,

V_C, “level”, “m”)

Mapping of local data models to

common data models


Heterogeneous Environments – Lessons Learned

Semantic data integration helps to mitigate defects and risks

from inconsistent engineering plans in distributed engineering projects.

Linking heterogeneous data supports quality assurance experts in focusing on most critical system parts (e.g., based on changes).

– Expert support for focused inspection.

– Foundation for automating consistency checks across engineering disciplines.

Successful application of early defect detection approaches in various domains.

25 25

Reviews of changes at interfaces of several engineering scopes.

Reviews of changes.

Derivation of

end-to-end test cases.

Case Study: Engineering Process Analysis –

Context & Issues

Engineering process analysis and improvement

according to VDE 3695 (domain and project model)

Continuous observation and improvement of workflows and engineering processes.

Basic Steps: (1) Definition, (2) Implementation, (3) Data collection, and (4) Workflow evaluation.

26

(1) Workflow definition

(2) Implementation

(3) Data capturing

Workflow

Engine

(4) Workflow evaluation

Sunindyo W.D., Moser T., Winkler D.: “Process Model Validation for Heterogeneous Engineering Environments”, Software Quality Days 2012.


Approach

Engineering Process Observation

and Analysis Framework.

Four layers from a business perspective.

Process automation supports the definition, implementation, and evaluation of process improvements.

Use Case: Continuous Integration and Test (CI&T).

Continuous Integration and Test Workflow Steps:

1. Informal CI&T Process description

2. Transformation to a more

formal representation

3. Derivation and Implementation of rules

in the workflow engine, e.g., the ASB.

4. Event Data Capturing with log files.

5. Expected Process modeled with PRoM

6. Evaluation of the expected process definition

with log-file data.

27 Sunindyo W.D., Moser T., Winkler D.: “Process Model Validation for Heterogeneous Engineering Environments”, Software Quality Days 2012.


Contribution & Improvement

Automated data collection based on executed process steps.

Foundation for verification and validation of workflows and processes.

– Conformance of executed process steps with real process data (PRoM).

– Foundation for in-depth analysis to identify engineering process bottlenecks based on advanced engineering process analysis.

28

Start Sta

rt

Co

mp

leteBuild

Check In

complete Sta

rt

Co

mp

leteTest

Sta

rt

Co

mp

leteDeploy

Build-Failed

Complete

Test-Failed

Complete

Deploy-

Failed

Complete

End

Test-

Exception

Complete

0.88

0.12

0.98

0.02

0.88

0.12

A1 A2 A3 A4p1 p2 p3 p5p4 p6 p7

Color Level Waiting Time (s)

High > 2.8

Medium 1.8 – 2.8

Low < 1.8

Each level contains 1/3 of the whole processes


Product prototyping process.


Lessons Learned

Comprehensive and efficient engineering process observation and analysis.

Process model evaluation with PRoM enables fast and efficient feedback on implemented vs. planned processes.

Simple process and workflow evaluation as foundation for compiling processes to larger engineering process maps, e.g., agile engineering processes in research and industry projects.

29

Prototype/Product

Maturity

Key Stakeholders

Agile Eng. Process

with Scrum

Extensions

Key Deliverables

Winkler D., Mordinyi R., Biffl S.: "Research Prototypes versus Products: Lessons Learned from Software Development Processes in Research

Projects", Proceedings of the 20th EuroSPI Conference, Dundalk, Irelande, 25.-27.06.2013.

Case Study: Reuse of Software Artifacts and

Expert Know-How – Context & Issues

Q: How to make reuse and expert know-how sharing

activities beneficial both for the project and the

organization?

Limitations of typical reuse and sharing scenarios:

1. Users store software artifacts

in an unstructured, incomplete manner.

2. Lack of systematic approach to store and relate artifacts.

3. No information about

artifact quality, usefulness, and traceability.

This leads to …

A “dump” of artifacts which buries valuable contributions.

Inefficient search for available elements to build upon.

Issue must be addressed on project-independent level.

30

(cc) seantoyer


Expert Know-How – Approach

Steps

1. Identify main workflow limitations

of mission-critical actors,

e.g., dispersed local engineering know how.

2. Identify artifacts of interest,

e.g. requirements, solution elements, and

reorganize them in a structured pool.

3. Actors perform contribution activity

(create, modify, review artifact)

which codifies content and knowledge.

4. Mine relevant contributions from artifacts in the pool

to create behavioral triggers for actors

e.g., notifications or signals.

5. Actors with incentive perform

contribution activities, creating

a constant flow of new contributions and triggers.

6. Continue with step 3.

31

Store

Use Develop

2

3

4

5


Expert Know-How – Contribution

Software Reuse and Sharing System

Web platform, which orchestrates reuse and know-how sharing activities across an actor community.

Support reuse process and improvement efforts.

Aggregates artifacts and knowledge about them.

Key Capabilities & Improvements

1. Structured adding and storing of artifacts.

2. Consistent artifact format enriched with metadata (e.g. context, rating) and relation information between artifacts.

3. Expert know-how about quality, usefulness,and user-driven recommendations.

Bottom-up emergent coordination.

Recommendation: Help engineers to identify best-fitting artifacts.

32

(cc) D

avid

Goehri

ng

(cc) C

ory

Docto

rw

Example: Github

Collaborative, global source code repository platform.

1. Code repository contributions via GIT cvs.

2. Links between artifacts (e.g. repo forks).

3. Expert know-how elicitation: e.g starring, activity monitoring, developer and project discovery.

33

Analyze forks

and contributions

1

Analyze activity level 2

2 Mark and build upon 1

Connect with developers

3

2

Explore new projects 3


Expert Know-How – Lessons Learned

Reusable assets are a well-structured basis for product-focused development.

The collective intelligence (CI) environment enables better coordination of QA activity and recommendation.

Users in other engineering teams can better filter and are better aware about relevant assets

based on context and quality ratings.

Success/Risk factors

Commitment of management and domain experts.

Selection of suitable “artifacts of interest.”

CI environment that is easy to use and adapt.

Calibration of CI system to load assets.

Risk: If CI system is not well integrated in daily workflow of users, the CI system will not be used. Example: use of a Wiki to document all “relevant engineering know-how” without considering CI systems success & risk factors.

34

35

Software Artifact Reuse and Engineering Know-

How Elicitation and Sharing – Outlook

How to make reuse and knowledge sharing activities

beneficial both for the project and the organization?

– Make better actor behavior easier and more rewarding.

– Advanced data and process analysis capabilities.

– Establish knowledge management

for mission-critical know-how.

Integrated Process Improvement Approach

– Combination of both software architecture and

process improvement.

– Enhanced, bottom-up workflows based on the

orchestration of CI system design and

process improvement activities.

Going ecosystem: Extending CI systems beyond

organization borders.

– Acquire knowledge and reuse software artifacts

created by external partners and communities.

Lessons Learned on Product-Focused Engineering


Challenges with families of products and systems-of-systems environments

Heterogeneity of local data models in systems and engineering tools,

Different speeds of processes and teams,

Overview and control are hard to keep.

B1 Data integration for process support and analysis

Data integration is the basis for automating continuous focused data collection.

Continuous data collection enables engineering process analysis.

Engineering process analysis prepares process improvements.

B2 Reusable semi-finished products

Product-focused engineering: Product vision towards

product line or ecosystem development.

B3 Eliciting and sharing engineering know-how

Collective Intelligence design approach

seems promising and should be investigated

in a variety of application contexts.

36

37

Summary – Product-Focused Engineering


Stakeholders want repeatable and flexible product development.

Software process approaches are helpful

to provide an overview on best practices and

on engineering process improvement areas.

Industry trends such as Enterprise 2.0,

the Industry 4.0 initiative in Germany, and

the European Union “Horizon 2020” program

emphasize the investigation of new approaches such as

cognition and intelligent support for workers in complex work spaces

systematic design of collective intelligence systems for specific applications.

Research case studies with industry partners discussed solution approaches,

which were empirically evaluated in several application domains with heterogeneity.

Visit us online at http://cdl.ifs.tuwien.ac.at

VDE 3695 process model

Data and tool integration Applications based on integrated data. Collective Intelligence Applications.

Model Mec.

Model

SW

Model

Elec.

Backup Slides

Collective Intelligence – Overview & Example

Collective Intelligence (CI)

Phenomenon: Group intelligence that emerges from

collaboration, collective action and competition

of many individuals.

Sociology, biology, business, computer science.

CI and IT

Achieved by hybrid systems in which humans and

computers interoperate and complement each

others' capabilities.

Highly effective collection and distribution of

knowledge

Crowdsourcing, Social Web/Media,

Social/Cognitive/Human Computing

Examples

– Github (code repositories)

– TopCoder (coding contests)

– Stakeoverflow (questions & answers)

39

(CC

) S

tockM

onkeys.c

om

Collective Intelligence Systems Research

Our Principles

1. Enabling organizations to reorganize work in new ways.

2. Hybrid human-computer systems that harness the

“wisdom of crowds”.

3. Support approaches, which propagate to build on work

already being done by others instead of reinventing the

wheel.

Our Take

Foundation research on new kinds of software architectures.

– Analysis of existing CI systems.

– Design and develop novel CI systems in yet

unaddressed domains.

Knowledge management for mission-critical know-how.

– Effective and cost-efficient elicitation and sharing of

distributed and dispersed know-how.

Process Improvement

– Coordinated bottom-up, emergent workflow

mechanisms and process risk management.

40

(C) iStockPhoto

41

References

Product-Focused Engineering Processes

VDE 3695 part 2 „Engineering of industrial plants – evaluation and optimization; subject processes“, Association of German

Engineers, November 2010.

Pohl K., Bockle G., & Linden F. van der (2005). Software Product Line Engineering. Berlin, Heidelberg, New York:

Springer-Verlag

Biffl St., Mordinyi R., Moser T., „Anforderungsanalyse für das integrierte Engineering – Mechanismen und Bedarfe aus der

Praxis“, atp edition 5/2012.

Building Engineering Bodies of Knowledge

Biffl S., Serral E., Winkler D., Dieste O., Juristo N., Condori-Fernandez N.: „Replication Data Management: Needs and

Solutions - An evaluation of conceptual approaches for integrating heterogeneous replication study data”, Proceedings of

the 7th International Symposium on Empirical Software Engineering and Measurement (ESEM), Baltimore, Maryland, USA,

10.-22.10.2013.

Biffl S., Kalinowski M., Ekaputra F.J., Serral E., Winkler D.: Building Empirical Software Engineering Bodies of Knowledge

with Semantic Knowledge Engineering, submitted to ICSE 2014, Demo online available at:

http://cdlflex.org/conf/icse14/ske/, 2013.

Biffl S., Musil J., Serral E., Winkler D.: A Semantic Directory for Content and Partner Discovery in Empirical Software

Engineering Research, 39th Euromicro Conference, Work in Progress, Santander Spain, 2013.

Collective Intelligence

Kittur, A., Nickerson, J. V., Bernstein, M. S., Gerber, E., Shaw, A., Zimmerman, J., … Horton, J. (2013). The Future of

Crowd Work. In Proc. 2013 Conf. on Computer Supported Cooperative Work (CSCW ’13) (pp. 1301–1317).

Malone, T. W., Laubacher, R., & Dellarocas, C. (2009, February). Harnessing Crowds : Mapping the Genome of Collective

Intelligence. MIT.

McAfee, A. (2009). Enterprise 2.0: New Collaborative Tools for Your Organization’s Toughest Challenges. Harvard

Business School Press.

Musil, J., Musil, A., & Biffl, S. (2013). Elements of Software Ecosystem Early-Stage Design for Collective Intelligence

Systems. In Proc. of the Int’l Workshop on Ecosystem Architectures (WEA '13) (pp. 21–25). ACM.

42

References (ctd.)

Software Process Approaches Basili V.R., Caldiera G.: Improve Software Quality by Reusing Knowledge and Experience, Sloan Management Review, 37/1, p55-64, 1995

Beedle M., Schwaber K.: Agile Software Development with Scrum, Prentice Hall, 2002.

Biffl S., Serral E., Winkler D., Dieste O., Juristo N., Condori-Fernandez N.: „Replication Data Management: Needs and Solutions - An evaluation of

conceptual approaches for integrating heterogeneous replication study data”, Proceedings of the 7th International Symposium on Empirical Software

Engineering and Measurement (ESEM), Baltimore, Maryland, USA, 10.-22.10.2013.

Biffl S., Kalinowski M., Ekaputra F.J., Serral E., Winkler D.: Building Empirical Software Engineering Bodies of Knowledge with Semantic Knowledge

Engineering, submitted to ICSE 2014, Demo online available at: http://cdlflex.org/conf/icse14/ske/, 2013.

Biffl S., Musil J., Serral E., Winkler D.: A Semantic Directory for Content and Partner Discovery in Empirical Software Engineering Research, 39th

Euromicro Conference, Work in Progress, Santander Spain, 2013.

Biffl S., Serral E., Musil J., Winkler D., Dieste O., Juristo N., Fonseca E.R.C.: An Ecosystem View on Empirical Software Engineering Research,

Submitted to the Special Session of the IST Journal, 2013.

Capability Maturity Model Integration, CMMI Institute, Carnegie Mellon University, http://cmmiinstitute.com/.

Chrissis M.B., Konrad M., Shrum S.: CMMI for Development: Guidelines for Process Integration and Product Improvement, Addison-Wesley Longman,

3rd edition, 2011.

IABG: V-Modell XT Referencemodel, Version 1.3, http://v-modell.iabg.de/v-modell-xt-html-english/index.html, 2006.

ISO/IEC 15504 Information Technology – Process Assessment, Software Process Improvement and Capability Determination, 2003-2012.

Leffingwell D.: Agile Software Requirements: Lean Requirements Proactices for Teams, Programs, and the Enterprise, Addision-Wesley Longman,

2010.

Loon H.: Process Assessment and ISO/IEC 15504: A Reference Book, Springer, 2nd edition, 2007.

Poppendiek M., Poppendiek T.: Lean Software Development: An Agile Toolkit for Software Development Managers, Addison-Wesley Longman, 2003.

Ning J.F., Chen Z., Liu G.: PDCA process application in the continuous improvement of software quality, Int. Conf on Computer, Mechatronics and

Electronic Engineering (CMCE), pp61-65, 2010.

Rozinat A., Alves de Medeiros A.K., Günther C.W., Weijters A.J.M.M., van der Aalst W.M.P.: The need for a process mining evaluation framework in

Research and practice, Position Paper, BPM Workshops, Springer, 2007.

Sommerville I.: Software Engineering, Addison-Wesley Longman, 9th edition, 2010.


VDI/VDE: Engineering of industrial plants – Evaluation and optimization – Fundamentals and procedure, technical rule, November 2010.

Winkler D., Elberzhager F., Biffl S., Eschbach R.: Software Process Improvement Initiatives based on Quality Assurance Strategies: A QATAM Pilot

Application“,17th European Systems & Software Process Improvement and Innovation (EuroSPI), Grenoble, France, 01-03.09.2010

Winkler D., Biffl S.: “Improving Quality Assurance in Automation Systems Development Projects”, In "Quality Assurance and Management", Book

Chapter, Intec Publishing, ISBN 979-953-307-494-7, 2012

Winkler D., Moser T., Mordinyi R., Sunindyo W.D., Biffl S.: "Engineering Object Change Management Process Observation in Distributed Automation

Systems Projects", 18th EuroSPI Conference, Roskilde, Denmark, 27.-29.06.2011

Winkler D., Mordinyi R., Biffl S.: "Research Prototypes versus Products: Lessons Learned from Software Development Processes in Research

Projects", Proceedings of the 20th EuroSPI Conference, Dundalk, Irelande, 25.-27.06.2013.

product-focused engineering process analysis and improvement · tool mec.. tool aelec. workflow...

Documents