International conference on software engineering and knowledge engineering: Session chair

The Thirtieth International Conference on Software Engineering and Knowledge Engineering (SEKE 2018) will be held at the Hotel Pullman, San Francisco Bay, USA, from July 1 to July 3, 2018. SEKE2018 will also be dedicated in memory of Professor Lofti Zadeh, a great scholar, pioneer and leader in fuzzy sets theory and soft computing. The conference aims at bringing together experts in software engineering and knowledge engineering to discuss on relevant results in either software engineering or knowledge engineering or both. Special emphasis will be put on the transference of methods between both domains. The theme this year is soft computing in software engineering & knowledge engineering. Submission of papers and demos are both welcome

Managing Technical Debt in Agile Software Development Projects

One of the key reasons that agile software development methods have gained popularity in recent years is because they enable organizations to produce software quickly to meet the needs of various stakeholders. However, this focus on delivering software quickly often encourages practitioners to incur technical debt – design or implementation constructs that are expedient in the short term but set up a technical context that can make future changes more costly or impossible. Worldwide, technical debt is estimated to be a trillion-dollar problem. This has prompted significant interest from both researchers and practitioners. In this dissertation, I present two essays that advance our knowledge of the causes of technical debt in agile software development projects and that offer potential solutions to manage the most important of these causes of technical debt. In my first essay, I conduct a ranking-type Delphi study of information technology (IT) project managers and software developers to identify and prioritize the most important causes of technical debt in agile software development projects. The findings from this study provide a verified list of 55 causes of technical debt in agile software development projects and offer 13 potential techniques to manage the causes of technical debt that were most important to the IT project managers and software developers in this study. In my second essay, I conduct a randomized experiment to examine the impact of software developers’ construal level, a cognitive process, on the unintentional accumulation of technical debt in software development projects. The findings from this experiment suggest that software developers at a high construal level are more likely to focus on developing the architecture or design than software developers at a low construal level. Collectively, the findings from these two essays deepen our understanding of the intentional and unintentional causes of technical debt in agile software development projects. Further, the findings offer potential techniques to manage the most important causes of technical debt for IT project managers and software developers

Technical Debt in Software Development : Examining Premises and Overcoming Implementation for Efficient Management

