Not Heavy, But Solid
RUP has a reputation for being a “heavy” methodology that requires a solid understanding of UML, which is why so many organizations find ways to avoid it. However, not having a plan or a methodology is not just unprofessional—it’s plain foolish.
I have worked with quite a few methodologies, from Coopers & Lybrand’s Summit S and D to CSC’s Catalyst. They too were heavy, but when they were used appropriately, I always found they contributed significantly to project success.
The main problem with methodologies is that organizations don’t embrace them. They don’t work with them enough or give them enough time to hit their stride within the development group. As an organization gains expertise, it learns the tricks of the trade and when and where shortcuts can be taken.
In my opinion, reactionary organizations that do not take project management seriously never really know the complexity or size of a project until it is under way. These types of organizations tend to add resources in a just-in-time fashion, and those resources are perpetually in a “hover” position, since management doesn’t really know how long the project will take or how to size it.
Project Approach and Methodology
RUP is a powerful methodology and useful for most object-oriented business systems projects, but I believe you need to level it for the type of project and complexity you are facing. The venerable Summit, from Coopers & Lybrand, incorporated a useful concept called “route mapping,” in which, depending on certain project characteristics such as whether the application being implemented was targeted for a mainframe or a PC, certain artifacts or tasks could be optional.
The basic methodology stayed intact, although it could be tailored to the unique needs of the project. In effect, RUP can be used in the same way. Some functionality may need only a simple high-level UML sequence diagram and no view of participating classes (VOPC). Other projects with more complex workflows might need state-transition diagrams. However, it is my understanding that RUP has never adopted a “route mapping” concept, so Activity, Sequence, Class, State, Transition, and the like seem to be necessary for all functionality.
Agile is another example of a methodology that uses the concept of route mapping. One of the fundamental ideas of eXtreme Programming (XP) is that there is no process that fits every situation, so the relevant tasks for each type of project need to be tailored to its individual needs. Route maps can be used in order to determine which structured method fragments should be used for a particular project.
Object-oriented purists might say that not exercising all artifacts is a bastardization of the methodology and not what its authors intended. That is, that all use cases should be realized in the form of sequence diagrams; and that sequence diagrams should be used to drive out class behavior; and that all sequence diagrams should have a VOPC, etc. I don’t agree with that, either. Mindlessly following RUP as a cookbook is exactly what has given it a less than stellar reputation and contributed to its reputation as being heavy. I believe that, given the limited time project managers usually allot for design, choosing design artifacts that will have the most impact is the best approach. In any case, a certain amount of methodology—and not just a veneer of methodology—is better than none at all.
Design Artifacts
I have found that even a basic set of sequence diagrams with well-defined method signatures can go a long way toward clarifying design. Take an application that imports an Excel file, parses the data in the incoming spreadsheet, persists the data to a database management system, and then asynchronously notifies Java Message Service (JMS) that there is a batch to be processed. (See Fig. 1.) In a typical project, several resources would be needed to realize the implementation of the design; the model is the first step in the collaboration effort.
On large teams, the consumers of UML artifacts are, for the most part, other team members. However, don’t make the mistake of thinking that UML is truly a universal language, as the name implies, and that all technologists have embraced it. Offshoring projects that rely on UML as the lingua franca assume that the human resources they’re communicating with have an understanding of UML. Not true. Today’s software development teams tend to be very eclectic, whereas resources can be language-challenged. On one recent project, I naively thought that if I created UML artifacts I would overcome the native language weakness with a common language construct (that is, the Unified Modeling Language). However, UML still requires an understanding of language, as well as rigorous conceptual skills that need to be learned over time. In the end, it took brute force to complete the project, since no one on the team really understood the artifacts. I would recommend interviewing project resources on their UML fundamentals or, better yet, have them create a design for you.
Recently I spoke with a project manager who observed that design was useful mainly for communication among project participants. While that is most definitely true, I take umbrage at the idea that design is useful only for that purpose. That type of attitude toward design relegates it to an activity that you perform in preparation for offshoring the implementation. At best, a good design artifact can allow for what NASA calls static design testing, where the design is robust enough to test prior to construction. At a minimum, a view of the system as a well-defined set of objects can provide scope and responsibility for application components to be implemented. In my opinion, UML is a good notation for getting ideas out of your head and down on paper in an organized manner. The process of committing your ideas to paper or a design tool is very much a part of the design process. For example, constructs that might appear simple at first may turn out to be complex, and vice versa.
Many projects go wrong because of the belief that a UML tool can emit a design through the XML Metadata Interchange (XMI) interface, and that the exported design can be used directly as working code. XMI is an Object Management Group (OMG) standard for exchanging metadata information via eXtensible Markup Language (XML). It can be used for any metadata whose meta-model can be expressed in Meta-Object Facility (MOF). The most common use of XMI is as an interchange format for UML models, though it can also be used for the serialization of models of other languages. Not that this isn’t achievable or that object prototypes can’t be emitted from a tool; many tools, such as IBM’s Rational XDE or realMethods, are capable of forward and reverse engineering. It is the typical developer’s lack of experience that is really the weak link: the promise or expectation of generating working code directly from a design artifact is usually more than they can deliver. A successful design phase should not be measured by the amount of code generated from the design tool.
0 komentar:
Post a Comment