By Dave Ingram


About Me

My Journey

About DBR


Part I

Part I: Production-Ready Software

Chapter 1: "Production" Readiness

Developing and implementing a software system is a complicated and tricky business. In fact, "developing" and "implementing" are really two different but very interrelated disciplines. For the purposes of this book, "implementing a software system" refers to the activities and processes required to get a software system from an initial concept into live service or production, whereas "developing a software system" refers to the activities and processes of actual software construction and proving. This chapter is organized into the following sections:

What Is Production Readiness? On the one hand, production readiness assesses whether your system meets all the necessary criteria for live service. On the other hand, production readiness also refers to your readiness to produce or manufacture software. This section reviews the high-level activities involved in the system development lifecycle and how they map to some mainstream software development methodologies. Software systems, whether large or small, include a variety of applications, environments, processes, and tools, as well as a number of different users. The foundation criteria for software development and implementation are:

  • Applications must be fit for purpose.
  • Environments must be fit for purpose.
  • Processes and tools must be fit for purpose.
  • Users must be trained.
Why Is Production Readiness Important? Some software projects fail or are seen to be a failure. You need to do everything that you can to ensure that your software development and implementation projects are successful. This section discusses some of the most important and common contributors to project failure, including poor scope, poor planning and execution, and poor quality.

The Production -Readiness "Process" — This section builds on the previous ones to provide some foundation principles for software development and implementation, which provide the basis of the production -readiness "process." I've put "process" in quotes because it is not really a formal process; rather, it is a mindset. You need to really think about what you're going to do, how you're going to it, and who you're doing it for.

Chapter 2: The Quality Landscape

The software quality landscape encompasses the categories and measures for defining and maintaining software quality. The measures are intended to reduce the number of defects that are found out late in the process and to produce high-quality code and artifacts throughout the project. There's no doubt that quality has costs associated with it, but the extent to which it actually costs needs to be understood, controlled, and minimized without compromising the final result. This chapter is organized into the following sections:

The Quality Characteristics — Provides an overview of the individual quality characteristics, including correctness and completeness, usability, accessibility, reliability and stability, performance, efficiency, availability, integrity and security, operability and supportability, deployability, configurability, maintainability, readability, reusability, modularity, flexibility and extensibility, and testability.

Why Quality (and Scope) Matter — Takes a look at a robust construction phase and the activities performed to get a realistic picture of what's involved in quality construction. This section also covers how budgets and timescales are affected if the appropriate scope isn't factored in accordingly. I then look at what potentially lies beyond the construction phase, including overlapping test phases, the profile of defects during testing, turning around defects, hot-fixing, technical tuning and re-factoring, and sweeping. I describe how some of these activities lead to a drop in the quality bar and outline a number of practices that you can employ to improve and maintain quality and productivity.

Quality Comes at a Price — Provides an overview of the financial matters involved in quality construction, and a basis for understanding the financial implications to assist in the decision-making process. The section also looks at calculating the potential cost of defects and performing cost/benefit analyses, and, finally, looks at the implications of realistic estimating to ensure that the scope, budget, and timescales are set and agreed on.

Chapter 3: Preparing for "Production"

This chapter examines some of the key areas you should consider when setting up your software-development production line. With a well-oiled production line, you should be able to develop anything and get high quality products out the end. We're not concentrating so much on the final solution, although its size and scale will affect some of the decisions you make. As with any kind of manufacturing, you need the right raw materials, the right processing, and the right quality controls. There are many processes that you need to establish before starting full-on production (e.g., development) to ensure that you are in a position to produce high quality outputs and I tend to use the word "defining" for a lot of the activities described. In the majority of cases, I am actually referring to "defining and implementing." This chapter is organized into the following sections:

Preparation Is Paramount — Examines the high-level activities that you perform during the project and shows how they can be broken down to ensure they are mobilized effectively. It also discusses the key constraints that should be identified when mobilizing any activities.

Build, Release, and Regular Integration Mobilization — The build and regular integration activities are vital to ensuring that you can build and release your software. This section discusses this process along with some of the different releases and their typical contents.

Test Mobilization — Testing is where you're going to prove your application works the way it should. Having solid foundations in place for testing will help your project. This section looks at some of the specifics in mobilizing your testing activities.

Defect Management (and Fix) Mobilization — Testing, as well as other activities, is going to raise defects. This section looks at defect management, including the workflow and the contents of defects, and discusses some ways of how defects can be categorized for management (and reporting) purposes.

Configuration Management Mobilization — You need to store all your artifacts somewhere, and this section discusses the configuration-management system and processes. It looks at some of the items that you can choose to place under configuration management and how they can be organized to meet the needs of the project. It also discusses branching and merging, which may be required.

Change Control Mobilization — Things are going to change, so you need to be ready to assess changes appropriately. You also need to ensure that the change process is followed.

Chapter 4: The Ins and Outs of Construction

In the previous chapters, I' ve outlined a series of activities and actions that you should consider for each and every project you undertake. Although each project will be different, the underlying principles and foundations for production readiness remain the same. This chapter completes the high-level overview of the production-readiness landscape by taking a closer look at some of these inputs and discussing how to refine them to ensure you have the right level of detail for construction purposes. That' s not to say that you' ll get everything 100 percent right the first time, but you can at least give yourself the best shot at success. This chapter is organized into the following sections:

Thinking Out -of-the-Box — Regardless of whether you' re developing software for in-house use, external use, or even off-the-shelf purchase, there are some key contents to a software package, and these include:

  • The "back of the box," which typically shows the key features of the software, the business or usage benefits, key statistics, and other high-level sales collateral.
  • The "media," which are essentially the DVDs or CDs that contain the actual software, help files, and installation files.
  • The "User Guide," which provides all the instructions for using the software effectively and performing the day -to-day tasks.
  • The "Operations Manual" or "Administrators Guide," which provides all the instructions and information for planning deployment, installation, configuration, and for monitoring and operating the software.

This section looks at how you can map everything you do to these basic contents. By thinking about what would come "out-of-the-box," you can shape the high-level roadmap of the project and its ultimate development and implementation.

Considering the Design — This section looks at some of the high-level design considerations and how these will clearly have a domino effect on the remainder of the project. The more that you can define up front, the better the overall scope will be. Starting with a very simple picture, you can begin to extrapolate a number of areas that will require further analysis, discussion, and decisions.

The Analysis and Design Outputs — This section discusses in detail how to use the following outputs of the analysis and design activities to further define the project and the out -of-the-box contents. The analysis and design outputs are the primary inputs into the construction activities. Good inputs can provide the basis for realistic estimates and, in turn, provide the very basis of the construction outputs (for example, the completed solution).

  • Scope (the items that are in or out of scope)
  • Requirements (both functional and non -functional)
  • Use-case diagrams and use cases
  • Navigation maps
  • Storyboards
  • Page layouts and specifications
  • The data dictionary and logical data model
  • Architecture and application component specifications
HomeAbout MeMy JourneyAbout DBROutlineExcerpts
Part I
Part II
Part III
Part IV
Part V