Project Overview Page

Course Intent and Format

The Senior Project Laboratory, more commonly referred to as the Senior Individual Project Course, or better yet, simply 402, drives home the software engineering lessons you learned (hopefully!) during the prior semester in CMSI 401. Where the previous experience is within a group setting, this project course will ensure you each get the opportunity to act as project manager, chief architect, designer, coder, test/quality assurance, and documentation book boss. The resulting project applications will be presented to the LMU community at a special meeting during finals week.

In order to direct the development effort (and to facilitate assigning grades), you will complete several activities, each of which is a slightly scaled-down version of a real world software engineering activity. The intent of the course is to teach you how to perform these activities and why each is important; a secondary course goal is to expose you to as much of the available software engineering methodology as is possible in a semester. This is done by a combination of reading the material, by doing the activities yourself, and by listening to your humble professor blather on about it.

IMPORTANT SAFETY TIP:

ASK AS MANY QUESTIONS AS YOU CAN THINK OF about the software engineering process! The more questions you ask, the more information you'll pick up, and the better prepared you'll be when you graduate!

More About Deliverables

In real life software engineering, a significant portion of the project development effort is spent in documentation of the project, including its proposal, solution analysis, requirements specification, as well as architectural and process design, development plan, testing plan, and scheduled deliveries and demonstrations. 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 these deliverables is combined into the SDF.

The class will meet once per week, for 2-1/2 hours at a stretch. Each of you will present your own work, from proposal through final presentation. There will also be several status reports to be delivered as mini-presentations. You will each need to be capable of doing a slide show of some type, either using a PDF, in Open Office Impress, or (ACH!) Microsoft Power Point. There will be several of the class periods during which your presentations will fill the entire class time. Other classes will be guest speakers who will talk about general topics relating to software development in the industry, and what they do at their companies.

Don't forget that this is likely your last semester as an undergraduate; as such it's the final opportunity to get this kind of one-on-one academic input. It is in your best interest to ask as many of your questions now as you can — this is the place to make your mistakes and to learn from them! I'm a big believer in what is known as experiential learning, so feel free to treat this class as an experience similar to an apprentice-ship.

Each project activity will focus on a particular deliverable. A deliverable is a written and/or spoken report that describes a particular part of the project. Each one is delivered to the customer, your humble instructor. The deliverables and their associated due dates are shown in table 1. Each deliverable is described in detail in a separate web page or handout, which is linked from the table. There is also a listing to the table of contents of the SDF, as well as some handy links to sample documents for a trivial web-based temperature converter I created for the purpose. Since these links are made with html hash tags you can bookmark them easily to refer to during the semester.

In industry, many of these deliverables are separate documents. For example, there is a Software Development Plan, a Software Requirements Specification, a Software Interface Configuration Document, a Database Design Description, a Sofware Quality Program Plan, and many others. Each of the notebook sections for the project SDF corresponds to one of these industry documents. This is why the notebook 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 several of these documents, and to become familiar (perhaps even proficient) with many of the different types of documentation required in industry.

If the initial document is poorly written, little time will be spent trying to give constructive criticism on it. This, in turn, will most likely lead to a poor grade on the report, unless you are able to anticipate what is expected and produce a perfect (according to the instructor) report. A very well-written report might still receive a few comments, yet will eventually result in a good grade, as well as time saved for you in the long run.

The bottom line on deliverables, then, is that each deliverable is a SDF section, 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.

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.

As you can see, there is a significant amount of work to be done. For each of the deliverables, you will turn in the entire SDF to that point. If there is a presentation associated with that deliverable, you will also present the information. SDFs will be graded and handed back by the next week. If corrections are needed, it is expected that they will be completed as part of the next deliverable in the schedule. For example, if there are fixes required in the Requirement Specification as a result of D#02, those changes are expected to be incorporated when the SDF is submitted as part of D#03. Failure to make required changes will cause the lowered grades for the section to remain, but if the changes are all incorporated, you'll get full credit. This gives you a second chance to get the maximum score for each of the deliverable sections of the document, and will give you some practice editing and incorporating comments, which happens a lot to software engineers.

