CSCI 421

Software Engineering Practicum

Spring 2008

Instructor :    Dr. George Rudolph

e-mail address : george.rudolph@citadel.edu

Office :    225 Thompson

Phone :    953-5032 (office), 953-5048 (dept office)

Office Hours:

1000-1100 MWF, 1300-1400 TR, by appointment, or stop in any time my door is open

Course Description: 

A team-based project class to apply software engineering practices in a realistic environment. The purpose of the course is to give students an opportunity to construct real-world software in a group using standard software engineering practices.

Course Pre-requisite:

CSCI-420  Software Engineering

Course Goal:

Students, as part of a team, demonstrate their ability to develop a medium sized software project. 

Course Objectives & Outcomes:  

Upon successful completion of this course, a student will be able to

• Formulate and set bounds for a problem suggested by a “real-world” client
• Design, implement and test a solution for a problem suggested by a “real-world” client
• Install and acceptance test a software system for a “real-world” client
• Write documentation associated with software development
• Choose and use appropriate software engineering methods and technologies during the software engineering process
• Work as part of a group to build a software system

Course Organization: 

Projects will be done by small teams of students (at most 4 students per team). Each team will have a separate customer.  (The job of the customer is to negotiate the project requirements with the team and to provide ongoing input about proposed solutions.)

Each team will set up their own work schedule. However, project reviews will be held weekly during the scheduled class meeting time. Each team will meet separately. 

Course Deliverables:

1.   Project Plan                                     presented during the week of  xx/xx/xx¹

2. Requirements Document                  presented during the week of xx/xx/xx¹

3. Design Document                            presented during the week of  xx/xx/xx¹

4. Build Document                              presented during the week of  xx/xx/xx¹

5. Test Plan                                        (will be part of requirements presentation)

6. Working System                             presented during the week of  xx/xx/xx¹

7. User Manual                                   presented during the week of  xx/xx/xx¹

8.    Acceptance Test Document                 presented during the week of  xx/xx/xx¹

¹Dates are part of the project plan, and therefore are set by the teams.

Course Evaluation:

A letter grade will be assigned to each of the course deliverables. Each artifact will be graded upon review, with the grade being adjusted at the end of the course, as follows. Project review sessions are also evaluated and graded.

A: The document has been reviewed, and all critical action items and corrections from the review have been made. The document is clear, concise, shows clear logical flow, analytical thought, and addresses the appropriate questions. Minor issues may exist.

B: The document has been reviewed, and most action items and corrections from the review have been made, but at leat one significant issue exists. Other than occasional lapses, the document shows clear logical flow, analytical thought, and addresses the appropriate questions.

C: The document has been reviewed, and many action items and corrections from the review have been made, but significant issues exist or remain. Intellectual standards are inconsistently applied, or key issues that should be addressed are poorly addressed or missing.

D: The document has been reviewed, and some action items and corrections from the review have been made, but significant issues have not been addressed. The document has critical errors and omissions, or shows minimal skill, understanding and almost no application of software engineering processes and principles. Document shows some logical flow but contains significant distracting irrelevancies, minimal analytical thought, and minimal effort to produce a useful document.

F: There are two ways in which a document can receive an F:

1. The document is not reviewed, or

2. The document is reviewed, but shows no logical or analytical thought, no effort to address key questions and issues, and no understanding of software engineering, and how this document fits into a process.