Assignments

In Class:

Introduction to CS190; description of project ideas; defining requirements.

In Class:

Requirements and Library Interviews.

Hand In (remember, by 2am Friday):

• Personal Background
• Talk to at least two friends not in CS190 (preferably not CS people, even) and jot down a list of 3-5 requirements for the project you are interested in. We will print out some of these and go over them in class, so make sure what you write is publically consumable! Design goals for this set of requirements: 1) capture some conflict among your requirements; 2) give a picture of a widespread problem amenable to a software solution; 3) fit within the scope of one of the two project domains

Required readings ((always) before class):

• Read the Syllabus and Project Handout.
• Read the Library handout and prepare questions to ask during class so that we can begin to formulate a requirements document in class.
• Peruse the annotated specifications documents from past years, GeoEvents and BikeQuest. A section of each document is requirements; look closely at the comments for that section. These are commented PDF documents, so make sure that you have comments visible when you read them.
• Skim "Techniques for Requirements Elicitation" to get a sense of the complexity of understanding how to ask for requirements and what the answers might mean. This should help in your interviewing.

In Class:

Critiques of requirements docs

Hand In:

• Requirements document. See the template. Design goals are: 1) a clear picture of the scope of the project; 2) a scope that is larger than can be done in a class project; 3) ambiguity only for things that don't matter; 4) brevity

Read:

• Start The Mythical Man-Month. Get at least through chapter 2. Preface - Chapter 1 - Chapter 2.

In Class:

Discussion of surprises from requirements; specifications.

Bring to class:

• A list of three things you found that were unexpected or unusual from talking to people about the requirements.

Read:

• Keep reading Mythical Man Month. You should be about halfway through it.
• Go through the specifications documents above from past years and read the rest of the annotations.

In Class:

Refined requirements critiques.

Hand In:

• Requirements 2, edited based on in-class critique. Explicitly prioritize the requirements (at least three refinable levels) and include non-functional requirements where applicable: performance, testing, reliability, ease of use, portability, documentation, dependencies on other systems. Design goals remain: 1) a clear picture of the scope of the project; 2) a scope that is larger than can be done in a class project; 3) ambiguity only for things that don't matter; 4) brevity. The third goal is tricky; we will concentrate on that in the critique.

In Class:

Discussion of readings; Specifications

Read:

• Finish Mythical Man Month, and make sure you read the essay in the back of the book, "No Silver Bullet."
• Read Slanty Design by Beale. This is a fun read.

In Class:

Initial specifications critique.

Bring to class:

• Specifications 1 (hardcopy only):
1. System model diagram -- describing how data flows through the system; base this on last class; diagram must be at least 3'x4' and HAND DRAWN with thick markers (both available in class); bring ALL your drafts!
2. User interface diagram -- something that illustrates the use of the system: a storyboard, an annotated drawing of the screen; again, must be at least 3'x4' and hand drawn.
3. Description of project, maximum 50 words, on one sheet of printer paper in the largest font size that fits.
• Be prepared to describe the components and identify difficulties or problems you aren't sure how to resolve.

Read:

• Start Large-Scale C++ Software Design by Lakos. Lakos, Chapter 0 is the only chapter we have online -- you should buy the book, or borrow it from someone. It's a useful book (and not only about C++). We are reading it in order to study design principles.

In Class:

User interface critiques.

Bring to class:

• User interface sketch -- something that illustrates the use of the system: a storyboard, an annotated drawing of the screen; again, must be large and hand drawn.
• Large description of project (same as last time) -- 10-50 words, on one sheet of printer paper in the largest font size that fits, or handwritten in marker.
• Be prepared to describe the interface and identify difficulties or problems you aren't sure how to resolve.

In Class:

Top-level design, discussion of readings.

Hand In:

• Complete specifications document (specs 2).
1. Short description (20-50 words)
2. System model diagram, revised
3. Annotations describing each component of the system model
4. User interface diagrams and descriptions, revised
5. Written description of the UI where necessary
6. Any non-functional specifications
7. Risks
• Requirements document corresponding to this specifications. If you changed it, some indication of the changes would be great, but not essential. Options are a brief list summarizing changes, or a document with "tracked changes" via Word. Source control can be helpful in keeping track of revisions so that you can produce a summary list.

