Assignments
The assignments due for each class are linked off the calendar below and
correspond with the (less detailed) due dates on the Google Calendar page.
Handins are due to the CS filesystem by 2am on the day of the
class, as this will allow for staff review before class.
Handins due on M-DD should be placed in the directory
/pro/web/web/courses/cs190/2007/handins/M-DD/[login].txt, where [login] is
your CS username. If there are multiple handins for a class, please add a
digit after your username (e.g. dhl1.txt, dhl2.txt, etc.). Note that
handins are not limited to plaintext. PDFs and Word files are also welcome.
Wed 1/24
In Class:
Introduction to CS190
Read:
- Look over the CS190 website to get a sense of the course and its assignments.
Fri 1/26
In Class:
Requirements and Library Interviews
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 end of the "Requirements" section in
Reiss, pp. 404-406, plus the outline on 407.
- Read Reiss, pp. 425-427.
- Peruse some example requirements documents from past years.
These examples are not perfect, they are intended to give you a feel for what was
proposed in previous years. GeoEvents and Bikequest are both projects that were
selected for implementation for their respective years.
Mon 1/29
In Class:
Requirements and Software Engineering
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:
Heads Up:
Wed 1/31
In Class:
Discussion of readings and requirements, presentation information
Hand In:
- Requirements document in text (.txt), PDF (.pdf), or Word (.doc) format. Refer to project handout.
Read:
Fri 2/2
In Class:
Discussion about readings and specification documents
Hand In:
- Read Requirements Documents for the other members of the class. 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.
Heads Up:
- Work on specification document.
Mon 2/5
In Class:
Requirements student presentations
Presentation:
- 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!
Read:
Wed 2/7
In Class:
A CS190 alumnus and the CEO of the local software company he works for will be our guests for this class.
They will be discussing their experiences in industry, what software companies look for when hiring out of college,
and will leave some time for questions as well. Please attend, and bring your friends from outside of class!
Hand In:
- Revised comments for requirements 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.
- Review the non-Lakos reading that has been done.
Fri 2/9
In Class:
Object-oriented design (reading discussion)
Hand In:
- Specifications document (.txt, .pdf, or .doc), including:
- Description of the project (from requirements)
- System model diagram
- Annotations describing each component of the system model
- User interface diagrams and descriptions
- Written description of the above
- Non-functional requirements (performance, testing, reliability, ease of use, portability, documentation,
dependencies on other systems)
- Updated requirements (with priorities, etc.)
- Any risky parts
Read:
Mon 2/12
In Class:
Continue talking about top-level designs.
Hand In:
- Read Specifications Documents for the other members of the class.
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.
NOTE: For the review forms, please
fill in reviews for the three students following you on the list online. If there are already three reviews for one
of those students, please pick the next student on the list.
- Update your reviews after the 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/14
In Class:
Specifications student presentations
Presentation:
- Specification 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.
Read:
- Chapters 2-6 of Mythical Man Month. Think about how this applies to the your group organization and top-level
design.
Fri 2/16
In Class:
Pick project
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 your answers.
Hand In:
Mon 2/19
In Class:
Presidents' Day, no class!
Wed 2/21
In Class:
Talk about tools, MMM essay discussion (postponed)
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.
Heads Up:
- Work on top-level designs and prepare for presentations
Fri 2/23
In Class:
Top-level design student presentations
Presentation:
- 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."
Hand In:
- Top-level Design Document, including:
- Levelized high-level component diagram(s) and description of components
- External dependencies
- Task breakdown
- Group organization
- Schedule (use the class page to help assign roles from your group)
- 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.
- 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.
Mon 2/26
In Class:
Project decision, begin MMM essay discussion
Read:
Wed 2/28
In Class:
Finish MMM essay and version control discussions
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:
Fri 3/2
In Class:
Initial group meetings and roster decision
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.
Read:
- The MMM essays, with attention to lessons relevant to roles in your
group.
Mon 3/5
In Class:
Debugging the Development Process discussion
Wed 3/7
In Class:
Group dynamics I
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.
Heads Up:
- Consider doing some of the reading that's coming up and working on the final design document, since there are
some busy days ahead.
Fri 3/9
In Class:
Schedule review, midterm evaluations and group meeting
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 completely addresses all of the following requirements.
- 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.
- 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.
- Testing strategy. All three types of testing we discussed in class should be represented.
- External dependencies
- 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.
Mon 3/12
In Class:
Programming style and interfaces
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.
Wed 3/14
In Class:
Discussion of Extreme Programming
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:
- Chapters 1-4 of Writing Solid Code.
Incorporate ideas from this reading into the component testing strategy and into your feedback on interfaces.
Fri 3/16
In Class:
Group meetings and schedule review
Read:
- Chapters 6-7 of Writing Solid Code.
Keep in mind while evaluating testing strategies and for creating designs that will be reliable and testable.
Mon 3/19
In Class:
Group Meeting
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:
Wed 3/21
In Class:
Group Dynamics II and testing discussion
Hand In:
Fri 3/23
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.
Mon 3/26
In Class:
Spring Break, no class!
Wed 3/28
In Class:
Spring Break, no class!
Fri 3/30
In Class:
Spring Break, no class!
Mon 4/2
Wed 4/4
In Class:
Group Dynamics III
Bring To Class:
Heads Up:
Fri 4/6
In Class:
Group meetings and schedule review
Hand In:
- Detailed designs for components.
Mon 4/9
In Class:
Component design presentation
Presentation:
- 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, so use printed transparencies, posters, or other graphical aids
to save presentation time! The goals here are to share with the the class what you learned that you think has lasting
value.
Hand In:
Wed 4/11
In Class:
Analysis of testing assignment
Fri 4/13
In Class:
Group meetings and schedule review
Mon 4/16
In Class:
Group meetings
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.
Wed 4/18
In Class:
Performance analysis tools
Fri 4/20
In Class:
Group meetings and schedule review
Read:
- MMM chapters "No Silver Bullet" and "No Silver Bullet Refired."
Mon 4/23
In Class:
Semester planning and group meetings
Wed 4/25
Fri 4/27
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.
Mon 4/30
In Class:
Reading Period, no class!
Heads Up:
- Prepare for public demos!
Wed 5/2
In Class:
Reading Period, no class!
Heads Up:
Fri 5/4
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:
Mon 5/7
In Class:
Post-mortems, course wrap-up, course evaluations
Public Demo:
Hand In:
Fri 5/17
Final Demo:
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.
[an error occurred while processing this directive]