Embedded Files
- Rationale Management in Software Engineering
- Rationale methods aim at capturing, representing, and maintaining records about why developers have made the decisions they have.
- Rationale includes:
- The problems developers encountered,
- The options they investigated,
- The criteria they selected to evaluate options,
- The debate that lead to making decisions.
- Rationale can serve 2 different purposes:
- Discourse
- Knowledge Capture
- By making explicit the main decision making elements, rationale facilitates negotiation among developers by systematically clarifying the possible options and their evaluation against well-defined criteria.
- By capturing rationale, developers make explicit knowledge that is usually only implicit and can later examine the justification of certain decisions.
- Why integrate Rationale Methods in Software Engineering:
- (1) Software engineering, as in other design activities, involves:
- The collaboration of many participants from different backgrounds and requires the negotiated settlement of many issues.
- Rationale methods, as negotiation support, clarifies issues and their related trade-offs for the involved participants.
- (2) Software systems are complex and changing artifacts: They result from the making and reopening of many interdependent decisions.
- Capturing not only these decisions but also their dependencies and the justification behind them facilitates their reevaluation later in the development process.
- The capture and organization of rationale, while introducing an overhead during early phases of development is beneficial during later and more costly phases such as maintenance.
- (1) Software engineering, as in other design activities, involves:
- Knowledge Needed in Software Engineering
- System Knowledge:
- System Knowledge pertains to the system under construction.
- System Knowledge is represented by several models looking at the system from different points of view.
- The System Design Model describes the system in terms of components, boundary conditions, and global control flow.
- System Knowledge is used by developers to design and validate the system at various stages of development.
- Parts of the System Knowledge gained during a project can be generalized for the benefit of the organization.
- Process Knowledge:
- Process Knowledge pertains to the work required to develop the system, including knowledge about roles, resources, tasks, and work products.
- Process Knowledge makes clear the responsibilities of each participants and the tasks they are currently accomplishing.
- Process Knowledge is used by management and developers to plan and monitor work during development.
- As for System Knowledge, Process Knowledge can be generalized across projects.
- Product Knowledge:
- Product Knowledge includes the system and process knowledge gained and used by a specific project in the course of developing a single system or a single product line.
- Product Knowledge includes both System and Process Knowledge.
- A product’s System Knowledge comprises all the system models and the information specific to the system.
- A product's Process Knowledge comprises all of task plans, schedule, budget, and constraints specific to the development of the system.
- Organizational Knowledge:
- Organizational Knowledge includes the knowledge shared among the organization by multiple projects.
- System generalizations, such as domain models, design patterns, and software architectures,
- Process generalizations, such as generic process models and company procedures, are organizational knowledge.
- Organizational Knowledge is much more structured and long lived than Product Knowledge.
- Organizational Knowledge includes the knowledge shared among the organization by multiple projects.
- Rationale is the justification of decisions:
- Rationale includes the problems that were solved, options that were considered, criteria that were used when evaluating options, arguments supporting or opposing options, and the decisions that were made to address problems.
- Rationale can be used by both management and developers to represent the justification of system or process decisions.
- While system and process knowledge focuses on the system and the work, rationale knowledge focuses on the decision making elements that lead to the system and process knowledge. Note that rationale can apply to both project and organizational knowledge. In this chapter, however, we focus exclusively on knowledge in the scope of a project and do not examine the implication of rationale in the organizational scope.
- System Knowledge:
- Representation of Rationale
- Argumentation Based Rationale
- Questions represent problems to be solved, such as a design issue, a need for clarification, or a disagreement.
- Options represent considered alternatives for answering a question.
- Options include designs, changes to a document, or clarifications.
- Criteria represent qualities that are used to evaluate options in a certain context.
- Criteria include design goals and management goals.
- The assessment of an Option against a set of criteria is represented with assessment links between the option and the criteria nodes.
- Arguments represent justifications of options or criteria as expressed by the participants.
- Arguments can support or oppose another rhetorical node.
Page updated
Google Sites
Report abuse