Evaluation Plan
CS 410 Red Team
Old Dominion University
July 26, 2016
CS 410 Red
SILENCER
7/26/2016
Table of Contents
Document
Pg. No.
Table of Contents ...............................................................................................................................................2
1
Design Reviews .........................................................................................................................................5
2
Code Reviews ............................................................................................................................................5
3
Unit Testing ................................................................................................................................................6
4
Integration Testing .....................................................................................................................................6
Page 2/9
CS 410 Red
SILENCER
7/26/2016
The four phases of the project will have to be evaluated constantly. Without this constant evaluation
our project will never reach its goal. We will be evaluating based on our milestones. There will need to
be weekly meetings in order to evaluate the success of our project. These meetings will allow the group
to discuss the progress, success and failures of the project. For phases 0 and 1 the meeting will be based
on the opinions of the group. The group receives assistance from Mrs. Brunelle (CS 410 & 411 instructor),
Dr. Olariu (wireless expert), Dr. Weigle (wireless expert), and Dr. Zeil (software design consultant). They
will help our group make sure that we stay on track. The team will go over the success of the project to
date. The same applies to weekly evaluation intervals. The phase 2 and phase 3 mid-phase evaluations
will be determined from WBS, and evaluation will be scheduled at a weekly meeting just as with the
phase 0. Before entering a given phase, the evaluation plan will be examined and updated as needed to
reflect any changes caused by previous phases.
During our project life cycle we will be constantly evaluating ourselves to make sure we meet the
deadline for all of the deliverables. The team will also be monitoring to make sure that we are under our
budget for the project’s life.
Page 3/9
CS 410 Red
SILENCER
7/26/2016
Phase Chart
The following chart shows the deliverables that will be evaluated at the beginning of the phase,
during the phase, and the end of the phase.
Phase 0
Phase Begin
Evaluation
Presentation I
Project Concept
SBIR I
Phase 1
Phase 2
Prototype
Final Production
Specifications
Product Description
Paper
Management plan
Prototype Product
Specification
Phase 3
Production Plan
Personnel plan
Marketing plan
Organization
Chart
Competition
Matrix
Risk Matrix
Phase Mid
Evaluation
Presentation II
Feasibility
WBS
MFCD
Presentation III
Milestone
Planning
Financial Plan
Phase End
Evaluation
Prototype
Development
Environment
Requirements
User Manual
Completed Budget
Prototype Test
Plan/Procedures
Marketing Plan
Test Plan
Online Support
1st Prototype
Demonstration
Final Prototype
Demonstration
Presentation IV
Project Approval
User's Manuals
Positive feedback
Project Webpage
Project Webpage
SBIR I
SBIR II
Figure 1
Working Product
Model
Phase Chart
Page 4/9
Return on
Investment
CS 410 Red
SILENCER
7/26/2016
Here are things that we will do to evaluate each phase of the project:
 Design Reviews
 Code Reviews
 Unit Testing
 Integration Testing
1 Design Reviews
This is the primary evaluation activity of Phase 0. The purpose of review is to carefully understand
and analyze design. We don’t want any important design features to be forgotten. We want to make sure
that the Silencer will actually help the teenage driver safer. We will make sure that no distractions will
be created by the cell phone while the teenager is driving. We want to make sure that there are no
loopholes that the driver can take advantage of, i.e. finding a way to get around the software and talk
while driving.
The design will be reviewed weekly by the team member. There are many important scenarios that
the users could experience while using our Silencer. The team members will discuss and try to find those
scenarios and make sure that our product will work well under those scenarios. The preparation of the
review will be send well in advance by email to the group reviewer so that no time is wasted during the
meeting. The group members will make sure that they have well understood the whole development
before the review session. This will help us to make most efficient use of our time.
2 Code Reviews
Code reviews will be pertaining to software requirements. The code reviews will occur at various
stages throughout the implementation stage of the project. Similar to the design reviews, code reviews
will be a group wide review of the code being used by all parties involved in the milestone/deliverable as
well as any additional parties that may be of use. Following the code review, any errors and/or flaws will
Page 5/9
CS 410 Red
SILENCER
7/26/2016
be corrected and a follow-up code review will be conducted if deemed necessary.
Code review is mainly done for the following purposes:
 If someone else looks at our code or design, they are likely to find mistakes we missed.
 Each team member will be looking at each other’s code so that fewer mistakes are found at testing
