| Weeks | |
|---|---|
| 1-3 | Form project teams and decide on a goal |
| 4-5 | Requirements analysis |
| 6-7 | Data model design and functional prototype |
| 8-11 | Implementation and data importation |
| 12-14 | Evaluation and iterative refinement |
| 15 | Class presentation and written report |
Idea rally: Each member of the class will get up and give a 90 second pitch on their idea and why they think it is both interesting and feasible and at least one strength that they can bring to project team. Presenters may pre-load one slide for display during their pitch, and they should prepare one sheet of paper with their name, photo, contact information, and a sketch of the idea that interested students can pick up after their talk (bring 22 copies). The pitches will be rigidly timed so that we have enough time at the end for potential project teams to meet together briefly afterwards. This is what is known as an "elevator pitch." Focus your limited time on the points that you believe will most impress the people you are trying to reach -- your classmates. This presentation is not graded -- its only purpose is to help form project teams around good ideas.
Forming a Team: By far the biggest mistake that people make when forming project teams is to select people that are like them, with similar strengths and similar weaknesses. Experience shows that while it is important that team members have enough in common to be able to work together effectively, the diversity of skills, abilities, and interests within a team is equally important, but often overlooked at the outset. I cannot emphasize this strongly enough -- you should be looking for someone with whom you share common interests, but not common weaknesses! Among the issues to consider are preferences for leading or following, ability to meet deadlines, and design skills, technical skills, writing skills, and, of course, good ideas. The most common mistake people make when forming project teams is to focus too narrowly on technical skills. You can, and should, learn technical skills in this class. Many of the other types of skills are equally important, and less likely to change much over the course of the semester. So use the discussion period after the idea rally to explore combinations that achieve a balance between diversity and cohesiveness. Individual projects will not be permitted (nor will teams of 4 or more), so put your best foot forward and get out there and meet people!
Roles: Every project team will have two sets of roles, one set focused on specialized implementation skills and one set for broader issues. At least the following three broader issues must be assigned: Project manager (responsible for managing the client relationship and the division of labor, and for monitoring and re-planning as necessary), architect (responsible for overall system architecture and allocation of functionality to individual components, including any necessary reallocation), and tester (responsible for design of system-level testing strategies, management of the system-level testing process, and providing feedback to implementers). At least the following three implementation roles must be assigned: Database administrator, Server-side programmer (e.g., PHP), Client-side programmer (e.g., JavaScript). People may be assigned more than one implementation role (e.g., everyone might do some part of the server-side programming), but the broader system-wide roles should be uniquely assigned to single individuals. Ajax teams may also need an XML implementer and a data architect (helping the system architect).
Requirements Analysis: Your next step will be to perform requirements analysis. We'll talk in class and have readings about how to do this. You'll need to work with your client at least twice during this period, once to begin the process of learning what they really need, and once to get their reaction to your initial ideas. The product of this effort will be a written report. Note that you need not, and should not, get feedback on the report before proceeding to the next step -- the report you turn in is designed to give you experience with the requirements analysis process. It will not be graded at this point (although you will receive comments on it, and if it is not turned in on time that fact will be graded!). This report, modified appropriately as you go, will become a chapter in your final report, which will be graded.
Prototyping: Once you have an initial understanding of the requirements worked out, you'll be ready to build a working prototype. This is NOT your final project -- rather, it is something that is implemented only to the degree needed to serve as a basis for further discussions with your client about things that were not easy to see when the design existed only on paper. Usually, there is no real data in the system at this point, but the interface looks something like what you really intend to build and you have a script to walk the client through a realistic scenario with some sample data that you have hardwired in. The expected outcome of this process is a greatly improved understanding of what is really needed. A week later, you will demonstrate your prototype to the class (in the same for the client saw it) and describe what you have learned to date about the real requirements and how you learned it. Five minutes will be available to each team for their presentation, of which one minute should be reserved for questions. We'll do these presentations at the end of class, which should be an incentive to finish each one on time :-).
Implementation: The next step is implementation. We will have been studying the implementation process and using structured assignments to gain experience with the techniques, so by this point in the semester you should be ready to start building things that actually work the way you envision. You'll note that only three weeks is allocated to this stage of your work -- plan accordingly, and don't try to solve all the world's problems with one class project. On the other hand, do try to do something worthwhile. If you want more time for this stage, you can accelerate the earlier stages, and you can work over Spring Break. But you cannot extend your implementation effort past the end of this phase because the biggest mistake that people make when building complex systems is to invest too much time in implementation and too little in testing and refinement. Your project need not be great at the end of this phase, but it must at least be working and doing what the client expected. You'll again talk to the client, and each project team will have 15 minutes to lead a discussion about what they are learning about implementation. That moderated discussion will be graded, and it will occur on one occasion during either this phase or the next. We'll also have a fast paced discussion on the mailing list during this time to help each other sort out problems as we encounter them, and if there is interest in doing so we might use some class time for one-on-one code walkthroughs in which we pair people with one or more people from another team to talk about some thorny problem that they are having.
Evaluation: The final stage in the actual development of your project will focus on evaluation and iterative refinement. Only about half as much time is allocated to this as would typically be needed in a real work setting in which a stable application must be delivered, so you may well not get quite that far. You should, however, evaluate what you have developed, correct any functionality deficiencies, and do the best you can to correct whatever usability deficiencies you discover. The end result of this will be delivered to your client and demonstrated by you to the class. Each group will have 15 minutes for their final in-class presentation, including time for questions. This presentation should address your goals, what you actually built, the results of your evaluation and how you addressed them, and what you learned along the way about the process. This presentation and the written report addressing the same topics are graded.
Project Report: Written project reports are due 5 days after the in-class presentation so that feedback received during your presentation can be incorporated. The report should be approximately 25 pages, with (at least) sections describing (1) the problem being addressed and its importance, (2) the data source(s) and characteristics, (3) the design of the system (architecture, data model, and Web interface), (4) evaluation results, and (5) lessons learned about the process.
Be Careful What You Promise: If you actually intend to deliver a stable application to your client for operational use, you should plan to spend some time after the end of the course on cleaning up any remaining problems and, if necessary, re-hosting your software in their environment. Many organizations have standards governing the development of software and services that you will not be in a position to comply with as you are learning in an academic setting, so you need not actually deploy what you have built to do well in this course. In many cases, it the right approach when first discussing your project with a client is to promise to work out the ideas and build a demonstration system that they can use to decide whether to invest in a full implementation effort. In other cases (e.g., small nonprofit organizations that lack resources for system development), you may find that your client would actually consider using your results as-is, particularly if you have an interest in a continuing relationship with the organization. The key is not to over-promise, but to deliver something that the client will value in exchange for the time that they invest. Often, a well implemented prototype is the sweet spot between what they will want and what you can realistically promise to deliver.
Managing Your Time: Students should expect to spend an average of 4 hours each outside of class on their projects during the first 7 weeks and an average of 9 hours each per week outside of class for the last 8 weeks, for a total of 100 hours per person. Note that these numbers equate to "average" performance, which typically equates to a grade of around B+ in my grading. Students expecting higher grades will need to work harder or work smarter. You should not just tackle the problems you encounter with brute force effort. Rather, you should seek to learn different ways to attack problems, you should form teams with a diversity of skills and perspectives (hard to overemphasize that one!), and you should turn to your classmates for help with you get stuck (and help them out when they ask!). Projects are similar to reality in this sense -- working smart will ultimately pay off because we all have only 24 hours in the day and just working harder quickly runs into practical limits.