8 IEEE SOFTWARE | PUBLISHED BY THE IEEE COMPUTER SOCIETY 0 7 4 0 - 7 4 5 9 / 1 8 / $ 3 3 . 0 0 © 2 0 1 8 I E E E

Editor: Jeffrey C. CarverUniversity of Alabamacarver@cs.ua.edu

PRACTITIONERS’ DIGEST

Empirical Software Engineering, Predictive Models, and Product LinesJeffrey C. Carver, Eduardo Santana de Almeida, Rafael Capilla, Leandro Minku, Marco Torchiano, and Alejandro Valdezate

THIS ISSUE’S COLUMN reports on pa-pers presented at the 11th Inter national Symposium on Empirical Software En-gineering and Measurement (ESEM 17), 13th International Conference on Predictive Models and Data Analytics in Software Engineering (PROMISE 17), and 21st Interna-tional Systems and Software Product Line Conference (SPLC 17). Feedback and suggestions are welcome. In addi-tion, if you try or adopt any of the prac-tices included in the column, please send Jeffrey Carver and the paper au-thors a note about your experiences.

Tools and Delivery Speed“Improving the Delivery Cycle: A Multiple-Case Study of the Tool-chains in Finnish Software Inten-sive Enterprises,” by Simo Mäkinen and his colleagues, investigates how different categories of tools af-fected the speed of software delivery cycles in Finnish companies.1 On the basis of qualitative semistructured interviews of developers from 18 organizations working in different domains (for example, consulting,

web services, telecommunications, and mobile games), the authors iden-tified 15 categories of tools across the software lifecycle:

• requirements (elicitation, backlog management, and bug tracking),

• development (version control, build, continuous integration, and artifact repository),

• operations (provisioning/ environments and deployment),

• testing (unit, UI, and acceptance),

• quality (performance and code review), and

• feedback (communication/feedback).

These tools ranged from commodity tools used in most organizations, to modestly used tools that were miss-ing from some organizations, to un-common tools that were used in only a few organizations.

The reasons for gaps in the tool-chain in some organizations included alternate enactment of activities (for

example, manual or outsourced), limited relevance in the domain (for example, lack of UIs in embed-ded systems), lack of knowledge, and company culture. A key finding was that companies aiming to de-ploy software more rapidly should strive for fewer manual steps. You can access this paper at bit.ly/PD _2018_May_1.

Release, Deployment, and Energy Use“Estimating Energy Impact of Soft-ware Releases and Deployment Strategies: The KPMG Case Study,” by Roberto Verdecchia and his col-leagues, reports on a study of indus-trial data to understand how various factors impacted a software applica-tion’s energy use.2 The authors used data from KPMG to study the impact of three factors:

• The release. They studied two functionally similar releases.

• The deployment strategy. They studied whether the database and web application were

PRACTITIONERS’ DIGEST

MAY/JUNE 2018 | IEEE SOFTWARE 9

deployed on the same server or different servers.

• The use case scenario. The two scenarios involved users com-pleting a common questionnaire or generating a report based on the questionnaire data.

The authors have provided an online replication package for interested readers (see bit.ly/PD_2018_May_2a).

All three factors significantly af-fected the underlying application’s energy consumption. But there was no consistent pattern, owing to the significant interactions among the factors. These findings indicate that although the release strategy, deploy-ment strategy, and chosen use case are all important, there’s no absolute best approach for all circumstances. The key finding is that for each application and use case, the software provid-ers should conduct a similar analysis to determine the best strategy. You can access this paper at bit.ly/PD _2018_May_2.

Classifying Developers“Characterizing Software Develop-ers by Perceptions of Productivity,” by André Meyer and his colleagues, discusses a survey of 413 Microsoft developers.3 The authors aimed to characterize the developers by their perception of what it means to be productive.

On the basis of the survey (avail-able at bit.ly/PD_2018_May_3a), Meyer and his colleagues identified six types of developers:

• The social developer feels pro-ductive when helping coworkers or collaborating. He or she likes to arrive early or work late and focus on a single task.

• The lone developer avoids disruptions and noise and feels

productive when working on tasks (solving problems, fixing bugs, or coding features) quietly, with little or no interruption or social interaction.

• The focused developer feels pro-ductive when working efficiently on one task at a time.

