Contents


    Project Iteration 1 -- Kick off

      History

      In this class we start a set of projects. In the original design for the BA Computer Systems degree these projects were comtinued in a "Requirements Analysis and Design" class. Some proceeded to be Senior Projects in the BA. This is no longer feasible.

      No Programming

      In this classs we will not worry about prograamming, software design, and coding. We will take the project to the point where we know what software will need programming and stop there.

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

      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 -- Smell, Problem, Opportunity, Risk, and/or Threat.
      3. Objectives -- what does your project aim to achieve.
      4. Benefits to enterpise -- why should we do it?
      5. 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:

        [Context for a tutoring feature]

      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 you if you have two or more soft copies 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. Another viable solution is DropBox which lets you store documents and data in the cloud. I would be glad to invite people to join because I get more storage when I do this.

      I would suggest appointing some body as 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 more technical in later reports. This time you are writing for an executive -- Keep It Simple.

      Due Date -- start of 8th class

      [ schedule.html ]

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

  1. TBA::="To Be Announced".
  2. TBD::="To Be Done".

    Links

    Notes -- Analysis [ a1.html ] [ a2.html ] [ a3.html ] [ a4.html ] [ a5.html ] -- Choices [ c1.html ] [ c2.html ] [ c3.html ] -- Data [ d1.html ] [ d2.html ] [ d3.html ] [ d4.html ] -- Rules [ r1.html ] [ r2.html ] [ r3.html ]

    Projects [ project0.html ] [ project1.html ] [ project2.html ] [ project3.html ] [ project4.html ] [ project5.html ] [ projects.html ]

    Field Trips [ F1.html ] [ F2.html ] [ F3.html ]

    Metadata [ about.html ] [ index.html ] [ schedule.html ] [ syllabus.html ] [ readings.html ] [ review.html ] [ glossary.html ] [ contact.html ] [ grading/ ]

End