Adaptation of enterprise architecture efforts to an agile environment

Agile ways of working have become mainstream, with many organisations practising a form of agile. Agile maturity among those organisations differs. In a research conducted by VersionOne Inc. (2016), 82% of the participating organisations stated to be at or below the level of ‘still maturing’. Existing agile and architecture methods have begun to incorporate some aspects of each other, with agile methods including architecting, such as the Scaled Agile Framework (SAFe), and architecture frameworks such as TOGAF (the Open Group Architecture Framework), adding agile elements (Poort, 2014). This study addresses the question how to shape the architecture function to effectively achieve compliance with architecture regulations, of solutions realised in an agile environment. To answer this question a multiple-case study was done, studying three different organisations. The findings are translated into seven propositions

Arkkitehtuuriset suunnittelupäätökset ketterissä ohjelmistokehitysryhmissä

Architectural design decisions have been a focal point of architectural research for years. Yet our understanding of how such decisions are made in agile development teams is limited to assuming that tightly knit developers make such decisions together. Even this assumption goes out the window when the development team is not co-located. There is also little understanding of when architectural decisions are made with different methods giving contradicting recommendations. The goal of this thesis is to show how architectural design decisions are made in one distributed agile development team. The research was done using action research methodologies due to their strength in understanding groups that are not very strictly structured. In the studied team independent developers have the initial responsibility for architectural design decisions but can share this responsibility with other members of the development team if necessary. We will also show the product owners role in supporting the developers in decision making and how the decisions that have been made are communicated to the product owner and the development team. In addition we present three project phases for architectural decision making: planning, foundation and iterative. We will show how problems arise when the developers fail to identify architectural design decisions or are unable to get the help they need for making them. We will also show how diverting understanding on how the system should work between the product owner and development team can lead to great problems. Based on these results we introduce a set of communication and development recommendations for alleviating these problems. We conclude that although empowering individual developers in making architectural design decisions carries many benefits it also puts heavy stock on both the abilities of individual developers in identifying and making architectural design decisions, but also in the team's ability to work together making of these decisions. Distributed teams should especially take these challenges into account in their development process.Arkkitehtuuriset suunnittelupäätökset ovat olleet keskeinen osa ohjelmistoarkkitehtuurin tutkimusta jo vuosikymmenen ajan. Kuitenkin ymmärryksemme siitä, miten arkkitehtuuriset suunnittelupäätökset tehdään ketterissä kehitysryhmissä, rajoittuu olettamukseen, että tiiviisti toimivat ketterät kehitysryhmät tekevät nämä päätökset yhdessä. Edes tämä oletus ei päde hajautettujen ryhmien tapauksessa. Tämän diplomityön tavoitteena on kuvata miten arkkitehtuuriset suunnittelupäätökset tehdään yhdessä ketterässä kehitysryhmässä. Tutkimus toteutettiin toimintatutkimuksena sillä se sopii hyvin rakenteellisesti löyhien ryhmien tutkimiseen. Tutkitussa kehitysryhmässä vastuu arkkitehtuurisista suunnittelupäätöksistä on yksittäisillä kehittäjillä. Kuitenkin kehittäjät voivat tarvittaessa jakaa tätä vastuuta muille kehittäjille. Osoitamme myös kuinka tuoteomistajalla on suuri rooli päätösten teon tukena ja näytämme kuinka tehdyt päätökset kommunikoidaan muille kehittäjille ja tuoteomistajalle. Lisäksi kuvailemme arkkitehtuuristen päätösten tekemistä projektin kolmessa eri vaiheessa, jotka ovat suunnitteleva, perustava ja iteratiivinen. Arkkitehtuuriin vaikuttavat suunnittelupäätökset nousevat ongelmaksi, kun kehittäjät eivät tunnista suunnittelupäätöksiä arkkitehtuurisesti merkittäväksi tai kun kehittäjät eivät saa tarvitsemaansa tukea päätösten tekemiseen. Työssä osoitetaan myös kuinka tuoteomistajan ja kehittäjien yhteisen näkemyksen puute kehitettävästä tuotteesta johtaa suuriin ongelmiin arkkitehtuuristen päätösten tekemiseksi. Näiden ongelmien lievittämiseksi esitetään joukko parannusehdotuksia. Johtopäätöksenä todetaan, että vaikka on edullista antaa yksittäisten kehittäjien tehdä arkkitehtuurisia päätöksiä, tämä vaatii kehittäjiltä kykyä tunnistaa ja tehdä arkkitehtuurisia suunnittelupäätöksiä sekä kehitysryhmältä mahdollisuuksia toimia yhdessä. Varsinkin hajautettujen kehitysryhmien tulisi ottaa nämä seikat huomioon

Proposta de metodologia de gestão de riscos para projetos ágeis de software no Instituto Nacional de Estudos e Pesquisas Anísio Teixeira (INEP)

