Keeping the build fast is often stated as an important prerequisite for continuous integration, and is also widely discussed in literature. But which importance does the capacity of the build system actually have in relation to developer behavior? Based on metrics and interview results from a large-scale industry project, we present the factors that according to the developers themselves affect how often they deliver software to the mainline. We show that the developer will deliver less frequently if the delivery processes is time-consuming, if it's too complicated to deliver or if there is no evident value in delivering often to the mainline. Behind these three main themes, we also present a range of sub-categories such as architecture, test activities and administration. The build system capacity is one of several factors which, if not considered, could result in undesired continuous integration behaviors – but other factors should be seen as at least as important.
{"title":"Continuous Integration is Not About Build Systems","authors":"Torvald Mårtensson, Par Hammarstrom, J. Bosch","doi":"10.1109/SEAA.2017.30","DOIUrl":"https://doi.org/10.1109/SEAA.2017.30","url":null,"abstract":"Keeping the build fast is often stated as an important prerequisite for continuous integration, and is also widely discussed in literature. But which importance does the capacity of the build system actually have in relation to developer behavior? Based on metrics and interview results from a large-scale industry project, we present the factors that according to the developers themselves affect how often they deliver software to the mainline. We show that the developer will deliver less frequently if the delivery processes is time-consuming, if it's too complicated to deliver or if there is no evident value in delivering often to the mainline. Behind these three main themes, we also present a range of sub-categories such as architecture, test activities and administration. The build system capacity is one of several factors which, if not considered, could result in undesired continuous integration behaviors – but other factors should be seen as at least as important.","PeriodicalId":151513,"journal":{"name":"2017 43rd Euromicro Conference on Software Engineering and Advanced Applications (SEAA)","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-08-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123650030","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Rodi Jolak, Eric Umuhoza, Truong Ho-Quang, M. Chaudron, M. Brambilla
One argument in the discussion about the adoption of UML in industry is the supposedly large effort it takes to do modeling. Our study explores how the creation of UML models can be understood to consist of different cognitive activities: (i) designing: thinking about the design (ideation, key-design decision making), (ii) notation expression: expressing a design in a modeling notation and (iii) layouting: the spatial organization of model elements in a diagram. We explain that these different subactivities relate to different short-term and long-term benefits of modeling. In this study we present two controlled experiments with a total of 100 subjects creating models for a small system. In these experiments we focus on software models as represented through UML class diagram. Our results show that at least 56% of the effort spent on creating a class model is actually due to designing. Notation expression is around 41% of the model creation effort and layouting is in the order of 3%. This finding suggests that a significant part of creating models is devoted to design thinking about the problem.
{"title":"Dissecting Design Effort and Drawing Effort in UML Modeling","authors":"Rodi Jolak, Eric Umuhoza, Truong Ho-Quang, M. Chaudron, M. Brambilla","doi":"10.1109/SEAA.2017.55","DOIUrl":"https://doi.org/10.1109/SEAA.2017.55","url":null,"abstract":"One argument in the discussion about the adoption of UML in industry is the supposedly large effort it takes to do modeling. Our study explores how the creation of UML models can be understood to consist of different cognitive activities: (i) designing: thinking about the design (ideation, key-design decision making), (ii) notation expression: expressing a design in a modeling notation and (iii) layouting: the spatial organization of model elements in a diagram. We explain that these different subactivities relate to different short-term and long-term benefits of modeling. In this study we present two controlled experiments with a total of 100 subjects creating models for a small system. In these experiments we focus on software models as represented through UML class diagram. Our results show that at least 56% of the effort spent on creating a class model is actually due to designing. Notation expression is around 41% of the model creation effort and layouting is in the order of 3%. This finding suggests that a significant part of creating models is devoted to design thinking about the problem.","PeriodicalId":151513,"journal":{"name":"2017 43rd Euromicro Conference on Software Engineering and Advanced Applications (SEAA)","volume":"149 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-08-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127223721","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
The importance of traceability in software development has long been recognized, not only for reasons of legality and certification, but also to enable the development itself. At the same time, organizations are known to struggle to live up to traceability requirements, and there is an identified lack of studies on traceability practices in the industry, not least in the area of tooling and infrastructure. This paper identifies traceability as a key challenge in achieving continuous integration and delivery and documents an industry developed framework — Eiffel — designed to provide real time traceability in continuous integration and delivery. The efficacy of the Eiffel framework is then investigated through comparison with previous traceability methods.
{"title":"Continuous Integration and Delivery Traceability in Industry: Needs and Practices","authors":"Daniel Ståhl, Kristofer Hallén, J. Bosch","doi":"10.1109/SEAA.2017.19","DOIUrl":"https://doi.org/10.1109/SEAA.2017.19","url":null,"abstract":"The importance of traceability in software development has long been recognized, not only for reasons of legality and certification, but also to enable the development itself. At the same time, organizations are known to struggle to live up to traceability requirements, and there is an identified lack of studies on traceability practices in the industry, not least in the area of tooling and infrastructure. This paper identifies traceability as a key challenge in achieving continuous integration and delivery and documents an industry developed framework — Eiffel — designed to provide real time traceability in continuous integration and delivery. The efficacy of the Eiffel framework is then investigated through comparison with previous traceability methods.","PeriodicalId":151513,"journal":{"name":"2017 43rd Euromicro Conference on Software Engineering and Advanced Applications (SEAA)","volume":"59 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-08-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123647516","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Background. The effects of different practices on fault distributions in evolving complex software systems is not fully understood. Software reuse and unit verification are practices used to improve system reliability by minimising the number of late faults. Reused software benefits from already being verified while unit verification aims to find faults early.Aims. We want to study effects of software reuse and unit verification on future modifications, fault densities of software units, and fault distributions.Method. We applied statistical analysis to a sample of 520 units that were reused and modified within four sequential projects from one product line in the telecommunication domain.Results. In reused units, the results of unit verification are correlated to a smaller degree of modifications and decreased fault densities.Conclusion. Unit verification in complex systems may improve system evolution in terms of smaller modifications and decrease of fault densities. The unit verification faults in reused components may be used as predictors of component modification and fault density.
{"title":"Unit Verification Effects on Reused Components in Sequential Project Releases","authors":"Tihana Galinac Grbac, P. Runeson, D. Huljenic","doi":"10.1109/SEAA.2017.63","DOIUrl":"https://doi.org/10.1109/SEAA.2017.63","url":null,"abstract":"Background. The effects of different practices on fault distributions in evolving complex software systems is not fully understood. Software reuse and unit verification are practices used to improve system reliability by minimising the number of late faults. Reused software benefits from already being verified while unit verification aims to find faults early.Aims. We want to study effects of software reuse and unit verification on future modifications, fault densities of software units, and fault distributions.Method. We applied statistical analysis to a sample of 520 units that were reused and modified within four sequential projects from one product line in the telecommunication domain.Results. In reused units, the results of unit verification are correlated to a smaller degree of modifications and decreased fault densities.Conclusion. Unit verification in complex systems may improve system evolution in terms of smaller modifications and decrease of fault densities. The unit verification faults in reused components may be used as predictors of component modification and fault density.","PeriodicalId":151513,"journal":{"name":"2017 43rd Euromicro Conference on Software Engineering and Advanced Applications (SEAA)","volume":"66 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125511709","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Agile software development methodologies have been widely adopted by the software industry during the last decade. Agility assessment is an approach to measure the success of this adoption as well as to satisfy the further demands. In response, a number of agile maturity self-assessment surveys have been developed. However, software organizations do not widely utilize existing self-assessment surveys. In this study we aim to identify the existing surveys and evaluate their strengths and weaknesses in agility assessment. Firstly, an exploratory case study is performed by using one of the surveys in order to determine the expected features of an agile maturity self-assessment survey. Then, a comprehensive case study is conducted to measure the sufficiency of the mostly referenced agile maturity self-assessment surveys according to the determined features. The study results reveal that current surveys do not meet the expected features comprehensively.
{"title":"Agile Maturity Self-Assessment Surveys: A Case Study","authors":"Ozan Raşit Yürüm, Onur Demirörs","doi":"10.1109/SEAA.2017.58","DOIUrl":"https://doi.org/10.1109/SEAA.2017.58","url":null,"abstract":"Agile software development methodologies have been widely adopted by the software industry during the last decade. Agility assessment is an approach to measure the success of this adoption as well as to satisfy the further demands. In response, a number of agile maturity self-assessment surveys have been developed. However, software organizations do not widely utilize existing self-assessment surveys. In this study we aim to identify the existing surveys and evaluate their strengths and weaknesses in agility assessment. Firstly, an exploratory case study is performed by using one of the surveys in order to determine the expected features of an agile maturity self-assessment survey. Then, a comprehensive case study is conducted to measure the sufficiency of the mostly referenced agile maturity self-assessment surveys according to the determined features. The study results reveal that current surveys do not meet the expected features comprehensively.","PeriodicalId":151513,"journal":{"name":"2017 43rd Euromicro Conference on Software Engineering and Advanced Applications (SEAA)","volume":"4 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128050133","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：