CS190 Assignments

David Laidlaw
Brown University
Spring 2000

Assignments for each class. Handins are due, unless otherwise specified, by 9am the day of class to allow for review before class. Handins due on MM-DD go in the directory /pro/web/web/courses/cs190/asgns/MM-DD-YY/LOGIN.txt -- replace LOGIN with your CS login id. For classes with multiple handins, add a digit after your login (e.g., dhl1.txt, dhl2.txt, ...).

Fri 1/28

Hand in:

personal background

Read the Syllabus and Project Handout. We'll go over requirements on Friday, so pay attention to that section. Note any questions for class.

Hand in: a list of 3-5 project titles that you are considering. For each title, list the potential project user(s) that you would interact with in developing and testing the project. For each idea, evaluate it according to the criteria in the project handout and indicate pros and cons of the project ideas. Any troubles with topics, come talk to a TA or to me and we'll brainstorm.

Read "The Phases of Software Engineering" through the "Requirements" section in Reiss, pp. 404-406 and table on 407.

Read 425-427 in Reiss.

Peruse: example requirements documents. These examples are not perfect, they are intended to give you a feel for what was proposed last year. The first two, alpha and bravo, were the main contenders for implementation last year, with bravo winning out.

Mon 1/31

Read

Read Preface to the 20th Anniversary Edition, chapter 1, and chapter 2 of The Mythical Man Month.
Read chapter 0 of Lakos.
Read table of contents and introduction to Writing Solid Code.
Read table of contents and introduction to Debugging the Development Process.
Read beginning of "Software Engineering" in Reiss, pp 397-404.
Read "The Software Development Process in Reiss, pp 416-422.

Hand In

A list of discussion points, questions, or topics for class based on the reading. What are some of the themes that appear across more than one source? What do you agree with? What do you disagree with? What seems intuitive and what seems counterintuitive? What surprised you?

Future work

Work on Requirements document. Check out everyone's project titles handins for ideas, if you wish.

Wed 2/2

Read

Continue reading with "The Phases of Software Engineering" through the "Specifications" section in Reiss, pp. 406-412.
Peruse example specifications docs online. Again, these are examples of the two main contenders in CS190 last year. Also included are specifications for a calendar manager from the year before.

Hand In

Requirements document in text (.txt), pdf (.pdf), or postscript (.ps). Refer to project handout.

Fri 2/4

Prepare to present in class:

Group 1: Brian Chuck, Di Wang, Joseph Fuqua, Melissa Cheng, Rikard Grafstroem, George Quievryn

Hand In:

Read Requirements Document for the three authors following you in the class list . (At the end of the list, cycle back to the beginning.) If not all three documents are present, continue down the list until you find three. Fill out and hand in the review form using the format AUTHOR_by_REVIEWER.txt for the filename. Replace AUTHOR and REVIEWER with the appropriate logins.
Update your reviews after the class presentation and hand in revised version by the class following the presentation.

Future Work:

Work on specifications.

Mon 2/7

Prepare to present in class:

Group 2: Bretton Heath-Wlaz, Emily Leventhal, Josh Tasman, Michelle Neuringer, Freddie O'Connell, David Yun

Read

"Design" section of Reiss, 412-414, "Design" section, pp 427-429, skim pp. 429-441.
Chapter 5 of Writing Solid Code.
Summary for Chapter 1 of Lakos, pp 61-62. Refer back to the chapter if these concepts are not clear.

Hand In:

Revised comments for Group 1 presentations.

Wed 2/9

Prepare to present in class:

Group 3: Christopher Filippis, Greg Getchell, Lisa Cozzens, Mark Zeldis, Toan Pham, Neelu Bedi

Hand In:

Revised comments for Group 2 presentations.

Read

Chapter 3 of Lakos. If you understand the statements in the summary, then you have gotten the essential information out of the chapter.
Chapter 13 of Mythical Man Month.

Fri 2/11

Hand In:

Revised comments for Group 3 presentations.

Hand in:

Specifications Document. Should include: 1) description of the project (from requirements); 2) system model diagram; 3) annotations describing each component of the system model; 4) user interface diagrams and descriptions; 5) written description of the above; 6) non-functional requirements (performance, testing, reliability, ease of use, portability, documentation, dependencies on other systems); 7) updated requirements (with priorities, etc.); 8) any risky parts.

