What are RUP, EUP, UP, OpenUP, EssUp?

Author: Geri Schneider Winters

RUP describes a process for developing software systems. It seems there are so many variations of RUP, how do you know which is best for you and your organization, if any? What do all those acronyms mean? Where are these things coming from?

RUP is the Rational Unified Process. This process is a combination of two earlier processes – the Rational Process and the Objectory Process. When Rational Software merged with Objective Systems in 1995, they began the work to merge their software development processes. This new merged process was released in 1997 as the Rational Unified Process or RUP.

RUP was designed to cover everything known at that time about how to develop software – from very large systems to very small systems. It was expected that users of RUP would customize it for their project and work environment.

RUP describes software development in terms of four phases: Inception, Elaboration, Construction, and Transition. RUP also describes software development in terms of nine disciplines: Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, and Environment.

Not everyone agreed that RUP was complete or correct. Scott Ambler in particular discussed a lot of what he thought was missing in the RUP. In 2005, he and his partners released a book called the Enterprise Unified Process or EUP. This book described the missing elements of RUP. In particular, Scott added a fifth phase – maintenance – to the project lifecycle.

Unified Process or UP, was a request for proposal issued by the Object Management Group. They were thinking of creating a standard for a meta-model process – or to put it another way, a description of how to create a process. This effort was abandoned, so there is currently no UP standard.

Some people use the term UP to refer to the core elements of RUP: risk managed, use case driven, architecture-centric, and iterative development.

OpenUP is a customized version of RUP which is designed for small and agile projects. OpenUP is an iterative software development process that is minimal, complete, and extensible. It is based on managing risk in an iterative development, use case driven, architecture-centric process.

OpenUP was donated by IBM Rational (I believe in 2005) to the Eclipse foundation and the open source communitee. You may download it free at http://www.eclipse.org. Here you may also download EPF, the Eclipse Process Framework, which is a tool you can use to develop your own process or modify OpenUP. EPF is a free, open source subset of the IBM Rational tool Rational Method Composer.

EssUP – the Essential Unified Process – is a product of Ivar Jacobson International. It appears to have been released around 2006. EssUP is based on the idea of a Practice. These Practices are based on best practices from RUP, Agile, and process improvement. Practices are grouped into the categories of Iterative, Architecture, Use-Case, Component, Model, Product, Process, and Team.

For example, a Use-Case Practice describes the work flow of collecting requirements in a use-case driven approach. Along with the work flow, the Practice describes the competencies that are required to do the work of the Practice. So if your Use-Case practice requires the use of class diagrams, then one of the competencies required is that someone involved in this process has to understand and be able to produce class diagrams.

EssUP intends that a company would use the basic elements – Practices and Competencies – to describe their processes and to direct process improvement efforts.

RUP, EUP, UP, OpenUP, and EssUp are all variations of a risk managed, use case driven, architecture-centric, and iterative development process. RUP tends to be popular in large, high ceremony projects. EUP is popular with those involved with Enterprise level concerns. UP refers to the basic process that the rest are built on. OpenUP is an open source variation for small, agile projects. Finally, EssUP is a variation focusing on the practices and competencies of software development, each of which can be independently implemented at a company.

 

Estimating Requirements Gathering

Author: Geri Schneider Winters

Alan Thompson wrote recently to ask, “How do we do a better job of estimating how long it will take to gather requirements?”

This is a question that often comes up, so I want to share my answer with all of you.

The bad news is that there is no good way to estimate the requirements gathering process in the general sense. You may be able to do a good job for specific projects, but there are too many variables to be able to have a good general purpose estimation method.

You can make some guesses based on the type of project it is.

If you are proposing a project that is a maintenance release, basically bug fixes and maybe a couple of new features, then requirements gathering is almost nothing. You just need to come up with the list of bugs that will be fixed in this release, and add details to the requested features. The amount of time for requirements gathering will be an estimate of how long it takes to detail the requirements for one feature (use your experience to estimate this) and multiply by the number of features. Determining the list of bugs to be fixed could be a matter of scheduling a one or two hour meeting of concerned stakeholders to settle the question of what is on and what is off the list of things to work on this release.

If you are proposing a project that is very well understood, then based on the number of requirements, you can do a fairly good estimate of the time it will take to document them and approve them. For example, I once worked on a project to automate the processes of loan application, loan approval, and loan buying and selling for a financial institution. The team knew their business very well, and we documented everything in 2 weeks. All the use cases, a basic business object model, a basic architecture, storyboards, and a draft of a plan to divide the work into 4 projects over 2 years. I had over 100 pages of documentation. The team was me and another 1/2 time person doing all the interviewing, documenting, and organizing of information, and about 10 people from the company who were involved part-time by being interviewed and reviewing documentation.

If you do have good, well-written, agreed on Business Use Cases, then then the time to write the detailed requirements should be the number of business requirements times the expected time to detail one of them. Which is basically a factor of the skill of the people interviewing and documenting the requirements. You may run into some cases where you find that the business use case was not as well thought out as you believed, and so the project use cases take longer to develop than expected. I would expect that situation to be the case fairly often the first couple of projects you try this approach, but the more experience you get, the better the Business Use Cases will be to begin with, and the less surprises you will find as you develop the detailed requirements.

