New Articles at Resources for Business Analysts Site

We are up to 290 members now at– very soon we’ll be over 300!

I posted some articles on the site today that were in my email list or somewhere on the blog or somewhere on my hard drive 😉

These are on the Use Case page and Determine Requirements page. I also added new sections to the BA Skill Matrix for SDLC and Tools. So go explore and see what is new!



Tips for BAs: BA on Agile and SCRUM teams

I have had some of you request more information on the Role of the BA on an Agile or SCRUM team. So I am holding a teleseminar on that topic. I will be interviewed by Thomas Meloche of Procuit, Inc., who is also an expert on Agile software development. This will be on Wednesday, January 6 at 5pm Eastern.

Update: We held the teleseminar, along with our guest Mike Vizdos of Implementing Scrum. Mike is a certified ScrumMaster and a trainer of Scrum Masters. It was great to have his input on this topic.

The replay is posted at on both the Scrum and Agile pages.

You can comment on the teleseminar either here on this blog or on the website.

I am looking forward to hearing from you!


Tips for Business Analysts: 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 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.


Now it is your turn.

Have you or your company considered the use of RUP, EUP, UP, OpenUP, or EssUP?

Are you using any of these processes in your projects?


You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…


* Article used with permission from Wyyzzk, Inc.’s Resources for Business Analysts site at This website of reports and tips contains information to help you succeed as a Business Analyst in IT.