Overview of Software Development

A software development process has four roles.

• Provide guidance about the order of a team's activities.
• Specify artifacts that should be developed.
• Direct the tasks of individual developers and the team as a whole.
• Offer criteria for monitoring and measuring the project's products and activities.[1]

  [1] 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.[2] 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.

[2] 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)[3] and the ICONIX Unified Process.[4] 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."[5] 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.[6] 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.

[3] An introduction to the process is provided by Philippe Kruchten, The Rational Unified Process: An Introduction, Second Edition (Boston, MA: Addision-Wesley, 2000).

[4] See Doug Rosenberg with Kendall Scott, Use Case Driven Object Modeling with UML: A Practical Approach (Boston, MA: Addision-Wesley, 1999).

[5] 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).

[6] See http://www.rational.com/rup.

One additional process that deserves mention is significantly different from the ones already mentioned: eXtreme Programming (XP).[7] 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.

[7] 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

• Use case driven
• Architecture-centric
• Iterative and incremental

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.

• Makeup of the company and organization. Large companies with pools of specialized talent may be more successful with an artifact-heavy process. In these types of organizations, team members perform one role and a small set of activities that are particularly suited to their talents and experience. Because of the large number of people involved, the need for formal communications among project team members is important. This means that the artifacts of the process must be complete and comprehensive. A greater emphasis on the review process might be appropriate because it is unlikely that team members will be participating in downstream activities and be able to provide explanations of earlier decisions.

  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.

• The nature of the application. What the application has to do can affect the structure of its development process tremendously. Human-critical applications, such as medical devices, spacecraft systems, and thermonuclear controls, obviously require a great deal of quality control. In these situations, strong emphasis is placed on quality assurance (QA), which includes reviews and testing. The rhythm of iterations in the process is established primarily by the successful completion of QA objectives.

  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.

• The skill level of the development staff. When implementing a process, the team's skill level should be taken into account. Relatively inexperienced teams require a more defined process, one in which peer reviews are more prominent. For these types of team, the development process is as much a learning process as anything else.
• The relative priorities of feature set, time to delivery, acceptable defect count, and so on. Whatever is important in the final system will obviously determine which elements of the development process are important. If getting the product to market first is the most important goal, reviews and inspections might be decreased, and the ability to remove requirements from the initial release might be given greater importance. The development process in this situation is tailored for quick delivery. When a rich feature set is important, it is important to ensure compatibility, and this means greater emphasis on analysis.

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.[8] 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.

[8] 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.