DTU ProjectLab - User contributions [en-gb]

Talk:Rational Unified Process (RUP)

2015-09-29T13:23:19Z

Lessisv: /* Reviewer 1, Damien */

Anna: I like the topic idea, remember to keep in mind that you need to showcase how this tool is relevant/useful for project/portfolio/program management.

===Reviewer 1, Damien===
The article has been accessed the 22/09/2015 at 4 p.m.

*Overall overview.
The presentation and the overall writing is very clear and clean. The article seems to be well organised and structured. It is also completed, more than 3000 words. Even without any knowledge of the subject, it becomes accessible through the article.

*Formal aspect.
No mistakes noticed, the vocabulary is very precise and the formal aspect of the Wiki seems to me perfectly mastered. The references and the links inside the article are well used in order to explain technical aspect through other pages.

*Schemas and photos
They are clearly identified and used in harmony within the text. Maybe more pictures should be introduced in order to break the monotony of the article.

*Links, connections and comprehension.
The article describes the subject in a cascade way, each part is clearly explained in a fall down structure leading to the use in management. So the choice structure makes perfect sense to me.

However, despite the great efficiency in term of explanation, the style can be quite repetitive in terms of reading. It may be corrected by introducing some personal comment, or practical example from times to times and when possible.

*Bibliography
The references seem to be very serious one.

However 4 references isn’t enough, and there is no explanation (yet) considering how each reference is relevant regarding the topic.

*Conclusion and advices:
From my very own point of view the subject is perfectly explained and presented. However I personally think that it may help to consider some practical examples of the use of the RUP, even if oversimplification is needed. It would make the article more alive in a way (possibility to introduce other picture etc.). The article described the use of RUP in management but doesn’t provide examples.

I understand the subject is complex and need a complete description in order to be fully understandable to the reader. Reducing the description or replacing some parts by concrete examples could still help for the comprehension.

The actual formal presentation is however perfectly acceptable.

'''Answer to reviewer 1'''
Dear Damien,
thank you very much for all your points. To me the most important ones were the missing references and some concrete examples of using the method. As far as the references are concerned, they have all been added. As you said the article was pretty extensive (a bit more than 3000 words) and i could not delete any of the parts to add a practical example (by doing so, i would have to delete important aspects of the method and it wouldn't make sense to the final reader). However, i added a '''Further Reading''' section where the reader can find such an example for better comprehension of the method.

‘’’Ana – Reviewer 2’’’
*I found this an interesting topic I did not know nothing about before. I really liked the start, it is good to have a definition when you are about to discover a new subject.

As I was blind in this matter it was a bit hard for me to read, there is “a lot of meat in that bone” but I have to admit that it is well structured event though it is quite long for the amount of information, it goes into much detail. I find useful the use of bullet points.

*Figures are useful and well use, they are referred in the text what make easier to follow the explanation.
The conclusion is brief and sums up the content of the article.

*I would have like to have links in the reference list to consult in case of doubts.

*I would have like to have examples of use in this article to make it easier to follow, I personally learn better with a “background story”, it seems more coherent for me in a complex topic like this.

*To conclude my feedback I have to say that this article looks accurate and good for expand knowledge.

'''Answer to reviewer 1'''
Dear Ana, thank you very much for your points. I added all the missing references as you suggested and i added a '''Further Reading''' section, where you can read a practical example of the method.

'''Reviewer username: s103128 (Martin Larsen) – Reviewer 1'''

Hello Author of Rational Unified Process! Wauv, what an outstanding article! I think you did an awesome job on this one.

-The introduction starts the article very well. In just a few lines, the origin and use of the method is covered and explained, even for someone, like me, with very little knowledge on the subject

-The subject seems very relevant, and the article follows the structure of a “method” article very well

-The process paragraph gives a good overview of what seems to be a complex process. I like the way it is done with bullet points, it gives a strong sense of linearity in the article.

-The use of figures support the text and arguments. Especially the figure describing the phases really improves understanding.

-Your language is correct, highly scientific and with very, very few errors. Awesome!

-Your link to project management is good, but maybe it should be emphasized a bit earlier, that this is a tool that can be used in the project/programme/portfoilio context? A line or two in the introduction would be sufficient.

-Remember to make the annotated bibliography for your sources, and I will recommend the use of the wiki reference system instead of a sub-section

-Your article has A LOT of headlines. Usually, I would consider many headlines with only limited amount of supporting text a bad thing. But I think, the subject and wiki format considered, you make it work. Just be careful that your points are not lost by having only a limited amount of “flowing” text. For instance the “deployment” sub-paragraph has very little supportive text, apart from the bullet points. It could be a bit more elaborated in text what is going on.

I must admit that I don’t have much else to critize you for, as I think you have written an excellent article. Good luck with your article!

/Martin

'''Answer to reviewer 3'''
Dear Martin, thank you very much for all your points! I added all the missing references and i also used the wiki reference system as you suggested. I agree that some parts may not contain a lot of supportive text, however i believe that these parts did not need any further explanation and the article was pretty extensive already(a bit more than 3000 words).

Talk:Rational Unified Process (RUP)

2015-09-29T13:19:15Z

Lessisv: /* Reviewer 1, Damien */

Talk:Rational Unified Process (RUP)

2015-09-29T13:17:20Z

Lessisv: /* Reviewer 1, Damien */

Anna: I like the topic idea, remember to keep in mind that you need to showcase how this tool is relevant/useful for project/portfolio/program management.

===Reviewer 1, Damien===
The article has been accessed the 22/09/2015 at 4 p.m.

*Overall overview.
The presentation and the overall writing is very clear and clean. The article seems to be well organised and structured. It is also completed, more than 3000 words. Even without any knowledge of the subject, it becomes accessible through the article.

*Formal aspect.
No mistakes noticed, the vocabulary is very precise and the formal aspect of the Wiki seems to me perfectly mastered. The references and the links inside the article are well used in order to explain technical aspect through other pages.

*Schemas and photos
They are clearly identified and used in harmony within the text. Maybe more pictures should be introduced in order to break the monotony of the article.

*Links, connections and comprehension.
The article describes the subject in a cascade way, each part is clearly explained in a fall down structure leading to the use in management. So the choice structure makes perfect sense to me.

However, despite the great efficiency in term of explanation, the style can be quite repetitive in terms of reading. It may be corrected by introducing some personal comment, or practical example from times to times and when possible.

*Bibliography
The references seem to be very serious one.

However 4 references isn’t enough, and there is no explanation (yet) considering how each reference is relevant regarding the topic.

*Conclusion and advices:
From my very own point of view the subject is perfectly explained and presented. However I personally think that it may help to consider some practical examples of the use of the RUP, even if oversimplification is needed. It would make the article more alive in a way (possibility to introduce other picture etc.). The article described the use of RUP in management but doesn’t provide examples.

I understand the subject is complex and need a complete description in order to be fully understandable to the reader. Reducing the description or replacing some parts by concrete examples could still help for the comprehension.

The actual formal presentation is however perfectly acceptable.

'''Answer to reviewer 1'''
Dear Damien,
thank you very much for all your points. To me the most important ones were the missing references and some concrete examples of using the method. As far as the references are concerned, they have all been added. As you said the article was pretty extensive (a bit more than 3000 words) and i could not delete any of the parts to add a practical example (by doing so, i would have to delete important aspects of the method and it wouldn't make sense to the final reader). However, i added a '''Further Reading''' section where the reader can find such an example for better comprehension of the method.

‘’’Ana – Reviewer 2’’’
*I found this an interesting topic I did not know nothing about before. I really liked the start, it is good to have a definition when you are about to discover a new subject.

As I was blind in this matter it was a bit hard for me to read, there is “a lot of meat in that bone” but I have to admit that it is well structured event though it is quite long for the amount of information, it goes into much detail. I find useful the use of bullet points.

*Figures are useful and well use, they are referred in the text what make easier to follow the explanation.
The conclusion is brief and sums up the content of the article.

*I would have like to have links in the reference list to consult in case of doubts.

*I would have like to have examples of use in this article to make it easier to follow, I personally learn better with a “background story”, it seems more coherent for me in a complex topic like this.

*To conclude my feedback I have to say that this article looks accurate and good for expand knowledge.

'''Reviewer username: s103128 (Martin Larsen) – Reviewer 1'''

Hello Author of Rational Unified Process! Wauv, what an outstanding article! I think you did an awesome job on this one.

-The introduction starts the article very well. In just a few lines, the origin and use of the method is covered and explained, even for someone, like me, with very little knowledge on the subject

-The subject seems very relevant, and the article follows the structure of a “method” article very well

-The process paragraph gives a good overview of what seems to be a complex process. I like the way it is done with bullet points, it gives a strong sense of linearity in the article.

-The use of figures support the text and arguments. Especially the figure describing the phases really improves understanding.

-Your language is correct, highly scientific and with very, very few errors. Awesome!

-Your link to project management is good, but maybe it should be emphasized a bit earlier, that this is a tool that can be used in the project/programme/portfoilio context? A line or two in the introduction would be sufficient.

-Remember to make the annotated bibliography for your sources, and I will recommend the use of the wiki reference system instead of a sub-section

-Your article has A LOT of headlines. Usually, I would consider many headlines with only limited amount of supporting text a bad thing. But I think, the subject and wiki format considered, you make it work. Just be careful that your points are not lost by having only a limited amount of “flowing” text. For instance the “deployment” sub-paragraph has very little supportive text, apart from the bullet points. It could be a bit more elaborated in text what is going on.

I must admit that I don’t have much else to critize you for, as I think you have written an excellent article. Good luck with your article!

/Martin

Talk:Rational Unified Process (RUP)

2015-09-29T13:16:36Z

Lessisv: /* Reviewer 1, Damien */

Anna: I like the topic idea, remember to keep in mind that you need to showcase how this tool is relevant/useful for project/portfolio/program management.

===Reviewer 1, Damien===
The article has been accessed the 22/09/2015 at 4 p.m.

*Overall overview.
The presentation and the overall writing is very clear and clean. The article seems to be well organised and structured. It is also completed, more than 3000 words. Even without any knowledge of the subject, it becomes accessible through the article.

*Formal aspect.
No mistakes noticed, the vocabulary is very precise and the formal aspect of the Wiki seems to me perfectly mastered. The references and the links inside the article are well used in order to explain technical aspect through other pages.

*Schemas and photos
They are clearly identified and used in harmony within the text. Maybe more pictures should be introduced in order to break the monotony of the article.

*Links, connections and comprehension.
The article describes the subject in a cascade way, each part is clearly explained in a fall down structure leading to the use in management. So the choice structure makes perfect sense to me.

However, despite the great efficiency in term of explanation, the style can be quite repetitive in terms of reading. It may be corrected by introducing some personal comment, or practical example from times to times and when possible.

*Bibliography
The references seem to be very serious one.

However 4 references isn’t enough, and there is no explanation (yet) considering how each reference is relevant regarding the topic.

*Conclusion and advices:
From my very own point of view the subject is perfectly explained and presented. However I personally think that it may help to consider some practical examples of the use of the RUP, even if oversimplification is needed. It would make the article more alive in a way (possibility to introduce other picture etc.). The article described the use of RUP in management but doesn’t provide examples.

I understand the subject is complex and need a complete description in order to be fully understandable to the reader. Reducing the description or replacing some parts by concrete examples could still help for the comprehension.

The actual formal presentation is however perfectly acceptable.

'''Answer to reviewer 1'''
Dear Damien,
thank you very much for all your points. To me the most important ones were the missing references and some concrete examples of using the method. As far as the references are concerned, they have all been added. As you said the article was pretty extensive (a bit more than 3000 words) and i could not delete any of the parts to add a practical example (by doing so, i would have to important aspects of the method and it wouldn't make sense to the final reader). However, i added a '''Further Reading''' section where the reader can find such an example for better comprehension of the method.

‘’’Ana – Reviewer 2’’’
*I found this an interesting topic I did not know nothing about before. I really liked the start, it is good to have a definition when you are about to discover a new subject.

As I was blind in this matter it was a bit hard for me to read, there is “a lot of meat in that bone” but I have to admit that it is well structured event though it is quite long for the amount of information, it goes into much detail. I find useful the use of bullet points.

*Figures are useful and well use, they are referred in the text what make easier to follow the explanation.
The conclusion is brief and sums up the content of the article.

*I would have like to have links in the reference list to consult in case of doubts.

*I would have like to have examples of use in this article to make it easier to follow, I personally learn better with a “background story”, it seems more coherent for me in a complex topic like this.

*To conclude my feedback I have to say that this article looks accurate and good for expand knowledge.

'''Reviewer username: s103128 (Martin Larsen) – Reviewer 1'''

Hello Author of Rational Unified Process! Wauv, what an outstanding article! I think you did an awesome job on this one.

-The introduction starts the article very well. In just a few lines, the origin and use of the method is covered and explained, even for someone, like me, with very little knowledge on the subject

-The subject seems very relevant, and the article follows the structure of a “method” article very well

-The process paragraph gives a good overview of what seems to be a complex process. I like the way it is done with bullet points, it gives a strong sense of linearity in the article.

-The use of figures support the text and arguments. Especially the figure describing the phases really improves understanding.

-Your language is correct, highly scientific and with very, very few errors. Awesome!

-Your link to project management is good, but maybe it should be emphasized a bit earlier, that this is a tool that can be used in the project/programme/portfoilio context? A line or two in the introduction would be sufficient.

-Remember to make the annotated bibliography for your sources, and I will recommend the use of the wiki reference system instead of a sub-section

-Your article has A LOT of headlines. Usually, I would consider many headlines with only limited amount of supporting text a bad thing. But I think, the subject and wiki format considered, you make it work. Just be careful that your points are not lost by having only a limited amount of “flowing” text. For instance the “deployment” sub-paragraph has very little supportive text, apart from the bullet points. It could be a bit more elaborated in text what is going on.

I must admit that I don’t have much else to critize you for, as I think you have written an excellent article. Good luck with your article!

/Martin

Rational Unified Process (RUP)

2015-09-28T23:55:13Z

Lessisv: /* Further Reading */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively <ref name="IBM (2005) Rational Unified Process"> IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational. </ref>. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective <ref name="RATIONALUNIVERSITY (2003) PRJ270">RATIONALUNIVERSITY (2003) PRJ270: Essentials of Rational Unified Process - Student Manual, IBM Corporation. </ref>.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model''' <ref name="KRUCHTEN, P.">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley</ref>. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved <ref name="Walker Royce">Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998. </ref>.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled. <ref name="Barry W. Boehm 2">Barry W. Boehm, A Spiral Model of Software Development and Enhancement, Computer, May 1988, IEEE, pp.61-72 </ref>

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs. <ref name="Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard">Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard, Object-Oriented Software Engineering—A Use Case Driven Approach, Wokingham, England, Addison-Wesley, 1992, 582p</ref>

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components. <ref name="Alan W. Brown (ed.)">Alan W. Brown (ed.), Component-Based Software Engineering, IEEE Computer Society, Los Alamitos, CA, 1996, pp.140.</ref>

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system. <ref name="Grady Booch, Ivar Jacobson, and James Rumbaugh">Grady Booch, Ivar Jacobson, and James Rumbaugh, Unified Modeling Language 1.3, White paper, Rational Software Corp., 1998</ref>

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== Further Reading ==
A [http://www.differnet.com/crose/CR_Files/CRose-RUPSample/RUPSample-CR1.pdf practical example] of using the Rational Unified Process.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-28T23:53:59Z

Lessisv:

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively <ref name="IBM (2005) Rational Unified Process"> IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational. </ref>. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective <ref name="RATIONALUNIVERSITY (2003) PRJ270">RATIONALUNIVERSITY (2003) PRJ270: Essentials of Rational Unified Process - Student Manual, IBM Corporation. </ref>.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model''' <ref name="KRUCHTEN, P.">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley</ref>. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved <ref name="Walker Royce">Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998. </ref>.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled. <ref name="Barry W. Boehm 2">Barry W. Boehm, A Spiral Model of Software Development and Enhancement, Computer, May 1988, IEEE, pp.61-72 </ref>

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs. <ref name="Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard">Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard, Object-Oriented Software Engineering—A Use Case Driven Approach, Wokingham, England, Addison-Wesley, 1992, 582p</ref>

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components. <ref name="Alan W. Brown (ed.)">Alan W. Brown (ed.), Component-Based Software Engineering, IEEE Computer Society, Los Alamitos, CA, 1996, pp.140.</ref>

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system. <ref name="Grady Booch, Ivar Jacobson, and James Rumbaugh">Grady Booch, Ivar Jacobson, and James Rumbaugh, Unified Modeling Language 1.3, White paper, Rational Software Corp., 1998</ref>

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== Further Reading ==
An [http://www.differnet.com/crose/CR_Files/CRose-RUPSample/RUPSample-CR1.pdf example] of using RUP

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T13:07:59Z

Lessisv: /* Visually model software */

Rational Unified Process (RUP)

2015-09-26T13:06:32Z

Lessisv: /* Use component-based architectures */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively <ref name="IBM (2005) Rational Unified Process"> IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational. </ref>. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective <ref name="RATIONALUNIVERSITY (2003) PRJ270">RATIONALUNIVERSITY (2003) PRJ270: Essentials of Rational Unified Process - Student Manual, IBM Corporation. </ref>.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model''' <ref name="KRUCHTEN, P.">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley</ref>. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved <ref name="Walker Royce">Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998. </ref>.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled. <ref name="Barry W. Boehm 2">Barry W. Boehm, A Spiral Model of Software Development and Enhancement, Computer, May 1988, IEEE, pp.61-72 </ref>

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs. <ref name="Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard">Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard, Object-Oriented Software Engineering—A Use Case Driven Approach, Wokingham, England, Addison-Wesley, 1992, 582p</ref>

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components. <ref name="Alan W. Brown (ed.)">Alan W. Brown (ed.), Component-Based Software Engineering, IEEE Computer Society, Los Alamitos, CA, 1996, pp.140.</ref>

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T13:05:01Z

Lessisv: /* Develop Software iteratively */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively <ref name="IBM (2005) Rational Unified Process"> IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational. </ref>. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective <ref name="RATIONALUNIVERSITY (2003) PRJ270">RATIONALUNIVERSITY (2003) PRJ270: Essentials of Rational Unified Process - Student Manual, IBM Corporation. </ref>.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model''' <ref name="KRUCHTEN, P.">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley</ref>. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved <ref name="Walker Royce">Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998. </ref>.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled. <ref name="Barry W. Boehm 2">Barry W. Boehm, A Spiral Model of Software Development and Enhancement, Computer, May 1988, IEEE, pp.61-72 </ref>

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs. <ref name="Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard">Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard, Object-Oriented Software Engineering—A Use Case Driven Approach, Wokingham, England, Addison-Wesley, 1992, 582p</ref>

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T13:04:34Z

Lessisv: /* Manage requirements */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively <ref name="IBM (2005) Rational Unified Process"> IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational. </ref>. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective <ref name="RATIONALUNIVERSITY (2003) PRJ270">RATIONALUNIVERSITY (2003) PRJ270: Essentials of Rational Unified Process - Student Manual, IBM Corporation. </ref>.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model''' <ref name="KRUCHTEN, P.">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley</ref>. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved <ref name="Walker Royce">Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998. </ref>.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled <ref name="Barry W. Boehm 2">Barry W. Boehm, A Spiral Model of Software Development and Enhancement, Computer, May 1988, IEEE, pp.61-72 </ref>.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs. <ref name="Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard">Ivar Jacobson, Magnus Christerson, Patrik Jonsson, and Gunnar Övergaard, Object-Oriented Software Engineering—A Use Case Driven Approach, Wokingham, England, Addison-Wesley, 1992, 582p</ref>

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T13:03:24Z

Lessisv: /* Develop Software iteratively */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively <ref name="IBM (2005) Rational Unified Process"> IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational. </ref>. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective <ref name="RATIONALUNIVERSITY (2003) PRJ270">RATIONALUNIVERSITY (2003) PRJ270: Essentials of Rational Unified Process - Student Manual, IBM Corporation. </ref>.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model''' <ref name="KRUCHTEN, P.">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley</ref>. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved <ref name="Walker Royce">Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998. </ref>.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled <ref name="Barry W. Boehm 2">Barry W. Boehm, A Spiral Model of Software Development and Enhancement, Computer, May 1988, IEEE, pp.61-72 </ref>.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T13:03:04Z

Lessisv: /* Develop Software iteratively */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively <ref name="IBM (2005) Rational Unified Process"> IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational. </ref>. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective <ref name="RATIONALUNIVERSITY (2003) PRJ270">RATIONALUNIVERSITY (2003) PRJ270: Essentials of Rational Unified Process - Student Manual, IBM Corporation. </ref>.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model''' <ref name="KRUCHTEN, P.">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley</ref>. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved <ref name="Walker Royce">Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998. </ref>.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled. <ref name="Barry W. Boehm 2">Barry W. Boehm, A Spiral Model of Software Development and Enhancement, Computer, May 1988, IEEE, pp.61-72 </ref>

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T13:01:32Z

Lessisv: /* Develop Software iteratively */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively <ref name="IBM (2005) Rational Unified Process"> IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational. </ref>. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective <ref name="RATIONALUNIVERSITY (2003) PRJ270">RATIONALUNIVERSITY (2003) PRJ270: Essentials of Rational Unified Process - Student Manual, IBM Corporation. </ref>.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model''' <ref name="KRUCHTEN, P.">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley</ref>. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved <ref name="Walker Royce">Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998. </ref>.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled. <ref name="Barry W. Boehm">Barry W. Boehm, A Spiral Model of Software Development and Enhancement, Computer, May 1988, IEEE, pp.61-72 </ref> <ref name="Barry W. Boehm 2">Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82.</ref>

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T13:01:07Z

Lessisv: /* Develop Software iteratively */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively <ref name="IBM (2005) Rational Unified Process"> IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational. </ref>. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective <ref name="RATIONALUNIVERSITY (2003) PRJ270">RATIONALUNIVERSITY (2003) PRJ270: Essentials of Rational Unified Process - Student Manual, IBM Corporation. </ref>.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model''' <ref name="KRUCHTEN, P.">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley</ref>. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved <ref name="Walker Royce">Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998. </ref>.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled. <ref name="Barry W. Boehm">Barry W. Boehm, A Spiral Model of Software Development and Enhancement, Computer, May 1988, IEEE, pp.61-72 </ref> <ref name="Barry W. Boehm">Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82.</ref>

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:55:47Z

Lessisv: /* Analysis and Design */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively <ref name="IBM (2005) Rational Unified Process"> IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational. </ref>. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective <ref name="RATIONALUNIVERSITY (2003) PRJ270">RATIONALUNIVERSITY (2003) PRJ270: Essentials of Rational Unified Process - Student Manual, IBM Corporation. </ref>.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model''' <ref name="KRUCHTEN, P.">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley</ref>. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved <ref name="Walker Royce">Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998. </ref>.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:51:57Z

Lessisv: /* Analysis and Design */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively <ref name="IBM (2005) Rational Unified Process"> IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational. </ref>. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective <ref name="RATIONALUNIVERSITY (2003) PRJ270">RATIONALUNIVERSITY (2003) PRJ270: Essentials of Rational Unified Process - Student Manual, IBM Corporation. </ref>.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model''' <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved <ref name="Walker Royce">Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998. </ref>.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:40:55Z

Lessisv: /* Workflow Dimension - Disciplines */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively <ref name="IBM (2005) Rational Unified Process"> IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational. </ref>. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective <ref name="RATIONALUNIVERSITY (2003) PRJ270">RATIONALUNIVERSITY (2003) PRJ270: Essentials of Rational Unified Process - Student Manual, IBM Corporation. </ref>.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved <ref name="Walker Royce">Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998. </ref>.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:39:09Z

Lessisv: /* Workflow Dimension - Disciplines */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively <ref name="IBM (2005) Rational Unified Process"> IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational. </ref>. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved <ref name="Walker Royce">Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998. </ref>.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:34:02Z

Lessisv: /* Project Management */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved <ref name="Walker Royce">Walker Royce, Software Project Management  A Unified Framework, Addison-Wesley, 1998. </ref>.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:32:07Z

Lessisv: /* Iterations */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN, P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:31:06Z

Lessisv: /* Iterations */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN, P."> KRUCHTEN,P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:30:25Z

Lessisv: /* Iterations */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process <ref name="KRUCHTEN,P."> KRUCHTEN,P. A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:26:23Z

Lessisv: /* Construction Phase */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:23:51Z

Lessisv: /* Construction Phase */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases <ref name="KRUCHTEN, P. (2000)">KRUCHTEN, P. (2000) The Rational Unified Process - An Introduction, Second Edition, Addison-Wesley.</ref>. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:17:58Z

Lessisv: /* Time Dimension - Phases and Iterations */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle <ref name="IBM (2003) The Rational Unified Process®">IBM (2003) The Rational Unified Process®, Version 2003.06.12.01, Rational Software Corporation.</ref>. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:15:21Z

Lessisv: /* Process Overview */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph <ref name="IBM (2005) Rational Unified Process">IBM (2005) Rational Unified Process – Best Practices for Software Development Teams. Rational Software White paper. Rational</ref>.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:11:56Z

Lessisv: /* Process Overview */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones <ref name="Barry W. Boehm">Barry W. Boehm, Anchoring the Software Process, IEEE Software, 13, 4, July 1996, pp. 73-82. </ref>.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:08:46Z

Lessisv: /* Process Overview */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases <ref name="Philippe Kruchten">A Rational Development Process, CrossTalk, 9 (7), STSC, Hill AFB, UT, pp.11-16.</ref>.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:07:03Z

Lessisv: /* References */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>

Rational Unified Process (RUP)

2015-09-26T12:06:45Z

Lessisv: /* References */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==
<references/>
1) Rational Unified Process vs Microsoft Solutions Framework : A comparative study, Johan W.A Traa 
2) Rational Unified Process: Best Practices for Software Development Teams, Rational Software white paper 
3) Planning a Project with the Rational Unified Process, David West 
4) Project Management Methodologies, Jason Charvat