Mon 2/14

Spec presentations should cover the following information. Begin with a very brief (< 30 second) reminder of the project. Then spend 2-3 minutes on the block diagram of the system describing the different parts and how they fit together. Finally, in 1-2 minutes go through a few non-obvious representative examples of functionality and how the parts of the program will implement them.

Prepare to present in class:

Group A: Brian Chuck, Di Wang, Joseph Fuqua, Melissa Cheng, Rikard Grafstroem, George Quievryn, Bretton Heath-Wlaz

Hand In:

Read Specifications Documents for the three authors following you in the class list . (At the end of the list, cycle back to the beginning.) If not all three documents are present, continue down the list until you find three. Fill out and hand in the review form using the format AUTHOR_by_REVIEWER.txt for the filename. Replace AUTHOR and REVIEWER with the appropriate logins.
Update your reviews after each class presentation and hand in revised version by the class following the presentation.

Read

Chapter 5 of Lakos. If you understand the statements in the summary, then you have gotten the essential information out of the chapter. This chapter is very important from a design perspective, so make sure that you really understand the summary!

Wed 2/16

Prepare to present in class:

Group B: Emily Leventhal, Josh Tasman, Michelle Neuringer, Freddie O'Connell, David Yun, Christopher Filippis, Greg Getchell

Read

Chapters 2-6 of Mythical Man Month. Think about how this applies to the your group organization and top-level design.

Hand In:

Revised comments for Group A presentations.
Group A presenters hand in specification self-assessment.

Fri 2/18

Prepare to present in class:

Group C: Lisa Cozzens, Toan Pham, Neelu Bedi

Hand In:

Revised comments for Group B presentations.
Group B presenters hand in specification self-assessment.

Read

Bring to Class:

Fill in project evaluation form for class projects. Enter scores for the 3 projects that you have reviewed, for your own project, and for any others that you would are interested in. Refer to specs documents to help with your decision. Be prepared to discuss all projects and to choose 2-3 that we will continue with for top-level designs. Each person in class will do a design for one of those projects.

Read

Hand In after class (but before midnight):

Revised comments for Group C presentations.
Group C presenters hand in specification self-assessment.

Mon 2/21 No class!

Wed 2/23

Note: due date for top-level designs moved to Friday!

Hand In:

200-400 word essay related to the Mythical Man Month reading (chapters 2-6 most recently, but feel free to tie back to earlier reading). Share a relevant example from your own experience, compare this reading with some other reading you've done, explain why you disagree with some point, etc.

Work

on top-level designs and prepare for presentations.

Fri 2/25

Hand in:

Top-level Design Document. Should include: 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. All three types of testing we discussed in class should be represented in the task breakdown and schedule.

Prepare to present in class:

Group Able: Christopher Filippis, Greg Getchell, Lisa Cozzens, Toan Pham, Joseph Fuqua. Presentations should be about a significant and unobvious part of your design. Pick something that you struggled with and that illustrates a lesson you learned this semester. For example, explain how you applied ideas from Lakos to remove a cycle, to increase breadth, or to reduce depth of the component graph. Or describe a significant difference in the design component graph from the specifications component graph and why it makes the design better. Or explain how you struggled with the schedule but were able to put something together that keeps everyone busy for the entire development time. Re-read carefully the examples from Lakos chapter 5 for ideas.

Mon 2/28

Prepare to present in class:

Group Baker: Bretton Heath-Wlaz, Emily Leventhal, Josh Tasman, Michelle Neuringer, Freddie O'Connell, David Yun. See guidelines for the presentation from Friday.

Read

Debugging the Development Process, Chapters 1-4.

Wed 3/1

Prepare to present in class:

Group Charlie: Brian Chuck, Di Wang, Neelu Bedi, Melissa Cheng, Rikard Grafstroem, George Quievryn. See guidelines for the presentation from Friday.

Read

Debugging the Development Process, Chapters 5-8.

Hand in:

A list of three lessons from DDP that you think will have the most impact on your CS190 project. Explain how and why.

Fri 3/3

Review:

All the top-level designs for your project. Pay particular attention to the group organization possibilities and come prepared with a list of at least 3 specific roles for which you feel you would be a good candidate.

Read:

The essays from 2/23, with attention to lessons relevant to roles in your group.

Mon 3/6

Wed 3/8

