Defining, validating and baselining the architecture as rapidly as is practical
Eliminating the highest risk elements of the project
Creating a first version of the business case
Baselining a high-fidelity plan for the construction phase
Demonstrating that the baseline architecture will support the product vision for a reasonable cost in a reasonable time.
To elaborate the architecture and selecting components.
To achieve concurrence among all stakeholders on the lifecycle objectives for the project
To clarify the remaining requirements and completing the development of the system based upon the baselined architecture
To ensure that software is available for its users and make minor adjustments based on user feedback
An individual can assume many roles, that is, wear many "hats".
A role defines the responsibility for artifacts, but not the behavior (activities) of an individual or a set of individuals working together as a team.
The responsibilities of each role are not defined relative to certain artifacts.
Lifecycle Objectives Milestone
Product Release Milestone
The Lifecycle Architecture milestone
Initial Operational Capability Milestone
It lets you take changing requirements into account.
Elements are integrated progressively - integration is not one "big bang" at the end.
It lets you mitigate risks earlier.
It facilitates reuse and ultimately a more robust architecture.
All of the above.
The Architect leads and coordinates technical activities and artifacts throughout the project.
The Architect establishes the overall structure for each architectural view: the decomposition of the view, the grouping of elements, and the interfaces between these major groupings.
Developing and testing components
Defining the detailed database design, including tables, indexes, views, constraints, triggers, stored procedures, and other database-specific constructs needed to store, retrieve, and delete persistent objects
Leads and coordinates requirements elicitation by outlining the system's functionality and delimiting the system
Iteratively and incrementally develop a complete product that is ready to transition to its user community
Establishing the project's software scope and boundary conditions, including an operational vision, acceptance criteria and what is intended to be in the product and what is not
Describing the remaining use cases, fleshing out the design, completing the implementation, and testing the software
To produce an evolutionary prototype of production-quality components, as well as possibly one or more exploratory, throw-away prototypes to mitigate specific risks
Decide if the software, the sites, and the users are all ready to “go operational.”
All of the developed use cases are tested at the end of Construction.
Each iteration has a test cycle following the pattern that includes Plan test, Design test, Implement test, Execute test, Evaluate test.
All of the developed use cases are tested at the end of Transition.
A variant of some artifact; later versions of an artifact typically expand on earlier versions.
A component containing functionality for testing purposes
A model element which has the semantics of a package, such that it can contain other model elements, and a class, such that it has behavior
A build is an operational version of a system or part of a system that demonstrates a subset of the capabilities provided in the final product.
A Test Case is a package-like artifact used to group collections of Test Scripts, both to sequence the execution of the tests and to provide a useful and related set of test log information from which test results can be determined.
A Test Case is a definition of a specific set of test inputs, execution conditions, and expected results, identified for the purpose of making an evaluation of some particular aspect of a Target Test Item.
A Test Case is the step-by-step instructions that realize a test, enabling its execution.
An ongoing or upcoming concern that has a significant probability of adversely affecting the success of major milestones.
A concern that has become a reality
A technical issue that impacts the project date or budget
Solutions development work effort
Includes work procedures, both extensive and throwaway
Is operative and executable, is focused on a specific objective, is quickly built
Has good look and feel, is executable, and is complete
Is quickly built, has mock-up, and is complete
Business process reengineering (BPR)
Group support system (GSS)
Joint application design (JAD)
Making decisions that will lead to easily implemented programs
Satisfying stated requirements
Identifying gaps or inconsistencies in system requirements
Custom Application Development
App Maint & Enhancements
New Enhancements (
Project Manager/Work Coordinator
Obtain Stakeholder Agreement
Define Detailed Requirements (based on Process Level)
Execute Test Cases & capture results (based on Process Level)
Deploy Work Product
Project Manager/Work Coordinator
Stakeholder agreement is not needed.
Ensure Stakeholder needs are met
Collaborate Across Teams
Demonstrate Value Iteratively
Emphasize quality and consistency throughout the lifecycle
Ensure SAS112 compliance through Information Technology General Controls (ITGC's)