The Rational Unified Process is a software engineering process developed and marketed by Rational Software. The RUP captures many of the best practices in modern software development and is suitable for a wide range of projects. This methodology is highly recommended for producing high quality software within time and budget constraints.
This method may be used for large or small teams, and may be modified to incorporate agile type methodologies. If you have a small team and want to use a flexible yet proven methodology, please read the book listed below "Software Development for Small Teams: A RUP-Centric Approach".
Even though this methodology is marketed by a commercial company in the form of their modelling software you do not need to purchase their product in order to use the methodology. There are many excellent books (see below) that describe this methodology in detail that you can use to guide your project.
The RUP says that you should use the following best practices in an interative manner to best manage your software project.
In the past managers used a waterfall or sequential process to create software. This process usually fails because the wrong assumptions were made initially or the requirements changed during the time we were coding the software. The RUP suggests an iterative waterfall process where requirements, design, implementation, and test are repeated over and over in small steps. This allows you to learn and make changes as the software is created.
What does RUP say about writing requirements?
When using RUP you should write requirements as described in our Requirements section, however RUP wants you to do this iteratively. Don't try and capture all the requirements at once up front. Concentrate on what you know and try to capture the big overall requirements that will affect your central design.
For example, does your software application need to run on several different computers with different operating systems and does it need to be accessed by remote users? Capturing these big overall system requirements up front is critical. Discovering that remote users cannot access your application after it is 80% complete is very costly.
After you have completed the initial RUP cycle, go back and dig deeper into what the stakeholders want and modify and add to your requirements document. Then implement these requirements in another RUP cycle. Keep doing this until you have the final product.
What does RUP say about design and modeling?
Follow what is described on the Software design and modeling. page but again do this iteratively. Create a UML design for a subset of the entire problem. This design should address the small set of requirements captured as described above.
Usually the design describes one horizontal pass through the software application. Once this has been implemented and tested, go back and add to the design to fill out more functionality.
For more information about the Rational Unified Process please refer to the following:
The Rational Unified Process: An Introduction, Third Edition by Philippe Kruchten (Paperback - Dec 19, 2003)
The Rational Unified Process Made Easy: A Practitioner's Guide to Rational Unified Process by Per Kroll and Philippe Kruchten (Paperback - April 8, 2003)
Software Development for Small Teams: A RUP-Centric Approach by Gary Pollice, Liz Augustine, Chris Lowe, and Jas Madhur (Paperback - Dec 12, 2003)
