| I can't imagine why anybody would see RUP as a bad process to follow. Things I like about it are: 1. It's focus on the User and the business case. In the RUP documents you have to describe what business problem you're trying to solve and make a complete list of stakeholders (this can be a wide variety of people, not just the main app user). 2. During the elaboration phase you have to describe the list of requirements and tie them to a business case - so you're forced to think about the problem you're solving. 3. During design phase you have to tie each class/module back to a specific requirement (this forces developers to focus on the real problem as stated) 4. Use cases are a fantastic tools for describing system interactions with the user, and force designers & developers to think about and provide solutions to the not-happy path in a very quick iterative way. In your use cases you should address the main requirements of your stakeholders and tie them back to the requirements doc. 5. RUP has a specific phase for transition to live, and so forces you to think about deployment, architecture, config and maintenance even before code has been written. Yes, your IT dept is a stakeholder. 6. RUP doesn't care what you use during the construction phase - following an agile methodology would be ideal in fact. 7. RUP doesn't care what you use as a project management process - it will have documents that clearly show the scope of your work and the list of prioritized requirements you have to fill before you're done, which is great for tracking progress. 8. RUP is iterative, so if you discovered something important missing during construction - go back to elaboration and work the new requirements through your design. 9. Creating and keeping up to date a fairly small set of well designed documents will lift the quality of your product. This is just my personal experience, but I found I learned a lot following the methodology and Rational's standard documents. Not only did I produce better solutions, I also found that the documentation could be shared and collaborated on with other people within the organisation, and so Business Analysts, testers and the system managers were all stakeholders and contributors throughout the whole lifetime of the project. They loved that. |
Are you kidding, the 90s were filled with same for and against arguments of RUP as we have about Agile and Scrum now. No process is right for everything so you will have people misuse a tool and blame the tool. The same orgs that micromanage Agile teams would micromanage RUP teams and people will be just as angry about it. RUP is a tool and is as good or bad as the people using the tool.
That said, I agree with you that RUP has some benefits.