Lessons Learned from Empirical IESE Dieter Rombach ISERN WS 2005 Noosa Heads, 14 November 2005.

Slides:



Advertisements
Similar presentations
Trusted Computing in Government Networks May 16, 2007 Richard C. (Dick) Schaeffer, Jr. Information Assurance Director National Security Agency.
Advertisements

Test Automation Success: Choosing the Right People & Process
Unit 2. Software Lifecycle
SECOND MIDTERM REVIEW CS 580 Human Computer Interaction.
September 30, 2011 OASIS Open Smart Grid Reference Model: Standards Landscape Analysis.
7.1 A Bridge to Design & Construction
The Experience Factory May 2004 Leonardo Vaccaro.
Chapter 2.
1 SOFTWARE LIFE-CYCLES Beyond the Waterfall. 2 Requirements System Design Detailed Design Implementation Installation & Testing Maintenance The WATERFALL.
A Prototyping Lifecycle. The Waterefall Model and Prototyping 4 As early as the 1980’s the classic “Waterfall model” of software development was criticised.
Presentation By: Chris Wade, P Eng. Finally … a best practice for selecting an engineering firm.
185 Final Project (Also covers Project Proposal and Document Specification)
A DAPT IST Composite Services Gustavo Alonso Swiss Federal Institute of Technology (ETHZ) Zürich, Switzerland.
CSE USC Fraunhofer USA Center for Experimental Software Engineering, Maryland February Empiricism in Software Engineering Empiricism:
1 Educational Experiences with F/OSS Development Projects: Helping the Inmates Take Over the Asylum Walt Scacchi Institute for Software Research University.
Professor Michael J. Losacco CIS 1150 – Introduction to Computer Information Systems Systems Analysis and Design Chapter 12.
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 2 Introduction to Database Development.
Performance Measurement and Strategic Information Management
Organizational Influences and Life Cycle
8 Systems Analysis and Design in a Changing World, Fifth Edition.
Embedding Security into a Software Development Methodology April 5 th, 8:30 AM Jonathan Minter Director, IT Development and Engineering Liberty University.
BPT 3113 – Management of Technology
185 Final Project (Also covers Project Proposal and Document Specification)
Office of Information Technology (OIT) PROJECT INITIATION DOCUMENTS - BUSINESS CASE, ALTERNATIVE ANALYSIS AND STATEMENT OF WORK (SOW)
Factors influencing open source software adoption
ISERN-Meeting, Honolulu, Hawaii 09 October 2000 Slide 0 Using Experiments to Teach Software Engineering Using Experiments to Teach Software Engineering.
S/W Project Management
Unit 2: Engineering Design Process
Reorganization at NCAR Presentation to the UCAR Board of Trustees February 25, 2004.
Institut Experimentelles Software Engineering Fraunhofe r IESE Andreas Birk Ulrike Becker-Kornstaedt Sauerwiesen 6 D Kaiserslautern Germany Experience.
Case Study on how the Navy DASN Acquisition Cut Allocated Web Technology Budget by Two- Thirds.
ISERN Open Issues, Grand Challenges or Have we made any progress and where are going? Vic Basili 2001.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
PPMT CE-408T Engr. Faisal ur Rehman CED N-W.F.P UET P.
Template for ISERN Instructions:  Keep your main message short and clear: you can discuss the details in person or provide additional background material.
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
Research in Computing สมชาย ประสิทธิ์จูตระกูล. Success Factors in Computing Research Research Computing Knowledge Scientific MethodAnalytical Skill Funding.
Software Requirements Engineering CSE 305 Lecture-2.
Requirements Engineering Requirements Elicitation Process Lecture-8.
SG - OSG Improving Campus Research CI Through Leveraging and Integration: Developing a SURAgrid-OSG Collaboration John McGee, RENCI/OSG Engagement Coordinator.
Communication 2 Report Writing.
Experimentation in Computer Science (Part 1). Outline  Empirical Strategies  Measurement  Experiment Process.
Environmental Management System Definitions
CS 111 – Nov. 22 Chapter 7 Software engineering Systems analysis Commitment –Please read Section 7.4 (only pp ), Sections –Homework #2.
Building and Recognizing Quality School Systems DISTRICT ACCREDITATION © 2010 AdvancED.
SWEN 5130 Requirements Engineering 1 Dr Jim Helm SWEN 5130 Requirements Engineering Requirements Management Under the CMM.
Ajh January 2007 CCSDS “Books” Adrian J. Hooke CMC Meeting, Colorado Springs 26 January 2007.
ISERN Survey & Benchmark 10 th anniversary meta-experiment project Session Chair, Stefan Biffl Marcus Ciolkowski, Forrest Shull, and Dieter Rombach 1.Strategy.
Chapter 4 Developing and Sustaining a Knowledge Culture
Selecting Evidence Based Practices Oregon’s initial attempts to derive a process Implementation Conversations 11/10.
DOCUMENT #:GSC15-PLEN-82r2 FOR:Presentation SOURCE:ATIS AGENDA ITEM: PLEN 6.14 CONTACT(S): Andrew White ATIS’
Requirements / Specifications. 01/18/10CS-499G2 Requirements Determine what the customer needs (wants) the software to do  What are requirements?  An.
Software Project Management (SEWPZG622) BITS-WIPRO Collaborative Programme: MS in Software Engineering SECOND SEMESTER /1/ "The content of this.
MITM743 Advanced Project Management Dr. Abdul Rahim Ahmad Assoc. Professor College of IT, UNITEN Kerzner Chapter 4 Project Management Methodologies.
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at:  php (1994)
IFIP TC5 Working Group 5.4 Computer Aided Innovation Objectives: The Working Group will: – Identify the different existing approaches – Share opinions,
Are you looking for an opportunity to join a company that has a long history and an exciting future? A place where you can grow within an international.
Requirements Engineering Processes, York EngD Programme, 2009Slide 1 Requirements engineering processes Prof Ian Sommerville.
OUTCOMES OBJECTIVES FUNCTIONS ACTIONS TERRITORIES LOCATIONS MARKET SEGMENTS TIME LINESCHALLENGE IMPACT RESOURCESACTIVITIESCHANNELS RELATIONS PARTNERS CUSTOMERS.
1 Requirements Elicitation – 2 Lecture # Requirements Engineering Process Requirements Elicitation Requirements Analysis and Negotiation Requirements.
Systems Analysis & Design 7 th Edition Chapter 2.
Introduction to Software Requirement Engineering Nisa’ul Hafidhoh Teknik Informatika
Driving Innovation V Power electronics – Enabling a resilient energy system, KTP thematic competition Christian Inglis – energy supply team Creating.
Systems Analysis and Design in a Changing World, Fifth Edition
Scoping a research project
Technical Communication: Foundations
SOFTWARE LIFE-CYCLES Beyond the Waterfall.
Class Project Guidelines
Projects, Assignments, and other Assessments
Chapter 26 Estimation for Software Projects.
Presentation transcript:

Lessons Learned from Empirical IESE Dieter Rombach ISERN WS 2005 Noosa Heads, 14 November 2005

Page 2/9 Noosa Heads Nov. 2005Dieter Rombach Guidelines for Empirical Studies ’05 Background Fraunhofer IESE (Institute for Experimental Software Engineering) IESE Mission Statement -Provide innovative and value-adding customer solutions with measurable effects - Advance the state-of-the art in software & system engineering - Promote the importance of empirically based software & system engineering Reality -Constant struggle to convince researchers that empirical investigation is NOT a “some times”, but a constant driver of research  All research areas have to be augmented with empirical results & hypotheses for future research  Both from a company customer & research perspective

Page 3/9 Noosa Heads Nov. 2005Dieter Rombach Guidelines for Empirical Studies ’05 Lessons learned (1 of 7): Education & Coaching Continuous education (and coaching) is necessary -Non-software engineer  software engineering conversion is hard -Software engineer  empirical software engineer is “super hard” -Regular class on “Empirical Model Building & Methods” university  Mandatory for all new IESE employees  Mandatory for all students in CS PhD program -Guidelines for project set-up & touch-down -Clearinghouse for empirical studies within IESE  Definition & design of study  Pre-publication review

Page 4/9 Noosa Heads Nov. 2005Dieter Rombach Guidelines for Empirical Studies ’05 Lessons learned (2 of 7): Empirical Research Motivation (PhD) Problem definition (e.g., Cycle-time to long) Feasibility Analysis (e.g., do questions address typical req. Defect classes?) Research (e.g., develop PBR for req‘s) Research proposal (e.g., develop PBR for req‘s to increase effectiveness) Research Testing (e.g., does PBR find more defects than X?) Problem Testing (e.g., does PBR – integrated into a lifecycle model contribute to reduced cycle time? Not necessary for completely automated processes (e.g., test data gen.) Always necessary in SE to check user acceptability

Page 5/9 Noosa Heads Nov. 2005Dieter Rombach Guidelines for Empirical Studies ’05 Lessons learned (3 of 7): Self-Confidence Not every paper has to contain 2 pages of justification of empirical research! Present results directly -Most results chapters can only be understood after major “reverse engineering effort” -Afraid to say “we observed that method A finds more defects of type X than method B” (because it is only true in context)  This is not a plea for unjustified generalization  It is a plea for top-down presentation (results first, then constraints) Provide better integration into state of research (aggregation) -Leads otherwise to rejection of replications in community, because variation is hidden! Include stronger “new” hypotheses in sections on “future directions”

Page 6/9 Noosa Heads Nov. 2005Dieter Rombach Guidelines for Empirical Studies ’05 Lessons learned (4 of 7): Context for Cross- Analysis We need to document MORE than one’s own study scope (dependent & independent variables), but what???, to explain inconsistencies between replicated studies Best addressed within some organization which defines scope (experiment line) of studies -IESE: defined by company needs (e.g., in automotive domain: objectives, major organizational, project & technology variations) -ISERN community??? f (M, C1) =/= g (M, C1)

Page 7/9 Noosa Heads Nov. 2005Dieter Rombach Guidelines for Empirical Studies ’05 Lessons learned (5 of 7): Documentation Clear standard to be IESE -based on “Wohlin” book -Minimal documentation requirements  Goals (method & usage for customers)  Variables (& IESE context)  Design  Data characterization & analysis  Data interpretation  Validity  Usage (trustability, sharing, new hypotheses) -Context provided by “IESE Business Analysis” Adherence coached & approved by Clearinghouse! Top Challenges

Page 8/9 Noosa Heads Nov. 2005Dieter Rombach Guidelines for Empirical Studies ’05 Lessons learned (6 of 7): Industrial Interest Increasing due to major challenges -Ultra-large systems (e.g., automotive industry) -Dependability (e.g., unexpected feature interactions in large systems) -Distributed development (across different cultures) -High risk of technology adoption (e.g., product lines) Controlled prototype development (industrial case studies =/= controlled experiments!!!) -Highest possible reality (company products, company staff) -Joint evaluation projects (“Research Labs”) -Leads to Business Case for company decision Examples -Bosch, Ricoh, … (software product lines) -Bosch (automated testing): together with J. Poore Possibility for joint collaboration (see J. Poore on Bosch testing study)

Page 9/9 Noosa Heads Nov. 2005Dieter Rombach Guidelines for Empirical Studies ’05 Lessons learned (7 of 7): Grant Lobbying Empirical Research MUST be part of SE funding programs Success in German Federal Program “SE 2006” -All projects must perform evaluation -All results have to be submitted to national SE portal (VSEK) managed by IESE and some other Fraunhofer institutes Plan to establish a “Software Engineering for Embedded Systems” network across other business domains within Fraunhofer (Lead: P. Liggesmeyer) -Materials -Microelectronics -Production technology -GRID