Running Head: LAB 1 – ICAT DESCRIPTION
Lab 1 – ICAT Product Description
Team Red
Kirby Weeks
CS 411W
Janet Brunelle / Hill Price
March 17, 2014
Version 3
1
LAB 1 – ICAT DESCRIPTION
2
Table of Contents
1. INTRODUCTION…………………………………………………………………………….3
2. PRODUCT DESCRIPTION…………………………………………………………………..4
2.1. Key Product Features and Capabilities…………………………………………………...4
2.2. Major Components (Hardware/Software)………………………………………………..5
3. IDENTIFICATION OF CASE STUDY………………………………………………………8
4. ICAT PRODUCT PROTOTYPE DESCRIPTION…………………………………………...9
4.1. Prototype Architecture (Hardware/Software)…………………………………………….9
4.2. Prototype Features and Capabilities…………………………………………………….10
4.3. Prototype Development Challenges…………………………………………………….11
GLOSSARY……………………………………………………………………………………..12
REFERENCES…………………………………………………………………………………..14
List of Figures
Figure 1. Major Functional Component Diagram (MFCD) for ICAT…………………………...6
Figure 2. Data Model……………………………………………………………………………..7
Figure 3. Centrality Algorithms………………………………………………………………….8
Figure 4. Major Functional Control Diagram (MFCD) for the ICAT prototype……………….10
LAB 1 – ICAT DESCRIPTION
3
Lab 1 – ICAT Description
1
INTRODUCTION
When systems engineers attempt to solve large scale problem domains, one of the key
factors is identifying those problems. If this is done incorrectly, it results in a type III error. The
type III error occurs when an incorrect problem is solved correctly. The term was originally
coined by Mitroff and Featheringham in 1974 (Yadav & Korukonda, 1985). The type III error
accounts for more than 80% of organizations’ failures when solving problems. This results in
wasted resources, such as time and money.
The ICAT, or Interactive Context Analysis Tool, will be built to minimize type III errors.
The phrase “a picture is worth a thousand words” is what the ICAT is based on. It will be a
brainstorming tool for systems engineers. By taking information in the form of data or words,
and transforming it into a graph or “picture”, the problem domain will be easier to visualize. The
ICAT will not eliminate type III errors automatically, but it will make identifying the problem
easier.
The ICAT will be an interactive software tool that allows the user to create a visual
representation of the problem domain. Users will be able to generate interactive and dynamic
diagrams that show the entities and forces involved in the problem domain. Usability will be
asynchronous for all users involved in the problem domain analysis process. Traceability, and
hence accountability, via notes on each user’s input on the diagram, will be available should the
project manager decides to keep track of team members’ input.
Albert Einstein once said, “If I were given one hour to save the planet, I would spend
fifty-nine minutes defining the problem, and one minute resolving it.” Correctly understanding
LAB 1 – ICAT DESCRIPTION
4
the problem domain is an important part of the entire problem solving process. Problem domain
analysis is what the ICAT will improve.
(This space intentionally left blank.)
LAB 1 – ICAT DESCRIPTION
2
5
PRODUCT DESCRIPTION
ICAT stands for interactive context analysis tool, and will be built for problem domain
analysis for systems engineers. Using a graphical user interface, the user will be able to create a
visual representation of the problem domain. By inputting different entities, such as
stakeholders, objectives, attributes, and resources that will affect, or are affected by the problem
domain, and connecting them with lines of varying influence (known as forces), a directed graph
will be made.
The ICAT is an enhanced drawing tool for systems engineers in their attempts to identify
the correct problem before continuing to solve the problem. As with basic drawing software,
there will be pan and zoom, exporting the image to different software types, such as .png, .jpeg,
.csv, and printing. The reports that it can generate will make it stand out from a simple drawing
tool. ICAT will have the ability to show Prominence, and Influence of the current Project.
The ICAT’s main goals are to decrease the risk of type III errors and to shorten the time it
takes to solve problems. Instead of having raw data, a visual representation will be created,
allowing the systems engineer to have a better understanding of the problem and the problem
scope. This will reduce the risk of type III errors and shorten the entire process of solving
problems. The ICAT will give the user the ability to solve the correct problem the first time.
2.1
Key Product Features and Capabilities
The ICAT has several features and capabilities that will help the user correctly identify
the problem. Panning and zooming will be available, allowing the user to focus on a particular
subset of Entities or Forces. This will be particularly helpful in large scale problem domains. It
will also have the ability to export a specific image to different software types. This could be an
LAB 1 – ICAT DESCRIPTION
6
image of the entire project, or, for example, an image of the project that has been zoomed in 75%
and panned to the left several units. The software types available for export will be .png, .jpeg,
and .csv.
This same option will be available for printing. Printing will be available for the entire
project, or for subsections that have been panned and zoomed. Having a hard-copy could always
prove useful to the systems engineers working on defining the problem.
There will be forces that connect the entities, and those forces will have specific weights
to them. Each entity will have an area for the user to enter meta-data. The forces, and the metadata from the user, will transform the graph to represent the problem domain.
As mentioned in Section 2, the reports that ICAT can generate will be what separate it
from a simple drawing tool. The user will be able to generate reports based on Prominence, and
Influence. By running these reports, a systems engineer will be able to tell how complex a
problem domain is, and which Entities have the most effect on that problem domain.
2.2
Major Components (Hardware/Software)
The hardware components for ICAT are basic. Any computer built within the last ten
years will have the specifications to run ICAT. A keyboard, mouse, and screen will also be
required. Also, any laptop with any basic computing power will suffice. ICAT does not require
intense processing speed or large amounts of memory.
Figure 1 illustrates the software representation of ICAT or the MFCD (Major Functional
Component Diagram). The software will be modeled around the MVC or Model View
Controller concept. There are three parts with this pattern, the data model, the viewer (Graphical
LAB 1 – ICAT DESCRIPTION
7
Interface), and the controllers. There will also be an analytics engine, another controller, where
the algorithms will be handled, and a file system, where data will be saved and loaded.
Figure 1
The controllers will be coded to keep everything up-to-date. As Figure 1 illustrates, it
will also update the file system. The viewer will be a Graphical Interface. It will give a visual
representation of the data model to the user. It will also consist of the drawing canvas, as well as
the buttons, scroll bars, menus, checkboxes, and any other design elements the user can “see”
while looking at the screen. The model component of the MVC is shown in Figure 2.
LAB 1 – ICAT DESCRIPTION
8
Figure 2
The data model, shown in Figure 2, is comprised of a single Project, Entities, and Forces.
A Project contains zero to infinite Entities, and zero to infinite Forces. An Entity contains zero
to infinite Forces, Metadata, a vertex, and radius. A Force contains a weight, a destination
Entity, and a Source entity. Although the source is already known upon creation of the Entity, it
must be stored in the Force component of the data model.
The analytics engine is where the reports algorithms for ICAT will run. This includes
Influence, and Prominence. The Influence algorithm will generate a report to show how many
Forces are coming out of each Entity, while the Prominence algorithm will generate a report
showing how many Forces are going into each Entity. A mathematical representation of the
algorithms can be viewed in Figure 3.
LAB 1 – ICAT DESCRIPTION
9
Figure 3
The last piece of software necessary to run ICAT will be a file system. No centralized
database will be necessary. The file system on the computer will store all of ICAT’s projects.
(This space intentionally left blank.)
LAB 1 – ICAT DESCRIPTION
3
10
IDENTIFICATION OF CASE STUDY
The red team’s case study is the team’s faculty advisor, Dr. Patrick Hester. Dr. Patrick
Hester is an associate professor in the engineering management and systems engineering
department at Old Dominion University. He has a Ph.D. in Systems Engineering, and his work
entails solving large scale problems.
Dr. Hester has made it clear that when solving problems, the type III error happens much
too often. Too little time is spent identifying the problem. He proposed a software tool that
would aid him strictly in problem domain analysis. He has expressed his want to visualize the
problem, instead of looking at raw data.
(This space intentionally left blank.)
LAB 1 – ICAT DESCRIPTION
4
11
ICAT PRODUCT PROTOTYPE
The ICAT prototype is little different than the real-world product. The ability to take raw
data and transform it into a visible, interactive diagram, hence making a problem domain more
understandable, is what this prototype is going to do. The user will be able to “draw” his or her
problem on the canvas, and also run algorithms on it from the analytics engine, as described in
Section 2.2. The user will also be able to set an entity as controllable or non-controllable, and
visible or non-visible.
The prototype must have all the components available, the drawing canvas, the GUI, and
the algorithms. Originally, the ICAT was planned to be able to plugin to S.T.A.T. and C.O.R.E.
(other systems engineering tools), however, due to time constraints, this was eliminated. The
ability to view a graph’s connectivity has also been eliminated from the prototype as Dr. Hester
said this algorithm was not necessary. The ICAT prototype will have the capability to
implement these in the future, should someone desire to do so.
4.1
Prototype Architecture (Hardware/Software)
The hardware required for the prototype will be the same as the real world product. Any
computer built with sufficient processing power, a keyboard, mouse, and a screen will suffice.
Also, any laptop with the same specifications will be able to run ICAT.
The software for the prototype is similar the real world product with some minor changes
illustrated in Figure 4. Most of the changes in the MFCD or Major Functional Component
Diagram for the prototype, all have to do with testing. A testing dashboard has been created for
LAB 1 – ICAT DESCRIPTION
12
better automation of testing. This will reduce the time spent in the testing phase. The file system
will also save project tests for examination.
Figure 4
The prototype will also be creating .csv and .pdf files in the file system. This is shown in
Figure 4 as well. All of these changes from Figure 1 revolve around the prototype’s ability to
run test data efficiently.
4.2
Prototype Features and Capabilities
The ICAT prototype will demonstrate the ability to draw on the canvas, creating a project
with entities and forces. It will also showcase the ability to run two centrality algorithms,
prominence and influence, defined in Section 2.2, to generate reports. As seen in Figure 4, the
LAB 1 – ICAT DESCRIPTION
13
prototype will export to .csv and .pdf, for any needs the user may have in his attempts at solving
problems.
The prototype will provide full functionality on the canvas. This includes pan and zoom,
set controllability, and set visibility for the entities. For the project, there will be the options to
save project, save project as, delete project, print, and export to .csv and .pdf. For the ICAT,
there is little difference between the real world product and the prototype.
4.3
Prototype Development Challenges
A very challenging aspect of developing the ICAT prototype is the large scale on which
this software must be developed. There are many new things the red team will have to learn in
order to be successful. No one on the team is familiar with graphics, as it was not taught in
previous classes. The red team has decided to use Github to share code, which will also be a
challenge to learn. In order for this to be a success, it will require great amounts of effort and
determination from everyone involved, however, based on everyone’s effort in CS410, the red
team has no doubt they will succeed.
(This space intentionally left blank.)
LAB 1 – ICAT DESCRIPTION
14
GLOSSARY
Attribute – an entity that represents some quality that exhibits an effect on other entites
Entity – objects within the data model; types include: problem, stakeholder, objective, attribute,
resource
Force – constraining or enabling forces that show influence between entities
Influence – a measure of the effect that one entity has on others in the system; 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 project
Problem – an entity that represents the issue or conflict that the solution is designed to address
Project – the collection of metadata and associated diagram created by the user
Prominence – a measure of the effect the 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
LAB 1 – ICAT DESCRIPTION
15
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, 1957)
Workspace – the area within ICAT in which the user edits or views the project
LAB 1 – ICAT DESCRIPTION
16
REFERENCES
Kimball, A. (1957). Errors of the third kind in statistical consulting. Journal of the American
Statistical Association, 52(278), 133-142.
Stevens Institute of Technology. (2008). Core Concepts of Systems Engineering: Glossary.
Retrieved from The Center for Innovation in Engineering and Science Education:
http://www.ciese.org/curriculum/seproject/glossary.html
Yadav, S.B., & Korukonda, A. (1985). Management of Type III Error in Problem Identification.
Interfaces, 15(4), 55-61