CS 361 Assignments (Winter 2008)

Last updated:Jan. 24, 2008.

The assignments list will evolve and change regularly, so you should double-check it regularly.

Presentations

Presentations will be done in teams. Within your team, you may divide up the work however you like, but each of you must do some of the speaking. Your presentation grade will be based on (1) demonstrated knowledge of the assigned topic, (2) adherence to the specifications given on what you are supposed to present about and (3) the professionalism demonstrated by the quality of your presentation (however, avoid flashy audio/visual effects, as these are neither a good use of your time nor a mark of professionalism).

You may use any kind of visual aid you want -- project from your laptop, from stored files on the network, use the board, use prepared transparencies, or whatever.

Here is a sample use of my presentation grading rubric from a prior term:

Correctness of concepts:
No mistakes in concepts, and in fact the conceptual
information was very nicely explained with good
attention to the concepts.

Conformance to specifications of the presentation:
This was weak: The material was presented
mostly as a lecture about what "one" does, and
not about what _you_ are doing.  The "application
to our project" part tried to address this, but ended
up with too little emphasis and time, so it really didn't
deliver this.

Clarity, organization, etc.: This was fine.

Written assignments

Hand-in instructions for electronic hand-ins: Login with your engr account into www.engr.orst.edu/teach. Click on 'submit assignment' under the 'class related'. Choose the appropriate assignment and upload your file and submit it. For team assignments, only 1 team member needs to do the submitting.

This is a writing-intensive course. Thus, students will be graded according to not only the content of their writing, but also the quality of it. Here are just a few of the writing problems that have cost students points in the past:
Making claims without substantiating them, grammatical errors and spelling mistakes, capitalization errors, inconsistent use of past/present tense, subject/verb agreement errors, lack of clarity.
As mentioned elsewhere on the CS 361 site, we will not teach grammar, spelling, etc., but you are responsible for them nonetheless. The Writing Resources link on the main page will help you connect with writing guidance as needed. We will also give a few writing tips throughout the term to help move your writing skills to the level expected of a professional in a technical field.

• HW #1 (on temporary team): (a) complete Pressman problem 21.1. (b) explain which of Pressman's paradigms you used. Give specific examples that illustrate your use of the paradigm(s) in a way that shows you understand what the paradigm is.

  Write all 3 team members' names on it. Approximately 1.5-3 double-spaced pages are expected. Or about half of that if single-spaced. (To improve your grade, this document should have gone through a couple of drafts, with edits/comments by all team members.) Begin in class, finish outside of class.

  Due date: Tu, Jan. 15

• HW #2 (with your permanent teammates): Imagine that your team is to develop a new front-end (user interface) for search engines like Google, for your company to market commercially, using Extreme Programming. Write a 'diary' of what your team members (pretend to) do, covering in detail the first paragraph of the 'How do I start this XP thing' resource on the class web page.

  Approximately 4-7 double-spaced pages will be needed. Remember that you are responsible for high quality writing, so do more than one draft, edit each other's work, remind yourself of writing principles, and get extra writing help if needed from the Writing Center.

  Due date: Tu, Jan. 22.

• HW #3 is already in progress (team): Finish performing the following team-forming tasks: (a) recruit/select a team, (b) choose a team paradigm, (c) elect a team leader, (d) elect a quality control lead, (e) choose a definition of success, and (f) decide upon a communication frequency/medium. Finally, (g) select your preference for one of the following two processes: RUP or XP (first come, first served: half the teams will be RUP and half XP). What you'll hand in is your decisions on each of the items a-g. (Your team is allowed to change your decisions to b-f later, if desired.) Hardcopy: 1 page or less is just fine.

  Due date: Tu, Jan. 29.

• HW #4 (team): Choose your term project. One paragraph is fine, as in the samples shown in the linked page. Don't forget to include the contact name/role. Turn in hardcopy and electronic.

  Due date: Tu, Jan. 29.

