Software Engineering

Electronic Project Archive -- Iteration 2(c) --  (due date given here)

1. The e-Archive Format

The required contents is as follows:

1. "README.txt" file containing all file names and for each file a brief description about the content of the file.
   Your "README.txt" must explain exactly how to run your software:
   • exact process of how to compile your source code and build a runnable file
   • where to find the runnable file if you already supplied one
   • how exactly to run the runnable—what are the allowed input parameters
   • if it is necessary to authenticate the user, then list some example user IDs and passwords that will work
   • describe the allowed values of all parameters that need to be entered while running your prgram
2. PDF files containing the entire Report #1 and Report #2 as these were originally sumbitted, not as modified as part of Report #3.
3. Microsoft PowerPoint files containing slides you used for your first demo and those used for the final demo.
4. PDF file containing the entire Report #3 as in the printed version submitted earlier. The report should appear as a single file.
5. Complete project source code (Java files, or other programming or markup language, if such is used)
6. Images or button icons loaded by the program when run
7. Shell-scripts, CGI scripts, HTML files, and any and all other files needed to run the program
8. Database tables and files or plain files containing example data to run the program
9. Anything else that your program requires to be run?
   (Do not include publicly available or commercial software such as Java JDK packages or database software. We should not need special commercial software to run your software. )
10. Unit tests (program code to run unit tests and a README.txt on how to run the unit tests)
11. Integration tests (program code to run unit tests and a README.txt on how to run the integration tests)

    -
    |
    +-----> doc           // documentation plus Report #3, presentation slides, etc.
    |
    +-----> design        // UML diagrams
    |
    +--+--> code          // project code
       |
       +-------> java     // Java source code
       |
       +-------> classes  // compiled Java classes
       |
       +-------> images   // images and button icons
       |
       +-------> data     // (database) files with example data
       |
       +-------> run      // scripts and/or HTML files
    |
    +-----> tests         // unit tests for the project code (and any other tests)
    |
    +-----> data          // data collected or need for the project

Each source code file should have at the top information about the student who authored it or assisted in writing and debugging the code, something like:

  // written by:
  // tested by:
  // debugged by:
  // etc.

2. Software Coding Standards

Another set of coding standards is given here: http://www.ambysoft.com/javaCodingStandards.html

A major factor in grading will be how well the code corresponds to the UML diagrams. The class names, operation names, and attribute names should exactly match. Put emphasis on consistency, neatness, and completeness. For example, all exceptions should be properly handled. Do not just catch an exception with empty braces: catch(Exception ex) { }.

A good example of a software engineering project along with documentation and source code can be found here: http://www.caip.rutgers.edu/disciple/whiteboard/.

3. Grading

Note that only negative points will be given if the eArchive/EPA is missing or poorly prepared. The project e-Archive can reduce the overall grade by 10 % if missing or poorly prepared. Email us the breakdown of individual contributions immediately after submitting the eArchive.

See also the grading policy for the assigning the overall team grade vs. grades for the individual members.

The eArchives will be graded as follows (note the negative points):

Aspect	Points
(1) Any of the project reports missing	-3
(2) Demo slides missing	-1
(3) The recommended format for EPA not followed	-1
(4) Poor quality of code documentation       a) Lack of correspondence between diagrams and code       b) Poor code structure and readability       c) Incomplete source code (e.g., missing files)       d) Missing information about the student who           authored/assisted/debugged on top of each file	-4
(5) Missing unit or integration tests	-3
(6) Inconsistency between the report printout and archive,      checked in terms of module/class/attribute/operation names	-1

Note the grading focus on the correspondence between the diagrams and the quality of comments.

• GitHub, Inc.
• Dropbox
• MediaFire
• Secure Systems Box

Once you posted the ZIP file online, email us where to find it. Make sure to email us the breakdown of individual contributions immediately after submitting the eArchive.

Submission deadline: 5:00 p.m. on the due date.