Table of Contents

1. System Overview
   
   1. System Objectives
      
   2. System Scope and Context
      
      
2. List of Documents
   
   
3. Product Rationale
   
   1. Business Case Analysis
      
      1. Development Cost Analysis
         
      2. Operational Cost Estimate
         
      3. Estimate of Value Added and Relation to Cost
         
   2. Stakeholder Concurrence
      
   3. Requirements Satisfaction
      
      1. Capability Requirements
         
      2. Interface Requirements
         
      3. Quality Requirements
         
      4. Evolution Requirements
         
   4. Operational Concept Satisfaction
      
      
4. Process Rationale
   
   1. System Priorities
      
   2. Process Match to System Priorities
      
   3. Consistency of Priorities, Process and Resources
      
      
5. Risk Analysis
   
   
6. Appendix
   
   
7. Glossary
   

The International (French) Cross-Cultural Teaching Model (ICTM) can be viewed as a teaching vehicle by which instructors can more effectively provide course instruction via the internet. For a more detailed overview of the ICTM, please refer to the System Overview of the OCD (Section 1.0).

1.1 System Objectives

Briefly speaking, the objective of the ICTM is to simplify and consolidate the process by which instructors may provide course-related multimedia materials to their students, thus indirectly providing the students with an intellectually rich, diverse atmosphere through which they can more effectively study and learn about, in this case, the French culture. For further details on the objectives of the ICTM, please refer to the System Objectives of the OCD (Section 1.1) .

1.2 System Scope and Context

The ICTM could potentially develop into a large scale software product comprised of components that provide users with extensive functionality; however, under the proposed time constraints, the scope and context of the ICTM system is limited to basic functionality that still achieves the fundamental goals of the system. The scope and context of the ICTM are further detailed in the System Scope and Context of the OCD (Section 1.2) .

2.0 List of Documents

3.1 Business Case Analysis

The operational costs associated with the International (French) Cross-Cultural Teaching Model are estimated and analyzed in the following sections. The objective of the business case analysis is to compare the value and cost of the current system that is employed by the French and Italian department against the value and cost of the proposed ICTM system. For further detailed analysis on the motives for changing from the current system to the proposed ICTM system, please refer to the Rationale for New Capabilities of the OCD (Section 4.3) .

3.1.1 Development Cost Analysis

The cost of development for this project is essentially zero because this project will be developed for free by a team of graduate students enrolled in CS577b. In addition to the free labor costs, the equipment expenses are also negligible since the system will be developed on either USC provided hardware or on student-owned computers. However, if a server cannot be found to house the ICTM system, then the development cost will increase considerably to cover the cost and purchase of an appropriate server. Inherent to the development costs of this project are also minor expenses in the form of storage media, paper, etc.

3.1.2 Operational Cost Estimate

The primary operational cost of the current system involves hiring student assistants to develop and maintain web pages for multimedia course deliverables as well as issuing course materials via more traditional methods such as handouts, in-class slides, etc. As stated by the customer, the costs for web development are currently minimal: theoretically $7.25/hr but, because the customer only hires work study students, the customer only ends up paying about 50% of the total hourly rate. The design of the page took one week (20 hours) and the student assistant is currently contributing about one hour per week on the project, since the "template" is already in place.

One of the objectives of the proposed system is to simplify the web page creation/modification process enough so that instructors can input material themselves. This can lower labor costs by reducing the amount of time student assistants will have to spend on data entry and site development. Offsetting this reduction in operating costs, however, is the additional cost necessary for account maintenance where both student and professor user accounts will have to be established to prohibit unauthorized access to the system.

But the primary objective of this system is to allow multiple local or remote instructors to input their material into this collaborative, instructional site. This can reduce operating costs in two ways: 1) it decreases the supplies and paperwork needed to accommodate the additional information and 2) it reduces the amount of time the student site assistants will have to spend on data retrieval and entry.

Therefore, it is estimated that there will be a net reduction in operational costs.

3.1.3 Estimate of Value Added and Relation to Cost

Although the International (French) Cross-Cultural Teaching Model does not generate revenue for the Department of French and Italian, its value can be measured by the enhanced instructional environment that it provides.

The comparison of the value added versus the relation to cost between the current system and the proposed system can be noted in two ways: 1) cost in terms of time spent in "clerical" and "housework" tasks (tagging, deleting outdated materials, checking outdated links) will be significantly reduced if not eliminated in the proposed system and 2) which will in turn allow for a system which allows for greater concentration in content. The advantages are thus qualitatively enhanced, while quantitative measures become less important.

