CSC 309 Milestone 1

CSC 309 Milestone 1

Due: 11:59PM, Friday 3 April

  1. Form a project team, during the first lab meeting. If you are continuing from CSC 308 last quarter, you may choose to continue in the same team. If you want, you are free to change teams.

    Once the teams have been formed, perform the following administrative tasks:

    1. Exchange team member contact information.

    2. Determine regular weekly meeting time(s). You may use the lab times when your team is not meeting with the instructor, but other times outside of class will be necessary some weeks.

    3. Elect the following team officers:

      1. leader -- overall managerial leader and decision-making arbiter

      2. assistant leader(s) -- for large teams, you may want to organize into groups, each with an assistant leader

      3. librarian -- keeper and primary organizer of the project repository

      4. secretary -- meeting note taker and assistant to the librarian

      5. technical lead -- leader of the design and implementation efforts (but NOT the sole designer and implementor; all members will design and implement)

  2. Select a project. The projects we will work on this quarter are CSTutor, Grader, Scheduler, and TestTool. Last quarter's projects may not have included some potentially useful features, due to time constraints. As necessary, the specs to be used this quarter will be combined versions of specs from previous quarters of 308. We will discuss the alternatives during the first two lab meetings.

  3. Read the requirements specification documents for your selected project and determine how much of the project is feasible to complete in one quarter. The CSC 308 project links are at 
    
http:/users.csc.calpoly.edu/~gfisher/classes/309/specs.
    Here are things to look for as you review the specs:

    1. important system features that seem to be missing from (any version of) the spec

    2. features that are not specified clearly, completely, and/or consistently

    3. features that could have been specified "better"

    4. how consistently to merge the features from two or more specs under consideration

    5. objects and/or operations that are not consistently defined in the scenarios versus the abstract Java model

    6. organization of the Java model objects and/or operations that is awkward from a design perspective (even though it may be OK from an end-user perspective)

    Since there are a lot of specs to read, you can divide the reading among team members according to team member interests and expertise. In particular, it makes sense for team members to read those sections of the specs that cover functionality that they worked on in the Fall. This of course does not apply to team members who are working on a 309 project that is different than what they worked on in 308.

  4. Write the initial SCOs that define what parts of the project will be designed and implemented, and any specification changes you feel necessary initially. More SCOs are likely to follow during the first few weeks of the quarter. We will discuss your initial SCOs in our lab meetings during the first and second weeks of class.

    If you are working from more than one spec, choose one of them as the base spec, with respect to which all SCOs are defined. Identify this base spec in the very first SCO, i.e., SCO Number 1. If you are replacing a feature in the base spec with the same or comparable feature from another spec, the SCO is defined in the form "Replace Section X in the base spec with Section Y from the other spec.". If you add a feature from another spec that does not exist in the base, define the SCO in the form "Add Section X from the other spec.".

    Identify the base spec and all "other" specs by date of publication and class section, e.g., "Fall 2007 Morning Section."

  5. In defining the parts of the project that you will complete in 309, use the following levels of completion: Note that you can use fractional components in assigning completions levels. E.g., LEVEL 1.5 means fully design and implement 50%.

  6. Determine an initial individual work breakdown for the project; i.e., determine what segments of the specification each team member will be responsible for.

  7. In your administration project directory for 308, rename work- breakdown.html file to 308-work-breakdown.html. (This way your 308 and 309 work breakdowns will be distinct.)

  8. Use the following template files for your project SCOs, work breakdown, and meeting minutes:

  9. For the project librarian, create the project repository if necessary; using the 308 repository is the most typical case.

    1. Authors of the files described above check these files in.

    2. Project librarian installs the base requirements directory.

    3. Project librarian then releases the project by 11:59PM Friday 3 April.
    The 309 SVN basics handout covers details; we'll go over this in lab on Wednesday.

  10. Consider what implementation platform your team would like to use this quarter. The deployment requirements for the 309 projects are: Java/Swing ore Java/FX are recommended for the desktop components. If you use Java Swing for the desktop, you can use Java/GWT or Java/FX for the browser- based component. A viable option for the GUI library instead of Swing is SWT, the GUI library supplied by Eclipse. A viable option for a platform other than Java is Python, with the QT GUI library.



index | lectures | handouts | examples | doc | lib | grades