1. Unified Process Review

2. Unified Process Phases
Inception
Elaboration
Construction
Transition
Inception
Establish the business case for the system, define risks, obtain 10% of the requirements, estimate next phase effort.
Elaboration
Develop an understanding of the problem domain and the system architecture, risk significant portions may be coded/tested, 80% major requirements identified.
Construction
System design, programming and testing. Building the remaining system in short iterations.
Transition
Deploy the system in its operating environment. Deliver releases for feedback and deployment.

3. Unified Process Model

4. The Phases/Workflows of the Unified Process
Phase is Business context of a step
Workflow is Technical context of a step
We have almost completed the elaboration phase.
We need to define our environment for the system.
We have the domain architecture but not the environmental architecture.
We have not yet laid out a plan of how we will implement
We are
here
Figure 3.1

5. Unified Process – Inception
OVERVIEW
Establish the business case for the system, define risks, obtain 10% to 20% of the requirements, estimate next phase effort.
DONE
The inception phase is of significance primarily for new development efforts, in which there are significant business and requirements risks which must be addressed before the project can proceed. For projects focused on enhancements to an existing system, the inception phase is more brief, but is still focused on ensuring that the project is both worth doing and possible to do.

6. Unified Process – Inception Objectives
Gain an understanding of the domain. DONE
Delimit the scope of the proposed project with a focus on the subset of the business model that is covered by the proposed software product DONE
Define an initial business case for the proposed system including costs, schedules, risks, priorities, and the development plan. DONE
Define an any needed prototypes to mitigate risks.DONE
Obtain stakeholder concurrence on scope definition, expenditures, cost/schedule estimates, risks, development plan and priorities. DONE

7. Unified Process – Elaboration Phase
Develop an understanding of the problem domain and the system architecture, risk significant portions may be coded/tested, 80% major requirements identified. DONE

8. Unified Process – Elaboration Activities
Elaboration Essential Activities
Analyze the problem domain.DONE
Define, validate and baseline the architecture (not yet)
Refine the Vision to understand the most critical Use Cases DONE
Create and baseline iteration plans for construction phase. (not yet)
Refine the development business case DONE
Put in place the development environment, (not yet)
Refine component architecture and decide build/buy/reuse DONE
Develop a project plan and schedule. (not yet)
Mitigate high-risk elements identified in the previous phase. DONE
This phase is a continuation of the analysis work done in the previous phase. It includes further analization of the problem domain, defining, validating and baselining the architecture as rapidly as practica, refining the Vision, based on new information obtained during the phase, establishing a solid understanding of the most critical use cases that drive the architectural and planning decisions, continuing with use case analysis by driving out the full descriptions to identify business rules and logic.
Detailed iteration plans for the software development and construction are identified and documented.
The development environment is defined including the process, tools and automation support required to support the construction team. The architecture and selected components are refined so that potential components can be evaluated for build/buy/reuse decisions with a sufficient understanding to determine the construction phase cost and schedule with confidence. The selected architectural components are integrated and assessed against the primary scenarios documented from the use cases. Lessons learned from these activities may well result in a redesign of the architecture, taking into consideration alternative designs or reconsideration of the requirements.

9. Unified Process – Elaboration Deliverables
Primary deliverables:
Requirements model for the system
The completed domain model (use cases, classes)
The completed business model (costs, benefits,risks)
The completed requirements artifacts
The completed analysis artifacts
Updated Architectural model NOT YET
Software project management plan NOT YET
All of these are done except the architectural model and project management plan which we will do during the first few weeks of class

10. Unified Process – Construction Phase
System design, programming and testing. Building the remaining system in short iterations.
The goal of the construction phase is to clarify the remaining requirements and complete the development of the first operational quality version of the software product.
Focus is on the implementation of the design
The construction phase is in some sense a manufacturing process, where emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and quality. In this sense the management mindset undergoes a transition from the development of intellectual property during inception and elaboration, to the development of deployable products during construction and transition.

