In this class we start a set of projects. They run to the end of this course, and then into CSci375. By the end of this course you should have a description of a piece of software that will be designed (in detail) in CS375.

Note -- each iteration in your CS372 project is an incomplete iteration in the sense that no software is developed or tested. This is because (1) this course is about what is done before software is developed, and so (2) this course has no assigned lab time etc.

How ever you will be expected to go back and correct errors and improve your documents at the start of each iteration. No document/artifact is ever finished...

Process

1. Brainstorm: What kind of system would you like to develop?
2. Review and create short list of projects.
3. You are encouraged to do project work in groups of no more than two to five (2..5) people.
4. Start to develop a Project Scope document for each project on short list. (one per team!).

Deliverable

A draft (unbound) "Preliminary Project Scope".

Document -- Project scope

1. Cover page
   
   1. Introduction: Who is on the team
   2. Executive Summary: one paragraph!
   
   
2. Background - Problem, Opportunity, Threat, Risk, etc.
3. A Problem Map showing
   Table

   Need/Problem	Cause	Consequence	Proposal

   
   (Close Table)
   
4. Objectives.
5. Benefits to enterpise -- why should we do it?
6. Description -- Include a Context DFD of either the existing or the new system. [ a4.html#Drawing DFDs ] This should show a single process -- your system surrounded by the external entities that send it data and get data from it. Each data flow should be named. No internal details allowed -- they come later. Here is an example:

Give me hardcopy because hardcopy can be read 3 times faster than softcopy. It is also cheap and easy for me to mark it up with advice and corrections.

It should be readable and in good English. It shouldn't need clever layouts, figures, fonts, .... Keep It Simple. Focus on content not glitz.

It will help if you have soft copy saved. I will be asking you to revize it each time a project deadline comes up.

Students have used Yahoo and Google groups and their own web servers to help them develop documents for this and other classes. I would suggest appointing some body a [ project librarian ] for maintaining your artifacts.

I figure that between two and four (2..4) pages (single sided) should do it. Use any of the techniques covered so far to help present your case if you want to. Note: We will get technical in later reports.

Due Date -- start of next class

Finished version due at start of class 8 (Fall 2009).

Note on Deliverables

Some types of people do not get promoted, don't get the interesting projects, and often get fired:

1. They deliver documents late and foul up their colleagues.
2. They deliver excuses instead of what was asked for.
3. They assemble the document at the start of the meeting.
4. They let the dog/computer/significant other/computer eat the deliverable.

On the other hand some people do well:

1. They have keep a softcopy ready to be modified.
2. When a disaster occurs they have a back up copy.
3. They think about the best (fun, quick, quality?) way to do the job.
4. They deliberately start early to have time for second thoughts.
5. They set a false deadline ahead of the due date so that that when a problem blows up they have time to handle it.


(project librarian): Some one who is rsponsible for keep copies of all documents, carrying out all changes to them, keeping back up copies, and keeping previous versions, ...

. . . . . . . . . ( end of section Project) <<Contents | End>>

Abbreviations