Preface
This is a formal document which lays out the design of our project. However, it is primarily internal, thus it will be viewed only by our team and Professor Greg Welch. Therefore, Dr. David Thissen, the client, will not be presented with a copy. This is the first version to be delivered, and if revisions need to be made, they will be before the implementation manual is put together.
Glossary
Item Parameters – In the input file, there is information about a test. For each question on that test, there are three data points: a, b, and c. These are called item parameters. They are used in the generation of tracelines.
Tracelines – Tracelines are generated using the item parameters. They are graphs which represent the probability a person got a question right or wrong, based on the intelligence of that person. The harder the question, the steeper the slope of its traceline.
1. Introduction
Basically, we are reworking a product that Dr. David Thissen created. We are also adding some functionality and making the product user friendly and cross platform. Furthermore, Java is being used in the development of the new product, as opposed to the original C++. The current interface, where the user enters a series of numbers to represent choices, is to be replaced with a Graphical User Interface (GUI), and the output will be similarly updated. The recursive mathematical algorithm that is the core of the computations of the program will remain the same, though the code representation of it may change slightly. Finally, the new code will be written using strict coding guidelines such as the black box philosophy.
2. High Level Design Specification
Figure 2.1 - Structural Model Diagram
Figure 2.2 – Control Model Diagram
2.A Main
This is the centralized manager of the program. It brings everything together through a call-return system. Thus all of the subprograms are run in sequence until the final output has been delivered to the user. Furthermore, it maintains the necessary data structures and passes the pertinent data along to each sub-process.
2.B User Interface
The user indicates which input file type is going to be used, then selects that file in a file chooser window. Also, the user specifies some pertinent information about that file.
2.C Input File Reader
This reads in the item parameters from the specified input file. There are three types of files which can be read: columns, bilog, and multilog.
2.D Recursive Algorithm
This takes the item parameters, genereates tracelines from them, and then calculates everything needed for the summed score to scale score conversion.
2.E Output
This takes the data calculated by the recursive algorithm and outputs it to the screen. It also allows the user to save the data to a file and “copy” it so that it may be “pasted” in another application.
3. Detail Design Specification
3A. Main
All four other aspects of the program are centered about the Main section. The main program will integrate all four other aspects: the User Interface, Input File Reader, the Recursive Algorithm, and the Output of the program. All of the processing that goes on is centered throughout the main section, including passing between the various data structures the Input File data, the Trace Lines and the Scaled Scores. There will be one main java program that implements the rest as objects and passes values between all four main procedures. The User Interface gathers all necessary user information, the Input File Reader determines which file type is in use, the data is read and then processed in the Recursive Algorithm, and then all data is sent to the Output file.
3B. User Interface
The User Interface is a fairly simple GUI that simply checks all the various user input and determines whether the information can be used to complete the data processing and produce a valid output file. The User Interface is a collection of items that will invoke the Input File Reader and Output upon completion.
Figure 3.1 – Lower Level Structural Diagram (User Interface)
3C. Input File Reader
In the GUI, the user types the name of a file that contains the input parameters. Also, the user will press a radio button which declares the format of the file. For each format, the reader will acquire the three input parameters using the Java StringTokenizer class, and store them as a, b and c. In the columns and the bilog file format, there is a line representing each test question. Each line of the file will be tokenized to the appropriate position, and then the parameters will be read in. In multilog format, there are two types of questions that can be represented. The first is identical to the line system in bilog, and will be handled in the same way. The second allows for partial credit for wrong answers, and can possibly have a great many more items to be read in as parameters. These extra parameters are handled in the same way, but will be stored as b1, b2, b3… The parameters for each input format are stored in the Test class which is vector of arrays.
Figure 3.2 - Lower Level Structural Diagram (Input File Reader)
*FileFormat = 0*FileFormat = 1*FileFormat = 2+
**Metric = false **Metric = true
StringTokenizerString Tokenizer
String Tokenizer
*FileFormat is an int variable in the main class that reads in its value from the GUI
**Metric is a boolean variable in the main class that reads in its value from the GUI
3D. Recursive Algorithm
Once the file input reader finishes, the input data will be passed to the recursive algorithm. Here, the input for each format will be used to calculate array representations of graphs, called tracelines, for each item in the test. Then, in a series of for loops, each item is successively multiplied against the standard normal curve once for a right and once for a wrong answer. At the end of the outer loop, a double array equal in size to the number of items on the test will contain the likelihood of someone getting a particular score given that the got a particular number of answers correct.
Figure 3.3 – Lower Level Structural Diagram (Recursive Algorithm)
Initialize double arrays
Tracelines
Exit Condition 1
Exit Condition 2
Exit Condition 3
EAPs
Exit Condition 1 = Exit LOOP 1 after it has gone through all possible scores (maxscore)
Exit Condition 2 = Exit LOOP 2 after it has gone through all possible scores up to the score equal to the
Index of LOOP 1
Exit Condition 3 = Exit LOOP 3 after is has gone through all of the categories for the question number
equal to the index of LOOP 1
3E. Output
Once the double array described above is completed, one line is output for each possible score on the test. Each line contains the score, the EAP calculated in the recursive algorithm, the standard deviation of the EAP, and any other information the user requested in the GUI.
Figure 3.4 – Data Flow Diagram
Input Parameters read
from said file
Test class made to graphs
Represented in arrays
Tracelines combined with
Normal Curve to get EAPs
GUI options performed
Like percentiles, SS…
4. Requirements Traceability
See attached Excel Spreadsheet.
5. Schedule
5.1 Development Milestones
Milestone
/Date
/Deliverables
/Member(s)
ResponsiblePreliminary report after meeting with client. / 1/25 / Document & Website / ALL
Team Website set up / 1/25 / LIB.
Contract I done / 2/6 / Document & Website / ALL
Contract II done and signed by client / 2/13 / Document &
Website / ALL
Design specification completed / 2/20 / Document & Website / ALL
User Manual I completed / 2/27 / Document & Website / ALL
GUI Framework working (Tested by ALL team members) / 3/7 / Prod. & Admin.
Recursive Algorithm Complete (Verified by QA member using client’s input files) / 3/4 / QA
Prepare for In-Class presentation. / 3/5 / Dir.
In-class Presentation / 3/6 / Presentation / ALL
Prototype Complete
(Prototype includes a working version using the Column file in the GUI framework.) / 3/6 / Prototype / ALL
Start Testing & Debugging / 3/26 / (Mainly QA)
Bi-Log Working (Dir. & QA verify) / 3/9 / DIR. & QA.
Output Format Working (ALL) / 3/29 / ALL
Multi-Log Working (Dir. & QA verify / 3/29 / DIR. & QA.
Finish coding. Start testing and Debugging. (Dir. assures that development is complete.) / 3/30 / QA & Dir.
Client testing complete / 4/18 / Client.
Final Checking (Team agrees that project is complete and all issues are resolved.) / 4/23 / ALL
Final Presentation / 4/24 / Presentation / ALL
5.2 Gantt Chart
Oh where oh where is my hairbrush?? I mean where’s my Gantt chart?
5.3 Risk Analysis and Management
5.3.1. Identified Risks
A)Difficulty in understanding certain advanced mathematical concepts used in the code provided by Dr. Thissen.
B)Difficulty in understanding parts of the provided code due to shortcuts around more obvious mathematical concepts.
C)Difficulty in modularizing the code provided by Dr. Thissen due to the lack of standard programming guidelines.
D)Different programming styles and ideas may cause individuals in the group to have incompatible code and difficulty in deciphering code for purposes of debugging.
E)Underestimation of the project leading to delays.
F)MultiLog and Bilog being difficult to implement. Though it does not seem hard, BiLog was not implemented due to some unknown errors. The error may cause problems for our team as well.
G)Port and Modularization. Due to the complexity of the mathematics, and the nonstandard previous program, difficulty in porting and modularizing may cause problems. That is we might not know how best to organize the data.
H)Trying to create multiple windows from button clicks.
5.3.2. Plans
A)Meet with Dr. Thissen so that he can give the team a more general understanding of the more advanced mathematics. Hopefully among five people and already pre-existing code, the team should be able to understand enough to implement the calculation functions.
B)Meet with Dr. Thissen for explanation of shortcuts taken and the reasoning behind them.
C)Attempt to rewrite as much of the code as possible. In doing so the team will hopefully be able to implement the code under the black box philosophy. Rewriting the code will require the team fully understand the goals of the program because the team can no longer perform the simpler task of language conversion.
D)Specific classes must be divide between team members in order to finish the project in the time given. However the structure of each class must be have rigid specifications agreed upon by all members so that code written by someone else is still useful to all members even if they do not understand the implementation of the class.
E)Having pre-existent code and only one real program may lead to the false notion that the task at hand is simple and capable of being finished at the last minute. Create a schedule involving of all known tasks that need to be accomplished. Keep to the schedule as best as possible and allow a large amount of time for debugging and testing so that certain parts of the program that may prove faulty can be corrected in time for the due date. Also list the tasks in matter of importance and have backup plans of features that can be left out and still obtain a finished product.
F)Attempt to complete the two formats. However, the finished product can function without these two formats and therefore if after the time allotted of 14 days total, the plan would be to skip this part until the end to see if extra time is available to go back and finish them.
G)If this occurs, though we might not be able to modularize all the code and make it very easy to understand, we can at the very least follow the organization provided by Dr. Thissen and get a working program. If possible, we may meet with him again to further explain the details of the code that is unclear to us so that we may be able to find a better way to organize the data.
H)Currently we would like to be able to use different GUI windows after one process the data so that the user can better see the results of the end data. However if we find it difficult to provide separate windows due to some difficulty or another, we will implement it under one window with the data exported stored in some text box with scrolling windows. Our current GUI model already supports using one window so not being able to create different windows would not be a big problem.
In general, if a specific task is not necessary for a finished product, we would choose to avoid the problem until we have something working that we can turn in. We must be careful to not let the deadlines for things in the critical path slip, and will raise discussion in each weekly meeting the progress of the more important aspect of our task. If something is not up to speed and in a critical path, all current members of the group not working on anything major will be reassigned to help finish the delayed task.