By simplifying the web page creation/modification process and by placing the teaching model on the internet, authorized instructors from around the word, in this case Paris, could input their material to this site, comfortably and efficiently. With multiple instructors contributing their material to the teaching site, the breadth and quality of material is augmented, thus providing students with a more comprehensive educational experience.

In addition, the International (French) Cross-Cultural Teaching Model benefits students in that it consolidates course-related information into one site, making it more convenient for students to access material and thus encouraging students to explore and make use of the site. Furthermore, by incorporating a search element, a translation element, and a communications element (bulletin board) into our proposed system, students are provided a more effective, a more efficient vehicle by which they can learn about contemporary French culture.

3.2 Stakeholder Concurrence

The three primary stakeholders in this project (user, developer, customer) used the WinWin negotiation process to identify and define the requirements of the proposed system. Project stakeholders specified their win conditions at the beginning of the negotiations. Subsequently, issues related to win conditions were identified and options were proposed to resolve the issues. The conclusion of the WinWin negotiation produced agreements to the win conditions and options that establish the functionality for our proposed system.

3.3 Requirements Satisfaction

3.3.1 Capability Requirements

The capability requirements for the ICTM proposed system can be divided into four categories: general capabilities, student site capabilities, instructor site capabilities, and optional capabilities. The general capabilities are those capabilities which are common to both the student and instructor sites. The student site capabilities are those capabilities contained at the student site which are intended primarily for student use. But because instructors also have access to the student pages, they are able to make use of the student capabilities as well. Students, on the other hand, do not enjoy the same privileges as the instructors and therefore cannot gain access to the instructor site, nor can they make use of the capabilities contained at that site. Thus, he instructor site capabilities are restricted for instructor use only. The optional capabilities are categorized by those features which, though they enhance the overall functionality of the ICTM system, should be considered only if resources, technology, and/or time becomes available.

Note that the capabilities of this system are available only to authorized users - students enrolled in the course and participating instructors.

General Capabilities:

• Authentication:
  Initially, any individual with internet access will have the capacity to login to the ICTM system. This login page will serve as a common starting point for all potential users of this system - unauthorized users will be filtered out at this stage. Authenticated users -- those users that have a UCS account and are enrolled in or instructing the target course -- will then proceed to the student site which consists of a student page, the student bulletin board, and the student capabilities. A link to the instructor site will also be available, though only instructor users will be granted access. Another login prompt should be unnecessary since the username can be checked against the username database to ensure that the user has enough privileges to access the instructor page.

• Bulletin board:
  As specified in the WinWin negotiations, a bulletin board will serve as a pseudo-live communications forum by which students and instructors can communicate with one another. It is important to note that the bulletin boards on each page are disjoint. Students will have the ability to read and post messages only on the student bulletin board and instructors will have the capacity to read and post on both bulletin boards. The username, the date, and the time will be posted along with each user's message to ensure integrity and proper identification. Furthermore, each bulletin board will possess a sorting mechanism based on date. In other words, a user should be able to click on a date and retrieve all the messages that were posted on that particular date. Optionally, both bulletin boards may possess a mechanism by which outdated messages will be automatically deleted after a period of two months.

• Translation:
  Any user on the student site will be granted the capability to translate a page into French, English or back to the original version. The translation should not occur when a user selects a translation option, otherwise, there will be an enormous performance overhead every time a user requests to translate a page. Instead, the translation should be done immediately following a page update by the instructor. This is accomplished by sending the updated page to the on-line translation provider which will then return two newly translated versions of the page, in French and in English, to be stored on the server along with the original. Thus when a user wants to translate a particular page, the user is simply following a link to the translated page. This means that the system will not support selective translation within a web page.

• Search:
  The student site will also support searching for text keywords in the web pages created by the instructors at the instructional site. The search should not extend beyond the boundary of the site due to performance issues. In addition, the query should be allowed in both French and English and the results should return a list of potential links to the local pages. Query searches on images containing text will not be supported; however, the system will allow instructors to include keyword descriptions along with images that will essentially enable users to perform searches on images.

