Group Project (45 marks)

TASKS

Your tasks are to:

1.   Form  and  structure your group,  allocating roles  and responsibilities to your members. Register your group using the link provided on Moodle. This must be finalized by the end of Week 2.

2.   Complete  the  design  and  development  of the  project  described  below  using  object- oriented design (at least at the back-end). This should cover software product design, software engineering design and implementation.

3.   Produce a report detailing the group's work.

SUBMISSION

1.   Verbal Progress Report: in Week 4 Lab

2.   Mid-project deliverable (softcopy to Moodle) ( 10 marks): 10:00am Thursday 6th  April 2023

3.   Final deliverables (softcopy to Moodle) (30 marks): 10:00am Friday 26th May 2023

•   Final report

•   Executable system + source code

4.   Product demonstration (5 marks): Week 12 Lab

5.   True weekly meeting reports from Week 3 to Week 12 (submit to Moodle every week from Week 3, at least one meeting report per week). Weekly meeting reports should cover at least the following:

•   Member contribution report up to that week (see details below for what should be included in the member contribution)

•    True  (the  meeting  must  occur)  group  meeting  records:  agendas  and  meeting minutes which include at least the following:   meeting date, attendance, progress

reports  of  each  week,  review  and  tracking,  discussion  summaries,  and  action plans/items.

GUIDELINES

Important note: Each deliverable must be accompanied with a member contribution report. Groups missing contribution report will NOT be marked.

1.   Week 4 verbal progress report

•   One member from each group presents the progress of their group

•   Use a few slides to introduce their group members and roles, and report on progress and plans for the remaining of the project.

2.   The mid-project deliverable should cover the following:

•   Software Product Design including:

o Software Requirement Specification

o Use cases (including use case diagrams and use case description)

o Mock-up prototypes.

o Clearly  demonstrate  (with  detailed  description  and  justification)  how requirements  alternatives  have been  considered  and  selected  (e.g.  using Scoring Matrix).

o Clearly  demonstrate  (with  a  detailed  justification)  how  your  product design meet ALL the product design principles.

•   Project progress up to Week 6

•   Member contribution up to Week 6 (with a signature from each member) – see details for this below.

3.   The final report should cover at least the following:

•   Software Engineering Design including:

o A complete and detailed description of architecture design. You also need to clearly demonstrate (with detailed description and clear justification) the use of at least one architectural design style in your design.

o A complete and detailed design including

1 Finalized use cases (including use case diagrams and description)

1 Class diagrams of the entire system.

1 Sequence diagrams (at least one for each use case).

1 State diagrams (for the whole system as well as the objects within the system)

1 Detailed description of database design.

1 Detailed description of user-interface design.

1 You  need  to   clearly   demonstrate   (with   detailed   description   and justification) the use of at least FIVE design patterns in your design.

o Clearly  demonstrate  (with  a  detailed  justification)  how  your  software engineering design meet ALL the software engineering design principles (including both basic principles and constructive principles).

o Define 5 invariants and 5 functions that are relevant to your design using the Object Constraint Language (OCL).

•   Member contribution for the whole project (with each member’s signature)

Member contribution report (each deliverable must be accompanied with a member contribution report):

•   On the cover page of your group’s report, you need to provide rating for the contribution of each team member and a detailed explanation of what the team member did for the   project to justify the rating.

•   Everyone in the team should write a statement “I agree with my group member       contribution report and ratings” and insert their signature next to the statement.

•   The individual contribution of each team member is assessed by all the other members.

•   The rating scale can be a specific percentage number (e.g. 40%, 60%, 80%, etc.).

•   Alternatively, it can be rated into one of the three scales: “contributed”, “very little”, and “almost no contribution” . For a team member who has “contributed”, he/she will receive 100% of the group mark; for a team member who contributed “very little”, he/she will    receive 50% of the team mark; for students who made “almost no contribution”, he/she  will receive 0 marks for the entire group project. Your tutor/lecturer may make                adjustment to this marking criterion based on practical situations.

See the enclosed marking schemes for further details.

Project - Description

Important Notes:

•   This  Project  Description  provides  only  the  high-level  goals  of  this  project.   The development    team    MUST    elicit    and    design    more    detailed    and    specific requirements/features/functionalitiesfor the system.

In this project, your team is asked to design and develop a research conference management system. This system will help organise the submission of research papers, allocation to reviewers and making decisions on accepting or rejecting papers.

The system should support at least the following key aspects.

1.   Support  and  manage  different  types  of  users  and  user  profiles  (i.e.  system  admin, conference chair, reviewers and authors).

2.   Support the authors to submit papers to a conference. A paper may have multiple authors and an author may submit multiple papers.

3.   Support the reviewers to bid for the papers they prefer to review and provide the maximum number of papers they would like to review.

4.   Support the conference chairs to allocate papers to reviewers. The allocation should take into the reviewers’ bidding and their preferred workload (i.e. maximum number of papers). Allocation can be done automatically or manually.

5.   Support the reviewers to submit and edit their review and rating. Ratings can be: 3 (strong accept), 2 (accept), 1 (weak accept),  0 (borderline paper), - 1 (weak reject),  -2 (reject),  -3 (strong reject). Once a reviewer has submitted their review for a paper, they would be able to see the other reviews on the same paper. They can then add comments to discuss the reviews.

6.   Support the conference chairs to view the reviews and ratings, and decide whether a paper should be accepted or rejected after the reviewing process completes. Once all decision have been made, the conference chairs should also be able to see a list of accepted and rejected papers and notify the authors accordingly via emails. The authors are then able to see the reviews of their paper and rate the review.

You must create test data that is sufficiently large enough to simulate the system (e.g. 100 records to each datatype). You could write a script to generate these data randomly. In the final product demonstration, you will need to run a live demo of your product with these test data.

The marking scheme is in the next page for your reference.

CSCI334 Software Design

Mid-project Deliverable (Worth 10%)

Group: