CS361 Software Engineering I - Fall 2009 Syllabus
Our world is full of problems such as war, poverty, addiction, and pollution. Software has played and will continue to play a vital role in promoting peace, education, health, and the renewal of our planet.
But software doesn't just grow on trees. Somebody has to carefully design and create the software in a way that actually addresses the problem without making it worse, without incurring excessive costs, and without creating troublesome new problems. That's called "engineering".
Tackling big problems requires dreaming big and planning big. I love what Grady Booch says about this:
If you want to build a dog house, you can pretty much start with a pile of lumber, some nails, and a few basic tools, such as a hammer, saw, and tape measure. In a few hours, with little prior planning, you'll likely end up with a dog house that's reasonably functional...If you want to build a high-rise office building, it would be infinitely stupid for you to start with a pile of lumber, some nails, and a few basic tools. Because you are probably using other people's money, they will demand to have input into the size, shape, and style of the building.... You will want to do extensive planning, because the cost of failure is high. You will be just a part of a much larger group responsible for developing and deploying the building, and so the team will need all sorts of blueprints and models to communicate with one another....
Building doghouse-sized software isn't going to make a meaningful impact on the big problems of our day. This course will give you the skills needed to analyze big problems, discover the requirements for a solution, design a solution, and manage the solution's implementation.
Do you want to build doghouses? Or do you want to change the world?
At the completion of the course, students will be able to...
- Select the most appropriate software process model to use in a particular situation
- See slides 14-18 of lecture on Process
- Synthesize requirements for a realistic software system and write a requirements specification document
- See lecture on Requirements
- Model system requirements using one or more semi-formal notations such as UML, dataflow diagrams, entity-relationship diagrams, or state diagrams
- See lecture on Diagram notations
- Design software systems at an architectural level and at lower levels, using one or more techniques, such as object-oriented design or agile methods, and express these designs in design specification documents
- See lecture on Architecture
- Validate designs and adjust the specification or design as necessary
- See lecture on Evaluating architecture
- Describe several methods of estimating the cost and developing a schedule for a programming project
- See lecture on Schedule and effort
- Participate effectively in a team environment
- See lecture on Individuals and interactions, and lecture on Professionalism
- Produce professional-quality software-related documents
- See lecture on Diagram notations, and lecture on Architecture
Prerequisites: CS261
Lectures: Tuesdays and Thursdays 4pm-5:20pm, Kelley Engineering Center 1003
Required textbook: Software Engineering - Theory and Practice, 4th Edition by Pfleeger & Atlee
Optional textbook: Waltzing with Bears by Tom DeMarco & Timothy Lister
Instructor: Christopher Scaffidi cscaffid@eecs.oregonstate.edu
Office hours: Monday, Wednesday, Thursday 1pm - 2pm in KEC 3047
Teaching assistant: Vignesh Viswanathan viswanvi@onid.orst.edu
Office hours: Friday 2:30 - 3:30
Website: http://web.engr.oregonstate.edu/~cscaffid/CS361_F09.shtml
Team assignments for the second half of the term: Click here for details
|
Grading
Grading weights: 2/3 homeworks, 1/3 final exam
Except for the midterm exam (HW6), all homeworks must be submitted electronically
through Blackboard
as
PDF files. To produce PDF files, you can create your documents with
Google Docs (which lets you convert docs
to PDF). Alternatively, on Windows, you can install the free PDF995 software,
which creates a virtual "printer" that saves printouts from any editor as PDF
files. (Using PDF995 requires you to download and install two files, the
Pdf995 Printer Driver and the Free
Converter.) If you have a Mac, just ask a friend for help making PDFs; it's apparently pretty easy
(I don't use a Mac). A final option if you have very legible handwriting is to
do all your work on paper, then scan the paper into PDF using an image scanner
(or if you have exceptionally big and clear handwriting, take a
photograph and convert the photo to PDF). Students with Disabilities Accommodations are collaborative efforts between students, faculty and Services for Disability Access Service (DAS). Students with disabilities approved through DAS are responsible for contacting the faculty member in charge of the course prior to or during the first week of the term to discuss accommodations. Students who believe they are eligible for accommodations but who have not yet obtained approval through DAS should contact DAS immediately at 541-737-4098. |
Grades
|
| Date | To be covered in class | Read prior to class | Due prior to class |
|---|---|---|---|
| Part I: Overview of Software Engineering | |||
| Tuesday Sep 29 | Overview | ||
| Thursday Oct 1 | Process |
Sidebar 1.1 (pg 6), Sections 1.3, 1.5-1.8 |
Your Vision Statement |
|
Part II: Waterfall process with prototyping |
|||
| Tuesday Oct 6 | Requirements | Sections 4.1-4.4 | HW1 (individual): SE overview |
| Thursday Oct 8 | Diagram notations | Section 4.5 | |
| Tuesday Oct 13 | Paper prototyping | Overview of paper prototyping and Discussion about risk | HW2 (team): Requirements |
| Thursday Oct 15 | Evaluating requirements | Sections 4.7-4.9 | |
| Tuesday Oct 20 | Architecture | Sections 5.1, 5.4-5.5, 5.7 | HW3 (team): Req. Evaluation |
| Thursday Oct 22 | Evaluating architecture
Pop quiz |
Sections 5.3, 5.9-5.10 | |
| Tuesday Oct 27 | OO design overview | Sections 6.2-6.4, 6.8 | HW4 (team): Architecture |
| Thursday Oct 29 | Design Patterns
Pop quiz |
Sections 6.5-6.6 | |
| Tuesday Nov 3 | Schedule and effort | Sections 3.1-3.4, 3.7 | HW5 (team): Implementation design |
|
Part III: Extreme programming process | |||
| Thursday Nov 5 | Agile overview | Sections 2.1-2.2, Sidebar 4.2 (p. 145), Entire Agile Manifesto website | Updated Vision Statement (individual) |
| Tuesday Nov 10 | Customer collaboration | Entire XP website and Entire Agile process website | HW6 (individual): Take-home midterm (counts as a double homework) |
| Thursday Nov 12 | Working software | Sections 8.1-8.3 | |
| Tuesday Nov 17 | Individuals and interactions | Sidebar 5.1 (p. 230), When is it not XP? and Misconceptions about XP | HW7 (team): User stories and set-up |
| Thursday Nov 19 | Continuous improvement | Sections 3-6 of Personal Software Process | |
| Tuesday Nov 24 | Professionalism (Don't skip class today) |
Engineering professionalism and ACM/IEEE code of ethics | HW8 (team): First implementation |
| Thursday Nov 26 | <<No Lecture>> | ||
| Tuesday Dec 1 | <<Final Exam Review>> Attending class is optional (today only) |
<<Review the slides from previous lectures>> | |
| Thursday Dec 3 | <<Team presentations>> | HW9 (team): Second implementation | |
| Dec 10, 6pm-7:50pm | <<Final exam>>> | Review your notes and all my lecture slides | Final Vision Statement |
You will mostly work in teams of 4-6 students. Each team will design and/or implement a software system based on ideas that you provide.
Here's how it will work:
- In the first week of class, each student will submit a Vision Statement. This statement will describe a software system that you believe will help to make the world a better place.
- I will post all Vision Statements on the web. All students will vote on what vision statements they find most compelling.
- I will pick the top few Vision Statements, based on popularity. While Vision Statements will not receive grades, the authors of the top Vision Statements will receive extra credit for the course and will serve as "customers" for the systems that they envisioned.
- I will assign you to teams based on which of the top Vision Statements you are interested in. Note that I cannot promise that I will assign you to your favorite choice, since I need to keep the teams fairly equally-sized.
- For homeworks 2 through 5, each team will design a system based on their
assigned Vision Statement (and input from the vision's customer). These will be graded as described below.
Then we break up the teams and start over again in new teams on a second project:
- At the midpoint of the course, each student will submit an updated Vision Statement. This will give you a chance to improve it or rewrite it completely, based on your classmates' feedback.
- I will again post all updated Vision Statements on the web, students will vote again, and new teams will be formed based on the top few updated Vision Statements. Extra credit will again be given.
- For homeworks 7 through 9, each team will design and implement a system based on their assigned Vision Statement and customer input. You will also present your system on the final day of class.
- At the end of the term, each student will submit a final revision of the Vision Statement.
Be forewarned that every single homework will require a lot of work. Do not wait until the night before to start the homework; you will be dismayed. Start on each homework the week before it is due, and spread the work throughout the week. Also spread out the work over the entire team. There is so much work that it would be hard for a single person to do it all.
As noted above, every student must make a contribution to every homework. When your team submits each homework, you must indicate what each team member contributed. Individual team members will usually get approximately the same grade on each team homework, but individual team member grades may be reduced depending on the quality and quantity of their contribution.
At the end of each project (ie: at the mid-point of the term and at the end of the term), each team member will assign points (confidentially) to the other team members. The top-rated student in each team will receive extra credit.
In extreme cases, a team can decide to fire a member for cause on or before the day that the team's first homework is due (ie: HW2 or HW8). To do this, the team members must first attempt to discuss potential firing with the teammate, and then contact me and make their case for why the teammate should be fired. Fired team members may join together (if there are others who are willing to join you), or may continue the course as a one-person team. Since being a one-person team would mean a lot of work, it would be sensible to avoid getting fired.
If your team is extremely successful at designing and implementing a system that will really benefit the world, then I will consider offering you a paying job as an undergraduate research assistant after the term ends. This research and development funding would enable you to continue developing the system, to deploy your system, to evaluate how well it actually helps people, and to publicize your accomplishments in a broader research venue. While this would be good for your resume and future employability, the real reward is the opportunity to make a deep, lasting impact on your world.