System Development Processes

Contexto: O desenvolvimento de aplicacoes moveis cresce, acompanhando as constantes evolucoes do hardware dos dispositivos. Com esta evolucao, mais e mais recursos sao adicionados e integrados a vida diaria dos usuarios. Contudo, a pratica de testes de software utilizada pela comunidade para garantir o correto funcionamento das aplicacoes, incluindo a verificacao de aspectos de seguranca, portabilidade e compatibilidade, continua sendo um assunto pouco difundido. Objetivo: O objetivo deste estudo e compreender como as equipes lidam com a pratica de testes de software aplicada ao contexto movel, a relacao cotidiana dos desenvolvedores com a literatura cientifica, a automacao de testes e os desafios encontrados neste contexto. Metodo: Foi elaborado um estudo qualitativo, baseado na metodologia de Analise Tematica, em tres etapas: um survey, de carater exploratorio, que obteve 44 respostas de profissionais da area, seguido de uma secao de entrevistas com 12 profissionais para detalhar ...

Agile methodology has been increasingly adopted for software development. However, little information on the application of processes and practices of agile methodologies end up having repercussions on Technical Debt (TD). This study aims to detect the understanding of software development professionals about DT in agile development. This study is applied in nature with a quantitative approach through exploratory research, data collection was application of an online questionnaire followed by statistical analysis. Sampling was non-probabilistic with 33 respondents, it can be observed that professionals have different reasons for the occurrence of TD. It was also detected that there is no organizational culture. This study proposes the Knowledge Portal and the Knowledge Café to disseminate experiences among professionals.

As práticas do governo eletrônico (e-gov) objetivam aumentar a transparência e a eficiência dos serviços públicos governamentais através do uso das tecnologias da informação. No entanto, negligenciar aspectos de usabilidade, comunicabilidade e boas experiências de usuário (User eXperience – UX) ao desenvolver soluções governamentais, prejudica e degrada a eficiência da governança digital (G2G). Neste contexto, esta pesquisa reporta como as práticas de Interação Humano-Computador (IHC) podem mitigar o referido problema ao serem utilizadas na concepção de soluções computacionais para a G2G. A metodologia utilizada na pesquisa segue os princípios do desenvolvimento de software utilizando o modelo de prototipação incremental, no qual uma ferramenta para G2G é submetido a avaliações formativas de usabilidade, comunicabilidade e UX. Os resultados obtidos revelaram a melhor aceitação da versão final da ferramenta após a utilização das metodologias de avaliação de IHC e o redesign do protót...

This paper describes a case study about introducing, implementing, and using Scrum in three software development companies in Norway. The study is based on several interviews and the data was analyzed using grounded theory practices. The motivation for this case study is to increase knowledge on the process of adopting Scrum in a company. In addition, we wanted to identify problematic issues regarding introduction and adoption of Scrum, issues that will be used to formulate further studies. The elements described in this paper are aspects of Scrum that the companies consider important. Specifically, we describe how Scrum was introduced in the companies, how it affected overtime, how self-organizing teams were handled, how the roles in Scrum functioned, and the relationship of the Scrum Team to the rest of the organization. The findings indicate that sudden implementation of Scrum is a painful process and that the role of the Scrum Master is unclear. Furthermore, there may be a lack of common understanding of the concept of self-organizing teams. In addition the companies did not experience the productivity gain they expected and finally, introducing Scrum implies large changes in organizational culture and work practices that may be difficult to adapt to.

O objetivo geral desta pesquisa é planejar os processos de capacitação para os novos colaboradores e de formação continuada para os colaboradores atuais, para que esses se apropriem das ferramentas e dos processos da organização. A pesquisa é de natureza aplicada com abordagem qualitativa através de pesquisa descritiva sobre uma StartUp maringaense. A análise sobre o processo de capacitação da StartUp demonstra que este exige muito tempo dos seus diretores pois estes devem estar presentes nas capacitações. Além disso, os formadores devem explicar sobre a StartUp, seus processos e ferramentas, exigindo que todos estejam síncronos durante o processo. Finalmente, detecta-se que os colaboradores não recebem formação contínua sobre ferramentas e/ou processos após o período de capacitação. Propõe-se um modelo para capacitação e formação contínua para resolver essas dificuldades

