Workshop RCoSE 2014 – Author Index |
Contents -
Abstracts -
Authors
|
| Alperowitz, Lukas |
RCoSE '14: "Rugby: An Agile Process Model ..."
Rugby: An Agile Process Model Based on Continuous Delivery
Stephan Krusche, Lukas Alperowitz, Bernd Bruegge, and Martin O. Wagner (TU München, Germany) In this paper we introduce Rugby, an agile process model that includes workflows for the continuous delivery of software. It allows part-timers to work in a project-based organization with multiple projects for the rapid delivery of prototypes and products. We show how continuous delivery improves the development process in two ways: First, Rugby improves the interaction between developers and customers with a continuous feedback mechanism. Second, Rugby improves the coordination and communication with stakeholders and across multiple teams in project-based organizations with event based releases. We have evaluated Rugby in two large university software engineering capstone courses with up to 100 participants working in 10 simultaneous projects with industry partners in 2012 and 2013. We describe the metrics used in the evaluation. First results indicate that Rugby increases the frequency and quality of the interaction between developers and customers leading to improved results in the delivered products. 
@InProceedings{RCoSE14p42,
author = {Stephan Krusche and Lukas Alperowitz and Bernd Bruegge and Martin O. Wagner},
title = {Rugby: An Agile Process Model Based on Continuous Delivery},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {42--50},
doi = {},
year = {2014},
}
|
|
| Ayed, Hajer |
RCoSE '14: "Supported Approach for Agile ..."
Supported Approach for Agile Methods Adaptation: An Adoption Study
Hajer Ayed, Benoît Vanderose, and Naji Habra (University of Namur, Belgium) Adopting agile software development methods is a wide and complex organisational change that usually impacts several aspects of the organisation (e.g., its structure, culture, management practices, produced artefacts, technologies in use, etc). In order to successfully handle the several key challenges, it's crucial to understand the organisation context and carefully study the transformation strategies. This paper presents an agile transformation experience that has been undertaken in a public organisation in Belgium and during which Scrum was applied in two pilot projects. The first project retrospective shows that the change cannot be accomplished only at the team-level without taking into account the overall structure of the organisation and that we must carefully evolve toward a context-specific adapted method. In the second pilot project, we defined structured and repeatable steps to assist the adoption of agile practices. The experience shows the usefulness of such an approach but suggests that automation efforts should be addressed. The last section of the paper summarizes the issues encountered and presents the AM-QuICK framework which aims at providing a supported approach to guide the agile adoption, adaptation and assessment.
@InProceedings{RCoSE14p36,
author = {Hajer Ayed and Benoît Vanderose and Naji Habra},
title = {Supported Approach for Agile Methods Adaptation: An Adoption Study},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {36--41},
doi = {},
year = {2014},
}
|
|
| Belk, Marios |
RCoSE '14: "Personalised Continuous Software ..."
Personalised Continuous Software Engineering
Efi Papatheocharous, Marios Belk, Jaana Nyfjord, Panagiotis Germanakos, and George Samaras (SICS, Sweden; University of Cyprus, Cyprus; SAP, Germany) This work describes how human factors can influence continuous software engineering. The reasoning begins from the Agile Manifesto promoting individuals and interactions over processes and tools. The organisational need to continuously develop, release and learn from software development in rapid cycles requires empowered and self-organised agile teams. However, these teams are formed without necessarily considering the members’ individual characteristics towards effective teamwork, from the personality and cognitive perspective. In this realm, this paper proposes a two level approach: first, form teams based on their collective personality traits and second, provide personalised tools and methods based on their individual differences in cognitive processing. The approach is motivated by a study conducted in a business environment focusing on task execution, satisfaction and effectiveness of team members in relation to their personalities and cognitive characteristics. Our preliminary results show that human factors provide a promising basis for increasing the capability of continuous software engineering.
@InProceedings{RCoSE14p57,
author = {Efi Papatheocharous and Marios Belk and Jaana Nyfjord and Panagiotis Germanakos and George Samaras},
title = {Personalised Continuous Software Engineering},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {57--62},
doi = {},
year = {2014},
}
|
|
| Bruegge, Bernd |
RCoSE '14: "Rugby: An Agile Process Model ..."
Rugby: An Agile Process Model Based on Continuous Delivery
Stephan Krusche, Lukas Alperowitz, Bernd Bruegge, and Martin O. Wagner (TU München, Germany) In this paper we introduce Rugby, an agile process model that includes workflows for the continuous delivery of software. It allows part-timers to work in a project-based organization with multiple projects for the rapid delivery of prototypes and products. We show how continuous delivery improves the development process in two ways: First, Rugby improves the interaction between developers and customers with a continuous feedback mechanism. Second, Rugby improves the coordination and communication with stakeholders and across multiple teams in project-based organizations with event based releases. We have evaluated Rugby in two large university software engineering capstone courses with up to 100 participants working in 10 simultaneous projects with industry partners in 2012 and 2013. We describe the metrics used in the evaluation. First results indicate that Rugby increases the frequency and quality of the interaction between developers and customers leading to improved results in the delivered products.
@InProceedings{RCoSE14p42,
author = {Stephan Krusche and Lukas Alperowitz and Bernd Bruegge and Martin O. Wagner},
title = {Rugby: An Agile Process Model Based on Continuous Delivery},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {42--50},
doi = {},
year = {2014},
}
|
|
| Fagerholm, Fabian |
RCoSE '14: "Building Blocks for Continuous ..."
Building Blocks for Continuous Experimentation
Fabian Fagerholm, Alejandro Sanchez Guinea, Hanna Mäenpää, and Jürgen Münch (University of Helsinki, Finland) Development of software-intensive products and services increasingly occurs by continuously deploying product or service increments, such as new features and enhancements, to customers. Product and service developers need to continuously find out what customers want by direct customer feedback and observation of usage behaviour, rather than indirectly through up-front business analyses. This paper examines the preconditions for setting up an experimentation system for continuous customer experiments. It describes the building blocks required for such a system. An initial model for continuous experimentation is analytically derived from prior work. The model is then matched against empirical case study findings from a startup company and adjusted. Building blocks for a continuous experimentation system and infrastructure are presented. A suitable experimentation system requires at least the ability to release minimum viable products or features with suitable instrumentation, design and manage experiment plans, link experiment results with a product roadmap, and manage a flexible business strategy. The main challenges are proper and rapid design of experiments, advanced instrumentation of software to collect, analyse, and store relevant data, and the integration of experiment results in both the product development cycle and the software development process.
@InProceedings{RCoSE14p26,
author = {Fabian Fagerholm and Alejandro Sanchez Guinea and Hanna Mäenpää and Jürgen Münch},
title = {Building Blocks for Continuous Experimentation},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {26--35},
doi = {},
year = {2014},
}
|
|
| Femmer, Henning |
RCoSE '14: "Rapid Requirements Checks ..."
Rapid Requirements Checks with Requirements Smells: Two Case Studies
Henning Femmer, Daniel Méndez Fernández, Elmar Juergens, Michael Klose, Ilona Zimmer, and Jörg Zimmer (TU München, Germany; CQSE, Germany; Wacker Chemie, Germany; MBtech Group, Germany; Daimler, Germany) Bad requirements quality can have expensive consequences during the software development lifecycle. Especially, if iterations are long and feedback comes late - the faster a problem is found, the cheaper it is to fix. We propose to detect issues in requirements based on requirements (bad) smells by applying a light-weight static requirements analysis. This light-weight technique allows for instant checks as soon as a requirement is written down. In this paper, we derive a set of smells, including automatic smell detection, from the natural language criteria of the ISO/IEC/IEEE 29148 standard. We evaluated the approach with 336 requirements and 53 use cases from 9 specifications that were written by the car manufacturer Daimler AG and the chemical business company Wacker Chemie AG, and discussed the results with their requirements and domain experts. While not all problems can be detected, the case study shows that lightweight smell analysis can uncover many practically relevant requirements defects. Based on these results and the discussion with our industry partners, we conclude that requirements smells can serve as an efficient supplement to traditional reviews or team discussions, in order to create fast feedback on requirements quality.
@InProceedings{RCoSE14p10,
author = {Henning Femmer and Daniel Méndez Fernández and Elmar Juergens and Michael Klose and Ilona Zimmer and Jörg Zimmer},
title = {Rapid Requirements Checks with Requirements Smells: Two Case Studies},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {10--19},
doi = {},
year = {2014},
}
|
|
| Fernández, Daniel Méndez |
RCoSE '14: "Rapid Requirements Checks ..."
Rapid Requirements Checks with Requirements Smells: Two Case Studies
Henning Femmer, Daniel Méndez Fernández, Elmar Juergens, Michael Klose, Ilona Zimmer, and Jörg Zimmer (TU München, Germany; CQSE, Germany; Wacker Chemie, Germany; MBtech Group, Germany; Daimler, Germany) Bad requirements quality can have expensive consequences during the software development lifecycle. Especially, if iterations are long and feedback comes late - the faster a problem is found, the cheaper it is to fix. We propose to detect issues in requirements based on requirements (bad) smells by applying a light-weight static requirements analysis. This light-weight technique allows for instant checks as soon as a requirement is written down. In this paper, we derive a set of smells, including automatic smell detection, from the natural language criteria of the ISO/IEC/IEEE 29148 standard. We evaluated the approach with 336 requirements and 53 use cases from 9 specifications that were written by the car manufacturer Daimler AG and the chemical business company Wacker Chemie AG, and discussed the results with their requirements and domain experts. While not all problems can be detected, the case study shows that lightweight smell analysis can uncover many practically relevant requirements defects. Based on these results and the discussion with our industry partners, we conclude that requirements smells can serve as an efficient supplement to traditional reviews or team discussions, in order to create fast feedback on requirements quality.
@InProceedings{RCoSE14p10,
author = {Henning Femmer and Daniel Méndez Fernández and Elmar Juergens and Michael Klose and Ilona Zimmer and Jörg Zimmer},
title = {Rapid Requirements Checks with Requirements Smells: Two Case Studies},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {10--19},
doi = {},
year = {2014},
}
|
|
| Fitzgerald, Brian |
RCoSE '14: "Continuous Software Engineering ..."
Continuous Software Engineering and Beyond: Trends and Challenges
Brian Fitzgerald and Klaas-Jan Stol (Lero, Ireland; University of Limerick, Ireland) Throughout its short history, software development has been characterized by harmful disconnects between important activities e.g., planning, development and implementation. The problem is further exacerbated by the episodic and infrequent performance of activities such as planning, testing, integration and releases. Several emerging phenomena reflect attempts to address these problems. For example, the Enterprise Agile concept has emerged as a recognition that the benefits of agile software development will be sub- optimal if not complemented by an agile approach in related organizational function such as finance and HR. Continuous integration is a practice which has emerged to eliminate discontinuities between development and deployment. In a similar vein, the recent emphasis on DevOps recognizes that the integration between software development and its operational deployment needs to be a continuous one. We argue a similar continuity is required between business strategy and development, BizDev being the term we coin for this. These disconnects are even more problematic given the need for reliability and resilience in the complex and data-intensive systems being developed today. Drawing on the lean concept of flow, we identify a number of continuous activities which are important for software development in today’s context. These activities include continuous planning, continuous integration, continuous deployment, continuous delivery, continuous verification, continuous testing, continuous compliance,continuous security, continuous use, continuous trust, continuous run-time monitoring, continuous improvement (both process and product), all underpinned by continuous innovation. We use the umbrella term, ``Continuous *'' (continuous star) to identify this family of continuous activities.
@InProceedings{RCoSE14p1,
author = {Brian Fitzgerald and Klaas-Jan Stol},
title = {Continuous Software Engineering and Beyond: Trends and Challenges},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {1--9},
doi = {},
year = {2014},
}
|
|
| Germanakos, Panagiotis |
RCoSE '14: "Personalised Continuous Software ..."
Personalised Continuous Software Engineering
Efi Papatheocharous, Marios Belk, Jaana Nyfjord, Panagiotis Germanakos, and George Samaras (SICS, Sweden; University of Cyprus, Cyprus; SAP, Germany) This work describes how human factors can influence continuous software engineering. The reasoning begins from the Agile Manifesto promoting individuals and interactions over processes and tools. The organisational need to continuously develop, release and learn from software development in rapid cycles requires empowered and self-organised agile teams. However, these teams are formed without necessarily considering the members’ individual characteristics towards effective teamwork, from the personality and cognitive perspective. In this realm, this paper proposes a two level approach: first, form teams based on their collective personality traits and second, provide personalised tools and methods based on their individual differences in cognitive processing. The approach is motivated by a study conducted in a business environment focusing on task execution, satisfaction and effectiveness of team members in relation to their personalities and cognitive characteristics. Our preliminary results show that human factors provide a promising basis for increasing the capability of continuous software engineering.
@InProceedings{RCoSE14p57,
author = {Efi Papatheocharous and Marios Belk and Jaana Nyfjord and Panagiotis Germanakos and George Samaras},
title = {Personalised Continuous Software Engineering},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {57--62},
doi = {},
year = {2014},
}
|
|
| Guinea, Alejandro Sanchez |
RCoSE '14: "Building Blocks for Continuous ..."
Building Blocks for Continuous Experimentation
Fabian Fagerholm, Alejandro Sanchez Guinea, Hanna Mäenpää, and Jürgen Münch (University of Helsinki, Finland) Development of software-intensive products and services increasingly occurs by continuously deploying product or service increments, such as new features and enhancements, to customers. Product and service developers need to continuously find out what customers want by direct customer feedback and observation of usage behaviour, rather than indirectly through up-front business analyses. This paper examines the preconditions for setting up an experimentation system for continuous customer experiments. It describes the building blocks required for such a system. An initial model for continuous experimentation is analytically derived from prior work. The model is then matched against empirical case study findings from a startup company and adjusted. Building blocks for a continuous experimentation system and infrastructure are presented. A suitable experimentation system requires at least the ability to release minimum viable products or features with suitable instrumentation, design and manage experiment plans, link experiment results with a product roadmap, and manage a flexible business strategy. The main challenges are proper and rapid design of experiments, advanced instrumentation of software to collect, analyse, and store relevant data, and the integration of experiment results in both the product development cycle and the software development process.
@InProceedings{RCoSE14p26,
author = {Fabian Fagerholm and Alejandro Sanchez Guinea and Hanna Mäenpää and Jürgen Münch},
title = {Building Blocks for Continuous Experimentation},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {26--35},
doi = {},
year = {2014},
}
|
|
| Habra, Naji |
RCoSE '14: "Supported Approach for Agile ..."
Supported Approach for Agile Methods Adaptation: An Adoption Study
Hajer Ayed, Benoît Vanderose, and Naji Habra (University of Namur, Belgium) Adopting agile software development methods is a wide and complex organisational change that usually impacts several aspects of the organisation (e.g., its structure, culture, management practices, produced artefacts, technologies in use, etc). In order to successfully handle the several key challenges, it's crucial to understand the organisation context and carefully study the transformation strategies. This paper presents an agile transformation experience that has been undertaken in a public organisation in Belgium and during which Scrum was applied in two pilot projects. The first project retrospective shows that the change cannot be accomplished only at the team-level without taking into account the overall structure of the organisation and that we must carefully evolve toward a context-specific adapted method. In the second pilot project, we defined structured and repeatable steps to assist the adoption of agile practices. The experience shows the usefulness of such an approach but suggests that automation efforts should be addressed. The last section of the paper summarizes the issues encountered and presents the AM-QuICK framework which aims at providing a supported approach to guide the agile adoption, adaptation and assessment.
@InProceedings{RCoSE14p36,
author = {Hajer Ayed and Benoît Vanderose and Naji Habra},
title = {Supported Approach for Agile Methods Adaptation: An Adoption Study},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {36--41},
doi = {},
year = {2014},
}
|
|
| Juergens, Elmar |
RCoSE '14: "Rapid Requirements Checks ..."
Rapid Requirements Checks with Requirements Smells: Two Case Studies
Henning Femmer, Daniel Méndez Fernández, Elmar Juergens, Michael Klose, Ilona Zimmer, and Jörg Zimmer (TU München, Germany; CQSE, Germany; Wacker Chemie, Germany; MBtech Group, Germany; Daimler, Germany) Bad requirements quality can have expensive consequences during the software development lifecycle. Especially, if iterations are long and feedback comes late - the faster a problem is found, the cheaper it is to fix. We propose to detect issues in requirements based on requirements (bad) smells by applying a light-weight static requirements analysis. This light-weight technique allows for instant checks as soon as a requirement is written down. In this paper, we derive a set of smells, including automatic smell detection, from the natural language criteria of the ISO/IEC/IEEE 29148 standard. We evaluated the approach with 336 requirements and 53 use cases from 9 specifications that were written by the car manufacturer Daimler AG and the chemical business company Wacker Chemie AG, and discussed the results with their requirements and domain experts. While not all problems can be detected, the case study shows that lightweight smell analysis can uncover many practically relevant requirements defects. Based on these results and the discussion with our industry partners, we conclude that requirements smells can serve as an efficient supplement to traditional reviews or team discussions, in order to create fast feedback on requirements quality.
@InProceedings{RCoSE14p10,
author = {Henning Femmer and Daniel Méndez Fernández and Elmar Juergens and Michael Klose and Ilona Zimmer and Jörg Zimmer},
title = {Rapid Requirements Checks with Requirements Smells: Two Case Studies},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {10--19},
doi = {},
year = {2014},
}
|
|
| Klose, Michael |
RCoSE '14: "Rapid Requirements Checks ..."
Rapid Requirements Checks with Requirements Smells: Two Case Studies
Henning Femmer, Daniel Méndez Fernández, Elmar Juergens, Michael Klose, Ilona Zimmer, and Jörg Zimmer (TU München, Germany; CQSE, Germany; Wacker Chemie, Germany; MBtech Group, Germany; Daimler, Germany) Bad requirements quality can have expensive consequences during the software development lifecycle. Especially, if iterations are long and feedback comes late - the faster a problem is found, the cheaper it is to fix. We propose to detect issues in requirements based on requirements (bad) smells by applying a light-weight static requirements analysis. This light-weight technique allows for instant checks as soon as a requirement is written down. In this paper, we derive a set of smells, including automatic smell detection, from the natural language criteria of the ISO/IEC/IEEE 29148 standard. We evaluated the approach with 336 requirements and 53 use cases from 9 specifications that were written by the car manufacturer Daimler AG and the chemical business company Wacker Chemie AG, and discussed the results with their requirements and domain experts. While not all problems can be detected, the case study shows that lightweight smell analysis can uncover many practically relevant requirements defects. Based on these results and the discussion with our industry partners, we conclude that requirements smells can serve as an efficient supplement to traditional reviews or team discussions, in order to create fast feedback on requirements quality.
@InProceedings{RCoSE14p10,
author = {Henning Femmer and Daniel Méndez Fernández and Elmar Juergens and Michael Klose and Ilona Zimmer and Jörg Zimmer},
title = {Rapid Requirements Checks with Requirements Smells: Two Case Studies},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {10--19},
doi = {},
year = {2014},
}
|
|
| Konersmann, Marco |
RCoSE '14: "Rapidly Locating and Understanding ..."
Rapidly Locating and Understanding Errors using Runtime Monitoring of Architecture-Carrying Code
Marco Konersmann (University of Duisburg-Essen, Germany) Finding and understanding errors in software that is deployed in the field and tested by beta testers or used in production is a difficult and often time consuming task. If the feedback to the developers is naïvely composed of log messages, stack traces, and informal user feedback, it might not contain enough information to locate the erroneous fragments efficiently. It is thus slowing the dynamics in rapid continuous software engineering scenarios. These errors can more easily be found when the code is explicitly designed to carry architectural specifications by intertwining structure and behavior models with the rest of the code. With architecture-carrying code, (1) the steps leading to single errors can be replayed for understanding and debugging; (2) statistical information about errors can be related to structure elements and behavior branches. In this paper we present our idea of architecture-carrying code and its application for error understanding to support rapid continuous software engineering.
@InProceedings{RCoSE14p20,
author = {Marco Konersmann},
title = {Rapidly Locating and Understanding Errors using Runtime Monitoring of Architecture-Carrying Code},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {20--25},
doi = {},
year = {2014},
}
|
|
 |
