B. Software process improvement plan
Figure 12-5. Organization policy outline
Figure 12-5. Organization policy outline personnel and determine whether the organization does what it says. Figure 12-5 shows a general outline for an organizational policy.
The organization environment for automating the default process will provide many of the answers to how things get done as well as the tools and techniques to automate the process as much as practical. Some of the typical components of an organization's automation building blocks are as follows:
• Standardized tool selections (through investment by the organization in a site license or negotiation of a favorable discount with a tool vendor so that project teams are motivated economically to use that tool), which promote common workflows and a higher ROI on training
• Standard notations for artifacts, such as UML for all design models, or Ada 95 for all custom-developed, reliability-critical implementation artifacts
.• Tool adjuncts such as existing artifact templates (architecture description, evaluation criteria, release descriptions, status assessments) or customi-zations
• Activity templates (iteration planning, major milestone activities, configuration control boards)
• Other indirectly useful components of an organization's infrastructure
• A reference library of precedent experience for planning, assessing, and improving process performance parameters; answers for How well? How much? Why?
• Existing case studies, including objective benchmarks of performance for successful projects that followed the organizational process
• A library of project artifact examples such as software development plans, architecture descriptions, and status assessment histories
• Mock audits and compliance traceability for external process assessment frameworks such as the Software Engineering Institute's Capability Maturity Model (SEI CMM)
The transition to a modern iterative development process with supporting automation should not be restricted to the development team. Many large-scale contractual projects include people in external organizations that represent other stakeholders participating in the development process. They might include procurement agency contract monitors, end-user engineering support personnel, third-party maintenance contractors, independent verification and validation contractors, representatives of regulatory agencies, and others.
These stakeholder representatives also need access to development environment resources so that they can contribute value to the overall effort. If an external stakeholder team has no environment resources for accepting on-line products and artifacts, the only vehicle for information exchange is paper. This situation will result in the problems described in Chapter 6 as inherent in the conventional process.
An on-line environment accessible by the external stakeholders allows them to participate in the process as follows:
• Accept and use executable increments for hands-on evaluation
• Use the same on-line tools, data, and reports that the software development organization uses to manage and monitor the project
• Avoid excessive travel, paper interchange delays, format translations, paper and shipping costs, and other overhead costs
Figure 12-6 illustrates some of the new opportunities for value-added activities by external stakeholders in large contractual efforts. There are several important reasons for extending development environment resources into certain stakeholder domains.
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.