Ref. OCD System Overview (Section 1.0)
2.0 List of Documents
Operational Concept Definition
System and Software Requirements Description
System and Software Architecture Definition
Software Development Plan (Life Cycle Plan)
Prototype
Feasibility Rationale
3.0 Product Rationale
Ref. OCD Rationale for New Capabilities (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. 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 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
The capability requirements for the ICTM proposed system can be divided into four categories: general capabilities, student capabilities, instructor capabilities, and optional capabilities. The general capabilities are available to both student and instructor users. The student capabilities are intended primarily for student use; however, instructors also have access to the student pages and consequently are able to make use of the student capabilities. Students, on the other hand, do not enjoy the same privileges as the instructors and therefore cannot gain access to the instructor page, nor can they make user of the instructor capabilities. The instructor capabilities are restricted for instructor use only. The optional capabilities 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:
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.
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. In addition, the ICTM indirectly interfaces with its users via web browsers. The user interfaces must be well-designed and user friendly.
The system's translation module also requires interfacing with some translation provider. The translator must be on-line to ensure accessibility by all users, otherwise, the translator must be ported to different platforms and downloaded or installed by users of the system.
3.3.3 Quality Requirements
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:
Backup copies of the student web pages should be maintained by UCS in the event of data loss.
Maintainability:
System maintenance should only require one student assistant to setup user accounts and deal with any system problems or errors that might occur. 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.
3.3.4 Evolution Requirements
The primary evolution requirements 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 and translation elements of the ICTM should also support different languages.
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.
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 possible scenarios are detailed below addressed from two points of view: the student user and the instructor user. Each scenario assumes proper validation on login.
Student user scenarios:
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. The essential capabilities are the core capabilities of the ICTM system and must be implemented prior to May 1, 1998. Following the implementation of the essential capabilities and if time permits, as many desirable capabilities are o be incorporated into the system as possible. The optional capabilities should be viewed as potential future enhancements to the system. All capabilities are to be implemented in the order specified below.
Essential capabilities:
Desirable capabilities:
Optional capabilities:
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 Cross-Cultural Teaching Model. The decision to pursue the Spiral Model is shown below in table 4.2.
| Growth envelope | Understanding of requirements | Robustness | Available technology | Architecture understanding
|
|---|
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 accomodate the two incremental development phases of the ICTM. The first incremental release will contain the primary core capabilities which is comprised of 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, logging in, and fetching multimedia files. The second incremental software release will contain the secondary core capabilities which is primarily comprised of functionality that will be available at the student site: searching, translation, time stamping of pages, and emailing the instructor.
The Sofware Development Plan 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. The first incremental release of software is scheduled for March 27, 1998 and the second for April 4, 1998.
4.3 Consistency of Priorities, Process and Resources
Ref. COCOMO model runs (N/A LCO)
5.0 Risk Analysis
Table 5.0 below summarizes and identifies the top risk items associated with the proposed system. For further detailed analysis, please refer to the Software Development Plan (Section 4.1)
| Risk item | Description | Resolution
|
Personnel shortfalls
|
The project team assigned to develop the ICTM will be comprised of five graduate students
enrolled in CS577b; however, 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.
|
Job matching and team building
|
Schedule constraints
|
Schedule constraints are a major risk item since the core and desirable capabilities are
fixed to an inflexible twelve week schedule.
|
Detailed, multisource cost and schedule estimation, design to cost,
incremental development, software reuse, and requirements scrubbing
|
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. It is
doubtful that a translation provider will be found that will translate a document with
total accuracy but it is very important that the translation provider be on-line since a
platform specific translation COTS software application cannot feasibly be distributed to
all registered users of the system. Even if an on-line translation provider does exist,
it remains to be seen whether our system interface will be compatible with the translation
provider.
|
Increase cost budget by purchasing the services of an on-line translator. 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.
|
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.
|
Prototyping and incremental development
|
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.
|
Requirements scrubbing, prototyping, cost-benefit analysis, and designing to cost
|
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.
|
High change threshold, information hiding, and incremental development by defering changes to later increments
|
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.
|
Simulation, benchmarking, modeling, prototyping, instrumentation, and tuning
| |
|---|
| ICTM home page | ICTM prototype | Back to top |