Proposal
Fall 2001 Edition
2.3. Feasibility/Justification of the Project
3.1. CMPS 490 Computer Projects
3.2. CMPS 374 Fundamentals of Software Engineering
3.3. CMPS 481 Computer Internship
3.4. SE 598-599 Master’s Thesis Project
The proposal is the first document presented by the student
for a project. This document encompasses several documents for a non-academic
project, such as Feasibility, Justification and the Business Case. It also
provides a basis for assigning the grade at the end of the project. Most of the
Proposal will be incorporated into the SRS.
The proposal is a three-five page double-spaced document
that explains the proposed project with sufficient detail that a committee of faculty
members can decide if the project is of the correct level for academic credit
and can be accomplished in the amount of time available. It is developed in
consultation with the student’s project advisor. (The page count does not include the cover sheet nor the
Gantt chart.)
The proposal provides the context of the project, an
overview of the product produced by the project, and speaks to the feasibility
that the project can be accomplished within the time and with the resources
available. It includes a time frame in terms of a Gantt chart.
The format for the proposal is much less formal than the
other documents. There must be a cover sheet with sufficient detail to fully describe
the contents. This includes the name of the project, the academic type of the
project (senior project, thesis, internship or a specified other type of
project), your name, your advisor(s) name(s) and the time frame for the project
(usually, a semester or academic year).
For example, for CMPS 490
Widget Inventory
System
Senior Project
Proposal
Joan Student
Dr. Advisor,
Departmental Advisor
Mr. Manager,
ThatCompany Advisor
Fall 2001
Or for CMPS 374,
Hanley
Scheduling System
Project
Proposal
Tom
Jones
Charlie
Brown
Sally
Brown
Dr.
Martin, Advisor
Spring
2001
The next chapter describes what is needed for the context,
the overview, and the feasibility/justification of the project. The following
chapter discusses differences among the major types of proposal. The final
chapter s details the Gantt chart.
Every project is designed to create a product that will
serve a need. In this section you provide the background for the project. Who needs
it and what is the intended user group? What is the value of the product over
the status quo? Where will it be used? What hardware and software will be
required?
This is a high level view of the product. The full details
form the Software Requirements Specification document. Start with a clear
concise description of the problem and include specific objectives for a
product that would solve the problem.
You should discuss the inputs of system — where does data
originate, when and in what form? Discuss the outputs of system — what
information is needed, by whom and in what form.
Provide an outline of what is to be included such as
backups, controls, and help features. List known constraints on performance or
language/platform.
The most critical question facing the review committee is
the level of the project. Is it too simple for the time available? Experience
has shown us that a more critical aspect is whether the project can be successfully
accomplished in the time available, that is, the proposed project is too hard
for the time period. What are you bringing to this project that will enable you
to successfully finish it? What previous courses are relevant? Do you know the
language/platform? Do you have domain knowledge (i.e., do you really understand
the project or will you need to have someone to answer questions about the
context of the project)? Finally, attach a Gantt chart that shows how you plan
to work on the various phases of the project.
In business, it is necessary to present a Business Case
(Jacobson, et al). There are always more good ideas of projects to
undertake than there are resources to undertake such projects. The Business
Case argues why this project should be the one the company should invest
its resources to develop in preference to other worthy projects. The
feasibility of a project is whether it can be reasonably done. It considers risks.
The justification of a project is whether it should be done. Because some can
be done is no reason that it should be done.
Please note that the second and third submissions are
called “Extended Abstract” in this course.
There are several submissions of the proposal. The first is
during the spring semester before the course is scheduled. Each student is
asked to submit a proposal for review. The departmental review committee
reviews each proposal and notifies the student if the proposal has been
accepted. If not, the student is informed what the problem is and is encouraged
to submit a revised proposal. With an approved proposal, the student may safely
undertake some of the software development during the summer. A Gantt chart is not
required with this submission of the proposal.
The second submission is due the first week of the fall
semester. If this is the first submission, the project is subject to committee
review at this time. If it is a second submission, it must reflect any changes
in the project that your summer work has suggested. You should address the
project in more detail in this submission. A Gantt chart is strongly
recommended. This draft will serve as a basis for a final discussion with your
project advisor.
The final submission is due early in the course and must be
approved by your project advisor. It must address all of the items, context,
overview and feasibility/justification listed above. A Gantt chart is required.
This is the project upon which your grade will be based.
There is only one submission for this proposal and it must
cover all of the necessary items. A Gantt chart is required. It is essential
that you understand the project well enough to make this proposal. Discussions
with the client (instructor) are necessary, as the project has been
intentionally vaguely stated.
In addition to the requirements stated here, there are other
specific items that must be addressed. Obtain the document Department of Computing Sciences: Internships
from the departmental secretary or the department Web site. No Gantt chart is required.
Two submissions are required, both in the spring semester
before registration for the two courses. The first is a draft and should be as
complete as possible. It is to be used as a basis for discussion with the
project advisor. The second submission is submitted in three copies and
describes the project upon which your grade will be based. The Graduate
Committee of the department will review it and notify the student of its
determination.
The Gantt Chart serves to
report the current status of a project. Different books give different rules
for these charts and the instructions contained here have been adapted from
informative and attractive Gantt charts that were submitted in CMPS 490. While
you may choose to use a variation on this style, your chart should be as
informative.
We note that there are
software tools available that will help create Gantt charts and that students
have created many excellent variations on these charts. For instance, some
students have used spreadsheet software or graphical software. Gantt charts are
freestanding and are usually required at set times during a project so that the
instructor can gauge progress. Careful attention to the Gantt chart can help
the developer understand how to estimate time better.
Attached are two charts for a single project. One is for the
start of the project and the other reports the progress about halfway through
the project. [Please note that neither the example Mathematics Placement System 2.0, Sabbatical Proposal nor the
Master’s thesis project is based on a semester.] These charts were designed
using Microsoft Word in Landscape mode and using tab settings for alignment.
The basic chart took several hours to do but once it was in place, the second
was an easy modification of (a copy of) the file. The font is Courier New as
that provides each character with a fixed amount of space. Time New Roman, used
in the rest of this document, is a proportional font that uses less space for
thin characters than wide characters. We also use 10 pt for the chart rather
than the 12 pt used in the rest of this document.
The proposed work schedule
consists of several sections. Any required artifact (document or code) must
have at least one work section whose endpoint corresponds to the delivery date
of the artifact. Large sections may have logical subsections, even if there is
not an explicit artifact (for example, Architectural Design produces certain of
the diagrams for the Software Design Document). However, there must be a way to
determine when the section is finished.
The portion of the chart at
the right shows each of these sections with the planned start and end dates. As
the project advances, planning becomes progress. Work done when scheduled is
recorded ‘S’ for Scheduled. Any work planned
to be done after the current date is also designated ‘S’ for Scheduled.
Work started before schedule is noted with a ‘B’ while work after the scheduled
time is recorded as ‘A’. Work not done when scheduled is noted with an X. This
might be because work on a section was started late or because it ended early.
At the end of the project the Gantt chart gives important feedback to help
improve estimates on future projects.
For Project Status, finished work is ‘A’ or Satisfactory,
even if finished late. Work on schedule is also ‘A’ or Satisfactory. Work that
is seriously behind is either ‘C’ for Caution or ‘F’ for Critical, depending on
how far behind it is or how much it impacts the rest of the project. The
Percent Complete estimate is an important part of this decision. There is no
fixed definition of these terms but experience has shown that software
developers usually overestimate the amounts already accomplished and
underestimate the amount of time needed to finish.
