The Basic Unified Process

I have never worked on a large software team – in fact, most projects that I have been involved with, did not have more than two participants. Still, getting some insight into software development on a larger scale seems like a worthwhile exercise. Recently, I have been made aware of the “Unified Process” (UP) and started to read up on it. However, I quickly felt overwhelmed by all the talk about roles and disciplines and what not, and could not help but wonder: This seems like total overkill! How does this all apply to small teams – the kind I might actually end up working with eventually?

A quick Web search brought up several variations of the Unified Process, which does not appear to be all that unified after all. A few of these variants seem optimized for small teams. One especially promising example is described in the white paper “Basic Unified Process: A Process for Small and Agile Projects” by Ricardo Balduino, Rational Unified Process Content Developer at IBM. The Basic Unified Process (BUP) derives from IBM’s Rational Unified Process (RUP), but was streamlined to better suit teams of 3 to 6 developers, working on small projects, often not lasting longer than 3 to 6 months.

BUP is organized into methods and processes. Methods are focused on the following disciplines: requirements, architecture, development, test, project management, and change management. Compared to the RUP, some disciplines, like Business Modeling, were omitted, while some others were absorbed into neighboring disciplines. The BUP roles are analyst, architect, developer, tester, project manager, and a catch all “any role”. The number of tasks and artifacts are reduced as well to minimize ceremonial overhead.

While simpler than the RUP, all the disciplines, roles, tasks and artifacts in the BUP still make up a huge collection of methods, of which typically just a small subset will apply to any given project. The BUP therefore organizes semi-ordered sequences of methods into custom tailored processes. These processes are subdivided into iterations, groupings of methods, which may be applied in parallel at different stages of the project.

I am not sure, how well I understood the details of the Basic Unified Process, but from my first impression this way of structuring software projects appears very logical and instantly applicable. While maybe not as general and powerful as the more complex Unified Process variants, the BUP seems to be a useful entry-point into the world of Unified Process project management. One, which is instantly understandable and applicable by people without prior large-project experience, like me.

This entry was posted in ITE 221. Bookmark the permalink.