Running Head: LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
Lab 2 – ICAT Prototype Product Specification
Team Red
Kirby Weeks
CS 411W
Janet Brunelle / Hill Price
April 14, 2014
Version 2
1
LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
Table of Contents
1. INTRODUCTION………………………………………………………………………….... 3
1.1. Purpose………………………………………………….................................................. 3
1.2. Scope……………………………………………………………………………………. 4
1.3. Definitions, Acronyms, and Abbreviations……………………………………………... 5
1.4. References………………………………………………………………………………..6
1.5. Overview ………………………………………………………………………………...6
2. GENERAL DESCRIPTION………………………………………………………………….7
2.1. Prototype Architecture Description……………………………………………………... 7
2.2. Prototype Functional Description……………………………………………………….. 9
2.3. External Interfaces………………………………………………………………………11
List of Figures
Figure 1. Major Functional Component Diagram (MFCD) for ICAT…………………………...8
Figure 2. Data Model……………………………………………………………………………..9
Figure 3. Centrality Algorithms………………………………………………………………...11
2
LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
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, which results in
wasted resources.
The ICAT, or Interactive Context Analysis Tool, is designed to minimize type III errors.
The phrase “a picture is worth a thousand words” is what the ICAT will be based upon. 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
understand. The ICAT will not eliminate type III, but it will make identifying the real problem
easier.
1.1
Purpose
ICAT stands for Interactive Context Analysis Tool. It 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 created and displayed.
The ICAT is an enhanced drawing tool for systems engineers. As with basic diagraming
software, there will be pan and zoom, exporting the image to different software types, such as
3
LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
.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 which shortens the time
it takes to solve problems. Instead of having raw data to analyze, a visual representation will be
created, allowing the systems engineer to have a better understanding of the problem and the
problem scope. The ICAT will give the user the ability to solve the correct problem on the first
try.
The red team’s case study is the team’s faculty advisor, Dr. Patrick Hester. Dr. 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
avoiding the type III error.
Dr. Hester has stated that when solving problems, the type III error happens much too
often. He proposed a software tool that would aid him in problem domain analysis. He has
expressed his want to visualize the problem scope, instead of looking at raw data.
1.2
Scope
The scope of the ICAT will be Dr. Hester and other system engineers. No other users will
benefit from this software. This software will be unable to benefit a person in another field. The
ICAT is a brainstorming tool for systems engineers.
1.3 Definitions, Acronyms, and Abbreviations
Attribute – an entity that represents some quality that exhibits an effect on other entites
4
LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
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
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
1.4
References
Kimball, A. (1957). Errors of the third kind in statistical consulting. Journal of the American
5
LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
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
1.5
Overview
Section 2 will be a general description of the ICAT prototype’s specifications. It will
describe the architecture, the functionality, and the external interfaces. Section 2 will only
describe the prototype, and not the real world product, as that is what the red team will be
creating.
(This space intentionally left blank)
6
LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
2.
General Description
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 decide it is needed.
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
the problem domain is an important part of the entire problem solving process. Problem domain
analysis is what the ICAT will improve.
2.1
Prototype Architecture Description
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 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
7
LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
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 Major Functional Component Diagram (MFCD) for ICAT
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.
(This space intentionally left blank)
8
LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
Figure 2 Data Model
The data model, shown in Figure 2, is comprised of a single Project, and any number of
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 is a
unidirectional arrow, which 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.
2.2
Prototype Functional Description
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
9
LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
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.
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 change the graph to represent the problem domain.
As mentioned in Section 1, 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.
The analytics engine is where the reports algorithms for ICAT will execute. 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.
(This space intentionally left blank)
10
LAB 2 – ICAT PROTOTYPE PRODUCT SPECIFICATION
Figure 3 Centrality Algorithms
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.
2.3
External Interfaces
The ICAT will be a standalone program written in Java. It will have no external
interfaces. However, it will have the capability to implement plugins in the future, should
someone desire to do so.
11