11. Unified Process – Construction Objectives
Minimizing development costs.
Achieving adequate quality as rapidly as practical
Achieving useful versions as rapidly as practical
Complete analysis, design, development and testing of functionality.
To iteratively and incrementally develop a complete product
To decide if the software, sites, and users are deployment ready.
To achieve parallelism in the work of development teams. 
The primary objectives of the construction phase include:
Minimizing development costs by optimizing resources and avoiding unnecessary scrap and rework.
Achieving adequate quality as rapidly as practical
Achieving useful versions (alpha, beta, and other test releases) as rapidly as practical
Completing the analysis, design, development and testing of all required functionality.
To iteratively and incrementally develop a complete product that is ready to transition to its user community. This implies describing the remaining use cases and other requirements, fleshing out the design, completing the implementation, and testing the software.
To decide if the software, the sites, and the users are all ready for the application to be deployed.
To achieve some degree of parallelism in the work of development teams.  Even on smaller projects, there are typically components that can be developed independently of one another, allowing for natural parallelism between teams (resources permitting). This parallelism can accelerate the development activities significantly; but it also increases the complexity of resource management and workflow synchronization. A robust architecture is essential if any significant parallelism is to be achieved.
Focus is on implementation of the design:
cumulative increase in functionality
greater depth of implementation (stubs fleshed out)
greater stability begins to appear
implement all details, not only those of central architectural value
analysis continues, but design and coding predominate

12. Unified Process – Construction Activities
Construction Essential Activities
Complete component development and testing (beta release)
Assess product releases against acceptance criteria for the vision. (Unit, Integration, Functional and System testing)
Integrate all remaining components and features into the product
Assure resource management control and process optimization
The emphasis in this phase is on
Implementation, and
Testing
Unit testing of modules
Integration testing of subsystems
Product testing of the overall system
Emphasis is placed on managing resources and controlling operations to optimise cost, schedules and quality.
Parallel construction can accelerate the availability of deployable releases.
Build the system in a series of iterations
Each iteration is a mini project
Develop a software product ready for inital operation (beta release)
Capture the remaining Requirements
Prioritize Use Cases to be implemented
Detail the remaining Use Cases, by completing their realization
Refine the Architectural Model by adding new subsystems and detailing existing ones
DESIGN DESIGN DESIGN
Implementation of the architecture, the subsystems, the classes
Perform Unit Testing
Integrate System
Perform System Testing

13. Unified Process – Construction Deliverables
Primary deliverables
Working software system (beta release version)
Associated documentation
Acceptance testing documentation
Updated project management deliverables (plan, risks, business case)
User Manuals
The deliverables of the construction phase include:
The initial user manual and other manuals, as appropriate
All the artifacts (beta release versions)
The completed architecture
The updated risk list
The project management plan (for the remainder of the project)
If necessary, the updated business case

14. Unified Process – Construction Outcomes
A product ready to put into the hands of end users.
The software product integrated on the adequate platforms.
The user manuals.
A description of the current release.

15. Unified Process – Construction Questions
Is this product (beta test version) release stable and mature enough to be deployed in the user community?
Are all stakeholders ready for the transition into the user community?
Are the actual resource expenditures versus planned expenditures still acceptable?
Transition may have to be postponed by one release if the project fails to reach this milestone.
During the construction phase, all remaining components and application features are developed and integrated into the product, and all features are thoroughly tested. The construction phase is, in one sense, a manufacturing process where emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and quality. In this sense, the management mindset undergoes a transition from the development of intellectual property during inception and elaboration, to the development of deployable products during construction and transition.

16. Unified Process – Transition Phase
Deploy the system in its operating environment. Deliver releases for feedback and deployment.
The focus of the Transition Phase is to ensure that software is available for its end users and meets their needs. The Transition Phase can span several iterations, and includes testing the product in preparation for release, and making minor adjustments based on user feedback.
Consists of the transfer of the system to the user community
Includes the manufacturing, shipping, installation, training, technical support and maintenance
Control is moved to the maintenance team
Integration with existing systems (legacy systems)
The focus of the Transition Phase is to ensure that software is available for its end users. The Transition Phase can span several iterations, and includes testing the product in preparation for release, and making minor adjustments based on user feedback. At this point in the lifecycle, user feedback should focus mainly on fine tuning the product, configuring, installing and usability issues, all the major structural issues should have been worked out much earlier in the project lifecycle. 
By the end of the Transition Phase lifecycle objectives should have been met and the project should be in a position to be closed out. In some cases, the end of the current life cycle may coincide with the start of another lifecycle on the same product, leading to the next generation or version of the product. For other projects, the end of Transition may coincide with a complete delivery of the artifacts to a third party who may be responsible for operations, maintenance and enhancements of the delivered system.
This Transition Phase ranges from being very straightforward to extremely complex, depending on the kind of product. A new release of an existing desktop product may be very simple, whereas the replacement of a nation's air-traffic control system may be exceedingly complex.
Activities performed during an iteration in the Transition Phase depend on the goal. For example,  when fixing bugs, implementation and test are usually enough. If, however, new features have to be added, the iteration is similar to one in the construction phase requiring analysis&design, etc.
The Transition Phase is entered when a baseline is mature enough to be deployed in the end-user domain. This typically requires that some usable subset of the system has been completed with acceptable quality level and user documentation so that transitioning to the user provides positive results for all parties. 

