Hi, I've been read several articles and the report of ISO/IEC15504-5 published on the RUP website about lacking of maintanence process, I am just wondering that if RUP has realized it's weakness in emphasizing the maintanence process and going to do improvement on it? Does anyone know the purpose of RUP publishing these articles on it's website?
Can you please provide a link to these articles? Sounds interesting... Thanks!
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
Originally posted by carol zhou: Hi, I've been read several articles and the report of ISO/IEC15504-5 published on the RUP website about lacking of maintanence process, I am just wondering that if RUP has realized it's weakness in emphasizing the maintanence process and going to do improvement on it? Does anyone know the purpose of RUP publishing these articles on it's website?
OK, I took a look at the report. I didn't read it from top to bottom, as I felt it to be rather wordy without having much meat. Also take in mind that I really don't know very much about RUP, let alone ISO/IEC15504-5, and might be seeing it from a rather agile/extreme perspective. The report seems to state that in the current form, RUP may not be sufficient to be successfully assessed in all processes regarding ISO/IEC15504-5. "Maintenance" is identified as one of the shortcomings, mainly because of RUP not being explicit enough about it. Is that a bad thing? I don't think it necessarily is... First, Alistair Cockburn makes a point when stating that *every* project needs its own process anyway. In fact, even in the course of one project, the process probably needs to be adjusted significantly over time. A process framework like RUP takes that into account by just giving you some guidelines on how to assemble your process. Of course you might criticize that RUP doesn't give you enough guidelines for maintenance, which takes me to Second: I don't think that a process framework needs to consider everything. Projects may be so different in form and size that it would be nearly impossible to do so. So a general framework such as RUP just *has* to lack in some regards. If you feel the lack in your project, you simply have to complement it by other means. So shouldn't RUP say something more about such a general concept as maintenance? Well, till now *I* never personally saw a project in maintenance mode, so I can't say much about the accompanied needs. On the other hand you can make the point that an agile project is in maintenance mode from nearly the beginning: after the first couple of weeks you have a working system and from there on you enhance/change it driven by the customers current needs. In such projects development and maintenance seem to be in fact identical. That are my thoughts so far. What do you think?
Well, if memory serves me right (god, I sound like the opening of 'Iron Chef'), Alistair Cockburn also distinguished that how much process you needed depended on the risk of the project. I'm probably about to sound like a bit of a hard-ass, but I'm not trying to be mean; just to get some issues on the table. I don't think you can draw solid conclusions in comparing RUP and ISO process standards with a lightweight process unless you know what kind of work you are talking about. - If you are talking about a small low-risk project, usually a lightweight process wins. - If you are talking about a large project with death-and-destruction risk, usually a heavy-weight process wins. - If you are talking about non-project work, then project-oriented development processes are usually irrelevant to the discussion. Those who haven't done process-oriented task work often fall into the trap of arguing a project-oriented methodology issue that actually doesn't apply to process-oriented work. What I often see happen in these discussions is an argument that follows the pattern "I only do X, process Y suits what I do better than process Z, hence I suspect Y suits a set of unspecified things other than what I myself do". Some forms of work are not project oriented. They can require a great deal of control on the process; incremental changes made in maintenance mode can be an example. The Challenger disaster is a textbook case; that resulted in a dramatic overhaul in how configuration management was handled for Nasa contracts. (To be completely accurate, here you could argue that the failures here weren't specifically in maintenance - the problem was that failures could crop up at multiple points and prior to establishing the IV&V checks Nasa wasn't able to catch those failures consistently.) Maintenance activities, when they are a material issue, have engineering challenges. Processes there really aren't a consensus issue; you don't pick what you like. You pick something that has been proven to reduce the risk that one person doesn't bring the entire organization crashing down. Obviously there are many situations where this kind of process oversight is not needed. Patching RUP wouldn't help them because they probably didn't even need RUP for the original project work. If, on the other hand, you are doing work that must exist in the context of some federally-regulated industry, it is likely that maintainance is a big deal. In this sense, the lack in RUP is a real issue, since it is presented by Rational as a process framework that can achieve the level of control required for high-risk situations. [ June 07, 2002: Message edited by: Reid M. Pinchback ]
Reid - SCJP2 (April 2002)
Joined: Jul 11, 2001
Reid, thank you for your very reasonable and interesting post!
Originally posted by Reid M. Pinchback: In this sense, the lack in RUP is a real issue, since it is presented by Rational as a process framework that can achieve the level of control required for high-risk situations.
I didn't know this. If this proves to be true, I have to aggree. Do you have any pointers, please? Thanks! [ June 07, 2002: Message edited by: Ilja Preuss ]
Reid M. Pinchback
Joined: Jan 25, 2002
I can't point at many documents on the configuration management issues, some of this is stuff I've learned because of my work, in particular from somebody who ate/breathed/sleep CM. I know of at least one case where Rational has helped a client use their tools for doing work with a lot of regulatory issues, but you aren't going to find reading material about it. As for the Nasa stuff, www.ivv.nasa.gov will get you there. There are books on applying process models to software development (particularly TQM), but you have to be very careful how you do it. People tend to get to focused on the details of what can differ between software projects, instead of looking at how their past approach to the work has obscured the commonality. In general it is easier if you keep out of true project work, and focus on fine-grained repeatable tasks (e.g. localized bug fixes, support requests, tweaking GUI functionality) until people get used to the process mind-set. The primary advantage isn't sometimes that you'll improve how this work is done, but that you'll uncover and fix a lot of related organizational weaknesses on the way. As for Rational and RUP, the way it was presented to me, and from what I've seen this makes sense, the marketing strategy of Rational is to take the capability maturity model and package it up for sale. Good way to sell to government and big financial and pharma organizations, but fundamentally flawed if you are the purchaser. CMM isn't something you buy. You really have to reorganize how the organization gets work done, which means a lot of the issues are people-related, not technical. It requires a great deal of skill building. I think by the end you could have a very efficient organization, but the effort to get there is very significant and not to be undertaken lightly. Most organizations that attempt it don't get much beyond CMM level 2; I don't know if anybody has made it all the way to 5. If you haven't been through TQM or Re-engineering I doubt you'd be mentally prep'd for the organizational efforts required to attempt CMM. I have a simpler philosophy - teach people to write decent requirements docs, and teach them how to work to those requirements. If you can't do that, don't bother with CMM or RUP or anything of that ilk; the way your organization approaches its work would doom such efforts to failure. Once folks can deal with requirements, introduce them to formal project management. If they never get further than that, they'll still have a hell of an organization. [ June 10, 2002: Message edited by: Reid M. Pinchback ]
Reid M. Pinchback
Joined: Jan 25, 2002
And I realized I should clarify/qualify what I said. "Working to requirements" means something in particular to me.
You bother to get initial requirements and write them down.
People brainstorm over them and come to some initial agreement.
You use the requirements to make your schedule estimates (yes, it is possible - anybody who tells you otherwise simply lacks the necessary skill). If you do project planning, then shoot for a direct correspondence between the requirements items and the work breakdown.
You use the requirements to plan the QA work (again, it is possible - much the same idea as using JUnit to write the tests before the code).
You use the requirements to do the design work (create links from design docs back to the requirements to show that you did something to satisfy a requirement, not simply because it seemed like a neat thing to try).
[ June 10, 2002: Message edited by: Reid M. Pinchback ]