Software development is a unique field of engineering: all software constructs retain their modifiability — arguably, at least — until client release, no single project stakeholder has exhaustive knowledge about the project, and even this portion of the knowledge is generally acquired only at project completion. These characteristics imply that the field of software development is subject to design decisions that are known to be sub-optimal—either deliberately emphasizing interests of particular stakeholders or indeliberately harming the project due to lack of exhaustive knowledge. Technical debt is a concept that accounts for these decisions and their effects. The concept’s intention is to capture, track, and manage the decisions and their products: the affected software constructs. Reviewing the previous, it is vital for software development projects to acknowledge technical debt both as an enabler and as a hindrance. This thesis looks into facilitating efficient technical debt management for varying software development projects. In the thesis, examination of technical debt’s role in software development produces the premises on to which a management implementation approach is introduced. The thesis begins with a revision of motivations. Basing on prior research in the fields of technical debt management and software engineering in general, the five motivations establish the premises for technical debt in software development. These include notions of subjectivity in technical debt estimation, update frequency demands posed on technical debt information, and technical debt’s polymorphism. Three research questions are derived from the motivations. They ask for tooling support for technical debt management, capturing and modelling technical debt propagation, and characterizing software development environments and their technical debt instances. The questions imply consecutive completion as the first pursued tool would benefit from—possibly automatically assessable—propagation models, and finally the tool’s introduction to software development organizations could be assisted by tailoring it based on the software development environment and the technical debt instance characterizations. The thesis has seven included publications. In introducing them, the thesis maps their backgrounds to the motivations and their outcomes to the research questions. Amongst the outcomes are the DebtFlag tool for technical debt management, the procedures for retrospectively capturing technical debt from software repositories, a procedure for technical debt propagation model creation from these retrospectives, and a multi-national survey characterizing software development environments and their technical debt instances. The thesis concludes that the tooling support, the technical debt propagation modelling, and the software environment and technical debt instance characterization describe an implementation approach to further efficient technical debt management. Simultaneously, future work is implied as all previously described efforts need to be continued and extended. Challenges also remain in the introduced approach. An example of this is the combinatorial explosion of technology-development-context-combinations that technical debt propagation modelling needs to consider. All combinations have to be managed if exhaustive modelling is desired. There is, however, a great deal of motivation to pursue these efforts when one re-notes that technical debt is a permanent component of software development that, when correctly managed, is a development efficiency mechanism comparable to a financial loan investment.Ohjelmistokehitys on uniikki tekniikan ala: kaikki ohjelmistorakenteet säilyttävät muokattavuutensa — otaksuttavasti ainakin — asiakasjulkaisuun asti. Yhdenkään projektiosakkaan tietämys ei kata koko projektia ja merkittävä osa tästäkin tiedosta karttuu vasta projektin suorittamisen aikana. Nämä ominaisuudet antavat ymmärtää, että ohjelmistokehitysala on sellaisten suunnitelupäätösten kohde, joiden tiedetään olevan epätäydellisiä—joko tarkoituksella tiettyjen projektiosakkaiden intressejä painottavia tai tahattomasti projektia vahingoittavia puutteelliseen tietoon perustuvia. Tekninen velka on konsepti, joka huomioi nämä päätökset sekä niiden vaikutukset. Konseptin tarkoitus on havaita, seurata ja hallita näitä päätöksiä sekä tuloksena syntyviä teknisen velan vaikutuksen alla olevia ohjelmistorakenteita. Edellisen kuvauksen valossa ohjelmistokehitysprojekteille on erityisen tärkeää huomioida tekninen velka sekä mahdollistajana että hidasteena. Tämän vuoksi kyseinen väitöskirja perehtyy tehokkaan teknisen velan hallinnan fasilitointiin moninaisille ohjelmistokehitysprojekteille. Väitöskirjassa tarkastellaan teknisen velan roolia osana ohjelmistokehitystä. Tarkastelu tuottaa joukon premissejä, joihin perustuen esitellään lähestymistapa teknisen velan hallinnan toteuttamiselle. Viisi väitöskirjan alussa esitettyä motivaatiota kiinnittävät ne premissit,joille ratkaisu esitetään. Motivaatiot rakennetaan olemassa olevaan teknisen velan sekä ohjelmistotekniikan tutkimustietoon perustuen. Näihin lukeutuvat muun muassa subjektiivisuus teknisen velan estimoinnissa, teknisen velan informaatiolle nähdyt päivitystaajuusvaatimukset sekä teknisen velan polymorfismi. Havainnoista johdetaan kolme tutkimuskysymystä. Ne tavoittelevat työkalutukea teknisen velan hallinnalle, velan propagoitumisen havainnointia sekä mallinnusta kuin myös ohjelmistotuotantoympäristöjen ja niiden velka instanssien kuvaamista. Tutkimuskysymykset implikoivat peräkkäistä suoritusta: tavoiteltu työkalu hyötyy—mahdollisesti automaattisesti arvoitavista—teknisen velan propagaatiomalleista. Valmiin työkalun käyttöönottoa voidaan taas edistää jos kuvaukset kehitysympäristöistä sekä niiden velkainstansseista ovat käytettävissä työkalun räätälöintiin. Väitöskirjaaan sisältyy seitsemän julkaisua. Väitöskirja esittelee ne kiinnittämällä julkaisujen taustatyön aikaisemmin mainittuihin motivaatioihin sekä niiden tulokset edellisiin tutkimuskysymyksiin. Tuloksista huomioidaan esimerkiksi DebtFlag-työkalu teknisen velan hallintaan, retrospektiivinen prosessi teknisen velan kartoittamiselle versionhallintajärjestelmistä, prosessi teknisen velan mallien rakentamiselle näistä kartoituksista ja monikansallinen kyselytutkimus ohjelmistokehitysympäristöjen sekä näiden teknisen velan instanssien luonnehtimiseksi. Väitöskirjan yhteenvetona huomioidaan, että teknisen velan hallinnan työkalutuki, teknisen velan propagaatiomallinnus ja ohjelmistokehitysympäristöjen sekä niiden teknisen velan instanssien luonnehdinta muodostavat toteutustavan, jolla teknisen velan tehokasta hallintaa voidaan kehittää. Samalla implikoidaan jatkotoimia, sillä kaikkia edellä kuvattuja työn osia tulee jatkaa ja laajentaa. Toteutustavalle nähdään myös haasteita. Eräs näistä on kombinatorinen räjähdys teknologia- ja kehityskontekstikombinaatioille. Kaikki kombinaatiot tulee huomioida mikäli teknisen velan propagaatiomallinnuksesta halutaan kattavaa. Motivaatio väitöskirjassa esitetyn työn jatkamiselle on huomattavaa ja sitä kasvattaa entuudestaan edellä tehty huomio siitä, että tekninen velka on pysyvä komponentti ohjelmistokehityksessä, joka oikein hallittuna on kehitystehokkuutta edistävänä komponenttina verrattavissa finanssialan lainainvestointiin.Siirretty Doriast

