Rethinking the Development Process in the AI Era

The Unified Process (UP) is a technology framework centered on models. The process assumes that models are created first and then translated into programs.

Requirement models and design models are used in UP as the basis for design decisions and implementation policies. Programs are concrete realizations of those models, and their consistency with the intent of the models is subject to verification.

In this way, UP presupposes a process in which meaning and structure are first established in models before proceeding to implementation.

One of the major characteristics of UP is that its project management framework has a dual structure of phases and iterations. The phases are divided into four: Inception, Elaboration, Construction, and Transition.

Phases are not merely process stages, but a meta-structure for shifting what should be emphasized and what should be fixed in the next stage. As phases progress, the center of gravity shifts in terms of requirement precision, architectural stability, and overall completeness.

Iterations in UP are not simply repetitions of work. Each iteration is positioned as a unit for redesigning how to proceed next, based on the knowledge gained at that point.

Thus, UP provides a mechanism for absorbing and organizing change at a meta level—through phases and iteration planning—rather than injecting it directly into day-to-day tasks.

The Unified Process (UP) is also a process that presupposes component-based development (CBD).

UP emphasizes dividing responsibilities into units such as subsystems and components and assigning clear boundaries to them in order to make the impact of changes easier to control.

CBD has important implications for the process itself, not merely as a design or implementation technique. Once component boundaries are established, it becomes clear which areas are subject to change and which constitute stable regions.

In UP, such boundaries are deliberately designed at a relatively early stage, serving as a foundation for stabilizing subsequent development.

In UP, use cases are not merely requirement descriptions.

Use cases are used as a central axis that runs through the entire development process.

As a result, each development activity is given meaning in terms of which use case it is intended to realize. In project management as well, progress can be assessed based on the realization status of use cases rather than merely on task completion.

The Unified Process (UP) presupposes iterative and incremental development.

Iteration in UP is defined as an approach that repeatedly executes small development units encompassing analysis, design, implementation, and testing.

Rather than flowing processes in a single direction, this design assumes that technical and structural factors—only revealed through implementation—should be identified early.

Iteration is positioned as a fundamental mechanism for surfacing such factors early, rather than deferring them to later stages of development.

Incremental development in UP is defined as an approach that progressively determines the content and precision of deliverables as development proceeds, rather than aiming for a complete form from the outset.

Elements such as requirements, design, and architecture are initially placed in provisional form and are gradually concretized and stabilized through iterations.

Incremental development is positioned as a fundamental progression principle that does not assume full determination at the outset, but instead builds decisions step by step.

In UP, architecture is placed at the center of decision-making.

Architecture is not merely a structural diagram, but a foundation that constrains and guides subsequent design and implementation choices. By establishing architecture at an early stage, the cost of rework is reduced and the overall stability of development is increased.

This architecture-centric perspective reflects a stance that prioritizes structural soundness over functional completeness.

One of the fundamental ideas underlying the Unified Process (UP) is risk-driven development.

In UP, priorities are determined not by simple feature order or workload, but by the magnitude of technical and structural risks.

The phase structure itself is designed from the perspective of which risks should be mitigated, when, and at what stage.

This makes it possible to surface uncertainties early and address them, rather than having problems emerge late and cause failure.

As we have seen so far, the Unified Process is a software development framework designed to accommodate projects of various scales and purposes, ranging from large enterprise systems to single-shot web applications.

Elements such as phases, iterations, architecture, use cases, and risks are organized as a set of functions for structuring how development proceeds and at what granularity decisions are made.

The Unified Process is positioned as a framework that allows development processes to be constructed according to the scale and nature of a project by combining these functions.

UP treats object models described in UML as primary artifacts and positions programs as deliverables derived from those models.

In contrast, agile development treats programs as primary artifacts, resulting in a code-driven development process.

Model-driven versus program-driven: this distinction can be seen as the decisive difference between UP and agile development.

This characteristic concerns the level at which change and uncertainty are organized and reflected in decision-making.

UP has a dual structure of phases and iterations, shifting the center of gravity of the project at the phase level while carrying out individual validation and progress through iterations. Changes are primarily organized at the level of planning and redesign.

Agile development, on the other hand, lacks a higher-level structure such as phases and responds to change directly within iterations (sprints). While both address the same challenges, they differ in the layer at which flexibility is exercised.

This characteristic addresses how the scope of change impact is controlled through process mechanisms.

In UP, component orientation is built into the development process from the outset. Boundaries are defined early, and subsequent changes are, in principle, localized.

In contrast, agile development does not mandate the definition or stabilization of component boundaries as a formal process, leaving such decisions to developers and teams.

This characteristic concerns how work is given meaning and at what unit it is managed.

In UP, use cases serve as management units that run through the entire process, linking requirements, design, testing, and progress tracking.

Agile development proceeds by starting from a backlog and decomposing work into user stories and tasks. While both approaches share similar concerns, they adopt methods with different levels of granularity and modes of expression.

This characteristic concerns what is advanced through iteration.

In UP, iteration is positioned as a means to mature understanding and structure and to reduce uncertainty. Outcomes are evaluated in terms of structural clarification and risk reduction.

Iteration is also an important means of progress in agile development, but it proceeds primarily through working deliverables and feedback. The difference lies in the layer at which iteration is operated and the criteria by which it is evaluated.

This characteristic concerns how far the process guarantees when and to what extent structure is determined.

In UP, architecture is positioned at the center of decision-making, and establishing it early is a process requirement.

In agile development, an architecture-centric stance is not mandatory, and structural establishment is assumed to occur gradually through practice and refactoring.

This characteristic concerns how priorities are determined.

In UP, technical and structural risks are explicitly prioritized, and the phase structure itself is designed as a risk mitigation strategy.

In agile development, business value and feedback serve as primary decision inputs, and risks that emerge during execution are handled incrementally.