• Instructor email:
  A form to email the instructor will be provided for students to email their comments, suggestions, and questions to the instructor. Although this capability serves a convenient communications medium for students, it also serves as a means by which instructors can copy and paste text, bulletin board messages for example, into the email body and mail the messages to themselves for storage or selective printing purposes. By using a form mailer, as opposed to a simple "mailto" HTML tag, the username can be included with the message, allowing the instructors to identify the sender. A carbon-copy of the message will also be sent to the user for verification purposes.

• Time stamping:
  Posted at the top of every student page will be a time stamp to indicate the last time the page was updated by an instructor.

• On-line help:
  Located on the student site menu bar will be a link to on-line help documentation for the ICTM. Though the CS577b personnel are not expected to be fluent in French, the help should be bilingual. Initially the on-line help documentation should be written in English and then translated over with the help of the client and/or the on-line translation service.

• Web page creation:
  In order to keep the underlying directory and file structure hidden from the user, new pages will be automatically assigned a filename and a page number (i.e. page1.html, page2.html, etc.) Though the filename will be invisible to the user, the page number assigned to the student web page will be displayed somewhere on the screen for user reference.

• Web page selection:
  At the instructor user's disposal will be a mechanism by which he/she will be able to cycle through the pages contained locally on the server. In addition, to accommodate the scenario where many pages are contained at one site, the user will be granted the ability to enter a desired page number. Thereupon, the desired page will be displayed on the screen.

• Web page authoring:
  The instructor user will also be granted a simple array of web page authoring operations: text manipulation, link and image creation, and link and image deletion.

  Link creation involves much more than just specifying the URL of a particular remote site. The instructor user will also have the ability to link internally within the site, meaning that the user can simply input the desired page number of the internal file that the link refers to. Link creation also allows the instructor user to link to multimedia files (video and audio) that have been fetched and stored locally on the server. Instead of typing in the name of the multimedia file to be linked to, the user simply selects the multimedia file from a list of available files.

  Image addition is similar to link creation in that it allows the user to select an image file (.jpg, .gif, etc.) from a list of available image files. The difference is that an image, not a text link, will be displayed on the dummy page and the resulting student page.

  Links and images are treated as objects and thus can be removed from the dummy page at the instructor user's will. In addition, more complex web-publishing features such as tables, lists, etc. will not be supported since time constraints warrant emphasis on more substantial functionality.

  It is important that the system keeps the instructor module interface as simple and as intuitive as possible, while retaining basic functionality, so that it encourages instructors to collaborate and add material to the instructional site.

• Fetch:
  An instructor user will also be given the opportunity to ftp media using our proposed system. By incorporating the ftp feature into our system, the directory structure and ftp commands are kept invisible to the instructor user. The only required elements associated with our fetch mechanism are then the username and password at the remote site, the location or ftp address of the desired file, as well as a descriptive name of the target file. It is important that the filename is descriptive since the system cannot provide any means by which the file can be previewed. Unfortunately, because of the limitations imposed by our system for this fetch feature, instructor users will not have the ability to modify or even delete files that have been stored on the server. It is the system administrator's responsibility for modification or deletion of any files stored at the site.

• Locking:
  A locking mechanism needs to be implemented to ensure consistency and reliability during web page modification stages. Essentially, no two instructor users shall be given permission to modify a web page concurrently.

• Link updating:
  Obsolete links or URL changes should be automatically updated by the system.

• Modification log:
  The time stamp at the top of every student page should follow a link to a page detailing the updates made for that particular page.

• Statistical log:
  A statistical log detailing the number of students, the pages that a particular students has accessed, as well as the features/functionality that a student utilizes should be recorded for analytical purposes by the instructor.

The International (French) Cross-Cultural Teaching Model is designed to be a semi-autonomous system. The ICTM does not require an interface with SIRSI, but does require extensive interfacing with a web server. The various interface requirements for the ICTM are as follows:

• COTS web browser interface:
  Users will need to interface with the ICTM using a COTS web browser which should support basic web browser features (printing, cutting, pasting, browsing, etc.). The browser should also support frames since both the student and instructor sites are planned to be subdivided into various frames containing various components of the ICTM (bulletin board, authoring tools, etc.) Please refer to the student site homepage or the instructor site homepage of the final prototype for a look at how frames could be utilized.

• Bulletin Board interface:
  The interface for the bulletin boards contained at both the instructor and student sites must be identical. The interface must consist of a region to enter text and a region where the user can view posted messages. The bulletin board interface must also contain a selection mechanism which would allow a user to retrieve messages posted on a particular date. The combination of the posting, viewing, and selecting interfaces is combined to form the overall bulletin board interface design and in general, the interface must be friendly and intuitive. For a look at potential interface options for the posting, viewing, and selection features, please take a look at the message writing section , the message viewing section , and/or the message selection section of the final prototype..

