OREGON INSTITUTE OF TECHNOLOGY
Computer Systems Engineering Technology Department
Software Process Management - CST 336
James N. Long
Purvine Hall #179
Office Phone: 885-1580
Web Page: http://www.jnltech.com
(If I am in my office, my door is usually open. You are welcome to drop by at other times.)
Class: 4 Credits
Spring Quarter Schedule
Text Books: UML Distilled,Third Edition., Addison Wesley, 2000
Agile Software Development , Addison-Wesley, 2002
Any student with a disability who anticipates a need for accommodation in this course is encouraged to talk with the instructor about his/her needs as soon as possible.
A third course in a three-term sequence that covers the design and implementation techniques used for large computer software systems. Each student is required to work on a project as a team member.
Course Overview and Objectives
Upon completion of this two-term course sequence, a student will be able to propose, design, document and implement a large software project using a software development team. To do this, you will become part of a team that will propose, design,document and implement a large software project.
NOTE: You must complete CST 316, CST 326 and CST 336 as a sequence. If you drop out of the sequence, the entire sequence must be repeated, with or without credits.
Upon completion of this course, the student will be able to:
As a team be able to:
PREREQUISITES: Successful completion of CST 326
This term, grades will be elicited from individuals, assigned by teams and students, and assigned by the instructor. There will be four review sessions during the quarter. These will be the design review, code review, alpha release review and beta release review. For each review session, a team will be tasked with presenting their current project based on the stage requirements. This will be done first to an individual team for feedback and correction then to the rest of the class. The team under review will be tasked with compiling proposed corrections to their artifacts under review. The team under review will then have one week to perform corrections suggested during review sessions. Once all suggestions are integrated into project artifacts, the instructor will perform an assessment of the artifacts and assign a point grade. The team under review will receive 100% of the assigned points, the assigned reviewing team will receive 50% of these points, the class will receive 25% of these points. The accumulation of these points will make up 50% of an individuals overall grade.
25% of the grade will be based on evaluations of the final presentation as done by all attending the presentation. This will be during dead week.
25% of the grade will be based on self assessment of project
deliverables. Self assessment will be done on project artifacts drawn
from system development based on use case expansion from use case
specification through test cases used in alpha, beta, and final system
release. To keep self evaluation realistic, a standard grading sheet
will be used. Self grade assignments that vary drastically from the
obvious will be counted negatively against the evaluation.
Dates for review submission and class based review will be posted on the course calendar.Grades will be based on a standard percentage scale.
80 <= x < 90
70 <= x <80
60 <= x <70
'A' work consist of:
The lab will consist of demonstrations and tutorials related to how to use the process tools and what will be expected in each of the deliverables. Failure to attend lab will weaken your team knowledge of deliverables and tools.ANY LAB THAT INVOLVES SCHEDULED PRESENTATIONS MUST BE ATTENDED. Exceptions must be approved by the instructor. See course rules and regulations for further discussion.
When a team is ready to turn in a deliverable, they will inform the instructor and produce the artifacts for the deliverable. Deliverable will be turned in according to any rules that accompanied the task as specified when the task was assigned.
When the deliverable is submitted via email, it must be turned in according to the following:
Any submitted deliverable not following these requirements will be put into the recycle bin. Please QA your submissions. Poor QA is not an excuse for a faulty deliverable.