A software development process has four roles.
 See Grady Booch, Object Solutions: Managing the Object-Oriented Project (Boston, MA: Addison-Wesley, 1996).
A software development process is packaged as a set of documents, or it could be an online hypertext system. The process defines the workflows, activities, artifacts, and workers in the development process (Figure 6-1). A worker in this sense is a role performed by an individual in the process. In many projects, any given individual may perform the activities of several of these workers (roles).
Figure 6-1. Roles in the software development process: workflows, workers, activities, and artifacts
A workflow is set of activitiesrequirements, analysis, design, implementation, testing, and deploymentthat ultimately produce a tangible and observable result. Workflows are things. Each workflow typically requires several workers to complete and a number of activities and artifacts.
Workflows define a set of activities that the workers engage in. Activities are the things that the workers do to produce the output artifacts of the workflow. An artifact is any persistent piece of information that is produced by the workers during the process. Artifacts are models, model elements, source code, and documents. An important property of an artifact is that it can be version controlled. An artifact often undergoes significant change during the process, and an accurate history of its evolution is critical to the process as a whole. Another key aspect of version control, or configuration and change management, is the association of change control and project tasks with discrete artifact versions. This level of artifact traceability allows team members to track discrete tasks with artifact versions and enables project management to estimate realistic costs of activities throughout the process.
 See Brian A. White, Software Configuration Management Strategies and Rational ClearCase: A Practical Introduction (Boston, MA: Addison-Wesley, 2000).
The process discussed here has its roots in the Rational Unified Process (RUP) and the ICONIX Unified Process. Both are essentially refinements of earlier object-oriented processes and methodologies based on the work of Grady Booch, Ivar Jacobson, and Jim Rumbaugh: the "three amigos." The process has also evolved somewhat from the one described in the first edition of this book. Since that time, I've had the opportunity to work with various groups of architects and Web application developers. I've tried to collect these experiences, distill some of the good development practices I've seen, and incorporate them into this latest version of the software development process for Web applications. If you are serious about using a scalable and well thought-out software development process, my recommendation is to get the Rational Unified Process or one of its tailored variants. These processes are not the only formal processes in use today but are the ones I am most familiar with, ones that I have used successfully, and unsuccessfully.
 An introduction to the process is provided by Philippe Kruchten, The Rational Unified Process: An Introduction, Second Edition (Boston, MA: Addision-Wesley, 2000).
 See Doug Rosenberg with Kendall Scott, Use Case Driven Object Modeling with UML: A Practical Approach (Boston, MA: Addision-Wesley, 1999).
 A more recent view of their collaborative work, and a useful companion to The Rational Unified Process, is Ivar Jacobson, Grady Booch, and Jim Rumbaugh, The Unified Software Development Process (Boston, MA: Addision-Wesley, 1999).
 See http://www.rational.com/rup.
One additional process that deserves mention is significantly different from the ones already mentioned: eXtreme Programming (XP). I have never worked in an XP-driven project, so my knowledge of it is limited; however, like most modern software processes, it includes a healthy respect for visual modeling and quality control. So if you are doing XP, much of the modeling content of this book is still applicable.
 Refer to Kent Beck, Extreme Programming Explained: Embrace Change (Boston, MA: Addison-Wesley, 1999).
The key aspects of the process described here are that it is
Like most modern development processes, this one is iteratively based (Figure 6-2). This means that each workflowrequirements, analysis, design, implementation, test, evaluationof the process is repeated and refined until it meets the system's requirements and is deployed. This is a significant departure from the traditional waterfall process, in which each project workflow was completed before the team moved on to the next one. Iterative processes came to be by simply acknowledging that software isn't created in a strict waterfall fashion. In all but the most exceptional cases, each phase of the project discovers issues and circumstances that question, and even change, decisions made in earlier phases. In the past, those changes were dealt with informally. Today, they are acknowledged and even planned for in the process.
Figure 6-2. Iterative process (Source: Philippe Kruchten, The Rational Unified Process: An Introduction, Second Edition (Boston, MA: Addison-Wesley, 2000, p.7)).
The process outlined here is not intended to be used directly. In practice, any process needs to be tailored for each organization that uses it. Processes that are taught or found in a book are basically abstract. Implementing a development process is a process itself. It's very unlikely that you can walk into an organization, plop down a book, and say, "This is our software development process; read it, and we begin tomorrow." It won't work: not for the obvious reason that a day isn't long enough to read and digest a book but for the fact that the process needs to take into account a number of factors not available to the authors. A process must consider the following in order to be tailored to the task.
At the other end of the spectrum, small project teams may prefer a more relaxed process. Teams that have worked successfully together in the past and whose group dynamics include good communications may not need the rigor of an artifact-laden process. These types of organizational structure rely on the proven abilities of the individual team members. This does not mean that a strong process is not required but rather that some aspects of the process, such as code reviews and formal meetings, play a less important role than others do.
Given the present state of Web application technologies, it is unlikely that a human-critical Web application will be built soon. Still, other factors of the application can influence the process of building Web applications. For example, international applications may require significantly more up-front effort during analysis than others, placing a greater emphasis on the nonfunctional requirements and processes. Commerce applications have architectural and security implications that must be monitored during the process with additional reviews and exploratory prototypes. If the application's goal is to use a new technology rather than solve a specific business problem, defining strict requirements is not as important as allowing the team to take advantage of discoveries along the way.
It cannot be stated strongly enough that the software development process has to work with the people and the goals of the effort if it is to be successful. A process is no good if it is not used. Huge monolithic processes that fill volumes of shelf space often go untouched because they didn't consider the people who had to use them. To be successful, a process must be accepted and used by the team.
While delivering seminars and working with Web application development teams over the years, I've had many opportunities to ask, "What are the most important issues facing you and your development effort?" Almost without exception, the issue of rapid development ranks number one. Other notable issues include quality, security, building the right application, and dealing with the rapid advancement of technology.
One additional issue facing these teams is related to the artistic aspects of the application. Internet applications today depend heavily on a good look-and-feel. In many situations, getting to the marketplace first is only the first step; maintaining a fresh look-and-feel, or user experience, is critical in keeping your customer base.
To handle the artistic and creative side of project, a new type of teamthe user experience (UX) teamand new type of specialistthe information architect (IA)have been introduced into the organization. Stan Ward of Context Integration and Per Kroll of Rational Software Corporation have done some excellent work in the area of integrating the "creative" input into the software development process. A lot of the enhancements to the process here were influenced by their work, as well as by an examination of other cutting-edge Web development organizations.
 Stan Ward and Per Kroll, "Building Web Solutions with the Rational Unified Process: Unifying the Creative Design Process and the Software Engineering Process." A Context Integration and Rational white paper, available at http://www.rational.com/products/rup/prodinfo/whitepapers/dynamic.jtmpl?doc_key=101057.
The project goals of rapid development and high quality, along with the problems of the rapid pace of technology and reliance on artistic attributes, must influence the process. Additionally, the iteration schedule of Web applications is typically tighter than that of most other efforts, and the process must be suited to this fast pace of development. Fortunately, good sets of tools and frameworks exist today that maximize worker productivity.
Overview of Modeling and Web-Related Technologies
Building Web Applications