CPSC 410: Advanced Software Engineering
Instructor: Thomas Fritz
In every aspect, this course was the continuation of CPSC 310. There were some overlap between the two, including lectures that covered:
- specifications (informal vs. formal specifications, with user stories as informal specifications)
- some design patterns (observer, composite, etc.)
- SOLID principles
- testing (test coverage with statement/branch/path/multiple condition coverage)
- UML diagrams
- code metrics
- non-functional properties
The topics that weren’t covered in 310 include:
- architectural styles (layered, pipe & filter, blackboard, microservices, etc.)
- more design patterns (decorator, state, strategy, template method, etc.)
- component/deployment diagrams
- REST APIs
- MVP/MVC/MVVM
- distributed systems
- cloud services
- release & deployment
A lot of the topics, such as design patterns and architectural styles, were covered at a high-level so we thought of how to design it (using UML diagrams or whatever type of diagram you prefer to use to display the components and the connections between them) rather than how to implement them. CPSC 410 is about software design and one of the takeaways from this course is that there is no real “right” answer. Quoting from The Pragmatic Programmer book, “there is no such thing as a best solution, be it a tool, a language, or an operating system. There can only be systems that are more appropriate in a particular set of circumstances.” That is why exams had so many written responses as opposed to multiple choice questions. To come up with the most appropriate software design, you have to understand the system’s requirements well. Thus, the in-class activities and the exam problems were gave us real life scenarios that we were supposed to design a system for.
Grade breakdown is the following:
- Project: 50%
- Midterm: 10%
- Final Exam: 40%
As you can see, the project is a huge chunk of your grade. This is unsurprising considering how much effort the project was. Each group came up with their own idea for the project. The only course requirements for the project were:
1. You have to design your own REST API
2. It has to be a mobile app
3. App must not require crowd involvement (therefore, app should be useful for as few as two users)
4. App must not be a database management (CRUD) app*
* While your app should have a back-end that the client can send requests to for purposes such as getting & retrieving information, it should also do more than that - something smart. If you are thinking this is a vague requirement, it’s best to discuss this with a TA since every project is different and this requirement, which expects your app to do something smart and complex, differs for every project.
The grading for the project is the formula:
(group project + bonus) * scale + individual = final project grade
Scale will range between 0.75 and 1.0. The components of the scaling mark will be determined by:
5: completeness (compared to proposal) 5: utility 5: polish 10: difficulty
My team focused on getting the points for difficulty and we were overambitious. Thus, we ended up promising too many things through our user stories and our grade for completeness suffered. That is why I advise those who take this course to be wiser when writing their user stories and be realistic about how time-consuming the user stories will be. Remember, each user story should only take several hours to a few days to complete.
Bonuses (2% each) were given out to the teams with the best pitch, best prototype demo, and best final demo. There’s also the 2% bonus given if you upload your app to a curated app store like Google Play Store or Apple’s App Store.
For the project, we started off with writing a project proposal which included the user stories. Then all the teams gave an in-class presentation on their proposals (5%), and we rated each team’s presentations (0.75%). We then documented and gave an oral assessment (in front of the instructors only) on the architecture & design, which included component, deployment, and UML diagrams as well as designing the REST API (14%). Then came the prototype demo in front of the class (5%) and we reviewed each other’s demos (0.75%). Testing & reflection came afterwards, where we wrote the front- and back-end tests with documentation and an oral assessment (14%). Lastly came the in-class project presentation (7.5%), app reviews again (0.75%), and the project video (2.5%).
I would say that this is the most time-consuming project I have embarked upon and performance is largely contingent on your group member’s abilities. We all had teams of 4 and we had weekly meetings with a TA to discuss our progress. Lectures were once a week from 5 - 8 p.m. Midterm and final exam was based on material covered in lecture, but similar to CPSC 310, expect a few questions on the final to be related to your project.