A maturity model based on ISO/IEC/IEEE 42010:2011 to identify technical debt in software architecture

Software architecture is considered an important area of Software Engineering, as it is useful for managing the development and maintenance of large scale software-intensive systems. The software architecture as a development product is useful for technical activities, such as describing the views and concerns of the future software products, as well as for management activities, including allocating tasks to each team and as an input for project management activities. One main issue when describing the software architecture is knowing what elements must be included in the architecture, and at what level of detail. Thus, the description of a Software Architecture has been considered a crucial deliverable in a software development process because it is read by many stakeholders when developing and maintaining complex software systems that are composed of multiple elements, including software, systems, hardware, and processes. Due to Software Architecture importance, the ISO/IEC/IEEE 42010:2011 standard was published in 2011. In order to facilitate and assist in the documentation of software architecture, many contributions have been proposed in the past decades for architectural standards, provided by academia and industry. This master thesis proposes the use of standard ISO/IEC/IEEE 42010:2011 to develop a maturity model, named ArchCaMo, which is based on sections 5, 6, and 7 of the mentioned standard. To support the designing of ArchCaMo, a Systematic Mapping Study was performed for describing studies that explicitly used the ISO/IEC/IEEE 42010:2011 standard, and identifying which parts of this standard were most considered in the literature. The ArchCaMo is useful to evaluate current architectures and analyze the rate of architecture debt. In addition, it is effective for organizations that are struggling with organizing, describing, and communicating the software architecture for multiple stakeholders. For each level of architecture maturity, the organization knows what to expect concerning activities and deliverables. Within this objective, three organizations are selected as case studies. The researchers conducted the survey by means of interviews with their software architect or the chief of the software architecture team. By analyzing the obtained results, the authors checked the compliance of their software architecture activities with ISO/IEC/IEEE 42010:2011. As a result, all three organizations were classified on level 1, which means that these organizations fail in at least one aspect to formalize and define the software architecture.Fundação de Apoio a Pesquisa e à Inovação Tecnológica do Estado de Sergipe - FAPITEC/SEArquitetura de software é considerada uma área importante da Engenharia de Software, pois é útil para gerenciar o desenvolvimento e a manutenção de sistemas intensivos de software em larga escala. A arquitetura de software como produto de desenvolvimento é útil para atividades técnicas, como descrever as visões e expectativas dos futuros produtos de software, bem como para atividades de gerenciamento, incluindo a alocação de tarefas para cada equipe e como entrada para as atividades de gerenciamento de projetos. Um problema principal ao descrever a arquitetura do software é saber quais elementos devem ser incluídos na arquitetura e em que nível de detalhe. Assim, a descrição de uma arquitetura de software é considerada uma entrega crucial em um processo de desenvolvimento de software, porque é lida por muitas partes interessadas em desenvolver e manter sistemas de software complexos compostos por vários elementos, incluindo software, sistemas, hardware e processos. Devido à importância da arquitetura de software, o padrão ISO/IEC/IEEE 42010:2011 foi publicado em 2011. Para facilitar e auxiliar na documentação da arquitetura de software, muitas contribuições foram propostas nas últimas décadas para os padrões de arquitetura, fornecidos pela academia e pela indústria. Esta dissertação de mestrado propõe o uso da norma ISO/IEC/IEEE 42010:2011 para desenvolver um modelo de maturidade, denominado ArchCaMo, baseado nas seções 5, 6 e 7 da norma mencionada. Para apoiar o projeto do ArchCaMo, foi realizado um Mapeamento Sistemático para descrever estudos que usavam explicitamente o padrão ISO/IEC/IEEE 42010:2011 e identificar quais partes desse padrão foram mais consideradas na literatura. ArchCaMo é útil para avaliar arquiteturas atuais e analisar a taxa de dívida técnica da arquitetura. Além disso, ele é eficaz para organizações que estão lutando para organizar, descrever e comunicar a arquitetura de software para vários interessados. Para cada nível de maturidade da arquitetura, a organização sabe o que esperar em relação a atividades e entregas. Dentro deste objetivo, três organizações são selecionadas como estudos de caso. Os pesquisadores conduziram a pesquisa por meio de entrevistas com seu arquiteto de software ou com o chefe da equipe de arquitetura de software. Ao analisar os resultados obtidos, os autores verificaram a conformidade de suas atividades de arquitetura de software com a norma ISO/IEC/IEEE 42010:2011. Como resultado, todas as três organizações foram classificadas no nível 1, o que significa que essas organizações falham em pelo menos um aspecto em formalizar e definir a arquitetura do software.São Cristóvão, S

