Course Objectives

    1. Introduce students to the concepts and techniques required to build large software systems
    2. Provide an opportunity to obtain practical experience applying the techniques on an actual development effort.

Grading
Evaluation Percentage
Project 55%
Midterm 20%
Final 20%
Class participation  5%

Date  Topic Project Milestones Due Reading
1/11 Introduction (html, Postscript)   Chapter 1
1/13 Project teams
(html, Postscript)
and planning
(html, Postscript)
and management
(html, Postscript)		   Chapter 5
1/18 Project plans Project Description
1/20 Risk management  
1/25 Requirements
(html, Postscript)		 Project Plan  Chapter 6
1/27 In-class requirements exercise   Chapter 7
2/1 Design (html, Postscript) Requirements
2/3 Design exercise
   Chapter 8
2/8 Testing (html, Postscript)
 Design Chapter 22
2/10 Cleanroom (html, Postscript)
Usage Testing (html, Postscript)
   Chapter 23
2/15 Presentations
(html, Postscript)
Introduction to Software Process
(html, Postscript)
 Test Plan  Chapter 4
2/17 Process assessment
(html, Postscript)

2/22 Demos Test Report
Product Delivery
2/24 Demos  
3/1 Midterm

3/3 Planning revisited
  
3/8 Requirements elicitation exercise
 Process Plan Resubmit and Evaluation 
3/10 Requirements modeling exercise

3/15 Object-Oriented Design
(html, Postscript)
   Chapter 14
3/17 Software Architecture
(html, Postscript)
   Chapter 11
3/22 Spring Break - no class  
3/24 Spring Break - no class

3/29 Midterm debrief
  
3/31 Design and code reviews
(html, Postscript)

4/5 In-class code review
 Requirements Specification Resubmit 
4/7 UI Design Exercise
  
4/12 User Interface Design
(html, Postscript)
 Design Resubmit  Chapter 16
4/14 Formal Verification
(html1, Postscript1)
(html2, Postscript2)
   Chapter 27
4/19 Refactoring
(html, Postscript)
Program versions (doc)
 Test Report Due 
4/21 Guest speaker: John Chilensky; Boeing
(Materials)
 
4/26 Demos Test Report Resubmit
Delivery

4/28 Demos  

Teams

A each team should be made up of four or five members, no exceptions. Moreover, in order to form roughly equal teams, if you have five members, one member may be asked to join another team. Also, if you have four members, an additional member may be added. If one or more members of your team drops the class, you are expected to complete the project, making suitable adjustments to its scope.

Rules for deliverables

  1. All deliverables should be placed on the Swiki
  2. A section should exist on the Team page called Deliverables
  3. A link should be placed to each deliverable, labeled appropriately
  4. Deliverables are due by 3:00pm on the due date
  5. A deliverables should be printable directly from a web browser. What this means is that they should be in text, HTML, or PDF format. Embedded graphics and diagrams should be exported into GIF or JPG. Doc, xls, and ppt files are prohibited.

Regrade policy

All documents are living; that is, they should be updated as the project progresses. All are initially due on the dates given above. At that time you may not yet have been exposed to all of the material required to do a complete job on that deliverable. You will be given feedback on your initial deliverable and allowed to resubmit it with corrections.
 
In order to have one of your deliverables regraded, you must do the following:
Deliverable Weight Template or Description Grading Criteria Original Due Date Last Regrade Date
Project description 5% Project description
1/18 1/18 (no regrades)
Project Plan 16% Project planning Project planning 1/25 3/8
Requirements 16% Requirements Requirements 2/1 4/5
Design 16% Design Design  2/8 4/12
Test Plan 11% Test plan Test Plan 2/15 4/19
Test Report 11% Test plan
2/22 4/26
Demo 5%

2/22 4/26
Delivery 20% Delivery Delivery 2/22 4/26

Individual contributions

Software development projects inherently comprise teams of cooperating individuals. But not every individual contributes equally. As part of the evaluation of your project, you must complete a document that includes a description of your individual effort and contributions and your assessment of the contributions of the other members of your team. A form you should use for constructing this document is given here.

References

Practical software engineering

Requirements

Architecture

Design

Coding

Testing

Other Resources