Review:

your DDP lessons. We'll talk about them in class. Think of relevant things that may have already come up in your groups.

Consider:

doing some of the reading for 3/15, since that's going to be a busy day.

Fri 3/10

Hand in:

Final Design Document. This is probably the most critical handin of the term so far. Please carefully check that the document carefully and completely addresses all of the following requirements. Link the handin from the asgns directory to your project page.

1) Revised specifications including updated requirements. These should now be cast in concrete. 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!

6) Group organization and roles. Include any cultural mechanisms your group will use to keep morale up and achieve the group project goals.

Mon 3/13

Review:

Chapter 5 of Writing Solid Code. How will you incorporate this into interfaces you design?

Read:

Summary of Chapter 8 of Lakos. Read back for any details that you find interesting.
Chapter 6 of Lakos. This chapter talks about how to reduce physical dependencies through changes in interfaces. Read the chapter summary first, then section 6.6, then start at the beginning of the chapter.

Wed 3/15

Read:

Writing Solid Code, Chapters 1-4. Incorporate ideas from this reading into the component testing strategy and into your feedback on interfaces

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

Fri 3/17

Read:

Writing Solid Code, Chapters 6-7. Keep in mind while evaluating testing strategies and for creating designs that will be reliable and testable.

Mon 3/20

Read:

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

Hand in:

Interface Comments. Each component needs to be reviewed from the perspective of every other component dependent on it. For each such pair, hand in a file with a name of the form <component1>_by_<component2>.txt, e.g. database_by_gui.txt. Also link all of these files to the project page. There should be one file for each arrow in the final design block diagram.

Interface feedback should also include feedback on the implementation schedule. Will the parts each component needs be implemented and tested by the time the component needs them?

Interface feedback should also be provided by the architect, testing person, and any other appropriate team members. Copy in, link, and label those files similarly (e.g., database_by_testing.txt).

Evaluating these interfaces is likely to make apparent that some arrows were missing from the final design and that some functions were missing from the interfaces.

Wed 3/22

Nothing!

Fri 3/24

Hand in:

Final Interfaces. All interface files handed in must compile! The testing strategy and external schedule should also be appropriately updated. Hand in 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.

Mon 3/27 (break)

Wed 3/29 (break)

Fri 3/31 (break)

Mon 4/3

Note:

Testing assignment due Friday

Wed 4/5

Hand in:

detailed designs

Fri 4/7

Hand in:

Testing assignment

Prepare to present in class:

BEAR group. Each person in the group should present the most interesting part of the detailed design they were involved with. The group needs to manage the class time effectively. Use printed transparencies for .h files and for diagrams to save presentation time!

Group Status:

both groups should hand in a written group status report this week in place of presenting it in class.

Mon 4/10

Prepare to present in class:

HelloUML group. Each person in the group should present the most interesting part of the detailed design they were involved with. The group needs to manage the class time effectively. Use printed transparencies for .h files and for diagrams to save presentation time!

Wed 4/12

Keep on with your projects!

Fri 4/14

Nada.

Mon 4/17

Don't forget:

Debugging assignment due Wednesday!

Wed 4/19

Hand in:

Debugging assignment

Read:

MMM chapter "No Silver Bullet" and "No Silver Bullet Refired"

Fri 4/21

Weekly project reports in class.

Mon 4/24

Prepare for code review:

Each group should bring a full printout of all the code for their project, a copy of the coding standards for the project, and transparencies of the most complicated piece of code in the project

Wed 4/26

Prepare for code review:

Same as last class.

Fri 4/28 (reading period)

Prepare for in-class demos!

Mon 5/1 (reading period)

Hand in:

gprof assignment

Review for class discussion:

"No Silver Bullet" and "No Silver Bullet Refired". Be prepared to discuss lessons relevant to these readings in class

Wed 5/3 (reading period)

Prepare for demos in Lubrano!

No class in the morning

Fri 5/5 (reading period)

Group Status:

each 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 and how it will get done.

Mon 5/8 (reading period)

Last Class!

Course wrapup, course evaluations, and free food :-)

Hand in:

a Maguire-style post-mortem about your project. See Debugging the Development Process pp 79-81 for details on doing a post-mortem.

Fri 5/12 9am (exam time)

In Sun Lab.

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; a printout of all code; and the final specifications/requirements document.