- Bridging the CM Gaps
- Bridge over Troubled Waters
- Identifying Actors
- Use Cases
- Activity Diagrams
- Component Diagrams
- Deployment Diagrams
- Bridge Building
This chapter is from the book
This chapter is from the book
This chapter is from the book
Bridge over Troubled Waters
There are bridges in software development, as well. Building a configuration management system can be a daunting task for any organization. Yet many teams, in the rush to solve immediate problems and focus their time on "billable" development activities, will push some kind of CM solution out the door without properly analyzing the organization's needs, short term and long term.
As we're sure you've all seen, far too many teams are tackling problems without understanding the full scope of the project in front of them. And yet, time after time, that's how projects get under way—with arbitrary deadlines—and usually behind schedule from the start. Customer demands and project deliverables require a speedy implementation. But a speedy deployment and a well-planned and well-developed system do not have to be mutually exclusive.
One common management dream is to start on a project at the beginning of the lifecycle, rolling out process and procedure at the inception phase of development. However, this is rarely the case. Luckily, configuration management systems are available to aid in your development efforts. They can be a powerful asset for increasing communication, productivity, and quality through process automation and integration of the tools that most engineering groups use today. You could call CM the "bridge" that links your company's development teams. Implementing some kind of CM solution will organize your development efforts around solid and repeatable processes—and by helping your team prioritize and manage the development lifecycle, you are more likely to meet your customers' needs.
As we've stated previously, configuration management and the teams that manage these tools are in a unique position because they are the glue between engineering and the rest of the product development structure in your organization. The product cannot move forward in a timely manner unless the CM team coordinates with the build-and-release teams and, generally, manufacturing. And unless your project is proceeding quickly, it's a safe bet that your customers are not happy.
Now . . . back to the steps that lead you to the solution. The process of determining the path and structure of the system as it is applied to your organization is called business modeling. The purpose of business modeling is to determine who and what the customer is—but not necessarily the requirements of the project. The point is to seek to understand the client's perspective, and not make any judgments about possible solutions or what the customer thinks he or she needs.
The purpose of this chapter is not to walk through the dos and don'ts of business modeling—there are plenty of chapters available on the Rational Developer Network on the subject. [3] It's probably safe to say that business modeling is the most undervalued part of the software development process. With that said, we feel it is important to remind everyone that we are not trying to identify the requirements at this stage. The business model is the "problem domain" while the requirements are the "solution domain," which we address later in the development process. Instead, it is critical to know what you are building and why.
Models help a software development project team visualize the system they need to build that will satisfy the various requirements imposed by the project's stakeholders. The aphorism "A picture is worth a thousand words" holds especially true when it comes to work involved in developing software: much of what's interesting about a given system lends itself to visual modeling better than plan test does. The UML is specifically designed to facilitate communication among participants in a project.
—From UML Explained ,by Kendall Scott (Addison-Wesley, 2001)