Software Development for Web Applications

Since this book is based in large part on the expressive capabilities of UML, it would seem only natural to express the process itself in terms of a UML model. Using the business modeling extension[9] for UML, we can express the workers, workflows, artifacts, and activities of the software development process with UML elements.[10]

[9] The use of the business modeling extension is not completely accurate, because I pull out activities and represent them with analysis-level control classes. The official specification can be found on the Rational Software Web site as a PDF file under the title "UML Extension for Business Modeling."

[10] The complete Rational Rose model is available from the Addison-Wesley Web site or from the author's Web site: www.wae-uml.org.

At the top of this model is the business use case view (Figure 6-3). The business actor Stakeholder represents all individuals outside of the project who have a vested interest in the project. They don't build the software; nor are they responsible for any artifacts of the process. Stakeholders do, however, contribute through interactions with the workers in the process. The Stakeholders are the customers, company executives, investors, and users: anyone with an active interest in the evolution and the delivery of the system.

Figure 6-3. Top-level business use case diagram for the Web software development process model

A Stakeholder interacts with the "business" through the business use case Develop Software, which is the main use case of the process. A critical part of this use case is the included use case Software Iteration. Software Iteration describes the bulk of the work that we would normally consider as part of the development process. Develop Software provides the description of all the other stuff involved in the process, including the activities that start and complete the entire process.

Develop Software

The activities of the Develop Software use case are expressed in Figure 6-4. The development process begins with an analysis of the business and its perceived problems, at the same time developing a domain model. A brief description of each of these activities follows.

• Manage artifact versions. This activity is done concurrently with every other activity that involves the evolution and the creation of process artifacts. Essentially, it is the activity of the change management process and the use of a version control system.
• Analyze business and perceived problems. Take an objective look at the state of the business. Try not to be influenced by the perceived problems presented by the stakeholders. Too often the perceived problem, as presented by the stakeholders, only scratches the surface and hides the real problems, which are rooted far deeper. Only with an understanding of the business can you examine the real problems in a truly unbiased way.
• Develop domain model. Use software development tools, such as UML, requirements gathering, and document management applications, to construct a model of the domain and the business. The UML extension for business modeling is the most appropriate way to express the major entities and processes of the business. The most important artifact of the domain model and the requirements model, however, is the glossary, which defines the key terms and concepts of the context that the system is working in.
• Analyze the understood problem. With a solid understanding of the state of the business and of the domain that it operates in, it is time to focus on the real problem, or at least the problem that the stakeholders are willing to let you work on.[11] Look at the problem without unnecessarily preconceived notions of the solution.

  [11] This may sound a little cynical, but on one project, it was pretty clear that the roots of the problem were that all the company's facilities were treated as cost centers, some of which were literally across the street from each other as a result of an acquisition binge. We, however, were tasked only with the creation of a centralized order fulfillment system that had to somehow be optimized for all peculiarities and differentiating features of each facility.

• Develop vision document. The vision document, the one that all else derives from, expresses the scope and the purpose of the entire software project. Typically, the vision document is focused on providing the principal features and acceptance criteria for the system under development.
• Develop project plan. The project plan outlines the activities of the entire software development effort, defining the major milestones and referencing appropriate standards documents, including the change and configuration management plan.

Figure 6-4. Activity diagram of develop software business use case

The project plan includes a first draft of the iteration plan. Planning iterations is key to the process. Iterations don't just happen; they are planned in advance. The project manager, with the architecture team, tries to identify the key high-risk areas for development. These areas are targeted for early iterations. The iteration plan describes in sufficient detail the activities that are expected to be carried out during the time period of the iteration.[12] The plan specifies the artifacts that should be delivered by the end of the iteration and, most important, the success criteria for each. The success criteria are important because in those situations, in which an encompassing artifact is evolved partially in one iteration, completeness may not be the goal, but rather a part or aspect of it is the real goal.

[12] This assumes a time-bound iteration. For human-critical applications, the end of the iteration might be identified only as the completion of QA objectives and tests.

It is fully expected that the iteration plan will undergo significant revision by the time the project is completed. Ideally, the plans for the first and second iterations should be reasonably accurate, but the farther out you go, the more likely that the iteration goals become more vague, to be revised with more detail, as it is available, later on.

One of my favorite stories about the variability of project schedules is from a former colleague of mine. While toiling late hours and weekends to meet a "do-or-die" deliverable, Wayne confided that in his nearly 20 years of software development experience, he had never failed to meet a system delivery date. He went on to explain that when the date arrived, the current version of the system was shipped, and whatever was done next was called maintenance. This is not exactly how I would approach the concept of a variable project schedule, but it does express a common practice in many companies.

One very important goal of the process described in this chapter is to address risk early. Risk is the unknown; it is areas that rely on new, unproved technology or areas with which the development team is unfamiliar. Throughout the process, and especially early on, the project manager, the architect, and key members of the team review the current set of requirement and architecture artifacts, which include the use cases, and look for signs of risk. These areas are targeted for development in early iterations.

Instead of letting risk pop up uncontrolled, the process actively seeks out risky areas of the system and implements them first. The reason for this is to let use cases drive the process. Use cases are a resource for nearly every activity in the process. All workers typically review the use cases to validate decisions made during their activities. The use casedriven approach helps manage and attack risk by providing a focus for development and identifying deliverable targets for the iterations.

