CMSC 345 Project Fall 2013

CMSC 345 Project

Design and Develop an application for a companies
Software Quality Assurance Organization. SQAO.

The goal is to have this be the instructions for
the SQAO including forms and check lists, and
in addition be the instructions for the software development
teams that must get their software approved by the
SQAO before it can be released to the customer.
(More details covered in lectures)

Your team has significant flexibility.
You may require, and have review check list, for the
documents required in this course or a different set
of documents that your team thinks would produce
better quality software. You may use a database or
other way to store, retrieve, archive documents and
code. It is OK to use information from the literature 
and from what some company does.

Your team may want to pick a specific programming
language and have a style guide and specific metric
measurements and requirements.

Your team may want to specify testing requirements
for various stages of the software development.
e.g. require a rapid prototype, require unit test,
require alpha, beta, final acceptance, or other test.

Your team may want to specify a specific configuration
management, configuration control system, and 
possibly specific configuration control software.

Being very specific, within practical limitations,
will get your team more points than being
"wishy washy". SQAO's are typically very strict.
Some programmers would say "hard nosed" or 
"draconian" or worse.

Provide for the SQAO to record their evaluation of
each project, at each step, through final approval
for delivery to the customer. Have at least one
complete sample project recorded. Some other
partial samples with different evaluations would help.
You will need some type of problem or defect reporting 
capability. Your choice of implementation, it is
allowed to model UMBC "ticket" system.


Your team will have a "customer" for your project.
The "customer" can not change the basic project, yet,
may ask for reasonable enhancements or suggest
choices for various details. Your "customer" will
be asked to give an evaluation of your project after
your team has presented it.



Technical details for doing your project.
Yes, this is a typical commercial software development.
Far different from any personal software development.

You will generate more than 10 times as many lines
in documents than you generate in code. Someone on
your team may be doing some preliminary programming,
technically called rapid prototyping. This code may
or may not get used and modified.

System Requirements Specification SRS
After getting information from lectures and having
your team discussions, document what requirements you
have so far in the System Requirements Specification, SRS.

Typically download srsTemplate.docx
copy to srs.doc and hack this into the SRS you will
give to your customer for review and possible corrections
and additions. Update, fill in contributions, get signatures in
appendix A. srsA.docx Appendix A

Submit final version with command on linux.gl.umbc.edu
submit cs345 team? srs.doc

The ? is your team number.


System Design Document, SDD
Now focus on design details. Be as specific as possible.
After getting information from lectures and having
your team discussions, document what design information you
have in the System Design Document, SDD.

Typically download sddTemplate.doc
copy to sdd.doc and hack this into the SDD you will
give to your customer for review.
Update as needed, fill in contributions, get signatures in
Appendix A. sddA.docx Appendix A

Submit final version with command on linux.gl.umbc.edu

submit cs345 team? sdd.doc


User Interface Design Document, UID
Now focus on details of screens that the SQAO will see.
Do a layout of login, project selection, check lists,
forms, etc.

After getting information from lectures and having
your team discussions, document the user interface information
you have in the User Interface Design Document, UI.

Typically download uiTemplate.doc
copy to ui.doc and hack this into the UI document you will
give to your customer for review and possible corrections or
additions. Some screen shots from rapid prototyping efforts
may be very useful in this document.
Update as needed, fill in contributions, get signatures in
Appendix A. uiA.docx Appendix A

Submit final version with command on linux.gl.umbc.edu

submit cs345 team? ui.doc

Now team software development should be "full steam ahead".
Every team member is expected to contribute some code.
The team member who is code lead, coordinates and makes
adjustments as needed.


Code Inspection Report, CIR
Now focus on what will help the quality of your code.
After getting information from lectures and having
your team discussions, document what inspections you
want in the Code Inspection Report, CIR.

Are you using any software metrics? Do you have
automated measurement of the metrics? Do you require
any specific range for the measured results to be
considered acceptable quality?

Typically download cirTemplate.doc
copy to cir.doc and hack this into the CIR you will
give to your customer for review.
Update as needed, fill in contributions, get signatures in 
Appendix A. cirA.docx Appendix A

Submit final version with command on linux.gl.umbc.edu

submit cs345 team? cir.doc


Testing Report Document, TRD
More focus on what will help the quality of your code.
There is a classic statement "No amount of testing will
produce quality software." But, without systematic
testing, the software will have poor quality.

Hopefully your customer has tried your project.
It may be good news or bad news if your customer
reports a defect. Fix all problems that can reasonably
corrected, be careful to not make changes that
introduce other problems or endanger stability.
You will be demonstrating your project. It typically
will still have some bugs. Just do you demonstration,
trying to avoid any known bugs. The product is at
a point where it would be made available for alpha
testing.

After getting information from lectures and having
your team discussions, and actually testing your
project, typically per the code inspection,
document your test results in the Testing Report Document, TRD.

Typically download trTemplate.doc
copy to tr.doc and hack this into the TRD you will
give to your customer for review.
Update as needed, fill in contributions, get signatures in
Appendix A. trA.docx Appendix A

Submit final version with command on linux.gl.umbc.edu

submit cs345 team? tr.doc



Administrator Manual, AM
Now focus on what will help the quality of your code.
After getting information from lectures and having
your team discussions, document what inspections you
want in the Code Inspection Report, CIR.

Are you using any software metrics? Do you have
automated measurement of the metrics? Do you require
any specific range for the measured results to be
considered acceptable quality?

Typically download amTemplate.doc
copy to am.doc and hack this into the AM you will
give to your customer for review.
Update as needed, fill in contributions, get signatures in 
Appendix A. amA.docx Appendix A

Submit final version with command on linux.gl.umbc.edu

submit cs345 team? am.doc


You are almost finished, just a presentation
With your customer present, each team member does part
of the presentation. Demonstrate from login, select project,
use of various forms or check lists, defect reporting, etc.
Typically administrator enters a new project, new users,
then user enters a new document and (comment, defect report,
bug, whatever you call it). Have users, at least one
project, e.g. some your documents, comments, status, etc.
preloaded before start of demonstration. There may be
status indicators and [user,date,time] tags on
appropriate items. Show sample report of your preloaded
information and there may be a few questions or request
for more information or demonstration.


Notes
Does this seem like too much work for a one semester
project? Well, yes for one person, that is why you
must make the team activity work.
  
Getting templates: When on linux.gl.umbc.edu, in
a terminal window,

cp /afs/umbc.edu/users/s/q/squire/pub/download/srsTemplate.docx  .
cp /afs/umbc.edu/users/s/q/squire/pub/download/srsA.docx  .
etc.
Or, save from the web. Be careful, you may not get an exact copy.

Either is acceptable .doc  or  .docx , try not to get a version
that is not readable by Libre Office, Open Office or old
Microsoft Word programs.

Ask questions
Some that have been asked:
What type of computer program is this project?
Ans: It is a data entry, data archiving, report generating
program. As a minimum it should handle many projects,
allow by user name and password, only specific people to
enter data into each project. Have an administrator who
can start a new project and authorize people. provide a
nicely formatted report on screen or printed with all
information available about a project.
Is it part of my project to write a style formatter? No.
Is it part of my project to write a metrics measurement program? No.
Last updated 12/6/2013