Computer Systems Engineering Technology Department
Software Process Management - CST 336
Spring 2014

James N. Long

Office:                              Purvine Hall #179
Office Phone:                   885-1580
Email:                               james.long@oit.edu          
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.

Grade Percentage
>= 90
80 <= x < 90
70 <= x <80
60 <= x <70
> 60

'A' work consist of:

  1. Project deliverables completed to the highest level of detail.
  2. All artifacts fully documented.
  3. Fully implement all top priority and mid level requirements for a fully functioning project.
  4. Deploy the end project in a manner acceptable by your project sponsor.
  5. An "A" reflects, if not perfect, close to perfect conformance to deliverable specifications.

    Lab Attendance:

    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.

    Project Deliverables:

    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:

    1. Email Subject Line must have: CST 336 - "Deliverable Name" - "Team Name" . Deliverable Name should be the name of the deliverable submitted - see Task Descriptions for details. Team Name should be the name of the team.
    2. The actual deliverable should be archived in a Zip file (...not rar...not sft....) and attached to the email. Attachments larger than 20Mbyts shall be delivered in hand on a Zip drive accompanied by an email announcing the correct deliverable.

    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.