Inventory Management System
Table of Contents
I. Project Overview – written by Joshua Zawislak 4
II. MOV – written by Greg Silverstein 4
III. Management Structure – written by Jon Chaplin 7
IV. Requirements – written by Joshua Zawislak 8
2. Stage Space Design: 9
3. Set Space Design: 10
4. Bar Design: 10
5. Instrument Plot Design: 11
6. Inventory Management: 12
7. Wiring Sheet: 13
V. Function Point Analysis – written by Jon Chaplin 14
1.Function Point Method Analysis 15
VI. ICED T Metrics – written by Colin McKinlay 17
VII. Development Schedule – written by Jon Chaplin 19
1. Scheduling Method Analysis: 22
2. Risk Analysis: 22
VIII. Testing Plan – written by Nick Mattielo 26
IX. 4 + 1 Architecture and Models – originally written by Colin McKinlay and Michael Blake. Revised by Ed Morrison 27
1. Logical View 27
2. Process View 28
3. Development View 29
5. Use Case Scenarios 31
6. Non-Functional/Performance Requirements 36
X. Design Simplifications - written by Colin McKinlay and Michael Blake 38
1. Reuse: platforms, COTS, components, tools 38
2. Requirements Interpretation 39
3. Algorithms 39
Appendix C: User Feedback 55
Appendix D: Glossary of Theatrical Terms 57
Appendix F: Data Storage Diagrams 60
I. Project Overview – written by Joshua Zawislak
Stevens’ DeBaun auditorium uses a CAD tool to design and set up lighting plots. They feel that it is inefficient because of the knowledge base required to use the tool and poor data representation. Our objective, with the help of DeBaun auditorium, is to design an easy to use, GUI based system that guides the user through the lighting design phase. Though the program will be developed largely with the help of DeBaun Auditorium, it will be capable of representing the lighting design of a theatre of any size. The involved parts of the theatre include: the room that encloses the stage, the stage itself, show set, lighting bars, their wiring, and the objects that hang on them. All items in the diagram will be selected from an inventory through the use of an inventory management system. The program will also be able to print out clear, concise, lighting plots and wiring plots that conform to the industry standards for lighting. Since the theatre has several different Operating System portability is an issue. As a result, the project will be written in JAVA, with an XML backend to store the data. Lastly, this project was chosen for the unique opportunity to work with the Theatre. It is very tough to find funding for the arts, and any time or money saved is greatly valued.
II. MOV – written by Greg Silverstein
Overall Project Goal: The goal of this project is to simplify the task of setting up theatrical lighting designs. The accomplishing of this task will free up the theatre’s 2 most valuable resources, time and money. This is especially important because many theatres aren’t adequately funded and the task of setting up for a play can be very time consuming.
Lighting Related Costs:
ME = Master Electrician E = Regular Electrician
Regular Electricians make $30 per hr. Master Electricians make $45 per hr.
Desired Fiscal/Time Saving Values:
Timeframe: 10/19/04 – 4/26/05
Tasks Automated by this project:
III. Management Structure – written by Jon Chaplin
Management Structure Overview: The group is divided into three distinct groups: Coding, Documentation, and Testing. The Coding group is the group that actually designs and creates the Software Application. The responsibilities of the Documentation group are to document how the Software Application was designed. Lastly, the testing group is responsible for testing all code modules and reporting all found errors back to the coders to be fixed. The 3 groups are ultimately headed up by the project manager who is responsible for coordinating the tasks and communication between the teams, amongst other things.
Project Manager – He is responsible for estimating and creating a project schedule. He also ensures the team follows the schedule closely. Any risks/time trade offs are his responsibility to assess and act upon. He is also responsible for final say on all documentation. If necessary, he may take on some coding responsibility as well.
Software Architect – He is the most knowledgeable person from both a coding and problem standpoint. He gives direction to all software engineers coding the project in order to ensure the software solution models and solves the problem as efficiently and accurately as possible. He is responsible for the coding and bug fixing of code modules.
Head Coder – He is second in command to the Software Architect and coordinates the project with him. His job is to hand out roles and responsibilities to coders based on the coding decisions agreed upon by himself and the software architect. He is responsible for the coding and bug fixing of code modules.
Coders – They code the application modules as directed by Head Coder. They are also responsible for fixing bugs that are reported by the testers.
Documenters – They are responsible for documenting the process by which the software application was created and all changes in the process along the way. All final documentation will be primarily organized by the Documenters.
Testers – They are responsible for testing all code modules and reporting any bugs or errors that occur to the coders so that they may be fixed.
IV. Requirements – written by Joshua Zawislak
1. General requirements:
A. Successfully create a theatrical lighting design from the viewpoint of lighting
designers that a master electrician can use to implement design.
B. Able to save and load all data that is needed to recreate the project in xml
C. Ability to edit stage space, set space, bars space, lighting plot, instrument
properties, inventory system.
D. Ability to see concurrent information between different aspects of design
through a GUI driven interface using 2D drawing and text.
E. Each design space will be stored in a separate xml file.
F. To load design spaces into a project for interaction the project need to have
exactly one house space defined.
G. Design spaces will be loaded as requested by the user, except on startup.
H. Only have 1 project open at anytime.
I. All data for current project is stored in JAVA data structures while the
program is running.
J. Only read and write to xml file on saves, loads and timed backups and error
check xml files for design types when this happens.
K. There will be a print routine for workspace, inventory screen, wiring sheet,
i. The print routine for the workspace can print out design aspects
individually or overlapped.
L. There will be a connection between JAVA data structures as follows:
*note variable names can change upon creation of JAVA Data structures
M. Program will be written in Java.
N. Window size will be 640x480 or 800x600. *final size to be determined when
GUI is finished.
O. X, y, z coordinates will be represented by integers and converted to user
chosen measuring system (USA/Metric).
2. Stage Space Design:
A. Accurately represent custom stage shape, total size and height of stage
through information provided in stage objects.
B. Show size, shape and height of house space from information in house
C. New houses will create empty data structures of other design spaces as place
holders for the following spaces, stage space, set space, bar space,
instrument space, inventory space.
D. Cannot transfer stage spaces into other house spaces but can light spaces, set
spaces, and bar spaces.
E. For each house space there is only one stage space.
F. House space is not editable once project is created.
G. Stage space is editable.
H. The data that needs to be saved for the house object is:
i. Integer Array of Size 15 Holding X Values for Vertices of Room
ii. Integer Array of Size 15 Holding Y Values for Vertices of Room
*note 15 is a temporary number for amount of vertices*
iii. String Containing Rooms Name and or Description for User
iv. Integer pertaining to overall height of room
v. Random unique string id to distinguish project from others
I. The data that needs to be saved for the stage object is:
i. Integer Array of Size 15 Holding X Values for Vertices of Stage
ii. Integer Array of Size 15 Holding Y Values for Vertices of Stage
*note 15 is a temporary number for amount of vertices
iii. Integer pertaining to total height of stage.
iv. String for Notes as well as Description
v. Integer id to connect stage to a house
3. Set Space Design:
A. Set objects have the following properties:
i. Set Objects are portrayed in 2D Block Form.
ii. Ability to rotate set objects.
iii. Can place set objects in anywhere in house space.
iv. Set object properties are editable
B. For the set space the information for each set object to be saved is:
i. Integer Array of Size 15 Holding X Values for Vertices of Item
ii. Integer Array of Size 15 Holding Y Values for Vertices of Item
*note 15 is a temporary number
iii. Integer to hold overall size of the Item
iv. String For Name
v. String For Description
C. For the overall set space the information that needs to be saved is:
i. Integer for number of set pieces
ii. String name of set
iii. String id to link back to house space
iv. List of set items
4. Bar Design:
A. Able to place bars objects anywhere in house space by start x, y, z and end x,
B. Record dimmer numbers per bar object.
C. Bar objects have unique names for reference that follows a name convention.
D. Bar objects can be viewed horizontally on lighting plot or vertically.
E. Dimmer numbers can be repeated on separate bar objects, but only once per
an individual bar object.
F. The information to be saved for a dimmer is:
i. Unique Dimmer ID
ii. Integer associated channel on lighting board
G. The information to be saved for a bar item is:
i. X1Y1Z1 pair for Point 1
ii. X2Y2Z2 Pair for Point 2
iii. Integer length of the bar object (distance between point1 and point
iv. Integer number of dimmers
v. List of dimmers
vi. List of distance down the bar object the dimmer is located.
vii. String Unique to project Bar ID
viii. String id to link back to project
H. The overall bar space information that needs to be stored is:
i. String id to link back to project.
ii. String to name bar space.
iii. Integer number of bar objects.
iv. List of bar objects.
5. Instrument Plot Design:
A. Able to link instrument objects anywhere on a bar object and assign a
dimmer to the instrument object from that bar object.
B. Record x, y, z to where the instrument object will be aimed.
C. Name instruments objects uniquely for reference using a naming convention.
D. There will be a user editable list of extras and accessories for instruments
E. All instrument objects will be represented with a black and white 2D
F. Link instrument objects in lighting plot to instrument objects in inventory.
G. An instrument object has to be on a bar object, and have a dimmer from that
bar object associated with it.
H. Dimmers can be associated with N# of instruments objects.
I. Error checking for instrument objects with unassigned dimmers.
J. The information that needs to be saved per instrument object is:
i. ID number for Inventory Space
ii. XYZ Position
iii. String Name
iv. String to link to Type
v. String Description
vi. Associated Bar Object ID
vii. Associated Dimmer ID
viii. String for extra accessories of instrument
6. Inventory Management:
A. Able to keep a list of known instrument types connected to a program and
B. Able to correspond instrument objects used in lighting plot to instrument
objects in inventory.
C. Error check for # of instruments from inventory to lighting plot.
D. Able to turn inventory checking off and on through interface.
E. Able to add custom instruments types to global known instrument type
F. There will be an xml file that stores all known types of instruments
G. Can add and remove known types from the theatre project instrument listing.
The project instrument listing will be a subset of the global known
instrument type listing.
H. House spaces have list of present instrument objects for inventory
I. All known instrument types will be assumed to connect to exactly one
J. Individual instrument objects will be saved as items in inventory.
K. The following information that will be used for known types of instruments:
i. String for type name
ii. Integer array 15 XY points for displaying type in plot
iii. Integer for overall height of type
iv. String description
v. Boolean if point can be aimed or not
L. Information for an inventory item:
i. String for type of instrument
ii. Unique id for light in inventory
iii. String for description
M. Information for the inventory space
i. String for name of inventory list
ii. String id to link back to a project
iii. Integer number of inventory items
iv. List of integer items
7. Wiring Sheet:
A. Information will be displayed in a table format
B. Wiring sheets based off of instrument objects and will list the instruments
C. Following properties must be able to be shown in a wiring sheet: instruments
name, dimmer, bar, position on bar, aim to point, extras the
instrument contains, and description of the instrument
D. Wiring sheets can be created from project.
E. Wiring sheets can be saved separately from a project not necessarily in xml
F. Wiring sheets can be edited separately from a project but is marked as so.
V. Function Point Analysis – written by Jon Chaplin
UFP = 4I + 5O + 4E + 10L + 7F
UFP = 4(3) + 5(1) + 4(5) + 10(1) + 7(1) = 54 Unadjusted Function Points
Technical Complexity Factor (TCF)
TCF = .65 + .01DI
TCF = .65 + .01(31) = .96
Function Points = UFP x TCF = 54 * .96 = 51.84 ~ 52 function points
54 UFP * 77 sloc / UFP = 4,158 sloc = 4.158 KSLOC
or approximately 4,158 lines of code.
(Source for sloc per function point: http://www.qsm.com/FPGearing.html)
The following formula calculates staff months:
Staff Months = 2.4(KSLOC) B
First Calculate B using B = 1.01 + .01(i wi) where i wi is the sum of the weights in the following table.
B = 1.01 + .01(i wi) = 1.01 + .15 = 1.16
Staff Months = 2.4(4.158) 1.16 = 12.53 Staff Months
Because the calculations dictate that 5.01 coders are needed for this project and there are only 4 primary coders (2 coders, 1 head coder and 1 software architect), the following actions will take place:
A. In the event coding isn’t proceeding according to schedule, some work may be assigned to the project manager. However, because of the learning curve associated with the project, and extra communication required any work assigned to a 5th coder will be minimal.
B. Coders may put in a little more than 20 hours some weeks to make sure that
coding gets done on time.
C. To alleviate pressure on coders, the bulk of the documentation will
be handled by the rest of the team.
VI. ICED T Metrics – written by Colin McKinlay
Intuitive – The intuitiveness of the project should be its major selling point. Two of the project’s major goals are Intuitiveness and Flexibility. Therefore users should be able to create Theatre spaces by multiple means that are easy to understand. However, some knowledge base is required because technical theatre terms will be used in the program.
Consistent – Consistency is also important because consistency in methods and appearance is part of what aids the ease of use. Ideally, the user should not be put in an environment in which he/she is too unfamiliar with.
Efficiency – It is important that the program be efficient because another major goal of this project is to save the theatre time and money. If the task could be accomplished faster by hand, then the application is not doing its job. Saved time not only means more time to allocate to other aspects of theatre design, but perhaps saved money as well.
Durable – The project should be able to work on multiple operating systems, hence the decision to code it in JAVA. It should also be able to model a wide range of theatres.
Thoughtful – Thoughtfulness plays into user friendliness as well. Our methods and implementation should be well thought out. Well thought out methods will ultimately be as easy to use as possible.
VII. Development Schedule – written by Jon Chaplin
Figure 1 (Task List Part 1)
Figure 2 (Task List Part 2)
1. Scheduling Method Analysis:
The two methods that will be used for development of the Theatrical Lighting Design project will be the Spiral Method and Evolutionary Prototyping. We feel that evolutionary prototyping is best used for this project because it emphasizes constant user feedback. Constant feedback from a variety of users promotes user friendliness, flexibility, and scalability which were 3 of the user’s primary goals. Constant user input will cause the project requirements and the project to change frequently. Thus, we chose the spiral method because of its flexibility. The spiral method allows for us to use any phase of the design process (Design, Requirements Engineering, Testing, etc.) at any time rather than being restricted to a sequential process such as the Waterfall Model.
Ultimately, through our input driven and flexible design method we hope to produce a product that is both intuitive, and able to represent a variety of theatre spaces differing in both size and shape.
2. Risk Analysis:
VIII. Testing Plan – written by Nick Mattielo
In general, the development process that will be used during the course of this project is evolutionary prototyping. With each release of the program, a testing process using regression testing will take place. A log will also be released along with the upgraded version letting the testers know what was changed and what features to test, as well as how these features work as to ensure the testers know how any added functionality should work.
In addition to this log, there will be another log to keep track of bugs. If any bugs/defects are found, they will be added to this log, along with their priority. Priority ranges from minor, major, and showstoppers depending on how the bug affects the projects. Minor bugs are little things that can transfer from version to version and we will list along with the log if bugs have been fixed or not. This is also the case for major bugs, but will be given more priority. Minor bugs include little things that don’t affect functionality, such as text outputs that are misaligned. Major bugs include things that allow the product to work, but a certain function(s) work improperly, such as wrong data when loading/saving. Showstoppers are bugs that must be fixed immediately, such as program crashes.
Lastly, a log of test cases will be used, as we will be using regression testing. This is to ensure not only that we know the desired result every time, but since we know the specific outcome of a test case, can be used to acknowledge any new functionality that has somehow changed previous versions.
IX. 4 + 1 Architecture and Models – originally written by Colin McKinlay and Michael Blake. Revised by Ed Morrison
1. Logical View
The program we are developing is designed to help facilitate theatrical lighting design. Through a detailed interface the user can manipulate stage layouts as well as add/edit objects that can be placed in the design. The performance will be tested severely when loading previously saved layouts. Much processor time will be needed when drawing the many objects on the stage. Throughout the rest of the program, there will be relatively little lag. Since our program relies heavily on the GUI, we can optimize where we see fit.
It is necessary for this design system to be flexible. Multiple different stages plus custom objects must be handled, as every stage/set has different needs, including varying lighting systems. The handling of custom objects can be managed through the inventory system. Objects, such as lighting bars and dimmers, can be added, edited, and removed. Not only will the objects be changeable, but the stage layout which includes the stage size and bars can be adjusted to fit the users’ needs.
Logical view diagram by Ilya Buzharsky
2. Process View
The goal of this theatrical lighting design system is to assist the user in managing and designing a stage. The most important part of this program is the main screen in which a layout of a stage is displayed along with objects available to the user.
Default objects will be preloaded with the software. The user can navigate to a form in which they can manipulate all of the objects in a number of different ways making use of the different views (3). These objects will be drawn on screen through a point and click drawing interface.
Making use of the three dimensions is essential to providing a usable piece of software, as the current method of designing these stage designs have this feature and so shall ours. Three dimensions are vital for the placement of the lighting bars/dimmers.
After designing the stage layout with the available tools, the user is able to save this layout. Layouts will be saved in an XML format in a quick and efficient manner. The loading of these layouts is supported as well. Despite the save and load in XML functions, there is an additional export feature. Exporting a lighting design will save the layout in a format through which users without our design software can view lighting designs. Additional system compatibility will be considered concerning the exported format as that will enhance its portability.
Process View Diagram By Ilya Buzharsky
3. Development View
This product will be implemented within the Java 2 development environment, with an XML backend to communicate between separate modules (loading, saving, etc.). The decision to use Java as our main language was based on demands for portability. Our client’s organization, DeBaun auditorium, contains workstations that run Windows, Mac OS X, or Linux, and are used frequently by employees for day to day theater operations. The universality of Java permits it to be run on any of these systems. Related files may be exchanged from one workstation to another seamlessly, and schematics can be printed as a layout for the master electrician. Development and testing will follow an evolutionary prototyping model. Each new version will build on the features of the previous, and delivered to the customer for trial and feedback. All modules will be tested thoroughly on each successive release.
Development View Diagram By Hari Patel
4. Physical View
The interface will consist of a main window which will serve as a container the view screen and other editable objects (i.e. text boxes, toolbars, checkboxes, etc). The view screen will be a top-down, two-dimensional perspective. View screen elements, and other inventory items will be usable via a drag-and-drop interaction method, to allow for flexibility. Wiring diagrams and lighting diagrams will also be present for the electrician. This is important because it will allow for the many variables that can occur in stage design, and was deemed imperative by our requirements and those of our client. Objects within the view screen will have specific properties based on object type (i.e. bars have a location and number of dimmers, etc), and these properties can be viewed on the Properties sub-window, and edited within. The same premise applies for objects within the inventory subsystem.
A system that runs this program needs to meet the following hardware requirements to ensure the program runs efficiently under normal usage:
5. Use Case Scenarios
4) Electric Bar Design – electrical bars are used to hang instruments.
g. Ensure all data is correct for bars and dimmers and that any related values
correspond to the correct object/project.
5) Instrument Plot Design – instruments are anything that hangs off of an electrical bar and is plugged into a dimmer on a given bar (electrical socket).
dimmer available on that bar.
f. Must be able to associate x, y, z, coordinates to an instrument representing
where it is aimed. Test to make sure these coordinates are within house space (not outside house, not under the stage, etc).
i. GUI must be able to graphically represent (in black and white) an
instrument. This will be tested with 0 instruments and many combinations
of built-in and created instruments.
7) Wiring Diagram – the wiring diagram is the printout that will be handed from the designer to the electrician in order to hang lights.
6. Non-Functional/Performance Requirements
A. Generally accepted technical terms are to be used.
B. The program should take less then two minutes to open with no active
C. If all dimensions are known it will take less then 5 minutes for a trained user
to create a house and stage space.
D. It will take less then 5 minutes for a trained user to create and place a set
piece if all information is known beforehand.
E. It will take less then 5 minutes for a trained user to create and place a
F. If all information is available it will take a trained user less then 3 minutes to
place an instrument on a bar
G. For a trained user if all information is available it will take less then 5
minutes to add an instrument to known types
H. For a trained user it will take less then 2 minutes to edit an instrument in
known types if all information is known
I. For a trained user it will take less then a minute to add remove and
instrument from inventory.
J. Program can support up to 6000 instruments.
K. House dimensions must not be greater than the maximum amount for the
data type being used.
(Please reference Physical View on pg. 22 for hardware constraints)
X. Design Simplifications - written by Colin McKinlay and Michael Blake
1. Reuse: platforms, COTS, components, tools
Our main project goal is a simplified yet flexible replacement of the theater’s current Lighting Design software. Currently the theater uses SolidWorks CAD or VectorWorks with a plug-in called SPOTLIGHT, as an extension for lighting design. Though useful for engineering purposes these programs are overly complicated and not catered to certain aspects of lighting design. These programs are the basis of our project and product; their features provide a rough outline for the Model Driven approach we are using.
For development, our primary software tool is Netbeans v4.0 (http://www.netbeans.org) which provides us with the necessary libraries and features to code and test in the Java 2 Environment v5.0. Other useful features include: a CVS server interface, a debugging interface, and JAR file building. The CVS server interface makes it easier to maintain and version code. The debugging interface allows us to set break points in the code, go through the code step by step, and observe values of variables at those break points. Lastly, JAR file building allows us to build and distribute the code as a single executable. Not only does this allow for convenience to the user, but it also prevents anyone from accidentally modifying the source code and consequently introducing bugs into the system! As with our software product, Netbeans itself is cross-platform. This makes it possible to easily develop and test on different workstations.
Non-personal group communication is mostly done via email. For non-code file sharing purposes, we utilize webspace at MSN Groups (http://groups.msn.com), as a central file repository. To keep things organized, a system of program identification is implemented. Any modified file ends in _R (number), where "(number)" is the number of times a file has been modified. All changes between revisions are tracked in a revision history. If data storage limit on MSN becomes an issue, we also have an FTP site courtesy of Prohosting.
For our development team, version control is done through our Concurrent Version System (CVS) server, located at cvs.tlighting.berlios.de. This is accessed via the aforementioned code editing software, Netbeans IDE. The website itself has several other functionalities, and can be found at http://www.berlios.de/ . Using this client-server interface, our developers can access code from any workstation with an internet connection. It also allows merging of different versions of code into one version, thus allowing multiple people to work on the same file at the same time.
2. Requirements Interpretation
In order to understand and interpret the requirements it is first essential to understand the reasons behind the project. The reason we’re doing this project is to save theatres time and money in their lighting design process. It’s an expensive and time consuming process that can be better optimized with custom fit software rather than the CAD software used in DeBaun, or other such programs used by theatres.
Requirements such as “Successfully create a theatrical lighting design from the viewpoint of lighting designers that a master electrician can use to implement design.” are in place to save time communicating between lighting designers and electricians. If a lighting designer can successfully implement a design in which the electrician can clearly understand it eliminates questions the electrician has to ask and time spent trying to understand/interpret the diagram.
Performance requirements such as “The program should take less then two minutes to open with no active project loaded.” are in place so that the program doesn’t take too long to do simple tasks. Our primary goal is user-friendliness, however, if the system is excessively slow because of the user-friendliness it becomes counterproductive. No time is saved if the designer can easily figure out how to use the system but has to wait long periods for it to do the tasks he needs.
Flexibility requirements like “Accurately represent custom stage shape, total size and height of stage through information provided in stage objects.” are in place to not only accurately draw stage objects based on inventory but represent a wide variety of theatre spaces as well. With the implementation of the inventory management system, the user can add existing or custom theatre objects to accurately represent the theatre inventory they have. Allowing the user to draw custom stage shapes also helps them to represent whatever theatre situation might be at hand.
A. Scaling Items: Items are scaled based off of a user set scaling factor rand taken
into account with drawing functions and user interface functions.
B. Item bounds: As long as the objects can be seen by the user, they can be
C. Drawing Bars:
i. Direction: A bar can be drawn on any x,y angle, but only horizontal in
the z direction.
ii. Length: A bar can be any length within the bounds of the house
iii. Width: The width of the bars is irrelevant and therefore not needed.
iv. View: Bars can be viewed at different angles (x and z axis only).
D. Drawing Objects:
i. Method: A custom class is used to store node positions. The class is
inherited so that all derived objects have drawing functionality. Objects
are then drawn to the screen when appropriate.
ii. Storage: The drawing information is saved in the data storage classes
and also gets passed to xml for storage.
E. Object Placement: Based on a point and click algorithm for movement,
creation, and additions of all objects.
F. Object Limits:
i. Location: Objects can only be drawn in the stage area.
ii. Size: An object’s size is limited to the space available on the screen.
iii. Amount: The amount of objects that can be placed is theoretically
limited, though realistically this constraint varies.
All saved project data in our backend will be stored using XML tags. We are using NanoXML (http://nanoxml.cyberelf.be), an open source, modular XML parser to extract data from the tags when it has to be loaded, and insert tags in the backend when it has to be stored. Since NanoXML is not fully developed by our team code will be added to conform to the technical specifics of our project. Although there will be work added in making NanoXML conform to our project specs, we feel that the effort saved from writing our own parser outweighs the effort of integrating this one.
Decisions that factored in the choosing of this parser were its small size (32 KB), its speed, and flexibility. NanoXML’s speed in parsing is demonstrated in a test against the Xerces XML (http://xml.apache.org/) parser. Both parsers were tested in parsing a well-formed 19KB XML file with and without other applications running. In both tests NanoXML parsed the file faster, 22 milliseconds faster with nothing else running, and 122 milliseconds faster with 4 other applications running(MS Word, McAfee Virus Scan, MS Outlook and AOL instant Messenger). Since it runs so efficiently with other programs running it should have no problem running well while our JAVA front end is running. NanoXML’s flexibility is demonstrated in its handling of data structures. The parser allows you to import a single xml file without regard to its data structure in 5 lines of code. The resulting data structure is not a string that requires more parsing but rather a set of internal data that may be navigated like a tree which is very easy and makes coding a lot simpler rather than writing my own routines to parse the translated string.
Another area where we've found we can save effort is the print functions to print out hard copies of the diagrams. The print functions, found at the following source http://www.apl.jhu.edu/~hall/java/, are both flexible and fast. These functions allow us to use 1 print function for many components rather than writing an individual print function for each object that needs to be printed. In the event that much printing needs to be done, there is even a small function optimization that speeds up mass printing.
Overall, the adding of both these refactored components saved us 9 function points. Using a conversion factor of 62 sloc / function point (Source: http://www.qsm.com/FPGearing.html) we are expected to save approximately 558 source lines of code in total. The effort and time saved from adding these components can not only be used in adding more features, but can be used simply in testing and improving the existing ones. Overall, the time saved through using refactored components should promote a more flexible, reliable, and efficient product.
XI. Coding Standards – written by Greg Silverstein and Ilya Buzharsky
The purpose of this section is to provide documentation for the tools and methods
used during this project to aid in coding as well as to maintain control and good practices throughout the project. This should also serve as a guide to what the system requirements are needed on developer stations, as well as production stations.
1 Tools Utilized
1.1 CVS Server (Continuous Versioning System)
1.1.1 The server is provided free via the website
1.1.2 The primary rational behind using this tool is to maintain
control over the code being developed by several
developers throughout the project. At a bare
minimum there will be 4 coders working at all times. Using
a manual method for this would be impossible.
1.1.3 This tool also allows accountability for the code added. If a
bug is found it is easy to trace who is responsible for the
code generated allowing the best developer for the task of
correcting the bug.
1.2 Task Management Tools
1.2.1 This tool is also provided via the free website listed in section
1.2.2 This allows for easy task management of all tasks ranging
from documentation to testing. Coding may also be broken
down into priority components and allows for work to be
spent on critical sections first.
1.3 Bug Tracking Tools
1.3.1 Provided via the same website as listed in section 1.1.
1.3.2 This tool allows for the testers to open logs easily for the
correct developer when bugs are encountered. This will
provide easy tracking of open bugs as well as previously addressed issues for documentation as well as later testing.
1.4 Project Visibility
1.4.1 As much of the project is located online it is easy for the user
to partake in the development cycle. This involvement of
the client will allow us to satisfy the needs of all
1.4.2 The client will also be able to see bugs in the system as well
as provide realistic user test cases throughout the development cycle.
2 Code Standards (Literal)
2.1.1 There are no standards established formally for code format
or naming conventions. Although it has been addressed that all code must be easily readable and the developer responsible must be available for comments on their
work when needed.
2.1.2 All code must be well commented to give others guidance for
this section of the code.
2.2.1 Due to the many modules being worked on there are specific
task areas assigned to the primary developers. This is so
each developer is highly knowledgeable about specific
portions rather than several developers somewhat
skilled in all aspects. This will allow for quicker debugging
184.108.40.206 Greg – XML parsing for saving a loading project
220.127.116.11 Josh – Drag and Drop Interface and print output
18.104.22.168 Ilya – Primary UI
22.214.171.124 Hari – Intermediate Layer
2.3 Code Architecture
2.3.1 Our code is designed to work on a three layered platform all built on top of the Java(TM) VM.
126.96.36.199 The bottom layer contains the data interfaces to the
xml and external file formats. This is for saved
188.8.131.52 The intermediate layer holds all pertinent current
data and controls program flow. This layer will interface between the data and the UI.
184.108.40.206 The UI and Drag and Drop are built on top of the
intermediate layer which provides all needed data and state.
3 Configuration Management
3.1 Developer Workstation
3.1.1 All developers are required to keep a copy of the most
current Java VM installed on their system.
3.1.2 Netbeans IDE
220.127.116.11 Supports CVS access
18.104.22.168 Updates local Java VM automatically
22.214.171.124 Provides GUI tools for rapid development.
3.1.3 Coders must adhere to the most recent XML standards as
3.2 Production Workstation
3.2.1 Any Operating System
126.96.36.199 Java VM Must Be Installed
188.8.131.52.1 Most current version is recommended. For
consistency of program behavior.
184.108.40.206.2 Must contain disk space to store saved project and
the program code itself.
220.127.116.11.3 Must have printer with system driver installed for
Java VM to perform the print functions.
18.104.22.168.4 Color Monitor is recommended to communicate
which objects are selected and which are not more clearly.
XII. Demonstration Plan – written by Don Salotti
This section entails how the product will be demonstrated to a party interested in using the software. The major goals when designing our system were to create an easy to use software tool capable of representing a wide array of theatres with ease. We feel that we do this through three major characteristics: User Friendliness, Flexibility and Reliability.
To begin with, our program is installable on any user workstation as long as it has JAVA and the proper hardware configuration to run JAVA (See Physical View on pg. 22 for hardware constraints). However, the User friendliness of our system is best demonstrated by the simple point and click interface with which you can design a theatre. The objects that can be added to a theatre are as follows: House, Stage, and Set Item, Instrument and Bar(see appendix for definitions). An object is added by simply clicking in the center pane(draw pane), right clicking the mouse then selecting add object from the drop down that appears. After selecting add object from the menu, the object is drawn for you as you click points on the screen. To finish the object you simply right click again and select commit from the drop down menu that appears.
Flexibility is best demonstrated by the wide variety of ways that the program accepts user input. After an object is created it is selectable not only in the drawing pane, but in an expandable drop down menu on the right hand side of the screen as well. This menu details all objects created in the drawing pane. In addition, object information is displayed in the upper right hand corner of the screen when the object is selected. This allows the user to check the information of the object without having to change screens to the inventory manager. Lastly, for diagram clarity, types of objects may be removed so that it is easier to view objects that “overlap” vertically.
Reliability is best demonstrated by our error checking. The program also acts as an inventory manager. Objects may be added to the project through the inventory manager and subsequently drawn on the screen if needed. Only objects in inventory may be added to the theatrical lighting design itself, thus making it impossible to design a theatre that exceeds your inventory. It is also impossible to draw objects outside the house space since the house encloses the entire theatre.
XIII. Release Plan – written by Harikrishna Patel
On Tuesday, April 26th, our group plans to deliver the finalized and fully functional ‘Lighting Design & Inventory Management System’ to DeBaun Auditorium of Stevens Institute of Technology. The software will be put on a CD that will be used as a means to install the system. Though capable of fitting on a disk (actual program size is < 300 KB), we feel CD distribution is best because it is a more widely used medium of transfer. Despite its size, since it will be a compressed file, we feel it should be put on a CD for compatibility reasons. In future, we are also planning to distribute the software via internet as per the demand.
The Software will be installed in the JAR (Executable) file format. In this manner, our foremost purposes of user-friendliness and ease of use is served since the software can be run just by double-click. Not only running the software is easy but also the installation process is considerably easier by having the software in the JAR executable file format. Besides the ease of use, it makes the software secure since there is no chance of introduction of errors through modifications in our fully functioning program. As it is mentioned earlier, the users must have JAVA platform installed on their computers because without the JAVA platform, JAR files don’t work.
The open source files that create the final JAR executable file will be stored for later use, and available upon request. We felt that this software will need changes and upgrades in the future as the requirements and structure of the theaters change. Once again, to serve our primary purposes of user-friendliness and ease of use, it is very important that there is enough room for improvement in the system as the time passes. The primary need for the improvement in any software is the source files therefore our source files will be available upon request after our final release.
To check the features of our system, please check the Development Schedule section on page 13. In this section, you will be able to see the different features added to the system at different releases.
Appendix A: Preliminary Customer Survey
Q-1: How much time do you spend on a lighting design by hand for small show?
A-1: 5 hours
Q-1A: medium show?
A-1A: 10 hours
Q-1B: Large Show?
A-1B: Wouldn’t really do it… but 25 hours or so probably….
Q-1 Notes: Much of the design process doesn’t involve making the plot… the artistic process that takes place before sitting down and creating a plot (reading the script, meetings with director, etc... etc…) can be a huge amount of time, but this is a constant regardless of the method by which I am creating the plot (by hand, CAD software, etc…)
Small shows I often won’t do all the paperwork in advance simply because they are more manageable so it can be done on the fly and jotted down on the back of a napkin as I work. However, this is often because I am both the Designer as well as the master electrician, making the working situation notably different. Under “normal” conditions jotting it down on the back of a napkin is not an option.
Generally, the designer will hand over all the paperwork to the master electrician who will hang and “rough focus” the show (along with other electricians for a big show). The designer will then go through and “fine focus” everything with the electricians.
Q-2: How much time do you spend on a lighting design with CAD program for small show?
A-2: 5 hours
Q-2A: Medium show?
A-2A: 7 hours
Q-2B: Large Show?
Q-2B: 20 hours
Notes: Pretty much... I’ll save time because the CAD will keep track of dimmer numbers, channel numbers, etc… and the paperwork will be automatically generated saving some time.. but any other time saved is eaten by fighting the stupid software!
Q-3: How long does it take to hang instruments for a small show?
A-3: 10 staff-hours.
Q-3A: medium show?
A-3A: 20 staff-hours.
Q-3B: large show?
Q-3B: 40 man-hours
Notes: I am estimating if I was hanging a show from scratch… at DeBaun we often work off a “house plot”, so 60% of the lights are already hung and don’t move. Also, that is a large show at say DeBaun... a large show at like a broadway theater would obviously be many many more hours both for design and hanging
Q-4: How do you normally give information to a master electrician for a small show?
A-4: Back of a napkin or not much more than that… usually just a rough plot and a little explanation… I let them pick dimmers and stuff and give me that information back…
Q-4A: medium show?
A-4A: Paper, but still a rough sketch
Q-4B: large show?
A-4B Output of CAD software….
Q-5: Is there any problems with the any of the methods that information is given to the master electrician?
A-5: Yea… back of napkin is kinda inefficient cause I give them a plot they give me back dimmer numbers etc… However, this is all drawing off of limited experience cause 70% of the time I am my M.E…. I still use the back of a napkin though
Q-6: How often do you reuse old light designs with slight changes?
A-6: In DeBaun, often... in other spaces never. But I get the impression though that many schools and small community theaters use the same designers over and over again who are probably working off similar designs that they have before.
Q-7: With a cad program how long does it take to design a house and stage space?
Too friggin long… I’ve probably worked in 5 spaces in the last 4 years and DeBaun is the only one I’ve bothered to do it for cause it’s the only place I keep going back to more than a couple of times…
Q-8: With a cad program how long does it take to design the bars in position?
A-8: Not bad… the Spotlight Add-On to vectorworks provides tools to automatically instead trusses and stuff… oddly, just straight pipes are more difficult cause you have to draw them and convert them to be defined as a “lighting position” in order to make the instruments associate with that “lighting position” and it took a bit of reading the manual to figure that part out… also, creating both 2-D and 3-D views of the symbol is a pain in the ass…
Q-9: With a cad program how long does it take to place lights on the bars?
A-9: Probably only half an hour or so… figuring out how to define them as “lighting positions” was a bitch though… but once its figured out, I suppose if I designed lights full time and used it all the time it wouldn’t be so bad… but I forget everytime I use it… quite un-intuitive
Q-10: Do you normally make a wiring plot by hand or with computer aide?
A-10: My hand if I did the plot by hand (small and medium shows) with computer
if I did the show by CAD (the spotlight addon for vectorworks will do it)
Q-11: How long does it take to make a wiring plot by hand?
A-11: Too friggin long… usually if I’m doin it by hand its cause I just hung the lights on the fly with the aid of some notes on the back of a napkin then I;m goin back and tryin to look at the bars to see whats on what dimmer and jotting it down (again on the back of a napkin often) .. but to give a number to it… maybe 15 minutes if I did it ahead of time and stuck to it, but doing it ahead of time also means u take more time hanging the lights cause you have to follow what you said otherwise its useless… If I do it after the fact probably bout half an hour
Q-12: How long does it take to make a wiring plot with computer aide?
A-12: If I was good and added all the information to the computer software that I should have in the first place .. about 15 seconds
Q-13: What’re the wages of the typical employees that work on a lighting design hang?
A-13: The question about wages that you asked… I checked with a friend of mine who is in the union – these prices are before union dues, health insurance, taxes, etc.. .so this is what the theater pays out.. the electrician is then responsible for paying all of the above:
Master Electrician: 600 – 1000 /day
Electrician: 400 – 600 /day
Not sure what designer rates are for the union… I know that non-union can range from a couple hundred dollar stipend for a small theater to a couple thousands for a big job… I did a couple “flat-rate” jobs for Jersey City University and got $600 each... that was probably on the low side. Anne McMills can give you some move information on Union rates I’m sure.
Appendix B: Timed Software Trial Statistics
1) Preface: Prior to undertaking the primary work of planning and implementing our custom solution for the theater we speculated at a reasonable goal of improvement in the work process for those who would be using our system. This estimate would provide a solid perspective for our perspiration throughout this project; a metaphorical mile marker for our success.
2) Purpose: The purpose of this section is to explain the reasons for performing this measurement as well as the reasons for the various acceptance questions.
3) Rationale: To estimate what we would like to accomplish was one of the many required tasks to receive a passing grade on our assignment. However throughout our project the main goal has been to satisfy our customer. To do so we set a goal or MOV for our project. In this packet we assessed our success or failure through standardized testing of certified theater employees with both our software and the previous system. The results are attached as a set of surveys as well as a work measurement worksheet including all tasks required to set up for a lighting design project. This would include install, initialization, saving as well as a host of other activities performed by a user. Although a complete theater was not modeled an analog could be made between these activities and a full project as a full project would amount to solely a repetition of these or similar activities.
4) Measurement: Our measurement was performed on a project member Josh Zawislak who is a member of the theater and has set up many lighting designs. As such he makes an excellent candidate due to his prior experience. Josh was timed performing actions in both Vector Works as well as our solution and the results are recorded below.
5) Measured Standard Data Sheet
6) Analysis: The end result of our system was that we achieved our MOV. Although not all system functionality is complete at this point our product still fits into the customers system and increases the rate of work. This ultimately results in more money back in the customer’s wallet from a slimmer payroll. Ultimately we ended up with a 60.83% reduction in time spent on activities to the Vector Works Software. Although we were unable to test the program in a situation with the electrician we can analyze this data in reference to our first measurable MOV element which was to reduce time spent learning and using the software by student designers by 25%. To this target we were 143.33% effective. This is due mostly in part to our focus on ease of use. There were several areas, which hurt our performance. The first would be the overall performance of the JAVA VM. Although very robust and helpful in attaining our goal of system independence and project portability, Java has difficulties saving, printing and displaying data as rapidly as a more integrated language such as C++. One other area where we lost time on the competition was in the fact that each time one wishes to use our inventory manager they have to re-open the tool from its menu. While this is much easier than the previous method of maintaining a document (MS Excel), once the Excel file is opened for work we actually lose time to the previous system here. This is however offset by the tremendous gains we made in other areas through a cleaner and more audience targeted application.
7) Survey Data: This information is a post measurement survey given to Josh to gain qualitative data about the application. Although this is not a recommended method we feel it invaluable to have word of mouth information from a future user of our system to help not only guide us through the final portions of coding but as well as to help others who may take up our project at a later date.
The first questions were questions responded to on a scale of 1 to 10:
The remaining questions were a direct comparison for the user between our application and Vector Works. IE In which program was this task easier.
8) Analysis II: With the data gathered from the survey we can ascertain that in the very least our application is on the right track. The user responded positive for our project in almost all of the questions asked. This survey also pointed out suggestions for future fixes such as a simpler file interface as well as perhaps adding more user-friendly utility to the design phase of the application.
9) Impact: The end result of this analysis determines that our product is indeed useful. It may not be as complete as we may have first anticipated but it has however assisted the customer in terms of time, money as well as ease of use.
Appendix C: User Feedback
I have been using the Lighting Design and Inventory Management software
for the last few days, to document several typical arrangements here at
With a few more features completed, it would prove to be a useful tool
in the planning and implementing of the stage lighting at DeBaun
Auditorium, for events both large and small.
The interface is logical and well displayed. With more editable details
in the Item Browser and dimensions in the Drawing Window, the design
information could be fully transmitted to the electricians responsible
for hanging and focusing the instruments.
Once the information is entered into the inventory, it is easy to place
instruments in the design. The flexibility of easily adding and
changing the stage and bars makes the software useful in any space.
Ergonomically, there are a few points that could be improved. Having to
mouse click to focus each window before entering information slowed
down the design process slightly. Selecting objects from the Stage
Items window would be easier if the outline did not collapse after each
action. The outline itself is a clear way to see what objects are in
use. The ability to select and move objects directly with the mouse
would be useful.
Being able to print the design with all of the aiming information would
be useful for the electricians.
Feel free to use any or all of my comments, as you see fit. Thanks for
the opportunity to act as your customer in this project. If there is
anything else I can do for you, please let me know.
Appendix D: Glossary of Theatrical Terms
Bar Diagram - The layout of where bars are placed and what dimmers are associated with these bars and the instruments attached to the bar.
Bar Object - Object that represents places where Instruments objects can be placed.
Bar Space - The area that bars contain and the information needs to represent bar objects inside this space.
Design Aspect - Different design points that the program can be used to illustrate. i.e. set designer and Lighting designer, Master Electrician.
Design Space - The different spaces in the program are: House space, Stage Space, Set Space, Bar Space, Inventory Space. These Spaces can be overlapping in x, y, z positions.
Dimmer - A power plug that is connected to a bar.
House Space - The building design portion that defines the space that contains all other spaces.
Instrument Object - Object that represents items that are put onto bars.
Inventory Item - A lighting object that is usable inside a house space.
Inventory Space - The portion of the design aspect that deals with what is in inventory or being used currently in the lighting plot.
Lighting Bars - Anything that is used to support a lighting instrument. (Bar for short)
Lighting Instrument - Anything that is attached to a lighting bar and plugged into a dimmer. Called Instrument for short or also called fixtures.
Lighting Plot - Represents where instrument objects are placed, where they are aimed, and what dimmer they are plugged into.
Props - anything used by actors during the performance.
Set - all platforms and walls used by actors that are not permanent to the house.
Stage Object - Object representing the stage within a theater.
Stage Space - Part of the building design area that the stage object takes up and the information needed to represent a stage object within area.
Wiring Sheet - Tabled data that represents where instruments should be placed aimed and plugged into along with other data.
Workspace - The Part of the window that holds the drawing and text that is used in the different design aspects.
Appendix E: Lessons Learned
After completing a project of any size it is easy to look back and find a better approach to accomplishing the same goal. This is especially true of a project in which the final version does not have all the features implemented that were set forth at the outset. Problems such as miscommunication, misappropriation (of time and resources), and enforcing deadlines all contribute to late projects. There is no one cause or one error that makes a project late. Any late project is the result of many different errors in understanding that may be dependent on each other, and occur one at a time.
The most blatant reason for not finishing the project is time management (or lack thereof). Although a schedule was set at the beginning of the project, some tasks were harder than they appeared. As a result, any tasks dependent on these “harder tasks” were delayed and thus delayed the project as a whole, rather than just the installation of the feature itself. This is evident in our usage of the open source XML parser used in saving/loading data. The parser was supposed to be easy to install and save lines of code, but actually delayed our release two weeks (see risks 10 and 11 on pgs. 18-19). Also, our goals were a bit ambitious for the given time period. The function point calculations show that 5 coders were needed for this project, and we attempted it with 4 full time coders and 1 part time coder. When this is coupled with the fact that not all coders completely understood JAVA it is easy to see why our project got delayed.
Another reason the project was incomplete was communication between team members. In groups as large as ours (10 people), some sort of communication standard needs to be set. Ideas such as naming conventions in the code, standardized diagrams and clearer requirements could all have been present in this project. Naming conventions allow for a quick and easy understanding of what functions do as opposed to the time consuming task of looking through the code to understand them. Standardized diagrams allow the group to communicate about the many different parts of the software through a common terminology. This avoids the different words different individuals may use to describe the same part of the program. Lastly, clearer requirements allow people to understand from the very beginning rather than ad-libbing and trying to understand many complex ideas and concepts as the project progresses.
Finally, meeting and enforcing deadlines contributed heavy delays to the unfinished project. Though an ideal schedule was set, somewhere around the middle of the project deadlines were not being met. When these deadlines were not met more hours were scheduled, but got little results. We feel that if more people had understood the problem and planned solution from the outset that many consequent tasks would have been made easier, and the project would have been made more complete.
There are many reasons that projects go wrong. It takes many different people working together to make any successful project. Consequently, different people think in different ways and there must be a standard language or medium of communication between them. As the team size grows, so does the effort needed to communicate amongst them. Time mismanagement in general is also a big problem. More specifically what to do when scheduled hours cannot be met due to outside commitments and other issues. Even though written code and documentation are the only measurable results from a successful project much time and consideration must be put into planning or the project will ultimately be unsuccessful.
Appendix F: Data Storage Diagrams
XML diagram by Joshua Zawislak
Additional XML structure available in the appendix.
Diagram that details structure of XML “Bar” Object and its attributes
Diagram that details structure of XML “Bar Item” Object and it’s attributes
Diagram that details structure of XML “Bar Item Type” Object and its attributes
Diagram that details structure of XML “Dimmer Object” and its attributes
Diagram that details structure of XML “Edge” Object and its attributes
Diagram that details the structure of XML “House” Object and its attributes
Diagram that details the structure of XML “Inventory Item” and its attributes
Diagram that details the structure of XML “Project” Object and its attributes
Diagram that details the structure of XML “Set Item” Object and its attributes
Diagram that details the structure of XML “Stage” Object and its attributes