This semester I was able to take a course called ICS 414: Software Engineering II. This course varied differently to other computer science courses at Manoa because it is a team project based course. I found that it was the closest I’ve ever had to real world experience in the field. We had to learn to assign tasks to one another, set aside realistic goals, and have group meetings every so often to check everyone’s progress and issues. Compared to other courses it was surprisingly difficult to adapt from independent work to team work. There’s a lot more checks that code must go through including approval for commits and pushes to main (which are always fear inducing). Overall there was a lot I learned from the group aspect of this course.
At the beginning of the year we were all assigned to a small group. We were provided with a spreadsheet featuring the data and math functions that would need to be accessible in the application. The program would feature role based accessibility, as in only auditors can modify audit data, analysts can perform calculations, administrators can modify user accounts, etc. We’d also need to implement a database that can hold user and finance information. Finally, being able to deploy it with in our case Digital Ocean. Truthfully it seemed pretty daunting at the start of the class. This would be the largest scale project that I’d ever worked on. There was an initial meeting with Spire (the customer) to discuss the primary functions of the application, what they were looking for as users, and provided a space that we could ask questions. Our goal was to work together to program a financial forecast application and model for a finance organization called Spire.
After we initally met with our team for the first time, we had our first Customer Milestone Meeting. These meetings serve as checkups between the programmer and the customer to check progress and ask questions. It felt very practical and professional and is definitely an aspect of work I’d expect in the field. During these meetings we’d take notes and show off our progress. As stated previously, the first meeting was more introductory to who the customer was and what they were looking for in the application. Throughout the project’s life we used the Milestone Project feature on Github. After the meetings we’d consult our notes and add tasks to the project board to be completed. This allowed us to set specific goals and deadlines to adhere to. Usually we wanted each person to add around 2-3 tasks per milestone to streamline our productivity and ensure that we’re making good progress between milestones. While it was easy to finish the board in the beginning half of the semester, towards the end the tasks became more complex and required more time. On top of that other classes started have midterms, exams, and more rigorous work so it became more challenging to balance. Something that I wouldn’t expect to be too much of an issue when only working. We implemented our application using a combination of Meteor and React jsx building upon the Island Snow template from ICS 314.
This project had the largest group that I have ever worked with. From the outside that seems like it would only make us faster and more productive but there was somewhat of a communication delay. Not everyone was able to attend most of our meetings, some people just stopped showing up, and it created a task bottleneck. Some of the tasks we had assigned to others just never ended up getting completed and kept getting moved to the next milestone board. After a certain amount of time, others had to adopt those tasks which only further delayed the completion of the milestone. This would result in more and more tasks having to get rolled to the next milestone and really bogged down the total amount of work we were completing. Again I think that this was a class related challenge seeing as every member had classes other than this and that in a working environment this project would be a much higher priority and would require much more time and focus on by the developers. A personal challenge was the focus on a pretty UI. The projects that I’ve worked on had UI that was more functional as opposed to pretty but because this project was for the everyday user, the UI needed to be intuitive, informative, pretty looking. I definitely had to review bootstrap and react documentation to ensure that the tables and graphs were visually acceptable.
I learned a lot about project management in this course. Like how to meet with the customer and establish the things that they want to change or add to the product, how to work with a team and schedule everyone’s tasks and make sure that those tasks are realistic and reasonable provided the deadline and abilities of the team. As well as forming a strong team bond to build trust and chemistry and ensure that our work is quality. I’ve learned the importance of proper scheduling and making sure that teammates are on pace, and if they’re not distributing the workload to ensure we are on time.
This course was very beneficial not only as a student but career wise. The way the course was oriented made it feel as though we were contracted to create an appliation for Spire and created an environment that mimics that of the real world. Having to meet with the customer, take that feedback to the team, assign duties and deadlines, and actual code. It’s far different than the other classes I’ve had where it was simply the goal of the program and then writing the code. This course required us to communicate the needs of the customer with the requirements changing over time. Which is far more realistic than a requirement set in stone from the beginning. I think that going forward I’ll be able to draw upon the experience of this course in whatever job, internship, or projects I have in the future.