17. Unified Process – Transition Objectives
Assess deployment baselines against acceptance criteria
Achieve user self-supportability
Achieving stakeholder concurrence of acceptance
Achieve user self-supportability.
Achieve stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision.
Achieve final product baseline as rapidly and cost-effectively as practical.

18. Unified Process – Transition Activities
Transition Essential Activities
Finalize end-user support material
Test the deliverable product at the development site
Validate beta test to assure user expectations met
Fine-tune the product based on feedback
Perform parallel operation of replaced legacy system
Convert operational databases
Train of users and maintainers
Roll-out to the marketing, distribution and sales forces Perform deployment engineering (cutover, roll-out performance tuning)
Focus on establishing the product in the operational environment
Distribute Beta Release
Gather user feedback
Refine product per user feedback
Re test the system
Prepare system rollout
Completing all project artifacts
Update all user models needed
Update user, operator, and system administrator manuals
Perform a post mortem of the project
The purpose of the transition phase is to transition the software product to the user community. Once the product has been given to the end user, issues usually arise that require you to develop new releases, correct some problems, or finish the features that were postponed.
The transition phase consists of the transfer of the system to the user community
It includes manufacturing, shipping, installation, training, technical support and maintenance
Development team begins to shrink
Control is moved to maintenance team
Alpha, Beta, and final releases
Software updates
Integration with existing systems (legacy, existing versions, etc.)

19. Unified Process – Transition Deliverables
Primary deliverable
Final product onto a production platform
Other deliverables
All the artifacts (final versions)
Completed manual
This moves the software project to the user community.
After release, issues usually arise that require new releases, either to correct problems or finish features that were postponed.
This phase is entered when a baseline is mature enough to be deployed in the end-user domain.
This means that some usable subset of the system has beem completed to an acceptable level of quality and that user documentation is available.
The activities depend on the goal
For fixing bugs, implementation and testing are usually enough.
For new features, iteration is similar to construction phase.

20. Phase Deliverables Inception Phase Elaboration Phase
Construction Phase
Transition Phase
The initial version of the domain model
The initial version of the business model
The initial version of the requirements artifacts
A preliminary version of the analysis artifacts
A preliminary version of the architecture
The initial list of risks
The initial ordering of the use cases
The plan for the elaboration phase
The initial version of the business case
The completed domain model
The completed business model
The completed requirements artifacts
The completed analysis artifacts
An updated version of the architecture
An updated list of risks
The project management plan (for the rest of the project)
The completed business case
The initial user manual and other manuals, as appropriate
All the artifacts (beta release versions)
The completed architecture
The updated risk list
The project management plan (for the remainder of the project)
If necessary, the updated business case
All the artifacts (final versions)
The completed manuals

21. Process Overview Phases (time) Workflow (tasks) Inception Elaboration
Construction
Transition
Requirements
Analysis
Design
Implementation
Test

22. The Phases/Workflows of the Unified Process
Phase is Business context of a step
Workflow is Technical context of a step
Figure 3.1

23. The Unified Process

24. Static workflows

25. Primary Workflows The Unified Process PRIMARY WORKFLOWS
Requirements workflow
Analysis workflow
Design workflow
Implementation workflow
Test workflow
Post delivery maintenance workflow
Supplemental Workflows
Planning Workflow

26. Planning Workflow Define scope of Project
Define scope of next iteration
Identify Stakeholders
Capture Stakeholders expectation
Build team
Assess Risks
Plan work for the iteration
Plan work for Project
Develop Criteria for iteration/project closure/success
UML concepts used: initial Business Model, using class diagram

27. Requirements Workflow
Workflow (tasks)
Requirements
Analysis
Design
Implementation
Testing
Requirements Workflow
Primary focus
To determine the client’s needs by eliciting both functional and nonfunctional requirements
Gain an understanding of the application domain
Described in the language of the customer
Application domain
The specific environment in which the target software product is to operate
Examples: banking, aerospace, university/college
List candidate requirements (textual feature list)
Understand system context
domain model describing important concepts of the context
business modeling specifying what processes have to be supported by the system using Activity Diagram
Capture functional and nonfunctional requirements (Use Case Model)
It is vital to determine t

