Elaine manages a software product that is sold to laboratories. New releases take about six months each year. Most are technology changes. Elaine's staff and I built models capturing industry knowledge and other models for design concepts. The models formed baselines for design discussions. Revisions to them became new baselines. By reviewing the knowledge models separate from the implementation, Elaine figures she has saved two months of rehashing and reconstructing information.
Illustrators model to explore the problem statement and uncover implied and derived requirements. Illustrator practice applies technical rules for model completeness, quality, and usefulness. Because good requirements are stressed, illustrator requirements usually include business goals, problem statements, and measures of success.
Illustrator practice reflects a mature modeling practice, integrating modeling and project planning processes. But this practice falters when model or library size exceeds the limits or capabilities of the tool technology being used.
Tim, an automotive engineer, and his colleagues have learned to track errors caught in simulation, comparing them to errors and debug time from their previous release. This early testing carves hours from expensive debugging and recoding. Management is now exploring integrated software and hardware simulation for vehicle testing and reducing full reliance on costly physical prototypes.
Kinetic practice centers on executable models. For highly complex systems with significant risks, model simulation exposes failure points early. Algorithms, logic paths, performance, conformance to requirements, and industry and regulatory standards get tested. Kinetic practice stresses model integrity and industrial-strength tools. Requirements may be detailed like the contract pattern, but emphasis is on identifying and containing risks.
Kinetic practice brings engineering discipline to software development. This approach proves itself with high-risk, complex systems. But this approach won't work if management won't budget for the tools, schedule time, or library support.
Kim manages a group of environmental control engineers that relies on reusable domain models and model translation. They've released three products based on this process and using translator tools. Last year a new product line used the team's models. The new software was ready for system test three months ahead of schedule. This year Kim told me she was assigned to a sister engineering group in France to share the control models and to teach them the process.
Vanguard practice recognizes models as corporate assets. Reusable models are cataloged by subject. Models are one ingredient for code translation. The vanguard modeler would say, "the models are the code." The models capture subject knowledge and system service abstractions. Design patterns, implementation rules, libraries, and model elements are fit to a particular architecture. Translator tools use this information to produce code.
Vanguard practice changes a technical process into a business practice, and will succeed as long as the culture upholds that belief and its investment in tools.
Putting It in Practice
One of my clients who has an artisan modeling practice hopes to step up their CMM rating, which enables them to compete in new areas. We used these patterns in discussing changes to their processes and measures. You may recognize more than one of these patterns in your organization and notice that practice varies according to organizational style, requirements process, and system complexity.
I would like to express appreciation for the SEI's CMM/CMMI and Gerald M. Weinberg's Software Engineering Cultural Patterns.