• Home
  • About
  • Mobile
  • Open Content
  • Search

Module Overview


  • Description
  • Facilitators
  • Weblinks
  • Timetable
CS3202 

SOFTWARE ENGINEERING PROJECT II
   2013/2014, Semester 2
   School of Computing (Computer Science)
Modular Credits: 4
  Tags: --

Learning Outcomes

Top

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).

CS3202 is the second in the two-course series that spreads over two terms, in which students work on the software engineering project. CS3202 is a continuation of CS3201.  CS3201 and CS3202 focus on applying proven software engineering principles in practice. In CS3201, students work on requirements analysis, architecture and do extended prototyping. In CS3202, more emphasis is placed on iterative development whereby in each iteration requirements and architecture are further refined; students analyze and justify design decisions in conformance to high-level architecture, and develop close to production-quality code.
 
CS3201/CS3202 replaced the former CS3215 that was offered in a single term and was worth 8 modular credits. CS3201 and CS3202 are worth 4 modular credits each.
The main thrust and teaching methodology for CS3201/CS3202 is similar to that of CS3215: We focus on applying proven software engineering principles in practice. However, a two-course formula allows us to look deeper into software architecture issues, and do team work with elements of individual assessment during requirements analysis and architecture design.
 
In CS3201/CS3202, students work through the Software Development Life Cycle (SDLC) to complete a team project.
 
The essence of this course is advanced software design in action. Students learn to apply design principles and “best development practices” in a team project. Architectural design, design specifications and evaluation of alternative design solutions that lead to quality code are emphasized throughout the course. The problem students work on is carefully selected to demonstrate application of design principles. The size of the problem and iterative development style makes it difficult to succeed in the project without applying principled and systematic approach to design, documentation, development and testing.
 
Specific objectives are:
 
  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.
 

Prerequisites

TopCS2103

Teaching Modes

Top
In CS3202, students go through the iterative development in teams of six. There are four development iterations, described in four assignments. At the end of the third iteration, students implement SPA as described in the project Handbook.  In the fourth iteration, students can implement extensions for bonus points.
 
The course involves lectures, consultations, a test, and a project. Each project team (of six students) is allocated time to meet with a supervisor in weekly consultations.  
 
Students present their work at the end of the course and their programs are tested for reliability with automated testing tool. 

Assessment

Top
Grading Policy
  • (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. 
CS3201/CS3202 is a team project and is evaluated as such. Different students may contribute in different ways, according to their skills, abilities and project plans set by the whole team. We expect all students to put in a similar effort towards completing the project.
 
All the students in a team share equal responsibility for creating team spirit, and making the team work as a whole. Should a problem arise, each student must be willing to work towards resolving the problem. If problems cannot be resolved within a team, do ask your supervisor for mediation -- in the past almost all problems could be helped if addressed early. Each student should deliver work products according to the project plans set by the whole team.
 
Cases of students who fail to become productive team members will be considered by supervisors. If such students do not put in additional effort to rectify the problem, grades the respective student(s) may be reduced (including failing the course, in drastic situations).
 
The first 3 assignments will be given full mark, 1/2 mark or 0  based on the following criteria (assuming you submit assignment on time):
  • 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.
For the final project:
  • 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.

Project Evaluation Criteria
 
Read more in Sections 3 and 8 in the Handbook.
  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).
 
Policy on Project Work
 
  • 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.

Preclusions

TopCS3215 Software Engineering Project

Workload

Top1-1-0-5-3

Workload Components : A-B-C-D-E
A: no. of lecture hours per week
B: no. of tutorial hours per week
C: no. of lab hours per week
D: no. of hours for projects, assignments, fieldwork etc per week
E: no. of hours for preparatory work by a student per week

Team Registration and Bidding for Consultation Slot

Top
All teams are required to register on IVLE and to choose a consultation slot. Should you fail to find enough team members or cannot find a team with less than five or six members, use the discussion forum on IVLE or contact the lecture during the lecture. Once formed, teams will complete the assignments together. 
 
1. Team registration -- STARTING January 14, 12pm (noon):
Each student has to join the team on IVLE: IVLE->CS3202->Project->Groups->Sign Up. The teams should choose a name and elect a leader. The team leader has to email the team name, and the name for all the team members (full name, NUSNET id, SoC/UNIX id) to Cristina by 16 January, 8pm. 
 
Please send the details of your team in the following format:
Team number (from IVLE): 
Team name:
Team leader name: leader_name
Full name: name1, name2, ...
NUSNET id: nusnet_id1, nusnet_id2, ...
UNIX/SoC account: unix_acc1, unix_acc2, ...
 
2. Choosing a consultation slot:
After consulting with the whole team, the team leader has to register the team for a consultation slot before 19 January, 8pm. To choose a slot, navigate to Project, click your group. A pop-up window will appear. Choose "Consultation" from the left side menu. Then "Sign up for consultation" by selecting one of the time slots. The whole team has to attend the same consultation slot. If you have multiple options for consultation slots, please do indicate so in the email.
 
The consultations will last for 30-45 mins, every week, starting on week 3. 

If you have any problems regarding the team formation and consultation, contact Cristina (ccris@comp.nus.edu.sg).


Available Consultation Slots
  • 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

Consultations

Top
Consultations are in weeks 3 to 12. Each team has a 45-minutes consultation slot (per week) with the assigned supervisor(s).
All team members must be present and comment on the work done.

