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.
USP is tied closely to UML, this makes sense since that’s the language that was developed by the people we just talked about. Many people consider USP to be the most reliable and trusted process for the development of a project, but you’re not here for that, you’re here for my opinion. To me, USP looks like an awesome way of developing a project. It is very organized and very clean, yet I think that the biggest flaw it has is it’s made by people in the software industry, for people in the software industry. This is cool and makes sense, but a development team is not always compromised by software engineers, it can have many parts to it. Designers, for example, can be a big part of a development team, and I don’t think this makes much sense if you’re not accustomed to this kind of methodology. However, if you can make it work and get other parts of your team up to speed and not struggle with the many different parts of USP, I do believe it is a very strong framework, one that can lead to the development of a great project.
I used a bunch of resources to try and learn about USP and I had some trouble getting the gist of it, so I’ll link my favorite video about it right here.
You can check out some of my latest work on my website: grupoargon.co