This week's book giveaway is in the Reactive Progamming forum. We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line! See this thread for details.
I'm interested in applying RUP but I haven't found any sample material or examples except one in The RUP: Made Easy book. Everybody talks about it in theroy. Could you share your experience and your opinion? I'm very interested how does it works mainly in smaller projects.
RUP is a process dedicated to software development. It is configurable to fit your needs. It means you won't use all the RUP's artifacts. The first step when using rup is a tailoring phase. You choose the relevant artifacts for your industry sector, size, (or for specific projects)
RUP is iterative (versus waterfall) As a process, RUP is nothing but a guideline during development activities. It define milestones, key artifacts, artifacts structures..... And a common vocabulary among stakeholders of a project.
/ JeanLouis<br /><i>"software development has been, is, and will remain fundamentally hard" (Grady Booch)</i><br /> <br />Take a look at <a href="http://www.epfwiki.net/wikis/openup/" target="_blank" rel="nofollow">Agile OpenUP</a> in the Eclipse community
My team customized and followed RUP very closely a few years ago, with significant direct mentoring from Rational. We used RUP roles & responsibilities, flows, document templates, milestones, fiddled with MS Project plans generated from the Rational toolset. Then over the years we cut some things out started doing other things instead. We also mapped RUP onto another process chosen by the company and started using other words and templates for the same documents. About all that one would recognize from RUP now is the use cases.
I think there is value in studying RUP because it covers a great many things you might need to do and might not think of otherwise. Scott Ambler added a few more good things to think about in his Enterprise Unified Process variation. But don't fall into thinking you should do all of RUP or EUP. Pick & choose what helps you deliver better software faster, or helps you interact with others outside your team.
In short I'd never say to someone you should "do RUP". I might say "be informed by RUP" and figure out what works for you on your own. [ February 11, 2005: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
posted 14 years ago
Do you no any sample project worked out in RUP? I have books, but I'd rather read some practical material, because I can understand and learn faster from examples.
posted 14 years ago
Maybe somebody is interested in some tangible example too. There's a good book: Software Development for Small Teams: A RUP-Centric Approach from Gary Pollice, Liz Augustine, Chris Lowe, Jas Madhur
Book is nice but I don't want to review it here just to tell that from the homepage of the book you can download documents they had created during their project. Source code is also available. I have found it extremely useful.
Couple of things: 1. It's very hard to convince organizations to share their project artifacts as examples, which is why you don't see detailed case studies about the RUP (or about other processes for that matter). 2. RUP doesn't have to be documentation heavy, as I show at Skinnier RUP and Agile Modeling and the RUP. 3. Many RUP projects suffer from The Politics Discipline. ;-)