The issue of controlling R&D behaviors and outcomes has attracted the interest of many managers in the last decades (Kerssen-van Drongelen and Bilderbeek 1999). In the turbulent business environment, quick responses to change are vital for organizations to survive and this is made possible through a strong control of firms' behaviors. Moreover, organizations need to learn from the past, in order to be able to identify

Resumo: Técnicas de Criatividade são ferramentas utilizadas para o estímulo do pensamento criativo, auxiliando pessoas a encontrar soluções inovadoras para seus problemas. A importância da criatividade no desenvolvimento de software é reconhecida e estudada por pesquisadores nas últimas décadas, contudo desenvolvedores de software ainda fazem pouco uso dessas ferramentas, a detrimento de suas vantagens. Com o objetivo de encorajar a adoção e o suporte ao uso das técnicas de criatividade no desenvolvimento de software, foi revisado e reestruturado um grande número de técnicas e criado o Guia de Padrões de Criatividade. O Guia segue os princípios de Padrões de Projeto, explicando e exemplificando o uso das técnicas de criatividade no contexto de desenvolvimento de software. Este artigo descreve o desenvolvimento do Guia, as escolhas metodológicas, estrutura das páginas e a interface final da ferramenta.

Requisitos não-funcionais (RNFs) precisam ser conhecidos e adequadamente tratados desde o início do ciclo de desenvolvimento do software. O objetivo deste artigo foi investigar se é possível obter dos clientes os RNFs da aplicação, de acordo com a opinião dos profissionais envolvidos com o processo de desenvolvimento. Para isso, foi utilizado um processo de pesquisa baseado no modelo disponibilizado por Kitchenham e Pfleeger. A pesquisa contou com a participação de 98 (noventa e oito) profissionais com diferentes níveis de experiência. Os resultados mostraram que os profissionais acreditam que a maioria dos tipos de RNFs não pode ser solicitada pelo cliente da aplicação em virtude da falta de conhecimento técnico necessário.

Software development process presents various types of models with their corresponding phases required to be accordingly followed in delivery of quality products and projects. Despite the various expertise and skills of systems analysts, designers, and programmers, systems failure is inevitable when a suitable development process model is not followed. This paper focuses on the Iterative and Incremental Development (IID)model and justified its role in the analysis and design software systems. The paper adopted the qualitative research approach that justified and harnessed the relevance of IID in the context of systems analysis and design using the Vocational Career Information System (VCIS) as a case study. The paper viewed the IID as a change-driven software development process model. The results showed some system specification, functional specification of system and design specifications that can be used in implementing the VCIS using the IID model. Thus, the paper concluded that in systems analysis and design, it is imperative to consider a suitable development process that reflects the engineering mind-set, with heavy emphasis on good analysis and design for quality assurance.

The evolutionary potential of digital technologies has made e-Gov a governance strategy in order to benefit citizens' access to and use of public services. Therefore, it is understood that e-Gov needs to meet the real needs of the population, one of the means for this to happen would be the development of user-centered systems. From this scenario, in partnership with a demand presented by an organization that develops e-Gov in Brazil, the action research method was adopted, with the purpose of inserting user-centered design practices during the organization's systems development process. The execution of the action research began in the explore phase, presenting an initial diagnosis, where the demand and need for insertion of user-centered design in the organization were verified. The main procedures applied in the explore phase were conversation and refinement, interviews and content analysis. In the act phase, in a practical-collaborative process with the organization's representatives, the problem was defined and the elaboration of actions, which were structured in planning, execution and evaluation. In the first cycle of the action research an overview of the knowledge of user-centered design in the area of systems development in the organization was carried out. The results of the first cycle were guiding for carrying out new interventions, and so, successively, the cyclical process of action research took place. The essential focus of the actions was on the lack of knowledge on the subject of user-centered design in the organization, therefore, the interventions carried out resulted in collaborative efforts to cater for this situation. The main procedures applied in the act phase were theoretical-conceptual mediations, questionnaire, elaboration of an informational-communicational material, the creation of a support tool with possible suggestions of user-centered design techniques. In addition, based on the organization's strategic planning, it was possible to carry out other interventions, which were produced in conjunction with the human resources and user experience laboratory teams, providing support and collaboration for the insertion of user-centered design in pilot projects , creation of a script for registration of internal cases, as well as the presentation of internal cases mapped by members of the action research, and the availability of an introductory course on user-centered design for the development teams. In the finalize phase, a final report was prepared that summarizes the actions carried out in the organization. In conclusive terms, conducting the thesis through action research, facilitated the identification of barriers or difficulties that may impede the insertion of user-centered design in the organization. With this identification, and in common agreement with the members of the action research, some actions were carried out to supply knowledge/concepts, as also the conception of a practical-operational tool to support developers. Through internal partnerships it was possible, initially, to mobilize the awareness and internalization of user-centered design in the organization. But, by empirical experience, it is understood that cultural change is slow, and requires continuity, a certain insistence from those involved in the practical-collaborative process to continue the transformation and internalization of user-centered design in the organization.

