Draft Requirements 1/3/2001 (based on requirements
6/24/2000)
Basic Information
1. Stellar is intended to be a courseware system for use throughout MIT.
Architecture
1. The architecture of Stellar is a basic three-tiered architecture, with webserver,
Java servlets, and database.
2. We plan to use Oracle. We also expect to be able to use other JDBC relational
databases (e.g. mysql, hypersonic SQL, etc.)
3. We plan to use Apache with SSL. It should be possible to use other webservers,
although there is no current plan to do so.
4. We expect to use Java for implementation.
5. Design documentation is available on the web at
<http://web.mit.edu/stellar/docs>, <http://web.mit.edu/stellar/ui/demo>, and
<http://web.mit.edu/stellar/design1>.
Integration
1. There are several ways to make an addition, enhancement, or integrating another
system with stellar. First, for legacy systems such as MITSIS, is possible to
develop "translation" programs to accept external data feeds or to provide data
from stellar to legacy system. Second, there is the "loose" integration provided by
a web reference (link). Stellar will define a number of such linkable entities.
Third, it is possible to read the Stellar code and make additions or enhancements
by writing them. Note that the central MIT stellar service will not necessarily
accept all external code for operation. See also
<http://web.mit.edu/stellar/design1/interfaces.doc>
2. What APIs, libraries, interfaces, public classes, etc. are available to use in
integrating stellar with MIT infrastructure and systems? This will be determined
later (TBD).
3. What programmer documentation, tools, and training are available? We will need
to make such available (TBD)
Operation and Maintenance
1. What is the support and maintenance model? TBD
2. Where do you expect us to host the system? Currently we expect to host Stellar
on EMCC systems. With further development and use of the system, we may
want to set up independent "server farm."
3. Who will do maintenance and service of the system? At present, this will be done
through the EMCC. Again, with further growth of system use, we may hand off
this work to another group at MIT.
4. What operational support is needed? Describe both the content creation and
maintenance and the technical support needed.
Content creation within stellar can be done by faculty, TAs, or other individuals
designated as content developers. It can be done using standard tools such as
Microsoft Word, Dreamweaver, text editors, etc. with files uploaded into stellar.
TBD on maintenance and technical support needed.
Intellectual Property
1. Content ownership -- if we are using your system, where does ownership of the
content reside?
While Stellar does not impose a policy concerning ownership of content, it does
provide ways to protect content and track access. We expect that Stellar will be
used at MIT for content which has very limited access and for content with
unlimited access.
2. What protection and services for intellectual property rights does your system
offer?
First, Stellar provides relatively fine-grain content management, with the
possibility of limiting access using groups, individual user profiles, and ACLs.
The same security features that offer positive identification of individuals
(authentication through Kerberos, X.509, and user name/password) help to protect
the information from unauthorized access.
While Stellar does not currently expect to build services for IP rights
management, we believe the arc approach would make such services
comparatively easy to construct and integrate.
Features
What features or functions do you provide in the following categories: (some examples
are included for illustration only)
1.
2.
3.
4.
Registration: class membership list, authentication, authorization
Administration: gradebook, student records
Navigation: calendar, syllabus, table of contents, index, portal, search
Content Management: formats (HTML, video, audio, PowerPoint, etc.), Metatags,
efficient storage and retrieval
5. Collaboration: threaded discussion, chat, instant messaging, shared whiteboard,
etc.
6. Query and Evaluation: quiz, test, examination, survey, assessment, problem sets,
etc.
7. Set up: file and directory, database, access control lists, etc. initialization
8. Content Creation: tools for content creation, upload, transformation, metatagging,
crosslinking, editing, etc.
9. Renewal: archiving, semester rollover, etc.
10. Other (Please describe the areas):
Please see the specs and <http://web.mit.edu/stellar/design1/> for further details.
However, this is the basic architecture and components of Stellar.
We do not currently plan to implement a portal, although we are expecting to work
with the Jasig portal and with other portals in the near term.
Costs
Please explain the pricing of your system. For this estimate, assume that we are setting up
a single server, with 1,000 students, for three years operation. Include the initial system
cost, any per-user fees you may charge, yearly charges if any, etc.
Initial cost:
Per-User charges:
Yearly charges:
Other fees or charges?
Description:
Estimated three-year total cost:
Provide any other terms, conditions, or descriptions of pricing which may be relevant to
evaluation of your system:
TBD
Schedule
What is a typical "rollout" plan? Describe the process. (If you have an actual rollout plan
available for review, this is preferable.)
TBD
User Support
1. What user support is available in your system, help desk, etc.? Describe both
online, oncall, and any other methods you may provide.
2. What user documentation is available for your system? Please indicate how a
copy can be made available for EMCC review.
3. What training is available for your system? Please include faculty, teaching staff,
student, technical staff, help desk, and any other training that may be available.
TBD
Pedagogical Models
Describe the main pedagogical models supported by your system.
TBD (see Phil Long for current status)
Risks
What are the main risks in using your system? What steps or measures do you take to
help us avoid or lessen these risks?
TBD
Description and Key Points
What are the key points of your system? How would you describe it?
See the Stellar One-Pager.
Requirements
Stellar is designed with the following requirements in mind:
1. Scalable: designed and tested for large growth (1,000 courses, 10,000 students,
1,000 faculty)
2. Scalable: able to be used with small classes (10 persons) without unnecessary
overhead
3. Sustainable: designed for service and maintenance largely by non-technical
course administrators
4. Sustainable: production and development systems clearly separated
5. Security: strong authentication (certificate-based, kerberos, etc.)
6. Security: single login
7. Security: Strong authorization (control over access to resources, functions, and
privileges)
8. Security: copyright and intellectual property protection (future version)
9. Security: digital signatures or other methods of identifying who produced specific
information (future version)
10. Privacy: individual notification and control of personal information
11. Privacy: individual identification removed as soon as feasible
12. Privacy: methods for anonymity, aliasing, or nicknames
13. Privacy: methods for encryption of personal information where desirable (future
version)
14. Privacy: methods for verifying who has access to information
15. Stability: continuous operation (24x7)
16. Stability: minimal downtime (i.e., designed for hot standby, backups, etc.? Can
the system be used with multiple servers?)
17. Usability: designed to help the user accomplish what he or she wants to
accomplish, quickly and easily, with a miinimum of frustration
18. Usability: limited use of technical terminology
19. Open interfaces: provides ways to create and manage interfaces to external
systems
20. Accessibility: provides support for multiple alternate formats, e.g. video,
slideshow, transcript
21. Accessibility: designed for use with screen readers and plain text browsers
22. Accessibility: provides tools for easy preparation and integration of text
transcripts, alt text tags, etc.
23. Accessibility: provides large font options
24. Accessibility: provides closed captioning where feasible
25. Logging: provides built-in methods for logging in various levels of detail
26. Customizable "look and feel"
27. Sharable content: ability to reuse and share content both within and outside the
system
28. Portal integration: ability to provide headlines, summaries, and other information
"up" to portal systems using standardized open interfaces
29. Flexible graphics: ability to use and modify graphics, including inherited styles
and other combinations
30. Navigational design: provides user with intuitive, clear navigational tools to
identify where they are and where they want to go next
31. Continuing Improvement: ability to incorporate additional content, structure, and
linkages as needed
32. Continuing Improvement: ability to incorporate new media