• Email interface:
  The email interface must be similar to other COTS email software so that a user can use this feature with little hassle on their first attempt. In other words, the email interface should only contain fields where the user can input a subject header and a message body, as well as a button to submit his/her message. Please take a look at the form emailer of the final prototype for an example interface.

• Search interface:
  The search interface should be similar in format to various popular on-line search engines such as Yahoo, Excite, etc. Minimally, the interface should contain a keyword field and a submit button. The interface should be simple and intuitive. Please take a look at the search option of the final prototype for an example interface.

• Translation interface:
  The translation interface should only consist of links to the translated pages that are stored on the server. Buttons could be substituted for a more graphical feel but the translation option of the final prototype shows all that really needs to be implemented. However, the interface between the ICTM and a translation service requires that either the COTS translation program be installed on the server or the translation provider be on-line. This is to ensure convenient accessibility by all users, otherwise, the translator must be ported to different platforms and downloaded or installed by every user of the system. The cost of the service must also be kept to a minimum. Essentially, the role of the translation provider is to accept HTML files from the ICTM system and translate these files into French and English versions, both of which are then stored (along with the original version) on the hard disk. Though the translation service has not be determined at this point, a tentative agreement has been reached with Vivigy, Inc. that would provide free on-line translation service for the ICTM system in exchange for advertising space on the ICTM student and/or instructor sites. The Vivigy, Inc. Power Translator for UNIX demo can be tested at http://www.vivigy.com/Demomain.htm and the person to contact at Vivigy is Rod Young (ryoung@vivigy.com) .

• Web page authoring/creation/selection interface:
  The web page authoring/creation/selection interface is the most critical of the interface requirements because these features are the most technically complex functions of the ICTM. The buttons for the web authoring tools (link/image addition, link/image deletion, fetch, add page, update) must be graphically intuitive (the pictures should be an accurate representation of the respective functionality) as shown by the web authoring toolbar of the final prototype. The page selection mechanism should also be graphically intuitive showing the current page number and allowing the user to click on buttons to cycle through the pages contained at the site, as shown by the page selection portion of the final prototype.

• Availability:
  One of the primary requirements of the ICTM project must be its availability to the registered students and instructors. The user base will potentially include students and instructors at remote locations such as Paris. By placing the ICTM on the internet and allowing web page modifications on the web, students and instructors can readily access student pages at the ICTM for exploration and modification.

• Performance:
  The translation of a web page should be done as soon as the page is updated. This means that when a web page is updated, it is sent to the translation provider. Thereupon, the translated versions of the web page are sent back to the ICTM server for storage and future retrieval. Because the translated versions of each web page are stored locally on the server, the translation overhead on the student user end is minimal since it simply involves following a link to the desired web page. Thus, the performance concern here is with the initial translation of newly created/updated web pages.

  The other performance concern is with the search mechanism. Because the search is restricted to just the web pages created by the instructors which are stored locally on the server, the query should be relatively fast and should return results to the user within 10 seconds.

• Usability:
  Another primary attribute of the ICTM must be its usability. Non-experienced instructors should be able to enter the instructional site and make use of all the available functionality in order to modify the student site. The user interface should be uncomplicated and intuitive enough for any user to understand; however, a link to a modest help page detailing instructions and frequently asked questions will be provided to accommodate the user.

  The bulletin board feature, furnished on both user and instructor sites, is simply a text message box with a button to submit and post the message to the proper bulletin board.

  The remaining student capabilities must also be intuitive and user friendly. Translation merely requires the user to select a link to the French, English, or original version of the web page. Likewise, the search mechanism should easy to use, allowing the user to just input the desired keyword, which subsequently returns a comprehensive, yet coherent, list of query results.

• Security:
  By implementing an authorization mechanism, non-authorized users will not be able to gain access to either the student or instructor pages. Furthermore, valid student users will strictly have access to the student pages contained at the ICTM. Student users will not be granted access to private information contained at the instructor site and have the ability tamper with the student pages. Valid instructor users, however, will have super-user privileges, able to access both the student and instructor sites.

• Reliability:
  A locking mechanism should be implemented in order to ensure reliability and consistency of web pages. Backup copies of the student web pages should also be maintained by UCS in the event of data loss.