Agile Processes in Software Engineering and Extreme Programming: 18th International Conference, XP 2017, Cologne, Germany, May 22-26, 2017, Proceedings

agile software development; lean development; scrum; project management; software developmen

Collaboration Strategies to Reduce Technical Debt

Inadequate software development collaboration processes can allow technical debt to accumulate increasing future maintenance costs and the chance of system failures. The purpose of this qualitative case study was to explore collaboration strategies software development leaders use to reduce the amount of technical debt created by software developers. The study population was software development leaders experienced with collaboration and technical debt at a large health care provider in the state of California. The data collection process included interviews with 8 software development leaders and reviewing 19 organizational documents relating to software development methods. The extended technology acceptance model was used as the conceptual framework to better understand the social and cognitive influences on the perceived usefulness of collaboration in reducing technical debt. An inductive analysis of the data was used for coding, triangulation, and identifying themes related to the use of collaboration strategies to reduce technical debt. Prominent themes included using collaboration at all stages of development, using continuous verification processes, promoting a participatory culture, and using tools to support distributed teams. The study findings showed an environment that promotes collaboration, a culture that encourages participation, and accessibility to collaborative tools that may reduce technical debt in software projects. The results of this study may contribute to positive social change by demonstrating how individuals with diverse backgrounds and different perspectives can work together to improve critical software that people depend on every day

An evaluation of the challenges of Multilingualism in Data Warehouse development

In this paper we discuss Business Intelligence and define what is meant by support for Multilingualism in a Business Intelligence reporting context. We identify support for Multilingualism as a challenging issue which has implications for data warehouse design and reporting performance. Data warehouses are a core component of most Business Intelligence systems and the star schema is the approach most widely used to develop data warehouses and dimensional Data Marts. We discuss the way in which Multilingualism can be supported in the Star Schema and identify that current approaches have serious limitations which include data redundancy and data manipulation, performance and maintenance issues. We propose a new approach to enable the optimal application of multilingualism in Business Intelligence. The proposed approach was found to produce satisfactory results when used in a proof-of-concept environment. Future work will include testing the approach in an enterprise environmen

Agile Processes in Software Engineering and Extreme Programming

This open access book constitutes the proceedings of the 22nd International Conference on Agile Software Development, XP 2021, which was held virtually during June 14-18, 2021. XP is the premier agile software development conference combining research and practice. It is a unique forum where agile researchers, practitioners, thought leaders, coaches, and trainers get together to present and discuss their most recent innovations, research results, experiences, concerns, challenges, and trends.  XP conferences provide an informal environment to learn and trigger discussions and welcome both people new to agile and seasoned agile practitioners. This year’s conference was held with the theme “Agile Turns Twenty While the World Goes Online”. The 11 full and 2 short papers presented in this volume were carefully reviewed and selected from 38 submissions. They were organized in topical sections named: agile practices; process assessment; large-scale agile; and short contributions

Mapeo sistemático sobre las arquitecturas de software en el desarrollo ágil

