MINUS - Project Process and
Architecture Framework
TEAM UGS – Shirin Aminifar, Eddy Gerenski, Amin Mehr
SYSTEMS 798 – Fall 2008
Contents
Introduction .................................................................................................................................................. 3
1.
MINUS Process ...................................................................................................................................... 3
1.1.
Process Definition ........................................................................................................................ 3
1.2.
Process Evaluation ....................................................................................................................... 4
1.2.1.
Waterfall Model ...................................................................................................................... 4
1.2.2.
Vee Model ............................................................................................................................... 5
1.2.3.
Spiral Model ............................................................................................................................ 6
1.2.4.
Process Model Comparison..................................................................................................... 7
1.2.5.
Stakeholder Value ................................................................................................................... 8
1.2.6.
Process Model Selection ......................................................................................................... 8
1.2.6.1.
Requirements and Specifications ................................................................................... 9
1.2.6.2.
Design ............................................................................................................................. 9
1.3.
2.
MINUS Process Integration ......................................................................................................... 9
1.3.1.
Process and Scope Reduction ................................................................................................. 9
1.3.2.
Planned Process Deliverables.................................................................................................. 9
1.3.3.
Process Schedule ................................................................................................................... 11
MINUS Architecture ............................................................................................................................ 12
2.1.
Architecture Definition .............................................................................................................. 12
2.2.
Architecture Evaluation ............................................................................................................. 12
2.2.1.
Department of Defense Architecture Framework (DODAF) ................................................. 12
2.2.2.
Zachman Enterprise Framework ........................................................................................... 12
2.2.3.
The Open Group Architecture Framework (TOGAF) ............................................................. 13
2.2.4.
Architecture Comparison ...................................................................................................... 13
2.2.5.
Stakeholder Value ................................................................................................................. 22
2.2.6.
Architecture Selection ........................................................................................................... 22
2.3.
MINUS Architecture Integration................................................................................................ 27
2.3.1.
Architecture and Scope Integration ...................................................................................... 27
2.3.2.
Architecture and Process Integration ................................................................................... 27
2.3.3.
Planned Architecture Deliverables........................................................................................ 27
1
List of Figures
Figure 1 – Waterfall Model ........................................................................................................................... 4
Figure 2 – Vee Model .................................................................................................................................... 5
Figure 3 – Spiral Model ................................................................................................................................. 6
Figure 4 – Model Comparison and Contrast Evaluation ............................................................................... 8
Figure 5 – MINUS Schedule ......................................................................................................................... 11
2
Introduction
The Miniature Intrusion Networked Unattended Ground Sensor System (MINUS) Project Process defines
what methodology will be used to structure the scope and schedule of the Systems 798 Final Project and
report. This document reviews various processes studied, the down selection made by the UGS team,
and a refined and attenuated project scope that is tailored to the process, assignments and limitations
of a semester project effort. This document also reviews systems engineering architecture frameworks
the UGS team has evaluated and the final selection that will be used for this project. The results of this
effort clearly define the way ahead of the UGS team process and architecture for developing the MINUS
System.
1. MINUS Process
1.1. Process Definition
A model will be selected in order to represent the major components of the development work the UGS
team plans to perform. The process will enable the UGS team to define the work that will be performed,
divide it into manageable pieces, determine the project milestones, and communicate the strategy to
stakeholders.
3
1.2. Process Evaluation
The following models were evaluated by the UGS team: Waterfall, Vee and Spiral. A description of each
model, the comparison of model, and our process model selection is provided in the subsequent
sections.
1.2.1. Waterfall Model
The Waterfall model is the least flexible life cycle model and is well suited for projects that have a well
defined architecture and an established interface and requirements. The Waterfall Model is linear and
sequential, it starts from requirements to the preliminary design, detailed design, coding/bugging,
integration and testing and then ending with operations and maintenance O&M. The model has defined
goals for each phase with no turning back. Once a phase in the model is completed, the next phase can
begin.
Figure 1 – Waterfall Model
4
1.2.2. Vee Model
The Vee model was developed after the Spiral and Waterfall. The model is shaped like the letter V, using
a top-down approach on the left side of the V and bottom-up approach on the right side of the V. The left
side of the Vee represents the evolution of user requirements into parts and lines of code through the
process of decomposition and definition. The downward iterations include engineering studies,
requirements understanding modeling, feasibility demonstrations, and what-if analysis, and descend to
the level of the system under investigation such as subsystem or piece parts as examples. The right side
of the Vee represents the integration and verification of the system components into successive levels of
assembly. The upward iterations ensure that the technical baseline, as it evolves, continues to be
satisfactory to the user.
Figure 2 – Vee Model
5
1.2.3. Spiral Model
The spiral model is typically used in IT. This model of development combines the features of the
prototyping model and the waterfall model. The spiral is typically used for large, expensive and complex
projects. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A
software project repeatedly passes through these phases in iterations/spirals. The baseline spiral is the
start of the planning phase where requirements are gathered and risk is assessed. Each follow spiral
builds upon the baseline spiral.
Figure 3 – Spiral Model
6
1.2.4. Process Model Comparison and Contrast
The Spiral model is almost identical to the Waterfall model, with the exception that the Spiral is an
iterative process where the Waterfall is a single one time process. They both use the top-down
approach. The Vee model uses the top-down approach on the left side identical to the Waterfall model,
but uses a bottom-up approach on the right side of the Vee process.
Both the Vee and Spiral model perform early risk mitigation to reduce project risks. In both models a
prototype of the system is developed in order to validate the requirements specification. The Waterfall
Model defers high-risk problems until it’s too late making the model a poor one for complex, long and
ongoing projects.
The Vee and Waterfall models begin with requirements whereas the Spiral model places requirements
definition in the last phases of the planning process.
The life cycle for the Waterfall and Vee models is a sequential path of execution of processes. Each
phase has to be completed before the next phase begins. The Spiral model is repeated in increasing
spirals, where at each cycle of the spiral milestones are achieved and risks are again re-evaluated.
When the Spiral model is used, the software is produced early in the software life cycle. For the Spiral
model, the steps are iterated until the customer is satisfied that the refined prototype represents the
product they want. When using the Waterfall and Vee model, if the model changes while developing
the application the customers have to be patient since a working product is not available until very late
in the process. The Vee model has a higher chance of success over the Waterfall model due to the
development of test plans early on during the life cycle.
For larger and more complicated projects, especially where new technologies are introduced, the Spiral
model is the best of the three to chose. The Spiral model allows a prototype to be delivered early in the
process stages so that the initial capability will be introduced to better assess the risk. This is more of an
evolutionary process where with each build, new capability is introduced.
The Waterfall and Vee models are more preferable to use for well defined projects where there are
little or no technology risks and well defined requirements.
Waterfall
Spiral
Vee
Process
One Time
Iterative
Iterative
Approach
Top-Down
Top-Down
Top-Down and BottomUp
Prototyping
No
Yes
Yes
Risk Analysis
No
Yes, a lot
Yes
Life Cycle
Systematic, Linear
and Sequential
Evolutionary, iterative
increasing spirals
Systematic, Linear and
Sequential
7
Project Type
Short and Small
projects w/ well
defined
requirements
Rigid, No iterative
steps
Large, expensive and
mission critical projects
Small projects w/ well
defined requirements
Allows re-works with
iteration
Rigid, expensive to go
back and make changes
Cost
More cost effective
and affordable
Very costly, expensive
More cost effective
and affordable
Ease of use
Simple and easy to
use
More difficult
Simple and easy to use
Software
Developed very
late
Developed very early in the
stage
Developed fairly late at
implementation phase
Flexibility
Figure 4 – Model Comparison and Contrast Evaluation
1.2.5. Stakeholder Value
MINUS stakeholders are looking for an initial requirements and design document for the MINUS system
which outlines the specifications and design elements of the MINUS system. Since the MINUS
stakeholders are looking for intrusion detection technology to be implemented sooner rather than later,
an iterative process will not be followed. The Waterfall and Vee models are more preferable for MINUS
stakeholders to use since MINUS is a well defined project and there is little or no technology risks and
well defined requirements.
1.2.6. Process Model Selection
The UGS team has selected the Waterfall model for the following reasons:

