Retrospective: ACCI Exam System

Description

The project was given throughout the course, from the Information Technology department, to teach the process from start to finish, rather than focusing on the technicalities or the AI hype-wagon like the Software Engineering department.

Us students are expected to go from diagrams, to proper designs, and then onto implementations, without skipping a single step.

The Process

Requirements Analysis

This project required us to, in short, develop a piece of software (resembling native Desktop applications using Windows API) that allows different roles to accomplish different tasks on the same platform or system.

• Acceptance Employee: Receives requests for individual examinations, or group-based organization examinations at once.
• Accounting Employee: Reviews examination bookings, and deals with payment-related flows.
• Data Employee: Manages the editing, viewing and re-examining the testing results.

We thought of only designing UIs in a way that it only showed options available to the current role, and any actions not related to such role would be hidden away.

UML Diagrams

Thanks to this course, we were able to learn what it was like to deal with business use cases, as well as system use cases, separating the two for separate actors and their expected audience.

Most of the files are already submitted at the time of the retrospective, so I couldn’t really show them.

From system use cases, we would start defining relationships in class and entity diagrams, with one-to-one or one-to-many relations. We would eventually learn that the professors really did like Windows UI Forms, which they based a lot of their diagrams in, such as using naming conventions for those, but as long as the names make sense, “Label”, “Button”, “Switch”, etc. then it would still be fine.

Implementation

For the implementation phase, you needed to adhere as closely to the Sequence Diagram as possible, but of course, for a bunch of kids majoring in Software Engineering somehow finding their way into Information Technology course, it would not be a surprise that we had a lot of trouble doing it.

I also wanted to force some level of discipline, such as any new features would need a separate branch, before being merged. But I also noticed that the other two members of my team had never worked on a repository in that way before, so the process was rather loosened up, to not take too much time walking on eggshells for arbitrary rules, but to not throw away all engineering practices either.

The Final Product