By Topic

Analyzing differences in risk perceptions between developers and acquirers in OTS-based custom software projects using stakeholder analysis

Sign In

Cookies must be enabled to login.After enabling cookies , please use refresh or reload or ctrl+f5 on the browser for the login options.

Formats Non-Member Member
$31 $13
Learn how you can qualify for the best price for this item!
Become an IEEE Member or Subscribe to
IEEE Xplore for exclusive pricing!
close button

puzzle piece

IEEE membership options for an individual and IEEE Xplore subscriptions for an organization offer the most affordable access to essential journal articles, conference papers, standards, eBooks, and eLearning courses.

Learn more about:

IEEE membership

IEEE Xplore subscriptions

4 Author(s)
Kusumo, D.S. ; Nat. ICT Australia, Australia ; Staples, M. ; Liming Zhu ; Jeffery, R.

Project stakeholders can have different perceptions of risks and how they should be mitigated, but these differences are not always well understood and managed. This general issue occurs in Off-the-shelf (OTS)-based custom software development projects, which use and integrate OTS software in the development of specialized software for an individual customer. We report on a study of risk perceptions for developers and acquirers in OTS-based custom software development projects. The study used an online questionnaire-based survey. We compared stakeholders' perceptions about their level of control over and exposure to 11 shared risks in OTS-based software, in 35 OTS-based software developments and 34 OTS-based software acquisitions of Indonesian background. We found that both stakeholders can best control, and are most impacted by, risks about requirements negotiation. In general stakeholders agree who can best control risks (usually the developer), but there were different perceptions about who is most impacted by risks (the developer reported either themselves or both stakeholders; while usually the acquirer reported both stakeholders). In addition, both stakeholders agree that the acquirer is most impacted by the risk of reduced control of future evolution of the system. We also found disagreement about who is most impacted by the risk of lack of support (usually each stakeholder reported themselves). This paper makes two main contributions. First, the paper presents a method based on stakeholder analysis to compare perceptions of the respondents about which stakeholder is affected by and can control risks. Second, knowing stakeholder agreement on which stakeholder has high risk control should be helpful to rationalize responsibility for risks.

Published in:

Empirical Software Engineering and Measurement (ESEM), 2012 ACM-IEEE International Symposium on

Date of Conference:

20-21 Sept. 2012