You can quickly find out about the approach taken in this project course, and about experiences teaching it in the paper "Teaching an Advanced Design, Team-oriented Software Project Course", published in the Proceedings of the 26th Conference on Software Engineering Education and Training (2013).

1. Develop the attitudes and abilities necessary to work effectively in a team,
2. Prepare students for industry projects,
3. Develop communication and writing skills,
4. Learn how to apply design principles in practice,
5. Enhance development and problem solving skills in areas of requirement analysis, architectural design, construction, testing and documentation,
6. Enhance project planning skills,
7. Apply and consolidate what you have learned in earlier courses such as CS1101, CS1102 and CS2103.

• (individual, penalty/bonus): The ability to work in a team
• (individual, penalty/bonus): Attendance and participation in Consultations
• (group, 10%): 3 assignments of equal weight; iterative development of the basic SPA
• (group, 75%): Basic SPA, design decisions, code quality (results of auto-testing), documentation and presentation
• (group, 15%): Extensions defined in the 4th assignment, as well as any other extensions. 

• full mark - if you submit a reasonable assignment solution; you will not be punished for errors or if your work does not fully cover the scope of the assignment, provided this is not due to negligence; if you get on track later, you still stand a chance to get the highest grade at the end.
• 1/2 mark - if your work is at the very low end of being reasonable with respect to what was expected.
• 0 mark - if your work is not reasonable with respect to what was expected, or if you got 1/2 mark in the last assignment and you did not put enough effort to improve.

• We expect at least:
  • implementation of the basic SPA (first three assignments)
  • important design decisions evaluated and justified
  • reliability: programs must pass our test benchmark
  • high quality of report and presentation
• Students aiming for an A or A+ grade should:
  • implement some of the extensions described in assignment 4 and/or other extensions
  • demonstrate flexibility and reusability of SPA design and code
  • demonstrate some degree of innovation in terms of PQL features, design solutions, query evaluation strategy, or in other areas
  • demonstrate maturity of skills in areas of team work, design, incremental development, approach to testing etc.
• We take into account all the above factors, not only functionality implemented, in the evaluation of project achievements and in grading the project.

1. Team-work: The ability to work in a team.
2. Quality of architectural and detailed design decisions: Evaluation and selection of design decisions. What matters is not only the design decision itself, but also the process of arriving on design decisions, how you evaluate and argue about design choices, and clarity of documenting design decisions.
3. Reliability of SPA code: conformance of SPA code to requirement specifications (checked during auto-testing of your SPA at the end of the course).
4. Quality of SPA code: Implementation strategies; Readability of code; Coding standards and practices; Conformance of implementation to architectural decisions (abstract APIs and information hiding).
5. Demonstrated maintainability, flexibility (“design for change”), reusability and scalability of design and code.
6. Quality of project report.
7. Quality of project presentation (during project evaluation in recess week).

• You are permitted to discuss the project with anyone.
• Solutions you hand in should be your own work -- coding and documentation should be the work of your team only!
• You may not view any code and document written for CS3201/CS3202 and  CS3215 in the past.
• You may not reveal your code and document to any students not in your team.
• Any case of academic misconduct will be prosecuted to the fullest extent provided for by University regulations.

• Mondays, 10am-10.45am
• Mondays, 10.45am-11.30am
• Mondays, 2.15pm-3pm
• Mondays, 3pm-3.45pm
• Mondays, 3.45pm-4.30pm
• Tuesdays, 11am-11.45am
• Tuesdays, 11.45am-12.30pm
• Tuesdays, 12.30pm-1.15pm
• Tuesdays, 1.15pm-2pm
• Tuesdays, 2pm-2.45pm
• Tuesdays, 2.45pm-3.30pm

1. P. 14 (bottom): "else" should not be numbered.
2. P. 18 (top): the line connecting "5:constant" to ":while" should
   connect instead ":assign" to ":while"
3. P. 35, Q26: "Select a2" should be "Select a1"
4. Section 7.4, Q16: "Select a such that ..." should be "Select  s such that ..." 
2. Section 5, p. 9: "4th line in procedure First: "all Second" should be "call Second" 


3. Section 6, p. 26: delete line “prog_line.prog_line# : INTEGER 


4. P. 11, 4th and 5th line should be:
   assign : var_name “=” expr “;”
   expr : expr “+” term | expr “-” term | term 


5. P. 33, Q13: replace “16” with “13” 


6. P. 33, Q15 : replace “stmt s;” with “variable v;”
7. P. 33, Q16: replace “Select a” with “Select s” in the first query; delete “or” and a query that follows “or”
8. P. 82, Table 3: Delete prog_line and INTEGER from  table entries for Calls and Calls*

