What are the roles of software product managers? An empirical investigation

Software product management covers both technical and business activities to management of products like roadmaps, strategic, tactical, and release planning. In practice, one product manager is seldom responsible for all these activities but several persons share the responsibilities. Therefore, it is important to understand the boundaries of product managers’ work in managing software products, as well as the impact a product manager has on the company business. The purpose of the study is to clarify what roles of software product managers exist and understand how these roles are interrelated with each other and the whole structure and business of an organization. The study is designed as an interpretative qualitative study using grounded theory as the research method. Based on the gathered data we developed a framework that reveals the role of a product manager in the organization and shows how this role can evolve by extending the level of responsibilities. Using the framework, we identified four stereotypical roles of product managers in the studied organizations: experts, strategists, leaders, and problem solvers. The presented framework shows that product managers’ roles are not limited to the conception of the “mini-CEO.” The results allow product managers and top management to collaborate effectively by assigning responsibilities and managing expectations by having a common tool for understanding the role of product managers in the organization.     

Software engineering beyond the project – Sustaining software ecosystems

ContextThe main part of software engineering methods, tools and technologies has developed around projects as the central organisational form of software development. A project organisation depends on clear bounds regarding scope, participants, development effort and lead-time. What happens when these conditions are not given? The article claims that this is the case for software product specific ecosystems. As software is increasingly developed, adopted and deployed in the form of customisable and configurable products, software engineering as a discipline needs to take on the challenge to support software ecosystems.ObjectiveThe article provides a holistic understanding of the observed and reported practices as a starting point to device specific support for the development in software ecosystems.MethodA qualitative interview study was designed based on previous long-term ethnographical inspired research.ResultsThe analysis results in a set of common features of product development and evolution despite differences in size, kind of software and business models. Design is distributed and needs to be coordinated across heterogeneous design constituencies that, together with the software, build a product specific socio-technical ecosystem. The technical design has to support the deference of part of the development not only to 3rd-party developers but also to local designers tailoring the software in the use organisation. The technical interfaces that separate the work of different design constituencies are contested and need to be maintained permanently. Development takes place as cycles within cycles – overlaying development cycles with different rhythms to accommodate different evolution drivers.ConclusionThe reported practices challenge some of the very core assumptions of traditional software engineering, but makes perfect sense, considering that the frame of reference for product development is not a project but continuous innovation across the respective ecosystem. The article provides a number of concrete points for further research.     

用PSP塑造合格的软件工程师

本文首先简要介绍了PSP的原理,阐述了如何使学生理解从个体软件开发过程到软件产品工程过程,培养学生从开发简单小程序的实践转向开发大规模软件。然后结合实际的教学环境对教学策略加以详细的说明,并对收集到的学生数据进行总结和分析。     

Software product roadmapping in a volatile business environment

Product roadmapping enhances the product development process by enabling early information and long-term decision making about the products in order to deliver the right products to the right markets at the right time. However, relatively little scientific knowledge is available on the application and usefulness of product roadmapping in software product development context. This study develops a framework for software product roadmapping, which is then used to study the critical aspects of the product roadmapping process. The collection of empirical evidence includes both quantitative and qualitative data which sheds further insight into the complexities involved in product roadmapping. Results revealed that organizations view the product roadmap mainly as a tool for strategic decision making as it aims at showing the future directions of the company's products. However, only a few companies appear to have an explicit approach for handling the mechanisms for creating and maintaining such a roadmap. Finally, it is suggested that the strategic importance of product roadmapping is likely to increase in the future and, as a conclusion, a new type of agility is required in order to survive in the turbulent and competitive software business environment.     

浅谈软件质量度量和软件产品评价

软件质量度量和软件产品评价系列标准是国际标准化组织ISO／IEC JTC1近年来在软件工程标准方面的研究重点之一,对于通过量化手段进行软件产品的度量和评价,规范软件产品的质量管理,这两个系列标准提供了一条可以参考的实施途径。本文在多年跟踪研究国际上软件工程标准和制定软件工程国家标准的基础上,对ISO／IEC JTC1近年推出的ISO／IEC 9126和ISO／IEC 14598系列,以及正在研制的ISO／IEC 25000系列标准进行综合介绍。     

The agile requirements refinery: Applying SCRUM principles to software product management

Context

Although agile software development methods such as SCRUM and DSDM are gaining popularity, the consequences of applying agile principles to software product management have received little attention until now.

Objective

In this paper, this gap is filled by the introduction of a method for the application of SCRUM principles to software product management.

Method

A case study research approach is employed to describe and evaluate this method.

Results

This has resulted in the ‘agile requirements refinery’, an extension to the SCRUM process that enables product managers to cope with complex requirements in an agile development environment. A case study is presented to illustrate how agile methods can be applied to software product management.

Conclusions

The experiences of the case study company are provided as a set of lessons learned that will help others to apply agile principles to their software product management process.     

Domain modeling as a basis for building a meshing tool software product line

Meshing tools are highly complex software for generating and managing geometrical discretizations. Due to their complexity, they have generally been developed by end users – physicists, forest engineers, mechanical engineers – with ad hoc methodologies and not by applying well established software engineering practices. Different meshing tools have been developed over the years, making them a good application domain for Software Product Lines (SPLs). This paper proposes building a domain model that captures the different domain characteristics such as features, goals, scenarios and a lexicon, and the relationships among them. The model is partly specified using a formal language. The domain model captures product commonalities and variabilities as well as the particular characteristics of different SPL products. The paper presents a rigorous process for building the domain model, where specific roles, activities and artifacts are identified. This process also clearly establishes consistency and completeness conditions. The usefulness of the model and the process are validated by using them to generate a software product line of Tree Stem Deformation (TSD) meshing tools. We also present Meshing Tool Generator, a software that follows the SPL approach for generating meshing tools belonging to the TSD SPL. We show how an end user can easily generate three different TSD meshing tools using Meshing Tool Generator.     

From integration to composition: On the impact of software product lines, global development and ecosystems

Three trends accelerate the increase in complexity of large-scale software development, i.e. software product lines, global development and software ecosystems. For the case study companies we studied, these trends caused several problems, which are organized around architecture, process and organization, and the problems are related to the efficiency and effectiveness of software development as these companies used too integration-centric approaches. We present five approaches to software development, organized from integration-centric to composition-oriented and describe the areas of applicability.     

A scoped approach to traceability management

Traceability is the ability to describe and follow the life of a software artifact and a means for modeling the relations between software artifacts in an explicit way. Traceability has been successfully applied in many software engineering communities and has recently been adopted to document the transition among requirements, architecture and implementation. We present an approach to customize traceability to the situation at hand. Instead of automating tracing, or representing all possible traces, we scope the traces to be maintained to the activities stakeholders must carry out. We define core traceability paths, consisting of essential traceability links required to support the activities. We illustrate the approach through two examples: product derivation in software product lines, and release planning in software process management. By using a running software product line example, we explain why the core traceability paths identified are needed when navigating from feature to structural models and from family to product level and backward between models used in software product derivation. A feasibility study in release planning carried out in an industrial setting further illustrates the use of core traceability paths during production and measures the increase in performance of the development processes supported by our approach. These examples show that our approach can be successfully used to support both product and process traceability in a pragmatic yet efficient way.     

SPI success factors within product usability evaluation

This article presents an experience report where we compare 8 years of experience of product related usability testing and evaluation with principles for software process improvement (SPI). In theory the product and the process views are often seen to be complementary, but studies of industry have demonstrated the opposite. Therefore, more empirical studies are needed to understand and improve the present situation. We find areas of close agreement as well as areas where our work illuminates new characteristics. It has been identified that successful SPI is dependent upon being successfully combined with a business orientation. Usability and business orientation also have strong connections although this has not been extensively addressed in SPI publications. Reasons for this could be that usability focuses on product metrics whilst today's SPI mainly focuses on process metrics. Also because today's SPI is dominated by striving towards a standardized, controllable, and predictable software engineering process; whilst successful usability efforts in organisations are more about creating a creative organisational culture advocating a useful product throughout the development and product life cycle. We provide a study and discussion that supports future development when combining usability and product focus with SPI, in particular if these efforts are related to usability process improvement efforts.     

软件产品线度量及应用研究

软件复用是提高软件生产力、软件质量的最有潜力的领域,软件产品线实质上是最高级别的软件复用.软件产品线对当前的软件密集性项目的管理提出了新的挑战,它需要管理者有超越单一产品的战略考虑,需要有组织性的预见、调查、规划和指导.一直以来软件过程管理和改进的重要思路是:在软件产品开发管理实践中应用软件度量技术,即通过分析软件过程和产品的相关属性,从而为管理决策实践提供客观的数据支持.针对软件产品线管理的一些关键目标,提出了一些重要的度量技术思路,分析了相应的度量指标,满足了软件产品线各层次管理角色的不同的信息需求.     

浅谈简繁体信息管理系统设计

汉语有两种书面形式：中国大陆和新加坡使用的简体中文,和台湾、香港等地使用的繁体中文,因此Windows系统也有简繁两种版本。随着两岸三地的进一步交流,软件公司迎来发展机会的同时,也面临简繁体操作系统的挑战,如何做到一套软件源代码,简繁两用,减少开发和代码管理成本,提高代码复用效率呢？     

Comparison of release engineering practices in a large mature company and a startup

Modern release engineering practices provide multiple benefits for software companies, but organizations have struggled when trying to adopt the most advanced practices, such as continuous delivery. It is not known in which contexts the most advanced practices are applicable and what can be achieved by adopting them. In this study, we discuss the effect of the organizational context on adopted release engineering practices and what outcomes are achieved with the practices. We study two organizational contexts: the startup and the large mature company context. The effect of the product context is mitigated by studying two case organizations with similar products, a rare research opportunity. We performed 18 interviews with various roles in the case organizations. The number of production environments, the number of customers, the control over the production environment, the available resources, the organization size and the distribution of the organization affected the release engineering practices and the ability to release frequently. Having less internal verification and more customer verification enabled fast feedback and customer experimentation in the startup context, but increased the number of production defects. However, having more internal verification in the large mature company context surprisingly did not prevent production defects. The organizational context had a large effect on how achievable modern release engineering practices, such as continuous delivery, were. In the startup context, the lack of resources was the main factor hindering the improvement of release engineering practices, while in the large mature company context, the number of stakeholders and products were the main factors.     

A Case Study on Implementing Modularity in Software Development

In today’s business world, firms are facing pressures to reduce costs, enhance productivity, and maintain quality in new product development. Past studies have provided evidence that modularity can enhance performance of new product development. However, real-life cases on how to implement the concept of modularity are limited. This article aims to propose a model for modularity implementation in the context of embedded software development. The model was applied in a software company in Hong Kong. Results from the case company provide evidence that the average reuse rate of software modules increased from 31% to 71% after the implementation, with productivity increasing by 258%, cost reducing by 70%, and quality increasing by 72%. The practical implications are finally discussed.     

How to design practical test cases

Published articles seldom discuss real-world software testing in detail. The author reveals strategic and tactical secrets that his company, Hitachi Software Engineering, has institutionalized. He offers some data for actual testing activities, describes how to achieve similar high-quality standards, and points out the importance of designing and documenting test cases     

Software engineering education: A study on conducting collaborative senior project development

Project and teamwork training is recognized as an important aspect in software engineering (SE) education. Senior projects, which often feature industrial involvement, serve the function of a ‘capstone course’ in SE curricula, by offering comprehensive training in collaborative software development. Given the characteristics of student team projects and the social aspects of software development, instructional issues in such a course must include: how to encourage teamwork, how to formalize and streamline stakeholder participation, and how to monitor students’ work, as well as sustain their desired collaborative effort throughout the development. In this paper, we present an exploratory study which highlights a particular case and introduces the meetings-flow approach. In order to investigate how this approach could contribute to the project's results, we examined its quantitative benefits in relation to the development of the project. We also conducted focus group interviews to discuss the humanistic findings and educational effects pertaining to this approach.     

Software development in startup companies: A systematic mapping study

ContextSoftware startups are newly created companies with no operating history and fast in producing cutting-edge technologies. These companies develop software under highly uncertain conditions, tackling fast-growing markets under severe lack of resources. Therefore, software startups present a unique combination of characteristics which pose several challenges to software development activities.ObjectiveThis study aims to structure and analyze the literature on software development in startup companies, determining thereby the potential for technology transfer and identifying software development work practices reported by practitioners and researchers.MethodWe conducted a systematic mapping study, developing a classification schema, ranking the selected primary studies according their rigor and relevance, and analyzing reported software development work practices in startups.ResultsA total of 43 primary studies were identified and mapped, synthesizing the available evidence on software development in startups. Only 16 studies are entirely dedicated to software development in startups, of which 10 result in a weak contribution (advice and implications (6); lesson learned (3); tool (1)). Nineteen studies focus on managerial and organizational factors. Moreover, only 9 studies exhibit high scientific rigor and relevance. From the reviewed primary studies, 213 software engineering work practices were extracted, categorized and analyzed.ConclusionThis mapping study provides the first systematic exploration of the state-of-art on software startup research. The existing body of knowledge is limited to a few high quality studies. Furthermore, the results indicate that software engineering work practices are chosen opportunistically, adapted and configured to provide value under the constrains imposed by the startup context.     

A comparative study of challenges in integrating Open Source Software and Inner Source Software

Context

Several large software-developing organizations have adopted Open Source Software development (OSSD) practices to develop in-house components that are subsequently integrated into products. This phenomenon is also known as “Inner Source”. While there have been several reports of successful cases of this phenomenon, little is known about the challenges that practitioners face when integrating software that is developed in such a setting.

Objective

The objective of this study was to shed light on challenges related to building products with components that have been developed within an Inner Source development environment.

Method

Following an initial systematic literature review to generate seed category data constructs, we performed an in-depth exploratory case study in an organization that has a significant track record in the implementation of Inner Source. Data was gathered through semi-structured interviews with participants from a range of divisions across the organization. Interviews were transcribed and analyzed using qualitative data analysis techniques.

Results

We have identified a number of challenges and approaches to address them, and compared the findings to challenges related to development with OSS products reported in the literature. We found that many challenges identified in the case study could be mapped to challenges related to integration of OSS.

Conclusion

The results provide important insights into common challenges of developing with OSS and Inner Source and may help organizations to understand how to improve their software development practices by adopting certain OSSD practices. The findings also identify the areas that need further research.     

Investigating Architectural Technical Debt accumulation and refactoring over time: A multiple-case study

ContextA known problem in large software companies is to balance the prioritization of short-term with long-term feature delivery speed. Specifically, Architecture Technical Debt is regarded as sub-optimal architectural solutions taken to deliver fast that might hinder future feature development, which, in turn, would hinder agility.ObjectiveThis paper aims at improving software management by shedding light on the current factors responsible for the accumulation of Architectural Technical Debt and to understand how it evolves over time.MethodWe conducted an exploratory multiple-case embedded case study in 7 sites at 5 large companies. We evaluated the results with additional cross-company interviews and an in-depth, company-specific case study in which we initially evaluate factors and models.ResultsWe compiled a taxonomy of the factors and their influence in the accumulation of Architectural Technical Debt, and we provide two qualitative models of how the debt is accumulated and refactored over time in the studied companies. We also list a set of exploratory propositions on possible refactoring strategies that can be useful as insights for practitioners and as hypotheses for further research.ConclusionSeveral factors cause constant and unavoidable accumulation of Architecture Technical Debt, which leads to development crises. Refactorings are often overlooked in prioritization and they are often triggered by development crises, in a reactive fashion. Some of the factors are manageable, while others are external to the companies. ATD needs to be made visible, in order to postpone the crises according to the strategic goals of the companies. There is a need for practices and automated tools to proactively manage ATD.