Use cases or sets of use cases that are determined to contain the most risk are targeted for early development. If they are included or are extensions, appropriate stubs and infrastructure are created so that they can be executed and evaluated. One by one, these use cases are elaborated and implemented, with their completion contributing to the incremental delivery of system functionality. Because most are delivered as executablesor at the very least as a set of semifunctional Web pagesthey can be evaluated by the testing team. The testing team uses the iteration plan and the current state of the use cases and requirements to prepare test plans and scripts to evaluate each iteration delivery. The project manager assesses the results and uses them to make adjustments to the development schedule and the next iteration's plan. Under some circumstances, the project manager may use the results to reassess the minimal set of requirements to make the project a success and to adjust the requirement set to make a successful delivery of the system more realistic.[13]

[13] I know you're smiling; let's face it, this happens far more often than we would like.

Iterate

Perform one instance of an iteration. The exact nature and the makeup of the iteration are defined by the iteration plan. Throughout the phases of the process, the emphasis of activities shifts from one workflow to another, yet most are active throughout the entire effort. Figure 6-5 shows the activity levels throughout the phases and workflows of the Rational Unified Process. This activity is expressed in more detail in the Software Iteration activity diagram of Figure 6-6.

Figure 6-5. Phases and workflows of the Rational Unified Process. (Source: Philippe Kruchten, The Rational Unified Process: An Introduction, Second Edition (Boston, MA: Addison-Wesley, 2000, p. 46.))

Figure 6-6. Software iteration activity diagram

On large software projects, iterations can happen in parallel. Usually, this is practical only during the elaboration and later phases, after key subsystems and interfaces have been defined.

• Deploy system. Deliver and install the system. This may involve a phased rollout or simply mean turn it on. If involved in a phased rollout, additional activities and workflows should be completed during the construction phase, in preparation.
• Maintain system. System maintenance is essentially a miniversion of the process that developed it.

Software Iteration

The Software Iteration business use case describes those development process activities that involve the iteration of all artifacts that make up the stepping stones from the vision document to the collected artifacts that make up the final product. This use case is included, or invoked, by the Develop Software use case and appears in its activity diagram as the Iterate activity.

The activities of the Software Iteration use case are described at a very high level by the activity diagram of Figure 6-6. The most significant feature of this diagram is that all the individual workflows happen in parallel. Before the iteration starts, the plan is checked. After the iteration is complete and has passed its success criteria, it is evaluated by the team. This is also a good time to update the stakeholders who are interested in the progress of the project.

A project manager experienced in this type of development process will realize that the use cases tackled in the first few iterations will typically take the longest to develop because they are often the learning mechanism for the team's junior members. Once the first few iterations are complete, the project's rhythm is established. Establishing a rhythm is crucial in the process. The project's rhythm is set by the periodic project activities that contribute to the creation of the system's artifacts. These activities include the weekly status meetings, the daily "stand-ups," the nightly builds, the morning's test reports, and any other periodic activity of the team. The rhythm is important because inevitably, something will go wrong. A date will slip or a technology will falter, and the natural reaction of an unseasoned team is to panic. With an established project rhythm, enough inertia will be built up to make it more difficult to toss away the process while concentrating on the fix of the "big" problem.

Nearly every organization starts with a process of some sort. The real test of a successful process-oriented organization is the continued use of the process even in the face of slipping schedules. I've seen it too many times: The organization starts well by defining, or at least accepting, a process and for the most part follows it. Technical problems pop up, requirements get changed, and the schedule starts slipping. The natural reaction of the team, still unsure about the process, is to temporarily drop it and concentrate on coding, hoping that a last-minute Herculean effort will bring the project back on schedule. What usually happens is that the team makes that one milestone on time but is left with a model and a set of project artifacts in such disarray that they are out of date, virtually unusable, and unable to help meet the next impending milestone. The cycle repeats, and the project continues to slip.

Ironically, in situations like this, when the schedule starts to slip, an even stronger commitment to the process is needed. In an incremental process, this slippage is considered an invaluable metric of the process. It guides future iteration plans. Slipping schedules and significant defects rates are key metrics to be monitored and are not meant to be hidden for fear of bad press. For iterations to be successful and to drive the project, each iteration result, whether good or bad, needs to be considered and used.

• Review and refine the iteration plan. Before the iteration, the team takes a look at the iteration plan. The project manager makes resource allocations, and the team makes its deliverable commitments.
• Review progress with stakeholders. Often the stakeholders are very interested in the progress of the project. Sometimes this review is required to retain funding. As a result, this activity can be either a dog-and-pony show with a lot of hand waving by an overextended and troubled team or an honest appraisal of the project's status. Needless to say, an honest review of progress is in everyone's long-term best interest.
• Evaluate iteration and adjust next iteration's plan. The team needs to do some serious soul searching and self-evaluation. Have the deliverables been made with the expected effort?[14] Is the level of quality what was expected by the team? Did it meet your personal expectations? These are all important measures that need to be reflected in the next iteration's plan.

  [14] Count the number of nights the pizza was ordered for the team to support a late night of work that week the iteration deadlines were due. Having more than two nights of boxes is a not a good sign.