This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Is there anyone out there that can help me find where best to start? I'm supposed to come up with a tailored RUP software development process for our project (with roles, activities, artifacts, and where the tools fit in). I have completely immersed myself in the RUP documentation and have completed a rough draft Development-Organization-Assessment and now trying to complete a Development Case. The problem I have is a good common place to start and some guidelines that will help me figure out what the Classifications (Won'ts Musts, Shoulds, and Coulds) and Review Procedures should be in the phases. As background this project is basically a new middleware project that will be a central hub for many systems to use to communicate. It will use J2EE and MOM technology. There are basically no new business requirements or redesign, but many of the requirements still need to be documented into UML and a Business Domain model. There's no current process. It looks like this project is going to drive the 1st RUP OOA/OOD process here. Most of the resources will be familiar with OOA/OOD (and I hope RUP or a process similar to it). So basically I have a clean slate to develop a process (at least at a high level to be refined) in a week. Oh, and the project is in the Elaboration phase of the 1st iteration, so they need the process ASAP to help give the incoming resources a process to use and follow. The most important disciplines needed now are Configuration & Change Management, Analysis & Design, Implementation, Deployment, and Testing. If you know any good articles, books, or net resources that can do things to help you get an idea about what activities and artifacts are needed and at what level, that would be great. I keep getting lost in the RUP information. A good sample Middleware project Development Case that I could follow would be extremely helpful.
I agree with Jim, outside help would be your best bet. Not to discourage you or anything but IMO, you're setting yourselves up to lose if you don't--at least this first time through. And if you lose this time, there may not even be a next time. I don't believe that it is realistic to expect to come up with a process in a week. There are too many variables not the least of which are the people involved and their own biases and opinions of how software development should be done. A process is something that you and your team would evolve over time and through experience. That said though, we all have to start somewhere. If I were in your shoes, I would suggest starting out light. Check out this document about dX, a minimal RUP: http://www.objectmentor.com/publications/RUPvsXP.pdf Look into Extreme Programming (XP) practices, especially the ones that have to do with planning. HTH, Junilu
John M Brown
Joined: Nov 29, 2001
Thanks Jim and Junilu... I will look into the Dx article... Unfortunately I AM the consultant, and if they need to hire a consultant to mentor me, then they would not need me. When I interviewed though, I thought I was pretty clear about my experience with RUP (I have worked with a RUP like process, but was not in the section of our department that defined the process). I know that they just want a high level baseline to start with and that this process will get refined along the way. I know that's the most risky method, and I have noted that, but it's not my decision. All I can do is take what info I have on the project, the current tools, and forge my way through the development case. I'm using the examples in RUP and then reading the development case guidelines to get something down for us to start with. I think that most everyone that I talked to realize that this is going to be a painful change, because no one is used to using a process. I did see a suggestion about delegating a lot of the admin type work (of some of the deliverables) to the right people so the designer/developers that are good at what they do will not get bogged down in artifact paperwork. Boy have I gotten a crash course in RUP!