This section contains some descriptive and prescriptive thoughts about the general themes of process improvement. My goal is to instill a proper balance of hope and fear about the promises of process improvement.
• Process maturity. Compliance with quality process frameworks such as the SEI CMM does not necessarily result in the development of quality products. However, a truly high-quality process that produces quality products will be assessed as mature. One drawback of most process frameworks is that they specify a statically defined quality assurance program as someone's separate job rather than integrate quality assurance dynamically into all jobs.
• Cost of a mature process. A mature process does not cost more money. On the contrary, it always saves money in the long run. Because improving an immature process changes their spending profiles, organizations usually perceive a near-term cost for process improvement. The important point here is that selling process improvement to in-process projects, which are dominated by near-term cost concerns, is very difficult. Process improvement is sellable, however, to organizations that are more concerned with long-term business pursuits, and to long-term projects still in the planning stage.
• Software metrics. Objective measures are required for assessing the quality of a software product and the progress of the work—two different perspectives of a software effort. Architects are more concerned with quality indicators, while managers are usually more concerned with progress indicators. The success of any software process whose metrics are collected manually will be limited. The most important software metrics are simple, objective measures of how various perspectives of the product/project are changing. Absolute measures are usually much less important than relative changes with respect to time. Because of the dynamic nature of software projects, these measures must be available at any time, be tailorable to various subsets of the evolving product (subsystem, release, version, component, team), and be maintained so that trends can be assessed (first and second derivatives). Such continuous availability has been achieved in practice only when the metrics were maintained on-line as an automated by-product of the development environment.
• Process tailoring. Different software efforts require different processes. While there are some universal themes and techniques, there are also situation-dependent differences in techniques, priorities, ceremony, and emphasis. Different software development situations have different needs that span a range of good processes. An organization's internal process for product development will not be exactly the same as the process used by projects developing large operational systems on contract with an external customer.
• Process versus method. A project management process deals with different concerns than a technical method does. The former is characterized by iterative development, demonstration-based evaluation, and risk management, the latter by object-oriented techniques, architectural approaches, and UML representations. Although a bad management process will probably never be saved by a good method, a good management process can succeed with most technical methods. Clearly, some methods are better than others. The result of a good design method coupled with a good management process is profound. This is the goal.
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.