• Maintainability:
  System maintenance should only require one system administrator to setup and enter user accounts into the username database. The system administrator should also deal with any miscellaneous system problems or errors that might occur. File/web page deletion will be handled by the system administrator by request and if the system is not implemented with a mechanism by which obsolete links are updated, the system administrator should take care of this responsibility at regular monthly intervals.

The primary evolution requirement for the ICTM is the capacity for interdepartmental usage. This would involve porting the ICTM to support other single byte and multi-byte character sets. Correspondingly, the search, translation, and on-line help should also support the department's language that the ICTM is being ported to.

Another evolution requirement is the capacity to perform queries on text contained in images, which would then eliminate the need for keyword descriptions associated with each image. JSTOR presents one intriguing possibility that could be implemented in the near future.

In all likelihood, the ICTM will not support link updating meaning that obsolete or non-existing links will not be automatically updated by the ICTM system. Instead, it will be the responsibility of the system administrator to update these obsolete links. Once technology has evolved to allow such a capability, the link updating shall remain an evolution requirement at this stage.

In addition, any evolution in hardware or web browser technology should not impact the ICTM to a significant degree since the ICTM only requires that the server hardware have a network interface card and that the browser retain its basic functionality.

3.4 Operational Concept Satisfaction

Several mainstream scenarios are detailed below addressed from three points of view: the system administrator, the student user, and the instructor user. In addition, an exception-handling scenario is included. Each scenario assumes proper validation on login.

System administrator scenarios:

• User account management scenario:
  At the outset of the course, the system administrator initially sets up a database of usernames which consists of all enrolled students and participating instructors. These usernames are acquired via email within the first few weeks of the semester. The system administrator only stores the usernames and privileges of each user into the database (the password is checked against the UCS database). For example, if the user is a student then the user will only have partial access privileges whereas an instructor user will have full access privileges.

• Link update scenario:
  A user discovers a link that is non-existent and then notifies the system administrator to update the link on the ICTM web page to reflect the change. The system administrator then modifies the web page by traditional editing methods (emacs, vi) or via the ICTM system.

• Bulletin board scenario:
  A user wishes to post a message to the bulletin board. The user enters a message into the text field and clicks on a button to submit the message. The user's message, along with the username, the date, and the time of the message are posted to the bulletin board.

• Instructor email scenario:
  A user may opt to email a message to the instructor by simply typing in his/her desired message and then submitting his/her message to the instructor. Since the email address is hardcoded into the form mailer, the student need not include the instructor's email address and will receive a carbon copy of his/her message. The instructor, to whom the email message will be sent, may also want to use this email feature. For example, if the instructor wishes to "save" or selective print a particular portion of text contained at the student site, the instructor can simply copy and paste the text into the form emailer's text field and send this text to himself/herself. Though the implementation of the form emailer should not be any different to accommodate this scenario, it is important to keep in mind that the instructor, to whom the message will be sent, will also be using this feature as well, but for different purposes.

• Translation scenario:
  A student user wishes to translate a page to another language. The student user clicks on a link for the desired language and retrieves the pre-translated page which is stored locally on the server. The translation options are then updated to reflect the student user's current status, meaning that if the user is browsing the French version of a page, the link to the French page is "off" while the links to the English and original versions are "on" or active.

• Search scenario:
  A student user wishes to perform a search on a particular keyword. The student user enters the keyword(s) into the search text field and clicks on the search button to process the query. A list of query results are then returned to the user.

• Bulletin board scenario:
  Identical to the student user bulletin board scenario, except that the instructor user bulletin board is maintained separately from the student user bulletin board.

• New web page scenario:
  An instructor user wishes to create a new web page at the ICTM. The instructor user clicks on the new page button which internally creates a new .HTML file and assigns a new page number to the page. The previous page is moved off the screen and the blank page is displayed to the user along with its assigned page number.

• Web page modification scenario:
  An instructor user wishes to modify an existing web page at the ICTM. The instructor user repeatedly clicks on the left or right arrow buttons to cycle through the existing web pages to the desired page. Modifications are then made by the user to the web page displayed on the screen. If the user wants to add a link, the user either highlights some text and clicks on the link button or just clicks on the link button which would require that the user enter the name of the link. The user then needs to specify where the link points to by entering either the URL of a remote site or the page number of a local web page. If the user wants to add an image, the user clicks on the image button which brings up a wizard/screen with a list of the available images on the server.