Rational Unified Process (RUP)

2015-09-26T12:05:37Z

Lessisv:

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that can meet and exceed the needs and expectations of end-users, strictly following a predictable budget and schedule <ref name="Ivar Jacobson, Grady Booch, and Jim Rumbaugh">Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process, Addison-Wesley, 1999.</ref>. RUP is the most popular and extensively documented refinement of the [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==

1) Rational Unified Process vs Microsoft Solutions Framework : A comparative study, Johan W.A Traa 
2) Rational Unified Process: Best Practices for Software Development Teams, Rational Software white paper 
3) Planning a Project with the Rational Unified Process, David West 
4) Project Management Methodologies, Jason Charvat

Talk:Theory of Constraint

2015-09-22T23:24:42Z

Lessisv:

Josef: Jane, I like the idea. Make sure to stick to the structure we propose for "methods" articles. I am looking forward to reading about the application of TOC in project management!

===Reviewer 2, lessisv===

'''Overall overview'''.
By the time the review was made, there were not Wiki functions used or figures. The author provided a word document to
review instead. The topic is a really interesting one to look into and the article so far seems to deliver what is
expected.

'''Formal aspects.'''
The article presents some syntax, grammatical and typing errors, but since the article is not in its final form , i am sure that
the author will correct them. The figures look good and help illustrating what is written in text. However some of the tables
(presented in the word document) seem to hold a lot of information inside and are a bit difficult to read. When writing in wiki
it would be better if this information is presented in a cleaner way.

'''Content aspects.''' 
The article consists of 2200 words, so there is still room for additions, as far as the content is concerned. The author uses quiet
a few references, which make the whole article look really solid. I also liked that you looked at the topic from 2 different perspectives.
Your limitations section was a bit difficult to read - check your syntax.

''' Conclusion and advices.''' 
All in all an interesting article, although a shame that i could not read it through the wiki and see it in its full potential. As far as i
can tell this is not close to the final version as the syntax is a bit confusing in various parts among the article. While what you write looks
solid (always backed up with references), is a bit hard to follow your writing. I would suggest to make it a bit "easier in the eyes" so that
the reader does not lose interest.

==Reviewer 3, Damien==
This article was accessed the 22/09/2015 16:00

*Overall overview.
There are no Wiki functions used and no figures. However a word version was available for this review.
The amount of text doesn’t fulfil the 3000 words required, so addition have to be made in terms of content. The plan and the structure of the article allow a reader to fully understand the concept without specific prerequisite knowledge.

*Formal aspect:
Mistakes :

“an” => and in the Abstract

“ ) “ in 1.1 without “ ( “

“TOC in very process”

I’m quite sure it is “Six Sigma” instead of “Sex Sigma”.

I think that the referencing throughout the article is really well done. The flow of the article makes it quite easy to read overall, but some sentences should be shorter or rewritten for example :
“The rope is a signal generated by the constraint indicating that some CTs have been consumed which triggers the start for new CTs to be processed in the flow.”
Basically I think that some work on the syntax have to be done.
Finally I think the presentation is various and not too monotonous which is really great.

*Schemas and photos
I believe the tables furnished interesting content but gather a lot of text and could therefore be resumed or more precisely introduced.
The positioning of the figures and tables cannot be judge at this point but the word version seems great to me.

*Links, connections and comprehension.
The article describes step by step the methods while considering literature reference. I think that provides a simple and great comprehension of the topic.
The example is more than welcomed in the article, in order to complete the content, it may be a good idea to try to find another spot in order to introduce a practical example of how TOC can be used in a project ( even if it is necessary to oversimplify a situation).

*Bibliography
The references seem to be very serious one.
The number of references is satisfying at this point, simply remember to explain for each one how it is relevant to the topic and why it should be consulted by the reader.

*Conclusion and advices:
The subject is fully treated and well presented with a reduced amount of words, therefore it could be great to add more content regarding the possible extension or future development of the methods, original applications or your own point of view well argued.
On the other hand, adding more examples in order to make the theory more accessible and visible can, I think, also be a great option. It could also clarify the connection with program, project or portfolio management.
Of course, the translation from Word to Wiki has to be done properly in order to ensure a good visibility for the article.

Talk:Benchmarking in Project Management

2015-09-22T22:31:24Z

Lessisv: /* Reviewer 3, lessisv */

Anna: Just a few pointers for you article: It is very important that you keep you focus on the tool/method itself and that you really relate it properly to the overall topic of project management. The article you are making should be a contribution that others can read if they ever need this specific tool when managing a project. So maybe focus more on the use of benchmarking within project management and a little less on the overall use of benchmarking in the external/internal environment of a company.

Reviewer 1, S997303
Hi Dimak

• Benchmarking is a very interesting topic, and it seems a bit difficult to structure, but I think you do it nicely and according to the requirements for the method article.

• Your point 2.2 is very fine and I think it is relevant to describe the development. I like your figure 2 with benchmarking generations, but the figure could be more readable, especially if you print out the article the figure is blurred.

• Also Figure 4 could be a little bigger and clearer, especially because I am curious to read the benchmarking parameters in the score card chart.

• In section 3 I could suggest you to consider creating a table listing different phases in project management and the benchmarking tools to be recommended in the different phases. This could provide the reader with an overview of how to use benchmarking in different PM phases.

• In section 3.1 I have a question because I am not 100% clear if “Iron triangle” and “Square Root” are tools which are used for benchmarking today, or if you are actually suggesting to consider to use these as benchmarking tools if adapted to PM.

• The content of your article in very interesting and you guide your reader, however, you could consider tightening up your writing style a little bit to make the text a little shorter and more precise. E.g. in section two you have a sentence of 54 words.

• I miss the listing of all the references you refer to, but I am sure you have overseen this being under time pressure. Also remember annotations.

Good luck with the completion of your article.
Jane

===Reviewer 3, lessisv===

'''Overall overview'''.
This is a very interesting topic and the article totally succeeds in presenting it in a very clear and straightforward
way to the reader.

'''Formal aspects.'''
The writing is very clean, and precise vocabulary is used. All figures make sense and are well explained through the
text.

'''Content aspects.'''
The article clearly relates to project management and in fact dedicates a whole section on it "Benchmarking in Project Management". It takes full advantage of the word limit (3000 words) and the content is presented in a very logical way. Excellent use of references throughout the article. I also really liked the detailed '''Limitations''' section as it is very important for the reader not only to understand what a method can do, but also when is not advised to use.

''' Conclusion and advices.'''
All in all a well structured article, giving the reader to understand the topic in a very satisfactory depth. My only advice would be to maybe use bullet points to better illustrate some parts. For example after Figure 3, when talking about the different phases that benchmarking could be applied, it would be cleaner for the reader to have it presented
through bullet points.
eg.
*Early on benchmarking
*Benchmarking during project execution
*Post-project benchmarking

Talk:Benchmarking in Project Management

2015-09-22T21:29:05Z

Lessisv: /* Reviewer 3, lessisv */

Anna: Just a few pointers for you article: It is very important that you keep you focus on the tool/method itself and that you really relate it properly to the overall topic of project management. The article you are making should be a contribution that others can read if they ever need this specific tool when managing a project. So maybe focus more on the use of benchmarking within project management and a little less on the overall use of benchmarking in the external/internal environment of a company.

Reviewer 1, S997303
Hi Dimak

• Benchmarking is a very interesting topic, and it seems a bit difficult to structure, but I think you do it nicely and according to the requirements for the method article.

• Your point 2.2 is very fine and I think it is relevant to describe the development. I like your figure 2 with benchmarking generations, but the figure could be more readable, especially if you print out the article the figure is blurred.

• Also Figure 4 could be a little bigger and clearer, especially because I am curious to read the benchmarking parameters in the score card chart.

• In section 3 I could suggest you to consider creating a table listing different phases in project management and the benchmarking tools to be recommended in the different phases. This could provide the reader with an overview of how to use benchmarking in different PM phases.

• In section 3.1 I have a question because I am not 100% clear if “Iron triangle” and “Square Root” are tools which are used for benchmarking today, or if you are actually suggesting to consider to use these as benchmarking tools if adapted to PM.

• The content of your article in very interesting and you guide your reader, however, you could consider tightening up your writing style a little bit to make the text a little shorter and more precise. E.g. in section two you have a sentence of 54 words.

• I miss the listing of all the references you refer to, but I am sure you have overseen this being under time pressure. Also remember annotations.

Good luck with the completion of your article.
Jane

===Reviewer 3, lessisv===

'''Overall overview'''.
This is a very interesting topic and the article totally succeeds in presenting it in a very clear and straightforward
way to the reader.

'''Formal aspects.'''
The writing is very clean, and precise vocabulary is used. All figures make sense and are well explained through the
text.

'''Content aspects.'''
The article clearly relates to project management and in fact dedicates a whole section on it "Benchmarking in Project Management". It takes full advantage of the word limit (3000 words) and the content is presented in a very logical way. Excellent use of references throughout the article. I also really liked the detailed '''Limitations''' section as it is very important for the reader not only to understand what a method can do, but also when is not advised to use.

''' Conclusion and advices.'''
All in all a well structured article, giving the reader to understand the topic in a satisfactory depth. My only advice would be to maybe use bullet points to better illustrate some parts. For example after Figure 3, when talking about the different phases that benchmarking could be applied, it would be cleaner for the reader to have it presented
through bullet points.
eg.
*Early on benchmarking
*Benchmarking during project execution
*Post-project benchmarking

Talk:Benchmarking in Project Management

2015-09-22T21:28:27Z

Lessisv:

Anna: Just a few pointers for you article: It is very important that you keep you focus on the tool/method itself and that you really relate it properly to the overall topic of project management. The article you are making should be a contribution that others can read if they ever need this specific tool when managing a project. So maybe focus more on the use of benchmarking within project management and a little less on the overall use of benchmarking in the external/internal environment of a company.

Reviewer 1, S997303
Hi Dimak

• Benchmarking is a very interesting topic, and it seems a bit difficult to structure, but I think you do it nicely and according to the requirements for the method article.

• Your point 2.2 is very fine and I think it is relevant to describe the development. I like your figure 2 with benchmarking generations, but the figure could be more readable, especially if you print out the article the figure is blurred.

• Also Figure 4 could be a little bigger and clearer, especially because I am curious to read the benchmarking parameters in the score card chart.

• In section 3 I could suggest you to consider creating a table listing different phases in project management and the benchmarking tools to be recommended in the different phases. This could provide the reader with an overview of how to use benchmarking in different PM phases.

• In section 3.1 I have a question because I am not 100% clear if “Iron triangle” and “Square Root” are tools which are used for benchmarking today, or if you are actually suggesting to consider to use these as benchmarking tools if adapted to PM.

• The content of your article in very interesting and you guide your reader, however, you could consider tightening up your writing style a little bit to make the text a little shorter and more precise. E.g. in section two you have a sentence of 54 words.

• I miss the listing of all the references you refer to, but I am sure you have overseen this being under time pressure. Also remember annotations.

Good luck with the completion of your article.
Jane

===Reviewer 3, lessisv===

'''Overall overview'''.
This is a very interesting topic and the article totally succeeds in presenting it in a very clear and straightforward
way to the reader.

'''Formal aspects.'''
The writing is very clean, and precise vocabulary is used. All figures make sense and are well explained through the
text.

'''Content aspects.'''
The article clearly relates to project management and in fact dedicates a whole section on it "Benchmarking in Project Management". I takes full advantage of the word limit (3000 words) and the content is presented in a very logical way. Excellent use of references throughout the article. I also really liked the detailed '''Limitations''' section as it is very important for the reader not only to understand what a method can do, but also when is not advised to use.

''' Conclusion and advices.'''
All in all a well structured article, giving the reader to understand the topic in a satisfactory depth. My only advice would be to maybe use bullet points to better illustrate some parts. For example after Figure 3, when talking about the different phases that benchmarking could be applied, it would be cleaner for the reader to have it presented
through bullet points.
eg.
*Early on benchmarking
*Benchmarking during project execution
*Post-project benchmarking

Rational Unified Process (RUP)

2015-09-22T15:18:11Z

Lessisv: /* Requirements */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end - users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==

1) Rational Unified Process vs Microsoft Solutions Framework : A comparative study, Johan W.A Traa 
2) Rational Unified Process: Best Practices for Software Development Teams, Rational Software white paper 
3) Planning a Project with the Rational Unified Process, David West 
4) Project Management Methodologies, Jason Charvat

