Course: CPS 622 Software Project Management
Semester: Summer 2023 Final Project Description
Due August 4th 11:55 PM EDT
Description
For your final project, you will select a project area of your choosing and act as a team lead to do
some project planning. Instead of planning out the fiscal aspects of a project, you will instead focus
on the technical content. I am expecting you to pick a project area that you have some background
or experience with, so that you don’t need to perform lots of background research. You may work
on this with one other classmate, for a total group size of 2.
Report Format
The report must be in the following format
• Word document submission, or a PDF.
• 12 pt Arial font for all text, and a minimum of 10 pt Arial font for figures or tables.
• 1” margins, double-spaced, no space before/after a paragraph
Project Deliverables for the Assignment
1. Propose a software project topic in an area of your choosing.
(a) Create an “elevator pitch”, which is a 1-2 paragraph description of your project. In this
pitch, you need to give a brief overview of the scope of the work, the need for the work,
the approach, your expected results.
(b) Prepare a high level architectural diagram that describes the project. Graphically show
how major components of your project will interact with each other, component connections, data flow, etc. This can be using UML, or any graphing format of your choosing.
Keep this diagram to no more than a 1 standard 8.5×11 page.
(c) Provide a detailed description of your architectural diagram, assuming that the reader
has a technical background, and would understand a high level discussion of the software
development process of this specific project. Discuss the software and resources that are
needed to perform the development for this product, and any software that is needed
for deployment (ie. database tools, website servers, etc.). This section should take you
at least 2 full pages, but you can use up to 5 total pages.
2. Develop a table that shows all of your main tasks and their subtasks.
(a) The project must have at least 3 major tasks. Each major task must have at least 5
subtasks, that are unique to them only. This means, that you can not repeat subtask
names or titles. If you can’t find a way around doing this, please reach out to me
BEFORE the due date.
1
(b) For each task and subtask, give a 1-2 sentence high level description. This description
should have enough information to inform the reader of the summary of work to be
performed. Note: You don’t need to set due dates or expected time frames for each
task, so there is no need to do this as a Gantt Chart, but you may include one if you
wish.
3. A list of anticipated deliverables for each subtask.
(a) These deliverables can be repeated for multiple subtasks. For example, multiple subtasks
could all have a report be listed as a deliverable. See the end of this document for a list
of suggested deliverables. You may pick deliverables off of this list, but this should give
you an idea of what usually qualifies as a deliverable.
(b) You can include this in the same table as above, or make a new table. Just make sure to
select deliverables that make sense for the subtask. You may choose multiple deliverables
for a single subtask, if needed. But, don’t select too many deliverables for a single task,
as this is a sign of unnecessary work.
4. Create a testing plan that lists out the following.
(a) List out all the testing types that you will require developers to complete for the project.
Give a reason for why each type was selected, and needed specially for this project. I
suggest you look to the lecture over what types exist, but you may also list types that
weren’t discussed in class. For every testing type to chose, give a 1-2 sentence definition
over the testing type in general.
(b) Give a preliminary list of what tests would be needed to verify each deliverable is met.
Look to match up each subtask with some sort of test, that ISN’T associated with its
deliverable. As a reminder, passing a test on its own isn’t a deliverable, but just helps
verify that a deliverable is working as intended. This doesn’t need to be code, just a high
level description of what the test would actually verify. Look to use around 2 sentences
to describe each verification test at a high level.
Grading
The following is a break-down of the grading and requirements for each aspect of the final project.
The points shown are the maximum allowed points for each requirement, with partial credit being
given for any aspect that doesn’t meet the standards below. The total project is out of a total of
150 points, but will be weighted according to the syllabus.
1. Project Proposal 25 pts
(a) (10 pts) The “elevator pitch” was less than two paragraphs, and accurately describes
the project in its whole. The pitch discusses a brief overview of the scope of the work,
the need for the work, the approach, the expected results.
(b) (5 pts) The figure is readable, flows well, and is understandable. It doesn’t exceed a
single page, and fits within the margin boundaries of the page. The figure has a label,
and a short description underneath.
(c) (10 pts) The detailed description of the figure is within the page requirements, and
fully describes the figure. There is a discussion of the software and resources needed to
2
development and deployment (note, you don’t need to discuss HOW many workers are
needed, just the physical resources). The description was written with the correct mix
of technical information and high level concepts to appeal to a wide range of technical
readers.
2. Task Breakdown Table 35 pts
(a) (15 pts) There are at least 3 main tasks, each with at least 5 unique subtasks.
(b) (15 pts) Each task and subtask have a 1-2 sentence description, that fully describes what
is the scope of the task, and should imply why it is needed for the project.
(c) (5 pts) The table format is readable, with proper column spacing. The table included the
task number, the task/subtask name, and the description of the task. The deliverable
for each task can also be included in this table, or it can be in a second table.
3. Deliverables List 30 pts
(a) (15 pts) There are at least 3 main tasks, each with at least 5 unique subtasks.
(b) (15 pts) Each subtask has an appropriate deliverable(s), and no clear deliverable(s) are
missing. Remember, testing is NOT a deliverable. You do not need to list a deliverable
for a main task, listing the deliverables for their subtasks suffices.
4. Testing Plan 30 pts
(a) (5 pts) Your testing plan contains the appropriate testing types, and all have proper
reasoning as to why they are needed.
(b) (5 pts) All testing types are given a valid, and correct definition.
(c) (5 pts) No appropriate testing types are missing from the testing plan.
(d) (15 pts) Every subtask has some listed form of verification test, that would actually
verify the subtask has been completed. The reasoning for each test is clear, and offers a
clear value to the project.
5. Submission quality and professionalism 30 pts
(a) (10 pts) The submission is clean, neat, professional, and in a single Word document.
There given format is followed and the images and tables are kept within the margins
of the page. There are headers or footers on every page, that list the page number, and
names of the students.
(b) (15 pts) There are minimal spelling and grammar mistakes, that don’t distract the
reader.
(c) (5 pts) There is a cover page listing the names and email addresses of each student, along
with a project title, the name of the instructor, the name of the course, and the current
semester. This can be in any format, as long as the project title, and the student’s
names are in larger font.
Suggested Deliverables
It is suggested you borrow some deliverables from this list, but you are not limited to only take
from this list. Propose the appropriate Note: it is assumed that the final deliverable of the project
is the working software, so make sure to include this deliverable at the appropriate location in your
project plan.
3
• Technical report
• Trade study
• Demonstration with customer
• Final report
• Presentation with stakeholders
• Working packaged software product
• Code review with stakeholders
4
