2.1 Case Study Analysis and Design Artifacts

What Type of A&D Process Is Appropriate for Web Applications?
A question we are commonly asked in our consulting practice is what advice we can give about setting up a development process for Web applications. Simple question. Difficult answer. The problem is that Enterprise Java applications can be approached from two sides—Web-up and enterprise-down.
The Web-up approach is where a Web site built using ad-hoc, seat-of-the-pants development methods must suddenly be rearchitected to scale up to thousands—or millions—of users to meet new demands. In this case, we see that there is often no development process in place, as it has not been necessary in the small-team environment that most Web shops employ. The enterprise-down approach is where a traditional IT organization finds it must reinvent itself to address the needs of customers and partners on the global Internet. In this case, there is often a set of development practices in place, but they do not necessarily apply to the development tools, techniques, and timescales that Web development necessitates.
We have found a happy medium where most groups doing Enterprise Java development can reside. We often recommend that our clients begin by looking at two books—Extreme Programming Explained by Kent Beck [Beck] and UML Distilled 3rd Ed. by Martin Fowler [Fowler].
Extreme programming (XP), the subject of Beck's book, is a radical revisiting of old theories about software development. It proposes a very rapid, highly productive development cycle that is characterized by constant testing, minimal up-front design, and tight control of software iterations. We have seen several cases where small teams (in the range of 3 to 10 programmers, which is about the limit of what XP can handle) can produce very high-quality software in a very short time using this process. On the other hand, there is often a need for some slight formalism in analysis and design artifacts, specifically where developers are learning new technologies, and need to be able to see, at a glance, where the new technologies fit into an overall picture of a software system. For this purpose we often recommend that an XP-like process be combined with some (but not all) elements of UML. Since many Web programmers (coming from both sides) are very visual people, we have seen that they may prefer a more diagrammatic approach to rapid design than the text-based CRC-card approach suggested by [Beck]. We often take this XP-plus-UML approach ourselves, and it is what we recommend for most small teams beginning to learn Enterprise Java technologies.
However, there may be a need for a more large-scale approach. If a team is large (over 15 people) or it must produce specific requirements and design documentation to fit an existing corporate or governmental process, then a more elaborate technique like RUP (described in [Jacobson]) may apply. While RUP is a well-understood and complete process, we feel that it may be overkill in many cases, as it does not accommodate itself well to either Web timescales or team sizes. However, there are those cases for which it must be chosen.
Another approach that is just emerging, and is particularly well-suited for developing enterprise applications, is model-driven development (MDD). MDD separates concerns by developing a platform-independent model (PIM) of the business application. This model focuses on the business domain, simplifying the domain discovery process by separating the complexities introduced by architecture and implementation domains.
The PIM is then translated by automated tools to a platform-specific model (PSM), using translation patterns that are developed for a particular deployment architecture and implementation language, like J2EE. These transformation patterns can be developed by platform experts and provide an excellent way of formalizing and codifying the architectural rules and best practices. See http://www.omg.org for further details.
You must consider carefully your timescales and the size of your team before you select a development process. The same process may not be appropriate for different projects