COMP 145 UNC-Chapel HillContract I-B

Psychometric Analysis Software

Submitted to

Dr. David ThissenAnd Prof. Greg Welch

2/11/01

________________ Benjamin Chen________________ Eric Karlsson________________ Chris Schenck________________ Charles Skender________________ Ian Yuan

PrefaceThis document is the first draft of a contract that will be presented to Dr. David

Thissen by our development team. It is designed so that the specifications and requirements of this project may be clarified and made concrete. Dr. Thissen will have one week to review this contract with our team, and after that a final, revised version will be drawn up. That final version will be signed by Dr. Thissen and our team members, and then turned in to Professor Welch.

1. IntroductionOur client is Dr. David Thissen, who is a professor in the UNC Department of

Psychology. We are attempting to design a quite user-friendly version of a program that performs summed-score calculations. What these calculations do is provide a way for test scores to be reported on a consistent scale, even though different versions of the test were given. Dr. Thissen and his colleagues have been working on this project for some time, with limited success. We aim to create a product which performs these calculations with minimum user knowledge or experience. We also aim to make the final product multi-platform and modular, so that parts of it can be used in other similar projects in the future.

2. User-Level Requirement Specification

Figure 2.1 - A Context Diagram for the Psychometric Analysis Program

Figure 2.2 - A Process Model Diagram For User Requirements

2-A. User Interface (Context Model)Below is our current GUI design implemented in part by suggestions by the Client Dr. Thissen, but will be modified according to future needs.

Figure 2.3 – GUI

Load Program Choose Optionslike Multilog/Bilog

Select Files to Read From Save Output File

Exit Program

Process the Data

A. Indicates if you would like Scaled Scores to be displayed in the output.B. Allows you to fill out the desired values of and for population distribution.C. The scaling allows one to decide the range of possible scores. For example, to give

points for the SAT or the GRE, on would put the numbers 200 and 800.D. The File Format allows the user to read in 3 different types of file structures and the

Column determines which columns in the file are relevant to the data analysis. E. Button for users to press when they wish to end the program.F. Allows user to choose which columns represent the corresponding data of a, b, and c

which are Item Parameters.G. The Select Item Parameter button will bring up a selection screen so that the user can

choose which file he would like to read in. H. Textbox included so that the user can see which file he has chosen. I. Allows for choosing between the normal metric data calculation and the Logistic

metric calculation.J. Allows the user if he would like to have the column of percentile on the output. An

percentile that is not very accurate but rather an approximation.K. The re-scale portion allows for the user to determine what he desires the

average/standard deviation to be and then to evaluate the data from the files accordingly.

L. Allows the user to choose to save the output as which type of file.M. Processes the input file to produce the output file.N. Preview allows one to check what the input looks like given the columns

specification so that one check the input file before processing.

2-B. Input File (Context Model)Using the column selection in the GUI interface, we are allowed to specify which columns are required in the calculation. The input files have 3 different formats: columns, bilog, multilog. These files are generated by other programs and the user must specify which type of file that he would like to read as can be seen on the GUI. Currently column files will certainly be supported. The other two file formats are not necessary in order to create a prototype and currently no one has ever implemented the bilog.

2-C. File Processing (Context Model)This portion of the code does the calculations necessary and is provided for by Dr. Thissen. Our goal here is to take the existing Pascal code and rewrite it using Java. We also plan to modularize the code to conform to standard programming form, including the implementation of the black box philosophy. This includes functions that do graph multiplication and file parsing for desired data.

2-D. Output (Context Model)The output of the file should end up looking something similar to the following:

Part 1Item Type Ncat Parameters:1 2 2 0.76 1.04 0.302 2 2 0.49 -0.37 0.263 2 2 0.75 1.76 0.16

Part 2Score EAP S.D. Prop. Sscore SE %ile0 -2.34 0.54 0.00000 27 5 11 -2.31 0.54 0.00000 27 5 12 -2.28 0.55 0.00000 27 5 13 -2.25 0.55 0.00000 28 5 1