This paper describes a case study about introducing, implementing, and using Scrum in three software development companies in Norway. The study is based on several interviews and the data was analyzed using grounded theory practices. The motivation for this case study is to increase knowledge on the process of adopting Scrum in a company. In addition, we wanted to identify problematic issues regarding introduction and adoption of Scrum, issues that will be used to formulate further studies. The elements described in this paper are aspects of Scrum that the companies consider important. Specifically, we describe how Scrum was introduced in the companies, how it affected overtime, how self-organizing teams were handled, how the roles in Scrum functioned, and the relationship of the Scrum Team to the rest of the organization. The findings indicate that sudden implementation of Scrum is a painful process and that the role of the Scrum Master is unclear. Furthermore, there may be a lack ...

An increasing number of companies aim to enable their development teams to work in an agile manner. When introducing agile teams, companies face several challenges. This paper explores the kind of leadership needed to support teams to work in an agile way. One theoretical agile leadership concept describes a Scrum Master who is supposed to empower the team to lead itself. Empirical findings on such a leadership role are controversial. We still have not understood how leadership unfolds in a team that is by definition self-organizing. Further exploration is needed to better understand leadership in agile teams. Our goal is to explore how leadership changes while the team matures using the example of the Scrum Master. Through a grounded theory study containing 75 practitioners from 11 divisions at the Robert Bosch GmbH we identified a set of nine leadership roles that are transferred from the Scrum Master to the Development Team while it matures. We uncovered that a leadership gap and...

In an action research study, we describe the application of the scrum software development process in a small cross-organizational development project. The stakeholders in the project report many of the benefits we have found in previous studies, such as increased overview of the project, flexibility and motivation. In addition, we have found that estimation can be challenging in cross-organizational projects due to the customer-provider relationship between the participating organizations.

Software development process presents various types of models with their corresponding phases required to be accordingly followed in delivery of quality products and projects. Despite the various expertise and skills of systems analysts, designers, and programmers, systems failure is inevitable when a suitable development process model is not followed. This paper focuses on the Iterative and Incremental Development (IID)model and justified its role in the analysis and design software systems. The paper adopted the qualitative research approach that justified and harnessed the relevance of IID in the context of systems analysis and design using the Vocational Career Information System (VCIS) as a case study. The paper viewed the IID as a change-driven software development process model. The results showed some system specification, functional specification of system and design specifications that can be used in implementing the VCIS using the IID model. Thus, the paper concluded that in systems analysis and design, it is imperative to
consider a suitable development process that reflects the engineering mind-set, with heavy emphasis on good analysis and design for quality assurance.

Context: Software development depends significantly on team performance, as does any process that involves human interaction. Objective: Most current development methods argue that teams should self-manage. Our objective is thus to provide a better understanding of the nature of self-managing agile teams, and the teamwork challenges that arise when introducing such teams. Method: We conducted extensive fieldwork for 9 months in a software development company that introduced Scrum. We focused on the human sensemaking, on how mechanisms of teamwork were understood by the people involved. Results: We describe a project through Dickinson and McIntyre's teamwork model, focusing on the interrelations between essential teamwork components. Problems with team orientation, team leadership and coordination in addition to highly specialized skills and corresponding division of work were important barriers for achieving team effectiveness. Conclusion: Transitioning from individual work to self-managing teams requires a reorientation not only by developers but also by management. This transition takes time and resources, but should not be neglected. In addition to Dickinson and McIntyre's teamwork components, we found trust and shared mental models to be of fundamental importance.

