Evaluation of Approaches for Documentation in Continuous Software Development
Saved in:
| Title: | Evaluation of Approaches for Documentation in Continuous Software Development |
|---|---|
| Authors: | Theunissen, Theo, Onderzoeker, Overbeek, Sietse, Onderzoeker, Hoppenbrouwers, Stijn, Lector |
| Contributors: | Data & Knowledge Engineering, HAN University of Applied Sciences@@@Academie IT en Mediadesign@@@Lectoraten |
| Source: | Proceedings of the 18th International Conference on Evaluation of Novel Approaches to Software Engineering - ENASE. :404-411 |
| Publisher Information: | HAN University of Applied Sciences, 2023. |
| Publication Year: | 2023 |
| Subject Terms: | Software documentation, Agile, Lean management, DevOps, Software Engineering, Software architecture |
| Description: | With the adoption of values, principles, practices, tools and processes from Agile, Lean, and DevOps, knowledge preservation has become a serious issue because documentation is largely left out. We identify two questions that are relevant for knowledge acquisition and distribution concerning design decisions, rationales, or reasons for code change. The first concerns which knowledge is required upfront to start a project. The second question concerns continuation after initial development and addresses which knowledge is required by those who deploy, use or maintain a software product. We evaluate two relevant approaches for alleviating the issues, which are ‘Just enough Upfront’ and ‘Executable Documentation’ with a total of 25 related artifacts. For the evaluation, we conducted a case study supported by a literature review, organizational and project metrics, and a survey. We looked into closed source-code and closed classified source-code. We found two conclusive remarks. First, g it commit messages typically contain what has been changed but not why source-code has been changed. Design decisions, rationale, or reasons for code change should be saved as close as possible to the source-code with Git Pull Requests. Second, knowledge about a software product is not only written down in artifacts but is also a social construction between team members. |
| Document Type: | conference Object |
| Access URL: | https://surfsharekit.nl/public/72ef16b3-f65d-41d1-9ff9-13bdc3413bee https://surfsharekit.nl/objectstore/9706754d-c3b6-490c-8f66-1a0e723ed63f |
| Availability: | http://www.hbo-kennisbank.nl/en/page/hborecord.view/?uploadId=sharekit_han:oai:surfsharekit.nl:72ef16b3-f65d-41d1-9ff9-13bdc3413bee |
| Accession Number: | edshbo.sharekit.han.oai.surfsharekit.nl.72ef16b3.f65d.41d1.9ff9.13bdc3413bee |
| Database: | HBO Kennisbank |
Nájsť tento článok vo Web of Science | Abstract: | With the adoption of values, principles, practices, tools and processes from Agile, Lean, and DevOps, knowledge preservation has become a serious issue because documentation is largely left out. We identify two questions that are relevant for knowledge acquisition and distribution concerning design decisions, rationales, or reasons for code change. The first concerns which knowledge is required upfront to start a project. The second question concerns continuation after initial development and addresses which knowledge is required by those who deploy, use or maintain a software product. We evaluate two relevant approaches for alleviating the issues, which are ‘Just enough Upfront’ and ‘Executable Documentation’ with a total of 25 related artifacts. For the evaluation, we conducted a case study supported by a literature review, organizational and project metrics, and a survey. We looked into closed source-code and closed classified source-code. We found two conclusive remarks. First, g it commit messages typically contain what has been changed but not why source-code has been changed. Design decisions, rationale, or reasons for code change should be saved as close as possible to the source-code with Git Pull Requests. Second, knowledge about a software product is not only written down in artifacts but is also a social construction between team members. |
|---|