time, which will save time.
 We will make sure there is an accurate and up-to-date documentation.
 Team members will learn by reading each other’s code.
 It can be a means of establishing quality metrics, so one can measure the effectiveness of different
quality processes.
 The process of explaining our software to someone else can help us actually review our own
program, rather than just looking at and seeing what we expect or want to see.
 With right code and design reviews we will save time and improve quality over the entire project life
cycle.
3 Unit Testing
Each functionality of the Bluetooth transceiver and the cell phone software will be tested to make
sure that they do what they suppose to. The developer of functionality will have a responsibility to
create test cases and use them to test that functionality. That functionality will also be double-checked
by another member of the team for quality assurance.
4 Integration Testing
In the integration testing, we want to make sure that the cell phone software will work with the
Bluetooth transceiver, i.e., the cell phone software is able to receive the signal sent from the Bluetooth
transceiver and switch to silent mode in a timely manner. This is an important test because, even though
each piece works well individually, when we put them together problems may arise.
Page 6/9
CS 410 Red
SILENCER
7/26/2016
Regression testing: We want to make sure that once the cell phone software or the Bluetooth
transceiver is updated, it is still be able to work with the other pieces.
Recovery testing: The Bluetooth transceiver may lose power from the car. We want to make
sure that no matter how many times the power source is lost, the transceiver is still able to boot up and
work correctly once the power source comes back.
Security testing: Because Bluetooth is used as a means of communication between the cell
phone and the transceiver, we want to make sure that our software is secured, that no intruder will be
able to hack into the phone via Bluetooth connection.
Performance testing: This is where the performance requirements are checked. These may
include the size of the software when installed, the amount of main memory it requires, and the
response time. Because the cell phone has limited battery power, we also need to make sure that the
software will not consume too much power.
Alpha and Beta testing: This is where the software is released to the actual end users. The
initial alpha release will be done at ODU by our team members. Once the application has passed through
the alpha phase, a beta release, possibly incorporating changes necessitated by the alpha phase, can be
made to larger more representative stores before the final release is made to all stores. We will ask the
members of the local Parent-Teacher Association (PTA) to test our Beta product because we feel they are
already predisposed to caring significantly about their children’s lives. .
Page 7/9
CS 410 Red
SILENCER
7/26/2016
From these tests and polls, we will evaluate the usability and effectiveness of our product. The
testing will also identify aspects of our product that can be improved. The member of the PTA will gain
an appreciation for the benefits our product will provide and they will also help us to market the
Silencer to other parents who did not join the PTA.
Beta testing plan:
The following will be tested:
 Product’s functionality
 Product’s user-friendliness
 User documentation
Each beta tester will receive the following:
 Bluetooth transceiver
 Cell phone software
 User Manual
 Basic instructions
Product functionality
 While the teen is driving, his/her cell phone will be switched to either silent or vibrate mode
depending on the parent’s choice.
 All calls will be forwarded to voice mail
 The software will be secured so that hackers cannot use the Bluetooth connection to intrude onto
the cell phone.
Page 8/9
CS 410 Red
SILENCER
7/26/2016
Product’s user-friendliness
 Due to the limitation of the cell phone, power consumption and performance issue, we will use Text
user interface (TUI) in stead of Graphical user interface (GUI). However, we will make sure that our
TUI is easy to used
 It will have a user friendly help menu
User documentation will contain:
 An instruction on how to install the Bluetooth transceiver and the software on the cell phone
 An instruction on how to use the software
 An instruction on how to configure the Bluetooth transceiver remotely by using the cell phone
 Common problems and troubleshooting
 Guaranty information.
Page 9/9