MINUS will be a small system with well defined requirements closely mapping to the Waterfall
model process

Waterfall begins with requirements phase which closely ties to UGS consultant and stakeholder
objectives

Waterfall is not iterative, but a one time process with a linear life cycle

A prototype of MINUS is not needed or required early on for stakeholder buy in

There is very limited technology risks associated with implementing MINUS

Waterfall is more cost effective and affordable

Waterfall is easier to use

MINUS software will be developed in a later phase
8
1.3. MINUS Process Integration
1.3.1. Process and Scope Reduction
The UGS team will focus on completing the requirements and design phases of the Waterfall lifecycle in
conjunction with meeting milestone A of the JCIDS framework which includes the development of the
CONOPS, Architectures and a Capability Based assessment. The following will be items will be
completed as part of the Waterfall requirements and design phases.
1.3.1.1.
Requirements and Specifications
For the Requirements phase we will complete the following:

Define the problem

Identify broad and detailed objectives of the MINUS system

Define functions and behavior of the system required by it’s users and operators

Clearly communicate system objectives with stakeholders

Provide mechanism for estimating project’s progress
1.3.1.2.
Design
For the Design phase we will complete the following:

Develop a high level design with structure charts, data flow diagrams, and user interface design
1.3.2. Planned Process Deliverables
The UGS team plans on delivering a final report that will include the following deliverables from the
Waterfall and JCIDS framework.

