Socio-technical and Ethical Dimensions of Architecture Practices in FLOSS Sven Thielen
arXiv:2609.09975v1 [cs.SE] 9 Sep 2026
Faculty of Mathematics and Natural Sciences Heinrich Heine University Düsseldorf Düsseldorf, Germany 0009-0004-3487-9137
Abstract—This project investigates how software architecture practices in Free/Libre Open Source Software (FLOSS) are shaped by socio-technical and ethical factors, and how education can support more explicit, inclusive, and reflective architectural work. Motivated by FLOSS’s role in digital sovereignty, it is observed that architectural decisions are often undocumented and scattered across issues, pull requests, and mailing lists. While prior research has studied architectural artifacts, erosion, and communication, the interplay between architectural work, governance arrangements, and ethical commitments in FLOSS remains underexplored. The research follows a three-phase design: (1) multi-method case studies of 3–4 domain-pairs of architecturally non-trivial FLOSS projects, (2) framework and intervention design with practitioners and educators, and (3) pilot evaluations in projects and courses. It will produce (i) cross-case empirical evidence on FLOSS architecture practices, (ii) a conceptual framework linking architecture practices to socio-technical conditions and ethical dimensions, and (iii) lightweight practices and teaching formats that render architectural work more explicit and inclusive. Index Terms—FLOSS, software architecture, maintenance, evolution, governance, socio-technical, ethics, education
I. I NTRODUCTION Free/Libre Open Source Software (FLOSS) constitutes critical infrastructure and is frequently linked to transparency, autonomy, and sustainability. Maintaining these systems therefore depends on the conditions under which architectural decisions are made, communicated, and sustained. Many FLOSS projects rely on emergent, informal architecture; rationale and constraints are only partly captured in artifacts and are scattered across issues, pull requests (PRs), and mailing lists [2], [3]. Prior work highlights architectural erosion [4], [5] and a concentration of decision authority in a few maintainers [9], which creates bottlenecks for review, onboarding, and change. This project investigates how FLOSS architecture practices are shaped by socio-technical and ethical factors, and how can FLOSS-based education support more explicit and reflective work? We conduct multi-method case studies, followed by the design and formative evaluation of lightweight practices and teaching formats. The expected contributions are (i) crosscase empirical evidence, (ii) a conceptual framework, and (iii) actionable, low-overhead practices and teaching formats. ©2026 IEEE. Reproduced with permission. Published in: 2026 IEEE International Conference on Software Maintenance and Evolution (ICSME)
II. BACKGROUND AND R ESEARCH G AP Research on software architecture in FLOSS provides relevant insights, but it is fragmented across distinct strands that rarely integrate architectural practice with governance and ethical concerns in an integrated way. The following paragraphs summarize the most relevant strands for this project. (S1) Architectural artifacts, recovery, and erosion. Empirical studies report that FLOSS projects often rely on partially documented or implicit architectural knowledge, and that architectural erosion can threaten maintainability and longterm evolution [2], [4], [5]. This strand motivates studying what architectural knowledge is captured (e.g., design documents, architecture decision records (ADRs), module boundaries) and how it changes over time. (S2) Communication of architectural knowledge. Architectural rationale in FLOSS is frequently distributed across heterogeneous channels (e.g., issues, pull requests, mailing lists), making it difficult to locate, reuse, and transfer [3]. Complementary analyses of practitioner discourse indicate that architecture discussions may emphasize later-stage concerns (e.g., deployment and operations), leaving earlier decisionmaking and rationale underrepresented [8]. This motivates examining where architectural decisions are negotiated and how rationale becomes (or fails to become) durable project knowledge. (S3) Governance, roles, and decision points. FLOSS governance research has characterized mechanisms of formalization, decentralization, and control in commons-based peer production [1]. Work on maintainership and review pathways (e.g., in the Linux kernel) suggests that responsibility distribution can be operationalized through concrete role arrangements that shape who can approve and coordinate changes [9]. However, governance studies rarely connect these mechanisms explicitly to architectural work (e.g., how architectural boundaries are negotiated, who sets constraints, and how architectural stewardship is maintained). (S4) Ethical concerns, ecosystem health, and participation. Ethical notions such as stewardship, responsibility, and inclusivity are frequently invoked in FLOSS. Architectural practices have been argued to influence ecosystem health [10]. However, these concepts are seldom studied at the level of day-to-day architectural work in projects, and they are rarely
operationalized into observable indicators (e.g., participation pathways in architecture-relevant discussions, traceability of decision rationale, or newcomer access to architectural knowledge). (S5) FLOSS in education and architecture training. FLOSS projects are increasingly used in software engineering education to provide authentic, large-scale systems and real collaboration contexts [6], [7]. At the same time, software architecture education emphasizes the need to teach trade-offs and decision-making beyond purely technical competencies [14]. However, it remains unclear to what extent FLOSSbased teaching explicitly addresses architectural practices as socio-technical work, including questions of responsibility distribution, participation, and rationale capture. Research gap. While strands (S1)–(S5) provide valuable perspectives, it remains underexplored how architectural work in FLOSS emerges at the intersection of artifacts, communication routines, and governance arrangements, and how this intersection relates to ethical concerns such as stewardship, responsibility, and inclusivity. In addition, there is limited evidence on lightweight, actionable practices that improve the durability and accessibility of architectural knowledge without imposing substantial overhead on maintainers, and on how such practices can be translated into educational formats. Project aim. To address this gap, a multi-method case studies of FLOSS projects will be conducted, a conceptual framework linking architectural practice to socio-technical and ethical dimensions will be developed, and lightweight interventions for practice and education will be designed and formatively evaluated. III. R ESEARCH Q UESTIONS AND O BJECTIVES The research design is intentionally iterative: early findings will inform refinement and refocusing of subsequent questions. Overarching research question: How are FLOSS architecture practices shaped by socio-technical and ethical factors, and how can FLOSS-based education make this work more explicit, inclusive and reflective? A. Sub-questions RQ1 How do selected projects document, communicate and coordinate architecture, and how do these practices evolve? RQ2 How do governance, communication structures and ethical considerations shape participation and rationale preservation? RQ3 How do FLOSS-based courses teach architectural decision-making and related socio-technical responsibilities? RQ4 Which lightweight practices and educational formats can improve explicitness and accessibility without raising maintainer workload? These questions are expected to evolve as empirical insights accumulate. The educational strand is therefore treated as a core component of this project rather than an optional addon. The design of teaching formats directly stems from the
empirical findings and is evaluated with the same rigor as the practice-oriented interventions. Table I maps the research strands to the objectives. B. Objectives O1: Systematically characterize architecture artifacts, communication channels, and decision-making mechanisms in a set of FLOSS projects. O2: Analyze how socio-technical and ethical factors shape architectural practices and knowledge distribution in these projects. O3: Examine how FLOSS-based teaching currently presents software architecture and whether it addresses sociotechnical and ethical aspects. O4: Develop a conceptual framework that links architecture practices, socio-technical conditions, and ethical considerations in FLOSS. O5: Design and preliminarily evaluate lightweight architectural practices and educational patterns that support more explicit and reflective architecture work in FLOSS. TABLE I F ROM STATE - OF - THE - ART STRANDS TO DISSERTATION OBJECTIVES Strand (S1) Architectural artifacts, recovery, erosion (S2) Communication of architectural knowledge (S3) Governance, roles, decision points (S4) Ethical concerns, ecosystem health, participation (S5) FLOSS in education
Corresponding Objective(s) O1: systematic characterization of artifacts and their evolution O1: capture of communication routines; O2: analyze how they shape knowledge flow O2: link governance structures to decision authority; O4: feed into design of interventions O2: identify ethical dimensions (stewardship, inclusivity); O4: translate into lightweight practices O3: analyse current teaching practice; O5: create and evaluate educational formats
IV. M ETHODOLOGY The study follows three iterative phases: 1) Information gathering (repo mining, communication analysis, interviews); 2) Solution generation (framework and lightweight practice design); 3) Evaluation (pilots in projects and courses). Repository mining, communication analysis, and semistructured interviews will be combined to capture both observable architectural artifacts and the tacit knowledge that shapes decision-making, thereby avoiding the treatment of social and technical aspects in isolation [11]. Educational materials will be analyzed to examine how FLOSS-based teaching currently represents architecture practices and whether the sociotechnical and ethical dimensions are sufficiently addresses. In Table II, each research question is linked to the primary data sources and the expected methodological outputs (e.g., recovered architectural views, coded decision rationale, and cross-case themes). Each case will produce (i) a description of the project’s architectural knowledge base (artifacts and their traceability),
TABLE II M APPING RESEARCH QUESTIONS TO DATA SOURCES AND METHODS . RQ RQ1 RQ2 RQ3 RQ4
Data Repos, ADRs/docs, dependency structure, issues/PRs Governance docs, communication threads, interviews Syllabi, assignments, teaching cases Co-design feedback, pilot observations
Method / Output Mining + architectural recovery; description of artifacts and coordination patterns Qualitative coding + case comparison; factors shaping responsibility/participation Document analysis; characterization of how architecture and ethics are addressed Design + formative evaluation; lightweight practices and educational patterns
(ii) a map of decision points and participation pathways (who proposes, discusses, and approves architecture-relevant changes), and (iii) themes describing socio-technical and ethical factors shaping architectural work. Fig. 1 provides a visual overview of the three-phase research design. A. Phase 1: Information Gathering and Interpretation (1) Literature review: a systematic review of FLOSS architecture practice, architectural erosion/smells, architecture knowledge communication, and FLOSS-based education will be conducted. (2) Case selection: 3–4 domain-pairs are examined, each pair sharing a comparable architectural core while differing in governance. Selection depends on accessibility of repositories and communication channels. Candidate projects include: • Office suites: LibreOffice vs. OpenOffice.org, • Cryptographic toolchains: GnuPG vs. Sequoia-PGP, • Package managers: Pacman vs. Zypper, • Messaging ecosystems: Matrix ecosystem vs. SimpleX, • Theorem provers: Rocq vs. Z3. Inclusion/exclusion criteria will be reviewed and refined after the initial literature scan and a pilot inspection of artifacts and communication traces; additional criteria (e.g., traceability of decisions, feasibility of recruiting interviewees, suitability for educational activities) will be documented transparently. From each repository, architecture-related artifacts (module structures, design documents) will be extracted and dependency graphs will be computed. Architectural recovery (static-analysis and clustering) will yield views of coupling and modularity. Where possible quantitative proxies will be derived for the five analytic dimensions introduced in the conceptual model: 1) Governance: Presence of formal governance documents will indicate whether an explicit architectural authority exists. Role-based permission matrices (GitHub or GitLab team settings) will reveal the concentration of push/merge rights on architecture-relevant files. 2) Participation: The number of unique contributors that appear in architecture-tagged threads will be counted and the ratio of newcomers (first-time contributors) to veteran participants in those threads will be computed. 3) Decision-power distribution: Ownership concentration will be measured on file-ownership for architectural modules. In parallel, it will be counted how many
reviewers have ever approved an ADR or a designcritical pull request. 4) Ethical stewardship: Design documents and ADRs will be scanned for explicit mentions of ethical concerns (privacy, sustainability, inclusivity). The existence of “participation pathways” (e.g., mentorship tags or “goodfirst-issue” labels) will be recorded. 5) Inclusivity: Diversity of role-types (developers, translators, UX designers, documentation contributors, etc.) will be extracted from mailing-list participant metadata. As a supporting indicator, sentiment or politeness scores will be computed for architecture-related discussions. All proxies will be obtained automatically where feasible (e.g., ownership metrics from the version-control history) and will be validated through the interview phase. The combination of quantitative indicators and qualitative interview data provides a transparent triangulation for reasoning about latent socio-technical and ethical constructs. Issues, pull requests and mailing-list archives will be mined for architecture-relevant threads. Threads are identified through keyword filtering, label-based metadata, and explicit links from ADRs or design documents to the discussion artifacts. A stratified manual sample will validate the retrieval, and the inclusion/exclusion criterion for what constitutes an “architectural decision” or “architectural constraint” will be refined iteratively per project. 10–20 semi-structured interviews with maintainers, reviewers and long-term contributors will be conducted to explore how they conceptualize and enact architecture work and what challenges they perceive. A small corpus of course descriptions, syllabi, and teaching materials from FLOSS-oriented software engineering courses will be collected. The results will provide (i) a descriptive account of current practices (RQ1), (ii) initial insights into the socio-technical and ethical factors (RQ2), and (iii) a baseline of how architecture is taught in FLOSS-based courses (RQ3). These findings will guide the refinement of research questions, sampling strategies, and data collection instruments for the subsequent phases. B. Phase 2: Solution Generation Based on Findings Based on the patterns identified in Phase 1, a framework that relates observed architectural practices to socio-technical factors (e.g., governance, communication structures, roles) and to ethical considerations (e.g., inclusivity, responsibility, stewardship) will be constructed. Lightweight architectural practices for FLOSS projects (e.g., adapted templates for documenting decisions, guidelines for involving newcomers in architecture discussions, or practices for making architectural constraints visible) will be proposed [10]. Prototype educational formats or resources (e.g., course assignments, reflective exercises, or teaching cases) that foreground architecture as a sociotechnical and ethical practice will be developed. A subset of FLOSS contributors and educators will be engaged through codesign sessions or feedback interviews to refine these practices and educational formats. Phase 2 focuses on RQ4, using
Research approach: iterative three-phase design Inputs / data sources: FLOSS repositories: code, ADRs, issues, mailing lists, governance/role descriptions etc. Interviews with maintainers/reviewers, long-term contributors Course materials: syllabi, assignments etc. Phase 1: Empirical case studies
Phase 2: Framework intervention design
Phase 3: Formative pilot refinement
3–4 domain pairs
Practices proposal
Feedback collection
Primary focus: RQ1–RQ3
Primary focus: RQ4 (informed by RQ1–RQ3)
Focus: evaluation and iterative refinement
Expected deliverables: (1) Cross-case empirical evidence
(2) Conceptual framework
(3) Lightweight practices + teaching formats
Fig. 1. Overview of the iterative three-phase research design.
empirical findings and stakeholder input to generate contextsensitive and realistic solutions. C. Phase 3: Evaluation of Proposed Solutions In the final phase, the proposed practices and educational formats will be evaluated and refined. Selected architectural practices (e.g., documentation templates or meeting structures) will be piloted in one or two collaborating FLOSS projects. Educational prototypes will be integrated into one or more teaching settings (e.g., a FLOSS-oriented software engineering course). Qualitative feedback (e.g., interviews, questionnaires, reflexive reports) from contributors and students on feasibility, perceived usefulness, and effects on understanding and participation will be collected. Lightweight quantitative cues will be tracked before and after the pilots, such as (i) adoption and completion rates of the proposed decision/rationale templates, (ii) traceability links between ADRs/design discussions and code changes (e.g., ADR ↔ PR references), and (iii) participation in architecture-relevant discussions (e.g., number of unique contributors and newcomer participation in architecture-tagged threads). Given the formative nature of the pilots, these cues will be treated as indicators to guide refinement rather than as evidence for causal effects [14]. Evaluation results will be used to further refine the conceptual framework and practical guidelines. Phase 3 strengthens the practical relevance and validity of the research outcomes and
supports the development of actionable recommendations for FLOSS communities and educators. D. Validity, Trustworthiness, and Ethics To enhance the robustness of findings, the study will apply the following measures: • Triangulation: Multiple data sources (repositories, artifacts, communication logs, interviews, and educational materials) will be combined and converging and diverging evidence will be compared across sources [12]. • Audit trail and transparency: A coding diary will be maintained, sampling and inclusion/exclusion decisions (e.g., for architecture-relevant threads) will be documented, and the evolving codebook and analysis scripts will be versioned. Where feasible, scripts and deidentified/aggregated datasets will be shared [11]. • Peer debriefing: Coding decisions, emerging themes, and alternative interpretations will be discussed periodically with the supervisory team or research peers (without implying co-authorship) to challenge assumptions and reduce researcher blind spots. • Member checking (interviews): Short summaries of interpreted themes will be shared with interview participants to confirm plausibility and to reveal misunderstandings. • Negative case analysis: Counterexamples will be actively sought within and across cases (e.g., projects
where architectural knowledge is explicit but participation remains concentrated, or vice versa) and explanations will be refined accordingly. • Reflexivity: The researcher’s position and potential biases will be reflected upon when interpreting sociotechnical and ethical dimensions. Risks and mitigation. The most critical risks stem from (i) limited access to maintainers for interviews, (ii) incomplete traceability of architectural rationale, (iii) the possibility that the selected case set does not capture the full spectrum of governance models, and (iv) the rapidly evolving role of generative AI/LLMs in software development. Mitigation strategies are summarised in Table III. TABLE III K EY RISKS AND PLANNED MITIGATION ACTIONS Risk Interview non-response Missing architectural rationale Insufficient domain coverage
Obscured authorship
Scope creep
Mitigation Early outreach via project maintainers; offer flexible interview formats (e-mail, video, async). Combine keyword-based trace mining with manual validation; use interview data to fill gaps. Use the paired-case strategy (two projects per domain) to guarantee at least two instances per governance type. Detect auto-generated commits (e.g., presence of “generated-by-ChatGPT” in commit messages) and treat them as a separate “AI-assisted” provenance class during ownership analysis. Adopt an iterative “stop-criterion”: if after the first two pairs the emerging patterns already saturate (no new themes in coding), subsequent pairs will be used mainly for validation rather than exploration.
AI/LLM note. Recent advances in generative AI are already being used in contributions. While this does not become a primary focus of this work, it will be recorded whether an architectural decision or an ADR was produced (or edited) with the assistance of an LLM (e.g., as identified in commit messages). This lightweight capture allows to assess any systematic impact of AI on decision authority and knowledge distribution without expanding the scope of this project. Additional risk: interpreting communication traces. Text-based communication can be perceived very differently by different developers, increasing the risk of misclassification when relying on trace data alone [13]. Therefore, sensitive interpretations (e.g., conflict) will be triangulated via interviews and reported cautiously. Ethical considerations. For interviews, informed consent will be obtained and participants can withdraw at any time. Recordings/transcripts will be stored securely and reported in aggregated form; direct quotes will be paraphrased or deidentified where necessary to reduce re-identification risks. For trace data, the study will avoid attributing sensitive interpretations to individuals and will anonymize project- and personlevel details where appropriate. V. E XPECTED R ESULTS The expected outcome is a grounded account of how architectural practices are enacted in FLOSS communities, together with a conceptual framework and pragmatic guidance
that can support more explicit and reflective architectural work. By connecting empirical software engineering with educational design, the project aims to produce insights that are relevant both to researchers and to FLOSS practitioners. It complements practitioner-oriented perspectives with a more holistic lens on architectural design, quality, and evolution [8]. Expected deliverables: • Empirical evidence: cross-case insights into how architectural practices are carried out and communicated in FLOSS projects (artifacts, communication patterns, recurring challenges). • Explanatory analysis: how roles, governance, and community norms shape knowledge distribution, participation, and architectural decision-making. • Conceptual framework: links between architecture practices, socio-technical conditions, and ethical considerations in FLOSS. • Interventions: lightweight practices and educational patterns supporting explicit, inclusive, and reflective architecture work in FLOSS and in FLOSS-based teaching. • Research outputs: publications and (where possible) open research data and scripts (e.g., via Zenodo), respecting licensing and ethical constraints. VI. R ESEARCH P LAN AND M ILESTONES Table IV outlines the planned milestones. The schedule may be refined based on access to projects and early empirical findings. TABLE IV P LANNED TIMELINE AND MILESTONES . Time 2026 Q3–Q4 2027 Q1–Q2 2027 Q3 2027 Q4–2028 Q1 2028 Q2 2028 Q3–Q4
Milestones Finalize case selection; finalize data collection protocol; pilot extraction of artifacts and discussion threads. Within-case analyses: repository mining + communication analysis; begin interviews; draft case reports. Cross-case synthesis; draft conceptual framework (sociotechnical and ethical dimensions). Co-design and refinement of lightweight practices and educational formats; prepare pilot deployments. Formative evaluations in 1–2 projects and 1–2 courses; iterate on framework and interventions. Consolidate results; dissertation writing and submission.
VII. F EEDBACK S OUGHT This project seeks feedback from the Doctoral Symposium on the following points: • Operationalization: Which proxies and analysis strategies are defensible to characterize architectural responsibility and decision power distribution from FLOSS traces? • Case strategy: Is the planned case pairing and diversity appropriate in terms of scope and for cross-case synthesis, or is a single case per domain sufficient and should cases be narrowed? • Interventions: Which lightweight interventions are realistic in FLOSS practice and education without increasing maintainer workload (and how should feasibility be assessed)?
ACKNOWLEDGMENT During manuscript preparation, the author used ChatGPT (OpenAI) for language-editing assistance (e.g., phrasing and grammar suggestions) and to explore alternative structures for clarity. The author takes full responsibility for the content and verified all technical claims and references. R EFERENCES [1] David Rozas and Steven Huckle, “Loosen control without losing control: Formalization and decentralization within commons-based peer production,” Journal of the Association for Information Science and Technology, vol. 72, no. 2, pp. 204–223, 2021, DOI:10.1002/asi.24393. [2] Sofia Migliorini, Roberto Verdecchia, Ivano Malavolta, Patricia Lago, and Enrico Vicario, “Architectural Views: The State of Practice in OpenSource Software Projects,” in Software Architecture, Springer Nature Switzerland, pp. 396–415, 2024, DOI:10.1007/978-3-031-70797-1 27. [3] Tingting Bi, Wei Ding, Peng Liang, and Antony Tang, “Architecture Information Communication in Two OSS Projects: the Why, Who, When, and What,” Journal of Systems and Software, vol. 181, Art. no. 111035, 2021, DOI:10.1016/j.jss.2021.111035. [4] Duc Minh Le, Daniel Link, Arman Shahbazian, and Nenad Medvidovic, “An Empirical Study of Architectural Decay in Open-Source Software,” in 2018 IEEE International Conference on Software Architecture (ICSA), pp. 176–184, 2018, DOI:10.1109/ICSA.2018.00027. [5] Sven Thielen, Björn Salgert, and Thomas Franz, “From Lab to Market: Architectural Evolution in Open Source Transition,” in Software Architecture, Springer Nature Switzerland, pp. 306–322, 2025, DOI:10.1007/978-3-032-02138-0 20. [6] Fernanda Gomes Silva, Moara Sousa Brito, Jenifer Vieira Toledo Tavares, and Christina von Flach G. Chavez, “FLOSS in Software Engineering Education: Supporting the Instructor in the Quest for Providing Real Experience for Students,” in Proceedings of the XXXIII Brazilian Symposium on Software Engineering, pp. 234–243, 2019, DOI:10.1145/3350768.3353815. [7] Moara Sousa Brito Lessa and Christina von Flach G. Chavez, “An Approach for Selecting FLOSS Projects for Education,” in Proceedings of the XXXIV Brazilian Symposium on Software Engineering, pp. 463– 472, 2020, DOI:10.1145/3422392.3422492. [8] Ruoyu Su, Noman Ahmad, Matteo Esposito, Andrea Janes, Davide Taibi, and Valentina Lenarduzzi, “Emerging trends in software architecture from the practitioner’s perspective: A five-year review,” Journal of Systems and Software, vol. 236, Art. no. 112820, 2026, DOI:10.1016/j.jss.2026.112820. [9] Eduardo Pinheiro and Paulo Meirelles, “Understanding Group Maintainership Model in the Linux Kernel Development,” Workshop de Visualização, Evolução e Manutenção de Software (VEM), pp. 113–124, 2024, DOI:10.5753/vem.2024.3912. [10] Simone da Silva Amorim, John D. McGregor, Eduardo Santana de Almeida, and Christina von Flach Garcia Chavez, “Software Architectural Practices: Influences on the Open Source Ecosystem Health,” Journal of Software Engineering Research and Development, vol. 11, Art. no. 9, 2023, DOI:10.5753/jserd.2023.967. [11] Rashina Hoda, “Socio-Technical Grounded Theory for Software Engineering,” IEEE Transactions on Software Engineering, vol. 48, no. 10, pp. 3808–3832, 2022, DOI:10.1109/TSE.2021.3106280. [12] Hashini Gunatilake, John Grundy, Rashini Hoda, and Ingo Mueller, “Enablers and Barriers of Empathy in Software Developer and User Interactions: A Mixed Methods Case Study,” ACM Transactions on Software Engineering and Methodology, vol. 33, no. 4, Art. no. 109, 2024, DOI:10.1145/3641849. [13] Marc Herrmann, Martin Obaidi, and Jil Klünder, “Modeling Communication Perception in Development Teams Using Monte Carlo Methods,” in Proceedings of the 29th International Conference on Evaluation and Assessment in Software Engineering, Association for Computing Machinery, pp. 327–337, 2025, DOI:10.1145/3756681.3756937. [14] Wilson Libardo Pantoja Yépez, Julio Ariel Hurtado Alegrı́a, Ajay Bandi, and Arvind W. Kiwelekar, “Training software architects suiting software industry needs: A literature review,” Education and Information Technologies, vol. 29, no. 9, pp. 10931–10994, 2024, DOI:10.1007/s10639023-12149-x.
[15] Dulaji Hidellaarachchi, John Grundy, Rashini Hoda, and Ingo Mueller, “The Influence of Human Aspects on Requirements Engineering-related Activities: Software Practitioners’ Perspective,” ACM Transactions on Software Engineering and Methodology, vol. 32, no. 5, Art. no. 108, 2023, DOI:10.1145/3546943.