Software Startup ESSENCE – How Should Software Startups Work?

Assessing the Impact of System Architecture on the Success of Project Management Methodologies in Software Engineering

Aligning business and IT is crucial in the software industry, where successful software projects depend not only on technology but also on management methodology. Software implementation involves development, migration, and tailoring across architecture‐based systems. The previous studies care on measuring success or failure of project methodologies without interest in system architectures and their effect on project management phases. The wrong selection of management methodology means failure of IT firms, where there is a lack in studying the success factor of selecting suitable project management methodology. Furthermore, there is no study until now that cares on searching the relationship between system architectures and project management methodologies. This paper fills this gap by finding answers for the research question “is system architecture's type one of selection factor for methodology of software project management?” This study investigates different models that measured success of the most popular project management methodologies (waterfall, agile, scrum, Kanban, Scrumban, agile‐waterfall, and DevOps) since 2019 until Jan 2026 through all three cases of software development (customization, ETO developing, migration) for three system architectures (MSA, SOA, Monolith). This study uses descriptive statistics to study the relation between system architectures and software project management. Pearson Correlation and Paired t‐test are used to study the success of developing system architecture by management methodologies. Means and Cohen's d are also used to measure the degree of effect. The main result is that management methodology has variable significance in different cases of developing three architecture‐based systems. Selecting a system architecture is correlated and one of project management's success factors.

Software Development Methodologies Evolutionary Trends from Waterfall to DevOps

Agile and DevOps are currently the most popular software development techniques. Software methodologies started with the application of the Waterfall model and other models of Software development. It provides a general overview of the approaches and their integration throughout the Software Development Life Cycle (SDLC). SDLC phases are described and different SDLC methodologies are discussed with respect to their impact on motivation, productivity and quality. A comparison of the traditional Waterfall and newer iterative/incremental/agile is identified, as are the reasons behind this change, such as customer participation, timely feedback, and quality improvement. The following issues are common to all methodologies: architecture limitations, scalability and organizational restrictions. It was identified that the industry tends to follow a hybrid Agile-DevOps practice with more emphasis on automation, continuous integration and collaboration to achieve quick and competitive software environments.

What do feature branches tell us about feature implementation in open-source projects?

It is revealed that feature branches in open-source projects are long-lived, with a median lifespan exceeding two years, diverging from the short, agile iterations typically employed in software development.

Using the Work and Organizational Psychology Perspective in Research on Agile Software Development Teams

Exploring the AHP-AgileITS-ArchDesign: An AHP Model and Tool for Evaluating IT Service Architectural Agile Designs in SMBs

The design of IT services—including the architectural design—is considered a core activity to obtain a cost-effective IT service. Consequently, the main extant IT service frameworks and standards—rigorous and lightweight-agile types—aim to provide guidance for this purpose. However, some of them are reported at a coarse-grain conceptual level, and others are practically null. Consequently, their utilization—in the best case for large businesses—demands additional ad hoc organizational efforts. In the worst case, small and medium businesses (SMBs) are practically blocked from performing these relevant IT service activities by their limited resources. In this research, we are interested in supporting IT service design activities for SMBs, and thus introduce the AHP-AgileITS-ArchDesign model. This AHP-AgileITS-ArchDesign model was elaborated with a Design Science Research Methodology (DSRM), and aims to provide theoretically valid, systematic, agile and usable fine-grain guidance to support the design and evaluation of IT service architectural agile designs. The AHP-AgileITS-ArchDesign model uses a three-Layer AHP model derived from the main lightweight-agile IT service design literature, and its utilization is illustrated with an Academic Data Science Analytics Platform IT Service case. Then, its conceptual validity and its usability are evaluated, respectively, by a Panel of 16 Experts and an Exploratory Pilot Sample of 62 ITSM academics and practitioners. The evaluation results indicate that the AHP-AgileITS-ArchDesign model has a valid theoretical conceptualization and satisfactory usability, and thus can be used by practitioners and academics in SMBs.

Requirements Engineering Artifacts in Agile Development

In Agile software development (ASD) projects requirements are incrementally and iteratively defined, with customer needs frequently expressed in User Stories (USs). However, minimal documentation has been identified as a key challenge for Requirements Engineering (RE) in ASD. Including too little information makes tracing and estimating USs more difficult, while including too many details limit the developer in their solution. In addition, development teams mainly rely on information contained in issue tracking systems, rather than speaking with their customer on a regular basis. To summarize, development teams are highly dependent on few artifacts. This PhD dissertation studies how development teams create and use RE artifacts such as requirements and acceptance criteria, guided by the following main research question: How are Requirements Engineering artifacts used in Agile Software Development? First, we introduce the RE4SA model as a means to support communication between requirements engineers and software architects, recognizing that requirements and architectural components should be designed in tandem. In practice, however, this alignment is difficult to achieve, often due to a lack of concrete guidance in existing models. The RE4SA model addresses this by expressing requirements as epic stories and USs, which are linked to architectural modules and features, respectively. The model is further instantiated as RE4SA-Agile, which connects common agile artifacts and introduces metrics to measure the alignment and granularity between requirements and architecture. These metrics help identify problematic situations, such as when the granularity of requirements or architectural components is inconsistent with the norm. Then, we focus on the definition of key concepts in the field of RE. Concepts, such as those in the RE4SA model, are often interpreted in different ways. To clarify fundamental concepts in software engineering, we propose the Concept Definition Review (CDR) method. The CDR method was formalized in a second iteration, in which we defined and compared the terms “non-functional requirement” and “quality requirement”, which revealed the existence of dozens of definitions, many nearly identical, and highlighting the importance of systematic conceptual analysis for effective communication. We also explored the impact of RE artifacts on efficiency of agile teams, focusing on the use of USs and acceptance criteria by teams. Our empirical studies show that while the quality of USs does not directly correlate with timely completion, the existence of acceptance criteria does improve efficiency; we found evidence for an increase in on-time completion and reduced completion time. Our Canonical Action Research study shows that interventions based on the Quality User Story (QUS) framework can improve the quality of USs, but practitioners sometimes find value in deviating from strict guidelines. This suggests that while guidelines are useful, they must be adaptable to the context and practitioner needs. Finally, the challenge of specifying non-functional requirements (NFRs) is addressed; practitioners expressed a need for support in defining NFRs. Unlike functional requirements, NFRs lack a widely adopted writing format and are notoriously difficult to quantify. A new NFR template is developed and validated, based on requirements from practitioners, incorporating fit criteria to make NFRs more measurable.