Dissertação (mestrado)—Universidade de Brasília, Instituto de Ciências Exatas, Departamento de Ciência da Computação, 2017.Visando atender as necessidades finalísticas do INEP, a Diretoria de Tecnologia e Disseminação de Informações Educacionais (DTDIE) desenvolve sistemas censitários e avaliativos para levantamento de dados que posteriormente possam gerar indicadores a fim de subsidiar a formulação de políticas públicas educacionais [46]. Este trabalho trata-se de estudo de caso realizado com base nos dados dos sistemas da Coordenação Geral de Sistemas de Informação (CGSI) subordinada a DTDIE. Analisando quantitativamente os dados dos sistemas da CGSI, foi possível diagnosticar que aproximadamente 48% de todas as ordens de serviços (OSs) de desenvolvimento de software foram entregues em atraso. Para entender as possíveis causas destes atrasos, foi realizada análise de causas raízes, por meio da FTA (Análise da Árvore de Falhas). Neste contexto, somando-se às recomendações por órgãos de controle sobre a adoção da gestão de riscos, avistou-se a necessidade de se propor uma metodologia de gestão de riscos com vistas a aumentar a perspectiva de sucesso dos projetos. A elaboração da metodologia de gestão de riscos propõe uma integração ao ciclo de desenvolvimento ágil de software adotado na coordenação. Para isso, foi desenvolvido o processo da gestão de riscos, alinhado à norma ISO/IEC 31000:2009 em conjunto com as recomendações constantes na instrução normativa INC MP/CGU N o 01/2016, integrada às etapas de desenvolvimento de software abarcadas no framework Scrum [93] [64]. Assim, foram analisados os modelos mais atuais de integração da gestão de riscos e métodos ágeis, por fim, dando origem a um modelo próprio. Esta metodologia também define um fluxograma evidenciando quais ferramentas poderão ser utilizadas em cada atividade da gestão de riscos. Ainda, foi desenvolvido um checklist de riscos comuns em projetos de software, para auxiliar na atividade de identificação dos riscos. Também foi elaborada proposta de template de Relatório de Gestão e Comunicação dos Riscos, que contemple todo o gerenciamento e monitoramento, podendo ser customizado dentro de software de gestão de riscos.In order to meet the final needs of INEP, the Educational Information Technology and Dissemination Board (DTDIE) develops census and evaluation systems for data collection that can later generate indicators to subsidize the formulation of educational public policies [46]. This work is a case study based on data from the General Information System Coordination (CGSI) systems under DTDIE. This General Coordination is directly responsible for the development, maintenance and support of INEP’s final systems. By quantitatively analyzing data from CGSI systems, it was possible to diagnose that approximately 48 % of all software development service orders (OSs) were delivered behind schedule. In order to understand the possible causes of these delays, a root cause analysis was performed through the Fault Tree Analysis (FTA). In this context, risk management is highly recommended because it presents risk mitigation actions as a way to prevent them from materializing and can increase the probability of reaching institutional goals. That is the reason the adoption of risk management has been widely recommended by the government controlling bodies. The proposed risk management methodology suggests an integration to the cycle of agile software development adopted. For this purpose, the risk management process was developed according to ISO / IEC 31000: 2009 and the recommendations of Normative Instruction INC MP / CGU N o 01/2016 and totally integrated to the Scrum Framework software development stages [93] [64]. Prior to the model definition, most current models of risk management and agile methods integration were analyzed. Proposed Methodology also defines a flow chart showing tools that could be used in each risk management activity. Also, a checklist of common risks in software projects was developed to assist the risk identification activity. Finally, a template for the Risk Management and Communication Report is presented. This document includes all management and monitoring activities and could be used to provide transparency to risks

Improving Bespoke Software Quality: Strategies for Application and Enterprise Architects

Despite over 50 years of software engineering as a formal practice, contemporary developers of bespoke software follow development practices that result in low-quality products with high development and maintenance costs. This qualitative case study sought to identify strategies used by software and enterprise architects for applying architectural best practices to improve bespoke software quality and lower the total cost of ownership. The study population was application and enterprise architects associated with delivering bespoke software for the enterprise architecture team at a large enterprise in the Nashville, Tennessee metropolitan area. Interview data were collected from 7 enterprise or solution architects; in addition, 47 organizational documents were gathered. Guided by the principles of total quality management, thematic analysis was used to identify codes and themes related to management of quality in software solutions. Prominent themes included focusing on customer satisfaction, collaborating and communicating with all stakeholders, and defining boundaries and empowering people within those boundaries. The findings from this research have implications for positive social change, including improved work-life balance, morale, and productivity of software and enterprise architects through streamlining development and maintenance activities

DEVELOPMENT OF A QUALITY MANAGEMENT ASSESSMENT TOOL TO EVALUATE SOFTWARE USING SOFTWARE QUALITY MANAGEMENT BEST PRACTICES

Organizations are constantly in search of competitive advantages in today’s complex global marketplace through improvement of quality, better affordability, and quicker delivery of products and services. This is significantly true for software as a product and service. With other things being equal, the quality of software will impact consumers, organizations, and nations. The quality and efficiency of the process utilized to create and deploy software can result in cost and schedule overruns, cancelled projects, loss of revenue, loss of market share, and loss of consumer confidence. Hence, it behooves us to constantly explore quality management strategies to deliver high quality software quickly at an affordable price. This research identifies software quality management best practices derived from scholarly literature using bibliometric techniques in conjunction with literature review, synthesizes these best practices into an assessment tool for industrial practitioners, refines the assessment tool based on academic expert review, further refines the assessment tool based on a pilot test with industry experts, and undertakes industry expert validation. Key elements of this software quality assessment tool include issues dealing with people, organizational environment, process, and technology best practices. Additionally, weights were assigned to issues of people, organizational environment, process, and technology best practices based on their relative importance, to calculate an overall weighted score for organizations to evaluate where they stand with respect to their peers in pursuing the business of producing quality software. This research study indicates that people best practices carry 40% of overall weight, organizational best v practices carry 30% of overall weight, process best practices carry 15% of overall weight, and technology best practices carry 15% of overall weight. The assessment tool that is developed will be valuable to organizations that seek to take advantage of rapid innovations in pursuing higher software quality. These organizations can use the assessment tool for implementing best practices based on the latest cutting edge management strategies that can lead to improved software quality and other competitive advantages in the global marketplace. This research contributed to the current academic literature in software quality by presenting a quality assessment tool based on software quality management best practices, contributed to the body of knowledge on software quality management, and expanded the knowledgebase on quality management practices. This research also contributed to current professional practice by incorporating software quality management best practices into a quality management assessment tool to evaluate software