There is no tutorial for CS3202.
 
The consultation schedule is:
Team Time Venue Instructor
1 Mon, 17:15 DR6 (COM2-2-12) Cristina
2 Mon, 14:15 DR7 (COM2-3-14) Stan
3 Mon, 18:00 DR6 (COM2-2-12) Yuchen
4 Tue, 18:15 DR7 (COM2-3-14) Ziquan
5 Tue, 17:00 DR7 (COM2-3-14) Ziquan
6 Mon, 14:15 DR6 (COM2-2-12) Cristina
7 Mon, 11:00 DR8 (COM2-3-15) Stan
8 Tue, 13:00 DR6 (COM2-2-12) Cristina
9 Tue, 12:00 DR7 (COM2-3-14) Yuchen
10 Mon, 10:00 DR8 (COM2-3-15) Stan

Software Engineering Project Handbook: Errata

Top
The points in red are recently added:
  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 ..." 
  5. Section 5, p. 9: "4th line in procedure First: "all Second" should be "call Second" 

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

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

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

  9. P. 33, Q15 : replace “stmt s;” with “variable v;”
  10. P. 33, Q16: replace “Select a” with “Select s” in the first query; delete “or” and a query that follows “or”
  11. P. 82, Table 3: Delete prog_line and INTEGER from  table entries for Calls and Calls*
  12. 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.

  13. Appendix A, p. 99, definition of attribute comparison: 
    Replace the following grammar rules:
------------------------
attrCompare : attrRef ‘=’ ref  |     
           synonym ‘=’ ref-pl
ref-pl : INTEGER | attrRef
// synonym must be a synonym of prog_line and attrRef must yield integer
 
attrRef : synonym ‘.’ attrName 
ref : ‘”’ IDENT ‘”’ | INTEGER | attrRef
------------------------
    with the grammar rules below:
-------------------------
attrCompare : ref ‘=’ ref
// left-hand-side and right-hand-side 'ref' must be of the same type (INTRGER or character string)
ref : attrRef | synonym | ‘”’ IDENT ‘”’ | INTEGER     
// in the above, 'synonym' must be a synonym of prog_line
attrRef : synonym ‘.’ attrName 
-------------------------

Tools

Top
A software team needs a set of good tools to build a product. We recommend the following tools:
 
  • 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.

Final Submission and Presentations

TopIn this section, you will find instructions regarding submission of your Final Report, your Code as well as information about the Final Project Presentation.

Submission of Final Project Report and Code

The deadline for submission of your Final Project Report and Code is 2pm (noon) on 17 April (Thursday).

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).

We won't be able to accept your report and/or code after 2 pm on Friday.
For multiple submissions received from the same team we will mark the most recent one. 

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.


Important notes:
  • 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:


Team Presentation
1 Tuesday, 12:00 - 12:45
2 Monday, 12:00 - 12:45
3 Monday, 13:00 - 13:45
4 Monday, 14:00 - 14:45
5 Monday, 16:00 - 16:45
6 Monday, 17:00 - 17:45
7 Tuesday, 09:00 - 09:45
8 Tuesday, 10:00 - 10:45
9 Tuesday, 11:00 - 11:45
10 Monday, 11:00 - 11:45
















Each team will have a 45-minute slot:
  • Presentation: 20 minutes
  • Q & A: 10 minutes
  • Discussion of failed cases: 15 minutes
  • Teams have to attend only their slot. All members must attend.

What to cover during the presentation:

  • Did you implement all the required functionalities? Which functions are not implemented? Any additional features implemented?
  • Which bonus features (i.e., assignment 4) did you implement?
  • Any achievements that you feel are important and that make your project special. Any solutions or approach that you think is unique and / or beneficial.
  • Illustrate your points with examples.
  • Do NOT present things we already know from the Project Handbook (e.g., what is SPA). You do not need to explain the design of each component such as parser, AST, etc. unless there is something special you want to tell us.

Basically, you will want to make use of this time to sell your SPA and convince us that your hard work this semester deserves a good grade. Therefore, concentrate mainly on your achievements and those special features of your SPA.

Good luck in final weeks of the project and in presentations. 


Autotester

Top
SPA implementations submitted by students will be tested using the AutoTester. Teams should ensure that their submissions work with Autotester without any failures. Usage information and download files of Autotester can be found here: http://www.comp.nus.edu.sg/~cs3201/Tools-Lab/AutoTester.html.

Automatic Project Testing

The Automatic Project Testing offers a start-up point for your project development and testing. You may use the sample Visual Studio 2010 solution as an example on how to structure your code and testing files. Also, this solution can be used as the base to start the project that can be modified according to your need. In the final states of the development, the sample script can be used to automatically run the complete set of tests.

You should either use this sample or the AutoTester. This sample solution already contains the AutoTester library, so you do not need to download the AutoTester package from the website. However, you need to read the documentation about the AutoTester to be able to integrate your code with the AutoTester. Click here to download the user guide for Automatic Project Testing: http://www.comp.nus.edu.sg/~cs3201/Tools-Lab/AutomaticProjectTesting.html

Contact

  • IVLE Webmaster

Social Media

Latest Alerts

  • IVLE scheduled maintenance every Tuesday 0300 hrs - 0700 hrs

Centre for Instructional Technology

Legal  |  Acceptable Use Policy

Copyright © 2015, National University of Singapore. All rights reserved.