In past Document Engineering courses some of the assignments were done in teams, but there has never been a team project. There simply wasn't enough time. But because the XML Foundations topics were excised from the course, now there is.
The differences between a group project and a group assignment are in continuity and scale. You will still have some individual assignments during the second half of the semester to ensure that you develop some proficiency in all the core Document Engineering skills, but these individual assignments (as you've seen) tend to be narrowly scoped by me, cover a range of domains (SportsML, Residency, Course Registration), and not that demanding in time. Your team project will be in a domain chosen and scoped by YOU and the separate phases will be more thorough and rigorous than the assignments you do as individuals.
These instructions are incomplete; they'll get more precise once we see what kinds of projects people want to do. Since we've never done this before I don't think it makes sense to get too specific without seeing what you want to do. We'll negotiate a project that balances my objectives with yours.
I envisioned this team project as a mechanism by which first year SIMS students could "incubate" a project that would develop into the MIMS project for their second year. But this isn't a requirement. It is vastly more important that you do a project that interests you.
You can choose just about anything that involves a document-intensive context; this can be a transactional domain like the event calendar or syllabus projects that you are all pretty familiar with, or it can be a narrative/publication domain. It can be an effort to automate and improve some existing processes or it can design entirely new ones. The biggest challenge is going to be pick something in which you can make meaningful progress in six or seven weeks.
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.
Your team must have at least two members and no more than four.
There are four project milestones:
30 March - Turn in a short project description. This needs to include a Business Domain View worksheet (like Figure 9-3) and a list of project members. You also need to include a partial list of potential document types or information sources (including the names or roles of at least two three people) that you expect can provide more detailed requirements.
11 April - Team Project Review 1 (Requirements, Inventory, Business Processes). Each team will present and turn in its work to date, and that should include some prioritized requirements, a completed document inventory and interviews with at least two of your animate sources, and some initial business process models (Business Process Use Case Worksheets like Figure 9-4c and some graphical representations of the collaborations). You should try to conduct one of the interviews as soon as possible and one of them after you've done some document analysis and process modeling.
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.
20 April - Team Project Review 2 (Document Analysis and Modeling). Each team will present its harvesting and consolidation work to identify the semantic components of its models. You probably have some sense of these from having read Chapter 7, and these activities and artifacts are described in detail in Chapter 12, which is the assigned reading for March 30. It would be very helpful to have your two (or more) interviewees involved in the consolidation, or at least have them review your work.
8 May - Team Project Review 3 (Schemas and/or Project Planning). Each team will present 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 ready the team to develop 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 another way, your project should emphasize Chapter 15 ("Implementing Models in Applications") topics and perspectives or Chapter 16 ("Management and Strategy") ones.