Producing Just Enough Documentation: An Optimization Approach Applied to the Software Architecture Domain

Díaz-Pace, J. Andrés; Villavicencio, Christian; Schiaffino, Silvia; Nicoletti, Matías; Vázquez, Hernán C.

doi:10.1007/s13740-015-0053-0

Cited by 10 publications

(3 citation statements)

References 39 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…A link that we did not study, but that is mentioned in other studies, is the relation between stakeholder satisfaction and requirements [65] [66] and documentation [67].…”

Section: Study Reliabilitymentioning

confidence: 91%

The effects of perceived value and stakeholder satisfaction on software project impact

Huijgens

Deursen

Solingen

2017

Information and Software Technology

View full text Add to dashboard Cite

In this paper we present a multiple case study on the insights of software organizations into stakeholder satisfaction and (perceived) value of their software projects. Our study is based on the notion that quantifying and qualifying project size, cost, duration, defects, and estimation accuracy needs to be done in relation with stakeholder satisfaction and perceived value. Objectives: We contrast project metrics such as cost, duration, number of defects and estimation accuracy with stakeholder satisfaction and perceived value. Method: In order to find out whether our approach is practically feasible in an industrial setting, we performed two case studies; one in a Belgian telecom company and the other in a Dutch software company. Results: In this study we evaluate 22 software projects that were delivered during one release in the Belgian telecom company, and 4 additional large software releases (representing an extension of 174% in project size) that were delivered in a Dutch software company. Eightythree (83) key stakeholders of two companies provide stakeholder satisfaction and perceived value measurements in 133 completed surveys. Conclusions: We conclude that a focus on shortening overall project duration, and improving communication and team collaboration on intermediate progress is likely to have a positive impact on stakeholder satisfaction and perceived value. Our study does not provide any evidence that steering on costs helped to improve these. As an answer to our research question-how do stakeholder satisfaction and perceived value relate to cost, duration, defects, size and estimation accuracy of software projects?-we found five takeaway messages .

show abstract

“…A link that we did not study, but that is mentioned in other studies, is the relation between stakeholder satisfaction and requirements [65] [66] and documentation [67].…”

Section: Study Reliabilitymentioning

confidence: 91%

The effects of perceived value and stakeholder satisfaction on software project impact

Huijgens

Deursen

Solingen

2017

Information and Software Technology

View full text Add to dashboard Cite

show abstract

“…A link that we did not study, but that is mentioned in other studies, is the relation between stakeholder satisfaction and requirements (Pitangueira et al, 2016) and documentation (Díaz-Pace et al, 2016).…”

Section: Study Reliabilitymentioning

confidence: 73%

Evidence-based software portfolio management

Huijgens

2016

Proceedings of the 20th International Conference on Evaluation and Assessment in Software Engineering

View full text Add to dashboard Cite

While many studies can be found on estimating the cost (or effort) of software deliveries (Jørgensen & Shepperd, 2007), only a handful exists about the price thereof. For pricing purposes in a commercial context where software delivery is partly performed by suppliers, most companies rely heavily on expert judgment (Boehm, 1984) (Jørgensen, 2004). This is not always a successful approach (Moløkken & Jørgensen, 2003), and software development is often characterized by high cost and schedule overruns (Verhoef, 2002) (Glass, 2002), despite a huge number of tools developed over time to support project estimation (Boehm, 1984

show abstract

“…Hence, it is important to define methods to identify and analyze concerns. Available methods have comprised the use of: (i) manual identification/mapping of concerns; (ii) information stored in software documents, e.g., software requirements documents (SRDs) (Rosenhainer, 2004) and software architecture documents (SADs) (Díaz-Pace et al, 2016) can be used to find concerns; and (iii) automation based on static and dynamic analyses of software projects (Dit et al, 2013; Bernardi et al, 2016. Static analysis refers to the analysis of syntactic models extracted from the source code, e.g.…”

Section: Introductionmentioning

confidence: 99%

Using Third-Party Components’ Metadata to Analyze Cross-cutting Concerns

Carvalho,

Mendes,

Gomes

et al. 2024

JSERD

View full text Add to dashboard Cite

Context: Modularity is a key concept in software development. Well-modularized systems are easier to maintain and evolve, but achieving good modularity is difficult. Concerns that are important, but not central to a systems' main business rules, frequently end up scattered and entangled throughout several software modules. Those so called cross-cutting concerns are a major source of loss of modularity and code decay in software systems. Motivation: Studies on cross-cutting concerns often resort to manual identification of concerns, but manual identification is effort demanding, does not scale, and tends to be imprecise. Automatic approaches are therefore very attractive when the codebase is extensive. In modern systems, developers implement modules to address central business rules, but they tend to add third-party components in the codebase to materialize concerns related to other secondary aspects. Logging, database access, and tests automation are examples of concerns that are usually implemented with the help of imported components and are prone to scatter and tangle throughout the codebase. Aims: This paper proposes a method to track this type of cross-cutting concern. Our work takes advantage of the addition of metadata about components to track them. The method scales by automating the identification and analysis of concerns scattered throughout the software codebase. We define a new metric, Dedication to Concern (DtC), to measure how much source code modules focus on implementing the identified concerns. Working Method: We describe our method to mine cross-cutting concerns from the metadata related to the use of components. The method is instantiated as a tool, architectural knowledge suite (AKS). The tool is used to analyze concerns in a set of large Java projects. The results are used to feed an action research study, during which software development specialists analyze the AKS outputs to evaluate and evolve the method. Conclusion: The semi-automated approach is feasible and scalable, and can be used to analyze secondary concerns that are currently being imported into modern software systems via third-party components.

show abstract

Producing Just Enough Documentation: An Optimization Approach Applied to the Software Architecture Domain

Cited by 10 publications

References 39 publications

The effects of perceived value and stakeholder satisfaction on software project impact

The effects of perceived value and stakeholder satisfaction on software project impact

Evidence-based software portfolio management

Using Third-Party Components’ Metadata to Analyze Cross-cutting Concerns

Contact Info

Product

Resources

About