Author(s):
Bob Glushko
glushko@sims.berkeley.edu
Course: Document Engineering and Information Architecture (INFO 243)
Date: 7 March 2007
Title: Assignment 5: Course Project
This assignment kicks off your course project. It describes five deliverables/milestones. You'll get feedback on all of them, but only the final ones (final report and presentation) are explicitly graded.
The differences between a course project and the other assignments this semester are in continuity and scale. You will have additional individual assignments in March and April to ensure that you develop some proficiency in all the core Document Engineering skills. Your course project will be in a domain chosen and scoped by YOU, will be done in teams rather than alone, and the separate phases should be more thorough and rigorous than the assignments you do as individuals.
These instructions are necessarily incomplete. Because I don't believe that every project can follow the same cookie-cutter template, it is necessary that we view your project requirements and deliverables as a negotiation. We'll jointly figure out a project that balances my objectives with yours.
I envisioned this course project as a mechanism by which first year I-school students could "incubate" a project that would develop into the MIMS project for their second year. It could also be a way for second year students to add an analysis and modeling dimension to the MIMS project they've already got underway. But doing either of these is not required. It is vastly more important that you do a project that interests you and that is tractable.
You can choose just about anything that involves some information and process analysis; this can be a transactional domain like the Sylvia project that produced the course syllabus viewer you use all the time, or it can be in a more narrative/publication domain. It can be an effort to automate and improve some existing processes or it can design entirely new ones.
Expected Level of Effort
The course project is worth 40% of your course grade, which makes it equivalent to four assignments in the amount of work (per person) that it should require. You will probably end up doing more work than this, especially if you choose a project tied to a potential or existing MIMS project. The biggest challenge is going to be pick something in which you can do something meaningful in a little less than two months, because you want to be able to package your work for your resume and professional portfolio.
To some extent you will decide what "meaningful progress" is, or put another way, where you want to be in early May when every team declares victory according to its own rules. That's why it is essential that I have a clear negotiated understanding of what you hope to accomplish.
Project Teams
Your team should have at least two members and no more than four.
STARTING NOW! Look around you in the world, or find some "Document Engineering in the News" stories, to get some inspiration. Are there other course projects you are doing that would be enhanced by more systematic analysis and modeling of the information and processes in the domain? Are there paper forms for some business process that you repeatedly fill out that should be re-engineered and automated? We've read many case studies and you know how to use the D-O-C-U-M-E-N-T checklist to identify promising domains for a project. But if you're stuck, come talk to me and we'll brainstorm some ideas and turn something into a project.
Describe the motivation or context for your project and a list of project members. You also should include a partial list of potential document types or information sources (people, articles, whatever) that you expect can provide more detailed requirements. I will give you feedback on your proposal before the end of this week (before spring break starts).
Each team will make a brief presentation (probably 5-10 minutes) of its work to date, which might include some prioritized requirements, some review of articles, some initial process models, or interviews with at least one "animate" sources.
At this point you will all have done individual assignments in gathering requirements, identifying information sources, and business process analysis. You should be able to create some modeling artifacts that are appropriate to your project, and these should be presented and turned in as part of your status report.
The length of this presentation will be determined when we know now many teams have formed. Class presentations will enable all of us to contribute to making each project successful.
Each team will present the results of some additional document engineering activity appropriate to its negotiated goals. This might be some harvesting and consolidation work to identify the semantic components of its models. (By this time you will all have done some of this in an individual assignments.)
Each team will turn in its final work products. What these are depends on the team's goals, but I envision two possibilities that are not necessarily exclusive. One goal might be to encode the document and possibly the process models as XML schemas, which would be the basis for subsequent implementation of an application prototype. An alternative goal would be to write a project plan / business case that discusses the organizational and technological considerations and capabilities that will shape the application's development and deployment.
Put in the language of the Document Engineering textbook, your project might emphasize Chapter 15 ("Implementing Models in Applications") topics and perspectives or Chapter 16 ("Management and Strategy") ones.
In any case, the final set of deliverables that you will turn in must (a) be negotiated with me by April 27 and (b) be well-documented enough so that someone else trained in document engineering or systems design could understand your project and resume work on it without much loss in continuity.