(ANTECEDENTES) El uso de frameworks y metodologías ágiles en el desarrollo de software es cada vez mayor, priorizando la entrega de valor al cliente, en este contexto las actividades de arquitectura de software son omitidas al no entregar un valor tangible, existiendo un aparente conflicto de perspectivas y no se tiene definido cuanto esfuerzo se debe invertir en el desarrollo de una arquitectura en proyectos ágiles. (OBJETIVOS) El objetivo de este trabajo es consolidar las distintas investigaciones respecto al uso de arquitecturas de software en el desarrollo ágil, identificar patrones arquitectónicos, factores, beneficios, desafíos, y lecciones aprendidas con respecto a la combinación. (MÉTODOS) Para este estudio se realizó un mapeo sistemático de la literatura en bases de datos digitales relevantes. (RESULTADOS) Se seleccionaron 61 artículos publicados desde el año 2015 hasta el año 2020, el 54% fueron de aplicación industrial principalmente en el sector salud, aeroespacial y automotriz, se pudo identificar que en el año 2016 se publicaron el mayor número de artículos referente al tema de investigación, donde la conferencia es el tipo de publicación más utilizado y el evento IEEE International Conference es el mayor canal de distribución .Adicionalmente, se identificó que el estilo arquitectónico más empleado es SOA, la práctica ágil más referenciada es Scrum , el uso combinado del framework Scrum y el estilo SOA es el más usado, emplear el estilo SOA en el sector salud es el más citado en las publicaciones, la flexibilidad que brinda tener una arquitectura sólida es la mayor ventaja referenciada asimismo los conflictos de enfoques entre la agilidad y las actividades de arquitectura es identificado como el mayor inconveniente que se afronta ,y la comunicación es el factor que más influye en la adopción de arquitecturas de software en el desarrollo ágil.(BACKGROUND) The use of agile frameworks and methodologies in software development is increasing, prioritizing the delivery of value to the client, in this context, software architecture activities are omitted by not delivering tangible value, with an apparent conflict of perspectives and it is not defined how much effort should be invested in the development of an architecture in agile projects. (OBJECTIVES) The objective of this work is to consolidate the different investigations regarding the use of software architectures in agile development, to identify architectural patterns, factors, benefits, challenges, and lessons learned regarding the combination. (METHODS) For this study, a systematic mapping of the literature in relevant digital databases was carried out. (RESULTS) 61 articles published from 2015 to 2020 were selected, 54% were of industrial application mainly in the health, aerospace, and automotive sectors, it was possible to identify that in 2016 the largest number of articles were published on the subject of research, where the conference is the most used type of publication and the IEEE International Conference event is the largest distribution channel. Additionally, it was identified that the most used architectural style is SOA, the most referenced agile practice is Scrum, the combined use of Scrum framework and the SOA style is the most used, using the SOA style in the health sector is the most cited in publications, the flexibility provided by having a solid architecture is the greatest advantage referenced also the conflicts of approaches between agility and architectural activities is identified as the greatest inconvenience faced, and communication is the factor that most influences the adoption of software architectures in agile development

Software Sustainability: Research and Practice from a Software Architecture Viewpoint

Context: Modern societies are highly dependent on complex, large-scale, software-intensive systems that increasingly operate within an environment of continuous availability, which is challenging to maintain and evolve in response to the inevitable changes in stakeholder goals and requirements of the system. Software architectures are the foundation of any software system and provide a mechanism for reasoning about core software quality requirements. Their sustainability – the capacity to endure in changing environments – is a critical concern for software architecture research and practice. Problem: Accidental software complexity accrues both naturally and gradually over time as part of the overall software design and development process. From a software architecture perspective, this allows several issues to overlap including, but not limited to: the accumulation of technical debt design decisions of individual components and systems leading to coupling and cohesion issues; the application of tacit architectural knowledge resulting in unsystematic and undocumented design decisions; architectural knowledge vaporisation of design choices and the continued ability of the organization to understand the architecture of its systems; sustainability debt and the broader cumulative effects of flawed architectural design choices over time resulting in code smells, architectural brittleness, erosion, and drift, which ultimately lead to decay and software death. Sustainable software architectures are required to evolve over the entire lifecycle of the system from initial design inception to end-of-life to achieve efficient and effective maintenance and evolutionary change. Method: This article outlines general principles and perspectives on sustainability with regards to software systems to provide a context and terminology for framing the discourse on software architectures and sustainability. Focusing on the capacity of software architectures and architectural design choices to endure over time, it highlights some of the recent research trends and approaches with regards to explicitly addressing sustainability in the context of software architectures. Contribution: The principal aim of this article is to provide a foundation and roadmap of emerging research themes in the area of sustainable software architectures highlighting recent trends, and open issues and research challenges