Please login or join to subscribe to this thread
I can not agree more. There is wide spread confusion about the separation between the process of building an OO system using an SDLC like DAD, and the actual management of the people, resources, places and schedules to deliver the software being built.
RUP is a work in process and is very incomplete. It is at best a collection of templates for OO deliverables using the Rational approach. It is trying to connect the dots that are not connected by the three amigos. For example how do you go from use cases to business process to method description. RUP is weak. Any OO project that really tries to use it will discover its weaknesses. RUP has no management tasks. It has some QA tasks, but it essentially ignores the whole areas of iteration planning (it thinks you will build everything at once, a naive view), other than unit testing it has little to say about testing (OO system integration testing is a nightmare) and so on. RUP does not define start and end activites and milestones (the very stuff for which PMs live). It has no metrics, no estimates, few guidelines.
That is why we wrote the DAD OO methodology. We used most of the principles of RUP (before RUP came along, methodologists were all integrating the three amigos, before they formed a posse!) and added all the needed management tasks, separation of issues, and quidelines to be useful to a project manager. With DAD you can drive a project plan from the tool. It will show a schedule of tasks (including the PM tasks) needed to deliver an OO project.
Having used methodologies most of my working life, I find that with the push to create working software faster and faster, methodology is going by the way side (as evidenced by the popular belief the RUP is a methodology). This is a sad state of affairs. Hopefully project managers will recognize that the process/ management dichotomy (it is endemic to work of any kind anyways) requires both a process description and a management method. But together make for a happy project.
I'm very intersted by the comments on DAD. I'm currently reorganising an IT development department, and about to kick of a methodology selection project. Can anybody pointme to info on DAD?
Thanks - Peter
I too agree that there should be a distinction between the process itself and the management of that process. However, I would argue that one of the aims of the RUP was to blur (if not eliminate) this distinction. A Rational white paper states that the RUP “presents an approach to managing the project that will markedly improve the odds of delivering successful software.” If blurring this line was one their aims, my experience (and Slade’s) tells me that they have been most successful.
As Andre has pointed out, the RUP is still a “work in progress” and it currently has some serious deficiencies in the management area. It is conceivable, however, that sometime in the future these weaknesses will be eliminated - along with the need for a distinction between process and management.
While I concede that there will always be a conceptual difference between the two, I doubt that there would be any value in pursuing these differences (at least not for the vast majority of projects).
As a company specializing in the use of soaftware engineering methodology to deliver on time and on budget and specifically using the Rational Unified Process (RUP) I cannot agree with most of what is said in this thread.
Here is an extract from RUP on project management:
<<<<<<< Our goal with this section is to make the task easier by providing some context for Project Management. It is not a recipe for success, but it presents an approach to managing the project that will markedly improve the odds of delivering successful software.
The purpose of Project Management is:
To provide a framework for managing software-intensive projects.
To provide practical guidelines for planning, staffing, executing, and monitoring projects.
To provide a framework for managing risk.
However, this discipline of the Rational Unified Process (RUP) does not attempt to cover all aspects of project management.
For example, it does not cover issues such as:
Managing people: hiring, training, coaching
Managing budget: defining, allocating, and so forth
Managing contracts, with suppliers and customers
This discipline focuses mainly on the important aspects of an iterative development process:
Planning an iterative project, through the lifecycle and for a particular iteration
Monitoring progress of an iterative project, metrics >>>>>>>>>
The Rational Unified Process® or RUP® product is a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget.
It clearly states what it is trying to do and what it is not trying to do. As such it does indeed acheive it's objectives. It should not be judged on what it is not trying to acheive.
It does have clearly defined planning activities for iterations, disciplines, phases.
It does have clearly defined workflows, activities and artifacts.
It does have clearly defined measurements that enable proper management of a software engineering exercise.
It does do what it sets out to do if used properly.
My company has a 100% success rate using the RUP for software engineering. If anyone wnats more information in how to use the RUP successfully then by all means contact me.
Dear Mr. Matthews, you present a very nice and thorough defense and positioning of RUP. I agree with everything you said. However, with respect to the original thread of this post, there are those that suggest that RUP can be the basis of a project management methodology for use throughout the enterprise for a wide variety of project types not just software development projects and not just IT projects. Can you imagine a business development professional using RUP to manage a product promotion project, or a marketing professional using RUP to manage the annual customer conference, or an A&E firm using RUP to manage a construction project..? I can't. It is in that context, that Mr. Beard per his post below disagrees with those that suggest that RUP is a PM methodology. For those seeking to establish project management as an enterprise wide best practice and core competency, there no doubt will be a home for RUP and/or an equivalent SDLC process for software development, but RUP or whatever SDLC process the organization uses is not likely to be an appropriate, useful, or even usable project management methodology for others in the enterprise. Any thoughts..? Cheers. Mark Perry, VP of Customer Care, BOT International
RUP can be customized to accomodate any project process.
Dear Anonymous, not even Rational now IBM suggest that RUP could be used or is even appropriate for any project process..! If by your post, "RUP can be customized to accomodate any project process", you mean any process within the domain of software engineering and development and as described in Mr. Matthews' excellent post, then I agree with you. On the other hand, if you really mean RUP can be customized to accomodate "Any Project Process", such as those outside of software development like Business Development Projects, Marketing Research Projects, Sales Go-to-Market Projects, Construction Projects, then I cautiously accept you claim. I would only add that of all of the organizations that use RUP that I am aware of, not one of them use RUP for any of those formerly mentioned, outside of software development, project process types. I look forward to learning from you and others and hope to find further posts on this topic. Cheers. -- Mark Perry, VP of Customer Care, BOT International
Please login or join to reply