productproduct--focused engineering focused engineering ...€¦ · b3 eliciting and sharing...
TRANSCRIPT
ProductProduct--Focused Engineering Focused Engineering Process Analysis and ImprovementProcess Analysis and ImprovementProcess Analysis and ImprovementProcess Analysis and Improvement
Stefan BifflStefan BifflChristian Doppler Laboratory CDL-Flex
Institute of Software Technology and Interactive Systems (ISIS) Vienna University of Technologyy gy
http://cdl.ifs.tuwien.ac.at
Tool Mec.
Tool Elec. Analysis
SCADA Model Mec.
Model SW
Model Elec
WorkflowTool SWSWElec.
CDL-Flex Research Background and Agenda
TU Wien CDL-Flex: application-oriented basic research with industry partners in line withwith industry partners in line with industry trends Enterprise 2.0, the Industry 4.0 initiative in Germany, andthe 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 improvementCase Studies and Lessons Learned
2 Hydroelectric power plant in Foz do Iguaçú, Brazil Steel mill
Product-Focused Engineering Aspects
Typical Product examplesI d t i l d ti t t ti– Industrial production system automation
– Engineering tools and information systems – Business application, services
Links between product qualityand development processes
Stakeholdersaround a product development environment
3 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.
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.
Eff t d i k f d l t d Q lit A– 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.Eli i h l did f li i i d h i i i k
4
– 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.
Product-Focused Engineering Stakeholders in the Organization and their GoalsStakeholders in the Organization and their Goals
1 2
32
1
3
41
4
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.
5
4. Software & Systems Team: effective development environment & processes.
Software and Systems Engineering Companies Selected Challenges at Industry PartnesSelected 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 P d t li t fi d d i bl t d th i i t A2 Product line parameters: fixed and variable parameters, and their impact A3 Ecosystem stakeholders and their interests, value streams
A1 B3
A2
A1
B2
B3
A3B1 B3VDE 3695 process model
Process-level challenges B1 Continuous data collection in a heterogeneous project environment B2 Reuse organization of software artifact asset candidates
6
B3 Engineering know-how: continuous elicitation during a project & across projects
VDE 3695 part 2 „Engineering of industrial plants – evaluation and optimization; subject processes“, Association of German Engineers, November 2010.
Software and Systems Engineering Companies Process Challenges at Industry Partners
StrategicProject-independent Activities
StrategicProject-independent Activities
Process Challenges at Industry Partners
Analysis Planning Realization Test/Approval
StrategicConstraints
Client/market Reusable
Analysis Planning RealizationAnalysis PlanningAnalysis Planning Realization Test/Approval
StrategicConstraints
Client/market Reusable
Analysis Planning RealizationAnalysis Planning
B2
B3
B2marketproject
requirementsArtifacts / Standard
marketproject
requirementsArtifacts / StandardB2B2
Project B
Project A
Acquisition Planning Realization Commis-sioning
Market Project B
Project A
Acquisition Planning Realization Commis-sioningAcquisition Planning Realization Commis-sioning
MarketB1 B3
Project C
Project Borders
Project-dependent Activities
Project C
Project Borders
Project-dependent ActivitiesVDE 3695 process model
B1 Continuous data collection in a heterogeneous project environment B2 Reuse organization of software artifact asset candidates
B3 E i i k h ti li it ti d i j t & j t
7
B3 Engineering know-how: continuous elicitation during a project & across projects
VDE 3695 part 2 „Engineering of industrial plants – evaluation and optimization; subject processes“, Association of German Engineers, November 2010.
Popular Software Process ApproachesMatching to Challenges of Industry PartnersMatching to Challenges of Industry Partners
A1 A2 A3 B1 B2 B3
Software process assessment approachese.g., CMMI, Spice, MPS-SW/SV
+/- - - - +/- -
Systematic software process models +/- +/- - - +/- -Systematic software process modelse.g., Waterfall, RUP, Spiral model, V-Modell XT
+/ +/ +/
Software management approachese.g., Agile, Lean, Kanban
+/- - - - +/- +/-e g , g e, ea , a ba
Software process improvement approachese.g., QIP, PDCA, VDE 3695, QATAM
+/- +/- +/- + + +/-
Legend: + … good match+/- partial match
MPS-SV Maturity Levels CMMI-SVC Maturity Levels
A – In Optimization 5 – In Optimization
B – Quantitatively Managed 4 – Quantitatively ManagedC – Defined 3 – Defined+/- … partial match
- … poor matchC Defined
D – Largely Defined
E – Partially Defined
3 Defined
F – Managed
G – Partially Managed
2 – Managed
8 See references for the software process approaches in the reference section.
VDE 3695 process improvement process
Software process assessment levels
B1: Continuous Data Collection From Engineering Environments – The Heterogeneity IssueEnvironments – The Heterogeneity Issue
Data sources in engineering environments are often heterogeneous, .e.g.1 Tool chains and disciplines in systems engineering1. Tool chains and disciplines in systems engineering,2. Business software development project consortium, 3. Disciplines in game development process.
2
1
3
9
Challenges from Heterogenity in the Engineering Process of Industrial Production PlantsProcess of Industrial Production Plants
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.
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);
A1A3
A2 Software product lines in an organization (VDE 3695); A3 Software ecosystems in a business domain (SECO).
E i i l i d i t
A2
Engineering process analysis and improvement according to VDE 3695.
B1 Data integration for process support and analysis;
B2
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.
B3
Lessons learned from case studies with research and industry partnersProject Monitoring & ControlQM & Defect Detection
Process Definition & Analysis
100%
B1
110%
20%
40%
60%
80%
Phase 1.1 Phase 1.2 Phase 1.3
Sha
re o
f Cha
nges
bas
ed o
n C
heck
-In D
ata
[%]
Check-in Phases
- Rejected Signals - Accepted Changes - Similar SignalsAutomation Service Bus ©
CDL “Flex Improvements” Case Studieswith Focus On Process-Level Challenges
B2
with Focus On Process-Level Challenges
B1 Data integration for process support and analysis B2 Organization of reusable semi finished products
B3
B2 Organization of reusable semi-finished products B3 Eliciting and sharing engineering know-how
1. Quality-Assured Tool Chains: Semantic Dropbox2. Project Overview with the Engineering Cockpit 3 E l D f t D t ti
B1 B2 B3
B1 B2 B3
3. Early Defect Detection4. Engineering Process Analysis5. Reuse of Software Artifacts and Expert Know-How
B1 B2 B3
B1 B2 B3
B1 B2 B3
B1B1B1
12 Automation Service Bus and Data Integration Environment
Case Study: Quality-Assured Tool Chains: Semantic Dropbox – Context & IssuesSemantic Dropbox – Context & Issues
Tool chains link engineering process activities Multitude of models and tools used by engineers management and customers Multitude of models and tools used by engineers, management, and customers
Implementation often only as manual activities or fragile constructs, e.g., scripts. I i t k lt i t f t i t Issues: version management, work culture in systems of systems environments.
Issue: visibility of process information from heterogeneous data sources.
Eff t d f i dli f lit t ll d ti f h Effort and user friendliness for quality-controlled propagation of changes in heterogeneous software data models needs to be improved.
Typical common concepts in industrial plant engineering.Partial views on selected tool chains across disciplines.13
Case Study: Quality-Assured Tool Chains: Semantic Dropbox – ApproachSemantic Dropbox – Approach
The Semantic Dropbox provides traceable and automated propagation of changes 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. y p j p p transforms data between local representations of common
concepts, so each project participant sees the representations of common concepts in his local representation format.
Process Engineer
Mechanical equipment properties
R i t Semantic Dropbox scenario
Software Engineer
ElectricalEngineer
Transmission linesTerminal points
Data TypesLogical Behavior
RequirementsLocation IDsComponents
Interfaces
Machine vendor catalogue
Tool A Data Model Tool B Data Model
Terminal points Logical Behavior
Tool C Data ModelSignals (I/O)
Model Mapping Tool A – Domain
Derived Mapping
Common concept
Signals (I/O)
14Typical 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
InformationAnalog 0 to 10 VX.22.2.1Domain/project data model
Derived MappingTool A – Tool B
Models
Case Study: Quality-Assured Tool Chains: Semantic Dropbox – Contribution & ImprovementSemantic Dropbox – Contribution & Improvement
Process improvements at software and systems engineering organizations1 Domain experts can produce traceable and secure tool chains easily1. 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 e ternal project partnersfrom external project partners.
1 2
Change propagation in a heterogeneous environment.15
Semantic Dropbox scenario
3 4
Case Study: Quality-Assured Tool Chains: Semantic Dropbox – Lessons LearnedSemantic 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 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 facilitatesThe 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.
Change propagation between Excel and XML representations. Semantic Dropbox scenario16
Case Study: Project Overview with the Engineering Cockpit – Context & IssuesEngineering Cockpit – Context & Issues
Data sets of systems-of-systems engineering groups evolve concurrently, often without project-wide version management and progress tracking.p j g p g g
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.
Heterogeneous data sources without effective data integration17
Case Study: Project Overview with the Engineering Cockpit – ApproachEngineering Cockpit – Approach
Collect and integrate data from engineering teams and processes Web application Engineering Cockpit” provides 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 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 j p p g qin 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.
Integrated view on heterogeneous data sources with the Engineering Cockpit.18
Case Study: Project Overview with the Engineering Cockpit – Contribution & ImprovementEngineering Cockpit – Contribution & Improvement
The Engineering Cockpit provides engineers and managers with a platform to organize and perform specific tasks across domain and tools 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.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 connectedWhich 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
Engineering Cockpit: Project Management Overview
Project Status OverviewRole-based Role-basedProject Status OverviewProject View Events
Project RelatedStakeholders
Role-basedStatus & Applications
20
Signal Overview
Case Study: Project Overview with the Engineering Cockpit – Lessons LearnedEngineering Cockpit – Lessons Learned
Engineering Cockpit: role-oriented dashboard and activity options, in particular, for project and quality management, on recent and integrated data.p , p j q y g , g
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
21Project progress and risk indicators based on integrated data from engineering teams and tools.
Case Study: Early Defect Detection in Heterogeneous Environments – Context & IssuesHeterogeneous Environments – Context & Issues
Collaboration of engineers in a heterogeneous engineering environment, e.g., electrical, mechanical, software, and process engineers.g , , , , p g
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 qualitysoftware variables, to improve engineering product quality, e.g. “end-to-end” consistency checks.
22Challenge 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.
Case Study: Early Defect Detection in Heterogeneous Environments – ApproachHeterogeneous 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 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 onAutomated end to end consistency checking and system testing based on
early defect detection approaches and “test-first” development.
Reviews of changes. Automated test run.
23End-to-end test.
Case Study: Early Defect Detection in Heterogeneous Environments – ImprovementHeterogeneous Environments – Improvement
Engineering Process Improvement with defect detection and data collection. Early defect detection based on integrated data from heterogeneous data sources 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– Basis for automated end-to-end consistency checks.
Efficient defect detection in early phases of systems development based on semantic technologies.
Example Query Result (S1, “pressure”, “mbar”, C1, ( p
V_A, “pressure”, “mbar”) (S4, “pressure”, “mbar”, C3,
V_B, “temperature”, “kelvin”)
SELECT ?Electric_ID, el:desc, e
(S2, “level”, “cm”, C5, V_C, “level”, “m”)
Mapping of local data models to
24
_?Config_ID, ?SW_ID, sw:des
WHERE {el:E_short ekb:mapsTo ?Electric_ID.
gcommon data models
Case Study: Early Defect Detection in Heterogeneous Environments – Lessons LearnedHeterogeneous Environments – Lessons Learned
Semantic data integration helps to mitigate defects and risks from inconsistent engineering plans in distributed engineering projects.g g p g g p j
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.
Reviews of changes.
2525Reviews of changes at interfaces of several engineering scopes.Derivation of
end-to-end test cases.
Case Study: Engineering Process Analysis –Context & IssuesContext & Issues
Engineering process analysis and improvement according to VDE 3695 (domain and project model)g ( p j )
Continuous observation and improvement of workflows and engineering processes.
Basic Steps: (1) Definition, (2) Implementation, (3) Data collection, and (4) Workflow evaluation.
(1) Workflow definition (2) Implementation
WorkflowEngine
26(3) Data capturing(4) Workflow evaluation
Sunindyo W.D., Moser T., Winkler D.: “Process Model Validation for Heterogeneous Engineering Environments”, Software Quality Days 2012.
Case Study: Engineering Process Analysis –ApproachApproach
Engineering Process Observation and Analysis Framework.y
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 T f ti t2. Transformation to a more
formal representation3. Derivation and Implementation of rules
in the workflow engine e g the ASBin the workflow engine, e.g., the ASB.4. Event Data Capturing with log files.5. Expected Process modeled with PRoM6 Evaluation of the expected process definition6. 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.
Case Study: Engineering Process Analysis –Contribution & ImprovementContribution & Improvement
Automated data collection based on executed process steps. Foundation for verification and validation of workflows and processes Foundation for verification and validation of workflows and processes.
– Conformance of executed process steps with real process data (PRoM).
F d ti f i d th l i t id tif i i b ttl k– Foundation for in-depth analysis to identify engineering process bottlenecks based on advanced engineering process analysis.
Sta
rt
mpl
ete
Sta
rt
mpl
ete
Sta
rt
mpl
ete
S
Com S
Com S
Com
28Sunindyo W.D., Moser T., Winkler D.: “Process Model Validation for Heterogeneous Engineering Environments”, Software Quality Days 2012.
Case Study: Engineering Process Analysis –Lessons LearnedLessons Learned
Comprehensive and efficient engineering process observation and analysis. Process model evaluation with PRoM enables fast and efficient feedback 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.
Prototype/ProductMaturityMaturity
Key Stakeholders
Agile Eng. Process with Scrum Extensions
Key Deliverables
Product prototyping process.29
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.
Collective Intelligence – Overview & Example
Collective Intelligence (CI) Phenomenon: Group intelligence that emerges from Phenomenon: Group intelligence that emerges from
collaboration, collective action, and competitionof many individuals.
Areas: business, sociology, and computer science. omAreas: business, sociology, and computer science.
CI and IT Achieved by hybrid systems in which humans and
(CC
) Sto
ckM
onke
ys.c
o
Achieved by hybrid systems in which humans and computers interoperate and complement each others capabilities.
Potential for highly effective collection and distribution of knowledge.
Used for Crowdsourcing, Social Web/Media,Social/Cognitive/Human Computing.
Successful CI system examples in SW engineering– Github (code repositories)– Stackoverflow (questions & answers)– TopCoder (coding contests)
30
Collective Intelligence Systems Research
Investigate and build applications on CI Principles1 Enabling organizations to reorganize work in new ways1. 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 work3. Support approaches, which propagate to build on work
already being done by others instead of reinventing the wheel.
Research areas of interest Foundation research on new kinds of software
architectures.(C) iStockPhoto
– 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 Process Improvement: Coordinated bottom-up, emergent workflow mechanisms and process risk management.
31
Case Study: Reuse of Software Artifacts andExpert Know-How – Context & IssuesExpert Know-How – Context & Issues
Q: How to make reuse and expert know-how sharing activities beneficial both for the project and theactivities beneficial both for the project and the organization?
Limitations of typical reuse and sharing scenarios: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.y pp3. 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.p Issue must be addressed on project-independent level.
(cc) seantoyer
32
Case Study: Reuse of Software Artifacts andExpert Know-How – ApproachExpert Know-How – Approach
Steps1 Identify main workflow limitations1. Identify main workflow limitations
of mission-critical actors, e.g., dispersed local engineering know how.
2. Identify artifacts of interest,2. Identify artifacts of interest,e.g. requirements, solution elements, and reorganize them in a structured pool.
3. Actors perform contribution activity 2 4
5(create, modify, review artifact) which codifies content and knowledge.
4. Mine relevant contributions from artifacts in the pool to create behavioral triggers for actors
35
to create behavioral triggers for actors e.g., notifications or signals.
5. Actors with incentive perform contribution activities creatingcontribution activities, creating a constant flow of new contributions and triggers.
6. Continue with step 3. Store
33 UseDevelop
Case Study: Reuse of Software Artifacts andExpert Know-How – ContributionExpert Know-How – Contribution
Software Reuse and Sharing System Web platform which orchestrates reuse and know 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.Aggregates artifacts and knowledge about them.
Key Capabilities & Improvements1 Structured adding and storing of artifacts1. 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,anduser-driven recommendations.
ehrin
g
Bottom-up emergent coordination. Recommendation: Help engineers to
identify best-fitting artifacts.
(cc)
Dav
id G
oe
34(c
c) C
ory
Doc
torw
Example: Github Collaborative, global source code
repository platform.
1 C d i ib i i GIT1. 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 project1 2
activity monitoring, developer and project discovery.
Analyze forksand contributions 2 Mark and build upon 1and contributions 2
Connect with developers
Analyze activity level 2
p
3
Analyze activity level 2
Explore new projects 3
35
Case Study: Reuse of Software Artifacts andExpert Know-How – Lessons LearnedExpert Know-How – Lessons Learned
Reusable assets are a well-structured basis for product-focused development.p p
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”all relevant engineering know-howwithout considering CI systems success & risk factors.
36
Software Artifact Reuse and Expert Know-How Elicitation and Sharing – OutlookElicitation and Sharing – Outlook
How to make reuse and knowledge sharing activities beneficial both for the project and the organization?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– Establish knowledge management for mission-critical know-how.
Integrated Process Improvement ApproachIntegrated Process Improvement Approach– Combination of both software architecture and
process improvement.– Enhanced, bottom-up workflows based on theEnhanced, 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 d b l d i i
37
created by external partners and communities.
Lessons Learned on Product-Focused Engineering Process Analysis and ImprovementProcess Analysis and Improvement
Challenges with families of products and systems-of-systems environments Heterogeneity of local data models in systems and engineering tools 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.
C ti d t ll ti bl i i l i 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 investigatedseems promising and should be investigated in a variety of application contexts.
38
Summary – Product-Focused Engineering Process Analysis and ImprovementProcess Analysis and Improvement
Stakeholders want repeatable and flexible product development. Software process approaches are helpful 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, VDE 3695 process modelIndustry trends such as Enterprise 2.0, the Industry 4.0 initiative in Germany, andthe European Union “Horizon 2020” program emphasize the investigation of new approaches such as
iti d i t lli t t f k i l k
VDE 3695 process model
cognition and intelligent support for workers in complex work spacessystematic design of collective intelligence systems for specific applications.
Research case studies with industry partners discussed solution approaches 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 Visit us online at http://cdl.ifs.tuwien.ac.at
39Data and tool integration Applications based on integrated data. Collective Intelligence Applications.
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., p
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 USAthe 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, 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)Work. In Proc. 2013 Conf. on Computer Supported Cooperative Work (CSCW 13) (pp. 1301 1317). Malone, T. W., Laubacher, R., & Dellarocas, C. (2009). 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.
40
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.
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 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., 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.
Capability Maturity Model Integration, CMMI Institute, Carnegie Mellon University, http://cmmiinstitute.com/. C S S C f G f 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 Practices 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
R h d ti P iti P BPM W k h S i 2007Research and practice, Position Paper, BPM Workshops, Springer, 2007. Sommerville I.: Software Engineering, Addison-Wesley Longman, 9th edition, 2010. Sunindyo W.D., Moser T., Winkler D.: “Process Model Validation for Heterogeneous Engineering Environments”, Software Quality Days 2012. VDI/VDE 3695 : 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.2010Application ,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
41
Projects", Proceedings of the 20th EuroSPI Conference, Dundalk, Irelande, 25.-27.06.2013.