One of the success factors of Business process outsourcing (BPO) is a comprehensive and in-depth understanding of the business processes outsourced. However, such business processes are often undocumented, and discovering them is difficult and time-consuming for BPO service providers. Previously, we introduced an approach for business process discovery that uses swim lanes to recognize that different parts of the process may be performed by different parts of an organization. It generates the business process from an event log and user information extracted from an existing system. Herein, this paper examines whether the approach aids engineers and consultants in the providers who need to investigate business processes of organizations (i.e., their customers on which they do not have sufficient knowledge) discovering the implicit operational knowledge of the target business processes (e.g., undocumented local rules). To do so, we survey an industrial workflow system from which we collected data about 2,000 events and 269 users for a two-year period of the system's operation. We conducted a study on the case by means of document evaluation and expert interviews. The study suggested that the output of the approach is a valuable process visualization for identifying knowledge that is not documented nor recognized by even experts in organizations.

Microtask programming enables software engineers such as freelancers and part-time employees to contribute to software projects even when they can not spend much time on them. It decomposes software design into small, self-contained specifications. The decomposed specifications enable them to complete implementation and review task in a short time. In this paper, we empirically investigate the time required for software engineers to complete microtasks in an industrial setting and explore their perceptions of microtask programming by investigating two industrial projects using it. The projects were carried out in different companies and differed in the employment of the engineers. One contracted 9 freelancers, and the other asked for 8 part-time contributions from employees at work on other projects. We conducted a survey and a focus group with the engineers. Based on the development data of the case studies, we found that almost all microtasks were completed in less than four pomodoro repetitions, namely about two hours in the pomodoro technique. These data shows that engineers who cannot work full-time on a project can undertake microtasks if they can spare one-third of their work day. We also examine how engineers who are employees experience microtask programming similarly and differently from freelancers.

COVID-19 has transformed face-to-face software development into distributed development (e. g., remote work). While the company authors belong to studies microtask programming, an open source software (OSS) -like development, as a solution to employ distributed development, a prior study reports a challenge: online communication in microtask programming takes longer; such lengthy communication discourages developers and affects their completion of assigned tasks. OSS, however, is successfully developed using online communication, such as issues. Hence, we have a question: how does OSS address the online communication challenge? In this experience report, we answer this question based on an empirical study on OSS communication. We found that (1) OSS prefers burst communication similar to face-to-face development, and (2) attracting developers’ attention may be a possible solution. Based on the findings, we discuss the direction of future studies to achieve better online communication in microtask programming in the company. The main contributions of this report are (1) to empirically reveal the actual communication times in OSS and (2) to show how an empirical approach helps industrial collaborators.

Microtask programming [4] is a solution to promote distributed development in industry. The key idea of microtask programming is to reduce face-to-face communication across developers by splitting the development task of software into independent microtasks. Such microtasks can be completed by crowd workers who work remotely and at their preferable time such as early morning. Dedicated developers who have the responsibility for the progress of development split the task into microtasks, and distribute them to crowd workers. Hence, microtask programming has these two actors. Our research team reported that microtask programming has potential benefits such as the fluidity of project assignments in industrial companies [4]. However, we suppose it still has challenges. In addition, it is still unclear what are future research direction to support both actors in microtask programming, though our research team has conducted three studies for microtask programming so far [2--4].

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.

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.

In agile software development projects, software engineers prioritize implementation over documentation to eliminate needless documentation. Is the cost of missing documentation greater than the cost of producing unnecessary or unused documentation? Even without these documents, software engineers maintain other software artifacts, such as tickets in an issue tracking system (ITS) or source code committed to a version control system (VCS). Do these artifacts contain the necessary knowledge? In this paper, we examine undocumented knowledge in an agile software development project at NTT. For our study, we collected 159 commit logs in a VCS and 102 tickets in the ITS from the three-month period of the project. We propose a ticket-commit network chart (TCC) that visually represents time-series commit activities along with filed issue tickets. We also implement a tool to generate the TCC using both commit log and ticket data. Our study revealed that in 16% of all commits, software engineers committed source code to the VCS without a corresponding issue ticket in the ITS. Had these commits been based on individual issue tickets, these "unissued" tickets would have accounted for 20% of all tickets. Software users and requirements engineers also evaluated the contents of these commits and found that 42% of the "unissued" tickets were required for software operation and 23% of those were required for requirements modification.

In this paper, we propose a Requirements Engineering Ontology (REO). We reviewed three well-known Bodies of Knowledge (BoKs) on requirements engineering: BABOK, SWEBOK, and REBOK. Based on the review, we compiled the REO as an organized set of knowledge of the requirements engineering. With the REO, we propose "knowledge spectrum analysis", a technique to analyze and visualize the distribution of knowledge in technical documents. As a practical application of the REO, we conduct two case studies on the knowledge spectrum analysis. First, we evaluate three BoKs (i.e., BABOK, SWEBOK, and BABOK) using the REO. Second, we utilize the REO to survey a set of technical documents for corporate-wide methodology for business modeling at NTT DATA. Based on the results of the case studies, we demonstrate the effectiveness of the REO.

We introduce a whole view of current status of requirements engineering based on REBOK (Requirements Engineering Body Of Knowledge) and its practical use with case studies.