• Fetch scenario:
  An instructor user wishes to ftp or fetch a file from a remote site. The instructor user then clicks on the fetch button which prompts the user to enter a username and password at the remote site, the name and the ftp address of the desired file, as well as the desired local filename. If the filename or address location are incorrect, then the system will inform the user appropriately; otherwise, the file is stored on the server for future insertion into a student web page.

• Server error scenario:
  The server crashes or become unavailable which thus prevents any user from accessing the ICTM sites. This would mean that the ICTM would experience an indeterminate amount of downtime until UCS brings up the server again.

• Account error scenario:
  A user cannot login to the ICTM site even though the user is enrolled in the course. The user then notifies the instructor or system administrator. The system administrator then checks the username database and then troubleshoots the problem from that point on. Once the problem has been pinpointed, the system administrator then emails the user on the reasons for the error and how to proceed with the authentication process.

• Concurrency error scenario:
  While an instructor modifies a web page and thus secures the lock for the page, the instructor's computer crashes or he/she forgets to update and unlock the page, rendering the page unmodifiable by other users until the problem is fixed. A user emails the system administrator who then proceeds to commit the changes to that page, subsequently unlocking it, granting other users the opportunity to modify the page.

4.1 System Priorities

Assuming that this project will be assigned a five person student team working at part-time, the system capabilities are divided into three categories based on the customers' requirements and potential time constraints: essential, desirable, and optional. Each of the capabilities are further grouped into four component modules based on functional similarity: collaboration, communications, tools, and system.

Essential capabilities:

The essential capabilities are the core capabilities of the ICTM system and must be implemented prior to May 1, 1998. The essential capabilities are listed below:

Collaboration module:
• Web page creation
  
• Web page authoring
  
• Web page selection
  

Communications module:

• Bulletin board
  

Tools module:

• Search
  
• Translation
  
• Fetch
  

System module:

• Authentication
  
• Locking
  

Following the implementation of the essential capabilities and if time permits, as many desirable capabilities are to be incorporated into the system as possible. The desirable capabilities are listed below:

Collaboration module:
• NONE

Communications module:

• Instructor email
  

Tools module:

• On-line help
  

System module:

• Time stamping
  

The optional capabilities should be viewed as potential future enhancements to the system. The optional capabilities are listed below:

Collaboration module:
• NONE

Communications module:

• NONE

Tools module:

• NONE

System module:

• Modification log
  
• Statistical log
  

Using the Process Model Decision Table, the Spiral Model in conjunction with a risk-driven waterfall approach will be the primary software development processes that will be used to develop the International (French) Cross-Cultural Teaching Model. The decision to pursue the Spiral Model is shown below in table 4.2.

The most important factors that contributed to the decision to pursue the spiral process model were the growth envelope of the system, the robustness of the project, and the technology available to the system. The growth envelope of the ICTM is fairly large because the system should be able to handle large amounts of multimedia information that will be contributed to the site by a multitude of instructors. In addition, the ICTM may be expanded interdepartmentally between foreign language departments and perhaps between various universities. The ICTM can also be expanded to support a large user-base. But as the ICTM stands currently, it is focused on the curriculum of two courses within the French and Italian department at USC with a projected low user-base. The ICTM is also designed to be fairly robust. Minor errors on both the student and user ends will be gracefully handled and should not halt the system, preventing other users from continuing to explore the student or instructor sites; however, major problems such as unexpected server crashes leading to downtime are not assumed, which is why our proposed system falls short of being categorized as being highly or fully robust. Lastly, the ICTM is dependent on commercial-off-the-shelf software applications in the form of browsers, translation programs, and Java (for developmental purposes).

A risk-driven waterfall strategy will be embedded within the spiral model to accommodate the two incremental development phases of the ICTM. The first incremental release will contain the primary core (essential) capabilities of the ICTM system which is comprised of the primary functionality available to both users as well as those specific to the instructor users: web page creation, web page authoring, web page selection, a bulletin board, the form emailer, logging in, translating, and fetching multimedia files. The second incremental software release will contain the secondary core (desirable) capabilities of the ICTM which is primarily comprised of functionality that will be available at the student site: time stamping of pages, an on-line help manual, and the form emailer.

The Overall Development Strategy of the Software Development Plan (Section 2.1) goes into further detail about how the Spiral and risk-driven waterfall approaches will be used in developing, testing, and implementing the system capabilities into the ICTM.

