The Software Engineering Laboratory, more commonly referred to as
Senior Group Project Course, Senior Project, or officially as the
Senior Capstone Project
, introduces the essential software engineering
principles that guide the design, management, implementation, deployment, and maintenance of software
development projects. We introduce the topics through lectures and in-class work, but the best way
to understand this subject is to experience it first-hand, with chances to get your hands dirty
under the hood
. Therefore, most of your time will be spent designing, managing, and implementing
medium- to large-sized group projects in [usually] four- to six-person teams. The quality of the
final product will depend upon both the abilities of the students on the teams and the dedication of
each class member. The final project products themselves will be presented to the LMU community at a
special meeting during [or the week before] finals week.
In order to direct the development effort and to evaluate the projects, students complete several
activities. Each of these activities is a somewhat scaled-down version of real world
software
engineering activities. The intent of the course is to acquaint the student with how to perform these
activities and why each is important; a secondary course goal is to expose the students to as much of
the available software engineering methodology as possible.
NOTE: UPDATED 2020-09-19 — In this regard, a significant portion of the project development effort is spent in the documentation of the project, including its proposal, solution analysis, requirements specification, architectural and process design, development plan, testing plan, and scheduled deliveries and demonstration. All of these are essential parts of the process as practiced in industry. Each of these documentation exercises is treated as one of a set of customer-deliverable entities, or
deliverables. The full set of deliverables is combined into the software development folder [SDF]. The SDF used to comprise a 3-ring binder with each document in its own section, but in the modern software development we don't use paper as much, so we save trees and use GitHub. The SDF is turned in for each deliverable according to the schedule in the table below, and is also submitted for archiving purposes at the end of the term. The SDF is therefore aFOLDERin name only.
Also you should note: in the real world of software development, you will spend a significant amount of time doing things that ARE NOT code! You will be writing documents, attending design meetings, holding code reviews, planning and reporting all of your work, asking for help or guidance, dealing with customers and team memebers, and many other items and activites too numerous to list here. To that end, I will do my best to give you as realistic an experience as possible by providing two things: 1) exposure and practice doing some [not all] of these activites so you get a chance to do them in a safe environment and to see why they are important; and 2) time in class to work on your code, have group meetings, and do some other group tasks that are made more difficult by the distributed nature of the class team environment and the on-line nature of the class.
Each project activity will focus on a particular "deliverable." A deliverable is a written and/or
spoken work product that describes a particular part of the project. Each
one is delivered to the customer, or in this case, the instructor. The deliverables and their
associated due dates are shown in Table 1. Each of them is described in detail
on its own separate web page. Note that the grade weights for each deliverable are listed in
Table 2. A complete table of contents for your entire SDF is shown below on
this page under SDF Outline
. The section numbers are what you should use
for your documents in your repositories on GitHub, which is where the documents will be submitted.
In industry, many of these deliverables are separate documents. For example, there is a Software
Development Plan [SDP]
, a Software Requirements Specification [SRS]
, a Software
Interface Configuration Document [ICD]
, and many others. Each of the repository sections for the
project SDF corresponds to one of these industry documents. This is why the repo has so many sections,
and incidentally is why the sections seem to contain some redundant information. The idea of the LMU
project SDF is to provide each student with the opportunity to create one or more of these documents,
and to become familiar with many of the different types of documentation required in industry. The
results become the SDF for this course.
It is recommended that ach team member on the project be assigned at least one section of the project
SDF, and she will be the primary person for that deliverable/document section. One team member may
be designated as the notebook master editor, or book boss
, whose job is to ensure that required
deliverables/sections are completed, and committed to GitHub on time. The book boss should also set
deadlines for when the other team members must submit their assigned deliverable, in order to provide
herself enough time to review the entire document from start to finish to prevent inconsistencies.
Being a book boss does not mean writing the entire document and does not mean doing all the typing. Remember: The primary responsibility of the book boss is to make sure that the document is turned in on time, has been read all the way through by at least one person and is a product of which the entire team can be proud.
Each deliverable/section will be evaluated after submission, and feedback will be provided to the team
in the form of a document feedback
text file. As you would have in industry, you will have a
second chance at the document; if you incorporate the changes specified in the feedback file by the end
of the term, you will get full credit for that deliverable. Note that several specific deliverables
are handled this way.
The bottom line on deliverables
, then, is that each deliverable is a section in the SDF, with
some deliverables also requiring oral presentations. Also note that due to semester time constraints,
there are several deliverables that are due at the same time, with a corresponding presentation for
all pertinent sections for that date.
| Table 1: Deliverables and Due Dates | ||
|---|---|---|
| Number | Deliverable | Due Date |
| D#01 | Project Proposal Presentation / Document | Week 02 |
| D#02 | Requirements Specification Initial Development Schedule [Part of SDP draft] |
Week 05 |
| D#03 | [This requirement has been removed to allow more time for development] |
|
| D#04 | Software Design Description Document [Architecture Section] | Week 10 |
| D#05 | Software Design Description Document [Complete] [This requirement is combined with the following presentation] |
Week 12 |
| D#06 | ALPHA/BETA/Critical Design Review Presentation/Demonstration | Weeks 12 & 14 |
| D#07 | User's Manual Final Updates — belongs in your project README.md file [This requirement has been removed to allow more time for development] |
Week 15 |
| D#08 | FINAL PROJECT PRESENTATIONS | Week 15 |
| D#09 | FINAL Product Delivery (Final Report and Code) All Documentation Final Updates Completed/Committed |
Week 16 … Code Freeze |
| D#10 | Oral Status Reports | Week 07 through Week 15 and part of all presentations |
| D#11 | Written Status Reports in the project SDF [Can be quad chart or other format; whatever fits your method] |
Every other week starting at Week 06 |
The color key to the above table is that as each deliverable is delivered, the row for that deliverable
will be grayed-out
. The next deliverable will be highlighted
in green for easy reference.
Oral status reports are due at the class meetings shown in the table above, and are also expected to be part of any oral presentation. Written status reports are due on the dates shown. The course web site contains an example status report form, or the student teams may design their own form, as long as all the required status information shown in the example form is present. Both oral and written status reports are to follow the same format. Status reports are standard fare in the work place, so this is a good time to become proficient at them.
Oral status will follow the idea of the weekly scrum
which is an adaptation of the idea
from Agile methods which is calle the daily stand-up
. You'll be told in class how this
works and shown a video of it as well.
Status reports are also a handy mechanism for documenting the amount of time you have spent on a project, which is very important when you are employed as a consultant. The more you know about the time required to complete a task, the better you can forecast the next job, so you can bill your clients accurately.
By the way, accurate billing involves more than just making sure you get enough for the task you will
do. It also means that you don't "underbid" the amount of work that you must do on a job so that you
wind up spending vastly more time than your contract will pay you for. In this case, you have no
choice but to do the work for the paltry sum that you are contractually entitled to. This is known
as eating the difference
, or simply as eating it.
Your final grade for the project makes up 80% of the grade for the course. The project grade will be weighted as follows [repeated and expanded from the Syllabus page]:
| Table 2: Deliverables and Grade Weights | |||
|---|---|---|---|
| Deliverable # | Deliverable Section | Item Wt. | Deliverable Wt. |
| D#01 | Project Proposal Presentation / Document | 5% | 5% |
| D#02 | Requirements Specification | 8% | 10% |
| Initial Development Schedule [Software Develpment Plan] | 2% | ||
| D#03 | Software Develpment Plan [completed] | 5% | 5% |
| D#04 | Architectural Design Specification [SDD Preliminary] | 10% | 10% |
| D#05 | Detailed Design Specification [SDD Complete] | 10% | 15% |
| Project CDR Presentation | 5% | ||
| D#06 | Alpha/Beta Presentation/Demonstration | 10% | 15% |
| Unit Test and Integration Plan | 5% | ||
| D#07 | User's Manual Interim Updates | 1% | 1% |
| D#08 | Final Product Delivery [Final SDF and code] | 15% | 20% |
| Users Manual Final Updates | 5% | ||
| D#09 | Final Project Presentation [LSB Auditorium] | 15% | 15% |
| D#10 | Oral Status Reports | 2% | 2% |
| D#11 | Written Status Reports | 2% | 2% |
| Totals [note that project grade is 80% of total course grade] | 100% | 100% | |
Here are some comments from previous years that may help you in this class.
"More projects have gone awry for lack of calendar time than for all other causes combined."
-- Fred Brooks
The following outline shows the format for the project SDF. Some changes are expected [in industry
this is called tailoring
], but the general format and flow should be as shown. Anything that
is highlighted in green is something you are responsible for doing in this
course, which includes all the sections under that header, where applicable. Anything that is in
strike-through text you are not responsible for, but the sections are left in so that
you can see what an industry document will require that you are NOT required to do. Sections 11, 12,
13, and 14 are optional but may have some value to you during your development effort.
Cover Sheet or Title page
Table of Contents
Project Status Sheets
1.0 Preliminary Project Proposal Document
2.0 Proposal Document and Presentation Slides
3.0 Needs Analysis
3.1 Introduction
3.2 Audience
3.3 Stakeholders
3.4 Critical Success Factors
3.5 Conceptual Solution Design
4.0 Software Development Plan
4.1 Plan Introduction
4.1.1 Project Deliverables
4.2 Project Resources
4.2.1 Hardware Resources
4.2.2 Software Resources
4.3 Project Organization
4.4 Project Schedule
4.4.1 PERT / GANTT Chart
4.4.2 Task / Resource Table
4.4.3 Class Schedule
5.0 Requirements Specification
5.1 Introduction
5.2. CSCI Component Breakdown
5.3 Functional Requirements by CSC
5.3.1 Functional Requirement 1
.
.
.
5.3.n Functional Requirement n
5.4 Performance Requirements by CSC
5.4.1 Performance Requirement 1
.
.
.
5.4.n Performance Requirement n
5.5 Project Environment Requirements
5.5.1 Development Environment Requirements
5.5.2 Execution Environment Requirements
6.0 Architectural Design Document
6.1. Introduction
6.1.1 System Objectives
6.1.2 Hardware, Software, and Human Interfaces
6.2. CSCI Descriptions
6.2.1 Concept of Execution
6.2.2 Interface Design
6.2.2.1 Interface Identification and Diagrams
6.2.2.2 Project Interactions
6.3 Preliminary User Manual
7.0 Detailed Design Specification
7.1 Introduction
7.2 Detailed Design Description
7.2.1 CSC 1 Descriptions
7.2.1.1 CSU 1 Description
.
.
.
7.2.1.n CSU n Description
<similar sections for all CSCs 1 through m-1>
7.2.m CSC m Descriptions
7.2.m.1 CSU 1 Description
.
.
.
7.2.m.n CSU n Description
7.3 Database CSU Design Description (if applicable)
7.3.1 CSU 1 Description
.
.
.
7.3.n CSU n Description
7.4 Detailed Interface Descriptions
8.0 Process Model
8.1 Introduction
8.2 Data Provision / Translation
8.3 Data Processing
8.4 Internal Data Translation
9.0 Configuration Management Plan
10.0 Testing
10.1 Unit Test Plan
10.1.1 Unit Test Descriptions
10.1.1.1 Unit Test 1
.
.
.
10.1.1.n Unit Test n
10.1.2 Unit Test Requirements Trace
10.2 Integration Test Plan
10.2.1 Integration Test Descriptions
10.2.1.1 Integration Test 1
.
.
.
10.2.1.n Integration Test n
10.2.2 Integration Test Requirements Trace
11.0 Lessons Learned
12.0 Document History
13.0 Reviewer/Auditor Comments
14.0 Notes
15.0 Project Source Code
15.1 Description of Code Location in CM Repository
At student request, here are links to a set of companion documents that go with the sample project called "TempConvApp". This project presents a browser-based Java Applet that converts temperature values from one scale (like Celsius) to four others (like Kelvin, etc.). Here are the links:
show offyour computer programming prowess
artand
craftof computer programming