28. Requirements Workflow
Workflow (tasks)
Requirements
Analysis
Design
Implementation
Testing
Requirements Workflow
The aim is to determine the client’s needs
First, gain an understanding of the domain
How does the specific business environment work
Second, build a business model
Use UML to describe the client’s business processes
If at any time the client does not feel that the cost is justified, development terminates immediately
It is vital to determine the client’s constraints
Deadline -- Nowadays software products are often mission critical
Parallel running
Portability
Reliability
Rapid response time
Cost
The aim of this concept exploration is to determine
What the client needs, and
Not what the client wants
he client’s constraints (nonfunctional requirements)
Deadline
Nowadays software products are often mission critical
Portability
Reliability
Rapid response time
Cost
The client will rarely inform the developer how much money is available
A bidding procedure is used instead

29. Requirements Workflow
Workflow (tasks)
Requirements
Analysis
Design
Implementation
Testing
Requirements Workflow
List candidate requirements
textual feature list
Understand system context
domain model describing important concepts of the context
business modeling specifying what processes have to be supported by the system using Activity Diagram
Capture functional and nonfunctional requirements
Use Case Model
Supplementary requirements
physical, interface, design constraints, implementation constraints

30. Analysis Workflow Primary focus
Workflow (tasks)
Requirements
Analysis
Design
Implementation
Testing
Analysis Workflow
Primary focus
Analyzing and refining the requirements to achieve a detailed understanding of the requirements essential for developing a software product correctly
To ensure that both the developer and user organizations understand the underlying problem and its domain
Written in a more precise language
Written in a more precise language
Ensures that the design and implementation workflows are carried out correctly

31. Analysis Workflow Workflow (tasks) The aim of the analysis workflow
Requirements
Analysis
Design
Implementation
Testing
Analysis Workflow
The aim of the analysis workflow
To analyze and refine the requirements
Two separate workflows are needed
The requirements artifacts must be expressed in the language of the client
The analysis artifacts must be precise, and complete enough for the designers
Specification document (“specifications”)
Constitutes a contract
It must not have imprecise phrases like “optimal,” or “98 percent complete”
Having complete and correct specifications is essential for
Testing, and
Maintenance
The specification document must not have
Contradictions
Omissions
Incompleteness
Analyze in depth the requirements
Develop Sequence Diagram from Use Cases
Develop Analysis Model: Class Diagram and State Diagram
Focus on what is the problem not how to solve it
Three main types of classes stereotypes may be used:
Boundary Classes: used to model interaction between system and its actors
Entity Classes: used to model information and associated behavior directly derived from real-world concept
Control Class: used to model business logic, computations transactions or coordination.
The aim of the analysis workflow
To analyze and refine the requirements
Why not do this during the requirements workflow?
The requirements artifacts must be totally comprehensible by the client
The artifacts of the requirements workflow must therefore be expressed in a natural (human) language
All natural languages are imprecise
Example from a manufacturing information system:
“A part record and a plant record are read from the database. If it contains the letter A directly followed by the letter Q, then calculate the cost of transporting that part to that plant”
To what does “it” refer?
The part record?
The plant record?
Or the database?
Two separate workflows are needed
The requirements artifacts must be expressed in the language of the client
The analysis artifacts must be precise, and complete enough for the designers
Specification document (“specifications”)
Constitutes a contract
It must not have imprecise phrases like “optimal,” or “98 percent complete”
Having complete and correct specifications is essential for
Testing, and
Maintenance
The specification document must not have
Contradictions
Omissions
Incompleteness

32. Workflow (tasks)
Requirements
Analysis
Design
Implementation
Testing
Analysis Workflow
Structure the Use Cases
Start reasoning about the internal of the system
Develop Analysis Model: Class Diagram and State Diagram
Focus on what is the problem not how to solve it
Understand the main concepts of the problem
Three main types of classes stereotypes may be used:
Boundary Classes: used to model interaction between system and actors
Entity Classes: used to model information and associated behavior deirectly derived from real-world concept
Control Class: used to model business logic, computations transactions or coordination.
The specification document must not have
Contradictions
Omissions
Incompleteness

