COS 333: Project Description 1

CS333 Project Preliminary Description

Mon Feb 14 12:34:01 EST 2000

Overview

The CS333 project is an opportunity (that you can't refuse) to work on a task larger and more elaborate than any of the assignments: design and write a significant piece of software, working in groups of 3 or 4 people.

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:

All projects have to be fundamentally similar: given the wide range of experience levels in the class, and the sheer number of people involved, it is infeasible for the instructor and TA's to manage 25 or 30 projects, and to grade them fairly and uniformly, unless there is considerable common ground.
At the same time, the basic project should leave plenty of room for people with interesting ideas to try them out, and freedom to use a broad spectrum of languages and tools.
It should be relevant to the general themes and topics of the course, which are programming techniques, languages, tools, and interfaces; it should not stray too far into topics better covered in other courses, like compilers, graphics, databases, networking, e-commerce and games.
It should break down naturally into a few components so it can be done in teams of 3 or 4 people, and into stages so that progress can be monitored.
It should be of some intrinsic interest and potential utility.

Project Definition

This is over-constrained, of course, but we have to do something. Accordingly, the basic project will be to build

an "integrated development environment" or IDE for your favorite programming language(s).

Such environments all do the same basic job: enable the user to create code, edit, compile, correct errors, and ultimately run a program. Microsoft Visual Studio is a big and elaborate example; though whatever you do will of necessity be far smaller, with some thought and judicious selection of features, you might provide for individual casual programmers half the value of Visual Studio with 0.1% of the code (and have something that runs on Unix and Linux as well).

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.)

User interface: This is what the user sees: a graphical interface that supports creation of new code, import of old code, editing of code, searching with regular expressions over parts or the whole. Multiple code windows should probably be supported, as should some kind of browsing. You must provide some editing capability, though you could also provide a way for users to edit with their own favorite editor and have changes observed and integrated. Editing could know a lot about the language, so it could provide syntax help and completion, and selective display or concealment of hierarchy.
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.
Compilation: You have to gather up the components of the program and send them to the appropriate compiler or other process, retrieve any status return and error messages, and report those to the user in a convenient form. In most cases you will have to provide a way to run the resulting program.
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.
Persistent workspace: Your IDE must keep track of the state of the program being developed, recording it when the IDE shuts down and restoring it when restarted. It must allow for more than one workspace, though not simultaneously.

Some Options:

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.

Things to Think About

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.

How big a task are you proposing to take on? It should be big enough to justify spending half a semester on it, but not so big that it's unrealistic.
What will you learn from it? It's good to try something that will force you to learn something new, like a language or a tool or a system, but you don't want to take on too many new things all at once.
What are the components or pieces going to be? How will you organize your project into stages so that you can stop at any point with something complete accomplished? You don't want to do something that requires that everything be finished before anything works -- "big bang" projects are a bad idea.
How will you divide the work among the members of the team? This is partly personalities and partly interests and aptitudes. Some people are better coders, others write better, others plan ahead, others work well under last-minute pressure. Some take charge naturally; others are happier with a defined task set by someone else. Try to organize yourselves to match the work to the people, and try to have a balanced group -- a team of superprogrammers can have a harder time than a team of mere mortals who work together effectively.

Schedule

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

March 8: Your team must have been formed, and you must have sketched out what you expect to accomplish in your project, and how. Each team must submit a brief (1-2 page) description of their project, along with a list of the people involved and their anticipated roles. If you need help finding partners, use the newsgroup.

March 24: By this date, each group must meet with their assigned TA to go over their projects in more detail, to describe their schedule, the components and interfaces, and the allocation of people to tasks. It is highly desirable to plan a sequence of stages such that each represents a working system; if your schedule proves too optimistic, this gives you a fallback that you can still demonstrate. You should bring a draft of your plan to the meeting, and hand in a final plan by this date.

April 7: Prototype. By this date, you should have a bare-bones prototype that shows approximately what you are trying to do, and what your system will look like. It need not do much, but it must do some minimal part of the job.

April 21: Alpha test. By this date, you must demonstrate an "almost working" version of the core functionality of your project. "Core" means the ability to create, edit, compile, see messages, edit, and run. "Almost working" means that wizards (you) can help experienced programmers (us) to use the system. Ideally, since this is a user-interface project, the use should be obvious, but some hand-holding is permitted. Your code may crash and need restarting. But you must be able to convince us that your project can be completed by the deadline.

April 28: Beta test. Your code should largely work, all intended features should be installed and working, no major component should be incomplete. A determined sadist might be able to break your system, but a casual experimenter should not. Drafts of written material should be done.

May 3-5: Demo days. Each group will give a brief (20-25 minute) quasi-public presentation of their work; other groups are strongly encouraged to attend, for instruction and moral support. A one-page marketing blurb and a web page must be available for interested users. I would also like to encourage real use by naive users: your classmates on other teams. You must attempt to use some of the systems written by others and see how well they work. Depending on how projects shape up, this may be done by area of interest.

May 9: Dean's date. Everything must be done and handed in by 5PM on this date, without exception. Final submission has to include a man page, an internals document describing the implementation, and a report on how the project and the team worked out and what was learned.

Grading

Grading for the project will be based on a number of criteria, including

planning: how careful, realistic and thoughtful your plan is.
functionality: successful design and implementation of the basic task.
extensions: sufficiently challenging or innovative to be interesting, yet simple enough to be feasible.
implementation: clean, working code is important, and will be a significant factor in your grade.
engineering: how well your project adheres to the important ideas of the course, like testing, portability, comparative efficiency, etc.
documentation: marketing blurb, web page, business plan, lessons learned: a good working description of the project and its implementation.

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...