Read:

• Read Lakos, chapters 3 and 5. Make sure you understand the summaries of each chapter! (in fact, one you understand the summaries, you can stop reading)
• Read Joel on Software, The Law of Leaky Abstractions. This is a fun one.

In Class:

Design 1 critique

Bring to class:

Your first pass at a levelized component diagram for the project of your choice. (This is "design 1"). Do it on a large sheet of paper with a thick marker. Design goals:

1. levelized (see Lakos or go to TA hours)
2. boxes represent software components now, don't forget run-time data structures
3. arrows represent caller->callee
4. detail of interfaces is sufficient for class to evaluate completeness w.r.t. requirements

Also bring a 20-50 word project description printed large.

In Class:

The Other Parts of a Top-Level Design, and more refactoring

Bring to class:

Nothing.

Read:

• Chapters 1-4 of Debugging the Development Process.

In Class:

Presidents' Day, no class!

In Class:

Scheduling and Group Organization

Hand In:

• Refactoring Assignment

In Class:

Become a Team

Hand In:

• Top-level Design Document, including:
1. Levelized high-level component diagram(s) and description of components
2. External dependencies
3. Task breakdown
4. Group organization
5. Schedule (use the class page to help assign roles from your group)
6. Assumptions you made about specifications that were not clear from the specifications doc. This should only be necessary if you changed your project since your requirements.
7. All three types of testing we discussed in class should be represented in the task breakdown and schedule.
• Check out example top-level design docs from past years online. Again, these are examples and are not perfect but are intended to give you a general idea of what is expected.

In Class:

Before & After Design Critique

Bring To Class:

• On large paper, present a refactoring you applied to your component diagram while you were doing your design. Design Goals: 1) the before/after change is clear; 2) the improvement in structure of the result is clear (but not explicit); 3) diagram and text are legible; 4) diagram stands alone, i.e., can be understood by the class without explanation.

Read:

• Read about development models in XP (Extreme Programming). Find out how iterative development works and read specifically about iteration planning. Feel free to do your own research if implementing this idea in class is interesting to you. The wikipedia page on Scrum might help too.
• Chapters 5-6 of Debugging the Development Process.

In Class:

Development models discussion.

Hand in:

• Development Process essay: defend your take on development process, planning, or related topic. Synthesize ideas from MMM, DDP, and XP, explain how they apply to the group project, and/or share examples from your own experience. Should be fairly short (300-500 words).

Read:

• Chapters 7-8 (finish) Debugging the Development Process

In Class:

Mike Pickett, Chief Information Officer of Brown, is speaking in class today. Brief talk and then Q&A.

Hand In:

• Final Design Document. This is probably the most critical handin of the term so far. Please carefully check that the document completely addresses all of the following requirements.
1. Revised specifications, including updated requirements. Any questions that you have been having about functionality must be answered in the revised requirements. Priorities must be finalized and of sufficient resolution to be used for later decision making about functionality changes.
2. Levelized high-level component diagram(s) and description of components. Assign level numbers to each module. The descriptions should include a list of the calls that each module will provide. Think of this as a pseudo-interface that lists the functionality in the form of calls.
3. Testing strategy. All three types of testing we discussed in class should be represented.
4. External dependencies
5. Task breakdown and schedule. Tasks should be small enough to be monitored effectively. Milestones for each piece of the project should be listed at least weekly, possibly more often, particularly for critical path pieces. The task breakdown should include not only design and coding, but also testing, documentation, and integration.
• The schedule will be presented most Fridays in class by the group leader to show the progress that's being made on the project. Try to keep the schedule on one page to facilitate this and create it in a form that can be modified as the term progresses. Things always change!
• Group organization and roles. Include any cultural mechanisms your group will use to keep morale up and achieve the group project goals.

In Class:

Schedule Critique. Bring the schedule you handed in with your individual TLD. The goal for this critique is to identify different schedule approaches and styles and discuss their effectiveness. Design goals: 1) large enough for the group to read (print it bigger and tape together, or redraw by hand on big paper); 2) captures all of the activities we discussed in class on 2/15 (I e-mailed five screen shots of the boards which captured those activities); 3) effective for tracking progress and identifying problems early; 4) as simple as possible while satisfying other goals

Read:

• Rands, What To Do When You're Screwed.
• Poppendieck, Unjust Deserts. Both are fun.

In Class:

Group dynamics I

Read:

• Start (read chapters 1-3) of Writing Solid Code.

In Class:

Schedule review, midterm evaluations and group meeting

Read:

• Lakos, Chapters 6-8.

In Class:

Programming style and interfaces

Read:

• Read chapters 4-5 of Writing Solid Code. How will you incorporate this into interfaces you design?

In Class:

Interfaces Critique: we will project each of the interfaces handed in and do a code review. Please be prepared to display each file in a reasonable-to-view form on the projector.

Hand In:

• Interface Proposals: These should include an interface for each component in your final design. (It's possible that some parts may have more than one component; justify these.) Each interface should be a single ".h" file, with comments. For level 0 components, the interface file should compile. As far as possible, higher-level interface files should also compile, but for this first pass, it isn't required, since dependencies may still need to be ironed out. Remember that the goal of this pass is to create the minimal interface that provides the functionality that other components need.
• Each interface should also include a component-level testing strategy and a schedule of implementation and testing deadlines that fit in with the overall project schedule.

In Class:

Group meetings and schedule review

Read:

• Chapters 6-7 of Writing Solid Code.

In Class:

Debugging Lab

Read:

• Chapter 8 of Writing Solid Code. How can this culture get into your project?

In Class:

Group Dynamics II and testing discussion

In Class:

Group meetings and schedule review

Hand In:

• Final Interfaces. All interface files handed in must compile! The testing strategy and external schedule should also be appropriately updated.
• An updated design document, including any changes to the schedule due to new dependencies, etc. The modified design document should have an introductory paragraph describing any changes.

In Class:

Spring Break, no class!

In Class:

Spring Break, no class!

In Class:

Spring Break, no class!

In Class:

Group Dynamics

In Class:

Dean Torgan of Concentrations will be in class.

In Class:

Group meetings and schedule review

In Class:

Testing lab

In Class:

Some people from Public Display, a company started from CS190 alums, are coming to talk.

In Class:

Group meetings and schedule review

In Class:

Integration demo

Hand In:

• Initial integration due. Your code should work, and hopefully do something useful-looking. Be prepared to show the TAs that all of your code compiles together, and that mid-level components can successfully interface with the lower-level components they depend on.

In Class:

Performance analysis tools

In Class:

Group meetings and schedule review

In Class:

Semester planning and group meetings

In Class:

New Profiling Lab

In Class:

In-class demo and schedule review

Heads Up:

• Reading period begins! Class will be held intermittently to give you time to wrap up the project.

In Class:

Reading Period, no class!

Heads Up:

• Prepare for public demos!

In Class:

Reading Period, no class!

Heads Up:

• Profiling assignment due Friday!

In Class:

Schedule review and profiling assignment discussion

Bring To Class:

• The group should be prepared to go over project status and present a detailed plan for the remaining work that needs to be done before the final demo. A schedule for completing this work should also be presented.

Hand In:

• Profiling assignment

In Class:

Post-mortems, course wrap-up, course evaluations

Public Demo:

• 4pm in the Sunlab.

Hand In:

• Individually hand in a Maguire-style post-mortem about your project. See Chapter 4 of Debugging the Development Process, pp. 79-81 for details on doing a post-mortem.

Final Demo:

• 10am in the Sunlab.

Hand In:

• Printed documentation, including sufficient detail to continue to run your project after you are all gone and pointers to all online resources (source, doc, web stuff, build areas, binaries, data files, etc.); a report on the results from your user testing and changes made as a result of it; a printout of all code; and the final specifications/requirements document.