9. P. 101: add the following at the end of the page:

   7)  Synonyms of assign, call, while and if can be used as arguments of relationships place of design entity stmt. E.g., Follows (a, w), where a is a synonym of assign and w is a synonym of while.


10. Appendix A, p. 99, definition of attribute comparison: 

• C++ compiler: Visual Studio 2010 or Visual C++ 2010 Express. This is a requirement since the other tools used in the course depend on this.
• Version control system: Teams can use the Subversion server of SoC or their own DVCS (Distributed Version Control System) like Mercurial or Git. Teams are required to pick and use a VCS and update it regularly with their code.
• Unit Testing Framework: Teams can use CPPUnit, other frameworks or write their own.
• Documentation: Doxygen or other documentation tools.
• Libraries: Teams can use Boost, flex, bison and other such libraries if they find it useful for their implementation.
• Design Tools: AgroUML, Visio and such tools can be used for creating and maintaining the UML models of your project.

Submission of Final Project Report and Code

If you submit report between 2 pm Thursday and 2 pm on Friday, penalty is 5 points (final submission has a maximum of 100 points).

If you submit code between 2 pm Thursday and 2 pm on Friday, penalty is 20 points (final submission has a maximum of 100 points).

Report and code softcopy submission: IVLE (see Section IVLE Submission).
Report hardcopy submission: Stan's office (COM2-3-21).

Final Project Requirements

• Your report should comply with the Project Report Format given in Assignment 4.
• Avoid repeating material contained in the Project Handbook; instead, such material can be referenced. We recommend that you use a 12pt single spacing font. It is important to make your report clear and readable. Make it as concise as possible, but also complete. In any case, do not exceed 50 pages (excluding API). In fact, your report may be much shorter than 50 pages if you plan well what you want to say in the report. Use good examples to illustrate your design.
• Emphasize in the report whatever you think is a strong point in your project that may affect your grade (e.g., good design solutions or extra features you implemented). Be brief about things that we already know well.

IVLE Submission

How to submit:

As we only use the source code from your submission archive for testing, please ensure that you have included all required files. In the folder called Team<XX>, include the following:

1. File Team<XX>.pdf cotaining the final report.

2. Sub-directory called Code<XX> containing (at least):

   1. Source code of SPA. Put source files in a sub-directory called source.

   2. Solution file (.sln) for Visual Studio 2010 (and additional project files). The solution should build and run without errors in "Release" configuration.

   3. Readme.txt file with instructions on how to compile and run the auto-tester on your SPA, the name of your solution that has to be built and the path to the executable produced.
      Do ensure that the solution files from your submission builds and produces the correct executable.

   4. The files you used to compile and run your auto-tester (mainly your TestWrapper class). Put them in a sub-directory called AutoTester.

   5. Test programs (projects) you used for testing your SPA (unit and integration). For example, your cppunit test files and/or any test files you developed for your own testing. Put them in sub-directories called UnitTesting and IntegrationTesting.

   6. Contact.txt file with names of all team members and their contact information.

   7. If you implemented bonus extensions (Assignment 4 or other notable features), then include code and tests for extra features in a sub-directory bonus as follows:

      • If your source code of SPA with additional features is different from the basic SPA, then put source files in a sub-directory called source.

      • Readme.txt file with instructions on how to compile and run your SPA, and any other information we may need in order to test your SPA, with test cases provided by you and our own test cases.

      • File with SIMPLE source code named feature_name_source.txt to run your SPA with your test cases.

      • File(s) with test cases named feature_name_testcases.txt.

3. Sub-directory called Tests<XX> containg THREE test cases (source code) for each type of query condition (relationship) and at least TEN tests for various combinations of query conditions (ten is the total number of tests cases required here, not ten tests for each combination of conditions). These tests should be written in AutoTester format.

• We use AutoTester to test your submission. Ensure that your code is integrated and works correctly with AutoTester (see Workbin->Tools->AutoTester for documentation).

• We will test your implementation with a set of SIMPLE source codes and PQL queries. Failed test-cases will be discussed after presentation.

• Please use the sample SIMPLE code on IVLE Workbin -> Tools to verify your parser will be able to parse our test cases. Also, note that the source code and queries are case-sensitive, so check that your SPA accepts and computes results according to correct casing (see AutoTester examples). In case we cannot compile your code or run SPA at all, we will contact you so that you can fix the problem. For that, please do not forget to include your contact information (see above) and be available after submission.

• If the SPA does not return an answer for a PQL query after 5,000ms, we assume an 'infinite loop' situation and the test-case is considered failed.

• We evaluate your code organization and the match between your implementation and the abstract API calls described in the report.

Final Project Presentation

Date:

• Monday and Tuesday during Reading Week (21 and 22 April)

Location:

• Tutorial Room 9 (COM2-108)

Schedule: