Search

A critical issue in software development projects in IT service companies is finding the right people at the right time. By enabling assignments of tasks to people to be more fluid, the use of crowdsourcing approaches within a company offers a potential solution to this challenge. Inside a company, as multiple system development projects are ongoing separately, developers with slack time on one project might use this time to contribute to other projects. In this paper, we report on a case study of the application of crowdsourcing within an industrial web application system development project in a large telecommunications company. Developers worked with system specifications which were organized into a set of microtasks, offering a set of short and self-contained descriptions. When crowd workers in other projects had slack time, they fetched and completed microtasks. Our results offer initial evidence for the potential value of microtask programming in increasing the fluidity of team assignments within a company. Crowd contributors to the project were able to onboard and contribute to a new project in less than 2 hours. After onboarding, the crowd workers were together able to successfully implement a small program which contained only a small number of defects. Interview and survey data gathered from project participants revealed that crowd workers reported that they perceived onboarding costs to be reduced and did not experience issues with the reduced face to face communication, but experienced challenges with motivation.

Sourcing the right IT engineers is critical for project success. In recent years, two sourcing strategies have been grabbing attention: crowdsourcing and inner-sourcing. Each has their own good points and bad points. Crowdsourcing allows organizations to recruit IT engineers from outside on demand. However, organizations working on closed-source code with confidential information might be worried about security concerns (e.g., information leak). The other strategy, inner-sourcing, can make any IT engineer in an organization become a member of all projects by adopting open source software development practices. This improves the mobility of IT engineers between projects inside the organization. However, there is a limit to the types of IT engineers that one organization can have. In this report, we propose a hybrid sourcing approach. It integrates the two sourcing strategies to develop software - crowdsourcing and inner-sourcing. This approach distributes the development tasks to either software crowdsourcing or inner-sourcing according to task type. As a case study, we adopt hybrid sourcing approach for an industrial project. The project developed a web application system for a bus company. We evaluate the effectiveness and future issues of hybrid sourcing.

Changes to software requirements occur throughout the software life cycle. Requirements engineers who maintain software systems in regulated environments must identify the affected artifacts when requirements change. This identification is critical to: (a) ensure continued compliance with regulations, and (b) accurately estimate budget requests. Previously, we introduced Requirements Evolution Charts (REC) to provide a visual representation of requirements evolution history. An REC is generated from the issue tickets in which requirements engineers record changes to requirements artifacts. Herein, we examine whether a REC helps software engineers conduct an impact analysis. Thirty experienced NTT requirements engineers with no prior domain knowledge identified the impact of seven requirements changes in a large-scale system governed by Japanese laws and regulations. They were divided into two groups of fifteen engineers. The REC group employed the REC to aid their efforts; the Non-REC group conducted their impact analysis without the REC. Participants in both groups identified which of the 139 artifacts were affected based on a history of 108 issue tickets. Our study reveals that engineers in the REC group identified the affected artifacts more accurately and quickly than the Non-REC group, suggesting that the REC is a valuable tool for examining the impact of requirements evolution.

Requirements evolve throughout the software life-cycle. When requirements change, requirements engineers must determine what software artifacts could be affected. The history of and rationale for requirements evolution provides engineers some information about artifact dependencies for impact analysis. In this paper, we discuss a case study of requirements evolution for a large-scale system governed by Japanese laws and regulations. We track requirements evolution using issue tickets created in response to stakeholder requests. We provide rules to identify requirements evolution events (e.g. refine, decompose, and replace) from combinations of operations (e.g. add, change, and delete) specified in the issue tickets. We propose a Requirements Evolution Chart (REC) to visually represent requirements evolution as a series of events over time, and implement tool support to generate a REC from a series of issue tickets using our rules to identify requirements evolution events. We found that the REC supports impact analysis and compliance efforts.