Tools Automation Building Blocks

Many tools are available to automate the software development process. This section provides an overview of the core environment necessary to support the process frame-


Management Environment Requirements Design





Life Cycle figure 12-1. Typical automation and tool components that support the process workflows work. It introduces some of the important tools that tend to be needed universally across software projects and that correlate well to the process framework. (Many other tools and process automation aids are not included.) Most of the core software development tools map closely to one of the process workflows, as illustrated in Figure 12-1.

Each of the process workflows has a distinct need for automation support. In some cases, it is necessary to generate an artifact; in others, it is needed for simple bookkeeping. Some of the critical concerns associated with each workflow are discussed next.


There are many opportunities for automating the project planning and control activities of the management workflow. Software cost estimation tools and WBS tools are useful for generating the planning artifacts. For managing against a plan, workflow management tools and a software project control panel that can maintain an on-line version of the status assessment are advantageous. This automation support can considerably improve the insight of the metrics collection and reporting concepts discussed in Chapter 13. The overall concept of a software project control panel is discussed in Section 13.6.

Environment Tools and Process Automation

Workflow automation, metrics automation

Change management, document automation

Requirements management

Visual modeling


Test automation, defect tracking

Defect tracking

Organization Policy





figure 12-1. Typical automation and tool components that support the process workflows


Configuration management and version control are essential in a modern iterative development process. Much of the metrics approach recommended in Chapter 13 is dependent on measuring changes in software artifact baselines. Section 12.2 discusses some of the change management automation that must be supported by the environment.


Conventional approaches decomposed system requirements into subsystem requirements, subsystem requirements into component requirements, and component requirements into unit requirements. The equal treatment of all requirements drained away engineering hours from the driving requirements, then wasted that time on paperwork associated with detailed traceability that was inevitably discarded later as the driving requirements and subsequent design understanding evolved.

In a modern process, the system requirements are captured in the vision statement. Lower levels of requirements are driven by the process—organized by iteration rather than by lower level component—in the form of evaluation criteria. These criteria are typically captured by a set of use cases and other textually represented objectives. The vision statement captures the contract between the development group and the buyer. This information should be evolving but slowly varying, across the life cycle, and should be represented in a form that is understandable to the buyer. The evaluation criteria are captured in the release specification artifacts, which are transient snapshots of objectives for a given iteration. Evaluation criteria are derived from the vision statement as well as from many other sources, such as make/buy analyses, risk management concerns, architectural considerations, implementation constraints, quality thresholds, and even shots in the dark.

Iterative models allow the customer and the developer to work with tangible, evolving versions of the system. Pragmatically, requirements can—and must—be evolved along with an architecture and an evolving set of application increments. In this way, the customer and the developer have a common, objective understanding of the priorities and the cost/schedule/performance trade-offs associated with those requirements. Rather than focus on consistency, completeness, and traceability of immature requirements specifications, projects need to focus on achieving the proper specification of the project vision and to evolve the lower level specifications through successive sets of evaluation criteria against the evolving design iterations.

The ramifications of this approach on the environment's support for requirements management are twofold:

1. The recommended requirements approach is dependent on both textual and model-based representations. Consequently, the environment should provide integrated document automation and visual modeling for capturing textual specifications and use case models. It is necessary to manage j and track changes to either format and present them in human-readable ! format, whether electronic or paper.

2. Traceability between requirements and other artifacts needs to be automated. The extent of traceability among sets, however, is the subject of a ; long-standing debate. My opinion is that the requirements set artifacts need a well-defined traceability to the test artifacts, because the overall assessment team is responsible for demonstrating the product's level of compliance with the requirements. However, I do not see any compelling reason to pursue strong traceability relationships between the requirements :

set artifacts and the other technical artifacts. The problem space description, as represented in the requirements set, and the solution space description, as represented in the other technical artifact sets, often have traceability that is very difficult to represent. This is especially true in com-ponent-based architectures that have a large percentage of commercial ¡

components. If the process demands tight traceability between the requirements and the design, the architecture is likely to evolve in a way that optimizes requirements traceability rather than design integrity. This effect is even more pronounced if tools are used to automate this process.


The tools that support the requirements, design, implementation, and assessment workflows are usually used together. In fact, the less separable they are, the better. The primary support required for the design workflow is visual modeling, which is used for capturing design models, presenting them in human-readable format, and translating them into source code. An architecture-first and demonstration-based process is enabled by existing architecture components and middleware.


The implementation workflow relies primarily on a programming environment (editor, compiler, debugger, linker, run time) but must also include substantial integration with the change management tools, visual modeling tools, and test automation tools to support productive iteration.

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


  • derek
    What is process automation building blocks in spm?
    4 years ago
  • Nathan
    What are the components that supports different workflows of spm?
    2 years ago

Post a comment