System level CONOPS

Initial Capabilities Document (ICD)/Requirements Specification

Preliminary Design Document

Architecture Views

Operational View (OV-1)

Technical View (TV-1)

Systems View (SV-1)
9
This final report will also contain the following items:

System Functional Decomposition

Stakeholder Identification and Analysis

Stakeholder Value Mapping

QFD

Market research/Analysis of Alternatives

Business Plan

Cost Estimation

Other items that may discussed in class that do not map to Waterfall/JCIDS process
10
1.3.3. Process Schedule
Figure 5 – MINUS Schedule
11
2. MINUS Architecture
2.1.Architecture Definition
A system architecture or systems architecture is the conceptual design that defines the
structure and/or behavior of a system. There is no universally agreed definition of which
aspects constitute a system architecture, and various organizations define it in different ways,
including:
The fundamental organization of a system, embodied in its components, their
relationships to each other and the environment, and the principles governing its design
and evolution. From ANSI/IEEE 1471-2000.
A representation of a system in which there is a mapping of functionality onto hardware
and software components, a mapping of the software architecture onto the hardware
architecture, and human interaction with these components. From the Carnegie Mellon
University's Software Engineering Institute as found at its glossary.
An allocated arrangement of physical elements which provides the design solution for a
consumer product or life-cycle process intended to satisfy the requirements of the
functional architecture and the requirements baseline. From The Human Engineering
Home Page's Glossary.
An architecture is the most important, pervasive, top-level, strategic inventions,
decisions, and their associated rationales about the overall structure (i.e., essential
elements and their relationships) and associated characteristics and behavior. From
OPEN Process Framework (OPF) Repository.
A formal description of a system, or a detailed plan of the system at component level to
guide its implementation. TOGAF
The structure of components, their interrelationships, and the principles and guidelines
governing their design and evolution over time. TOGAF
-Wikipedia.com
2.2. Architecture Evaluation
2.2.1. Department of Defense Architecture Framework (DODAF)
2.2.2. Zachman Enterprise Framework
12
2.2.3. The Open Group Architecture Framework (TOGAF)
Architecture Comparison The following are 4 EA frameworks and their graphical tools:
1) FEAF: The Federal Enterprise Architecture is a strategic information asset base that defines the
business, information necessary to operate the business, technologies necessary to support the
business operations, and transitional processes for implementing new technologies in response
to the changing needs of the business. The Federal Enterprise Architecture Framework is a
conceptual model that begins to define a documented and coordinated structure for crosscutting businesses and design developments in the Government. Collaboration among the
Agencies with a vested interest in a Federal segment will result in increased efficiency and
economies of scale. Agencies should use the Framework to describe segments of their
architectures.
FEDERAL ENTERPRISE ARCHITECTURE FRAMEWORK
Architecture Drivers - Represents an external stimulus that causes the
Federal Enterprise Architecture to change.
� Strategic Direction - Ensures that changes are consistent with the overall Federal direction.
� Current Architecture - Represents the current state of the enterprise.
Full characterization may be significantly beyond its worth and maintenance.
� Target Architecture - Represents the target state for the enterprise within the context of the strategic
direction.
� Transitional Processes - Apply the changes from the current architecture to the target architecture in
compliance with the architecture standards, such as various decision making or governance procedures,
migration planning, budgeting, and configuration management and engineering change control.
� Architectural Segments - Focus on a subset or a smaller enterprise within the total Federal Enterprise.
� Architectural Models - Provide the documentation and the basis for managing and implementing
changes in the Federal Enterprise.
� Standards - Include standards (some of which may be made mandatory), voluntary guidelines, and
best practices, all of which focus on promoting interoperability.
13
14
2) TOGAF
The Open Group Architecture Framework (TOGAF) is a framework for Enterprise Architecture which
provides a comprehensive approach to the design, planning, implementation, and governance of an
enterprise information architecture. The architecture is typically modeled at four levels or domains;
Business, Application, Data, Technology. A set of foundation architectures are provided to enable the
architecture team to envision the current and future state of the architecture.
Summary of TOGAF's characteristics
Comprehensive phased approach
The development of enterprise and IT architectures is at the core of TOGAF. A phased approach ensures
15
that managers make good decisions about their business structures and IT.
Complete lifecycle management
TOGAF has the ability to manage the complete architecture lifecycle - from the initial introduction and
visioning of the conceptual architectures to the full specification, implementation and governance of the
completed architectures.
Best practice tool support
TOGAF is supported by a large number of best practice tools and techniques. Customers have a rich
infrastructure of instantly available capability to enable them to start using the method and bring it into
their organisations quickly.
Simplicity and depth
The appeal of TOGAF is its combination of simplicity and depth. For the CIO and CTO, TOGAF's refreshing
simplicity enables IT to easily engage with the business. However, TOGAF also has the depth to manage
complexity and provide sophisticated IT services. This combination allows business and IT to work
together to build effective business operations and infrastructures that deliver competitive advantage.
In addition, TOGAF supports four architecture domains:
1. Business (or business process) architecture which defines the business strategy, governance,
organization, and key business processes of the organization
2. Applications architecture which provides a blueprint for the individual application systems to be
deployed, the interactions between the application systems, and their relationships to the core
business processes of the organization
3. Data architecture which describes the structure of an organization's logical and physical data
assets and the associated data management resources
4. Technology architecture which describes the software infrastructure intended to support the
deployment of core, mission-critical applications
TOGAF Components:
16
TOGAF Foundational Architecture consists of two pieces
The TOGAF Technical Reference Model (TRM)
 A model and a taxonomy of generic platform services
