Analysis and Design and the SEI CMM

< Free Open Study >

Analysis and Design and the SEI CMM Quality software project management is based upon three interlaced bodies of knowledge: the Project Management Institute's Body of Knowledge (PMBOK), IEEE standards and processes, and the SEI capability maturity model. Discussions of the CMM are threaded throughout the book, particularly in Chapter 4, "Selecting Software Development Life Cycles," and in Chapter 26, "Continuous Process Improvement." Software project managers are strongly urged to operate at maturity Level 2, the repeatable level, at a minimum. As an organization moves up the maturity ladder, visibility into the software process improves with each level, as does the improvement of control, predictability, and effectiveness. Level 3, the defined level, should be a goal for all software-producing organizations currently operating below it. At Level 3, integrated management and engineering processes are used across the organization. A key process area within Level 3 is software product engineering (SPE). This KPA involves performing the engineering tasks to build (and maintain) the software using the project's defined software process and appropriate methods and tools�those methods may be based on SA/SD or OOA/OOD. According to Paulk, goals of SEI CMM KPA SPE are these: Goal 1: The software engineering tasks are defined, integrated, and consistently performed to produce the software. Goal 2: Software work products are kept consistent with each other. Activities performed include: Activity 1: Appropriate software engineering methods and tools are integrated into the project's defined software process. Activity 2: The software requirements are developed, maintained, documented, and verified by systematically analyzing the allocated requirements according to the project's defined software process. The individuals involved in developing the software requirements review the allocated requirements to ensure that issues affecting the software requirements analysis are identified and resolved. Software requirements cover the software functions and performance, the interfaces to both hardware and software, and other system components (e.g., humans). Examples of methods for requirements analysis include functional decomposition, object-oriented decomposition, trade-off studies, simulations, modeling, prototyping, and scenario generation. Activity 3. The software design is developed, maintained, documented, and verified, according to the project's defined software process, to accommodate the software requirements and to form the framework for coding. Design criteria are developed and reviewed. Examples of design criteria include verifiability, adherence to design standards, ease of construction, simplicity, and ease of planning. Effective methods are used to design the software. Examples of software design methods include prototyping, structural methods, design reuse, object-oriented design, and essential systems analysis. The software architecture is developed early, within the constraints of the software life cycle and technology being used.[1] The software architecture establishes the top-level software framework with well-defined internal and external interfaces. In this chapter, we present the specific methods of functional decomposition (data flow diagrams, control flow diagrams), object-oriented decomposition (classes, objects, interaction diagrams, activity diagrams), and scenario generation (use cases). We also present structural methods (structure charts, Chapin charts), object-oriented design (classes, objects, interaction diagrams, activity diagrams, use cases), and essential systems analysis. The "bottom line" is that the PM who follows the suggestions in this chapter will satisfy the requirement for KPA software product engineering at SEI CMM Level 3. Chapter 16, "Eliciting Requirements," presented high-level generic templates for data modeling in the form of entity relationship diagrams (ERDs), process modeling in the form of data flow diagrams (DFDs and use cases), and process/data modeling (object models). These representations of software requirements are useful during interviewing, brainstorming, and JAD sessions as communication devices. They are not detailed enough, however, to serve as the blueprint for coding and implementation. There are more steps in the development-by-stepwise-refinement process to get the models to that state. The analogy of home construction is frequently used. High-level analysis models are analogous to the drawings that an architect shows to the homeowner�the "look and feel" of the structure. Should there be two bedrooms or three? Should there be one bath or two? Should the garage appear at the front or rear of the home? Lower-level analysis and design models, while available to the homeowners, are not nearly as interesting to them�these documents show where the electrical circuitry and plumbing are to be placed, analogous to the contractors working with a blueprint. In this analogy, software analysis and design transition the product from "architectural renderings" to the final, detailed electrical, structural, and mechanical blueprints.

< Free Open Study >