Note that the number of components is heavily weighted in the first increment and the Detailed Schedule of Deliverables of the Software Development Plan (Section 2.2) reflects this. The first incremental development phase is scheduled to begin on roughly on February 1, 1998 and release on April 1, 1998. The second incremental development phase is scheduled to being roughly on March 16, 1998 and release on May 1, 1998.

4.3 Consistency of Priorities, Process and Resources

COCOMO II was used to analyze and determine the consistency of the priorities that were specified for the system capabilities throughout each of the LCA documents. After analyzing the COCOMO II results, it was determined that the priorities assigned to each of the ICTM system modules -- collaboration, communications, tools, and system -- was consistent.

As shown below in figure 4.3, the COCOMO II results estimated that it would most likely take 5.5 full time software personnel (FSWP) 11.6 person months to complete the entire International (French) Cross-Cultural Teaching Model system. Note that because COCOMO II does not allow a SLOC count below 2000, the system and communications modules were combined into one component module consisting of a combined 3233 SLOC. Please refer to figure 6.0a in the Appendix for the original overall ICTM SLOC estimation.

This estimation does not agree with the original estimation that this project would only require a team of five graduate students a period of four months to complete. However, we feel that this estimation is inflated for the following reasons:

1. The largest ICTM module, in terms of SLOC, is the collaboration module which has been estimated to consist of 5837.5 source lines of code. Approximately 87% of the overall SLOC count for the collaboration module involves the web page authoring portion which in itself is estimated to have a SLOC count of 5075; however, we feel that the SLOC estimation that we originally assigned to this specific component is inflated since this estimation is based on the CS577b team developing this collaboration java applet from scratch. We are under the impression that the source code for some java applet can be found on the web that will significantly reduce the SLOC (up to 50%) for the web authoring portion of the collaboration module.
2. Again, the original SLOC estimates are based on the CS577b developers coding the ICTM from scratch. But the ICTM final prototype has done a good portion of the HTML coding of the various module and assuming that the CS577b development team chooses to build their functionality on top of our prototype, this should significantly reduce the amount of coding that they will have to do.
3. There was a considerable amount of discrepancy in our original combined SLOC estimates, particularly in the web authoring and search components. Each team member then presented his reasononing for each of the individual SLOC estimates and a new set of estimations were obtained as shown in figure 6.0b in the Appendix . The discrepancies were eliminated and the overall SLOC count for the ICTM system were subsequently reduced.
4. It is a distinct possibility that the graduate students working on the ICTM project next semester can be more productive than FSWP.

Figure 4.3b below shows the adjusted COCOMO model which uses the new SLOC estimates in figure 6.0b in the Appendix and has removed the desirable and optional capabilities in order to focus on the schedule for the essential capabilities of the ICTM system.

The new COCOMO results estimated that it would most likely take 5.0 full time software personnel (FSWP) 8.2 person months to complete the essential capabilites of the ICTM system. This estimation does not take into consideration software reuse. Based on this new estimation, we still firmly believe that it will be feasible to implement the ICTM system in the alloted four month period given a team of five graduate students.

5.0 Risk Analysis

The sections below summarize and identify the top risk items associated with the proposed ICTM system. For further detailed analysis, please refer to the Software Development Plan (Section 4.1)

1. Personnel shortfalls:
   At this point, three of the four team members from the CS577a team have elected not to enroll in CS577b next semester. This means that virtually a new team of five graduate students in CS577b will be assigned to develop the ICTM posing a potential risk. Each team member's ability will vary depending on their educational backgrounds and work experiences, thus making it nearly impossible to accurately predict how the personnel will factor into the system development process. In addition, compatibility conflicts could arise between team members decreasing the overall efficiency of the team. Loss of personnel is another concern that could greatly impact the status of the project, particularly if the loss occurs during critical phases of the life cycle.

   Resolution:
   To reduce the risk of personnel shortfalls, particularly in the area of technical expertise, it is strongly suggested that each CS577b developer be proficient in the one or more of following areas:

   • Java programming
   • CGI scripting
   • HTML
   • Networking and concurrency

