Rational Unified Process (RUP)

From apppm
(Difference between revisions)
Jump to: navigation, search
Line 2: Line 2:
  
  
==History==
+
== Process Overview ==
This is the History
+
 
 +
=== The Phases===
 +
 
 +
==== Inception Phase ====
 +
 
 +
==== Elaboration Phase ====
 +
 
 +
==== Construction ====
 +
 
 +
==== Transition Phase ====
  
 
== Ten Essentials ==
 
== Ten Essentials ==
Line 26: Line 35:
 
=== Control changes to software ===
 
=== Control changes to software ===
  
== Process Overview ==
 
 
=== The Phases===
 
 
==== Inception Phase ====
 
 
==== Elaboration Phase ====
 
 
==== Construction ====
 
 
==== Transition Phase ====
 
  
 
== Limitations ==
 
== Limitations ==
  
 
== Conclusion ==
 
== Conclusion ==

Revision as of 12:42, 17 September 2015

The Rational Unified Process (RUP) is an iterative, software development methodology, firstly introduced by the Rational Software Corporation which was acquired by IBM in 2003. RUP is a disciplined approach to assign tasks within a development organization and software project teams. It was developed to ensure the production of high quality software by providing the development team with a set of guidelines, templates and tool mentors, for all the critical life-cycle activities within a project. This way, the deliverable software can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule. RUP is the most popular and extensively documented refinement of the Unified Process, an iterative and incremental software development process framework. Other worth mentioning forms are the OpenUP and Agile Unified Process.


Contents

Process Overview

The Phases

Inception Phase

Elaboration Phase

Construction

Transition Phase

Ten Essentials

Vision

Plan

Risks

Issues

Business Case

Architecture

Product

Evaluation

Change Requests

User Support

Best Practices

Develop Software iteratively

Manage requirements

Use component-based architectures

Visually model software

Continuously verify software quality

Control changes to software

Limitations

Conclusion

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox