THE UNIFIED PROCESS AND PERSONAL/TEAM PROCESS MODELS
Introduction to the Unified Process (UP)
The Unified Process is an iterative and incremental software development process framework
that incorporates the best features of traditional software development models while integrating
agile principles. It emphasizes customer communication, use case-driven development, and
software architecture to ensure adaptability to changes and reuse of components.
History of the Unified Process
During the early 1990s, James Rumbaugh, Grady Booch, and Ivar Jacobson worked on a unified
methodology that merged their object-oriented analysis and design methods. This led to the
development of UML (Unified Modeling Language) in 1997, which became an industry standard
for object-oriented software development.
While UML provided a strong notation system for modeling, it did not offer a process framework.
Jacobson, Rumbaugh, and Booch later developed the Unified Process as a comprehensive
framework for object-oriented software engineering using UML. Today, UP and UML are widely
used across various projects, with UP being adaptable to specific project needs.
Phases of the Unified Process
The Unified Process is divided into five key phases that align with the generic software process
model:
Inception Phase
• Focuses on customer communication and planning.
• Stakeholders collaborate to identify fundamental business requirements.
• Preliminary use cases are developed to define user interactions and expectations.
• A rough system architecture is proposed.
• Planning includes resource identification, risk assessment, scheduling, and outlining
iterative development cycles.
Elaboration Phase
• Refinement and expansion of initial use cases and requirements models.
• Architectural models developed with five views: use case model, requirements model,
design model, implementation model, and deployment model.
• May produce an “executable architectural baseline” that demonstrates the feasibility of
the system.
• The project plan is reviewed and refined to ensure risk assessment and realistic delivery
schedules.
Construction Phase
• Implements software components based on architectural models.
• Use cases guide software development and testing.
• Development models from the elaboration phase are finalized.
• Source code is implemented, unit tested, and integrated.
• Integration testing ensures the correct operation of combined components.
• Acceptance tests are derived from use cases to validate the system.
Transition Phase
• Focuses on software deployment and user acceptance.
• Beta testing is conducted, with user feedback identifying defects and necessary changes.
• Support documentation (user manuals, installation guides, troubleshooting resources) is
developed.
• Software increment is released for use.
Production Phase
• Coincides with deployment activities.
• Involves ongoing monitoring, support, and maintenance of the software.
• User-reported defects and change requests are managed.
• While one software increment is in production, work on the next increment may have
already begun, leading to staggered concurrency in UP phases.
Software Engineering Workflow in UP
• UP defines a workflow as a set of tasks required to complete software engineering
actions.
• Workflows can be adapted to meet the specific needs of a project.
PERSONAL AND TEAM PROCESS MODELS
A software process should be adaptable to individual developers and teams. Watts Humphrey
proposed Personal Software Process (PSP) and Team Software Process (TSP) models to enhance
software engineering discipline.
Personal Software Process (PSP)
PSP focuses on personal discipline and measurement of software development activities.
Developers follow a structured process to improve productivity and quality through
measurement and analysis.
PSP Framework Activities:
1. Planning – Define requirements, estimate size and resources, project defects, and create
a schedule.
2. High-Level Design – Develop external specifications and component designs, prototype
uncertain components, and document issues.
3. High-Level Design Review – Apply formal verification techniques to identify design errors
and maintain metrics.
4. Development – Refine design, generate and review code, compile and test components.
5. Postmortem – Analyze collected metrics to assess process effectiveness and identify
improvements.
PSP focuses on identifying errors early and understanding common mistakes. While highly
effective, PSP adoption is hindered by training costs, cultural resistance, and required
commitment levels.
Team Software Process (TSP)
TSP extends PSP principles to team-based projects, aiming to build self-directed teams that
improve productivity and software quality.
Objectives of TSP:
• Encourage self-directed teams to plan, track, and own their processes.
• Provide managerial guidance for coaching and sustaining peak team performance.
• Accelerate process improvement in high-maturity organizations.
• Improve team-based software engineering education.
TSP Framework Activities:
1. Project Launch – Define objectives, assign roles, and create a project plan.
2. High-Level Design – Develop and refine architectural models.
3. Implementation – Code development, unit testing, and component integration.
4. Integration and Testing – Ensure system functionality and performance.
5. Postmortem – Review collected metrics to improve future processes.
TSP emphasizes structured task management, risk assessment, and quantitative tracking. Like
PSP, TSP requires a strong commitment and training for effective implementation.
PROCESS TECHNOLOGY
Organizations use process technology tools to analyze, monitor, and control software
development activities. These tools help:
• Build automated models of software processes.
• Organize tasks, monitor progress, and ensure quality control.
• Define workflows and integrate with software engineering tools.
Product and Process
Margaret Davis highlighted the ongoing shift between product and process focus in software
engineering. Both aspects must be considered together to achieve high-quality development.
Key Points:
• The software community alternates between focusing on product (e.g., structured
programming, object-oriented methods) and process (e.g., structured analysis, agile
development).
• Software should be viewed as a duality of product and process rather than two separate
aspects.
• Satisfaction in software development comes from both the creative process and the final
product.
• Reuse of software artifacts is enhanced when both product and process perspectives are
considered together.
