€¦ · Web viewMicrosoft Word, due to the widespread popularity and ease of use, will likely be...

COMP 145 Client Contract IIOral Text Learning Production Interface Project

for Mr. Dick SchmitzFebruary 13th, 2001

Name Title Approval Signature

Dick Schmitz Client

Group 10 Software Engineering TeamTeam Member Title Approval SignatureKaren Parker Producer

Brianne Roth Administrator

Sean Rielly Director

Jason Howell Librarian

Sam Adu Quality Assurance/Tester

of 26 February 13th, 2001

COMP 145: Group 10: Client Contract II Oral Text Learning Production Interface Project for Mr. Dick Schmitz

Table of Contents:Section Description Page

1 Preface 31.1 Document Change History 3

2 Introduction 42.1 The Client 42.2 Oral Text Learning Description 42.3 Current Production 42.4 Production Problems and Project Goal 4

3 Glossary (alphabetical order) 5-74 User Requirements Specifications 7-9

4.1 (A) User Interface 74.2 (B) Microsoft Word Interface 84.3 (C) Audio Extraction 84.4 (D) Network File Transfer 8Figure 4 Summarized Context Model Diagram 9

5 System Requirements Specification 9-155.1 Functional Requirements 95.1.1 Overall Model Diagram 105.1.1.* Detailed Screens from Diagram 11-145.2 Non-Functional Requirements 14-155.3 Domain Requirements 155.4 Goals 15

6 Hardware and Software Resource Requirements 15-166.1 Hardware 156.2 Software 156.3 Plans to procure 15-166.4 Estimated Schedule of Procurement/Delivery 166.5 Alternatives (risk management) 16

7 Verification and Validation 16-177.1 Strategy 167.2 Test Cases 17

8 Developmental Schedule 17-208.1 Development items 178.1.1 Major Phases 17-188.1.2 Tasks and Dependencies 18-198.1.3 Major milestones 208.1.4 Deliverables 208.1.5 Diagrams (see 9.1 and 9.2) 20 (see 21-26)8.1.6 Risk Analysis and Management 20

9 Appendices 21-26+9.1 Pert Chart Pages 1-4 22-259.2 Gant Chart Page 1 269.3 Technical Notes Issue 1.1 Attached



1 PrefaceThis is the second version of the Contract for the Oral Text Learning Production Interface. The first version of the contract was delivered to the Client on February 6th, 2001. The Client had one week to review this document with the Engineering Team, to point out changes, mistakes, or points of contention that need to be addressed. Then, the team delivered this version (entitled Contract II) on February 12th, 2001, which includes an additional section about Contract Changes made since Contract I [section 1.1], and a new Verification and Validation section [section 7].

1.1 Document Change History2.4 Changes made including background about file transferring and Internet connection.3.15 VPN definition updated.4 Added alphabetical labeling system (A-D).4.1.2 The term “professor” was changed to “user” for consistency.4.4.2 Changed server folder names and clarified.4.4 (D) Clarify need for network transfer. 5 The term “teacher” changed to “user” for consistency.5.1 Added special instruction functionality – for each major step in the process.5.1.1 Made changes to Overall Model Diagram to match A-D labeling and to correct

sequential processes.5.1.1.5 Lesson name does not have to be in all lowercase. Clarified usage of folder names.5.1.1.6.1 Added preview graphic functionality.5.1.1.6.2 Added text area for notes about web page URL graphic.5.1.1.9 Skip a song choice added.5.1.1.9.1 Added ability to preview saved song.5.1.1.9.2 Added ability to preview saved song.5.1.1.11 Changed to preview, modify, and/or add all special instructions5.2.1.1 Efficiency section removed.5.2.3.1 ONYEN login changed to Departmental Login.5.3 Should operate in Windows 95 / 98 / NT4.0 / 2000.6.3.2 Commercial audio extraction code library acquired.6.4.2 Commercial audio extraction code library acquired.6.5.2 Commercial audio extraction code library acquired.7 Added new section, entitled Verification and Validation.7.2.4 Word 97 and 2000 compatible, not backwards.8 Added a button for “special notes” on applicable pages.8.1.2.10 Added Beta Phase Section8.1.5.1 Updated PERT chart. Added stronger dependencies.8.1.5.2 Updated Gant Chart. Added more milestones and modified due dates on deliverable

documents.



2 Introduction2.1 The Client

The client is Dick Schmitz, a staff computing consultant for the UNC College of Arts and Sciences. He is presently consulting on the “Oral-Text Learning” project at the Foreign Language Resource Center in the basement of Dey Hall. This Foreign Language Resource Center provided computer and audio-visual labs, recording services, technology classrooms, and other supportive services for the Department of Germanic Languages and Literatures, Department of Romance Languages and Literatures, Department of Slavic Languages and Literatures, and Department of Linguistics. The Director of the FLRC, Dr. Jim Noblitt, began the development of the “Oral Text Learning” system that is currently running at http://www.unc.edu/FLRC. Mr. Schmitz expects to spend a few months time on the “Oral-Text Learning” project improving the lesson production process.

2.2 Oral Text Learning DescriptionCurrently, the “Oral Texts in the Romance Languages” web site is up and running. This web site provides streaming Real-Audio and a few Real-Video musical tracks with printed foreign lyrics and English translations for students studying one of the Romance Languages. The student logs-in with their UNC ONYEN and password to gain access to the web site, located at http://www.unc.edu/FLRC. The student selects which language they are studying, and then selects from a list of countries, artists in those countries, and particular songs by that artist. Once the song is selected, the Real Media plug-in starts in the student’s web-browser, and he may press play to listen to a song, and begin read along with the choice of the foreign lyrics, the translated lyrics, or both combined in one table adjacent to the audio plug-in and a graphic of the artist. This technique of “oral-text learning” combines access to real-world examples of the syntax, dialect, semantics, and intonation of a language with a presentation method that gets and holds the interest of most students.

