CS 190 Winter 1997 Computer Science Design Project

A. Klinger 3531-H Boelter Office (3532-J Mail Slot) Tues/Thurs 8-10 AM Boelter 5514

Resource Information

Secretary: Ms. Gisele Pham, 3532-F, <gpham@cs.ucla.edu>, 310 825-1322

URL: http://www.cs.ucla.edu/csd-lanai/fweb/cs190

SEL: CS 190 Notes, Book References

Project Management

Reference: Gildersleave, T.R., Data Processing Project Management, Van Nostrand Reinhold Company, New York, 1974.

The basic idea in creating a project is to break out the different items that could be done, put priorities on them, assign each to one or more participants and establish a schedule for concluding the constituent parts of the overall job. In this one distinguishes three main things, beginning with a way to order the parts of the project. This is generally called the phase approach. The second concept is that the project team and the management structure (possibly a client) has to validate that the work done met the original need. This is generally ascertained through a series of acceptance tests. Finally, since the group as a whole is responsible for the ultimate design, all members of a project must contribute to a process of planning. The planning process determines which items are done within this project.

In addition to a list of tasks and their priorities, planning uses the dependence of some on others. This can be done via a task dependency list. Such data can be summarized by a visual chart where nodes are tasks to perform and they are joined by arrows that exhibit dependencies between tasks. Other types of visual displays are bar charts, time-lines, benchmarks and milestones, the latter three being specially useful in project management. Each of them may show an external constraint on a project.

Project work generally includes many different kinds of work. Analysis consists of determining what the system will do. This is something that often involves coming into agreement with a user. Design sometimes is used to signify just determining how the best system should be built. In other words, a point to keep in mind in doing a project is comparing your choices to alternative approaches and indicating what makes your method preferable. Distinguishing between a design and the ultimate product involves the term construction. That often refers to creating the system according to some given specifications. This concept itself builds upon different ideas implied by the overall job: project description, task description; requirements, system analysis (or user-interview report): after all these are in place it is possible to write a set of technical specifications that list quantitative measures to be met.

Problems always occur. Either they are solved/resolved or they become setback-causing. If the latter, the project can state that a solution is: a) being applied; b) suggested/recommended; or unavailable. You need not expect things to work correctly: if you hit a snag, find a way to work around it. Allow for contingencies, estimate time required for each task, constantly create documentation, list your status information via weekly progress statements and summaries of accomplishments during report period. Indicate your progress toward your long-term project goals.