The tools and environment used in the software process generally have a linear effect on the productivity of the process. Planning tools, requirements management tools, visual modeling tools, compilers, editors, debuggers, quality assurance analysis tools, test tools, and user interfaces provide crucial automation support for evolving the software engineering artifacts. Above all, configuration management environments provide the foundation for executing and instrumenting the process. At first order, the isolated impact of tools and automation generally allows improvements of 20% to 40% in effort. However, tools and environments must be viewed as the primary delivery vehicle for process automation and improvement, so their impact can be much higher.
Section 3.2 focused on process improvements that reduce scrap and rework, thereby eliminating steps and minimizing the number of iterations in the process. The other form of process improvement is to increase the efficiency of certain steps. This is one of the primary contributions of the environment: to automate manual tasks that are inefficient or error-prone. The transition to a mature software process introduces new challenges and opportunities for management control of concurrent activities and for tangible progress and quality assessment. Project experience has shown that a highly integrated environment is necessary both to facilitate and to enforce management control of the process. An environment that provides semantic integration (in which the environment understands the detailed meaning of the development artifacts) and process automation can improve productivity, improve software quality, and accelerate the adoption of modern techniques. An environment that supports incremental compilation, automated system builds, and integrated regression testing can provide rapid turnaround for iterative development and allow development teams to iterate more freely.
An important emphasis of a modern approach is to define the development and maintenance environment as a first-class artifact of the process. A robust, integrated development environment must support the automation of the development process. This environment should include requirements management, document automation, host/target programming tools, automated regression testing, continuous and integrated change management, and feature/defect tracking. A common thread in successful software projects is that they hire good people and provide them with good tools to accomplish their jobs. Automation of the design process provides payback in quality, the ability to estimate costs and schedules, and overall productivity using a smaller team. Integrated toolsets play an increasingly important role in incremental/iterative development by allowing the designers to traverse quickly among development artifacts and keep them up-to-date.
Round-trip engineering is a term used to describe the key capability of environments that support iterative development. As we have moved into maintaining different information repositories for the engineering artifacts, we need automation support to ensure efficient and error-free transition of data from one artifact to another. Forward engineering is the automation of one engineering artifact from another, more abstract representation. For example, compilers and linkers have provided automated transition of source code into executable code. Reverse engineering is the generation or modification of a more abstract representation from an existing artifact (for example, creating a visual design model from a source code representation).
Round-trip engineering describes the environment support needed to change an artifact freely and have other artifacts automatically changed so that consistency is maintained among the entire set of requirements, design, implementation, and deployment artifacts. This concept is developed more fully in Chapter 12.
As architectures started using heterogeneous components, platforms, and languages, the complexity of building, controlling, and maintaining large-scale webs of components introduced new needs for configuration control and automation of build management. However, today's environments do not come close to supporting automation to the extent possible. For example, automated test case construction from use case and scenario descriptions has not yet evolved to support anything beyond the most trivial cases, such as unit test scenarios.
One word of caution is necessary in describing the economic improvements associated with tools and environments. It is common for tool vendors to make relatively accurate individual assessments of life-cycle activities to support claims about the potential economic impact of their tools. For example, it is easy to find statements such as the following from companies in a particular tool niche:
• Requirements analysis and evolution activities consume 40% of life-cycle costs.
• Software design activities have an impact on more than 50% of the resources.
• Coding and unit testing activities consume about 50% of software development effort and schedule.
• Test activities can consume as much as 50% of a project's resources.
• Configuration control and change management are critical activities that can consume as much as 25% of resources on a large-scale project.
• Documentation activities can consume more than 30% of project engineering resources.
• Project management, business administration, and progress assessment can consume as much as 30% of project budgets.
Taken individually, none of these claims is really wrong; they are just too simplistic. (Given these claims, no wonder it takes 275% of budget ánd schedule resources to complete most projects!) When taken together, the claims can be very misleading. Beware of this type of conclusion:
This testing tool will improve your testing productivity by 20%. Because test activities consume 50% of the life cycle, there will be a 10% net productivity gain to the entire project. With a $1 million budget, you can afford to spend $100,000 on test tools.
The interrelationships of all the software development activities and tools are far too complex for such simple assertions to be reasonable. In my experience, the combined effect of all tools tends to be less than about 40%, and most of this benefit is not realized without some corresponding change in process. It is unlikely that any individual tool will improve a project's productivity by more than 5%. In general, you are better off normalizing most vendor claims to the virtual 275% total than the 100% total you must deal with in the real world.
Was this article helpful?
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.