Pub Date : 2012-06-02DOI: 10.1109/ICSSP.2012.6225961
Li Jiang, Kathleen M. Carley, A. Eberlein
There are many factors that provide input into the software development process, such as the values, beliefs, norms, practices, skills, behaviors, knowledge and goals of stakeholders. Research has shown that successful software system development relies on alignment or congruence between these factors. How to monitor the level of congruence between these factors and how to use the congruence as an indicator or a measure to monitor a software development process is a challenge in software engineering. This paper proposes a model that uses three congruence measures to examine the levels of social-technical congruence in software development processes. Using a controlled experiment with seven student teams developing a robot project, this paper demonstrates that the proposed congruence measures provide results consistent with the assessment by the course lecturers.
{"title":"Assessing team performance from a socio-technical congruence perspective","authors":"Li Jiang, Kathleen M. Carley, A. Eberlein","doi":"10.1109/ICSSP.2012.6225961","DOIUrl":"https://doi.org/10.1109/ICSSP.2012.6225961","url":null,"abstract":"There are many factors that provide input into the software development process, such as the values, beliefs, norms, practices, skills, behaviors, knowledge and goals of stakeholders. Research has shown that successful software system development relies on alignment or congruence between these factors. How to monitor the level of congruence between these factors and how to use the congruence as an indicator or a measure to monitor a software development process is a challenge in software engineering. This paper proposes a model that uses three congruence measures to examine the levels of social-technical congruence in software development processes. Using a controlled experiment with seven student teams developing a robot project, this paper demonstrates that the proposed congruence measures provide results consistent with the assessment by the course lecturers.","PeriodicalId":166836,"journal":{"name":"2012 International Conference on Software and System Process (ICSSP)","volume":"49 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-06-02","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133514194","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}
Pub Date : 2012-06-02DOI: 10.1109/ICSSP.2012.6225969
Dan X. Houston
The young field of software process simulation was born out of research that stimulated the imagination of many researchers who created a vision for addressing “the software problem.” Though the vision has yet to be realized widely, the need for the field is growing and benefits are being seen slowly. Opportunity for continued growth of this field lies in the reciprocity between research and industrial practice. An agenda for advancing software process simulation through this reciprocity is offered.
{"title":"Research and practice reciprocity in software process simulation","authors":"Dan X. Houston","doi":"10.1109/ICSSP.2012.6225969","DOIUrl":"https://doi.org/10.1109/ICSSP.2012.6225969","url":null,"abstract":"The young field of software process simulation was born out of research that stimulated the imagination of many researchers who created a vision for addressing “the software problem.” Though the vision has yet to be realized widely, the need for the field is growing and benefits are being seen slowly. Opportunity for continued growth of this field lies in the reciprocity between research and industrial practice. An agenda for advancing software process simulation through this reciprocity is offered.","PeriodicalId":166836,"journal":{"name":"2012 International Conference on Software and System Process (ICSSP)","volume":"25 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-06-02","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114083407","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}
Pub Date : 2012-06-02DOI: 10.1109/ICSSP.2012.6225966
T. Schluter, T. Birkhölzer
Managed software development organizations are de facto closed loop systems, in which management actions influence future behavior based on observations of previous behavior thus forming a closed feedback loop. It is well known from control theory that a closed loop system might exhibit dynamics very different from the dynamics of its open loop components. Therefore, it is the goal of this work to study the importance of closed loop effects in the context of software process dynamics. To this end, an exemplary model is presented with a work-test-rework cycle as operational part and a productivity estimation and personnel allocation model as management component. The behavior of this closed loop system is probed with respect to typical disturbances and nonlinearities of software processes. The results underscore the importance of such a closed loop analysis.
{"title":"Modeling and analysis of software development management as closed loop control","authors":"T. Schluter, T. Birkhölzer","doi":"10.1109/ICSSP.2012.6225966","DOIUrl":"https://doi.org/10.1109/ICSSP.2012.6225966","url":null,"abstract":"Managed software development organizations are de facto closed loop systems, in which management actions influence future behavior based on observations of previous behavior thus forming a closed feedback loop. It is well known from control theory that a closed loop system might exhibit dynamics very different from the dynamics of its open loop components. Therefore, it is the goal of this work to study the importance of closed loop effects in the context of software process dynamics. To this end, an exemplary model is presented with a work-test-rework cycle as operational part and a productivity estimation and personnel allocation model as management component. The behavior of this closed loop system is probed with respect to typical disturbances and nonlinearities of software processes. The results underscore the importance of such a closed loop analysis.","PeriodicalId":166836,"journal":{"name":"2012 International Conference on Software and System Process (ICSSP)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-06-02","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129741320","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}
Pub Date : 2012-06-02DOI: 10.1109/ICSSP.2012.6225963
Luanna Lopes Lobato, P. A. M. S. Neto, I. Machado, E. Almeida, S. Meira
Software Product Lines (SPL) adoption can affect several aspects of an organization and it involves significant investment and risk. This way, SPL risk management is a crucial activity of SPL adoption. This study aims to identify SPL risks during the scoping and requirement disciplines to provide information to better understand risk management in SPL. In order to achieve the previous stated goal, a case study research was applied in an industrial project in the medical information management domain. Using the captured risks, a classification scheme was built and risk mitigation strategies were identified. We spent five months, totaling 79 hours, performing risk management (RM) in the scoping discipline and twelve months, totaling 148 hours, performing RM on the requirements discipline. We identified 32 risks during the scoping discipline and 20 risks during the requirements discipline, 14 risks occurred in both disciplines. Some identified risks are not particular to SPL development, however, they have their impact increased due to the SPL characteristic. All the study results and lessons learned are useful for all project managers and researchers who are considering the introduction of SPL risk management in industry or academia.
{"title":"Risk management in software product lines: An industrial case study","authors":"Luanna Lopes Lobato, P. A. M. S. Neto, I. Machado, E. Almeida, S. Meira","doi":"10.1109/ICSSP.2012.6225963","DOIUrl":"https://doi.org/10.1109/ICSSP.2012.6225963","url":null,"abstract":"Software Product Lines (SPL) adoption can affect several aspects of an organization and it involves significant investment and risk. This way, SPL risk management is a crucial activity of SPL adoption. This study aims to identify SPL risks during the scoping and requirement disciplines to provide information to better understand risk management in SPL. In order to achieve the previous stated goal, a case study research was applied in an industrial project in the medical information management domain. Using the captured risks, a classification scheme was built and risk mitigation strategies were identified. We spent five months, totaling 79 hours, performing risk management (RM) in the scoping discipline and twelve months, totaling 148 hours, performing RM on the requirements discipline. We identified 32 risks during the scoping discipline and 20 risks during the requirements discipline, 14 risks occurred in both disciplines. Some identified risks are not particular to SPL development, however, they have their impact increased due to the SPL characteristic. All the study results and lessons learned are useful for all project managers and researchers who are considering the introduction of SPL risk management in industry or academia.","PeriodicalId":166836,"journal":{"name":"2012 International Conference on Software and System Process (ICSSP)","volume":"2 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-06-02","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114337558","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}
Pub Date : 2012-06-02DOI: 10.1109/ICSSP.2012.6225978
R. Hebig, Gregor Gabrysiak, H. Giese
One of the multiple technical factors which affect changeability of software is model-driven engineering (MDE), where often several models and a multitude of manual as well as automated development activities have to be mastered to derive the final software product. The ability to change software with only reasonable costs, however, is of uppermost importance for the iterative and incremental development of software as well as agile development in general. Thus, the effective applicability of agile processes is influenced by the used MDE activities. However, there is currently no approach available to systematically detect and handle such risks to the changeability that result from the embedded MDE activities. In this paper we extend our beforehand-introduced process modeling approach by a notion of process pattern to capture typical situations that can be associated with risk or benefit with respect changeability. In addition, four candidates for the envisioned process patterns are presented in detail in the paper. Further, we developed strategies to handle changeability risks associated to these process patterns.
{"title":"Towards patterns for MDE-related processes to detect and handle changeability risks","authors":"R. Hebig, Gregor Gabrysiak, H. Giese","doi":"10.1109/ICSSP.2012.6225978","DOIUrl":"https://doi.org/10.1109/ICSSP.2012.6225978","url":null,"abstract":"One of the multiple technical factors which affect changeability of software is model-driven engineering (MDE), where often several models and a multitude of manual as well as automated development activities have to be mastered to derive the final software product. The ability to change software with only reasonable costs, however, is of uppermost importance for the iterative and incremental development of software as well as agile development in general. Thus, the effective applicability of agile processes is influenced by the used MDE activities. However, there is currently no approach available to systematically detect and handle such risks to the changeability that result from the embedded MDE activities. In this paper we extend our beforehand-introduced process modeling approach by a notion of process pattern to capture typical situations that can be associated with risk or benefit with respect changeability. In addition, four candidates for the envisioned process patterns are presented in detail in the paper. Further, we developed strategies to handle changeability risks associated to these process patterns.","PeriodicalId":166836,"journal":{"name":"2012 International Conference on Software and System Process (ICSSP)","volume":"96 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-06-02","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114945752","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}
Pub Date : 2012-06-02DOI: 10.1109/ICSSP.2012.6225965
Jamshaid G. Mohebzada, G. Ruhe, A. Eberlein
Recommendation systems provide users with up-to-date guidance on processes, artifacts or other project-relevant information. Recommendation systems for requirements engineering can be used to provide the right information, at the right time, to requirements engineers. In this paper, we use systematic mapping to provide an overview of recommendation systems for the requirements engineering process, their characteristics, and state of validation. The resulting maps are analyzed to provide conclusions and to identify the limitations of current studies, and future research areas. The results of the mapping are used to outline the motivation for our future work on a recommendation system that helps product managers decide on the assignment of requirements to subsequent releases while considering constraints such as time, effort, quality, and resources.
{"title":"Systematic mapping of recommendation systems for requirements engineering","authors":"Jamshaid G. Mohebzada, G. Ruhe, A. Eberlein","doi":"10.1109/ICSSP.2012.6225965","DOIUrl":"https://doi.org/10.1109/ICSSP.2012.6225965","url":null,"abstract":"Recommendation systems provide users with up-to-date guidance on processes, artifacts or other project-relevant information. Recommendation systems for requirements engineering can be used to provide the right information, at the right time, to requirements engineers. In this paper, we use systematic mapping to provide an overview of recommendation systems for the requirements engineering process, their characteristics, and state of validation. The resulting maps are analyzed to provide conclusions and to identify the limitations of current studies, and future research areas. The results of the mapping are used to outline the motivation for our future work on a recommendation system that helps product managers decide on the assignment of requirements to subsequent releases while considering constraints such as time, effort, quality, and resources.","PeriodicalId":166836,"journal":{"name":"2012 International Conference on Software and System Process (ICSSP)","volume":"77 1-3 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-06-02","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126989127","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}
Pub Date : 2012-06-02DOI: 10.1109/ICSSP.2012.6225986
Mery Pesantes, Cuauhtémoc Lemus Olalde, Hugo A. Mitre-Hernández, J. Mejía
Software organizations are moving to a process oriented approach to develop its products. Many improvement technologies have emerged as a response in a multimodel environment. The term improvement technology is used to refer in general to the long list of reference models, standards, best practices, regulatory policies and other types of practices that an organization may use simultaneously (i.e. CMMI, ISO 15504, ISO 9001, Bootstrap and others). The simultaneous use of multiple improvement technologies is causing many problems such as the handling of heterogeneous improvement technologies for deriving processes. Although process architecture has been considered as a means for harmonizing these technologies and assisting process stakeholders do their job, it is unclear how to design a process architecture that supports a multimodel environment. In this article, we identify and analyze main problems in a multimodel environment and critical issues in process architecture area. As a result of this, we derive a set of criteria, as groundwork to design a process architecture in a multimodel environment.
{"title":"Identifying criteria for designing a process architecture in a multimodel environment","authors":"Mery Pesantes, Cuauhtémoc Lemus Olalde, Hugo A. Mitre-Hernández, J. Mejía","doi":"10.1109/ICSSP.2012.6225986","DOIUrl":"https://doi.org/10.1109/ICSSP.2012.6225986","url":null,"abstract":"Software organizations are moving to a process oriented approach to develop its products. Many improvement technologies have emerged as a response in a multimodel environment. The term improvement technology is used to refer in general to the long list of reference models, standards, best practices, regulatory policies and other types of practices that an organization may use simultaneously (i.e. CMMI, ISO 15504, ISO 9001, Bootstrap and others). The simultaneous use of multiple improvement technologies is causing many problems such as the handling of heterogeneous improvement technologies for deriving processes. Although process architecture has been considered as a means for harmonizing these technologies and assisting process stakeholders do their job, it is unclear how to design a process architecture that supports a multimodel environment. In this article, we identify and analyze main problems in a multimodel environment and critical issues in process architecture area. As a result of this, we derive a set of criteria, as groundwork to design a process architecture in a multimodel environment.","PeriodicalId":166836,"journal":{"name":"2012 International Conference on Software and System Process (ICSSP)","volume":"32 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-06-02","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130388428","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}
Pub Date : 2012-06-02DOI: 10.1109/ICSSP.2012.6225984
Fabian Fagerholm, Jürgen Münch
New ways of working such as globally distributed development or the integration of self-motivated external developers into software ecosystems will require a better and more comprehensive understanding of developers' feelings, perceptions, motivations and identification with their tasks in their respective project environments. User experience is a concept that captures how persons feel about products, systems and services. It evolved from disciplines such as interaction design and usability to a much richer scope that includes feelings, motivations, and satisfaction. Similarly, developer experience could be defined as a means for capturing how developers think and feel about their activities within their working environments, with the assumption that an improvement of the developer experience has positive impacts on characteristics such as sustained team and project performance. This article motivates the importance of developer experience, sketches related approaches from other domains, proposes a definition of developer experience that is derived from similar concepts in other domains, describes an ongoing empirical study to better understand developer experience, and finally gives an outlook on planned future research activities.
{"title":"Developer experience: Concept and definition","authors":"Fabian Fagerholm, Jürgen Münch","doi":"10.1109/ICSSP.2012.6225984","DOIUrl":"https://doi.org/10.1109/ICSSP.2012.6225984","url":null,"abstract":"New ways of working such as globally distributed development or the integration of self-motivated external developers into software ecosystems will require a better and more comprehensive understanding of developers' feelings, perceptions, motivations and identification with their tasks in their respective project environments. User experience is a concept that captures how persons feel about products, systems and services. It evolved from disciplines such as interaction design and usability to a much richer scope that includes feelings, motivations, and satisfaction. Similarly, developer experience could be defined as a means for capturing how developers think and feel about their activities within their working environments, with the assumption that an improvement of the developer experience has positive impacts on characteristics such as sustained team and project performance. This article motivates the importance of developer experience, sketches related approaches from other domains, proposes a definition of developer experience that is derived from similar concepts in other domains, describes an ongoing empirical study to better understand developer experience, and finally gives an outlook on planned future research activities.","PeriodicalId":166836,"journal":{"name":"2012 International Conference on Software and System Process (ICSSP)","volume":"144 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-06-02","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116075145","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}
Pub Date : 2012-06-02DOI: 10.1109/ICSSP.2012.6225976
R. Turner, R. Madachy, Dan Ingold, J. Lane
Systems engineering processes using pull scheduling methods (kanban) are being evaluated with hybrid modeling and simulation. We are assessing integrated systems and software engineering at the enterprise level, where rapid response software development projects incrementally evolve capabilities of existing systems and/or systems of systems. A kanban-based scheduling system was defined and implemented with connected discrete, continuous and agent-based models. We are simulating the process performance vs. traditional methods of sharing systems engineering services across projects, and whether the overall value of the systems of systems over time is increased.
{"title":"Modeling kanban processes in systems engineering","authors":"R. Turner, R. Madachy, Dan Ingold, J. Lane","doi":"10.1109/ICSSP.2012.6225976","DOIUrl":"https://doi.org/10.1109/ICSSP.2012.6225976","url":null,"abstract":"Systems engineering processes using pull scheduling methods (kanban) are being evaluated with hybrid modeling and simulation. We are assessing integrated systems and software engineering at the enterprise level, where rapid response software development projects incrementally evolve capabilities of existing systems and/or systems of systems. A kanban-based scheduling system was defined and implemented with connected discrete, continuous and agent-based models. We are simulating the process performance vs. traditional methods of sharing systems engineering services across projects, and whether the overall value of the systems of systems over time is increased.","PeriodicalId":166836,"journal":{"name":"2012 International Conference on Software and System Process (ICSSP)","volume":"5 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-06-02","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114330387","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}
Pub Date : 2012-06-02DOI: 10.1109/ICSSP.2012.6225959
Natalja Nikitina, M. Kajko-Mattsson, Magnus Strale
Transitioning from one development method to another has become a common routine for many companies. Despite this, very few reports describe how the process transition has been carried out, and provide suggestions for how to define a process transition model. This paper reports on a process transition from Scrum to Scrumban in one software development company. The paper gives an account on the process transition process, changes done to the development process undergoing the transition and the improvements achieved. It rounds up with lessons learned.
{"title":"From scrum to scrumban: A case study of a process transition","authors":"Natalja Nikitina, M. Kajko-Mattsson, Magnus Strale","doi":"10.1109/ICSSP.2012.6225959","DOIUrl":"https://doi.org/10.1109/ICSSP.2012.6225959","url":null,"abstract":"Transitioning from one development method to another has become a common routine for many companies. Despite this, very few reports describe how the process transition has been carried out, and provide suggestions for how to define a process transition model. This paper reports on a process transition from Scrum to Scrumban in one software development company. The paper gives an account on the process transition process, changes done to the development process undergoing the transition and the improvements achieved. It rounds up with lessons learned.","PeriodicalId":166836,"journal":{"name":"2012 International Conference on Software and System Process (ICSSP)","volume":"14 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2012-06-02","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126997804","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}