MINUS - Project Process and Architecture Framework

MINUS - Project Process and Architecture Framework

TEAM UGS Shirin Aminifar, Eddy Gerenski, Amin Mehr

SYSTEMS 798 Fall 2008

Contents

Introduction2

1.MINUS Process2

1.1.Process Definition2

1.2.Process Evaluation2

1.2.1.Waterfall Model2

1.2.2.Vee Model3

1.2.3.Spiral Model4

1.2.4.Process Model Comparison5

1.2.5.Stakeholder Value6

1.2.6.Process Model Selection6

1.2.6.1.Requirements and Specifications6

1.2.6.2.Design7

1.3.MINUS Process Integration7

1.3.1.Process and Scope Reduction7

1.3.2.Planned Process Deliverables7

1.3.3.Process Schedule9

2.MINUS Architecture9

2.1.Architecture Definition9

2.2.Architecture Evaluation10

2.2.1.Department of Defense Architecture Framework (DODAF)10

2.2.2.Zachman Enterprise Framework10

2.2.3.The Open Group Architecture Framework (TOGAF)10

2.2.4.Architecture Comparison10

2.2.5.Stakeholder Value11

2.2.6.Architecture Selection11

2.3.MINUS Architecture Integration11

2.3.1.Architecture and Scope Integration11

2.3.2.Architecture and Process Integration11

2.3.3.Planned Architecture Deliverables11

List of Figures

Figure 1 Waterfall Model4

Figure 2 Vee Model4

Figure 3 Spiral Model5

Figure 4 Model Comparison and Contrast Evaluation7

Figure 5 MINUS Schedule10

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 Process1.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.

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

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

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

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 its 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 Bottom-Up

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

Project Type

Short and Small projects w/ well defined requirements

Large, expensive and mission critical projects

Small projects w/ well defined requirements

Flexibility

Rigid, No iterative steps

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

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

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.

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 its users and operators

Clearly communicate system objectives with stakeholders

Provide mechanism for estimating projects progress

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)

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

1.3.3. Process Schedule

Figure 5 MINUS Schedule

2. MINUS Architecture2.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

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 cross-cutting 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.

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 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:

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

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, MODAF-compliant 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.

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:

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 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.

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. 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).

Todays 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 clients 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.

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.

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 architectures 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 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.

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