Systematic review on evaluating planning process in agile development methods

Agile development methods have been catering the need of faster delivery of theever-demanding domain of software engineering. These methods are able to deliver value to users and businesses via fast, reliable, and repeatable process.  Planning requirements and processes takes the driving seat in a dynamic environment because the value proposition rapidly changes. This paper exhibits asystematic literature review of planning processes implementedby various agile methods in order to find the best suited agile method in terms of robust planning. Keywords: It was found that Scrum is the best suited agile method for planning processes

DevOps in an ISO 13485 Regulated Environment: A Multivocal Literature Review

Background: Medical device development projects must follow proper directives and regulations to be able to market and sell the end-product in their respective territories. The regulations describe requirements that seem to be opposite to efficient software development and short time-to-market. As agile approaches, like DevOps, are becoming more and more popular in software industry, a discrepancy between these modern methods and traditional regulated development has been reported. Although examples of successful adoption in this context exist, the research is sparse. Aims: The objective of this study is twofold: to review the current state of DevOps adoption in regulated medical device environment; and to propose a checklist based on that review for introducing DevOps in that context. Method: A multivocal literature review is performed and evidence is synthesized from sources published between 2015 to March of 2020 to capture the opinions of experts and community in this field. Results: Our findings reveal that adoption of DevOps in a regulated medical device environment such as ISO 13485 has its challenges, but potential benefits may outweigh those in areas such as regulatory, compliance, security, organizational and technical. Conclusion: DevOps for regulated medical device environments is a highly appealing approach as compared to traditional methods and could be particularly suited for regulated medical development. However, an organization must properly anchor a transition to DevOps in top-level management and be supportive in the initial phase utilizing professional coaching and space for iterative learning; as such an initiative is a complex organizational and technical task.Comment: ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM '20), October 8--9, 2020, Bari, Ital

What Makes Agile Test Artifacts Useful? An Activity-Based Quality Model from a Practitioners' Perspective

Background: The artifacts used in Agile software testing and the reasons why these artifacts are used are fairly well-understood. However, empirical research on how Agile test artifacts are eventually designed in practice and which quality factors make them useful for software testing remains sparse. Aims: Our objective is two-fold. First, we identify current challenges in using test artifacts to understand why certain quality factors are considered good or bad. Second, we build an Activity-Based Artifact Quality Model that describes what Agile test artifacts should look like. Method: We conduct an industrial survey with 18 practitioners from 12 companies operating in seven different domains. Results: Our analysis reveals nine challenges and 16 factors describing the quality of six test artifacts from the perspective of Agile testers. Interestingly, we observed mostly challenges regarding language and traceability, which are well-known to occur in non-Agile projects. Conclusions: Although Agile software testing is becoming the norm, we still have little confidence about general do's and don'ts going beyond conventional wisdom. This study is the first to distill a list of quality factors deemed important to what can be considered as useful test artifacts

Working software over comprehensive documentation : Rationales of agile teams for artefacts usage

Agile software development (ASD) promotes working software over comprehensive documentation. Still, recent research has shown agile teams to use quite a number of artefacts. Whereas some artefacts may be adopted because they are inherently included in an ASD method, an agile team decides itself on the usage of additional artefacts. However, explicit rationales for using them remain unclear. We start off to explore those rationales, and state our primary research question as: What are rationales for agile teams to use artefacts? Our research method was a multiple case study. In 19 agile teams we identified 55 artefacts and concluded that they in general confirm existing research results. We introduce five rationales underlying the usage of artefacts in ASD: (1) Adoption of ASD leads to agile artefacts, (2) team-internal communication leads to functional and technical design artefacts, (3) quality assurance leads to test-related artefacts, (4) agile teams impose governance on their own activities, and (5) external influences impose user-related material. With our contribution we substantiate the theoretical basis of the Agile Manifesto in general and contribute to the current research with regard to the usage of artefacts in ASD in particular. Agile teams themselves may from this research extract guidelines to use more or less comprehensive documentation

Working software over comprehensive documentation: Rationales of agile teams for artefacts usage

Agile software development (ASD) promotes working software over comprehensive documentation. Still, recent research has shown agile teams to use quite a number of artefacts. Whereas some artefacts may be adopted because they are inherently included in an ASD method, an agile team decides itself on the usage of additional artefacts. However, explicit rationales for using them remain unclear. We start off to explore those rationales, and state our primary research question as: What are rationales for agile teams to use artefacts? Our research method was a multiple case study. In 19 agile teams we identified 55 artefacts and concluded that they in general confirm existing research results. We introduce five rationales underlying the usage of artefacts in ASD: (1) Adoption of ASD leads to agile artefacts, (2) team-internal communication leads to functional and technical design artefacts, (3) quality assurance leads to test-related artefacts, (4) agile teams impose governance on their own activities, and (5) external influences impose user-related material. With our contribution we substantiate the theoretical basis of the Agile Manifesto in general and contribute to the current research with regard to the usage of artefacts in ASD in particular. Agile teams themselves may from this research extract guidelines to use more or less comprehensive documentation

