Software engineering education at universities plays an increasingly important role as software quality is becoming essential in realizing a safe and dependable society. This paper proposes a practical state transition model (Practical-STM) based on the Organizational Expectancy Model for the improvement of software process education based on the Personal Software Process (PSP) from a motivation point of view. The Practical-STM treats an individual trainee of the PSP course as a state machine, and formalizes a motivation process of a trainee using a set of states represented by factors regarding motivation and a set of operations carried out by course instructors. The state transition function of this model represents the features or characteristics of a trainee in terms of motivation. The model allows a formal description of the states of a trainee in terms of motivation and the educational actions of the instructors in the PSP course. The instructors are able to decide effective and efficient actions to take toward the trainees objectively by presuming a state and a state transition function of the trainees formally. Typical patterns of state transitions from an initial state to a final state, which is called a scenario, are useful for inferring possible transitions of a trainee and taking proactive operations from a motivation point of view. Therefore, the model is useful not only for improving the educational effect of the PSP course, but also for the standardization of the course management and the quality management of the instructors.

Requirements are elicited step by step during the requirements engineering (RE) process. However, some types of requirements are elicited completely after the scheduled requirements elicitation process is finished. Such a situation is regarded as problematic situation. In our study, the difficulties of eliciting various kinds of requirements is observed by components. We refer to the components as observation targets (OTs) and introduce the word “Requirements maturation.” It means when and how requirements are elicited completely in the project. The requirements maturation is discussed on physical and logical OTs. OTs Viewed from a logical viewpoint are called logical OTs, e.g. quality requirements. The requirements of physical OTs, e.g., modules, components, subsystems, etc., includes functional and non-functional requirements. They are influenced by their requesters' environmental changes, as well as developers' technical changes. In order to infer the requirements maturation period of each OT, we need to know how much these factors influence the OTs' requirements maturation. According to the observation of actual past projects, we defined the PRINCE (Pre Requirements Intelligence Net Consideration and Evaluation) model. It aims to guide developers in their observation of the requirements maturation of OTs. We quantitatively analyzed the actual cases with their requirements elicitation process and extracted essential factors that influence the requirements maturation. The results of interviews of project managers are analyzed by WEKA, a data mining system, from which the decision tree was derived. This paper introduces the PRINCE model and the category of logical OTs to be observed. The decision tree that helps developers infer the maturation type of an OT is also described. We evaluate the tree through real projects and discuss its ability to infer the requirements maturation types.

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.

The modeling of an application domain and its specific knowledge description language are important for developing knowledge-based systems. A rapid-prototyping approach is suitable for such developments since in this approach the modeling and language development are processed simultaneously. However, programming languages and their supporting environments which are usually used for prototyping are not necessarily adequate for developing practical applications. We have been developing an integrated development environment for knowledge-based systems, which supports all the development phases from the early prototyping phase to final commercial development phase. The environment called INSIDE is based on a Prolog abstract machine, and provides all of the functions required for the development of practical applications in addition to the standard Prolog features. This enables the development of both prototypes and practical applications in the same environment. Moreover, their efficient development and maintenance can be achieved. In addition, the effectiveness of INSIDE is described by examples of its practical application.

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.

The success of any project can be affected by requirements changes. Requirements elicitation is a series of activities of adding, deleting, and modifying requirements. We refer to the completion of requirements elicitation of a software component as requirements maturation. When the requirements of each component have reached the 100% maturation point, no requirement will come to the component. This does not mean that a requirements analyst (RA) will reject the addition of requirements, but simply, that the additional requirements will not come to the project. Our motivation is to provide measurements by which an RA can estimate one of the maturation periods: the early, middle, or late period of the project. We will proceed by introducing the requirements maturation efficiency (RME). The RME of the requirements represents how quickly the requirements of a component reach 100% maturation. Then, we will estimate the requirements maturation period for every component by applying the RME. We assume that the RME is derived from its accessibility from an RA to the requirements source and the stability of the requirements. We model accessibility as the number of information flows from the source of the requirements to the RA, and further, model stability with the requirements maturation index (RMI). According to the multiple regression analysis of a case, we are able to get an equation on RME derived from these two factors with a significant level of 5%. We evaluated the result by comparing it to another case, and then discuss the effectiveness of the measurements.

This paper proposes a reference model of CAD system generation, and describes its prototype implementation. The problems encountered in using CAD systems in industry involve complicated data handling and unsatisfied demands for domain knowledge because of the lack of a way of extracting and adopting it in the system. In the example domain of architecture, the authors have already defined domain-specific BDL (Building Design Language) for architecture experts to describe modelers of architectural structure in CAD systems by themselves. Moreover, the authors have developed a CAD system generator based on BDL descriptions. However, the different domain-specific languages required for individual domains create difficulty in developing various CAD system generators. The proposed reference model solves this problem by applying a common intermediate language based on the object model. Moreover, the model allows the creation of an integrated CAD system which contains multiple domains required by a field of industry. Its prototype implementation demonstrates its feasibility.