COMP 145: Design Specification
Oral Text Learning Production Interface Project
for Mr. Dick Schmitz
February 20th, 2001
Group 10 Software Engineering TeamTeam Member / Title / Approval Signature
Karen Parker / Producer /
Brianne Roth / Administrator /
Sean Rielly / Director /
Jason Howell / Librarian /
Sam Adu / Quality Assurance/Tester /
Preface: This is the Design Specification document for Group 10 (Oral Text Learning) of Comp 145. This document is intended for internal purposes and should help us as we begin to design this piece of software. This document will lie out the design of the project, and provide something our group can follow during the implementation process. It should also help us to design each part so they will be easy to combine.
1. Introduction: In this project we are redesigning an existing process, not an existing program. In order for the Oral Text Learning pages to be created, users must get certain information to editors so that they can create the web pages (i.e. the lyrics or the song itself). Currently there is no convention to this process, which makes it somewhat difficult. Users submit their materials in many different forms, often in an inconvenient manner. In this project, we are trying to ease this process by providing a very easy to understand, conventional medium for users to submit their materials to the editors. There have been no prototypes created for this so far, we are in fact creating this program to ease things for the editors. This medium does have some design constraints. These users are assumed to have limited computer knowledge. That means for this program to be successful, two things must be remembered:
1)The interface must be drop-dead easy. If what we create is too difficult for the average user to understand, they will not use it.
2)The program must work. If people lose faith in this (which is very easy to do if the program crashes) they will not use it. If this software is not used, then we have not succeeded on easing the existing process.
2. High-Level Design Specification:
Diagram 2.1: Structural Model:
Diagram 2.1 shows an overall static architecture of all the pieces. This breaks down the system into several subsystems, which are semi-independent of each other. The program needs to gather several pieces of information from the user and submit it in a conventional manner to the editors. Each subsystem is responsible for gathering a different piece of information, and saving it with a specific given name, to a specific file so the editors can easily make the web pages.
2.1.1 Introduction screen - this section only directs the user to where he/she wants to go (administrative, create new lesson, or modify existing lesson). This is the one section of the program that does not manage data, simply sends the user on the correct track.
2.1.2 Administrative screen - this subsystem manages some important data that the rest of the program depends on. There are several things that when changed will effect the rest of the program (for example path name of where the files are stored or e-mail address of the webmaster). This system interacts with the other subsystems by managing some important pieces of information that the program depends on. These pieces of data will be stored internally, and this screen will be password protected.
2.1.3 Information gathering - This screen gathers information from the user to be passed on to the webmaster (and eventually to the editors). While the user is allowed to modify (from the time he/she starts to the time he/she clicks finished) this information will have to be stored in an accessible place, so that it can be accessed and modified. Upon completion of the program (clicking “finished”) this information will be part of the email sent to the webmaster informing him that a new lesson is ready to be created. One important piece of information that the rest of the program will use is the Language the lesson is in. This will determine the file all of this information is stored in. It will also need to get a unique lesson name that will be used in the naming convention for the rest of the program.
2.1.4 Graphic gathering - This subsystem needs to obtain a graphic from the user if one is available. If a graphic is ready to be submitted the subsystem needs to get it from the user, and save it in the designated file with the name lessonname_graphic.filetype. This subsystem will also allow the user to submit a URL of a graphic if they don’t have one immediately available. This piece of information will be sent to the webmaster in the email when the user clicks finished. The URL will have to be stored with the user information until that event happens (the user will also be able to write a text description of the picture, see Special Instructions - 2.1.8). This subsystem can be bypassed if the user doesn’t want to submit a graphic or a URL.
2.1.5 Lyric gathering - This subsystem needs to obtain the lyrics from the user. It will open an already created file and allow the user to type in the lyrics. This subsystem will be required to save the file name in the correct directory with the correct name. This subsystem can be bypassed if the user doesn’t want to submit lyrics.
2.1.6 Song gathering - This subsystem will need to obtain the song, and store it in WAV format in the correct directory. The song can either come from a CD (in which case, the subsystem will have to do digital audio extraction), or from the users disk/hard drive (if the file is already in WAV format). This subsystem can be bypassed if the user doesn’t want to submit a song.
2.1.7 File gathering - This subsystem will need to obtain any files the user wants to attach to the lesson (for example a lesson plan). It will have to transfer the files to the correct directory, and make note of the file in the email sent to the web master. This subsystem can be bypassed if the user doesn’t want to submit a file.
2.1.8 Special Instructions - Throughout the program the user can enter special instructions as text that they want submitted to the webmaster/editor. There will be a button on every screen that the user can push, that will let them enter this subsystem. At the end, all the special instructions that are entered in will be concatenated and emailed to the webmaster.
2.1.9 Finished - Clicking on the finished button will have functionality. It will concatenate all the necessary information from above and email it to the webmaster. This is also the point of no return, when the user finishes, he/she can no longer come back and modify. This will relay some important information, and let the webmaster know that there is a lesson ready to be created.
2.1.10 Modify - The modify subsystem will allow the user to go to a certain subsystem by clicking on a button. Each button will have functionality, but this subsystem doesn’t manage any data.
Diagram 2.2: Control Model:
From the control model, we can see how this is an event driven program. Subsystems respond to events, usually the user clicking on a button to bring him/her to the next subsystem. This program is somewhat sequential, but the user has the freedom of backing up, or using the modify screen to hop to any section of the program. The event handlers take the user to the requested screen, and also have to register somehow that the user has completed that subsystem. Event handler I will take the user to the administrative side if necessary, or to the basic program (either to the info screen, or the modify screen). The second event handler handles the changes made in the Administrative screen. The third event handler handles the events of the bulk of the program.
3. Detailed Design Specification
3.1 Object Model Diagram
3.2 Low Level Data Flow
Note that each variable and subroutine is preceded by an icon and followed by a bracketed cross-listing reference from section [3.1] above.
5.1.1.1 / 5.1.1.2 / 5.1.1.3 / 5.1.1.3.1 / 5.1.1.4 / 5.1.1.5 / 5.1.1.5.1 / 5.1.1.5.2 / 5.1.1.6 / 5.1.1.6.1 / 5.1.1.6.2 / 5.1.1.6.3 / 5.1.1.7 / 5.1.1.7.1 / 5.1.1.8 / 5.1.1.9 / 5.1.1.9.1 / 5.1.1.9.2 / 5.1.1.10 / 5.1.1.10.1 / 5.1.1.11 / 5.1.1.12 / 5.1.1.13
3.1 Object Model Diagram / A.D.1 / X / X / X / X / X / X
A.D.2 / X / X
A.D.3 / X / X / X / X / X / X
A.D.4 / X / X / X / X / X / X
A.D.5 / X / X / X / X / X / X
A.D.6 / X / X
A.D.7 / X / X / X / X / X
A.D.8 / X
A.D.9 / X
A.D.10 / X / X
B.D.1 / X / X / X / X / X / X / X / X / X / X / X
B.D.2 / X / X / X / X
B.D.3 / X / X
B.D.4 / X
B.D.5 / X / X
B.D.6 / X / X / X / X / X / X / X / X / X / X / X / X / X / X / X / X / X / X / X / X / X
B.D.7 / X / X / X / X / X / X / X / X
C.D.1 / X / X / X / X / X
C.D.2 / X / X / X / X / X / X / X / X / X
C.D.3 / X / X / X / X / X / X
C.D.4 / X / X / X / X
C.D.5 / X / X / X / X
D.D.1 / X / X / X / X / X / X
D.D.2 / X / X / X / X / X / X / X / X / X
D.D.3 / X / X / X / X / X / X / X
E.D.1 / X / X / X / X / X / X / X / X / X
E.D.2 / X / X / X / X / X / X / X / X / X
E.D.3 / X / X / X / X / X / X / X / X / X / X / X / X
E.D.4 / X / X / X / X / X / X / X
E.D.5 / X / X / X
E.D.6 / X / X / X
E.D.7 / X / X / X
E.D.8 / X / X / X
E.D.9 / X / X / X
4. Requirements Traceability Correspondence
5. Schedule
5.1 Development Milestones
5.1.1Introduction and Naming Phase Show and Tell
Karen and Brianne to report to team regarding progress by showing work in progress. Team will evaluate the work in progress and make suggestions regarding further work.
5.1.2Graphics Phase Show and Tell
Jason and Sam to report to team regarding progress by showing work in progress. Team will evaluate the work in progress and make suggestions regarding further work.
5.1.3Lyrics Phase Show and Tell
Jason and Sean to report to team regarding progress by showing work in progress. Team will evaluate the work in progress and make suggestions regarding further work.
5.1.4Inspection I passed
The introduction and Naming Phase, Graphics Phase, and Lyrics Phase show and tells passed and the team can now move on to the later phases: Modify Feature Phase, Audio Extraction Phase, Communication Phase, and Additional Features Phase.
5.1.5Modify Feature Phase Show and Tell
Karen and Brianne to report to team regarding progress by showing work in progress. Team will evaluate the work in progress and make suggestions regarding further work.
5.1.6Audio Extraction Phase Show and Tell
Jason and Sean to report to team regarding progress by showing work in progress. Team will evaluate the work in progress and make suggestions regarding further work.
5.1.7Communication Phase Show and Tell
Karen and Sam to report to team regarding progress by showing work in progress. Team will evaluate the work in progress and make suggestions regarding further work.
5.1.8Additional Features Phase Show and Tell
Sean and Brianne to report to team regarding progress by showing work in progress. Team will evaluate the work in progress and make suggestions regarding further work.
5.1.9Beta Version Deployed
A working version of the application submitted to Dick and some of his colleagues for evaluation and testing.
5.1.10Beta Report from Dick Schimitz
Report given from Dick regarding his evaluation and testing of our beta version of the application.
5.1.11Final Product Available
The final product is available and ready for submission. All files have been gathered into a deliverable format and all documents are final.
5.2Gannt Chart and Pert Chart
5.2.1Gannt Chart – See Appendix 6.1
5.2.2Pert Chart – See Appendix 6.2
5.3 Risk Management
5.3.1 Identified Schedule Risks
5.3.1.1Education/Learning of Visual Basic - The group needs to learn the language in a short amount of time. The risk is that we might not have enough time to become proficient in it.
5.3.1.2Admin Screen - Since we are not sure exactly what will be included in this section (features will be added as we code), it is difficult to know exactly how much time this section will take.
5.3.1.3Resume/Modify Screen - The resume and modify features may be troublesome since certain folders will have different read and write access. We must make sure certain files do not get overwritten.
5.3.1.4Naming Convention - We must make sure the naming convention is kept and that files are only allowed unique names.
5.3.1.5Word Interface - This could be problematic since our program will have to interact with another program which we have no programming control over. We will be required to open up MS Word with a editable template.
5.3.1.6Audio Extraction - Sean is working on an audio extractor. If this is not done in time we will have to come up with another way to extract the song from a CD. Also, in order to write the extraction program, Sean needs a library that we must obtain.
5.3.1.7Email Scripting - We will have to send an email to the webmaster telling them that a new lesson is ready for creation/posting. The group (especially Karen and Sam) will have to learn email scripting. We may not have enough time for this.
5.3.2Plans of Action/Prevention
5.3.2.1Books have been obtained from Microsoft to learn VB and all group members have been assigned the task of learning the language by 2/20/01.
5.3.2.2Since the Admin screen is still not clearly defined, we will include everything we can think of that we are able to program in the set time we have.
5.3.2.3The resume/modify feature has been assigned to Karen and Brianne. They will be working on this from 3/8/01 to 3/28/01. Extensive testing will be completed on this section.
5.3.2.4Naming convention will be kept through template names and our program will check for duplicate names during the naming phase (assigned to Karen and Brianne).
5.3.2.5This section has been assigned to Sean and Jason. It will be tested extensively. Our program should open Word with a template saved with the correct naming convention.
5.3.2.6The group is trying to get the funding for buying the library Sean needs. If his program can not be working by 3/8/01 we will have our program call a freeware version of an audio extractor.
5.3.2.7Karen and Sam have been assigned to this section. They (along with the rest of the group members) will be required to learn email scripting so we can send a formatted email with an attachment.
6Appendix
6.1 Gannt Chart
6.2 Pert Chart
Page 1 of 14 / February 20th, 2001