02162: Course on Software Engineering 2 (e20)

The final submission is via DTU Inside (Campus Net). Note that the final submission consists of two parts: the group submission of the project and an individual submission with the individual contributions and reflections of each student.

The deadline for both parts of the final submission is Tuesday, December 22, 2020 at 23⁵⁹.

The group's submission should contain all necessary software projects (including build and project files); they should be submitted as a tagged commit in the group's GitLab repository, and Shahrzad and Ekkart should be given access to these repositories (at least on the "reporter" level). The Campus Net submission should clearly refer to the tag (preferred) or the SHA hash value of the commit and indicate where to find which projects and how to use them and deploy them (README). Moreover, the submission should contain all documentation (updated system specification), handbook, test documents — uploaded as PDF files to the group's DTU Inside (Campus Net) submission.

The main rational is that the group's software can be installed, started and used without any additional information on top of the documents that you submit. It should be possible to use your software on the web just based on the delivered handbook (which is part of the documentation).

In addition, you should have a version of your web application installed and running on the group's virtual machine for the evaluation (the evaluation will very likely go on from January 4 to January 20). If needed for using your system, provide user accounts and the resp. passwords for the different users in the different relevant roles, so that we can try out your system (as a separate part of your submission).

The final submission must include:

1. All necessary code. All the non-generated code should have comments and authors tags (in C# this could be // Author: ...). Note that the author tags must refer to individual students (if the author tag is not the student number, it needs to be clearly stated with the submission which author tag stands for which student; and each student should use the same author tag throughout all parts of the software and its documentation), but there can be more than one author for the same class or method.
2. Provide access (or access information) to the repository the group was using for the development of the software and a list of the user names of each group member in the respective repository.
3. Instructions on how to install and start the software (on a web server / virtual machine) and how to configure and use it (could be part of the handbook or systems specification).
4. A complete example set up demonstrating all the features and qualities of your sofware, and information on how to use this set up (can be part of the handbook) — possibly in different roles.
5. The revised and updated systems specification and the handbook should be submitted as PDF documents (if it is clearly indicated, the handbook can be part of the systems specification).
6. These documents should clearly indicate which parts were written by which students, so that the individual contributions of the students can be evaluated (using the same unique author tags as for the author tags in the software).
7. Documentation of tests (unit test should be submitted as code; for manual tests, it is enough if they are included in some test reports).
8. A list identifying which student has worked on which parts of the project. This concerns the work on the major parts of the software (in addition to the author tags in the code) and organisational and management work, or work on testing, which is not documented somewhere else (this list does not need to include the work on the different parts of the documentation and the handbook, since these are authored, see 6.).

   If the author tag in the code and documents deviates from the student number of the student, the submission must contain a list stating which author tag represents which student (see 1.).

    

9. In addition to the submission of the group, every student must submit an individual document (as a PDF file) via DTU Inside (CampusNet), in which the student explains the own contributions to the project, in which part he or she was involved, and in which other activities and duties (project leader, responsibilities in the different phases, quality management, etc.) he or she was involved during the project. And the student should reflect on some of the experiences made during this project. This document should be 1-2 pages long and submitted by Dec. 22, 23⁵⁹ via CampusNet (individually).

Please make sure that the submission is complete and will run when installed on a different computer and platform; in particular, make sure that the software and its configuration do not use absolute path names. Here is a check list for the final submission:

1. Are all required files and documents submitted?
2. Did you provide the access information to your development repository to Shahrzad and Ekkart (at least on "reporter" level).
3. Are the documents complete (and understandable)?
4. Did you provide a running version of your software with a properly set up configuration?
5. Does the submission contain all necessary details for installing, starting and using the group's software?
6. Are the buildpaths and configuration files of the projects set up in such a way that the projects build and run on other computers. Are pathes to resources independent from a specific computer? Make sure to test this!
7. Are all references to out-dated or irrelevant packages or plugins removed?
8. Are all output commands to the console deleted from the code (or only made in debugging mode)?
9. Does the software include the comments and, in particular, the author tags for all non-generated parts? Is the same tag used for the same author throughout the project (also in the submitted documents)?
10. Does the documentation and code include the information on the authors for the different parts?
11. If the author tags are not the student numbers, did you provide a a list of the austhor tags used for each student as author tag?
12. Did you provide a list of the user names for each student in that repository?
13. Did you provide the access information to your running version of you web application (user names and passwords for all necessary roles).

     

14. Did every student submit his or her individual document (own contributions and reflections)?