Introduction // The assignment // Some issues // Some pointers and suggestions
As you might have read in the Tech (V116.2, 2/9/96, "Re-engineering teams target student service processes"), MIT student services are next on the list for re-engineering. A recent management fad which is sweeping the nation's corporations as well as MIT, re-engineering aims to save money and improve services by simplifying administrative processes, like payroll, acquisitions, and purchase orders--or like adding and dropping classes, registering, and submitting grades. Re-engineering rethinks a process from the ground up, making it serve the community faster, easier, and better.
It sounds like a tall order, so who better to tackle it then 6.033 students? The MIT Financial and Academic Services Transition Team (the FAST team) is in charge of re-engineering student services, and they need your help. Specifically, they want you to work on the services listed below. Currently they're taken care of by a big mess of different forms, involving many different campus offices; the FAST team wants you to rethink them and integrate them into the MIT computing environment.
Students and faculty currently find that they spend way too much time filling out these forms, especially on and around registration day. The FAST team wants to make them quicker and easier to fill out, but make them even more secure and reliable than they are now. Here are the goals they list for student service re-engineering:
The FAST team has finished a preliminary design, but the design isn't really fleshed out, and implementation work isn't scheduled to begin until after May. The team is very interested in your projects! We plan to forward the best ones to them. In the past, 6.033 design projects have made impact on the MIT community, and your design project could have direct influence on how these processes will be automated!
First, this is a team project, so form a team of 3 people where everyone has the same recitation instructor. Please email your recitation instructor before Thursday, April 18 with the names and email addresses of your team members. Then get to work! Your report is due in recitation on Thursday, May 2.
Your team's job is to write a 10 to 12-page report that describes the design of a system that supports electronic student services, specifically the 9 services listed above. You must analyze the services that exist now and decide what it means to implement them electronically, and how you can do it. All the services must be provided in a secure and reliable way while maintaining users' privacy.
Describe the protocols used by your system, the means of privacy and authentication, and the user interface(s) your system presents. Explain how your design addresses reliability issues (high availability of service, durability and integrity of data, etc.). Evaluate your design from a technical standpoint. You should also assess the social impact of your design.
Phrase the goals and design of your team's project in 6.033 terminology and use 6.033 design approaches and techniques that were discussed in lectures and recitations.
Your intended audience is Professor Marty Schlecht, the head of the FAST team. You may assume he has taken 6.033 in the past, but is not completely up to date on the developments of the last 5 years. In addition, he knows all the high-level goals of the project, but probably hasn't had the time to study all the technical and social aspects of reengineering student services. It is your team's job to give a him a good, coherent, self-contained, well-written proposal for a design, including an evaluation of the benefits and disadvantages.
It is crucial that you provide enough detail for Professor Schlecht to evaluate the real-world feasibility of your design. To this end, your report should include at least one specific example: Describe exactly what happens when a student adds a class (which currently requires signatures from the student, her advisor, and the instructor of the class she is adding) using your system.
You might want to think about these issues while developing your design. This is by no means an exhaustive list; it will just get you started. Realize that some of these problems may be better addressed by non-electronic means: don't design only the computerized part of your system!
The FAST team's design suggestions, and what they've learned about student services, are available online at http://web.mit.edu/studentserve/www/. Most of the documents available there are in the form of very high-level overheads in JPEG format. We don't suggest that you spend too much time concentrating on the slides. They are very far from an implementation. Also, feel free to change their design however you see fit.
Several of these services are available on-line now. The Student Information System (or SIS; "add sis; sis" on Athena) allows access to students' class schedules and grades, lets students change their address and phone information, and provides a primitive degree audit. (SIS uses a second Kerberos password to further protect grade information, since people often share their normal passwords; the method SIS uses to ensure the initial security of this second password is worth looking at.) The Registrar's Office online (http://registrar.mit.edu/) has some other services, including another, friendlier class schedule interface (although it doesn't actually access your real schedule data, you have to provide it yourself). Use these systems to think about different ways to provide information to the user. You don't have to stay compatible with either of them.
Likewise, don't just implement the paper forms that exist now. Think through the processes behind the forms. Maybe you can simplify several forms into one, or get rid of the need for one of them--or all of them!--altogether.
Make sure you understand the real reason for each form. For instance, you might think that forcing your advisor to sign the Add/Drop form is a waste of time. But there's a good reason for this: it forces you to meet with your advisor before making big decisions. Maybe you can figure out a better way to do this, or argue why it's not necessary.
You may find it helpful to separate the design into two parts: the design of a lower-level, generic system which could support all the specific services we require, and designing the specific services using that generic system. Such a generic system would be more generally useful as well.
Some of the more important slides from the FAST team are included with this handout, along with the text of a recent Tech Talk article (V40.25, 4/3/96) on student service re-engineering.
Top // 6.033 home // 6.033 Handout 22, issued 4/11/96