We want to be able to store the output as a saved file able to be read in a word processor and manipulated.

Part 1 is what is read in as an input file but is outputted here again so that it can be checked. This is not a direct reprint of the input, but a refined input in which the different types of input files are standardized. Ncat represents the number of categories. For most cases, this value is 2, either right or wrong.

Part 2 is the result of the processed data.First column - Represents the summed score, which ranges from the minimum to the maximum score.Second column – EAP stands for expected a posteriori and represents the score without that has yet to be scaled.Third column – S.D. is for standard deviation and is calculated based on the data provided.Fourth column – Prop. is the expected proportion for each summed score. Fifth column – Scaled scores. For example, this would be from 200 – 800 on the GRE/SAT.Sixth column – SE stands for standard error of the scaled scores.Seventh column – Only appears if the percentiles are requested on the GUI. They are the not-very-accurate percentiles.

2-A. (Process Model Diagram)User must load the program to begin.

2-B. (Process Model Diagram)Certain options need to be chosen. These options include ability to display Scale Scores and Percetiles, log format, normal or logical 3PL, and file format.

2-C. (Process Model Diagram)Select which file the user wishes to read. After selecting the button, another window will appear with the standard window selection items.

2-D. (Process Model Diagram)The user must click process before calculations are done. Each of the fields will have initial values in case the user does not specify certain parameters.

2-E. (Process Model Diagram)User can choose to save the created output onto a file for printing and manipulation, or cancel if the data is not the desired results.

2-F. (Process Model Diagram)The user must close the program when he is finished with it.

3 System Level Requirement Specifications

3.1 Functional Requirements

Figure3.1- System-Level Context Diagram

A. Graphical User Interface (GUI)

A.1 User Input A.2 Output

A.1.1 User Input from GUI

A.1.2 Input from data files

A.2.1 Column Generated Output

B. Data Processor

B.1 Input as Test Class

B.2 Newly Calculated Data as Output

C. Data Files

A.2.2 Output Functionality

C.1 Format of Input Files

C.2 Format of Output Files

Figure 3.2 - Data Flow Diagram

File Format Incorrect

LOAD

END

Figure 3.3 - State Machine Diagram

Bring upGUI

Begin Program when PROCESSButton is clicked

File format checked for validity

Read Input &Store input in

Test class

Test class constructs numerical representation of a graph specified by input parameters

Recursive algorithmCalculates summed

scores using the trace lines and GUI

input

Scaled/Summed scores output to

specified file

Option to run program a second time

Awaiting GUI input

3.1 Functional Requirements

3.1-A. Graphical User InterfaceThe user interface will be a GUI box implemented using Visual J++. It will contain check boxes, radio buttons and text fields in order to obtain the various input in order to perform the calculations and interpret the data files as needed.

3.1-A.1 User InputThe primary user input will come from two separate locations that will work in conjunction: user input from the GUI and input from selected data files in one of three formats: Columns, BiLog, and MultiLog

3.1-A.1.1 User Input From GUIThe GUI will be developed to include the following functionality and user options when inputting the various data.

a. A check box for scaled scores, which will then input the following data:b. Population distribution

1. Mu2. S.D.

c. Scaled distribution around:1. 0.0 2. Entered #

d. Three radio buttons to set the type of input file as either

File Input

Processing Data

Output Data

1. Column2. BiLog3. MultiLog

e. Three text fields to input the relative location of the columns in the designated input file:1. Column for A data2. Column for B data3. Column for C data

f. A checkbox for whether or not integers are to be rescaled, with corresponding text fields for the following:1. Integers with …2. Standard deviation

g. A check box to determine whether or not a column containing percentiles should be part of the data

h. A check box and two corresponding radio buttons for determining 3PL use1. A radio button for Logistic Metric2. A radio button for Normal Metric

i. A text field for the name of the data filej. An input button for completion of the user input

