ExperBLOG

Although I have been a strong proponent of software engineering process, and have utilized basic principles of Unified Process for many years, I am also quick to point out that RUP and all of its derivations are not without risk. As often as I have seen succesfful applications of the RUP, I have also seen many instances of misdirected applications end with negative results.

The first principle of the RUP that I would suggest for any organization attempting adoption of the methodology is to start small. This means very specifically start with a small, well-bounded pilot effort - one that can exercise most of the important principles (risk management, iterative development, visual modeling, requirements management, architecture-centric, etc.) and to staff that project with experienced practitioners. This is the organic form of introducing RUP to an organization, and I have found to be the best approach in terms of risk mitigation and long term success. Each successful small project will ultimately graduate a new group of practitioners that can carry the skills forward in an organization. Identifying a small project and providing a quick training overview for the participants is never sufficient to drive the project through to a successful conclusion. For the uninitiated, RUP is often confusing and overwhelming, to say nothing of lack of understanding about the disciplines and the business value associated with all the myriad of artifacts. Fuggetaboudit. Start small, set reasonable objectives for a first pilot, and above all staff with experienced practitioners the first time out. That means professionals that have a proven track record of development work following RUP that can fully embed themselves for the duration of the project serving as coaches and mentors.

What I know for certain does not work in RUP initatives, is the approach where RUP is summarily mandated as “the new corporate standard”, in the form of a sweeping enterprise-wide initiative proclaiming “everyone get on board - we’re all moving to RUP”. Doesn’t work. At least I’ve never seen it work. This approach is flawed on a couple of levels:

1. Does not take into consideration the huge implications of organization change that typically go along with that type of fundamental shift.
2. RUP is too broad and deep for the uninitated to make any sense from, or to use in an effective, productive manner.
3. Lack of understanding or buy-in forom the key stakeholders actually doing the work (analysts, designers, architects, developers, QA) is not going to promote excitement or enthusiasm for the process. Logically, these key individuals will be skeptical (heck, I would be too!), and in most cases will not “get on board” until it can be demonstrated how RUP will make their work better, cheaper, faster.

These are harsh truths about the RUP. Mind you, I have been using the RUP for many years and personally am a huge proponent of it. I frankly don’t know of a better basis for building quality systems based on the best practices in the RUP knowledge base. The newer approaches to RUP like Ivar Jacobson’s Essential Unified Process and the Eclipse open source offerings are exciting developments and suggest that the essential best things about RUP will continue to be invested in and deliver value - keeping pace with the newest development platform innovations. Just remember… to increase your probability of success with RUP, start small, keep it lightweight. With RUP, less really is more!

-Alex Rush

I was asked by a colleague to identify the top 5 core skills a Requirements Analyst needs to be successful. That’s a pretty basic question, but one that I’d never really given much thought to. I formulated this response, which I think is reasonably accurate:
1. Analytic skills. Ability to synthesize information and work at
differing levels of abstraction.
2. Writing skills. Ability to formulate coherent and concise sentences.
3. Modeling skills. Ability to recognize relationships and
dependencies and model accurately in use case models, business workflows, etc.
4. People skills. Ability to work with and elicit information from
all types of individuals (from executive egos to nerdy
programmers to arrogant architects to blustery business proponents to testy testers).
5. Lifecycle perspective. A firm grasp on where and how requirements
fit into an overall lifecycle, relationship of software development
disciplines and roles, and how requirements are consumed and
transformed/traced into other artifact types.