74 lines
7.8 KiB
TeX
74 lines
7.8 KiB
TeX
\section{Method}
|
|
|
|
The development of Study Sprint followed a practical and iterative project method. Rather than treating the application as a fixed specification that could be implemented in one pass, the team worked from a product vision, built early versions of the core functionality, and then refined the solution as weaknesses became clearer through use, testing, and discussion.
|
|
|
|
\vspace{2mm}
|
|
|
|
This approach fit the nature of the project well. The main challenge was not only to implement isolated features, but to shape a small mobile product that felt coherent, reliable, and easy to use in practice. Because of that, the method had to support both technical implementation and repeated revision of structure, flow, and scope.
|
|
|
|
\subsection{Vision-Driven and Scope-Conscious Development}
|
|
|
|
The project vision functioned as the main strategic starting point for the work. It defined the target users, the most important customer needs, and the product attributes that mattered most for success. In particular, simplicity, reliability, low friction, and realistic scope were treated as guiding constraints throughout the project \cite{projectvision}.
|
|
|
|
\vspace{2mm}
|
|
|
|
This had a direct effect on development priorities. Features that supported the core study flow were given precedence, while ideas that would broaden the product without strengthening its main purpose were de-prioritised or excluded. That is also why the report separates requirements into must-have, should-have, could-have, and will-not-have categories. This prioritisation made it easier to protect the project from feature growth and to keep effort focused on the parts of the application that contributed most directly to the intended user experience.
|
|
\clearpage
|
|
|
|
|
|
\subsection{Iterative Prototyping and Refinement}
|
|
|
|
The practical development process was iterative. Early work focused on establishing the underlying structure of the app, including navigation, CRUD support for subjects, assignments, and tasks, and the first timer-related flows. These early versions were useful for confirming that the main ideas were technically possible, but they also revealed architectural and usability problems that were not obvious at the planning stage.
|
|
|
|
\vspace{2mm}
|
|
|
|
One clear example was the relationship between the app's conceptual data model and its screen structure. The intended hierarchy was always \textit{Subject $\rightarrow$ Assignment $\rightarrow$ Task}, but earlier versions exposed assignments and tasks too much as top-level concepts. As the app was used and reviewed, this was recognised as a source of redundancy, weak context, and unnecessary navigation complexity. The architecture was therefore revised so that the interface reflected the actual hierarchy more clearly.
|
|
|
|
\vspace{2mm}
|
|
|
|
The same pattern appeared in the timer and session logic. Initial timer behaviour was gradually replaced by a more complete session model with focus sessions, breaks, persistence, and safer finalisation rules. Several parts of the timer flow changed more than once as practical issues were discovered, especially around routing, active-session recovery, break handling, and reliability. In that sense, prototyping was not only used to create a first version, but also as a way to expose where the product model was still too weak or too rough.
|
|
|
|
\subsection{Incremental Delivery of Core Features}
|
|
|
|
The implementation was carried out in layers rather than as one large build phase. A basic feature foundation was established first, followed by increasingly product-specific refinement.
|
|
|
|
\vspace{2mm}
|
|
|
|
At an early stage, the work concentrated on basic entity management and data flow, such as creating, editing, viewing, and deleting subjects, assignments, and tasks. After that, the project moved further toward the product's intended identity by adding progress tracking, local reminders, more structured navigation, and task-linked study sessions. Later work focused more strongly on reducing friction in the main study flow, improving onboarding, and making the timer and break cycle more robust.
|
|
|
|
\vspace{2mm}
|
|
|
|
This incremental method helped reduce risk. A simple but working baseline could be established first, after which the team could decide which refinements actually improved the product and which ideas were unnecessary within the project's time constraints.
|
|
|
|
\subsection{Testing, Verification, and Revision}
|
|
|
|
Testing in this project was not treated as something that only happened at the end. Instead, verification and revision were interwoven with development. When new functionality was added, the result was checked, weaknesses were identified, and the implementation was adjusted before the project moved further.
|
|
|
|
\vspace{2mm}
|
|
|
|
The notes show two main forms of verification. The first was manual testing of the app's actual behaviour, especially in flows where user interaction and timing mattered. This was particularly important for the timer, break handling, onboarding flow, routing, and notification behaviour. The second was technical verification through static checks such as linting and TypeScript compilation, which helped detect invalid code, inconsistent types, and integration mistakes before further changes were added.
|
|
|
|
\vspace{2mm}
|
|
|
|
This combination was necessary because the project contains both logic-heavy and interaction-heavy features. Static checks can confirm that the codebase is structurally valid, but they cannot on their own confirm that a timed session flow feels correct or that screen transitions behave as intended. Manual testing was therefore especially important whenever reliability, usability, or flow clarity were central concerns. For native-dependent functionality such as notifications, a development build was also used instead of relying only on Expo Go, since that gave more realistic behaviour during testing.
|
|
|
|
\subsection{Collaboration and Work Organisation}
|
|
|
|
The work was organised as a collaborative group project with regular meetings, shared responsibility, and ongoing task distribution. According to the project vision and group contract, the group planned to meet weekly to review progress, divide work, and discuss problems as they appeared. Discord functioned as the main communication channel between meetings, making it easier to adjust responsibilities when needed.
|
|
|
|
\vspace{2mm}
|
|
|
|
Because the project remained relatively limited in scope, with a small team and a fairly small number of central features, the group did not use a heavier Scrum-oriented project management setup with dedicated ticket tools such as Taiga. In practice, many tasks were easier to define, discuss, and re-prioritise through regular meetings and direct communication than through maintaining a formal backlog with only a few active items. This reduced unnecessary administrative overhead and made the work organisation more appropriate for the actual scale of the project.
|
|
|
|
\clearpage
|
|
|
|
Version control and shared documentation were important parts of the method. GitHub was used to manage source code and changes over time, while notes and work reports were used to document completed work, encountered problems, and follow-up decisions. This created a lightweight but useful development trail that supported both collaboration and report writing.
|
|
|
|
\subsection{Why This Method Was Appropriate}
|
|
|
|
An important reason for choosing this style of method was that Study Sprint is a product where usability, flow, and reliability matter at least as much as raw feature count. A more rigid process could have described the intended system early, but it would have been less useful for improving the real experience of moving from planning work to starting a study session.
|
|
|
|
\vspace{2mm}
|
|
|
|
The iterative and scope-conscious method therefore matched the project well. It allowed the team to begin with a workable prototype, identify weaknesses through repeated review and testing, and gradually move the application toward a more coherent and dependable final form without losing control of scope.
|