2. Schedule constraints:
   Schedule constraints are a major risk item since the development team is fixed to a twelve week schedule next semester and COCOMO estimates have projected that the ICTM system will take nearly 10 months to complete.

   Resolution:
   To successfully resolve this risk item next semester, the CS577b project team should adhere to the incremental development plan stated in the Software Development Plan and scrub requirements (after consulting with the customer) if necessary. More importantly, the CS577b should attempt to reuse as much code as possible especially in regards to the java applet that will serve as the collaboration module. The CS577b should also consider building on top of the prototype that the CS577a team has developed. Much of the HTML coding has already been done and the customer has expressed her satisfaction with the prototype interface.

3. Translation provider risks:
   At this point, it is unknown whether a commercial on-line translation provider exists that will reliably and accurately translate HTML documents at little to no cost for the customer. Accurately translating documents from one language to another requires knowledge of not only the language itself, but also the subtle nuances that oftentimes accompany it. Currently one translation provider has been found whose Power Translator for UNIX seems to be a viable option for a on-line translation service. However, it has been discovered that the Power Translator does a very literal translation which thus reduces the accuracy of the translation. A tentative agreement has been reached with Vivigy, Inc. that would provide free on-line translation service for the ICTM system in exchange for advertising space on the ICTM student and/or instructor sites. The Vivigy, Inc. Power Translator for UNIX demo can be tested at http://www.vivigy.com/Demomain.htm and the person to contact at Vivigy is Rod Young (ryoung@vivigy.com) . If the CS577b ICTM team cannot reach a final agreement with Vivigy, Inc. then the risk of finding a translation provider becomes very high because an alternate translation service has not been found. Again, it is very important that the CS577b ICTM team find a translation provider that is on-line since a platform specific translation COTS software application cannot feasibly be distributed to all registered users of the system.

   Resolution:
   The client has agreed to help search for a reliable on-line translator that the CS577b team can use next semester. At this point, the client has expressed her desire not to use Power Translator due to its literal translation; however, as a last resort, this may seem a viable solution which would require a warning posted somewhere on the ICTM site stating the potential loss of meaning with the translations.

   Note that the order that this risk should be resolved should be in the following order: accessibility (on-line), interface, accuracy/reliability, and cost. In other words, an on-line translator that provides service at a fixed cost should be considered over a platform specific, software package that is provided for free.

4. Server hardware risk:
   At this point, a server has not been found that will house the ICTM system. Both the Center for Excellence in Teaching and the French and Italian department do not own their own servers.

   Resolution:
   If a server has not been found by the time the ICTM system has undergone development next semester, the developers can, for the time being, develop the system on UCS servers. Once a server has been found, all of the files and documents associated with the ICTM project can then be moved over to the new server.

5. Incorrect user interface:
   The user interface is one of the single most important elements associated with the ICTM. Thus, it is unknown whether the team members assigned to this project next semester will develop an interface that accurately reflects what the customer desires.

   Resolution:
   Prototyping and incremental development

6. Gold plating:
   Gold plating is the process by which the specifications and capabilities for the proposed system are overambitious, leading to excessive functionality that may be cost ineffective and/or infeasible within the given time constraints.

   Resolution:
   Requirements scrubbing, prototyping, cost-benefit analysis, and designing to cost

7. Continuing stream of new or changing requirements:
   During the course of system development, there exists a distinct possibility that the proposed requirements may be altered or may be modified to accomodate new ones. Unfortunately, the advantages of early and frequent prototyping are offset by the risk that the customer may want to modify or add requirements to the preexisting set.

   Resolution:
   High change threshold, information hiding, and incremental development by defering changes to later increments

8. Real-time performance shortfalls:
   It is difficult to analyze the performance of the various features of the ICTM since so many variables are involved when determining the performance of a function. For instance, it is impossible to accurately determine the performance of the translation feature since it is unknown at this point what translation provider will be used.

   Resolution:
   Simulation, benchmarking, modeling, prototyping, instrumentation, and tuning

Figure 6.0a Team 16 SLOC Estimation

As shown in figure 6.0a above, there are a number of discrepancies in the SLOC estimates particularly in the web authoring and the search components. Thus, each of our team members submitted their reasoning for their respective SLOC counts and a new set of SLOC estimates were obtained as shown below in figure 6.0b below. For example, all team members, except the architect, believed that the search component of the ICTM system would involve a considerable amount of coding; however, we all agreed that since the search has been refined to a simple string-search (UNIX grep), the SLOC count should be reduced to match what the architect had originally estimated (50).

Figure 6.0b Adjusted Team 16 SLOC Estimation

Ref. OCD (Section 10.0)