Bring to class: 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.
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.
Read "The Software Development Process in Reiss, pp 416-422.
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?
Work on Requirements document. Check out everyone's project titles handins for ideas, if you wish.
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 (HelloUML and BearAdvisor). Also included are specifications from years past.
Requirements document in text (.txt), pdf (.pdf), or postscript (.ps). Refer to project handout.
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.
Work on specifications.
"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.
Revised comments for Group 1 presentations.
Revised comments for Group 2 presentations.
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.
Revised comments for Group 3 presentations.
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.
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!
Chapters 2-6 of Mythical Man Month. Think about how this applies to the your group organization and top-level design.
Revised comments for Group A presentations.
Group A presenters hand in specification self-assessment.
Revised comments for Group B presentations.
Group B presenters hand in specification self-assessment.
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.
Revised comments for Group C presentations.
Group C presenters hand in specification self-assessment.
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.
on top-level designs and prepare for presentations.
Debugging the Development Process, Chapters 1-4. (Available as PDF files online. Only accessible from computers on Brown's network.)
Debugging the Development Process, Chapters 5-8. (Available as PDF files online. Only accessible from computers on Brown's network.)
A list of three lessons from DDP that you think will have the most impact on your CS190 project. Explain how and why.
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.
The essays from 2/19, with attention to lessons relevant to roles in your group.
your DDP lessons. We'll talk about them in class. Think of relevant things that may have already come up in your groups.
doing some of the reading for 3/15, since that's going to be a busy day.
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.
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.
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.
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.
Mon 3/24 (break)
Wed 3/26 (break)
Fri 3/28 (break)
Copyright 1999-2003 David Laidlaw