Software Engineering II
14 Dec 2022
Hawaii DoE Legislative Tracker
https://hidoe-legistracker.github.io
The project
This semester, we were tasked to rebuild an application that the Department of Education (DoE) used to track their bills. This application could track the state of the legislative bills, keep up to date with the hearing notices, and allow the user to work on testimony on a given bill through the given workflow. The overall goal was to take the ideas of the old application and renovate the application into a more efficient and modern tool. Any addition that could improve the workflow and quality of life of the application is desired.
The DoE bill tracker
The project started with only a rough idea of what was desired from this renewed program. With only a few screenshots of the old application and some explanation of the tracker, there was much left up for interpretation by our group. Though this allowed our group to think creatively about what the application would become. As desired, we implemented a tracker for bills, testimonies, and hearings. Built to have ease of access and detailed information when requested. Also, including accounts and roles to keep track of every valid user. Roles would be managed by administrative users to keep track of each user’s office and committee they reside. From this point, we implemented other requested features, such as an email system, personal bill manager, and other quality-of-life features. Each system implemented was built to be functional and complementary to other components. Emails are made to send info and directly connect to each bill. The calendar kept each hearing notice tracked and detailed information available at a moment’s notice. The features included were added to complement the program to allow the user to have a better experience compared to the older example.
Challenges and Confusion
This project was a confusing ordeal for a good part of the semester. Understanding each component of this legislative workflow was crucial. Yet the information and requests we received at every other meeting complicated our project flow. Every person giving insight into how the program should work was helpful. Though when ideas collided, the groups working on the project had to be the ones to come up with a compromise. Some ideas seemed very useful and easy to implement, while other requests were borderline impossible for the time we were willing to invest in a single class. This was a good insight into how larger projects, even on a smaller scale, can become complicated to find the best possible outcome for all members. Our group struggled less with the actual code and discussion on this project. Not only having talented members in our group, but we were also able to communicate with each other about what we wanted from each other. Being open to each other and creating a bond was helpful throughout the project. Making any collaborative efforts much easier, and asking for help wasn’t another task. The code was a struggle to deal with for me for not using REACT-based coding. Though I was able to quickly pick up on each language used as the project went on with help of my group. The only real struggle came from finding and using outside open-source codes.
Software Engineering II
Overall this course gave a better insight into what working on a project with multiple members feels like. Compared to Software Engineering I, this course focused on the actual project rather than learning how to enter the project. Giving the experience of starting a project with unknown faces, talking to a customer with unpredictable requests, and the struggles that come from a long-term project. Understandably this course only shows a glimpse into what larger scaled projects are meant to be like. Though it was a good first step into experiencing a project worked on a larger time scale.