Krusche, Stephan |
RCoSE '14: "Rugby: An Agile Process Model ..."
Rugby: An Agile Process Model Based on Continuous Delivery
Stephan Krusche, Lukas Alperowitz, Bernd Bruegge, and Martin O. Wagner (TU München, Germany) In this paper we introduce Rugby, an agile process model that includes workflows for the continuous delivery of software. It allows part-timers to work in a project-based organization with multiple projects for the rapid delivery of prototypes and products. We show how continuous delivery improves the development process in two ways: First, Rugby improves the interaction between developers and customers with a continuous feedback mechanism. Second, Rugby improves the coordination and communication with stakeholders and across multiple teams in project-based organizations with event based releases. We have evaluated Rugby in two large university software engineering capstone courses with up to 100 participants working in 10 simultaneous projects with industry partners in 2012 and 2013. We describe the metrics used in the evaluation. First results indicate that Rugby increases the frequency and quality of the interaction between developers and customers leading to improved results in the delivered products.
@InProceedings{RCoSE14p42,
author = {Stephan Krusche and Lukas Alperowitz and Bernd Bruegge and Martin O. Wagner},
title = {Rugby: An Agile Process Model Based on Continuous Delivery},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {42--50},
doi = {},
year = {2014},
}
|
| Mäenpää, Hanna |
RCoSE '14: "Building Blocks for Continuous ..."
Building Blocks for Continuous Experimentation
Fabian Fagerholm, Alejandro Sanchez Guinea, Hanna Mäenpää, and Jürgen Münch (University of Helsinki, Finland) Development of software-intensive products and services increasingly occurs by continuously deploying product or service increments, such as new features and enhancements, to customers. Product and service developers need to continuously find out what customers want by direct customer feedback and observation of usage behaviour, rather than indirectly through up-front business analyses. This paper examines the preconditions for setting up an experimentation system for continuous customer experiments. It describes the building blocks required for such a system. An initial model for continuous experimentation is analytically derived from prior work. The model is then matched against empirical case study findings from a startup company and adjusted. Building blocks for a continuous experimentation system and infrastructure are presented. A suitable experimentation system requires at least the ability to release minimum viable products or features with suitable instrumentation, design and manage experiment plans, link experiment results with a product roadmap, and manage a flexible business strategy. The main challenges are proper and rapid design of experiments, advanced instrumentation of software to collect, analyse, and store relevant data, and the integration of experiment results in both the product development cycle and the software development process.
@InProceedings{RCoSE14p26,
author = {Fabian Fagerholm and Alejandro Sanchez Guinea and Hanna Mäenpää and Jürgen Münch},
title = {Building Blocks for Continuous Experimentation},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {26--35},
doi = {},
year = {2014},
}
|
|
| Münch, Jürgen |
RCoSE '14: "Building Blocks for Continuous ..."
Building Blocks for Continuous Experimentation
Fabian Fagerholm, Alejandro Sanchez Guinea, Hanna Mäenpää, and Jürgen Münch (University of Helsinki, Finland) Development of software-intensive products and services increasingly occurs by continuously deploying product or service increments, such as new features and enhancements, to customers. Product and service developers need to continuously find out what customers want by direct customer feedback and observation of usage behaviour, rather than indirectly through up-front business analyses. This paper examines the preconditions for setting up an experimentation system for continuous customer experiments. It describes the building blocks required for such a system. An initial model for continuous experimentation is analytically derived from prior work. The model is then matched against empirical case study findings from a startup company and adjusted. Building blocks for a continuous experimentation system and infrastructure are presented. A suitable experimentation system requires at least the ability to release minimum viable products or features with suitable instrumentation, design and manage experiment plans, link experiment results with a product roadmap, and manage a flexible business strategy. The main challenges are proper and rapid design of experiments, advanced instrumentation of software to collect, analyse, and store relevant data, and the integration of experiment results in both the product development cycle and the software development process.
@InProceedings{RCoSE14p26,
author = {Fabian Fagerholm and Alejandro Sanchez Guinea and Hanna Mäenpää and Jürgen Münch},
title = {Building Blocks for Continuous Experimentation},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {26--35},
doi = {},
year = {2014},
}
|
|
| Nyfjord, Jaana |
RCoSE '14: "Personalised Continuous Software ..."
Personalised Continuous Software Engineering
Efi Papatheocharous, Marios Belk, Jaana Nyfjord, Panagiotis Germanakos, and George Samaras (SICS, Sweden; University of Cyprus, Cyprus; SAP, Germany) This work describes how human factors can influence continuous software engineering. The reasoning begins from the Agile Manifesto promoting individuals and interactions over processes and tools. The organisational need to continuously develop, release and learn from software development in rapid cycles requires empowered and self-organised agile teams. However, these teams are formed without necessarily considering the members’ individual characteristics towards effective teamwork, from the personality and cognitive perspective. In this realm, this paper proposes a two level approach: first, form teams based on their collective personality traits and second, provide personalised tools and methods based on their individual differences in cognitive processing. The approach is motivated by a study conducted in a business environment focusing on task execution, satisfaction and effectiveness of team members in relation to their personalities and cognitive characteristics. Our preliminary results show that human factors provide a promising basis for increasing the capability of continuous software engineering.
@InProceedings{RCoSE14p57,
author = {Efi Papatheocharous and Marios Belk and Jaana Nyfjord and Panagiotis Germanakos and George Samaras},
title = {Personalised Continuous Software Engineering},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {57--62},
doi = {},
year = {2014},
}
|
|
| Papatheocharous, Efi |
RCoSE '14: "Personalised Continuous Software ..."
Personalised Continuous Software Engineering
Efi Papatheocharous, Marios Belk, Jaana Nyfjord, Panagiotis Germanakos, and George Samaras (SICS, Sweden; University of Cyprus, Cyprus; SAP, Germany) This work describes how human factors can influence continuous software engineering. The reasoning begins from the Agile Manifesto promoting individuals and interactions over processes and tools. The organisational need to continuously develop, release and learn from software development in rapid cycles requires empowered and self-organised agile teams. However, these teams are formed without necessarily considering the members’ individual characteristics towards effective teamwork, from the personality and cognitive perspective. In this realm, this paper proposes a two level approach: first, form teams based on their collective personality traits and second, provide personalised tools and methods based on their individual differences in cognitive processing. The approach is motivated by a study conducted in a business environment focusing on task execution, satisfaction and effectiveness of team members in relation to their personalities and cognitive characteristics. Our preliminary results show that human factors provide a promising basis for increasing the capability of continuous software engineering.
@InProceedings{RCoSE14p57,
author = {Efi Papatheocharous and Marios Belk and Jaana Nyfjord and Panagiotis Germanakos and George Samaras},
title = {Personalised Continuous Software Engineering},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {57--62},
doi = {},
year = {2014},
}
|
|
| Samaras, George |
RCoSE '14: "Personalised Continuous Software ..."
Personalised Continuous Software Engineering
Efi Papatheocharous, Marios Belk, Jaana Nyfjord, Panagiotis Germanakos, and George Samaras (SICS, Sweden; University of Cyprus, Cyprus; SAP, Germany) This work describes how human factors can influence continuous software engineering. The reasoning begins from the Agile Manifesto promoting individuals and interactions over processes and tools. The organisational need to continuously develop, release and learn from software development in rapid cycles requires empowered and self-organised agile teams. However, these teams are formed without necessarily considering the members’ individual characteristics towards effective teamwork, from the personality and cognitive perspective. In this realm, this paper proposes a two level approach: first, form teams based on their collective personality traits and second, provide personalised tools and methods based on their individual differences in cognitive processing. The approach is motivated by a study conducted in a business environment focusing on task execution, satisfaction and effectiveness of team members in relation to their personalities and cognitive characteristics. Our preliminary results show that human factors provide a promising basis for increasing the capability of continuous software engineering.
@InProceedings{RCoSE14p57,
author = {Efi Papatheocharous and Marios Belk and Jaana Nyfjord and Panagiotis Germanakos and George Samaras},
title = {Personalised Continuous Software Engineering},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {57--62},
doi = {},
year = {2014},
}
|
|
| Stol, Klaas-Jan |
RCoSE '14: "Continuous Software Engineering ..."
Continuous Software Engineering and Beyond: Trends and Challenges
Brian Fitzgerald and Klaas-Jan Stol (Lero, Ireland; University of Limerick, Ireland) Throughout its short history, software development has been characterized by harmful disconnects between important activities e.g., planning, development and implementation. The problem is further exacerbated by the episodic and infrequent performance of activities such as planning, testing, integration and releases. Several emerging phenomena reflect attempts to address these problems. For example, the Enterprise Agile concept has emerged as a recognition that the benefits of agile software development will be sub- optimal if not complemented by an agile approach in related organizational function such as finance and HR. Continuous integration is a practice which has emerged to eliminate discontinuities between development and deployment. In a similar vein, the recent emphasis on DevOps recognizes that the integration between software development and its operational deployment needs to be a continuous one. We argue a similar continuity is required between business strategy and development, BizDev being the term we coin for this. These disconnects are even more problematic given the need for reliability and resilience in the complex and data-intensive systems being developed today. Drawing on the lean concept of flow, we identify a number of continuous activities which are important for software development in today’s context. These activities include continuous planning, continuous integration, continuous deployment, continuous delivery, continuous verification, continuous testing, continuous compliance,continuous security, continuous use, continuous trust, continuous run-time monitoring, continuous improvement (both process and product), all underpinned by continuous innovation. We use the umbrella term, ``Continuous *'' (continuous star) to identify this family of continuous activities.
@InProceedings{RCoSE14p1,
author = {Brian Fitzgerald and Klaas-Jan Stol},
title = {Continuous Software Engineering and Beyond: Trends and Challenges},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {1--9},
doi = {},
year = {2014},
}
|
|
| Vanderose, Benoît |
RCoSE '14: "Supported Approach for Agile ..."
Supported Approach for Agile Methods Adaptation: An Adoption Study
Hajer Ayed, Benoît Vanderose, and Naji Habra (University of Namur, Belgium) Adopting agile software development methods is a wide and complex organisational change that usually impacts several aspects of the organisation (e.g., its structure, culture, management practices, produced artefacts, technologies in use, etc). In order to successfully handle the several key challenges, it's crucial to understand the organisation context and carefully study the transformation strategies. This paper presents an agile transformation experience that has been undertaken in a public organisation in Belgium and during which Scrum was applied in two pilot projects. The first project retrospective shows that the change cannot be accomplished only at the team-level without taking into account the overall structure of the organisation and that we must carefully evolve toward a context-specific adapted method. In the second pilot project, we defined structured and repeatable steps to assist the adoption of agile practices. The experience shows the usefulness of such an approach but suggests that automation efforts should be addressed. The last section of the paper summarizes the issues encountered and presents the AM-QuICK framework which aims at providing a supported approach to guide the agile adoption, adaptation and assessment.
@InProceedings{RCoSE14p36,
author = {Hajer Ayed and Benoît Vanderose and Naji Habra},
title = {Supported Approach for Agile Methods Adaptation: An Adoption Study},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {36--41},
doi = {},
year = {2014},
}
|
|
| Wagner, Martin O. |
RCoSE '14: "Rugby: An Agile Process Model ..."
Rugby: An Agile Process Model Based on Continuous Delivery
Stephan Krusche, Lukas Alperowitz, Bernd Bruegge, and Martin O. Wagner (TU München, Germany) In this paper we introduce Rugby, an agile process model that includes workflows for the continuous delivery of software. It allows part-timers to work in a project-based organization with multiple projects for the rapid delivery of prototypes and products. We show how continuous delivery improves the development process in two ways: First, Rugby improves the interaction between developers and customers with a continuous feedback mechanism. Second, Rugby improves the coordination and communication with stakeholders and across multiple teams in project-based organizations with event based releases. We have evaluated Rugby in two large university software engineering capstone courses with up to 100 participants working in 10 simultaneous projects with industry partners in 2012 and 2013. We describe the metrics used in the evaluation. First results indicate that Rugby increases the frequency and quality of the interaction between developers and customers leading to improved results in the delivered products.
@InProceedings{RCoSE14p42,
author = {Stephan Krusche and Lukas Alperowitz and Bernd Bruegge and Martin O. Wagner},
title = {Rugby: An Agile Process Model Based on Continuous Delivery},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {42--50},
doi = {},
year = {2014},
}
|
|
| Wagner, Stefan |
RCoSE '14: "Scrum for Cyber-Physical Systems: ..."
Scrum for Cyber-Physical Systems: A Process Proposal
Stefan Wagner (University of Stuttgart, Germany) Agile development processes and especially Scrum are chang- ing the state of the practice in software development. Many companies in the classical IT sector have adopted them to successfully tackle various challenges from the rapidly changing environments and increasingly complex software systems. Companies developing software for embedded or cyber-physical systems, however, are still hesitant to adopt such processes. Despite successful applications of Scrum and other agile methods for cyber-physical systems, there is still no complete process that maps their specific challenges to practices in Scrum. We propose to fill this gap by treating all design artefacts in such a development in the same way: In software development, the final design is already the product, in hardware and mechanics it is the starting point of production. We sketch the Scrum extension Scrum CPS by showing how Scrum could be used to develop all design artefacts for a cyber physical system. Hardware and mechanical parts that might not be available yet are simulated. With this approach, we can directly and iteratively build the final software and produce detailed models for the hardware and mechanics production in parallel. We plan to further detail Scrum CPS and apply it first in a series of student projects to gather more experience before testing it in an industrial case study.
@InProceedings{RCoSE14p51,
author = {Stefan Wagner},
title = {Scrum for Cyber-Physical Systems: A Process Proposal},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {51--56},
doi = {},
year = {2014},
}
|
|
| Zimmer, Ilona |
RCoSE '14: "Rapid Requirements Checks ..."
Rapid Requirements Checks with Requirements Smells: Two Case Studies
Henning Femmer, Daniel Méndez Fernández, Elmar Juergens, Michael Klose, Ilona Zimmer, and Jörg Zimmer (TU München, Germany; CQSE, Germany; Wacker Chemie, Germany; MBtech Group, Germany; Daimler, Germany) Bad requirements quality can have expensive consequences during the software development lifecycle. Especially, if iterations are long and feedback comes late - the faster a problem is found, the cheaper it is to fix. We propose to detect issues in requirements based on requirements (bad) smells by applying a light-weight static requirements analysis. This light-weight technique allows for instant checks as soon as a requirement is written down. In this paper, we derive a set of smells, including automatic smell detection, from the natural language criteria of the ISO/IEC/IEEE 29148 standard. We evaluated the approach with 336 requirements and 53 use cases from 9 specifications that were written by the car manufacturer Daimler AG and the chemical business company Wacker Chemie AG, and discussed the results with their requirements and domain experts. While not all problems can be detected, the case study shows that lightweight smell analysis can uncover many practically relevant requirements defects. Based on these results and the discussion with our industry partners, we conclude that requirements smells can serve as an efficient supplement to traditional reviews or team discussions, in order to create fast feedback on requirements quality.
@InProceedings{RCoSE14p10,
author = {Henning Femmer and Daniel Méndez Fernández and Elmar Juergens and Michael Klose and Ilona Zimmer and Jörg Zimmer},
title = {Rapid Requirements Checks with Requirements Smells: Two Case Studies},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {10--19},
doi = {},
year = {2014},
}
|
|
| Zimmer, Jörg |
RCoSE '14: "Rapid Requirements Checks ..."
Rapid Requirements Checks with Requirements Smells: Two Case Studies
Henning Femmer, Daniel Méndez Fernández, Elmar Juergens, Michael Klose, Ilona Zimmer, and Jörg Zimmer (TU München, Germany; CQSE, Germany; Wacker Chemie, Germany; MBtech Group, Germany; Daimler, Germany) Bad requirements quality can have expensive consequences during the software development lifecycle. Especially, if iterations are long and feedback comes late - the faster a problem is found, the cheaper it is to fix. We propose to detect issues in requirements based on requirements (bad) smells by applying a light-weight static requirements analysis. This light-weight technique allows for instant checks as soon as a requirement is written down. In this paper, we derive a set of smells, including automatic smell detection, from the natural language criteria of the ISO/IEC/IEEE 29148 standard. We evaluated the approach with 336 requirements and 53 use cases from 9 specifications that were written by the car manufacturer Daimler AG and the chemical business company Wacker Chemie AG, and discussed the results with their requirements and domain experts. While not all problems can be detected, the case study shows that lightweight smell analysis can uncover many practically relevant requirements defects. Based on these results and the discussion with our industry partners, we conclude that requirements smells can serve as an efficient supplement to traditional reviews or team discussions, in order to create fast feedback on requirements quality.
@InProceedings{RCoSE14p10,
author = {Henning Femmer and Daniel Méndez Fernández and Elmar Juergens and Michael Klose and Ilona Zimmer and Jörg Zimmer},
title = {Rapid Requirements Checks with Requirements Smells: Two Case Studies},
booktitle = {Proc.\ RCoSE},
publisher = {ACM},
pages = {10--19},
doi = {},
year = {2014},
}
|
26 authors
proc time: 0.91