Activity: Plan Component Integration

Workflow Details: Implementation The primary input is the Implementation Model Document that specifies what should be delivered to system integration and when. Define the Builds Study the use cases and scenarios that have been selected for the current iteration. Select one, or several scenarios, that will be the goal for each increment of the integration. It may be necessary to…

Read More Read More

Checkpoints: Implementation Model

Artifacts > Implementation Artifact Set > Implementation Model > Checkpoints Interfaces and dependencies between components have been defined. The workload for the Implementation Team is balanced; potential bottlenecks have been identified and work has been redistributed, and contingency plans have been created to allow critical work to be redistributed if the initial work allocation becomes imbalanced. There are no instances…

Read More Read More

Report: Actor Report –

Artifacts > Requirements Artifact Set > {More Requirements Artifacts} > Actor > Report Actor Report This report contains information regarding an actor () within the use-case model. Role: Analyst This report is used by various people interested in the actor, such as designers, testers, and managers. Brief Outline 1. Brief Description A brief description of the actor. 2. Characteristics The…

Read More Read More

Checkpoints: Use-Case Realization

Artifacts > Analysis & Design Artifact Set > Use-Case Realization > Checkpoints The use-case realization completely realizes the selected sub-flows of the use case; there is no missing behavior. All additional requirements on the use case have been handled All required behavior has been unambiguously distributed among the model elements participating in the use-case realization. All exceptional cases to be…

Read More Read More

Checkpoints: Software Architecture Document

The architecture appears to be stable. The need for stability is dictated by the nature of the Construction phase: in Construction the project typically expands, adding developers who will work in parallel, communicating loosely with other developers as they produce the product. The degree of independence and parallelism needed in Construction simply cannot be achieved if the architecture is not…

Read More Read More

Activity: Design Test Classes

Roles and Activities > Designer > Design Test Classes Workflow Details: Purpose To identify and design the classes and packages that will provide the needed test specific functionality. Based on input from the test designer identify and specify test-specific classes and packages in the design model. A driver or stub of a design class has the same methods as the…

Read More Read More

Checkpoints: Use Cases

Artifacts > Requirements Artifact Set > Use Case > Checkpoints Is each concrete use case involved with at least one actor? If not, something is wrong; a use case that does not interact with an actor is superfluous, and you should remove it. For more information, see Guidelines: Use Case. Is each use case independent of the others? If two…

Read More Read More

Checkpoints: Test Plan

Artifacts > Test Artifact Set > Test Plan > Checkpoints The test plan clearly identifies the scope of the test effort, by stating the following: stages and types of test to be implemented and executed target-of-test features or functions to be tested / not tested (if appropriate) any assumptions, risks, or contingencies which may affect or impact the test effort…

Read More Read More

Guidelines: C++ Programming

Large software projects are generally undertaken by correspondingly large teams of developers. For the code produced by large teams to have project-wide measurable quality, the code must be written in accordance with; and be judged against a standard. It is therefore important for large project teams to establish a programming standard, or set of guidelines. The use of a programming…

Read More Read More

Activity: Update Change Request

Workflow Details: Configuration & Change Management The Change Request Form is a formally submitted artifact that is used to track all requests (including new features, enhancement requests, defects, changed requirements, etc.) along with related status information throughout the project lifecycle. All change history will be maintained with the CR, including all state changes along with dates and reasons for the…

Read More Read More