Running Head: CS411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
LAB 2 – ICAT Prototype Product Specification
Daniel Spangler
CS411
Janet Brunelle and Hill Price
March 19, 2014
1
CS 411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
2
Table of Contents
1 INTRODUCTION ........................................................................................................ 3
1.1 Purpose................................................................................................................... 4
1.2 Scope ...................................................................................................................... 9
1.3 Definitions, Acronyms, and Abbreviations ........................................................... 9
1.4 References ............................................................................................................ 11
1.5 Overview .............................................................................................................. 12
2 General Description .................................................................................................... 12
2.1 Prototype Architecture Description ..................................................................... 12
2.2 Prototype Functional Description ........................................................................ 13
2.3 Prototype External Interfaces ............................................................................... 15
List of Figures
Figure 1 - Major Functional Components Diagram ............................................................ 6
Figure 2 – Data Model High Level Class Diagram ............................................................ 7
Figure 3 – Mathematical Description of In-degree and Out-degree Centrality .................. 8
Figure 4 – Major Functional Components Diagram with Testing Dashboard.................. 13
CS 411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
3
CS 411 Lab 2 – ICAT Prototype Product Specification
1 INTRODUCTION
It is estimated that 80 percent of all systems engineering failures can be traced back
to Type III errors (Bea, Mitroff, Farber, Foster, & Roberts, 2009, p. 36). Type III errors
can loosely be defined as “the error associated with solving the wrong problem precisely”
(Mitroff, 1998, p. 15). They are a result of not properly defining a problem before
implementing a solution. The proper definition of a problem might seem to be an
obvious step in problem solving, but as systems get increasingly complex, with growing
numbers of dependencies, this seemingly obvious issue becomes more problematic. The
problem definition process is denied the same engineering rigor that implementation
receives and often results in a loss of resources.
A recent example of this is the case where Boeing decided that their domestic
suppliers were too expensive and that outsourcing parts of their production would reduce
costs. Outsourcing their components ended up costing 12-18 billion dollars, a delay on
their Boeing 787 Dreamliner, and a large amount of negative publicity. Had they
properly analyzed the problem domain they might have chosen a different solution
(Boeing, 2013).
Another example is the case where JC Penney decided to change their pricing
structure to address sagging sales. The assumption was that customers would buy more if
they had a simplified pricing structure, but their core customer base preferred the existing
CS 411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
4
structure. This cost the company an estimated one billion dollars as their repeat
customers began shopping at other stores (J.C. Penney, 2013).
1.1 Purpose
It is theorized that a major reason that Type III errors are often neglected a proper
analysis is a lack of modeling tools and methodologies (Bea et al, 2009, p. 37). The
Interactive Context Analysis Tool (ICAT) attempts to fill that void by providing a
graphical user interface in which systems engineers can model a problem domain. The
ICAT allows stakeholders to visualize, perform analytics and experiment with a problem
domain, facilitating improved decision-making.
The primary feature of the ICAT is the ability to model a problem domain in a
visual context. It does this by allowing a systems engineer to create a digital model of a
problem domain within a diagramming tool. The layout of the diagram is similar to a
context diagram with additional features relevant to the specific use case of modeling a
problem domain.
The diagrams have features common to other diagramming tools such as zooming,
panning, and exporting; but the ICAT also adds capabilities unique to the specific task of
modeling and analyzing problem domains. The ICAT narrows down the shapes in a
diagram to circles and arrows. A circle represents an entity and an arrow represents the
influence between two entities. An entity is something within the problem domain such
as a stakeholder, resource, or objective, while a force represents the influence between
entities.
CS 411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
The systems engineer constructs a diagram by adding entities and forces. Each
entity and force contains domain specific properties that influence the visualization of
these shapes. One example of this is the weight associated with a force. The ICAT will
style the connecting lines behind a weight differently based on the weight entered by the
user. A force with a higher weight will have a thicker line. Another example is the use
of background color to represent the type of entity being rendered.
The most important of the domain specific features is the ability to provide
analytics on the domain. A systems engineer can perform a suite of standard algorithms
to assist in analysis. The initial implementation consists of in-degree and out-degree
centrality. These algorithms assist the systems engineering in determining how much
influence is directed on specific entities and the degree in which an entity influences
others.
The ICAT is a standalone desktop style application. It has no external hardware or
software dependencies outside of a file system and an operating system capable of
running Java. The application consists of the following major software components:
Graphical Interface, Controller(s), Data Model, and Analytics Engine.
5
CS 411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
6
Figure 1 - Major Functional Components Diagram
A systems engineer always interacts with the system through the ICAT graphical
interface. This is the only software component directly accessible to a user of the system.
Additional components are utilized internally to facilitate the user experience. The first
view that a user encounters is the Dashboard. The Dashboard allows a user to search for
projects, view recent projects, and load a specific project. The Workspace view is
presented to the user once a project is selected. The Workspace is where all project
specific functions are performed such as the creation and analysis of a problem domain.
CS 411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
7
Figure 2 – Data Model High Level Class Diagram
The data model for the ICAT is similar to a directed graph. Each vertex in the
graph represents an Entity within the problem domain. A user can include descriptive
information about the Entity including things such as name, classification, and
controllability. Additionally, visual coordinates are also stored on the Entity to identify
positioning in the visual representation. The edges of the graph represent Forces within
the problem domain. A Force goes from one Entity to another Entity. In addition to
maintaining this relationship, the Force can also contain weighting to indicate that some
Forces represent more influence than others.
The Analytics Engine is responsible for executing analytics algorithms on the data
model and producing reports depicting the results. Each algorithm is implemented using
a well-defined interface to allow for future extensibility, but only In-Degree and OutDegree centrality are initially implemented.
CS 411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
8
Figure 3 – Mathematical Description of In-degree and Out-degree Centrality
The in-degree algorithm describes how an entity is influenced by other entities while the
out-degree algorithm describes how much influence a given entity has on others. These
algorithms also take into account user provided data such as the weight of a force.
The ICAT utilizes a standard Model View Controller (MVC) architecture to manage
internal interactions within the application. The Graphical Interface represents the View
and the Data Model represents the Model within the MVC. The Controller is used to
manage the interactions between the various components in the system. It instructs the
Graphical Interface on what should be displayed at any given time, and the Graphical
Interface notifies it of any actions performed by the user. This sort of interaction occurs
between the Data Model and Analytics Engine as well. The Analytics Engine could be
considered a type of Controller, but is listed independently given the scope and
importance it plays in the overall application.
CS 411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
9
1.2 Scope
The primary goal of the ICAT prototype focuses on the ability to model a problem
domain in a visual context. Once the problem domain is modeled, then it can be analyzed
both manually and programmatically. The secondary goal is to execute one or more
analytics algorithms on the model.
It is important that both of these goals be addressed in order to prove the viability of
the product. If analytics cannot be executed against the model, the problem domain could
be created in a generic diagramming tool such as Microsoft Visio. If the problem domain
cannot be modeled then analytics cannot be executed. A successful prototype will allow
systems engineers to use the ICAT to quickly create and traverse a real problem domain
and have the system provide meaningful analytics driven reports about the problem.
Capability reduction occurs in the following categories: collaboration, export
formats, and number of analytics algorithms. These features are not considered necessary
to prove the viability of the ICAT, however, the prototype will be constructed in such a
way that future teams could add these capabilities by implementing well-defined
abstractions around these areas. For example, a pluggable architecture will be used to
allow additional analytics algorithms to easily be registered with the application.
1.3 Definitions, Acronyms, and Abbreviations
Attribute – an entity that represents some quality that exhibits an effect on other entities
CS 411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
10
Dashboard – the area within ICAT in which the user searches for and loads projects into
the workspace.
Entity – objects within the data model; types include: problem, stakeholder, objective,
attribute, and resource
Force – show a directional influence between entities
Influence – a measure of the effect that one entity has on others within the problem
domain; also known as out-centrality
Metadata – data associated with entities or forces
Objective – an entity that represents a goal or target of the real world
Problem – an entity that represents the issue or conflict that the solution is designed to
address
Problem Domain – the collection of entities, forces and associated information
necessary to consider when solving a problem
Project – a digital representation of the problem domain as entered by an ICAT user
Prominence – a measure of the effect that other entities in a system have on a specific
entity; also known as in-centrality
Resource – an entity that represents a required good or service
Stakeholder – an individual or group affected in some way by the undertaking (Stevens
Institute of Technology, 2008)
Systems Engineering – the orderly process of bringing a system into being using a
systems approach (Stevens Institute of Technology, 2008)
Type III Error – the type of error described as “giving the right answer to the wrong
problem” (Kimball, 19567)
CS 411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
11
Workspace – the area within ICAT in which the user edits or views a project
1.4 References
Robert Bea, Ian Mitroff, Daniel Farber, Howard Foster, Karlene H Roberts (2009).
A new approach to risk: the implications of E3.
Risk Management (2009) 11, 30 – 43. doi: 10.1057/rm.2008.12
Mitroff, I.I. (1998). Smart Thinking for Crazy Times: The Art of Solving the Right
Problems. San Francisco: Berrett-Koehler Publishers.
J.C. Penney (28 Jul 2013). Retrieved from Why Projects Fail: Catalog of Catastrophe:
http://calleam.com/WTPF/?p=5874
Boeing Commerical Aeroplanes (3 Feb 2013). Retrieved from Why Projects Fail:
Catalog of Catastrophe: http://calleam.com/WTPF/?p=4617
Stevens Institute of Technology. (2008). Core Concepts of Systems Engineering:
Glossary. Retrieved from The Center for Innovation in Engineering and Science
Education: http://ciese.org/curriculum/seproject/glossary.html
Kimball, A. (1957). Errors of the third kind in statistical consulting. Journal of the
American Statistical Association, 52(278), 133-142.
CS 411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
12
1.5 Overview
The goal of this production specification is to provide enough details to begin
development of the ICAT prototype. This document describes the features, functional
requirements, software, hardware, and external interfaces of the prototype. The
following sections provide more detail on these topics.
2 General Description
While a real world implementation of ICAT would have a richer feature set
including more analytics algorithms, more diverse data exports, integrations with other
systems, and collaboration utilities; the prototype focuses on the basic concept of
modeling a problem domain in a graphical context and proving that rudimentary analytics
can be performed on this model.
2.1 Prototype Architecture Description
The prototype will be written in the Java programming language. The Java
programming language was chosen because of its cross platform nature and the wide
range of existing open source libraries that can be leveraged. The build environment will
use the Gradle build tool in order to facilitate an IDE agnostic development experience.
Version control will be managed via a Git repository.
CS 411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
13
Figure 4 – Major Functional Components Diagram with Testing Dashboard
Figure 4 illustrates the major functional components of the ICAT prototype. It is
similar to Figure 1 with the inclusion of a Testing Dashboard. The Testing Dashboard
will provide a mechanism to construct and execute automated tests to verify that the
application is working as expected and returning appropriate results from the analytics
engine. This will be important in verifying that the prototype meets its goals.
2.2 Prototype Functional Description
The ICAT prototype consists of a single primary user. A Dashboard will be
presented to the user when they initially launch the application. The Dashboard provides
the user with the ability to view recent projects, search their projects, open a project, or
import a project.
CS 411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
14
The Workbench view is displayed after a user selects to open a project from the
Dashboard view. The Workbench is where the user performs the task of modeling a
problem domain.
The Workbench contains an interactive diagram consisting of circles that represent
entities, and arrows between these circles that represent forces. The user can add circles
by right clicking on the diagram and selecting to add entities from a context menu item.
The user will then be prompted to enter additional information about the entity including
its controllability, type, name and notes. Additionally, the user can create forces between
entities by dragging a line between two entities. The user will be prompted to enter
additional information about the force such as weight, name, and notes.
The Workbench provides features such as panning and zooming to facilitate
analysis of the problem domain. Additionally, the user may select to execute specific
analytics algorithms to provide more detailed analysis of the domain. The prototype will
include in-degree and out-degree centrality. The details of these algorithms are provided
in Figure 3.
The Workbench facilitates sharing of projects by supporting the ability to print and
export to PDF. Multiple copies of a project can be saved to facilitate traceability on the
project. A user can save different versions of a project by applying a naming convention
to the files such as “va_schools_initiative_version_1.icat” and
“va_schools_initiate_version_2.icat.”
CS 411 LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
15
2.3 Prototype External Interfaces
The ICAT is a standard desktop application and has no external interfaces with the
exception of what is commonly accepted as part of a standard desktop computer. It
requires a monitor, a keyboard, and a mouse-like device.