This chapter is from the book
This chapter is from the book
This chapter is from the book
The Key Principles and Your Environment
After you have completed the exercise of crafting a vision statement, you will need to begin looking just under the covers of RUP and tying in the underlying principles to a value statement for your company. RUP has been based on six best practices that have evolved into the six key principles that IBM Rational has gleaned from involvement in tens of thousands of software development projects supporting customers throughout the world, as well as within IBM itself. The evolution from the practices to the principles are in alignment with industry trends. For those of you in larger organizations, you may be working in an environment of IT governance, geographically distributed development, or SOA governance, to name just a few relevant items in a world of outsourced IT and business processes. The key principles are a wonderful evolution of a tried-and-true foundation that has served its adopter well.
The key principles are as follows:
- Adapt the Process.
- Balance Competing Stakeholder Priorities.
- Collaborate Across Teams.
- Demonstrate Value Iteratively.
- Elevate the Level of Abstraction.
- Focus Continuously on Quality.
The best practices are as follows:
- Develop Iteratively.
- Manage Requirements.
- Use Component Architectures.
- Model Visually.
- Continuously Verify Quality.
- Manage Change.
Many of the good books written on RUP that are noted in the Preface, such as The Rational Unified Process: An Introduction, Second Edition3 and The Rational Unified Process Made Easy: A Practitioner’s Guide to the RUP,4 do a great job of getting into the nuts and bolts level of detail of the best practices for project team practitioners. My goal is to arm you with information on what the six best practices and the six key principles will mean to your company and how you can clearly articulate the value they will have in your environment.
There are a lot of ways to sum up what the key principles or best practices are, both in technical terms as well as in laymen terms. I will provide some guidance for you to use in discussing both from a laymen’s perspective, a midpoint between the laymen and technical perspectives, and finally provide some thoughts on how to tie them into your environment. Generally, your executives and decision makers are going to need the laymen terms, but every once in a while, you will encounter someone who needs something deeper. Rarely have I seen the case where you will need to give a decision maker a very technical viewpoint, especially early on.
If you do take a technical deep dive into the key principles or best practices, I would recommend that you either have a current technical background and/or recent and thorough experience with RUP as well as the Rational tools. When you are just trying to float the idea of an improved process solution and set of tools, which is going to take a fundamental cultural change to be effective, being challenged early on and answering ineffectively can damage your efforts tremendously. If you don’t have the background and experience for the technical deep dive, don’t take it. I have rarely seen a lack of technical expertise be a negative when you disclose it from the beginning. Try this: Answer that you can discuss the business drivers for moving the company to the RUP and the Rational tools (which this book will provide), but for a deeper technical discussion, you would have to get one of the candidate future implementation team mentors to join the discussion. Rest assured, there are going to be the technical types that are going to challenge the idea of the RUP and Rational tools, but I have yet to see them want to continue the debate when you start discussing business drivers and returns on investment. My intention here is not to put off the technical side of the equation, as it is critically important. If you truly feel that you are qualified and will do more good than harm, then by all means press forward. However, if you don’t feel that you are qualified, rely on someone who is. To get to the future, you will have to get buy-in, funding, and momentum; often a little damage avoidance goes a long way this early in the process.
Note that it is also important when you are in the initial stages of introducing the idea of bringing in the RUP and the tools to your organization that you don’t bore people when trying to get them interested and planting the seeds for making the next steps a reality. Just as with the vision, having a well-prepared elevator speech for when a high-level response is warranted will help you clearly communicate a visual of the future based on why the person you are addressing should strive to be a part of that future you just painted.
Laymen Terms
Let’s start with the elevator speech type of guidance you can give when a high-level response is warranted. For the six key principles:
- Adapt the process, balance competing stakeholder priorities, collaborate across teams, demonstrate value iteratively, elevate the level of abstraction, and focus continuously on quality are proven to help organizations such as ours make proper decisions for development driven by key principles. By adapting the process, we evolve the required formality over the project’s lifecycle, as uncertainties are resolved. We balance competing stakeholder priorities by taking the time to define, understand, and prioritize business and user needs and align our applications to those needs. Through collaboration across teams of business, software, and operations, we will motivate people and increase efficiency. Employing adaptive management using an iterative process, we will be able to demonstrate value iteratively. This will drive early risk reduction, reducing our project costs and increasing trust among our stakeholders. Complexity has become an issue in our software-intensive systems over time. By elevating the level of abstraction, we can reduce complexity and documentation by reusing existing assets and high-level modeling tools. By making the team responsible for the end product that will be delivered, everyone will focus on quality, which will happen continuously from the beginning to the end of our project’s lifecycle.
In an interview with Chips Magazine,5 Grady Booch6 (IBM Rational’s Chief Scientist) responded to a question on what the six best practices were. His response was one of the best I have seen:
- Architecture [design] first, develop iteratively, test continuously, model visually, manage requirements, manage change—exist because they are proven to help an organization make the proper engineering and business decisions that balance the forces upon the software development organization. By focusing on architecture first, one intentionally attacks the highest technical risks in the system; by developing iteratively, one has the opportunity to reach closure on a regular rhythm and then make intelligent midcourse corrections relative to the current business and technical risks. Testing can then happen continuously, with each new release representing a baseline against which the emerging product can be measured relative to the current (and more deeply understood) requirements of the system. Modeling permits the team to visualize, specify, construct, and document the artifacts of a software-intensive system so as to control its architecture and reason about elements that cannot be known at the level of pure code. The management of requirements and the management of change refer to the intentional consideration of changing user needs (for the mere presence of a release will tell the user things they could not have known or asked about initially) and of the artifacts that constitute the developing product itself.
Midway Between Laymen and Technical Terms
Now let’s get a little deeper, say at the midpoint between laymen and technical. The simplest way to relate either the key principles or the best practices is to know a little about the person you are conversing with and target a key principle or best practice that relates to their role. State that RUP has a key principle that will help them and their team by taking some of the chaos out of their day-to-day work.
For example, the key principle to balance competing stakeholder priorities in RUP means that you are solving the right problem and building the right system. RUP provides discussion on how to understand and prioritize business and stakeholder needs, as well as providing prescriptive guidance on how to elicit, organize, document, and finally manage requirements. It will provide you with workflows and activities that will help you analyze the problem, understand what your users need, and help them distinguish between what is really needed and what they may only feel they need. It will show how to put boundaries around the scope of what the system and/or the specific project is going to include and manage the inevitable change and its impacts on the existing requirements.
The two most significant items that RUP and RequisitePro (the requirements management tool) will provide to you are capturing the functional (behavioral) requirements of the system with the Use Case technique, combined with a tool that facilitates the requirements management by combining both document-centric (through Microsoft Word) and database-centric (Access, SQL, DB2, etc.) methods. You will be able to organize your requirements and provide traceability and change management throughout the entire project lifecycle.
Then ask, so how are you doing it now? With email and spreadsheets? Where are your pain points?