33. Workflow (tasks)
Requirements
Analysis
Design
Implementation
Testing
Design Workflow
The aim of the design workflow is to refine the analysis workflow until the material is in a form that can be implemented by the programmers
Determines the internal structure of the software product
Refine the Class Diagram
Assign responsibilities to new design classes
Assign visibility to class attributes
Define Methods signature
Structure system with Subsystems, Interfaces, Classes
Define subsystems dependencies
Capture major interfaces between subsystems
Describe realization of Use Cases
Develop state diagram for relevant design classes
Use Interaction Diagram to distribute behavior among classes
Use Design Patterns for parts of the system

34. Design Workflow Workflow (tasks)
Requirements
Analysis
Design
Implementation
Testing
Design Workflow
The goal is to refine the analysis workflow until the material is in a form that can be implemented by the programmers
Many nonfunctional requirements need to be finalized at this time, including: Choice of programming language, Reuse issues, Portability issues.
Classical Design
Architectural design
Decompose the product into modules
Detailed design
Design each module using data structures and algorithms
Object Oriented Design
Classes are extracted during the object-oriented analysis workflow, and
Designed during the design workflow
The goal is to refine the analysis workflow until the material is in a form that can be implemented by the programmers
Many nonfunctional requirements need to be finalized at this time, including: Choice of programming language, Reuse issues, Portability issues.
Classical Design
Architectural design
Decompose the product into modules
Detailed design
Design each module using data structures and algorithms
Object Oriented Design
Classes are extracted during the object-oriented analysis workflow, and
Designed during the design workflow
Mapping between Classical and OO
Classical architectural design corresponds to part of the object-oriented analysis workflow
Classical detailed design corresponds to part of the object-oriented design workflow
Accordingly
Retain design decisions
For when a dead-end is reached, and
To prevent the maintenance team reinventing the wheel

35. Design Workflow General Design Refine the Class Diagram
Workflow (tasks)
Requirements
Analysis
Design
Implementation
Testing
Design Workflow
General Design
Refine the Class Diagram
Structure system with Subsystems, Interfaces, Classes
Define subsystems dependencies
Capture major interfaces between subsystems
Assign responsibilities to new design classes
Describe realization of Use Cases
Assign visibility to class attributes
Define Methods signature
Develop state diagram for relevant design classes
Use Interaction Diagram to distribute behavior among classes
Use Design Patterns for parts of the system

36. Design Workflow Architectureal Design Identify Design Mechanisms
Workflow (tasks)
Requirements
Analysis
Design
Implementation
Testing
Design Workflow
Architectureal Design
Identify Design Mechanisms
Refine Analysis based on implementation environment
Characterize needs for specific mechanisms (inter-process communication, real-time computation, access to legacy system, persistence, …)
Assess existing implementation mechanisms
Identify Design Classes and Subsystems
A Subsystem is a special kind of Package which has behavioral semantics (realizes one or more interfaces)
Refine analysis classes
Group classes into Packages
Identify Subsystems when analysis classes are complex
Look for strong interactions between classes
Try to organize the UI classes into a subsystem
Separate functionality used by different actors in different subsystems
Separate subsystems based on the distribution needs
Identify Interfaces of the subsystems

37. Implementation Workflow
Workflow (tasks)
Requirements
Analysis
Design
Implementation
Testing
Implementation Workflow
The aim of the implementation workflow is to implement the target software product in the selected implementation language

38. Implementation Workflow
Workflow (tasks)
Requirements
Analysis
Design
Implementation
Testing
Implementation Workflow
Distribute the system by mapping executable components onto nodes in the deployment model
Implement Design Classes and subsystems through packaging mechanism:
package in Java, Project in VB, files directory in C++
Acquire external components realizing needed interfaces
Unit test the components
Integrate via builds
Distribute the system by mapping executable components onto nodes in the deployment model
Implement Design Classes and subsystems through packaging mechanism:
package in Java, Project in VB, files directory in C++
Acquire external components realizing needed interfaces
Unit test the components
Integrate via builds
The aim of the implementation workflow is to implement the target software product in the selected implementation language
A large software product is partitioned into subsystems
The subsystems consist of components or code artifacts

39. Test Workflow Carried out in parallel with other workflows
Workflow (tasks)
Requirements
Analysis
Design
Implementation
Testing
Test Workflow
Carried out in parallel with other workflows
Primary purpose
To increase the quality of the evolving system
The test workflow is the responsibility of
Every developer and maintainer
Quality assurance group
Develop set of test cases that specify what to test in the system
many for each Use Case
each test case will verify one scenario of the use case
based on Sequence Diagram
Develop test procedures specifying how to perform test cases
Develop test component that automates test procedures
The test workflow is the responsibility of
Every developer and maintainer, and
The quality assurance group
Traceability of artifacts is an important requirement for successful testing