3.1-A.1.2 User Input from Data FilesThe user will be prompted to select a file with corresponding input type (Column, BiLog, MultiLog). This is a fairly straightforward procedure, with the data being read in from the file (as long as file is correct type) and sent forward to the processing procedure. This should be user friendly, with messages that inform the user whether or not they are using a supported data file/format.

3.1-A.2 OutputThere are two central components to the resultant output from the data entered through the use of the GUI: the data must be output in the standard column format already introduced to us by Dr. Thissen, and the output must contain a certain level of user functionality as described below.

3.1-A.2.1 Column Generated OutputThe output will be in the same column format as Dr. Thissen currently employs in his version of PlotLog. The format is relatively straightforward, with required columns () as well as optional columns () that are included depending on the user interaction with the GUI. Output should always be in the same format and in standard font type and size.

3.1-A.2.2 Output FunctionalityThe Output must also contain a fair amount of simple user functionality. The outputted columns must be output to a file similar to a text editor, with the most important functions the ability to copy and pasted selected items and columns

from the outputted data to another text/data file. Also, the ability to print a hard copy of the data would be an excellent feature to include, but is something that must be considered with respect to time constraint and is not a necessary component of the requested output functionality.

3.1-B. Data ProcessorThe GUI input coupled with the vector will be used to compute the summed score and scale score conversion information. This will require two main components. The first is to take the data files, convert them into the necessary (Vector) objects, and calculate the data. The second includes sending the newly calculated data to a properly formatted output file.

3.1-B.1 Input as Test ClassThis considers how the data will be read into the created (Vector) object from the data files. The idea is to consider each object containing separate Vectors for each of the three columns to input data from and make use of these three sets of data in the calculations for the resultant output.

3.1-B.2 Newly Calculated Data as OutputThe processed data will be output in the column format that is already in place from previous versions of PlotLog. Will use input from the GUI to determine the number of extra data fields and columns.

3.1-C Data FilesThis concerns the creation/use of data files.

3.1-C.1 Format of Input FilesThere are three types of input files as discussed above: Column, BiLog, and MultiLog. The input files must adhere to one of these three formats, or it will not be read in properly and the data will not be able to be calculated.

3.1-C.2 Format of Output FilesThe generated output files will all adhere to the same standard and will closely resemble the Column format used in the input files. Will include extra columns specified by GUI.

3.2 Non-functional Requirements

3.2-A. Product RequirementsThe following are hard requirements that must be realized in order to have a successful project that adheres to the project guidelines.

3.2-A.1 Computational and Processing Time

The software much be sufficiently efficient in the processing of the data. Calculation and computation must be kept to a minimum where possible, as the idea is to make a quick interface that is not hampered by slow processing.

3.2-A.2 Cross Platform/Machine PortabilityThis is not as important as keeping computational and processing time to a minimum, but should be carefully considered. The idea will be to make the GUI size sufficient so that it is aesthetically pleasing on monitors ranging in size from a 13” laptop to a 21” desktop. Cross Platform capability (i.e. between Windows and Macintosh operating systems) is desired, but given time constraints, is not a necessity. Should be fully capable of efficiently running on any machine with a processing speed of over 133 mHz.

3.2-B. Project OrganizationThe project must be organized according to standards set forth in class. This pertains to the content and appearance of all deliverable documents as well as the contents and layout of the team web-page.

3.3 Domain RequirementsThe project should function on any computer using a Windows operating system and containing a Java Virtual Machine (JVM). If time permits, we would like to successfully implement the software on the MAC OS. This second aspect should not be difficult thanks to the portability of Java. However, layout, file, and the corresponding menu will have to be changed in order to correctly work on a Macintosh. Also, Microsoft runs a JVM that is slightly altered from the standard version. Whether or not this will pose a problem is not yet known, but this fact should be taken into consideration when determining if a complete implementation on both platforms will be an achievable goal.

