Software Engineering Principles and Patterns
A-
AY24/25 S1
The mod is all about software design. The first half is about the planning phase. This includes gathering requirements, understanding the business needs of the software. This leads to domain-driven design and event storming, which is all about breaking down the problem into different parts that we can group, categorise, arrange, and convert into code components. The second half talks about patterns in software architecture, with focus on object interactions, message and data patterns. Though some may seem trivial, I think the lectures do a good job at introducing us to different ways things can be done. Different ways will have different trade offs, and many times, there will be more than one viable solution, depending on the context and constraints of the system.
Vague AF requirements. That pretty much sums up the mod. Seriously. 90% of the anxiety in the mod stems from understanding what the project actually wants from us. But I guess that's a key learning point of this mod. in the real world, you're not gonna get all the requirements fed to you. You need to ask the right people for clarification. In this case, we could've just asked the prof for clarification on marking points. The profs encourage us to just email them when we encounter an issue. Don't solely rely on TAs.
That said, the project portion was excruciatingly heavy. It was to build PeerPrep, a platform for students to practice technical interview questions together. That's the core functionality of the project, which required us to develop a matching and a collaboration feature. But of course that's not all. They gave us 12 different bonus features to add to the project. From this list, we were to pick at least 4-5 of them to work on. Most of them were not trivial either. Some involved deployment on cloud platforms including gateway, CI/CD etc. Some involved adding audio and video calls to the collaboration space. Some involved adding an AI assistant, language translation, code execution, and many more. The graders have a checklist of what to look out for when grading your project. Hidden functionality that are not explicitly stated but you're expected to include in your project. As such, always be thoughtful of what you add or exclude.
The most important thing is to document whatever discussion you may have with your groupmates. Key decision points, like why you chose to do option A over option B. For example, if option B was the way that the profs wanted you to do, then you can at least show in your report that the team has discussed it and decided to go with option A for whatever valid reason. Without this documentation, it is an easy missed mark.
Loading comments...