Rational Unified Process (RUP)

2015-09-22T15:16:06Z

Lessisv: /* Iterations */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover, change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==

1) Rational Unified Process vs Microsoft Solutions Framework : A comparative study, Johan W.A Traa 
2) Rational Unified Process: Best Practices for Software Development Teams, Rational Software white paper 
3) Planning a Project with the Rational Unified Process, David West 
4) Project Management Methodologies, Jason Charvat

Rational Unified Process (RUP)

2015-09-22T15:13:51Z

Lessisv: /* Elaboration Phase */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype, is to address the critical use-cases that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==

1) Rational Unified Process vs Microsoft Solutions Framework : A comparative study, Johan W.A Traa 
2) Rational Unified Process: Best Practices for Software Development Teams, Rational Software white paper 
3) Planning a Project with the Rational Unified Process, David West 
4) Project Management Methodologies, Jason Charvat

Rational Unified Process (RUP)

2015-09-22T08:14:00Z

Lessisv: /* Visually model software */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype is to address the critical use-cases, that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the [http://www.uml.org/ Unified Modelling Language (UML)] standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==

1) Rational Unified Process vs Microsoft Solutions Framework : A comparative study, Johan W.A Traa 
2) Rational Unified Process: Best Practices for Software Development Teams, Rational Software white paper 
3) Planning a Project with the Rational Unified Process, David West 
4) Project Management Methodologies, Jason Charvat