3.4 GoalsThe most important part of this project is to create a user friendly GUI that can be used with a minimum amount of time spent learning how to use it from any user. It is crucial that the software be as hassle free as possible. Two important assumptions are made about all users: they have some familiarity with the data formats that are being supported (Columns, BiLog, and MultiLog) and that the machine they are using contains a JVM.

The target completion date is the middle of April 2001 so that there is sufficient time to test and elicit a small degree of feedback, possibly implement small interface changes to the completed project. Once completed, the software should be modular enough that it can be easily altered/updated in accordance with whatever changes are deemed necessary by those using the software.

4. Hardware and Software Resource Requirements For development of our software project, we will require the following resources to increase our productivity and efficiency in completing the project. The most important of these documents is Visual J++, which will greatly decrease the developmental period of the GUI as well as allow any changes to be implemented with little project overhead.

4.1 Microsoft ProjectMicrosoft Project will be used to help efficiently organize and coordinate our project objectives and schedule. Because of the built in tools offered in Microsoft Project, we will be able to carefully track our project as well as always be aware of impending deadlines and target completion dates for the software. This item has already been obtained and integrated into use by the team, allowing us to easily do the included Gantt chart.

4.2 Visual J++Visual J++ is and important tool for easily completing the task of creating the GUI. Visual J++ offers a number of tools that assist in developing the GUI from scratch (the layout manager is excellent in being able to change the look and functionality of the GUI as needed). All of the members of the team have copies of the software or have access to it on the computer labs on campus (Sitterson, Davis, Venable all have copies of it).

4.3 UNIX SystemFor all other Java programming needs, we will develop on the Unix platform, and this code will be implemented with the GUI developed in Visual J++. Unix is readily available and well known be all team members. Using the UNIX system we will be able to work on any computer on campus and have access to the necessary files to implement the project.

5. Preliminary Schedule (Task Budgeting) 5.1 Development Items5.1.1 Major Phases:1) Design & Planning Phase

Includes meeting with client and understanding the requirements. Team meeting for defining our approach to the project. Deciding on the language and application to use. Contract I: Result of initial assessment of project and our understanding of the

client’s requirements. Contract II: Complete after validating contract I with client and updating

additional changes.

2) Implementation & Testing Phase GUI framework. Columns, BiLog, and MultiLog. Implementing the Recursive algorithm. Prototype available / Midterm presentation to follow. Port and Modularize client’s original code. Output Formatting. Create User Manual Create Implementation Manual

3) Validation & Verification Phase Testing of implementation and fix possible bugs. Meet with client to obtain test files for testing purposes. Let client try using the application and ask for feedback. More fixing after receiving feedback from client. Validate with client user manual and make possible changes.

4) Completion & Delivery Packaging and final presentation. WWW site complete Team report and individual reports.

5.1.2 Tasks & Dependencies:Please see PERT Chart diagram Figure 5.1:

5.1.3 Major Milestones.

Milestone Date Deliverables

Preliminary report after meeting with client. 1/25 Document & Website

Team Website set up 1/25

Contract I done 2/6 Document & Website

Contract II done and signed by client 2/13 Document &Website

Design specification completed 2/20 Document & Website

User Manual I completed 2/27 Document & Website

GUI Framework working 3/7

In-class Presentation 3/6 Presentation

Prototype Complete 3/6 Prototype

Finish coding. Start testing and Debugging 3/28

Client testing complete 4/18

Final Presentation 4/24 Presentation

5.2 Schedule Diagrams:

5.2.1 PERT Chart: Diagram 5.1

The Numbers in the Pert Diagram correspond to the numbers in the chart above

5.2.2 Critical Path:1-> 2 -> 8 -> 11-> 13-> 15->17->18

5.2.3 Gantt chart: Diagram 5.B

Task IDs on the chart can be referenced from the PERT chart in Diagram 5.A.

5.3 Risk Analysis and Management5.3.1. Identified RisksA) 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 to 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.

5.3.2. PlansA) 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.