Let’s simply start with the fact that this blog was supposed to be made about 3 weeks ago, yet my procrastination was too big and now here I am, on partial’s week, blogging about what Unified Software Process (I’ll now refer to it as USP) is.
Last blog, I talked about some of the different methodologies used for developing software projects and how it could literally mean the difference between a good process and just having a really bad time. So we’ve already established that having a good framework is important, now we’re going to talk about USP and it’s iterative ways.
Everything started back in 1999 when the trio of Grady Booch, Ivar Jacobson and James Rumbaugh published a book called “The Unified Software Development” in which described the process that we know as USP today. Just for clarification, this process was owned by Rational Software, so people just started using the USP name to avoid conflict with what Rational called RUP, or Rational Unified Process, but they’re mostly the same concepts. Anyhow, this process has many different interesting aspects, but the one’s that I found more interesting were the fact that it is an iterative process, and it has many different layers, which overlay between each other. The model has 4 differents stages, which are Inception, Elaboration, Construction and Transition. Unlike some of the methodologies discussed before, USP is risk-focused in a way that it relies on the development team addressing the most critical risks early on.
So that’s enough about the history and what was a very basic explanation on USP. I felt that every single resource I tried to use to uncover and uncork the true meaning of USP was just so bloated, I couldn’t really get a good enough grasp of it, so I’m going to ask my friends and fellow students about their thoughts on this.