Software Product Family Evaluation

Linden, Frank van der; Bosch, Jan; Kamsties, Erik; Känsälä, Kari; Krzanik, Lech; Obbink, J. Henk

doi:10.1007/978-3-540-24667-1_27

Cited by 30 publications

(45 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Lower value means the company does not resemble characteristics of SPL. Following are the four main dimensions of BAPO model [12], [23]: 1) Business: How to make profit from products and services. 2) Architecture: Technical means to build the software.…”

Section: Discussionmentioning

confidence: 99%

“…To increase usability among features, Boyun should separate roles and responsibilities among teams in two steps. First, the company should establish roles that focus on the reusable assets by using SPLE approach [12]. As a suggestion, they can apply the SPL's domain engineering concept to develop these reusable core assets.…”

Section: International Journal Of Computermentioning

confidence: 99%

“…According to these reports, for product line adoption success, a strong management commitment is needed as well as a long term vision, which is generally lacked in small companies. It is normally believed that small companies cannot afford the start-up cost, burdensome process, strict organizational rules and the tedious planning; a core prerequisite for adopting Software product lines [12]. Furthermore, small companies lack the same resources and time to plan as a large company with regard to adopting new platforms or strategies.…”

Section: Introductionmentioning

confidence: 99%

“…Van der Linden et al [12] propose four-dimensional software product line evaluation framework based on the BAPO concept of operations that incorporates the business, architecture, process, and organizational aspects. This framework provides a preliminary foundation for a systematic and comprehensive strategy for a process maturity evaluation of software product line engineering.…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Analysis of a Small Company for Software Product Line Adoption — An Industrial Case Study

Nazar¹,

Rakotomahefa²

2016

IJCTE

View full text Add to dashboard Cite

Abstract-While there are many success stories of adoption of software product line (SPL) practices in large companies, there is a need to investigate how well the product line strategy works for small organizations and what issues and challenges they could possibly face. This case study provides a comprehensive detailed analysis of a small company's tendency of adopting Software product line. It also reveals how new trends in software engineering, for example, agile methods interact with product line strategy. We used an ethnographic approach of collecting data by spending some time at a company in China and gathering information through interviews, documents, and studying organizational processes. The collected data was analysed using grounded theory. The findings were evaluated with regard to business, architecture, process and organizational concerns of a company, generally known as BAPO model. In the end, the challenges faced by the company were addressed and potential improvements were suggested to reap the benefits of software product line. The results show that the company is unknowingly using some SPL practices and has a potential to adopt SPL practices fully.Index Terms-Agile development processes, BAPO model, empirical study, grounded theory, software product lines. I. INTRODUCTIONSoftware Product Line Engineering (SPLE) is an idea of building and managing a family of products with shared commonalities, targeting a certain market area and is developed from a common set of core resources. SPLE is therefore beneficial for a company developing a software suite with common or somewhat similar features between the products. To manage this product line, the commonalities are first identified and modularized. This commonality has certain variational points separating different products. There exist possibilities to derive new products from the platform by creating new variabilities. Thus, decreasing production cost, time to market, increased product quality, and exploring new market ventures could be achieved by reusing such variations and commonalities in a proper manner [1]. Usually, managing commonality and variability between different products are conducted using systematic variability management techniques [2]. Such techniques help achieve a number of benefits including defining the sources of variability and the different variants, tracing variability from the model to the code and vice versa, and communicating variability to the different stakeholders [3]. Manuscript received October 14, 2014; revised May 12, 2015. N. Nazar is with School of Software, Dalian University of Technology, China (e-mail: najamnazar@126.com).T. M. J. Rakotomahefa is with the School of Civil Engineering, Dalian University of Technology, China (e-mail: ymamesoj@outlook.com).The SPLE is proactive in nature and often structured to facilitate two separate roles: domain engineering and application engineering [4]. Domain engineering concerns the commonalities in order to build and manage reusable or core assets such as requirement...

show abstract

Section: Discussionmentioning

confidence: 99%

Section: International Journal Of Computermentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Analysis of a Small Company for Software Product Line Adoption — An Industrial Case Study

Nazar¹,

Rakotomahefa²

2016

IJCTE

View full text Add to dashboard Cite

show abstract

“…According to [5] a platform infrastructure consists of the operating system and commodity components, with database management and GUI being two examples. In case 1 and 2 this concern is present, as application developers often have to make implicit assumptions about the available hardware and software services available to be able to efficiently build applications on top of the platform.…”

Section: Infrastructurementioning

confidence: 99%

Characterising Software Platforms from an Architectural Perspective

Eklund

Ljungblad

2013

Software Architecture

View full text Add to dashboard Cite

Abstract. With demands of speed in software development it is of interest to build on available software platforms that incorporate the necessary non-competitive functionalities and focus the development effort on adding features to a competitive product. This paper proposes that we move from an API-oriented focus and instead suggest four architectural concerns for describing software platforms as more relevant.

show abstract

Introducing agile customer‐centered development in a legacy software product line

Bosch

Bosch‐Sijtsema

2011

Softw Pract Exp

Self Cite

View full text Add to dashboard Cite

The ability to rapidly respond to customer interest and to effectively prioritize development effort has been a long‐standing challenge for mass‐market software intensive products. This problem is exacerbated in the context of software product lines as functionality may easily fall over software asset and organizational boundaries with consequent losses in efficiency and nimbleness. Some companies facing these problems in their product line respond with a new development process. In this paper we discuss the developments within a single case study, Intuit's Quickbooks product line that combined agile software development, design thinking and self‐organizing teams in a successful approach, which provided a significant improvement in terms of responsiveness and accuracy of building customer value. Copyright © 2011 John Wiley & Sons, Ltd.

show abstract

Software Product Family Evaluation

Cited by 30 publications

References 6 publications

Analysis of a Small Company for Software Product Line Adoption — An Industrial Case Study

Analysis of a Small Company for Software Product Line Adoption — An Industrial Case Study

Characterising Software Platforms from an Architectural Perspective

Introducing agile customer‐centered development in a legacy software product line

Contact Info

Product

Resources

About