Richard Doherty
This blog post will be a SWOT analysis of the CS 497 – Computer Science Online Capstone course.
Strengths:
I believe the biggest strength of this course is that most projects require students to utilize the advanced software engineering skills that students have acquired from multiple courses in the CS program. It is often the case that when taking a course students will complete projects that solely focus on the skills that the course is centered on. For example, in the web development course you focus on creating web applications. These websites are hosted on the OSU servers which does not require an understanding of how the hosting and networking of the website works. With the cloud application development course, you will learn about hosting services but will not be hosting complex web applications such as the ones you learned to develop in web development. This is understandable because when designing courses, the professors want the students to focus on the skills required within each course and don’t want to overwhelm the students by requiring them to implement the more advanced skills they learned in other classes. The strength of this class is that you are forced to employ the advanced skills you learned in a multitude of classes in a single large project. This gives the student exposure to the type of development environment that they will be in when working as a software engineer.
Another strength of this course is that it requires a large amount of teamwork and organizational skills. With most classes you will, at most, be working with a single partner for term projects. However, with capstone you will most likely be working with several partners on top of a project sponsor who fills a type of manager or employer role. This requires students to use and understand management skills such as version control and project planning as well as basic organizational skills such as scheduling meetings and communication amongst partners, sponsors, and professors. This also mirrors the environment that students will face in software engineering jobs, which is great exposure.
Weaknesses:
Capstone projects will often ask students to utilize software engineering concepts that they may have a basic understanding of from previous classes but are often asked to research and implement advanced technologies related to these concepts. While I understand that researching new technologies is fundamental to this course, I think that it is easy for students to incorrectly or improperly employ technologies. In my own project we made a similar mistake. We used Firebase as the backend for our android application and wanted to develop an API hosted by a Firebase function to handle all the data storage and retrieval for our application as opposed to implementing Firebase calls in our application’s source code. We did this because in the future our project will expand from an android application into a web and iOS application, and we wanted an easy way to keep data handling consistent. However, after implementing this design we found that this approach negated the off-line querying capabilities of Firebase which is only possible by implementing Firebase calls in our application’s source code. In this scenario we researched backend technologies for Android applications and found Firebase to be the best option, but we began using it without any knowledge of the technology and made a design decision that negated one of its most crucial features.
Opportunities:
An opportunity to improve the weakness I outlined in this course would be to have OSU CS staff, not just capstone instructors, get briefed on the projects available for capstone. In these meetings CS staff will brainstorm ways to implement the project using technologies that they are familiar with. These options, along with the contact information of the professors that proposed them, could then be presented to each group with the understanding that OSU staff has experience with these approaches and can better advise the group if this approach is taken. In the end the project group still has the option to go with whatever approach they desire. For our project, the capstone staff was not familiar with Android and Firebase development compared to other technologies. It would have been nice to get some information on other OSU staff members that are familiar with these technologies or information on other technologies that could be used aside from Firebase or Android that the OSU staff is familiar with.
Threats:
One thing that severely hindered my group’s production was the quality of the handoff from the previous group. It took my group over a week to get in contact with our project sponsor, who we were told had the hand off documentation and source code. Once we got the handoff, we realized that the previous group’s source code threw several errors when loaded into android studio due to file structure dependencies for files that were not included in their source code as well as dependencies on google API keys that were not specified in the code nor in their handoff documentation. The documentation provided only instructions on how to run an APK version of their application, which loads the compiled application into an emulator, and then how to navigate the application once loaded. When a project is assigned at the start of the term the hand off documentation should be immediately provided to the group via the OSU capstone staff, not the project sponsor. Also, when a handoff is submitted at the end of the term the project group should be required to handoff source code in a way that someone can immediately take the code and run it without errors and their documentation should outline steps required for any dependencies, such as API keys, that the next group will need. OSU capstone staff should then grade the handoff based upon their own ability to get a project running from the provided source code and documentation ensuring that the next group will be able to immediately pick up from where they left off.
Leave a Reply