Working software over comprehensive documentation – Rationales of agile teams for artefacts usage

Abstract Agile software development (ASD) promotes working software over comprehensive documentation. Still, recent research has shown agile teams to use quite a number of artefacts. Whereas some artefacts may be adopted because they are inherently included in an ASD method, an agile team decides itself on the usage of additional artefacts. However, explicit rationales for using them remain unclear. We start off to explore those rationales, and state our primary research question as: What are rationales for agile teams to use artefacts? Our research method was a multiple case study. In 19 agile teams we identified 55 artefacts and concluded that they in general confirm existing research results. We introduce five rationales underlying the usage of artefacts in ASD: (1) Adoption of ASD leads to agile artefacts, (2) team-internal communication leads to functional and technical design artefacts, (3) quality assurance leads to test-related artefacts, (4) agile teams impose governance on their own activities, and (5) external influences impose user-related material. With our contribution we substantiate the theoretical basis of the Agile Manifesto in general and contribute to the current research with regard to the usage of artefacts in ASD in particular. Agile teams themselves may from this research extract guidelines to use more or less comprehensive documentation

Requirements Engineering that Balances Agility of Teams and System-level Information Needs at Scale

Context: Motivated by their success in software development, large-scale systems development companies are increasingly adopting agile methods and their practices. Such companies need to accommodate different development cycles of hardware and software and are usually subject to regulation and safety concerns. Also, for such companies, requirements engineering is an essential activity that involves upfront and detailed analysis which can be at odds with agile development methods. Objective: The overall aim of this thesis is to investigate the challenges and solution candidates of performing effective requirements engineering in an agile environment, based on empirical evidence. Illustrated with studies on safety and system-level information needs, we explore RE challenges and solutions in large-scale agile development, both in general and from the teams’ perspectives. Method: To meet our aim, we performed a secondary study and a series of empirical studies based on case studies. We collected qualitative data using interviews, focus groups and workshops to derive challenges and potential solutions from industry. Findings: Our findings show that there are numerous challenges of conducting requirements engineering in agile development especially where systems development is concerned. The challenges discovered sprout from an integration problem of working with agile methods while relying on established plan-driven processes for the overall system. We highlight the communication challenge of crossing the boundary of agile methods and system-level (or plan-driven) development, which also proves the coexistence of both methods. Conclusions: Our results highlight the painful areas of requirements engineering in agile development and propose solutions that can be explored further. This thesis contributes to future research, by establishing a holistic map of challenges and candidate solutions that can be further developed to make RE more efficient within agile environments

Atualização da Interface de Usuário do dotProject+

TCC(graduação) - Universidade Federal de Santa Catarina. Centro Tecnológico. Sistemas de Informação.Empresas em geral, e principalmente as que trabalham com software, devem levar a sério a Gerência de Projetos para que se mantenham competitivas no mercado, e uma ferramenta para o auxílio e acompanhamento desse processo é essencial. Dentre os diversos softwares disponíveis, um que se destaca é o dotProject. Por ser de código livre e desempenhar bem o seu papel, ele tem sido, historicamente, uma das ferramentas que possuem o maior número de downloads. Embora seja utilizado há bastante tempo, ele possui limitações de usabilidade e design, possuindo uma interface com usuário que remete a softwares antigos. Para que os usuários tenham uma melhor experiência ao utilizá-lo, há a necessidade da atualização da interface para que fique com uma apresentação mais moderna e seja visualmente mais agradável. Este trabalho visa propor e realizar alterações na ferramenta levando em conta o estado da arte de usabilidade e estética das demais ferramentas de Gerência de Projetos mais utilizadas atualmente. Para isso, será feita uma atualização de tecnologias, com uso de frameworks Javascript e CSS, reestruturação do layout de todas as telas, correção de bugs conhecidos e a redefinição da lógica de definição da árvore da EAP (Estrutura Analítica do Projeto). Ao final deste projeto, foi possível perceber que a satisfação dos usuários com relação à interface de usuário do dotProject+, por meio de uma avaliação com os atuais alunos da disciplina de Gerência de Projetos do Departamento de Informática e Estatística da UFSC, aumentou.Companies in general, mainly the ones that work with software, must take Project Management seriously to keep themselves competitive in the market, and a tool for helping and monitoring this process is essential. Among the many software available, one that stands out is dotProject. For being an open source tool and play well its role, it has been one of the tools with most downloads in the world. Though it has been used for a long time, it has some usability and design problems, having an aspect of an old software. Looking for a better experience for its users, there is the necessity of an update on its interface so that it has a more modern presentation and becomes visually more pleasant. This work aims to propose and make changes to the tool taking into account the state of art in usability and aesthetics of the currently most used Project Management tools. For this, there will be done a technology update, with the use of Javascript and CSS frameworks, restructuring of the layout of all the screens, fixing of known bugs and a PAS (Project Analytical Structure) tree definition logic reset. By the end of this project, the user satisfaction with the user interface of dotProject+, measured by an evaluation with the current students of Project Management from the Departament of Informatic and Statistics of UFSC, has increased