2.3 Current Production Currently, department assistants referred to as “editors” communicate with professors and other instructors that wish to produce a new audio/text lesson. These editors collect the information required from professors and instructors needed for the lesson, such as the foreign text lyrics of the song, the translated text lyrics, graphics files of the artist or the CD jacket, the audio compact-discs, tapes, or comparable extracted [.wav] sound files, and copyright information about the audio clip. The editor is then responsible for designing the web page for that lesson, and producing real-audio streaming files to place on the server for student listening.

2.4 Production Problems and Project GoalOftentimes the lesson editors are less than fluent in the lesson's language, which makes production quite a challenge. The professor or instructor who requests a lesson, not the editor, should do text entry and content decision-making. Presently, communication limitations between teachers and editors make the lesson production process slow and inefficient. Editors receive many different audio file formats, sometimes substandard or unusable, and various text files from numerous word processors with different formatting and pagination standards or even plain-text emails with lyrics and translations. The editors have to contend with the haphazard file formats and produce the lesson with the information provided, or contact the instructors and teach them how to provide useful information. The process is usually tedious, and needs improvement. The goal of this software project is to make an extremely simple computer program production interface for a foreign language instructor, which will step him through a standardized content entry process. The lesson text and files will then be transferred from the computer lab or office, where the lesson was created, over a connection to the departmental Windows NT server for centralized storage and editor access. Typically the user will connect through the high bandwidth UNC Campus Local Area Network, or alternatively, he can connect remotely through a DSL or cable-modem line via a Virtual Private Network to the server without a noticeable difference.


http://www.unc.edu/FLRC


3 Glossary3.1 Audio Extraction

Commonly known as “Ripping.” The process of transforming a physical audio medium such as a track of a audio compact disc or a cassette tape into a digital computer file such as a high fidelity wave file or compressed mp3 file, which can be transferred easily from one computer to another, without losing quality or affecting content.

3.2 BitmapBitmap images, also known as raster images, are generally any computer graphic made up of pixels in a grid. Pixels are picture elements; tiny dots of individual color that make up what you see on your screen. More commonly, Bitmaps refer to the file type with the extension *.bmp used in Microsoft Windows. These are fairly primitive graphics files that are easily edited and produced, and commonly used in web pages.

3.3 .docDocument Files created by Microsoft Word end with the extension *.doc. Microsoft Word allows formatting of text documents using RichText markup language, and extends capability to include images, tables, and other embedded formatted objects. Microsoft Word can also edit HTML files or read-only templates that allow easy text entry into pre-existing formatting. Microsoft Word, due to the widespread popularity and ease of use, will likely be used in this project for foreign lyrics text entry, and English translation text entry into a standard html template set up such that text is divided into table cells representing stanzas or verses of recorded music.

3.4 EditorThe individual FLRC employee that is responsible for taking the provided information from an instructor and producing the web based oral-text lesson, including the naming and editing of all HTML files, audio/video extraction, creation of streamable Real-audio or video files, and the posting of such files for student access. This editor currently communicates with the instructors in a case-by-case fashion as needed to collect required information for a lesson.

3.5 FLRCForeign Language Resource Center, which provides computer and audio-visual labs, recording services, technology classrooms, and other supportive services for the Department of Germanic Languages and Literatures, Department of Romance Languages and Literatures, Department of Slavic Languages and Literatures, and Department of Linguistics. Directed by Dr. Jim Noblitt.

3.6 .gifA compressed digital computer file with the file extension *.gif. GIFs are a standard for colorful computer generated graphics. GIF is short for Graphics Interchange Format. Technically best for the lossless interchange of raster images that have no geospatial context, such as the exchange of still-images that can be viewed in sequence. GIF files are popular because of their small file size, animation capabilities, and optionally transparent pixels, which makes them popular for web pages.

3.7 GUIGUI or Graphical User Interface is a user interaction mechanism which is performed through pictorial representation of textual information. In the case of this project, the GUI is the windowed application within Microsoft Windows that will allow entry of information into text fields, allow file browsing of disk space, and provide step-wise, reversible navigation through the different sections of the application.

3.8 InstructorThe individual professor or teacher that requests an oral-text lesson, and provides the materials to create the web based lesson from, including the audio, graphics, text lyrics, translated lyrics, and copyright information.



3.9 .jpeg or .jpgA compressed digital computer file with the extension *.jpg or *.jpeg. JPEGs are standard for still image compression. It is commonly used for storage of scanned photographs, or for photographs on web pages. JPEG or JPG is short for the 'Joint Photographic Experts Group'. Best used for very large still-raster images that have no geospatial context and where lossy decompression is acceptable (See also http://www.jpeg.org/ )

3.10 Oral Text LearningThe technique of learning and practicing a foreign language by listening to popular or operatic music sung in that foreign language while reading the transcribed foreign lyrics adjacent to an English translation. This technique of “oral-text learning” combines access to real-world examples of the syntax, dialect, semantics, and intonation of a language with a presentation method that gets and holds the interest of most students.

3.11 Real Audio, .rm or .rpmAn audio file compression format that is playable through a free software program (plug-in) called Real Player that works with a web browser to allow visitors to hear audio over the Internet. RealAudio files are smaller than full-fidelity files, and thus can be downloaded or streamed easily over relatively slow internet connections. Files can be copyright protected, such that the user cannot save the files for local hard drive access. Real Audio files must be produced by copyrighted software called Real Producer, and are streamable with a special network transfer protocol through a designated server. Real Media pointer files are used in the Oral Texts in the Romance Languages web site to instruct web browsers to stream audio and video files into the browser-integrated plug-in.

3.12 SNAbbreviation for Sitterson Hall, the location of the Computer Science Departments, where undergraduate students have classes and computer labs are open for them to design programs.

3.13 UserCommonly, the User of this developing software product is the Professor or instructor that is requesting an Oral-text lesson online and is in the process of providing the necessary audio, graphics, and text files for production of the lesson.

3.14 Visual BasicAlso known as VB. A proprietary programming language and compiler developed by Microsoft that is very useful for highly optimized rapid application development. It is particularly easy to develop graphical user interfaces and to connect them to handler functions provided by an application, such as Microsoft Word or a CD Audio extraction program. The graphical user interface of the VB provides intuitively appealing views for the management of the program structure in the large and the various types of entities (classes, modules, procedures, forms, etc.) Since VB is a very popular language, there is a large amount of existing libraries and VB code that can prove useful in small-scale software development projects, such as this one.



3.15 VPNA Virtual Private Network connects the components and resources of one network over another network. VPNs accomplish this by allowing the user to tunnel through the Internet or another public network in a manner that lets the tunnel participants enjoy the same security and features formerly available only in private networks. VPNs allow telecommuters or off-campus users to connect in a secure fashion to a University departmental server on the University Local Area Network (LAN) using the routing infrastructure provided by a public internetwork (such as a dialup connection to the Internet). This connection works best only where high bandwidth is available, whereas dialup 56kbps connections can cause problems. From the user's perspective, it appears as if the data is being sent over a dedicated private link, activated by the departmental login name and password. VPN’s would be used to transmit the audio, text, and graphic files from an off-campus user’s local hard drive to the FLRC server, where these files are stored for editing and web production. VPN is transparent to this application, because the computer behaves just as if it was on the Local Area Network.

3.16 .wav FileA wave file is a digital audio file with the Windows extension *.wav. Wave files can be played on most computers with a sound card. The wave format does not require MIDI. Wave files are large and stored on hard disks. A typical wave file, for stereo, 16-bit 44.1KHz audio and will take up about 11 megabytes of your computer's memory for each minute of recording time. Wave files preserve much of the quality of high-fidelity sound from CDs and other recordings, but in turn are much larger in file size when compared to other compressed audio file formats such as MPEG Layer 3 (.mp3) or RealAudio files (.rm) (see [3.11]).

3.17 WebmasterThe individual responsible for delegating web-authoring tasks to various editors in the FLRC. This person will receive email notification and special instructions from the developing software product notifying him that the User has posted materials to the dedicated FLRC NT Server for lesson production. The webmaster schedules editors to produce the lesson, then approves lesson web pages before they are posted to the internet for students.

4 User Requirements Specifications4.1 Figure 4 Region A: User Interface

4.1.1 User LevelThe user interface allows the user to interact with the program. It will be a simple GUI, easily understandable by most average computer users. The next and back buttons will allow the user to navigate the windows. All important information will be prompted for.

4.1.2 Process LevelThe user interface serves two functions. First, is to make the program simple enough for most user with little computer knowledge. The client requested that we have “large buttons” and a “simple interface”. We plan to take the user step-by-step through the process of creating a lecture with next and back buttons. Users will also be allowed to save their work in order that they might come back at a later time to finish it. Second, the user interface serves on a higher level to reduce the editors’ workload. Since the interface allows users to gather all relevant material and store it in the same location, this should cut down on the editors’ work. The user interface will allow users to enter important information such as the lesson name, the date needed and the copyright information. It will also handle audio extraction so the user does not have to try and get the song into .wav format on their own.



4.2 Figure 4 Region B: Microsoft Word Interface4.2.1 User LevelA document will pop up in MS Word where the user will be able to enter the foreign language and English text. When the user saves his/her work the text portion of the program will be completed. One column will be for foreign language text and the other will be for the English translation.

4.2.2 Process LevelOur program will pop up an MS Word template (copied under the name of their text file). This template will have the page settings already set and the user will simply type the foreign language text in one column, and the English text in the other column. Our program will save this file as an HTML file, which will be sent to the editor. MS Word was chosen because every campus computer (and most computers in general) has Word and because it supports HTML files.

4.3 Figure 4 Region C: Audio Extraction4.3.1 User LevelOur program will handle all of the audio extraction. The user will be required to place a CD in the CD-ROM drive, choose the drive from a list where the CD is located, and choose the desired track. When they are ready to extract the track, the user will click on an OK button or something similar. Our program will automatically extract the track.

4.3.2 Context LevelThe audio extraction will be handled through our program so the user does not have to attempt to do this by himself. The user will choose a track from a CD and click on something signaling the program to start the extraction. An audio extractor will pop up (at current, Sean is trying to write this in VB but we may decide to use a freeware version) and the track will be extracted behind the scenes. The user will then be allowed to replay the song if desired to check for correctness.

4.4 Figure 4 Region D: Network File Transfer4.4.1 User LevelThe user will see a progress bar notifying them that their files are being transferred to a centralized location for storage and manipulation. This includes the transfer of the graphic, the audio file, the word file, and all file attachments. They do not need to understand how our program gets the files to the editor, however they need to know that this process is taking place. They will be notified, first, that our program will transfer the files when they are ready, and then they will be notified that the transferring has been completed.

4.4.2 Context LevelLesson files must be transferred to a centralized storage location so that editors and users can access them when required for manipulation or web page creation. The client has asked that we do all transferring over the Windows NT network instead of by FTP. When the files for the lesson have been created or submitted, they will be transferred into a directory in a set domain. They will be stored using the naming convention currently in place by the program used by the FLRC. We will have several folders in which the files will be classified and stored. For example, there will be "in", "ready", "wip" (works in progress), and "active" folders. There are two reasons for the separate folders. First, this will help with the implementation of the "Resume/Modify" feature. This way, the program will know which files can still be edited and which cannot. The users will not have access to certain folders such as the "ready" folder. Here, editors can store the files that are ready to be posted to the Internet. This serves as a security feature, restricting access to only the editors and the Webmaster.



4.5 Figure 4: Summarized Context Model Diagram

5 System Requirements Specification5.1 Functional Requirements

The following is a System-level text description of the Overall model (Diagram [5.1.1]). It will go through each screen, and discuss the behavior and interface requirements for each section of the diagram. I will refer to the Technical Notes that the Client gave us as [TN.1.page_number] (see [Section 9: Appendix] for this document). The large dashed regions indicate major regions of functionality within the Context Model Diagram [Figure 4 and Section 4]. All items not included in a larger dashed region, (B, C, or D) are considered to be part of region A, User Interface.

For every section of the program, the user will have an option to save their progress, and return later to finish. Because this option will be on many pages, we will describe it here, and just refer to the functionality as the “save” button. On a general basis, the save function will have to save the state of how far the user has gone in the program (by associating a special number corresponding to the last page completed). The user, if he/she wants to save their progress, they will have to remember the name they gave their lesson. Since we guarantee the name will be unique, this will serve as a sufficient way to maintain the state of the user.

Another option that will appear on many screens is the special instruction page. Again, since this function will appear on many screens, we will describe it once here and refer to it is the “S.I. button”. If the user feels the need to leave instructions (“this file is a quiz they should take”, or if the user feels that he/she did not do something right “the graphic might be too big, but I don’t know”, etc.). All of the instructions that are entered in through the program will be concatenated together into a text file and the user will be able to view/edit those instructions before he/she sends it in.


A: User Interface B: MS Word Interface

C: Audio Extraction D: Network File Transfer

ORALTEXT

LEARNING Production


5.1.1 Overall Model Diagram


D:N.F.T.

5.1.1.1 Welcome

5.1.1.2 Administrative Screen 5.1.1.3 Resume/ Modify ID 5.1.1.4 User Information

5.1.1.5 Name Entry

5.1.1.6 Do you have a graphic?

Open word

5.1.1.8 Song Information

5.1.1.9 Where is the Song?

5.1.1.10 File Attachment

5.1.1.11 Special Instructions

5.1.1.12 Review or Modify anything

5.1.1.13 Finished

5.1.1.3.1 What do you want to Modify?

5.1.1.5.2 Confirm Name

5.1.1.5.1 Rename

5.1.1.6.1 Get drive/disk

5.1.1.6.2 Get URL

5.1.1.6.3 none provided

5.1.1.7.1 Preview Word

5.1.1.9.1 .wav file on hard

5.1.1.9.2 Song is on a CD

5.1.1.10.1 Attach file now

5.1.1.7 Pre-Word

Open Word File

Login with password Create New LessonModify Existing/Resume

Duplicate rename. Unique valid name.

Yes

Yes

No

CD or existing .wav

Yes, attach

Yes, review or modify

No

No file

Modify Graphic

Modify Lyrics

Modify Song Info

Modify Attachments

Modify Song File

B: MS Word Interface

Skip song

C:Audio Extraction

A:UserInterface(all un-boxed items)


5.1.1.1 Welcome ScreenThis could potentially become two screens, but the functionality will remain the same. This is a basic welcome screen. It will probably contain some written information telling the user what he/she should expect/need to complete the program (very broadly). The only functionality of this screen will be that the user will have one of three options: 1. “Administrative” (password protected - this option will send the user to the administrative

screen [5.1.1.2]) 2. “New” - for users who want to create a new lesson plan (will take users to screen [5.1.1.4]) 3. “Resume/Modify” - for users who saved their progress and want to finish (or modify) where they

left off. (screen [5.1.1.3])

5.1.1.2 Administrative ScreenThis screen will have several basic functionalities for administrators. Most of these options will come up as we are coding, and we realize what we should allow a basic administrator to be able to change. Some options we have already come up with are: ability to change web-masters email address (see [5.1.1.13]); ability to change password; ability to change path of where files are saved. More will come up as we begin to actually implement some code. There will be options that the administrator can change, and a button to accept and make the necessary changes.

5.1.1.3 Resume/Modify ID ScreenThis screen will request the name the user decided on in [5.1.1.5]. Since this name will be unique, this will be the easiest way to let the user resume his/her progress. If deemed necessary (pending implementation) there will be a confirmation screen showing the users info to make sure the user entered the correct name. Upon getting the name, the program will need to find all the information that the user has already given, upload the necessary info into the correct places, and then take the user to screen [5.1.1.3.1].5.1.1.3.1 What do you want to modify screenUpon getting to this screen, there will be a list of steps given (a list of all the necessary steps to complete the program). By clicking on one of the steps, the user will be taken to corresponding screen.

5.1.1.4 User Information Entry ScreenThis will get the user info requested in [TN1.1.7]. It will be a basic form requesting the following information: instructors name; course number; date the new lesson set is needed (mm/dd/yy); title to show on the index page and which index page it should play from; title to appear in the lesson set player frame; language lesson is in; user’s email. A back button will take the user to [5.1.1.1]. A next button will be provided. There will be some sort of internal representation (a boolean for example) saying if a lesson name has been given or not (have they gone through [5.1.1.5] yet). If they have already gone through [5.1.1.5] (because of several internal reasons, it would be easier if the user would not be allowed to go back and change the lesson name) the next button will take the user to [5.1.1.6]. If the user has not gone through [5.1.1.5], the user will be taken to [5.1.1.5]. There will be a “save button” and a “S.I. button” as described above.



5.1.1.5 Name ScreenThe user needs to provide a one-word name for the lesson. The screen will inform the user the importance of remembering this name for purposes of saving and returning to finish their progress. Upon giving this name, if it is not unique, the user will be taken to [5.1.1.5.1]. If the name given is unique, it needs to be saved with the user info, and assigned to a name field. Also, the program needs to make a copy of the HTML template file into the designated directory and name it givenname_4_text_pg1_2col.htm. The directory it is saved in determines the status of the lesson and whether the user can resume or whether he/she can only modify a copy of the original files. For example, if the lesson is in the "wip" (work in progress) or "complete" folder, the user will not have write access and will therefore only be allowed to modify a copy of the files. If the files are in the "in" folder, the user does have write access and will be allowed to simply resume his/her original lesson. These directories are listed in [4.4.2]. The program will then take the user to [5.1.1.5.2]. There will be a submit button that will take the user to [5.1.1.5.1] or [5.1.1.5.2] pending uniqueness. A back button will take the user to [5.1.1.4]. A "save button" and a "S.I. button" are provided as discussed above.5.1.1.5.1 Re-name ScreenWill have the exact same functionality as [5.1.1.5], but will have different text informing the user that the name they have given has been used already, and if a non-unique name is given again, it will return to this screen. If a unique name is given, the program will have to create the word template file and take the user to [5.1.1.5.2]. A “save button” and a “S.I. button” are provided as discussed above.5.1.1.5.2 Confirm Name ScreenThis will show the user the name they have given, ask them to remember it and tell them that it now cannot be modified. Clicking on “next” will take the user to [5.1.1.6]. Clicking on “back” will take user to [5.1.1.4]. A “save button” and a “S.I. button” are provided as discussed above.

5.1.1.6 Do you have a graphic ScreenThis screen will ask the user if they have a graphic they want to provide, and how they want to provide it. The user will be given three options to click from in radio button fashion:

o (default) No I do not have a graphic - will take user to screen [5.1.1.6.3];o I have a graphic on my disk/hard drive - will take user to [5.1.1.6.1]; o I have a url of a graphic I want to give - will take user to [5.1.1.6.2].

Upon clicking the “next” button, the user will be taken to the screen pending the radio button. Clicking on the “back” button will take them to [5.1.1.5.2]. A “save button” and a “S.I. button” are provided as discussed above.5.1.1.6.1 Get hard drive/disk graphicThis screen will have some way for the user to look through their files on their hard drive/disk and provide the pathway to the graphic they want to provide. There will be a “browse” button. There will be a “next” button that will take the user to [5.1.1.7] if there is a file provided or a warning screen will pop up (the file will be saved in the correct file with the name givenname_graphic.filetype). The “back” button will take the user to [5.1.1.6]. A “save button” and a “S.I. button” are provided as discussed above. The warning screen (or something similar) will state that the user has not provided a graphic and ask if they want to continue anyway. If yes it will take the user to [5.1.1.7]; if no, it will take the user to [5.1.1.6.1]. The user will also be able to view the graphic. 5.1.1.6.2 Get URL graphicThis will provide a one-line text box so the user can enter in a URL of a graphic they want to give. It will be saved as a string and provided in the email to the web-master. There will be a text field, where the user can enter any special notes regarding their desired graphic. There will be a “next” button that will take the user to [5.1.1.7] if there is a URL provided or a warning screen will pop up. The “back” button will take the user to [5.1.1.6]. A “save button” and a “S.I. button” are provided as discussed above. The warning screen (or something similar) will state that the user has not provided a URL and ask if they want to continue anyway. If yes it will take the user to [5.1.1.7]; if no, it will take the user to [5.1.1.6.2].



5.1.1.6.3 No Graphic ScreenAn information page saying that the user can save their progress, and come back later with a graphic, or email the Webmaster later and provide one as an attachment. There will be a “next” button that will take the user to [5.1.1.7], and a back button that will take the user to [5.1.1.6]. A “save button” and a “S.I. button” are provided as discussed above.

5.1.1.7 Pre-Word ScreenAn information page explaining what is about to happen. Word will open with the pre-named template open. The user will need to enter the text and save the file (without changing the path or file name). This screen will explain all of this in very laymen’s terms. There will be an ok button that will open Word and take the application to page [5.1.1.7.1] (there will be two applications running at the same time). There will be a back button that will take the user to [5.1.1.6]. A “save button” and a “S.I. button” are provided as discussed above. 5.1.1.7.1 Preview Word ScreenWill give the user a chance to view the template file. This will be useful for modifying purposes, and to make sure the file is saved in the correct place. There will be a “preview” button that will open the word template. There will be a back button that will take the user to [5.1.1.7] and a next button that will take the user to [5.1.1.8]. A “save button” and a “S.I. button” are provided as discussed above.

5.1.1.8 Song Information ScreenThis will be a form getting all the necessary song information as requested in [TN1.1.7] and [TN1.1.8]. The fields will be - Artists name; song title; composer’s name; label company name; and copyright year. There will be a back button that will take the user to [5.1.1.7.1], a next button that will make sure all fields are entered, and then take the user to [5.1.1.9]. A “save button” and a “S.I. button” are provided as discussed above.

5.1.1.9 Where is Song ScreenThe user will be given three options to submit the song to the program. The choices will be (radio button format):

o On hard drive/disk in .wav format o On a CD o Skip song extraction.

The next button will depend on the radio button. If the file is on the hard drive or a disk the user will be taken to [5.1.1.9.1]. If the file is on a CD - the user will be taken to [5.1.1.9.2]. If the audio extraction is skipped, the user is taken to [5.1.1.10]. There will be a back button that will take the user to [5.1.1.8]. A “save button” and a “S.I. button” are provided as discussed above.5.1.1.9.1 .wav file on hard drive/disk screenIf the file is on the hard/drive or disk in a .wav file, the user can submit it here. There will be a text box for the user to enter in the path name, and a browse button. There will be a submit button that MUST do type checking to make sure the file is a .wav file. If the file is not in .wav, the user will be asked to enter in the file again, or hit back so they can just put in the CD. If the file is .wav, it will save copy the file into the correct directory with the name givenname.wav, let the user listen to the saved song, and then take the user to [5.1.1.10]. There will be a back button that will take the user to screen [5.1.1.9]. A “save button” and a “S.I. button” are provided as discussed above.5.1.1.9.2 Song on a CD screenThis will either open an application that we will tie in, or (if we create a CD ripper, open our version). Either way, it will be an application that will extract .wav audio from the CD, allow the user to listen to the saved song, and then take the user to [5.1.1.10].



5.1.1.10 File Attachment ScreenThis will ask the user if they have any files they wish to attach to the lesson (notes, quiz, etc.). If the user clicks yes, they will be taken to [5.1.1.10.1]. If they click no, they will be taken to [5.1.1.11]. There will also be a back button that will take the user to [5.1.1.9]. A “save button” and a “S.I. button” are provided as discussed above.5.1.1.10.1Attach File ScreenThis will provide a text box and a browse button so the user can attach files to be mailed to the webmaster. There will be an “attach” button that will attach the file, and ask the user if they want to attach any more files. If yes, they will be taken back to [5.1.1.10.1]. If no, they will be taken to [5.1.1.11]. There will be a back button that will take the user to [5.1.1.10]. A “save button” and a “S.I. button” are provided as discussed above.

5.1.1.11 Special Instructions PageThis screen will allow the user to preview any special instructions they have entered in to this point. If they want, they can add some, or modify the already entered ones. Whatever is typed will be concatenated with all the previous special instructions, with delimiters, and will be included in the email (see [5.1.1.13]). If they included a file, this would be good to explain what the file is, or any concerns they might have (I don’t know if I did this right….. etc.). There will be a next button that will take the user to [5.1.1.12], a back button that will take the user to [5.1.1.10] and a save button as described above.

5.1.1.12 Review or Modify pageThis will have an option to see if the user wants to review or change anything that they have entered. If they click on yes, they will be taken to [5.1.1.3.1] (or a similar page). If they click on no, they will be taken to [5.1.1.13]. There will be a back button that will take the user to [5.1.1.11], and a save button as described above.

5.1.1.13 Finished PageOn this page will inform the user that if they click finished, they can no longer go back and modify anything because it will all be sent to the webmaster. If the user clicks ‘Finished’, they will no longer be able to modify any information, and an email with several pieces of given information will be sent automatically to the webmaster informing him that the lesson is ready to be created. The user can click a back button if they want to modify anything, and a save button as described above.

5.2 Non-Functional Requirements5.2.1 Application

5.2.1.1 StorageCan accommodate any file size

5.2.1.2 I/O device capabilityMust have a CD-ROM that allows digital audio extraction

5.2.1.3 File TypesProgram can process text, audio and graphic files*.doc or *.html*.wav*.jpg or *.jpeg*.bmp*.gifFile type checking will ensure that appropriate files are selected.

5.2.1.4 Stand-aloneApplication is not web based



5.2.2 Organizational Requirement5.2.2.1 Naming Convention

Follow naming convention given in [TN1.1.7]5.2.2.2 Implementation

All coding will be done in Visual Basic (VB) and C++

5.2.3 External Requirements5.2.3.1 Authentication

User must have a valid departmental login and password5.2.3.2 Copyright Information

A user must provide the copyright information of a CD:Song Title, Composer’s name, Label company nameCopyright year.

5.3 Domain RequirementsApplication is guaranteed to run on Windows NT 4.0 Operating System, and should operate functionally in Windows 95, 98, NT 4.0, or 2000 operating systems.User must have high bandwidth connection capability to the required network.Need text editing application that can handle *.html files.

5.4 Goals5.4.1 User friendly system

Create an easy-to-use interface so that anyone with little computer training will be able to use the program.

5.4.2 Easy to maintain systemProvide adequate documentation for revision and improvement in the future.

6 Hardware and Software Resource Requirements6.1 Hardware

6.1.1 CD-Rom with digital audio extraction capabilities

6.2 Software (in order of importance)6.2.1 Visual Basic Development Software (Microsoft)6.2.2 CD Extraction6.2.3 Audio Preview6.2.4 Email Scripts6.2.5 Graphics Preview

6.3 Plans to procure6.3.1 Visual Basic Development Software

Microsoft will provide copies of Visual Basic if labs in Sitterson do not have copies or if they are unavailable to satisfy our request.

6.3.2 CD ExtractionA commercial audio extraction code library has been located. There are no current legal issues with use of this code. Team member Sean is also developing his own extractor that may be used optionally if scheduling is not jeopardized.

6.3.3 Audio PreviewThe Internet is the best option if not a built-in feature of the extractor.

6.3.4 Email ScriptsThe Internet is one option for finding information on this topic if we cannot solve it using system calls.



6.3.5 Graphics PreviewThe Internet is one option if we cannot develop a way to display graphics.

6.4 Estimated Schedule of Procurement/Delivery6.4.1 Visual Basic

Some machines in Sitterson have Visual Basic now installed. Our team could begin prototyping and development in Sitterson upon availability of these select machines. Otherwise, these phases will be on hold until available from Microsoft—optimistically, by Feb 8, 2001.

6.4.2 CD ExtractionA commercial audio extraction code library has been located. Team member Sean has begun developing an additional extraction resource.

6.4.3 Audio PreviewThis is not a required feature, however, Dick Schmitz desires for it to be included. Thus far, no resources have been procured for this feature. If it is not a built-in feature, then we will need to procure resources before the Audio Extraction Phase.

6.4.4 Email ScriptsHopefully this requirement can be done through VB system calls. However, in the case that this cannot be done, resources for this feature need to be procured before the beginning of the Communication Phase of development.

6.4.5 Graphics PreviewThis is also a desirable feature, but is not required. At this moment no resources have been procured for this feature. Resources will be needed before the Additional Features Phase.

6.5 Alternatives (risk management)6.5.1 Visual Basic

There is no alternative to using Visual Basic. Each team member has his own personal copy of Microsoft Visual Studio for VB development, and computer labs in Sitterson are available for development. Reference books are on order from Microsoft Press.

6.5.2 CD ExtractionA commercial audio extraction code library has been located. There are no current legal issues with use of this code. This is probably the most important feature and the most difficult feature of the entire application.

7 Verification and Validation7.1 Strategy

The program should be tested for the conditions listed under Test Cases [7.2]. These are the areas of general concern for the Software Engineering Team. There are two specific areas of concern for the project. The program will have to handle user input many times. Because our users are not computer aficionados, our program should be able to handle wrong/unexpected input. The program also needs to make sure the information gathered is stored correctly. Another main concern is that the interface with external programs works correctly. Since these programs are outside the control of this program, a lot can go wrong. Our program should expect user error. Our testing phase should mainly occur between March 5th and April 9th. This will be testing done by the team for problematic or buggy code. This part of testing will be done on section by section (i.e. test all the graphic screens as a whole). After the program is completed, we will implement “beta testing” where the program is tested by actual users. They will notify the Software Engineering Team of critical problems they encounter with the program. Minor corrections may be made at this point but major changes will not.



7.2 Test Cases7.2.1 Invalid Input

For each step, the program needs to prevent invalid input (i.e. wrong file types).7.2.2 Resume/Modify

Make sure that all files are retrievable from the server for modification, and any changes made are accurately synchronized with those originals still on the server. Make sure the program knows how much of the wizard the user has completed, and where all the user’s files are located.

7.2.3 Graphic TestMake sure the graphic supplied by the user is in an acceptable format and if it is not, the program should recover from this gracefully. The program also needs to let the user see the submitted graphic.

7.2.4 Word InterfaceBe able to handle problems created by opening Word. For example, if Word is already active when the program attempts to open it, the program should not crash. Microsoft Word 97 or 2000 should be compatible, but earlier versions do not have to be supported.

7.2.5 Network TransferringThe program needs to guarantee that the files are saved in the correct space with the correct name.

7.2.6 Information EmailMake sure all information entered by the user is emailed to the webmaster in the correct format and that the email address to which this information is sent can be changed in the Administrative Section.

7.2.7 PC Crash ProtectionThe program should be able to handle computer crashes without losing all information provided. In order to do this the program must save each file or text as it is advancing to the next screen.

7.2.8 Audio ExtractionThe program needs to extract the proper track from a CD. The program should also be able to handle no CD in the drive, or a non-audio CD.

7.2.9 Lesson NameThe program needs to guarantee unique lesson names. It also needs to convert any uppercase letters given to lower case before testing for uniqueness. It also needs to handle spaces.

8 Developmental Schedule8.1 Development items8.1.1 Major Phases

8.1.1.1 GUI PhaseDesign and development of user graphical interfaces/pages for each step of the application.

8.1.1.2 Introduction and Naming PhaseDevelopment of the introduction, general information, and lesson naming pages.

8.1.1.3 Graphics PhaseDevelopment of the insertion of the user graphic or URL page.

8.1.1.4 Lyrics Text PhaseDevelopment of page that will open Word for text editing.

8.1.1.5 Modify Feature PhaseDevelopment of the pages that will allow modifications to already created lessons.

8.1.1.6 Audio Extraction PhaseDevelopment of page that will extract a track from the user’s CD-Rom drive.



8.1.1.7 Communication PhaseDevelopment of page that will create and send an email to the editor from the user communicating that a new lesson has been created.

8.1.1.8 Additional Features PhaseDevelopment of:

8.1.1.8.1 Administrator’s MenuDevelopment of page that contains changeable information such as editor’s email, file saving location, etc.

8.1.1.8.2 Audio PreviewDevelopment of the feature that replays the CD extraction.

8.1.1.8.3 Graphics PreviewDevelopment of the feature that will display the user specified graphic.

8.1.1.8.4 File Attaching PhaseDevelopment of the feature that will allow the user to attach quizzes, notes, etc.

8.1.1.9 Testing/Quality Assurance PhaseTesting of all phases to ensure completeness and accurateness.

8.1.1.10 Packaging PhasePackage all files into deliverable format—perhaps distributable CD’s or downloadable format.

8.1.1.11 Documentation PhaseProduction of deliverable documents about the software including user manuals and system manuals.

8.1.2 Tasks and Dependencies8.1.2.1 GUI Phase

Learn the basics of Visual Basic to get started with development with an emphasis on GUIs.

8.1.2.2 Introduction and Naming Phase8.1.2.2.1 Creation of the GUI of this step.8.1.2.2.2 Text fields for user information and any other important information needed.8.1.2.2.3 Text field for the naming of the lesson and error checking to ensure

uniqueness.8.1.2.2.4 Button for modify option to be implemented in the Modify Feature Phase.8.1.2.2.5 Button for Administrator’s menu option to be implemented in the Additional

Features/Administrator’s Menu Phase.

8.1.2.3 Graphics Phase8.1.2.3.1 Creation of GUI for this step.8.1.2.3.2 Text fields for the location of the graphic or URL.8.1.2.3.3 Button for graphics preview to be implemented in Additional Features/Graphic

Preview Phase.8.1.2.3.4 Button for special notes.8.1.2.3.5 Transfer of file to network.

8.1.2.4 Lyrics Text Phase8.1.2.4.1 Creation of GUI for this step.8.1.2.4.2 Creation of HTML template file for text editing.8.1.2.4.3 Command to open Word application for text editing.8.1.2.4.4 Button for special notes.8.1.2.4.5 Save and transfer file to network.



8.1.2.5 Modify Feature Phase8.1.2.5.1 Creation of GUI for this step.8.1.2.5.2 Implementation of button on main page for the option of modifying an existing

lesson.

8.1.2.6 Audio Extraction Phase8.1.2.6.1 Creation of GUI for this step.8.1.2.6.2 Button for audio preview to be implemented in the Additional Features/Audio

Preview Phase.8.1.2.6.3 Use of CD extraction program to extract a track from a CD on the user’s CD-

Rom drive.8.1.2.6.4 Button for special notes.8.1.2.6.5 Transfer of file to network.

8.1.2.7 Communication Phase8.1.2.7.1 Creation of GUI for this step.8.1.2.7.2 Text field for modifications to standard email.8.1.2.7.3 Button for special notes.8.1.2.7.4 Creation of email to be sent to WEB master with any special instructions.

8.1.2.8 Additional Features Phase8.1.2.8.1 Administrator’s Menu

8.1.2.8.1.1 Creation of GUI for this step.8.1.2.8.1.2 Text fields for changeable information.8.1.2.8.1.3 Security protected.

8.1.2.8.2 Audio Preview8.1.2.8.2.1 Implementation of button on Audio Extraction Phase.8.1.2.8.2.2 Implementation of playing back the extracted audio file.

8.1.2.8.3 Graphics Preview8.1.2.8.3.1 Implementation of button on Graphics Phase.8.1.2.8.3.2 Implementation of displaying user specified graphic.

8.1.2.9 Testing/Quality Assurance Phase8.1.2.9.1 Testing of all files to ensure correctness.8.1.2.9.2 Testing of all files to ensure ease of use.8.1.2.9.3 Testing of all files to ensure efficiency.8.1.2.9.4 Testing of all files to ensure stability.

8.1.2.10 Beta Phase8.1.2.10.1 Gathering of all files into preliminary deliverable format.8.1.2.10.2 Non affiliated team members will test for completeness and accuracy.

8.1.2.11 Packaging Phase8.1.2.11.1 Gathering of all files into deliverable format.8.1.2.11.2 Creation of deliverable format (perhaps available on CD or for download)8.1.2.11.3 Collecting all documentation and manuals for distribution.

8.1.2.12 Documentation Phase8.1.2.12.1 Creation of user manual or alternatively a integrated help file.8.1.2.12.2 Creation of Implementation Manual.8.1.2.12.3 Creation of System Manual including system requirements etc.



8.1.3 Major milestones8.1.3.1 Project Milestones

8.1.3.1.1 Backbone MilestoneMilestone representing the technical halfway point. At this milestone the beginning and easy part of the application should be completed.

8.1.3.1.2 Almost Done MilestoneMilestone representing the ending of the development process and finishing testing and quality assurance phase of development. At this point, the development should be done and should be moving towards final testing and packaging.

8.1.3.2 Deliverable Milestones8.1.3.2.1 Preliminary Report8.1.3.2.2 Project WEB I8.1.3.2.3 Contract I8.1.3.2.4 Schedule I8.1.3.2.5 Contract II8.1.3.2.6 User Manual8.1.3.2.7 HLD8.1.3.2.8 Project WEB II8.1.3.2.9 Prototype8.1.3.2.10 Schedule II8.1.3.2.11 Implementation Manual8.1.3.2.12 WEB complete8.1.3.2.13 Project Packages8.1.3.2.14 Final Reports (Team and individual)

8.1.4 Deliverables8.1.4.1 Weekly Reports8.1.4.2 Preliminary Report8.1.4.3 Contract I & II8.1.4.4 Schedule I & II & III8.1.4.5 User Manual8.1.4.6 Implementation Manual8.1.4.7 Project Packages8.1.4.8 Individual Final Reports

8.1.5 Diagrams8.1.5.1 PERT Chart- See Appendix 9.18.1.5.2 Gant Chart- See Appendix 9.2

8.1.6 Risk Analysis and Management8.1.6.1 Identified Risks

8.1.6.1.1 Software procurement8.1.6.1.2 Education/Learning of Visual Basic

8.1.6.2 Plans8.1.6.2.1 Avoidance or assignment

Learning materials have been ordered from Microsoft.8.1.6.2.2 Tasks have been split between the group.



9 Appendices9.1 Pert Chart Pages 1-4 (pages 22-25)9.2 Gant Chart Page 1 (page 26)9.3 Technical Notes Issue 1.1 for Procedure # 01-001 by Dick Schmitz for FLRC

(attached)



9.1 Pert Chart page 1 (Top Row Left)



9.1 Pert Chart page 2 (Top Row Middle)



9.1 Pert Chart page 3 (Top Row Right)



9.1 Pert Chart page 4 (Bottom Row)



9.2 Gant Chart


€¦ · Web viewMicrosoft Word, due to the widespread popularity and ease of use, will likely be...

Documents

Transcript of €¦ · Web viewMicrosoft Word, due to the widespread popularity and ease of use, will likely be...