Rational Unified Process (RUP)

2015-09-22T08:13:12Z

Lessisv: /* References */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype is to address the critical use-cases, that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the Unified Modelling Language (UML) standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==

1) Rational Unified Process vs Microsoft Solutions Framework : A comparative study, Johan W.A Traa 
2) Rational Unified Process: Best Practices for Software Development Teams, Rational Software white paper 
3) Planning a Project with the Rational Unified Process, David West 
4) Project Management Methodologies, Jason Charvat

Rational Unified Process (RUP)

2015-09-22T08:12:53Z

Lessisv: /* References */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype is to address the critical use-cases, that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the Unified Modelling Language (UML) standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==

1) Rational Unified Process vs Microsoft Solutions Framework : A comparative study, Johan W.A Traa 
2) Rational Unified Process: Best Practices for Software Development Teams, Rational Software white paper
3) Planning a Project with the Rational Unified Process, David West
4) Project Management Methodologies, Jason Charvat

Rational Unified Process (RUP)

2015-09-22T08:12:08Z

Lessisv: /* References */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype is to address the critical use-cases, that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the Unified Modelling Language (UML) standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==

1) Rational Unified Process vs Microsoft Solutions Framework : A comparative study, Johan W.A Traa
2) Rational Unified Process: Best Practices for Software Development Teams, Rational Software white paper
3) Planning a Project with the Rational Unified Process, David West
4) Project Management Methodologies, Jason Charvat

Rational Unified Process (RUP)

2015-09-22T08:06:38Z

Lessisv:

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype is to address the critical use-cases, that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the Unified Modelling Language (UML) standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

== References ==

Rational Unified Process (RUP)

2015-09-22T08:06:14Z

Lessisv: /* Workflow Dimension - Disciplines */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype is to address the critical use-cases, that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the Unified Modelling Language (UML) standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

Rational Unified Process (RUP)

2015-09-22T08:05:06Z

Lessisv: /* Conclusion */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype is to address the critical use-cases, that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. The relationships between the role, activity and artifact is shown in Figure 3. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the Unified Modelling Language (UML) standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

The Rational Unified Process, is an exemplary method for addressing and mitigating risks from the very early stages, by rapidly developing an initial version of the system (prototype) that describes its architecture. There are not fixed requirements from the beginning but rather allows refining requirements , while the project progresses. It expects and actually deals with change pretty well while its main focus is the quality of the product and the degree to which it satisfies its end - users, throughout the project life-cycle. However, while being a complete and well documented methodology, it should be stressed that remains a very complex one. In order to increase the likelihood of success, while adopting this methodology, all the project members need to be '''experts''' in their respective fields. The method can easily become too difficult to learn and most importantly too difficult to apply.

Rational Unified Process (RUP)

2015-09-22T07:52:21Z

Lessisv: /* Limitations */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype is to address the critical use-cases, that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. The relationships between the role, activity and artifact is shown in Figure 3. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the Unified Modelling Language (UML) standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

Rational Unified Process (RUP)

2015-09-22T07:51:46Z

Lessisv: /* Limitations */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype is to address the critical use-cases, that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. The relationships between the role, activity and artifact is shown in Figure 3. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the Unified Modelling Language (UML) standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

While being a complete methodology in itself with an emphasis on accurate documentation and quickly resolving project associated risks, RUP comes with a number of limitations.

* In order for team members to start developing software under this methodology, they need to be '''experts''' in their respective fields.
* The development process can easily become too complex to handle.
* When working with cutting - edge projects, that highly utilize new technology, components will not be able to be reused.
* While in theory integration throughout the process of software development sounds like a good thing, when working with particularly complex projects with multiple development streams, issues and significant confusion may rise during the stages of testing.

== Conclusion ==

Rational Unified Process (RUP)

2015-09-22T07:27:11Z

Lessisv: /* Control changes to software */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype is to address the critical use-cases, that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. The relationships between the role, activity and artifact is shown in Figure 3. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the Unified Modelling Language (UML) standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