Now you get to the hard projects – the ones that are not well understood or where the stakeholders disagree on the purpose of the project. In that case, any estimate of the time to develop the requirements is just a guess. You can look at past similar projects to find out how long requirements gathering took, and use those figures as a rough estimate. But I have watched stakeholders argue for months about the features and requirements for a project, not because the requirements were difficult to determine, but because they had a basic disagreement about the purpose of the project.

When I work as a consultant, the requirements gathering phase is always time and materials. I will not do fixed bids on that work, because my experience is that there is too much variation in that phase for me to be able to do a good job estimating it. All contractors I know who do this work feel the same way, though some have done fixed bids because that was the only way to get the contract. They have almost always been burned by it, because something happened to extend the requirements gathering phase well beyond what was expected.

Another approach to reduce risk is to go with a true iterative approach. In this approach, you identify and specify just a few requirements, write and test the code, and demonstrate it to the customer. Determine what works and what does not work. Make a list of fixes, add a couple of new requirements, and develop the next bit of code. This way, you are only working on a small piece of the project at a time, which is relatively easy to estimate. But then, you do not have an estimate of overall cost to give upper management. You can use historical records of similar projects to get an idea of overall cost for your project.

All estimation methods ultimately depend on your experience and an estimate of how long it will take to do some small task. Then various formulas are applied to turn the time to do a small task into the time to do the whole job.

In the book “Applying Use Cases”, I have a copy of a paper that shows a use case estimation method, but it is more designed for estimating the project after you have written the use cases. It is based on what are called Use Case Points, and is similar to the method of estimation with Function Points. But if you review that, you might get some good ideas for coming up with your own formula for estimating the requirements gathering phase at your company.

 

Do you have a need to estimate the requirements gathering phase on your projects? What method do you use to estimate that phase?

 

Managing Requirement Changes

Author: Geri Schneider Winters

Almost every project will have to deal with requirements that change. I can imagine some maintenance type projects that are so well defined (fix this list of bugs) that there are no requirements changes for the lifetime of the project. Or perhaps the project is so short (a couple of hours) that there are no requirements changes. But all other projects will have some amount of requirements change.

You could argue that XP projects do not have to deal with this. In XP, a developer works directly with a customer to implement a small amount of functionality. So that small amount of functionality will probably be completed without change. But as soon as the customer sees the results of that functionality, they will want something more or something different.

This is one approach to dealing with changing requirements. Define a small amount of functionality, write the code for that, and demonstrate it to your customer. Get their feedback. Now define another small amount of functionality. This could be any combination of new features and changes to existing features. Write the code for that small amount of functionality and demonstrate it to your customer.

Sound familiar? It should. This is a brief description of a basic iterative development process. XP is an iterative development process, as are RUP and EUP. All iterative or spiral processes were defined for the purpose of dealing with the problem of requirements that change throughout the project.

The key to this is to *not* define all the requirements at once, but to only define enough of the requirements to be able to write some code so you can demonstrate it to the customer.

“But”, you say, “even though my company does iterative development, I am required to write all of the requirements at the beginning of the project and to get them signed off by the stakeholders before any development work is complete.”

Basically, you are describing a process that is waterfall at the beginning, followed by a series of development releases. This is really a modified waterfall. I think what drives so many companies to this process is that upper management wants an estimate of project cost up front, and to estimate the cost of the entire project basically requires you to describe all of the requirements of the project at the beginning.

(Side note: Another way to estimate project cost is to compare what you know about this project to similar projects in the company’s past, and use the final amount of the cost of the previous project as the estimate for the current project. Of course, this requires that the company keep information about previous projects in such a way that it can be found later.)

In this situation, your project must either adjust to each change as it comes along, or define a process to allow you to bundle a set of changes and deal with those changes at well-defined points in time in your project.

This latter way of doing things is preferred, since it minimizes the impact of change on your project team. An easy way to do this is to wait until the development team reaches the end of one of their cycles of development, and introduce the changes when the next set of functionality is being designed. This is less of a disruption on the development team than giving them changes whenever they are discovered.

Another issue arises when considering the impact of change on the project timeline and budget. If you are required to accept every requested change, your project will go over time and over budget. If you cannot exceed your resources, then you will have to add to the change process a mechanism for deciding how much the change will cost, and what the project will give up in exchange. You have to pay for changes somewhere in the project. Either you get more time and money to develop the product, or you pay for changes by not developing something that was originally planned.

This is just basic budgeting as we all practice it at home. If I have $5.00, I can buy a Venti Chai Soy Latte at Starbucks, or a Big Mac meal at McDonalds. But I do not get to buy both. I have to pick one or the other to spend my money on. The same is true on a project. If you have $10,000 to spend, then to add feature A which costs $10,000 you have to remove another feature from the project which costs $10,000. This is very easy to understand, but so many people want to believe that adding new features to the software is somehow free.

I have had fairly good success at positioning requirements changes in terms of cost (time and/or money). So instead of saying, “If you want A you have to give up B” or “We can’t do that within our time and budget”, I tell the customer “You have so much money to spend on the project and it is all allocated to development costs already. This feature you want will cost $10,000 to develop. Where do you want that money to come from? Can we add $10,000 to the budget, do you want to give up something else worth $10,000, or is this new feature not important enough to spend $10,000 on?”

Estimating the cost of the changes and presenting that estimate is part of my process for changing requirements. I do not tell the customer “No”, I tell the customer the cost and the consequences and let the customer decide what to do.

What is the approach to handling requirements changes at your company? There always is an approach, even if that approach is to try to ignore the change requests and hope they go away.