Scope
Developing a web application wasn’t beyond the realm for the development team. The idea of a service-based application formed quickly in a discussion to understand how to bridge lessons garnered from prior projects. The main scope: understanding how to create a functional, user-oriented application which could provide a real time database and other operand functions. Thus, the discussion shifted towards providing a service that would permit the team to familiarize such proficiency. The unfortunate size of CompChores development team meant that a web application was the best of limited choices. To circumvent the shortcomings, CompChores came to the conclusion that the development environment had to permit for scalability, an ability to transform accordingly without requiring a large-scale engineering operations team. An environment that could trim as easily as it could include with little fuss or troubling fallouts. An environment that Dart and Flutter could provide, which will be further discussed in Process and Methods Used. The development team concluded that with the tight development environment, CompChores could feasibly communicate from user to database, permit changes if necessary, all without being too taxing for the scope of its purpose. To clarify, CompChores was focused on a simple service-oriented mindset for its development. Lay the groundwork of a working chore management software before allocating any resources or time to user experience enhancements. Grounded, could be considered the word of the project. For a traditional commercial project, one could consider this inefficient, dangerously conservative in thinking that could jeopardize longevity of the project. For the development team, this was a necessary acceptance as how to realistically achieve a tangible project for C-Day without taking on futile bulk. The primary goal of the project was to better the team’s aptitude towards making a realistic product, even with a team size sometimes less than half of that to other projects. This meant constructing the practical basis and working up. This app would have the capabilities of speaking with a Relational Database and, when permitted, would allow changes to be done and communicated back to the application all in real time. As facile as the scope of the project was to be retained, it did not serve as an excuse to provide an equally scarce product. CompChores would be able to achieve this learning goal while being packaged as an entirely plausible, commercially transferable application.