Value Based Software Engineering

We consider a set of programs a family when it pays to look at their common aspects before looking at their differences. For commercial software developers the implications are twofold: First, making rational decisions about product-line processes and products requires the ability to answer the question: "Does it pay?" Second, whether or not something pays is ultimately a business (rather than software engineering) question. In short, making sound software engineering decisions requires understanding the business implications of those decisions, and vice versa. This paper describes work in progress to develop a product-line process model and common value metric that adequately link product value drivers (what it pays) with the software engineering decisions that affect those drivers. In it, we describe a systematic approach to quantifying the return on investment for both product and process improvements based on common software engineering principles and a common value me...

Project managers aim at keeping track of interdependencies between various artifacts of the software development lifecycle, to find out potential requirements conflicts, to better understand the impact of change requests, and to fulfill process quality standards, such as CMMI requirements. While there are many methods and techniques on how to technically store requirements traces, the economic issues of dealing with requirements tracing complexity remain open. In practice tracing is typically not an explicit systematic process, but occurs rather ad hoc with considerable hidden tracing-related quality costs. This paper reports a case study on value-based requirements tracing (VBRT) that systematically supports project managers in tailoring requirements tracing precision and effort based on the parameters stakeholder value, requirements risk/volatility, and tracing costs. Main results of the case study were: (a) VBRT took around 35% effort of full requirements tracing; (b) more risky or volatile requirements warranted more detailed tracing because of their higher change probability.

The Value-Based Software Engineering (VBSE) agenda described in the preceding article has the objectives of integrating value considerations into current and emerging software engineering principles and practices, and of developing an overall framework in which they compatibly reinforce each other. In this paper, we provide a case study illustrating some of the key VBSE practices, and focusing on a particular anomaly in the monitoring and control area: the "Earned Value Management System". This is a most useful technique for monitoring and controlling the cost, schedule, and progress of a complex project. But it has absolutely nothing to say about the stakeholder value of the system being developed. The paper introduces an example order-processing software project, and shows how the use of Benefits Realization Analysis, stakeholder value proposition elicitation and reconciliation, and business case analysis provides a framework for stakeholder-earned-value monitoring and control.

The Value-Based Software Engineering (VBSE) agenda described in the preceding article has the objectives of integrating value considerations into current and emerging software engineering principles and practices, and of developing an overall framework in which they compatibly reinforce each other. In this paper, we provide a case study illustrating some of the key VBSE practices, and focusing on a particular anomaly in the monitoring and control area: the "Earned Value Management System". This is a most useful technique for monitoring and controlling the cost, schedule, and progress of a complex project. But it has absolutely nothing to say about the stakeholder value of the system being developed. The paper introduces an example order-processing software project, and shows how the use of Benefits Realization Analysis, stakeholder value proposition elicitation and reconciliation, and business case analysis provides a framework for stakeholder-earned-value monitoring and control.

Context: To remain competitive, innovative and to grow, companies must change from cost-based decision-making to value-based decision-making where the decisions taken maximize software value and support company's overall value creation. Objective: The objective of this paper is to complement and expand an existing classification of value aspects within the context of product management and development with additional aspects relating to value within the context of project management and development. Method: In this study, we present the results from a snowballing literature review that focuses on software value in software project management. In the research for relevance literature we focus on software value aspects different than cost as cost is widely used in project management literature to estimate value. Results: We have identified nine primary studies in two snowball iterations. From these studies, we derived three categories of value aspects: financial, risk analysis and process improvement based on value identification.

In software development, the waterfall model is commonly used, especially for large-scale software systems. For smaller-scale software development, agile software development approaches such as extreme programming or scrum are used. Traditional software development methodologies are mainly targeted toward customer-centric development, and therefore, new software methodologies are often not well received in the industry. In this study, we propose a new software development methodology that is aimed at developing innovative software using artificial intelligence (AI), idea creation, value engineering, and systems design. The name of our method is named as EPISODE (Extreme Programming method for Innovative SOftware based on systems DEsign). EPISODE supports the efficient and creative development of open source software (OSS) by small groups. Moreover we describe an evaluation of EPISODE in a class.

In this study, we investigate the state of the literature and practice about Value-Based Requirements Engineering. We focus on identifying what models for VBRE were presented and what challenges were discussed. We triangulate our results with industrial practitioners by conducting an industrial survey with 59 respondents. We identified 26 primary and 3 secondary studies and synthesized the findings using content analysis. VBRE was identified to be having a positive impact among survey practitioners. However, challenges like aligning product, project and organization opinions, selecting a most valuable requirement for a particular release, and including time-dependent requirements were identified to be impacting the organizations. The results from the study also suggest that, value dimensions like stakeholder value and customer value were not so frequently discussed in RE processes in both literature and among our industry respondents.