Status Reports

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, even if they are not specifically noted in the table or in the deliverable requirements. Written status reports (deliverable D#09) are due on the dates shown in the table. There should be a section, page, or other division of your SDF devoted to status reports, and it should be updated for each submission. The course web site contains an example status report form, or you may design your 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 general format of accomplishments, upcoming plans, and identified risks. Status reports are standard fare in the work place, so this is a good time to become proficient at writing them.

A word about status reporting: Status reports are really important for tracking your own progress. As a project is developed, being able to see which milestones are approaching, which ones have passed, and which ones are late can help you understand where you need to focus more effort for success. Status reports should also include a section for identified problems and possible solutions to those problems — this is the whole idea behind risk mitigation.

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. See the material on the PSP page for more ideas.

By the way, accurate billing involves more than just making sure you get enough for the tasks 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 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.

There are sample documents in various formats on the assignments page just under the extra credit page link.

Lessons Learned From Past Projects

Here are some comments from previous years that may help you in this class.

• Take version control seriously.
• Hold firm to scheduled delivery dates.
• Everything takes a lot longer than you think it will, and even longer than that.
• This has been the most worthwhile course I have taken since I learned to write in the first grade... I've learned a lot about computing, time management, people management, and my ability to stay on the computer for days at a time. I even liked the course. There is only one major problem. My GPA is dropping faster than a wingless airplane because I've spent my semester working on 402.
• I think we need to strictly follow all the scheduled deadlines so that we would not fall behind in any stages of the project. This is important because we always have to spend time on matters relevant to the project that we never have expected, especially towards [sic] end of the semester.

More projects have gone awry for lack of calendar time than for all other causes combined.

-- Fred Brooks

SDF Outline

The following outline shows the format for a hardcopy version of the project SDF. Some tailoring is expected, but the general format and flow is what you will see in the wild. NOTE: This is an EXAMPLE ONLY!! You do not need to do all of these sections for your project! You will only be responsible for the sections and related activites that are highlighted in GREEN on the course documents page.

                   Cover Sheet or Title page
                   Table of Contents
            1.0    Project Status Sheets                                      1-1
            2.0    Preliminary Project Proposal                               2-1
            3.0    Proposal Document and All Project Presentation Slides      3-1

            4.0    Software Development Plan                                  4-1
            4.1    Plan Introduction                                          4-1
            4.1.1  Project Deliverables                                       4-1
            4.2    Project Resources                                          4-1
            4.2.1  Hardware Resources                                         4-2
            4.2.2  Software Resources                                         4-3
            4.3    Project Organization                                       4-4
            4.4    Project Schedule                                           4-5
            4.4.1  PERT / GANTT Chart                                         4-6
            4.4.2  Task / Resource Table                                      4-8

            5.0    Requirements Document                                      5-1
            5.1    Introduction                                               5-1
            5.2    Functional Requirements                                    5-1
            5.2.1  Functional Requirement 1                                   5-1
                           .
                           .
                           .
            5.2.n  Functional Requirement n                                   5-10
            5.3    Performance Requirements                                   5-10
            5.3.1  Performance Requirement 1                                  5-11
                           .
                           .
                           .
            5.3.n  Performance Requirement n                                  5-23
            5.4    Environment Requirements                                   5-23
            5.4.1  Development Environment Requirements                       5-24
            5.4.2  Execution Environment Requirements                         5-26

            6.0    Software/Database Design Description                       6-1
            6.1.   Introduction                                               6-1
            6.1.1  System Objectives                                          6-1
            6.1.2  Hardware, Software, and Human Interfaces                   6-1
            6.2.   Major Software Functions                                   6-4
            6.2.1  Software Function 1                                        6-4
                           .
                           .
                           .
            6.2.n  Software Function n                                        6-11
            6.3.   Class Descriptions                                         6-11
            6.3.1  Major Class Description 1                                  6-11
                           .
                           .
                           .
            6.3.n  Major Class Description n                                  6-31

            7.0    Configuration Management Plan                              7-1
            7.1    SwCM Activities                                            7-1
            7.1.1  Configuration Identification                               7-3
            7.1.2  Configuration Control                                      7-4
            7.2    SwCM Schedules                                             7-6
            7.3.   SwCM Software/Hardware Resources                           7-7

            8.0    Test Plans                                                 8-1
            8.1    Introduction                                               8-1
            8.2    Unit Test Plan                                             8-1
            8.2.1  Unit Tests Planned                                         8-2
            8.2.2  Unit Test Procedures                                       8-7
            8.3    Integration Test Plan                                      8-12
            8.3.1  Integration Tests Planned                                  8-13
            8.3.2  Integration Test Procedures                                8-16
            8.4    Acceptance Test Plan                                       8-20
            8.4.1  Acceptance Tests Planned                                   8-21
            8.4.2  Final Acceptance Test Procedures                           8-23
            8.5    Test Configuration Control                                 8-33
            8.6    Items Not Tested                                           8-34
            8.7    Test Verification Matrix                                   8-36

            9.0    User's Manual and Installation Guide                       9-1
           10.0    Lessons Learned                                           10-1
           11.0    Document History
           12.0    Reviewer/Auditor Comments
           13.0    Notes
           14.0    Project Source Code
      

The listing above shows the format for the Table of Contents, which is the sequence that the sections of your SDF should take. However, it is important for you to number the pages in each section of the document with both the section number and page number, such as 1-1. The TOC entries then must also contain the page number next to each section, as demonstrated in the above TOC sample. Of course, these are sample page numbers; the actual values will be different for each document.

Notice there is no section listed in the TOC which goes lower than three number levels. This fact keeps the TOC from becoming dot-heavy. If there are sections containing four or more numbers, e.g., 5.4.3.2 or 6.1.2.1.5.6.99, only show the sections in which those sub-sections are contained on the TOC down to the third number, e.g., 5.4.3 or 6.1.2.

Also, notice the last four sections have no page numbers. This is because:

1. The history section contains old pages from all sections, so doesn't neet to be numbered for its own section numbering
2. The Reviewer/Auditor comments section is where to put the instructor comment sheets from deliverables and the comment sheets from peer reviews; thus, it needs no page numbers
3. The notes section is for any notes, scratches, diner napkins, cell phone photos of white board scribbling, and other such like which you have used to jot down designs and notes.
4. In the spirit of being green, you will not need to print out your source code for this project. All source is expected to be a code repository such as github, and will thus be readily available to whoever wants to see it, get it, and run it. The SDF would normally have a single page that re-directs the reader to the repository; in your case, the repository should be easy to locate, given the nature of modern online code tools.

Links to Sample Documents

 The following links will provide access to 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.):

1. Request for Proposal (RFP) [Word] [PDF]
2. Proposal Document [Word] [PDF]
3. Statement of Work Document [Word] [PDF]
4. Requirements Specification [Word] [PDF]
5. TempAppConv HTML Main Page [HTML] [code]
6. About Page HTML Page[HTML] [code]
7. TempAppConv Class code (text ver)
8. ButtonPanel Class code (text ver)
9. InputPanel Class code (text ver)

Reminder: Point of This Course

• Opportunity to apply your computer science knowledge
• Opportunity to show off your computer programming prowess
• Opportunity to learn the discipline of software engineering
• Opportunity to have fun with your student colleagues
• Opportunity to learn and implement Process
• Opportunity to practice the art of computer programming

Next Document