40. Test Workflow many for each Use Case
Workflow (tasks)
Requirements
Analysis
Design
Implementation
Testing
Test Workflow
Develop set of test cases that specify what to test in the system
many for each Use Case
each test case will verify one scenario of the use case
based on Sequence Diagram
Develop test procedures specifying how to perform test cases
Develop test component that automates test procedures
Develop set of test cases that specify what to test in the system
many for each Use Case
each test case will verify one scenario of the use case
based on Sequence Diagram
Develop test procedures specifying how to perform test cases
Develop test component that automates test procedures
The test workflow is the responsibility of
Every developer and maintainer, and
The quality assurance group
Traceability of artifacts is an important requirement for successful testing

41. Deployment Workflow Activities include Software packaging Distribution
Installation
Beta testing
Producing the Software
Output of implementation is tested executables.
Must be associated with other artifacts to constitute a complete product:
Installation scripts
User documentation
Configuration data
Additional programs for migration: data conversion

42. Deployment Workflow Producing the Software
Output of implementation is tested executables.
Must be associated with other artifacts to constitute a complete product:
Installation scripts
User documentation
Configuration data
Additional programs for migration: data conversion.
In some cases:
different executables needed for different user configurations
different sets of artifacts needed for different classes of users:
new users versus existing users,
variants by country or language
Producing the Software
Output of implementation is tested executables.
Must be associated with other artifacts to constitute a complete product:
Installation scripts
User documentation
Configuration data
Additional programs for migration: data conversion

43. Deployment Workflow
Producing the Software (continued)
For distributed software, different sets may have to be produced for different computing nodes in the network Packaging the Software
Distributing the Software
Installing the Software
Migration
Providing Help and Assistance to Users
Acceptance
Producing the Software
Output of implementation is tested executables.
Must be associated with other artifacts to constitute a complete product:
Installation scripts
User documentation
Configuration data
Additional programs for migration: data conversion

44. Iterations and WorkflowP h a s e C o r e W k f l w s I n c e p t i o E l a b o r t i n C o n s t r u c i T r a n s i t o
Requirements A n i t e r a o h l b p s
Analysis
Design
Implementation
Test P r e l i m n a y I t o ( s ) i t e r . # 1 i t e r . # 2 i t e r . # n i t e r . # n + 1 i t e r . # n + 2 i t e r . # m i t e r . # m + 1 I t e r a i o n s

45. Supporting Workflows of The Unified Process
The support workflows focus on the managerial aspects of information system development
3) Environment
Addresses tools and processes needs of developers

46. Software Project Management Plan
Once the client has signed off the specifications, detailed planning and estimating begins
We draw up the software project management plan, including
Cost estimate
Duration estimate
Deliverables
Milestones
Budget
This is the earliest possible time for the SPMP

47. Post delivery Maintenance
Post delivery maintenance is an essential component of software development
More money is spent on post delivery maintenance than on all other activities combined
Problems can be caused by
Lack of documentation of all kinds
Two types of testing are needed
Testing the changes made during post delivery maintenance
Regression testing
All previous test cases (and their expected outcomes) need to be retained

48. Retirement Software is can be unmaintainable because
A drastic change in design has occurred
The product must be implemented on a totally new hardware/operating system
Documentation is missing or inaccurate
Hardware is to be changed—it may be cheaper to rewrite the software from scratch than to modify it
These are instances of maintenance (rewriting of existing software)
True retirement is a rare event
It occurs when the client organization no longer needs the functionality provided by the product

49. What to Read…
Dean Leffingwell, Don Widrig, Managing Software Requirements, Addison-Wesley, 2000, 491p.
Alistair Cockburn, Writing Effective Use Cases, Addison-Wesley, 2001, 270p.
Alan W. Brown (ed.), Component-Based Software Engineering, IEEE Computer Society, Los Alamitos, CA, 1996, pp.140.
Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard, Object-Oriented Software Engineering-A Use Case Driven Approach, Wokingham, England, Addison-Wesley, 1992, 582p.

50. Recommended Reading
Applying UML and Patterns: An Introduction to OOA/D and the Unified Process, Prentice Hall, 2002, by G. Larman
The Rational Unified Process - An Introduction, Addison-Wesley Professional, 2002, by its lead architect Ph. Kruchten