Software Engineering

Electronic Project Archive

1. The e-Archive Format

Each group should submit an electronic archive containing everything that is necessary to evaluate and run your software.
Do not email your eArchive as an attachment because the mail server will discard it as apossible virus.
Instead, upload a ZIP file to your project repository (preferrably, GitHub hosting page) and let us know where to download it (see Section 4 below).

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:
  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)
Please store different information into different directories/folders. For example, your directory tree may look like this ("README" file is in the root folder):
  
    -
    |
    +-----> 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.
The code will be compared with the diagrams in Report #3. The class, attribute and method names should exactly match. It is not necessary that these are consistent with Reports #1 & #2 since Report #3 revises and overrides the previous two. However, it is critical that the final UML diagrams in Report #3 and the final code are consistent.

2. Software Coding Standards

The source code should be neat and well documented. This is in your best interest so that all group members can seamlessly collaborate on the project. Please refer to the following web site for Java coding standards guide: http://developer.netscape.com:80/docs/technote/java/codestyle.html

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 is missing some files/details or poorly prepared. The project e-Archive can reduce the overall grade by 10 % if missing or poorly prepared. Include the breakdown of individual contributions in the reflective essay + peer evaluation 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 Electronic Project Archive 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.

4.   e-Archive Submission

Package everything into a single ZIP file and upload to a website. Example websites for free file hosting include (but not limited to):

Submission deadline: 11:59 p.m. (Central Time) on the due date.

BACK TO:

Mike Mireku Kwakye
Mon Dec 4 12:12:59 EST 2023