The TOGAF Standards Information Base (SIB)

A database of open industry standards that can be used to define services and components
for an enterprise architecture
17
3) MODAF
The UK Ministry of Defence Architectural Framework (MODAF) defines a standardised way of
conducting Enterprise Architecture and provides a means to model, understand, analyze and specify
Capabilities, Systems, Systems of Systems, and Business Processes. The purpose of MODAF is to provide
a rigorous systems of systems definition when procuring and integrating defence systems. As of 10th
April 2007, MODAF version 1.1 was released
The principal purpose of MODAF is to facilitate the successful delivery of Network Enabled
Capability (NEC). By covering both the operational and technical aspects across the enterprise, MODAFcompliant Architectures enable all communities of interest to gain the essential common understanding
that will be required to deliver the benefits to be derived from NEC.
As an enabler for managing complexity, MODAF provides a specification of how to represent an
integrated model of an enterprise, from the operational / business aspects to the systems that provide
capability, together with appropriate standards and programmatic aspects. It assists in managing
complexity by providing a logical, standardized way to present and integrate models of the enterprise.
18
MODAF, mandated for use on new Ministry of Defense projects from 2006, is a key enabler for
Network Enabled Capability (NEC). While the framework is predominantly used for acquisition purposes,
MODAF can be used to analyze operational systems and improve their integration with both new and
existing systems.
MODAF incorporates aspects of the U.S. Department of Defense Architectural Framework
(DoDAF) specification, the most mature and widely adopted architectural framework in the industry.
This framework has its origins in the C4ISR community and is seen as a fundamental part of the DoD's
drive towards Network Centric Warfare.
Graphical Tools:
19
4) DoDAF
The Department of Defense Architecture Framework (DoDAF) defines a standard way to
organize an enterprise architecture (EA) or systems architecture into complementary and consistent
views. All major U.S. Government Department of Defense (DoD) weapons and information technology
system procurements are required to develop and document an EA using the views prescribed in the
DoDAF. While it is clearly aimed at military systems, DoDAF has broad applicability across the private,
public and voluntary sectors around the world, and represents only one of a large number of systems
architecture frameworks. It is especially suited to large systems with complex integration and
interoperability challenges, and is apparently unique in its use of "operational views" detailing the
external customer's operating domain in which the developing system will operate
DoDAF is the standard framework chosen by the United States Department of Defense to
comply with the Clinger-Cohen Act and United States Office of Management and Budget Circulars A-11
and A-130. It is administered by the Undersecretary of Defense for Business Transformation's DoDAF
Working Group. DoDAF was formerly named C4ISR (Command, Control, Communications, Computers,
Intelligence, Surveillance and Reconnaissance) AF. Other derivative frameworks based on DoDAF include
20
the NATO Architecture Framework (NAF) and Ministry of Defence (United Kingdom) Architecture
Framework (MODAF).
Like other EA approaches, for example The Open Group Architecture Framework (TOGAF), DoDAF is
organized around a shared repository to hold work products. The repository is defined by the Core
Architecture Data Model 2.0 (CADM -- essentially a common database schema) and the DoD
Architecture Repository System (DARS). A key feature of DoDAF is interoperability, which is organized as
a series of levels, called Levels of Information System Interoperability (LISI). The developing system must
not only meet its internal data needs but also those of the operational framework into which it is set.
21
And finally:
2.2.4. .
2.2.5. Stakeholder Value
2.2.6. Architecture Selection
Zachman framework is most likely one of the oldest and most popular framework. It was developed
for dealing with large information systems and mainly focused on data processing of mainframes.
Zachman
framework
focused
was
on
data
aspect
of
businesses.
Especially
after
information/knowledge being recognized as a key component in the success of businesses today,
the increasing interest in information management or so called “knowledge management” has
created this demand for architectures like Zachman. The framework is defined very broadly so it
would cover all areas for designing and analysis. One of the biggest challenge facing organizations
and those seeking the facilitate systems within them is complexity.
22
According to Hoffman
complexity has two sides’ content and process. The Zachman framework focuses on content by
defining the views that provide a holistic perspective.
The row describes the perspectives of those who use the models or descriptions. The top row
represents the most generic perspective of an organization while lower rows are successively more
concrete. The columns describe the abstractions that define each perspective. Based on the
historical questions that people have asked when they should understand (who, what, when, where,
why, how).
Today’s dynamic warfare had motivated architecture, many different systems come together to
carry out one overall mission, therefore interoperability is not an option. The exchange of
information and data between these systems are critical in saving lives and winning battles. DoDAF
was developed both for war fighting operation and business operations. The intention of the
framework was to ensure the architectural descriptions can be compared and related across
organizational boundaries joint and multinational.
The DoDAF defines three architectures;
operational (OA), systems (SA) and technical (TA).
OA describes the tasks and activities required to accomplish or support military operation. SA
describes the system and interconnections providing and supporting military functions. TA is defined
as “the minimal set of rules governing the arrangement, interaction, and interdependence of system
parts or elements, whose purpose is to ensure that a conformant system satisfies a specified set of
requirements.” Unfortunately the DoDAF has been characterized by a general failure to meet
client’s expectations. The information necessary to drive enterprise architecture decisions are
absent such as business, financial and technical analysis information. MITRE has described it as
missing a knowledge component which is key concept in architecture.
23
Above diagram maps the DoDAF onto Zachman, there are many common areas between the
Zachman and DoDAF. According to research conducted by MITRE and Lockheed:

Zachman does not explicitly cover “rules” or Product standards (Technical)

DoDAF does not address “time” in detail, but does include some timing and sequencing
products and technology forecasts.

DoDAF does not explicitly address “motivation” but allows related aspects to be described in
mission and vision statement.
The purpose of architecting is to produce actionable decision information by the application of
reliable knowledge through mature processes. The ability to describe and evaluate large SoS
architectures is limited to both knowledge and process. According to MITRE the DoD architecture
lacks the knowledge and process aspects.

The body of knowledge underpinning DoD architecting lacks sufficient formal and complete
vocabulary capable of expressing the increasing conceptual complexity of such systems.

DoD architecting practice lacks mature processes capable of integrating multiple individual
architecture descriptions and evaluating the architecture of the integrated whole.
24
Unlike the Zachman framework which is data centric the DoDAF is very product centric. The 26
views composing the DoDAF and its associated viewpoints products were conceived by a group. The
focus on products led to the current deficiencies in DoDAF. To remedy this issue is not difficult since
DoDAF does not state any constraints on new products one can create new DoDAF products. But a
more appropriate approach would be the data centric approach. With this approach views can be
created as needed also the ability to create a single integrated view of architecture’s data can be
useful.
The above diagram shows the maturing practice suggested by MITRE.
Activity-Based Methodology (ABM) is a tool-independent approach to integrated DoDAF
architectures. It uses data centric architecture elements and product renderings and cross product
relationships based on core set of architecture elements. ABM enables both the as-is and to-be
architecture development, gap analysis, and assessment. Architecture Specification Model (ASM) is
described to be an objective to manage the risk inherent in DoDAF. It emerges from the ABM
concept. ASM provides a common set of semantics for expressing and in describing DoD
Architecture. ASM and ABM both take the data-centric approach for architecture element and
product generation. Lockheed suggests adding another view called the motivation view to complete
the DoDAF. The motivational view would consist of work products such as business case, investment
25
decision model, risk analysis, and so on. This would fill in the gap stated earlier regarding business
financial, investment and strategy aspects missing in the DoDAF. These views facilitate the business
rationale and trade-offs required to develop a valid and achievable transition plan to transform the
enterprise from its current as-is state to the future to-be state. The motivational view complements
the existing DoDAF views, providing a complete holistic view.
Joint Technical Architecture (JTA) is another initiative put in place to increase commonality and
standardization within DoD. It supports TA products defined in the C4ISR Architecture Framework
to meet system and operational requirements. JTA is a document that that was created by DoD to
mandate the minimum set of commercial specification standards and guidelines for the acquisition
of all DoD systems that produce, use or exchange information such as information processing,
information transfer, modeling, user interface, security and data format. It is designed to be used be
anyone involved in the management, development or acquisition of new or improved systems
within DoD. These standards and guidelines support interoperability described in SA and operational
concept defined by the OA.
DoDAF is baseline for MODAF, it has added extra view to be more complete compared to
DoDAF. Here are the factors that motivated MODAF to be different from DoDAF:

The need to model incremental acquisition programs as these represent an increasingly
common form of defense procurement

The need to model transformational programs and their inter-dependencies

The need to model capabilities as the outcome from force development and capability
integration programs

The need to model solution resources in terms of people as well as technical system
resources

The need to model physical attributes and capabilities and, by extension, flows of personnel,
energy and materiel not just information

The need to integrate program models into traditional architecture models in order to meet
the needs of enterprise architects

A drive towards a more coherent object oriented underpinning for the Architectural
Framework.
26
The most important changes were addition of the 2 viewpoints Strategic and Acquisition. The
concern for capability managers and to describe the capability taxonomy and evolution was the
reason for the strategic viewpoint. The acquisitions Viewpoint describe projects, how those projects
deliver capabilities, the organizations contributing to the projects and dependencies between them.
In conclusion DoDAF is key in creating data-centric environment. With the help of such tools and
concepts DoDAF can be evolved into a more complete AF.
2.3. MINUS Architecture Integration
2.3.1. Architecture and Scope Integration
2.3.2. Architecture and Process Integration
2.3.3. Planned Architecture Deliverables
27