I’m assuming that you are referring to Rational Unified Process as the software engineering process rather than the RUP product licensed from Rational Software.
The methodology, including the phases at which specific artifacts are initiated and completed is well documented in several texts, of particular note are The Rational Unified Process: An introduction by Phillippe Krutchen and The Rational Unified Process Made Easy: A Practioners Guide by Phillippe Krutchen and Per Knoll.
Many organisations make use of the RUP product as it offers a knowledge base, document templates, Microsoft Project plans and resource centre. However, the methodology can be adopted outside of the product use. To that end I’ve attempted to outline the main artifacts created and a brief description of what is contained within them. Please note that these are based solely on my use of RUP within organisations. Like any methodology unless a specific product is used it’s likely that there is significant variance between organisations and experiences.
Vision Document
This document should contain the general vision of the project, including the key requirements, features and identified constraints.
Use Case Model (the what)
In other project management methodologies you would consider this to be your requirements documentation.
RUP tries to reduce one of the more common failings of software development projects, the ‘this isn’t what we wanted’, by creating common language between developers and users. To this end, use-cases are defined, which represent the required behaviours from the system as defined by Actor’s needs. Actors in RUP represent users and systems which will interact with the system to be developed.
As with any project there will inevitably be a degree of trade-off, i.e. in order to deliver one use-case another must be dropped or amended. The full history of these amendments should be captured and documented within the Use Case Model.
The Use Case Model is very much a collaborative document with significant input from both development and Actor resources.
Business Case
As for any other project.
Risk Assessment
As for any other project.
Project Plan (the when and by who)
Aas for any other project. The level of granularity required will be entirely dependent upon the organisation. The plan may start as a phase plan indicating iterations only and major milestones before evolving into something more sophisticated at a later stage.
Prototypes
At various stages of the project, e.g. Inception and Construction it is likely that multiple prototypes will be produced.
Design Model (the how)
In other methodologies this could be named Solution Architecture of Design Overview.
The Design Model contains the concept of how the development will be designed. It is not actual source code. It will consist of a full breakdown of the proposed architecture in degrees of granularity e.g. The Design Model>Design Case>Design Classes> Design Packages>Components.
It is crucial that that each design case should be easily referenced back to the use-cases outlined in the Use Case Model.
Test Plan
As for any other project. The use-cases set out in the Use Case Model can be re-used to form the test plan.
Test Evaluation Summary
Containing the summary of the results of the Test Plan. Often split into Use Case results and Code Based results, comparative analysis based upon each iteration of development and trends identified should be presented and recommended actions.
User Manuals
Produced to transition the product from development to live.
Deployment Plan
As with any other project.
There are available templates out there, however, if an organisation is new to RUP then it may be worth establishing the methodology for development first and allowing the document templates to be established through trial and error using some online resources as a ‘starter for ten’ so to speak until you've found your feet.