A software system is developed by a number of teams or individuals, using different platforms and at times being in different locations. As a result, it is essential to somehow make sure that all the changes made in the system are synchronized and constantly verified. RUP ensures that all the individuals working in the project are well informed about any changes and everything is in sync. The process describes how to control, track and monitor changes to enable successful iterative development.

== Limitations ==

== Conclusion ==

Rational Unified Process (RUP)

2015-09-22T07:14:32Z

Lessisv: /* Continuously verify software quality */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype is to address the critical use-cases, that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. The relationships between the role, activity and artifact is shown in Figure 3. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the Unified Modelling Language (UML) standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===

In software development, quality should always be reviewed with respect to the requirements based on reliability, functionality , application and system performance. In RUP, quality verification and assessment is built into the process, inside all activities, including all stakeholders and is not treated as a separate activity, performed by a separate group.

=== Control changes to software ===

== Limitations ==

== Conclusion ==

Rational Unified Process (RUP)

2015-09-22T06:56:00Z

Lessisv: /* Visually model software */

The '''Rational Unified Process (RUP)''' is an iterative, '''software development methodology''', firstly introduced by the [https://en.wikipedia.org/wiki/Rational_Software Rational Software Corporation] which was [http://www-03.ibm.com/press/us/en/pressrelease/314.wss 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 cluster of objects, form a knowledge base that is shared between all project team members. As a result, no matter what each member is working with (e.g testing, designing, managing), they all share a common language and view on how to develop software. Consequently, team productivity is boosted, in order to deliver software that 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 [https://en.wikipedia.org/wiki/Unified_Process Unified Process], an iterative and incremental software development process framework. Other worth mentioning forms are the [https://en.wikipedia.org/wiki/OpenUP OpenUP] and [https://en.wikipedia.org/wiki/Agile_Unified_Process Agile Unified Process].

== Process Overview ==

[[File:RUP.png|450px|right|thumb| Figure 1. The iterative model graph shows how the process is structured along two dimensions]]

The best possible way to describe the methodology is through a 2 - dimensional graph.
* The first dimension (horizontal axis) represents the '''dynamic aspect''' of the process. It expresses '''time''' in terms of '''phases''' and '''iterations'''.
* The second dimension (vertical axis) represents the '''static aspect''' of the process. It expresses '''workflows''' in terms of 6 core and 3 supporting '''disciplines''' (more on that on "Disciplines" section).

=== Time Dimension - Phases and Iterations ===
When developing software, the project team goes through a multi-step process, from establishing a system's requirements to designing, implementing and finally maintaining the software with new releases. This is the software life cycle. RUP delicately breaks the software life cycle down to four consecutive phases.

* Inception phase
* Elaboration phase
* Construction phase
* Transition phase

Depending on the project, each of these phases can consist of one to a number of '''iterations'''. An iteration is defined as a complete development loop, resulting in a new product release. All the phases include a well-defined milestone, in order to be completed. In the end of every phase, the development team can evaluate whether all the key goals have been achieved, all stakeholders have been considered and the actual expenditures correspond with the planned ones.

[[File:RUP_phases.png|550px|right|thumb| Figure 2. The four phases and milestones of a project]]
==== Inception Phase ====
The first phase is the inception phase. The focus of this phase, is understanding the scope of the project and studying if is both worth doing and possible to do. All the internal and external entities that the system will interact with are identified and the nature of the interaction is well defined at a high level. For this reason, the inception phase is primarily significant for new development projects.
The expected outcome of the inception phase includes :

* A vision document: The document states the general vision of the project including its key requirements, features and main constraints.
* An initial use-case model (10%-20% complete)
* An initial project glossary
* An initial business case, including the business context, success criteria and a financial forecast.
* An initial risk assessment
* A project plan (phases and iterations)
* A business model (if necessary)
* Prototypes

At the end of the inception phase lies the first major project milestone; the '''Lifecycle Objective Milestone'''.
The inception phase has five evaluation criteria:

* Stakeholder concurrence on scope definition and cost/schedule estimates.
* Depth and breadth of any prototype that was developed.
* Actual expenditures versus planned ones.
* Requirements understanding.
* Credibility of the cost/schedule estimates, risks and priorities.

If for any reason the project fails to pass this milestone, it can either be completely cancelled or re-designed to successfully meet the criteria.

==== Elaboration Phase ====
The second phase is the elaboration phase. The focus of this phase, is establishing a baseline to the architecture of the system, further developing the project plan and analyzing the problem domain while trying to mitigate the highest risk elements. In other words, this is the phase where the project starts to take shape. One of the most important characteristics of this phase, is the production of a component-based architectural prototype. The purpose of this prototype is to address the critical use-cases, that were identified in the previous phase, and hopefully expose the highest technical risks of the project. The expected outcome of the elaboration phase includes:

* A use-case model (at least 80% complete) which will be able to identify all the actors and use-cases.
* Supplementary requirements (if any).
* A clear description of the software architecture.
* An architectural prototype.
* A more detailed risk assessment and business case.
* A development plan for the overall project.
* A preliminary user manual (optional).

At the end of the elaboration phase lies the second major project milestone; the '''Lifecycle Architecture Milestone'''.
The elaboration phase has six evaluation criteria:

* Is the vision stable enough?
* Is the system architecture stable enough?
* Have all the major risks been successfully identified and resolved?
* Is the plan for the construction phase accurate enough?
* Do all the stakeholders share the opinion that the vision can be achieved by executing the current plan?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass the milestone, there is still time to be re-designed or even cancelled. However, when the project moves to the next phase the associated operation risks raise significantly and changes become much more difficult.

==== Construction Phase====
The third phase is the construction phase. The focus of this phase, is to develop and integrate all the remaining components and application features into the product. In other words this is the phase where the vision is finally translated into a final stable product, which is based on the architecture that was developed during the previous phases. Most emphasize is given to resources, control and process management in order to fully optimize costs, schedules and quality. The existing prototype evolves via a number of iterations into a fully functional product that meets the stakeholders' needs. The construction phase is usually the longest one of the project life cycle. The expected outcome of the construction phase includes:

* First external release of the software.
* User manuals.
* A detailed description of the current release.

At the end of the construction phase lies the third major project milestone; the '''Initial Operation Capability Milestone'''.
The construction phase has three evaluation criteria:

* Is the software release stable enough to be given to the user community?
* Are all the stakeholders ready for the transition to the user community?
* Is the actual vs planned resource expenditure in acceptable levels?

If the project fails to pass this milestone, transition may have to be postponed by one release.

==== Transition Phase ====
The fourth and final phase is the transition phase. The focus of this phase is, as the word says, to transition the software product to the user community. It includes ensuring that the product has been developed to an acceptable quality level, by beta testing the software through the end users, and validating it against the stakeholders' expectations. Once the product has been given for beta testing, a number of issues can arise, requiring the development of new releases (fixing bugs) and adding features that may have been postponed. The expected outcome of the transition phase includes:

* Beta-testing to fix any major [https://en.wikipedia.org/wiki/Software_bug software bugs] and add any missing features.
* Conversion of operational databases
* Training of end users and maintainers.
* Marketing and distribution of the product.

At the end of the transition phase lies the fourth and final major project milestone; the '''Product Release'''.
The transition phase has two evaluation criteria:

* Are the end - users satisfied with the product?
* Is the actual vs planned resource expenditure in acceptable levels?

==== Iterations ====
As stated before, every phase can consist of a number of iterations, depending on the project size and scope. RUP, in comparison to the traditional [https://en.wikipedia.org/wiki/Waterfall_model waterfall] approach, is heavily based on iterations. This gives a number of advantages and benefits to the project team, with the most important one being mitigating risks much more earlier in the project. Moreover change is more manageable and there is normally a higher level of reuse. Finally, iterations ensure an overall high quality in the final product and that the project team can learn throughout the developing process.

=== Workflow Dimension - Disciplines ===

[[File:activities.png|350px|right|thumb| Figure 4. Individuals, Roles and Activities]]
[[File:workflows.png|350px|right|thumb| Figure 5. Example of a workflow]]

A process describes '''who''' is doing '''what''', '''how''' and '''when'''. RUP addresses those terms with four modelling elements; '''Roles''', '''Activities''', '''Artifacts''' and '''Workflows''' respectively. The relationships between the role, activity and artifact is shown in Figure 3. A '''role''', formally addressed as a worker, describes the behavior and responsibilities of an individual or a group of individuals in order to produce an artifact. Throughout the development of a project, a person can play one or a number of roles. Some examples of roles are the system analyst, designer, tester. '''Activities''' are expressed through behaviors. An activity, is a job that a person performs through his role, as seen in Figure 4. The length of an activity may vary from a few hours to a number of days. Examples of activities are: Plan an operation - performed by the role of Project Manager or add a missing feature - performed by the role of a software developer. All activities produce a meaningful result, called an artifact. '''Artifacts''', are the responsibilities of ones role or roles and express a piece of information that is produced, modified or even used by a process. They can act both as input or output of an activity. Examples of artifacts are the source code, the business case, the software architecture. The roles perform activities that can produce a sequence of artifacts, called '''workflows'''. Examples of workflows can be seen in Figure 5.

RUP identifies nine core process workflows, called '''disciplines'''. Every discipline, addresses a set of activities and artifacts, based upon a set of skills that are common in an ICT project. These disciplines have the ability to arrange the activities and artifacts in such a way, to provide an understanding of the overall project from a waterfall perspective.

There are six core "engineering" disciplines:
* Business Modelling Discipline
* Requirements Discipline
* Analysis and Design Discipline
* Implementation Discipline
* Test Discipline
* Deployment Discipline

And three core "supporting" disciplines:
* Project Management Discipline
* Configuration and Change Management Discipline
* Environment Discipline

==== Business Modelling ====

Miscommunication between the software engineering community and the business engineering community is one of the most common problems among most business engineering efforts. This means that the output from software development efforts is not correctly used as input to the business engineering and vice versa. The purpose of the Business Modelling discipline is to provide a common language between the two communities and create a direct coupling between software and business models. All business processes are documented using "use cases". This assures that all stakeholders share the same understanding of the demanding organization.

==== Requirements ====
The purpose of the requirements discipline is to describe in detail '''what''' the system should do. Based on that, a Vision document is created where required functionality and constraints are documented. Moreover, actors (end users) and use cases (behaviors of the system) are identified. Use cases are described in detail and each description clearly shows how the system interacts with the actors. This way an agreement is established between the customers and the rest of the stakeholders regarding the system's capabilities, user-interface and the end user's needs.

==== Analysis and Design ====

The purpose of the Analysis and Design discipline it to investigate '''how''' the system requirements will be translated into a detailed implementation plan. The system needs to:
* Perform exactly as described in the use-case descriptions.
* Fulfill all requirements.
* Have a robust structure.

Analysis and Design result in the creation of a '''design model'''. The design model is an abstraction of the system's architecture and acts as a guide of how the source code should be finally written and structured.

==== Implementation ====
The purpose of the Implementation discipline is to:

* Arrange the code into subsystems, organized in layers.
* Implement classes and objects in terms of components.
* Uni-test the developed components to ensure quality.
* Integrate the results into an executable system.

The whole system can be realized as an implementation of various components. RUP enables the integration of those components, in a revolutionary way, making the system easier to maintain and increasing the possibilities for future re-use.

==== Test ====

In the implementation discipline, all the developed components were uni-tested individually and were integrated into the system. The purpose of the Test discipline is to assess the system as a whole and verify the product quality. It is a mechanism to verify the smooth interaction between the various components, their proper integration into the system and finally ensure that all requirements have been successfully implemented. All tests are carried out along 4 quality dimensions:
* Functionality.
* Reliability.
* Application Performance.
* System Performance.

==== Deployment ====

The purpose of the Deployment discipline is primarily to develop product releases and distribute the software to the end – users. More specifically the Deployment discipline focuses at:

* Developing external software releases
* Distributing the software
* Installing the software
* Providing help to the end – users
* Creating an up-to-date user manual
* Conducting beta testing

==== Project Management ====

The purpose of the Project Management discipline, is to successfully balance competing objectives, manage and mitigate risks and finally handle any constraints on delivering the product. Project management, ideally provides:

* A framework for managing software-intensive projects.
* A framework to successfully manage risks.
* A framework to plan, execute and monitor projects.

While the discipline does not guarantee success, the odds of delivering successful software are greatly improved.

==== Configuration and Change Management ====

The purpose of the Configuration and Change Management Discipline is to control, maintain and configure all the various artifacts that are produced by the different actors that are working on a project. During the software development life cycle, artifacts are regularly updated (changed). In order to understand the current state of an artifact, it is very important to keep track of its location and history; what was the reason and who decided to change the artifact. The discipline helps create a framework that keeps track of all the project assets.

==== Environment ====

The purpose of the environment discipline, is to provide the development team with all the processes, tools and methods for supporting all developing activities. It is responsible for producing a Development Kit, able to provide guidelines and templates for customizing processes.

== Why RUP - Best Practices ==

RUP captures many of the “best practices” that are currently used in modern software development and more particularly in industry by successful organizations. The practices are:

* Develop Software Iteratively
* Manage Requirements
* Use component-based architectures
* Visually model software
* Continuously verify software quality
* Control changes to software

=== Develop Software iteratively ===

Today’s high sophisticated software systems, consist of many and complex structures which make it nearly impossible to define the entire system from the very beginning, develop the entire solution and then test the product in the end. RUP uses an iterative approach that allows an increasing understanding of the problem and developing a step – by – step solution, over multiple iterations. Each iteration ends with an executable release, which enables continuous end - user involvement and feedback. As a result, the risks of the project are mitigated at an early stage and stakeholders are ensured that the project requirements are fulfilled.

=== Manage requirements ===

The requirements of a system include the description of the services that the system is able to provide and its operational constraints. RUP documents, organizes and tracks required functionality and constraints and easily communicates business requirements. The use – cases that are used in the process are an excellent way to ensure that requirements are actually those elements that drive the design, implementation and testing of software, making it more likely that the final system fulfills the stakeholders needs.

=== Use component-based architectures ===

Component-based architecture makes the system dynamic; components are independent from the system and interact with other components through well-defined interfaces. Their in-dependency from the system, gives them a great flexibility meaning that they can easily be added, updated or totally replaced. RUP supports component-based software development by providing a systematic approach to defining an architecture using new and existing components.

=== Visually model software ===

A model is an abstraction of reality that can help better comprehend large and complex systems. Visual abstractions help the development team to easily communicate different aspects of the software and see how all the components fit together. RUP uses the Unified Modelling Language (UML) standard which is a graphical language for visualizing and constructing the artifacts of a software-intensive system.

=== Continuously verify software quality ===
=== Control changes to software ===

== Limitations ==

== Conclusion ==