• The balanced developer feels productive when working on rel-evant, clear, and familiar tasks and is less affected by disrup-tions. He or she likes to arrive early or stay late.

• The leading developer feels productive when participating in meetings and responding to emails.

• The goal-oriented developer feels productive when complet-ing or making progress on a task. He or she is more open to meetings and emails in case they help achieve the goal.

Knowledge of these productiv-ity types can be useful for orga-nizations that want to create the most productive work environments for different types of developers. You can access this paper at bit.ly /PD_2018_May_3.

Estimating Issue Resolution Time“Multi-objective Search-Based Ap-proach to Estimate Issue Resolution Time,” by Wisam Al-Zubaidi and his colleagues, presents an approach to estimate the time required to re-solve an issue.4 These estimates can be used to inform

• users about when a new func-tionality will become available,

• bug reporters about when a fix will be ready, or

• project managers about when new releases will be finished.

The authors’ approach uses data from previously closed issues to build tree-like models to estimate issue resolution time. It seeks to max-imize accuracy and minimize tree size. The smaller trees are human- readable, thereby enabling software engineers to understand how the es-timations are made.

Results from an evaluation of 8,260 issues from five open source projects show that this approach out-performed other common estimation models (linear regression, case-based reasoning, and random forests). In particular, this approach obtained a mean absolute error that was 24 to 40 percent smaller than that obtained by random forests (the best among those three other estimation mod-els). Furthermore, this approach’s estimates were 50 to 60 percent more accurate than random guessing, on average. You can access this paper at bit.ly/PD_2018_May_4.

Product Line Testing“Product Line Engineering on the Right Side of the ‘V,’” by Susan Gregg and her colleagues, offers a practical testing approach for products devel-oped using feature-based product line engineering (PLE).5 This approach reduces the cost and effort of testing activities by increasing testing accu-racy and decreasing testing activity. It increases accuracy by using the PLE factory to configure test cases to ex-actly match the product assets to be tested. It decreases testing activity by testing inside the PLE factory wher-ever possible and appropriate.

The authors present five key prin-ciples for deciding whether to test something once, inside the factory, or once per product, outside the factory:

• Perform standalone testing inside.

PRACTITIONERS’ DIGEST

10 IEEE SOFTWARE | W W W.COMPUTER.ORG/SOFT WARE | @IEEESOFT WARE

• Assess defects’ consequences.• Assess past pedigree.• Assess context sensitivity.• Exploit commonality.

Because testing occurs while the product line is continually evolving, the approach uses branching poli-cies to define stable spaces for test-ing operations. It draws from the experience of the AEGIS Weapon System product line (a highly inte-grated naval-combat ship system). You can access this paper at bit.ly /PD_2018_May_5.

Agile Product Lines“Agile Tames Product Line Variabil-ity: An Agile Development Method for Multiple Product Lines of Automotive Software Systems,” by

Kengo Hayashi and his colleagues, describes stringent requirements’ role in the diversity of automotive software products when agility is necessary to deliver software.6 The authors devised APLE, an extended agile PLE method. APLE divides the application-engineering phase into a sequence of iterative processes and performs minor iteration loops in a project and major iteration loops across projects. With APLE, devel-opers can manage the diversity of multiple product lines by iteratively reusing assets, which decreases the cost and complexity of maintain-ing those lines. Developers can reuse variation points several times while engineering multiple applications.

The implementation of APLE in DENSO’s automotive division over

10 months and 22 two-week sprints decreased the complexity of handling multiple product lines. The resulting productivity volatility was narrowed down to lower than 20 percent, and mostly lower than 10 percent, indicating a stable development ap-proach. You can access this paper at bit.ly/PD_2018_May_6.

Microservices and Product Lines“Using Microservices and Software Product Line Engineering to Sup-port Reuse of Evolving Multi-tenant SaaS,” by Leonardo Tizzei and his colleagues, reports on the integrated use of a micro service architecture and PLE activities to develop multi tenant software as a service (SaaS).7 (Micro-services are small, decentralized,

AB

OU

T T

HE

AU

TH

OR

S

JEFFREY C. CARVER is a professor in

the University of Alabama’s Department of

Computer Science. Contact him at carver@

cs.ua.edu.

LEANDRO MINKU is a lecturer (assistant

professor) in the University of Leicester’s

Department of Informatics. Contact him at

leandro.minku@leicester.ac.uk.

EDUARDO SANTANA DE ALMEIDA is an

associate professor of software engineering at

the Federal University of Bahia. Contact him at

esa@dcc.ufba.br.

MARCO TORCHIANO is an associate professor

in Politecnico di Torino’s Department of Control

and Computer Engineering. Contact him at

marco.torchiano@polito.it.

RAFAEL CAPILLA is an associate professor

of computer science at Rey Juan Carlos

University of Madrid. Contact him at rafael

.capilla@urjc.es.

ALEJANDRO VALDEZATE is a software

engineer at Ibermática and a PhD candidate at

Rey Juan Carlos University of Madrid. Contact

him at alejandro@valdezate.net.

PRACTITIONERS’ DIGEST

MAY/JUNE 2018 | IEEE SOFTWARE 11

autonomous services that work to-gether.) The authors used the Weather InSights Environment (WISE) to as-sess the extent to which their ap-proach supports software reuse during the evolution of multi tenant SaaS.

The evaluation of the evolution of multitenant SaaS refactorings of 13 reviews over 384 days showed that the tenants reused an average of 62 percent of the LOC, reducing main-tenance effort and increasing scalabil-ity Also, nonreused LOC increased by 200 percent in cases in which one tenant consumed features that other tenants hadn’t consumed. Overall, the study shows this approach’s suc-cess when existing functionality can be decomposed into small, indepen-dent services that are easier to main-tain. You can access this paper at bit .ly/PD_2018_May_7.

References 1. S. Mäkinen et al., “Improving the

Delivery Cycle: A Multiple-Case

Study of the Toolchains in Finnish

Software Intensive Enterprises,” In-

formation and Software Technology,

Dec. 2016, pp. 175–194.

2. R. Verdecchia et al., “Estimating En-

ergy Impact of Software Releases and

Deployment Strategies: The KPMG

Case Study,” Proc. 2017 ACM/IEEE

Int’l Symp. Empirical Software Eng.

and Measurement (ESEM 17), 2017,

pp. 257–266.

3. A.N. Meyer, T. Zimmermann, and

R. Fritz, “Characterizing Software

Developers by Perceptions of Produc-

tivity,” Proc. 2017 ACM/IEEE Int’l

Symp. Empirical Software Eng. and

Measurement (ESEM 17), 2017,

pp. 105–110.

4. W.H.A. Al-Zubaidi et al., “Multi-

objective Search-Based Approach to

Estimate Issue Resolution Time,”

Proc. 13th Int’l Conf. Predictive Mod-

els and Data Analytics in Software

Eng. (PROMISE 17), 2017, pp. 53–62.

5. S.P. Gregg, D.M. Albert, and

P. Clements, “Product Line Engineering

on the Right Side of the ‘V,’” Proc.

21st Int’l Systems and Software

Product Line Conf. (SPLC 17),

vol. A, 2017, pp. 165–174.

6. K. Hayashi, M. Aoyama, and K.

Kobata, “Agile Tames Product Line

Variability: An Agile Development

Method for Multiple Product Lines

of Automotive Software Systems,”

Proc. 21st Int’l Systems and Software

Product Line Conf. (SPLC 17), vol. A,

2017, pp. 180–189.

7. L. Tizzei et al., “Using Microservices

and Software Product Line Engineer-

ing to Support Reuse of Evolving

Multi-tenant SaaS,” Proc. 21st Int’l

Systems and Software Product Line

Conf. (SPLC 17), vol. A, 2017, pp.

205–214.

Read your subscriptions through the myCS publications portal at

http://mycs.computer.org

JULY/AUGUST 2016

www.computer.org/cloudc

omputing

MANUFACTURING

& THE CLOUD

Mobile Service Computing 32

Securing Cryptographic Keys 42

MARCH/APRIL 2016

www.computer.org/cloudcomputing

Security and Dependability of Cloud-Assisted Internet of ThingsLive Migration 12Capability-Oriented

Methodology 58

computer.org/cloudcomputing

Subscribe today! IEEE Computer Society’s newest magazine

tackles the emerging technology of cloud computing.

MAY/JUNE 2016www.computer.org/cloudcomputing

MAY/JUNE 2016www.computer.org/cloudcomputing

AUTONOMICCLOUDSSoftware-De� ned Networking 8Datacenter Threats 64