Mon Feb 14 12:34:01 EST 2000
The intent is that this will not be just hacking, but a serious attempt to simulate some aspects of reality: choosing something suitable to work on, planning how to get it together, designing it before building it (though allowing for the inevitable changes of direction as you learn), building it in stages, testing it thoroughly, and documenting and presenting the result, all as part of a small team. If you do it well, this should be something that you can show with pride to friends and prospective employers.
The project will involve many of the issues of software engineering as they occur in small, multi-person real-world projects. Some of this material will be discussed in class, and some will be found in assigned readings.
The considerations affecting the form of the project are:
Other places to look for inspiration or counter-examples include Linux projects and GNU, notably GUIDE and DDD. Suggestions for additions to this list are welcome.
The basic part of the assignment is to create a bare-bones IDE, using whatever combination of existing tools and new code is necessary. The functionality that you must provide includes the following, with obvious extensions in a smaller font. (I'm picturing an interface for a conventional compiled language like C, C++ or Java here; if you have something else in mind, some details will be different.)
The interface provides menus for file access, setting parameters, compilation, saving and restoring state, and so on.
Error messages from compilation are presented in a form that makes it easy to go immediately to the offending part of the program. Some syntax errors like unbalanced parentheses might be noted before compilation.
Depending on the language and the environment, you might also provide access to a debugger. For example, gdb does not seem to have a simple graphical interface; a simple interface might be a contribution. Other tools that support editing or compilation could include access to a source code control system like RCS or CVS, an interactive version of diff, program analysis tools, an interface to make, and so on.
You can choose to support any reasonable language or languages, not restricted to the usual suspects; targets might include Python, AMPL, ML, or MMIX.
You can choose any reasonable target and implementation environments, for example, developing code on Unix for a Palm Pilot.
You can invent new widgets or controls that do a better job than the existing ones provided in Java, Tcl/Tk, VB, etc.
You can invent a new language if you have a suitable one in mind.
An IDE can be structured in at least two different ways. One possibility is a standalone program like Visual Studio, a system (conceptually a single program) that runs on the same machine as the compiler and creates programs for that environment. There is no good version of such a tool on Unix that I know of, so that's an obvious target. If you choose this path, you might build the graphical part in Java or Tcl/Tk, which are portable between Unix and Windows. If your IDE is to run only on Windows, Visual Basic or Visual C++ might be chosen instead. (Warning: the latter has a steep learning curve.)
Another possibility is a browser interface, so the compiler and runtime environment could be on separate machines from the interface. The interface itself might be HTML forms (and Javascript), or a Java applet, or some other plug-in. The server part could be Perl or C or C++ or Java, and could be done with cgi-bin code or perhaps with socket connections. I haven't seen a browser interface for a mainstream programming language, but it might be a good example of a client-server application even if client and server run on the same machine.
I have attempted to make this as open-ended as possible. Once the core functionality is in place and working, the sky is the limit: this is your chance to invent something new, or to do something better than others do. You might think of this as practice for some new e-business or e-service, the sort of e-thing that has made some of your predecessors here (like Jeff Bezos or Phil Goldman) into zillionaires. Of course if it's a really good idea and you sell out to Microsoft or do an IPO by the end of the semester, it's an automatic A+.
But you have only half a semester, so you can't get too carried away. Part of the assignment is to plan exactly what you are going to create, what each team member will be responsible for, what interfaces you will require between components so independently-created pieces will fit together. What schedule will you follow? How can you work on different parts in parallel? How will you ensure, if your time estimates are too optimistic (as they inevitably will be), that you have a working subset, rather than a non-working collection of partially completed pieces? How will you convince skeptical TA's and instructor that you are making progress, not just writing code?
Since the project will involve multiple people, a significant part of the task is to divide the work into reasonable pieces, with planned interfaces. Each of these components must be a separate entity, which can be implemented and tested separately. But you will have to think carefully about the interfaces between them. So that each person contributes equitably, it is also necessary to be explicit about the roles of each person on the team. Each person must write a reasonable fraction of the code for the system, no matter what other role they play.
The project will represent about 60 percent of the course grade. All members of a team will get the same grade (with the potential for a small correction factor assigned anonymously by other team members), so you must make sure that you all agree on who will do what, by when, and to what standard.
Here are some things you should start thinking about now; this will list be augmented over the next few weeks, and we will do a fair amount of talking about it in class as well.
The following is subject to change in detail but the spirit is right. Take note.
Since the project involves more than half a semester, it is possible to develop a significant piece of software. At the same time, serious planning and steady work will be required for your project to be completed on time. To encourage planning and organization, the project will have several deadlines that will be strictly enforced. [Some of the dates near the end may have to be shifted a bit; there will be adequate warning.] Fengyun, Matthias, Erich and Chi will each be responsible for primary supervision of 6-8 teams; Rob and I will act as backup and second-level management.
We will also try to follow good software engineering practice as much as possible; in particular, this will mean using checklists and other planning forms that help organize and monitor activity. I will lean heavily on tools by Steve McConnell.
March 2000 S M Tu W Th F S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 April 2000 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 May 2000 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Grading for the project will be based on a number of criteria, including
There will be more information as we go along, to flesh out or clarify some of the sketchy parts here. There will also be class lectures on some of the UI building tools, and if necessary we can have a few Monday evening sessions on those as well.
You are encouraged to ask questions that will help clarify things for everyone. This is by far the largest class for which I have tried to run a project, so there will undoubtedly be screwups. I apologize for those in advance, but of course they too will be a simulation of reality...