Running Head: CS411 LAB I – ICAT PRODUCT DESCRIPTION
LAB I – ICAT Product Description
Daniel Spangler
CS411
Janet Brunelle and Hill Price
March 17, 2014
Version 2
1
CS 411 LAB I – ICAT PRODUCT DESCRIPTION
Table of Contents
1 INTRODUCTION ........................................................................................................ 3
2 ICAT PRODUCT DESCRIPTION............................................................................... 4
2.1 Key Product Features and Capabilities .................................................................. 4
2.2 Major Components (Hardware/Software).............................................................. 5
3 IDENTIFICATION OF CASE STUDY ....................................................................... 5
4 ICAT PRODUCT PROTOTYPE DESCRIPTION ...................................................... 5
4.1 Prototype Architecture (Hardware/Software) ........................................................ 6
4.1.1 Data Model...................................................................................................... 7
4.1.2 Graphical Interface.......................................................................................... 8
4.1.3 Analytics Engine ............................................................................................. 8
4.1.4 Controller ........................................................................................................ 9
4.2 Prototype Features and Capabilities....................................................................... 9
4.3 Prototype Development Challenges ..................................................................... 10
5 Glossary .......................................................................Error! Bookmark not defined.
6 References ....................................................................Error! Bookmark not defined.
CS 411 LAB I – ICAT PRODUCT DESCRIPTION
CS 411 Lab I – ICAT Product Description
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 I – ICAT PRODUCT DESCRIPTION
structure. This cost the company an estimated one billion dollars as their repeat
customers began shopping at other stores (J.C. Penney, 2013).
2 ICAT PRODUCT DESCRIPTION
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 software engineers can model a problem domain. The
ICAT allows stakeholders to visualize, perform analytics and experiment with a problem
domain, facilitating improved decision-making.
2.1 Key Product Features and Capabilities
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
CS 411 LAB I – ICAT PRODUCT DESCRIPTION
as a stakeholder, resource, or objective, while a force represents the influence between
entities.
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.
2.2 Major Components (Hardware/Software)
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.
CS 411 LAB I – ICAT PRODUCT DESCRIPTION
Figure 1 - Major Functional Components Diagram
2.2.1 Graphical Interface
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 I – ICAT PRODUCT DESCRIPTION
2.2.2 Data Model
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.
2.2.3 Analytics Engine
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 I – ICAT PRODUCT DESCRIPTION
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.
2.2.4 Controller(s)
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 I – ICAT PRODUCT DESCRIPTION
3 IDENTIFICATION OF CASE STUDY
The primary stakeholder for this project is Dr. Patrick Hester. He is an associate
professor in the Engineering Management and System Engineering department at Old
Dominion University. Dr. Hester is frequently presented with large, complex problems
in which Type III errors are often present. Dr. Hester currently uses combinations of
generic diagramming and mind mapping tools to develop context analysis diagrams for
his various projects but has expressed the need for a custom tool developed for the
explicit purpose of modeling problem domains.
4 ICAT PRODUCT PROTOTYPE DESCRIPTION
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
CS 411 LAB I – ICAT PRODUCT DESCRIPTION
abstractions around these areas. For example, a pluggable architecture will be used to
allow additional analytics algorithms to easily be registered with the application.
4.1 Prototype Architecture (Hardware/Software)
Given that the ICAT is a standalone desktop application with no external
dependencies, no changes to the previously defined major hardware and software
components are need for the prototype. An additional component called the Testing
Dashboard will be added to facilitate verification of the application. 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 meetings its
goals.
Figure 4 – Major Functional Components Diagram with Testing Dashboard
CS 411 LAB I – ICAT PRODUCT DESCRIPTION
4.2 Prototype Features and Capabilities
The prototype demonstrates the graphical modeling of a problem domain including
all of its entities, and the weight and direction of influence between them. The visual
representation of this information is easier to understand than verbose textual
descriptions, allowing stakeholders to more quickly and accurately notice missing or
incorrect elements. Users are capable of printing or exporting a project to facilitate the
sharing of information with stakeholders that do not have the ICAT.
The ICAT allows for the storing of as many versions of a project as is desired. The
ability to rapidly change a project has the added benefit of facilitating experimentation
with hypothetical scenarios that would be impractical otherwise. This allows
stakeholders to visualize what would happen if they were able to impact the influence of
a particular entity within the domain. It also may serve as a revision history for the
purposes of providing traceability throughout the project.
4.3 Prototype Development Challenges
The largest usability challenge for the prototype will be developing a graphical
representation that is informative and appealing to the user. If it is too overwhelming or
becomes difficult to navigate, then the prototype will fail. To mitigate this it is
imperative to focus on the diagraming portion of development as quickly as possible such
that many iterations can be developed and reviewed by Dr. Hester. Early development of
large test scenarios will also be required.
CS 411 LAB I – ICAT PRODUCT DESCRIPTION
The rendering of the diagrams is also the most difficult technical challenge. There
are potential libraries that may help, but the team has no experience with any of them. If
a library is not found, then there is a high risk of failure.
Most of the team members have never worked on a project this large before,
resulting in a learning curve that may prove to be challenging. This learning curve
includes using version control software, writing modular code, limited exposure to the
selected programming language, and the challenges of working in a shared codebase. All
of these issues can be overcome but are more problematic given the relatively short
timelines for the prototype.
5 GLOSSARY
Attribute – an entity that represents some quality that exhibits an effect on other entities
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
CS 411 LAB I – ICAT PRODUCT DESCRIPTION
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)
Workspace – the area within ICAT in which the user edits or views a project
6 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.
CS 411 LAB I – ICAT PRODUCT DESCRIPTION
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.