THIS book continues a new approach to understanding the key development issues that constantly distract important software projects from delivering effective software, because they aren't documented in most organizations. It has been known for many years that an effective software development lifecycle will deliver good software with fewer defects than the uncontrolled random iteration of code and requirement. The initial book defined the core development stages and lifecycle. The second volume provides the management, testing, and delivery phases of development.

The world of software and system development is changing. Tools and languages are starting to gain de facto standards that are allowing projects to develop the more complex systems being demanded by the business and end users. As more people join the software industry, experience is being stretched and it is becoming more difficult to find senior developers with more than three strong projects behind them. Communicating experience is becoming one of the most important success factors to most development teams. Quality systems are fine for defining the letter of the law and rules that must be obeyed to keep a project on track, but they often miss the guidance and explanation of why it is important to follow the steps outlined in their often hundreds of pages. These can make quality systems very unapproachable by the average developer.

Scott's book provides an intuitive and clearly written guide to the key issues, concepts, deliverables and processes needed to deliver a successful project.

THE FOURTH SERIAL PHASE of the OOSP is the Maintain and Support phase, commonly referred to as maintenance and support in the structured world. This is where you keep the application running and as up-to-date as possible by:

• supporting the efforts of users by providing training, answering their questions, and fixing any problems that they may encounter.

• identifying any possible bugs with the application, prioritizing those bugs, and then addressing those bugs in a future release.

• identifying any possible enhancements that can be made to the application, prioritizing those enhancements, and then making those enhancements in a future release of the application.

WHEN we left off in Process Patterns (Ambler, 1998b) I had taken you to the point where your software was written. Now in More Process Patterns I'll show you how to deliver, and then maintain and support applications built using object-oriented (OO) technology. Sadly, these are two topics that have been generally overlooked by the object community, until now. There is a lot more to OO development than writing code. There is also a lot more to it than creating use cases, CRC models, and class diagrams. OO development is about creating applications that solve the needs of your users. It's about doing this in such a way that the applications that are built are timely, accurate, and of high quality. This book is about helping you to accomplish these worthy goals.

In this chapter I summarize key concepts presented in Process Patterns. I explore common myths about object-oriented development; describe what process patterns are all about; discuss the object-oriented software process (OOSP) focusing on the serial phases, iterative stages, and the project and cross-project tasks that are vital to the success of your software efforts; and overview the Software Engineering Institute (SEI)'s Capability Maturity Model (CMM).

Exploring Object-Oriented Myths

One thing that you have likely read is that OO development by its very nature is iterative. As you saw in Process Patterns this is only partly true. The main components of OO development—modeling, programming, and testing in the small (formerly known as unit testing)—are in fact performed iteratively.

THE goal of the Maintain and Support phase, the fourth serial phase of the object-oriented software process (OOSP), is to keep your application running in production and to ensure that changes to the application are identified and acted on appropriately. Common forces applicable to this stage are the unwillingness of senior management to adequately fund maintenance and support efforts, the unwillingness of “hard-core” developers to perform maintenance activities (or to even recognize their importance), and the difficulty of finding and retaining support staff.

The process pattern depicted in Figure 7.1 shows that the Maintain and Support phase is comprised of two stages: the Support stage (Chapter 8) and the Identify Defects and Enhancements stage (Chapter 9). The Maintain and Support phase begins for an application after it has been successfully delivered to your customers—your user, support, and operations communities. The main output of this phase is a series of maintenance changes that have been allocated to the configuration items (CIs) that make up your application, changes that are accompanied by the software problem reports (SPRs), and software change requests (SCRs) from which they were generated.

The purpose of the Support stage is to respond to incoming support requests from users; to identify a resolution for the issue; and then to oversee the implementation of that resolution.

ORGANIZATIONS have moved beyond the pilot project stage and are now using object technology to build large-scale, mission-critical business applications. Unfortunately they are finding that the processes that proved so successful on small, proof-of-concept projects do not scale very well for real-world development. Today's organization needs a collection of proven techniques for managing the complexities of large-scale, object-oriented software development projects: a collection of process patterns. A process pattern describes a collection of general techniques, actions, and/or tasks for developing object-oriented software. In many ways process patterns are the reusable building blocks from which your organization can tailor a mature software process. To be fair, however, it isn't enough to just have a collection of process patterns, you must have a pattern language of process patterns that fit together as a consistent whole, that form a complete software process. That is what Process Patterns and its sister book More Process Patterns provide.

The object-oriented software process (OOSP) presented in these two volumes is a collection of process patterns that are geared toward medium to large-size organizations that need to develop software to support their main line of business. Although the OOSP could easily be modified for the development of shrink-wrapped software, I would rather point you in the direction of the Unified software process. The Unified software process was created by a leading maker of shrink-wrapped development tools. There is no such thing as a one-size-fits-all process, and the OOSP is just one of several approaches to developing object-oriented (OO) software.

THE OBJECT-ORIENTED SOFTWARE PROCESS (OOSP) is held together by a collection of project and cross-project tasks that support your organization's efforts to develop software. Although I have touched on them throughout this book, I have yet to specifically focus our attention on them. Until now. Furthermore, I have yet to discuss the means through which you can successfully introduce process patterns into your organization.

This is a great book about using object technology. Like all the new books in this area, it uses the Unified Modeling Language (UML), which is the standard notation for expressing object-oriented designs. For me, however, Tried & True Object Development really stands out from the recent flood of books on UML. Why? Because, this book is about the realities of object-oriented software engineering written from a position of authority. That authority is based on the authors’ many years of experience developing complex software in Nokia, one of the world's most successful hi-tech corporations. The authors know the secrets of successful object-oriented development from the inside.

However, this book is much more than an experience report, it is truly about how to engineer software. Thus, unlike many other books, it is not written from the perspective of the single engineer working on a small new application. Instead it focuses on how real-world teams, large and small, can use UML and object-oriented methodology. It covers all the phases of software development from requirements through testing. It shows how the fundamental techniques for each of these phases can be molded into an incremental evolutionary lifecycle that can deal with project risk.

Real projects have to handle many problems that lie outside the tidy theories of object-oriented methodologies. This book faces up to those issues. For example, it covers how to make objects persistent using a relational database, and how object-oriented design interfaces with GUI design.