We propose PM (Project Management) patterns to prevent schedule delays caused by changes in requirements on empirical studies. Changes or late elicitation of requirements during the design, coding and test processes are one of the most serious risks, which may delay project schedules. However, changes and late elicitation of requirements are usually accepted during development processes. Therefore, the PM methods for preventing schedule delays caused by changes and late elicitation of requirements during development processes are an important area of study. In this study, we examined the actual conditions of various projects which succeeded in preventing schedule delays resulting from changes and late elicitation of requirements during development processes. We were able to extract various typical PM techniques for preventing these schedule delays. The techniques, known as "PM patterns", were also applied to other projects. The patterns were arranged on a two-dimensional framework. We discuss a framework of PM patterns aimed at solving the problems caused by changes in requirements.

Requirements changes sometimes cause a project to fail. A lot of projects now follow incremental development processes so that new requirements and requirements changes can be incorporated as soon as possible. These processes are called integrated requirements processes, which function to integrate requirements processes with other developmental processes. We have quantitatively and qualitatively investigated the requirements processes of a specific project from beginning to end. Our focus is to clarify the types of necessary requirements based on the components contained within a certain portion of the software architecture. Further, each type reveals its typical requirements processes through its own rationale. This case study is a system to manage the orders and services of a restaurant. In this paper, we introduce the case and categorize its requirements processes based on the components of the system and the qualitative characteristics of ISO-9126. We could identify seven categories of the typical requirements process to be managed and/or controlled. Each category reveals its typical requirements processes and their characteristics. The case study is our first step of practical integrated requirements engineering.

To identify problems in a software development process, we have been developing an automated measurement tool called TaskPit, which monitors software development tasks such as programming, testing and documentation based on the execution history of software applications. This paper introduces the system requirements, design and implementation of TaskPit; then, presents two real-world case studies applying TaskPit to actual software development. In the first case study, we applied TaskPit to 12 software developers in a certain software development division. As a result, several concerns (to be improved) have been revealed such as (a) a project leader spent too much time on development tasks while he was supposed to be a manager rather than a developer, (b) several developers rarely used e-mails despite the company's instruction to use e-mail as much as possible to leave communication records during development, and (c) several developers wrote too long e-mails to their customers. In the second case study, we have recorded the planned, actual, and self reported time of development tasks. As a result, we found that (d) there were unplanned tasks in more than half of days, and (e) the declared time became closer day by day to the actual time measured by TaskPit. These findings suggest that TaskPit is useful not only for a project manager who is responsible for process monitoring and improvement but also for a developer who wants to improve by him/herself.

Nowadays, open source software (OSS) systems are adopted by proprietary software projects. To reduce the risk of using problematic OSS systems (e.g., causing system crashes), it is important for proprietary software projects to assess OSS systems in advance. Therefore, OSS quality assessment models are studied to obtain information regarding the quality of OSS systems. Although the OSS quality assessment models are partially validated using a small number of case studies, to the best of our knowledge, there are few studies that empirically report how industrial projects actually use OSS quality assessment models in their own development process. In this study, we empirically evaluate the cost and effectiveness of OSS quality assessment models at Fujitsu Kyushu Network Technologies Limited (Fujitsu QNET). To conduct the empirical study, we collect datasets from (a) 120 OSS projects that Fujitsu QNET's projects actually used and (b) 10 problematic OSS projects that caused major problems in the projects. We find that (1) it takes average and median times of 51 and 49 minutes, respectively, to gather all assessment metrics per OSS project and (2) there is a possibility that we can filter problematic OSS systems by using the threshold derived from a pool of assessment metrics. Fujitsu QNET's developers agree that our results lead to improvements in Fujitsu QNET's OSS assessment process. We believe that our work significantly contributes to the empirical knowledge about applying OSS assessment techniques to industrial projects.

AspectM, an aspect-oriented modeling (AOM) language, provides not only basic modeling constructs but also an extension mechanism called metamodel access protocol (MMAP) that allows a modeler to modify the metamodel. MMAP consists of metamodel extension points, extension operations, and primitive predicates for navigating the metamodel. Although the notion of MMAP is useful, it needs tool support. This paper proposes a method for implementing a MMAP-based AspectM support tool. It consists of model editor, model weaver, and model verifier. We introduce the notion of edit-time structural reflection and extensible model weaving. Using these mechanisms, a modeler can easily construct domain-specific languages (DSLs). We show a case study using the AspectM support tool and discuss the effectiveness of the extension mechanism provided by MMAP. As a case study, we show a UML-based DSL for describing the external contexts of embedded systems.