Open source software (OSS) solutions provide missioncritical services to industry and government organizations. However, empirical studies on OSS development practices raise concerns on risky practices such as unclear requirement elicitation, ad hoc development process, little attention to quality assurance (QA) and documentation, and poor project management. Event then the ability to produce high quality products in such an environment may seem surprising and thus warrants an investigation on effective QA mechanism in OSS projects. This paper provides a preliminary exploration to improve our understanding of software quality practices in different types of OSS projects. We propose a framework of QA in an OSS project, elicit OSS stakeholder value propositions for QA, and derive performance indicators. For an initial empirical evaluation we applied these indicators to 5 releases of 2 large Apache projects (Tomcat and MyFaces) to analyze the extent to which QA aspects are commonly performed during development process.

Traceability from requirements to code is mandated by numerous software development standards. These standards, however, are not explicit about the appropriate level of quality of trace links. From a technical perspective, trace quality should meet the needs of the intended trace utilizations. Unfortunately, long-term trace utilizations are typically unknown at the time of trace acquisition which represents a dilemma for many companies. This chapter suggests ways to balance the cost and benefits of requirements traceability. We present data from three case studies demonstrating that trace acquisition requires broad coverage but can tolerate imprecision. With this trade-off our lessons learned suggest a traceability strategy that (1) provides trace links more quickly, (2) refines trace links according to user-defined value considerations, and (3) supports the later refinement of trace links in case the initial value consideration has changed over time. The scope of our work considers the entire life cycle of traceability instead of just the creation of trace links.

Design decisions crucially influence the success of every software project. While the resulting design is typically documented quite well, the situation is usually different for the underlying rationale and decision-making process. Despite being recognized as a helpful approach in general, the explicit documentation of Design Decision Rationale is not yet largely utilized due to some inhibitors (e.g., additional documentation effort). Experience with other qualities, e.g. software reusability, evidently shows that an improvement of these qualities only pays off on a large scale and therefore has to be pursued in a strategic, pre-planned, and carefully focused way. In this paper we argue that this also has to be considered for documenting DDR. To this end the paper presents: (i) the Decision, Goal, and Alternatives (DGA) DDR framework, (ii) experience in dealing with DGA, (iii) motivators and inhibitors of using DDR, and (iv) an approach for systematic DDR use that follows value-based software engineering principles.

... M. Ramzan, M. Arfan Jaffar M. Amjad Iqbal, Sajid Anwar, Arshad A. Shahid National University of Computer and Emerging ... AK Brohi Road, H11/4 Islamabad, Pakistan, {muhammad.ramzan, arfan.jaffar}@nu.edu.pk, {amjad.iqbal, sajid.anwar, arshad.a.shahid}@nu.edu.pk ...

Many software development standards mandate establishing trace links among software artifacts such as requirements, architectural elements, or source code. However, for typical real-world systems it is currently too expensive and error prone to generate highly detailed trace links. We previously developed an approach to semi-automatically generate trace links and analyzed cost-benefit trade-offs in this context. We consider it as imperative to include value considerations into planning the generation of trace dependencies. This paper discusses three key trade-off decisions for planning the trace generation process: (a) the level of detail of traces among artifacts; (b) the value of the artifacts that are traced; and (c) the points in time of trace generation (early vs. late). We present cost-benefit considerations, empirical data, and argue for a pragmatic value-based planning approach.

A recent survey with project managers of highly distributed projects at Siemens Program and Systems Engineering (PSE) brought up as main challenges: more severe communication hurdles compared to collocated teams and higher effort to communicate requirements in the team. In this paper, we address requirements tracing options to facilitate risk management with requirements clarification, collaboration, and knowledge management. We propose concepts for enhanced requirements tracing that include the rationale for requirements, related decisions, their history; and stakeholder value propositions. We sketch a cost-benefit model that helps the project manager to understand what tracing approach is worthwhile to address requirements risk in a project. The outcome lays the basis for planning empirical studies at PSE.

... M. Ramzan, M. Arfan Jaffar M. Amjad Iqbal, Sajid Anwar, Arshad A. Shahid National University of Computer and Emerging ... AK Brohi Road, H11/4 Islamabad, Pakistan, {muhammad.ramzan, arfan.jaffar}@nu.edu.pk, {amjad.iqbal, sajid.anwar, arshad.a.shahid}@nu.edu.pk ...

As a relatively young discipline within software engineering, value-based software engineering does not yet have an established curriculum. The area draws on models and techniques in so many other disciplines that it is likely to be some time before a single individual is ready to prepare a course or a textbook. Several of the EDSER-4 participants expressed interest and enthusiasm for sharing the effort of developing curriculum and course materials. Inspired by the success of open source software development, especially the distributed collaboration, the free public access to the results, and the lack of administrative overhead; we decided to try to establish a similar community for curriculum development. This report describes progress to date, with emphasis on the community standards for cooperation and sharing.

Product value is based on which requirements are included in a specific release of a software product. This chapter provides an overview of the value concept and presents an empirical study conducted as an industrial survey. The objective of the survey was to quantify the importance of different decision-making criteria when deciding whether to include a requirement in a project or release. The results reported from the survey are based on responses from two companies. It was discovered that there were similarities in responses at a company level, although major differences existed between individual respondents to the survey. The most important criteria were found to be those related to specific customers or markets and criteria, such as development cost-benefit, delivery date and resources. The least important criteria were those related to development and maintenance. The results also indicate that a better balance between the most important and least important criteria ought to be achieved in the future.