CS190 Assignments

In Class:

Bring To Class:

• Bring your favorite proposed titles hand written on a piece of paper so that they will be legible from 5 feet away. Use a dark, thick pen. Write large. Get a big piece of paper. Put your name on the paper.

Hand In:

• personal background
• 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. At least two of your choices must be from the list of outside proposed projects. Any troubles with topics, come talk to a TA and brainstorm.

Read:

• Read the Syllabus and Project Handout. We'll go over requirements on Friday, so pay attention to that section. Note any questions for class.
• Review the evaluation form that will be used for requirements documents to get an additional sense of the criteria for a good project.
• Read the Library handout and prepare questions to ask during class so that we can begin to formulate a requirements document in class.
• Read "The Phases of Software Engineering" through the "Requirements" section in Reiss, pp. 404-406 and table on 407.
• (chapter 15 of Reiss)
• Read 425-427 in Reiss. (chapter 16 of Reiss)
• Peruse example requirements documents from 2000 and 2003 These examples are not perfect, they are intended to give you a feel for what was proposed in previous years. The first two in the 2000 set, alpha and bravo, were the main contenders for implementation that year, with bravo getting implemented. Also look at some of the requirements documents from previous years: bheathwl , tpham , ljc , jfuqua .

Heads Up:

In Class:

Bring To Class:

• Bring your favorite proposed titles hand written on a piece of paper so that they will be legible from 5 feet away. Use a dark, thick pen. Write large. Get a big piece of paper. Put your name on the paper.

Hand In:

• A list of three 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?
• Hand in the name of the project idea that you will proceed with, the names of at least two clients that you will interview, and the times that you have set up for those interviews (which ideally have already passed). Remember that you must have these interviews before you can write your requirements document for Wednesdsay!

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. book is here,
• Read table of contents and introduction to Debugging the Development Process. (Available as PDF files online: table of contents, introduction)
• Read beginning of "Software Engineering" in Reiss, pp 397-404. (chapter 15 of Reiss)
• Read "The Software Development Process in Reiss, pp 416-422. (chapter 15 of Reiss)
• 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.

Heads Up:

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

In Class:

Bring To Class:

Hand In:

• Requirements document in text (.txt), pdf (.pdf), or word (.doc). Refer to project handout.

Read:

• Continue reading with "The Phases of Software Engineering" through the "Specifications" section in Reiss, pp. 406-412.
• Peruse example specifications docs from 2000 online. Again, these are examples of the two main contenders in CS190 from previous years (HelloUML and BearAdvisor). Also included are specifications from years past. Here are specifications documents from 2003.

Heads Up:

In Class:

Prepare to present: Group 1

• Andy
• Amy
• Haley
• Kaveh

Presentatations will be posters, 3' wide, as tall as you think will work. Their main points should be about the evaluation of your project with respect to cs190 project criteria, with any information you want to support the evaluation. Supporting info should include information about what the project is. Secondarily, they should make it sound compelling to to the rest of the class. You'll have 2 minutes to describe your project using the poster as a prop. Practice with friends -- it will really make a difference!

Bring To Class:

Hand In:

• Read Requirements Document for the three authors following you . (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.

Read:

Heads Up:

• Work on specifications.

In Class:

Prepare to present: Group 2

• Peter
• Sam
• Toby
• Yotsawan

See guidelines from Friday

Bring To Class:

Hand In:

• Revised comments for Group 1 presentations.

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.

Heads Up:

In Class:

In Class:

Bring To Class:

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
  The document can be a text (.txt), pdf (.pdf), or word (.doc) file.

Read:

Heads Up:

In Class:

Prepare to present: Group A

• Peter
• Sam
• Toby
• Yotsawan

Spec presentations should cover the following information. Begin with a very brief (15 second) reminder of the project. Then spend 15-30 seconds -- very briefly -- going over the block diagram of the system describing the different parts and how they fit together. Practice this part to see how much you can say in 15-30 seconds! Finally, in about 1-2 minutes, talk about a software engineering lesson that you learned from making the spec. Try to think of something not too obvious, since you'll have lots of company coming up with these ideas. The lesson might be a non-obvious way that the components of your spec handle some part of the requirements. It might be a surprise you had about how an obvious organization wouldn't work. It might be a surprising way that some of the reading applies to your design. Give us all a take-home lesson to think about. We'll try to have a few minutes to discuss each presentation. Bring visuals to put on the wall illustrating your block diagram and your take-home lesson. Include your project title (and short description if not self-describing) and your name or login.

Bring To Class:

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!

Heads Up:

In Class:

Prepare to present: Group B

• Andy
• Amy
• Haley
• Kaveh

See guidelines from Monday

Bring To Class:

Hand In:

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

Read:

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

Heads Up:

In Class:

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.
• Complete the refactoring assignment and bring your solutions to class to hand in. Please note that hand written solutions are completely acceptable, and all we want is to be able to read you answers.

Hand In:

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

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

In Class:

Bring To Class:

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.

Read:

Heads Up:

• Work on top-level designs and prepare for presentations

In Class:

Prepare to present:

• Andy
• Haley
• Peter
• Toby

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. Look for a design change that that is as significant as possible. Don't lump several changes together. Stay focused on one change. The presentation should clearly show the part of the design that changed both before and after the change. For example, show the component diagram before and after shifting it around or show the design and schedule before and after a schedule-improving design change. The presentation must start with a one-sentence description of the change and its significance. An example: "I factored out functionality from a level-2 module to reduce the total height of my levelized component diagram."

Bring To Class:

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.
  7. All three types of testing we discussed in class should be represented in the task breakdown and schedule.
  See example top-level design docs from previous years here: 2000, 2003, 2004

Read:

Heads Up:

In Class:

Prepare to present:

• Amy
• Kaveh
• Sam
• Yotsawan

See guidelines for the presentation from Friday.

Bring To Class:

• What to bring to class 1
• What to bring to class 2

Hand In:

• What to hand in 1
• What to hand in 2

Read:

• Debugging the Development Process, Chapters 1-4. (Available as PDF files online. Only accessible from computers on Brown's network.)

Heads Up:

In Class:

Bring To Class:

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.

Read:

• Debugging the Development Process, Chapters 5-8. (Available as PDF files online. Only accessible from computers on Brown's network.)

Heads Up:

In Class:

Bring To Class:

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

Hand In:

Read:

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

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

In Class:

Bring To Class:

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

Hand In:

Read:

Heads Up:

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

In Class:

Bring To Class:

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.

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

• Review Chapter 5 of Writing Solid Code. How will you incorporate this into interfaces you design?
• 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.

Heads Up:

In Class:

Bring To Class:

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.

Read:

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

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

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

Heads Up:

In Class:

Bring To Class:

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.

Read:

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

Heads Up:

In Class:

Bring To Class:

Hand In:

• Debugging assignment

Read:

Heads Up:

In Class:

Bring To Class:

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.

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

• Testing assignment due Monday

In Class:

Bring To Class:

Hand In:

• Detailed designs

Read:

Heads Up:

In Class:

Prepare to present:

Geoevents 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 posters or transparencies for diagrams to save presentation time! The goals here are to share with the other groups what you learned that you think has lasting value.

Bring To Class:

Hand In:

• Testing assignment

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

• Initial Integration Due. 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.

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

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

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

• Prepare for public demos!

In Class:

Bring To Class:

Hand In:

Read:

Heads Up:

• Prepare for public demos!

In Class:

Bring To Class:

Hand In:

• gprof assignment

Read:

Heads Up:

Group Status:

In Class:

Public Demo:

Bring To Class:

Hand In:

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

Read:

Heads Up:

In Class:

Bring To Class:

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. Each group should report on their user testing and changes from it.

Read:

Heads Up:

Copyright 1999-2006 David Laidlaw