• Req and PP assignments (team): Following your team's software process model (RUP or XP), begin working on your requirements and your project plan (the "release plan" in XP). Don't forget that part of your project plan is what data you'll collect along the way, so that you can evaluate how well your project plan is working.

  Assignment Req-1 is to turn in Version 1 of your requirements. PP-1 is to turn in Version 1 of your project plan. We call these Version 1 because both RUP and XP are iterative and thus your documents will change. Later in the course you will turn in later version(s).

  • Details about Req-1: See the project web page for details about what has to be in the Requirements document. For this Req-1 part, you must have all the parts of the document, including Sections 1 and 2 and covering at least one fourth the detailed requirements of Section 3. Thus, you must have at least one fourth of the planned requirements written up, and the ones you turn in must be "complete" in form, referring to substantiating stories or use cases and/or scenarios that are also present. You must also include some validation details to the extent possible, except for Cognitive Dimensions/Attention Investment, which we will not cover in time for this assignment. Number every Volere card (RUP) or task (XP), so that you can refer to them in your other documents. Finally, state what other planned requirements you have not included. (Turn in hardcopy and electronic.)

    Due date: Tu, Feb. 5.

  • Details about PP-1: Structure should follow the Project Plan outline/format in the project web page. This is your real plan to get your actual final project turned in by the end of the term, not a work about some fictional situation you're imagining. If you are XP, it must go through the end of "iteration 1"; RUP teams must turn in their entire plan. Tie back specifically to the requirements you numbered in Req-1. (Turn in hardcopy and electronic.)

    Due date: Tu, Feb. 26.

• (Continue team assignments): Hold your first postmortem: what went right, what went wrong, what does the data tell you about your project plan so far, etc. Record your findings and plan follow-ups and changes needed based on those findings.

  From now on, after every hand-in, you should conduct a postmortem (based on your data) so as to improve your processes and keep trouble at bay. Include the postmortem data and resulting adjustments in your growing Project Plan (which you'll eventually turn in). After this first postmortem, adjust your project plan as needed and start working on your design at a high level.

  Due date: Do this immediately after your first Req-1 handin. There is nothing to turn in at this time from this postmortem, but add it to your project plan which will eventually be turned in.

• PP-1post: After turning in Design-1UI (as with every handin), conduct your post-mortem, which we'll call POST. Add it to your growing project plan. But also, this one you need to turn in (hardcopy and electronic).

  Due date: Tu., Feb. 26.

• Design-1UI and Design-1ARCH: The UI must be completed in Design-1UI and the architecture must be completed in Design-1ARCH, but low-level details of the design (other than UI) do not yet have to be present. Specifically:
  • Design-1ARCH should be in the form of diagrams, such as those found in your text book's chapters on architecture. These do not need to use UML yet, since they are still very high-level, but they can include UML if you wish.
  • Design-1UI should be pictures of all screens and reports. (These can simply be scanned-in pencil sketches at this point, but they do need to be specific and clear.) Thus, the Design-1UI document is basically the design from the user's perspective.
  Number these and all your design documents and in them, refer to the requirements by number. In turn, the requirements should refer to these design documents by number. The design documents that tie to the UI should also refer to those screens by number, and so on. The point is to cross-reference, so that you can tell by reading a requirements page where in the design to look for it, and that you can tell by reading a design which requirements it's supposed to relate to. Include your current Req document for our reference. Turn in hardcopy and electronic.

  Due dates: Both are due Th., Feb. 21.

• Design-2: You should have drawn UML diagrams that reflect the detailed design to a complete state of at least four requirements. (That's all we need in order to give you feedback. But note that if all you have detailed design of at this stage are four requirements, you are in big trouble time-wise!) Tie the designs you have included back to requirements by number. Also to the screens/reports by number. Include your current version of Req for our reference.

  Due date: Design-2 is due Tuesday, Mar 4.

• Final versions of everything (i.e., Requirements, Project Plan, and Design) are due on the last day of class. Turn in hardcopy and electronic.

Additional details on the evolving Req, PP, and Design documents, which the above assignments are transitioning you toward, can be found here.