The daily stand-up meeting is one of the most used agile practices but has rarely been the subject of empirical research. The present study aims to identify how daily stand-up meetings are conducted and what the attitudes towards them are. A grounded theory study with 12 software teams in three companies in Malaysia, Norway, Poland and the United Kingdom was conducted. We interviewed 60 people, observed 79 daily stand-up meetings and collected supplementary data. The factors that contributed the most to a positive attitude towards the daily stand-up meeting were information sharing with the team and the opportunity to discuss and solve problems. The factors that contributed the most to a negative attitude were status reporting to the manager and that the frequency of the meeting was perceived to be too high and the duration too long. Based on our results, we developed a grounded theory of daily standup meetings and proposed empirically based recommendations and guidelines on how to organize them. Organizations should be aware of the factors that may affect the attitude towards daily stand-up meetings and should consider our recommendations and guidelines to make this agile practice as valuable as possible.

In this paper a tool is proposed to foster reflection in agile software development teams. Based upon the qualitative model of Moe et al. , we contribute a quantitative questionnaire organized along five dimensions of agile teamwork analogous to the "Five Factor Model" in contemporary psychology. To test this survey tool and its alignment with existing studies, we have executed an empirical validation of the tool with 79 individuals and 8 international Scrum teams. We find that interteam agreement on the factors is high and that the survey tool is found very useful. The instrument offers a comparable measure to agile teams and gives recommendations for each of the factors helping to understand individual as well as organizational level barriers.

Agile software development has become the standard in many companies. While there are reports of major improvements with agile development over traditional development, many teams still strive to work effectively as a team. A multiple case study in two companies discovered challenges related to communication, learning and selecting the tasks according to the priority list. For example, the fact that the developers were not actively involved in the planning process, resulted in weak team orientation; even though the teams had identified and discussed recurring problems, they found it difficult to improve their teamwork practices; and because customers and support communicated tasks directly to the developers and developers chose tasks according to interest and expertise, following the priority list became difficult. We provide practical suggestions for teamwork in agile software development that intend to overcome these problems and strengthen team orientation and team learning in order to achieve effective agile teams.

Traditional software teams consist of independently focused self-managing professionals with high individual but low team autonomy. A challenge with introducing agile software development is that it requires a high level of both individual and team autonomy. This paper studies the barriers with introducing self-organizing teams in agile software development and presents data from a seven month ethnographic study of professional developers in a Scrum team. We found the most important barrier to be the highly specialized skills of the developers and the corresponding division of work. In addition we found a lack of system for team support, and reduced external autonomy to be important barriers for introducing selforganizing teams. These findings have implications for software development managers and practitioners.

Context: Software development depends significantly on team performance, as does any process that involves human interaction. Objective: Most current development methods argue that teams should self-manage. Our objective is thus to provide a better understanding of the nature of self-managing agile teams, and the teamwork challenges that arise when introducing such teams. Method: We conducted extensive fieldwork for 9 months in a software development company that introduced Scrum. We focused on the human sensemaking, on how mechanisms of teamwork were understood by the people involved. Results: We describe a project through Dickinson and McIntyre's teamwork model, focusing on the interrelations between essential teamwork components. Problems with team orientation, team leadership and coordination in addition to highly specialized skills and corresponding division of work were important barriers for achieving team effectiveness. Conclusion: Transitioning from individual work to self-managing teams requires a reorientation not only by developers but also by management. This transition takes time and resources, but should not be neglected. In addition to Dickinson and McIntyre's teamwork components, we found trust and shared mental models to be of fundamental importance.

This paper describes a case study about introducing, implementing, and using Scrum in three software development companies in Norway. The study is based on several interviews and the data was analyzed using grounded theory practices. The motivation for this case study is to increase knowledge on the process of adopting Scrum in a company. In addition, we wanted to identify problematic issues regarding introduction and adoption of Scrum, issues that will be used to formulate further studies.