# Software Development Process Considerations in GNSS-Denied Navigation Project for Drones
## 3 Software Development Process Given for Consideration in This Paper
#### 3.2.3 Software Implementation and Testing  
Software implementation and testing activity was essential during the transformation from specification and design into a tangible item. It was composed of a few tasks as shown in Figure 4.  
After initiating the activity, each developer chose a task from the iteration backlog. The software development plan (SDP) assumed that there should be only one task under implementation at a time for an individual to minimise the risk of errors implemented in the source code. This depended on how the tasks were created and if there were no related tasks that should be at least partially completed before to enable tests for the current task. Each developer followed the path on his own and independently from the others. Fortunately, in the example project, teams were organised so that one developer was responsible for one software component [16], for example, one software application. After the developer decided which task from the iteration backlog to implement first, the branch (For a definition of branch see [47]) was created. The term \"branch\" is related to the git version control tool ([[https://www.git-scm.com/](https://www.git-scm.com/)]([https://www.git-scm.com/](https://www.git-scm.com/)), accessed on 23 September 2024). The general idea of branch management in the project is shown in Figure 5.  
Figure 4: Software implementation and testing activity. Figure 3: Iteration planning activity. There was one main branch foreseen to store the source code. It was accepted in the retrospective after each iteration (the next activity in the process). Each developer responsible for the chosen task created a new branch from the main branch at the beginning of the iteration. Before the first iteration, the main branch stored an empty repository structure. Each developer needed to clone and organise a project in the integrated development environment (IDE) of choice to fit the repository structure. The repository structure is shown in Figure 6.  
After preparing the project in the IDE, each developer had to create a branch with an identifier designed for error or defect tracking and task management. Identifier details have no meaning for this article, so they will not be discussed. Each branch corresponded to a different issue. To facilitate repository and task/issue management, the GitLab tool ([[https://about.gitlab.com/](https://about.gitlab.com/)]([https://about.gitlab.com/](https://about.gitlab.com/)), accessed on 23 September 2024) was selected. Selection criteria are beyond the scope of this paper, as the tool is only a means to facilitate activities but is not, and should not be, the core of the process. Tool selection criteria were also dependent on company factors. In the GitLab, issues are marked with \"#\" followed by a number pointing to a particular unique issue number. Corresponding with Figure 5, \"issue #1 CS\" and similar text in rectangles on the left mean different branches corresponding to all issues. \"CS\", \"MNS\" and \"DMS\" that appear in this paper are acronyms of the full names of software components developed during the example project and have no meaning for this article. Figure 5: Branch management. After having work completed, or at the end of the iteration (during retrospective described further), the last created and completed branch (meaning that the corresponding task was also completed) was merged to the main branch that stored the up-to-date and working code. Splitting teams where only one team/individual (as a team) was responsible for their component and organising repository, as shown in Figure 6, allowed to minimise the number of merge conflicts depending on team size and internal communication. If the task was not completed, or its results did not fit the acceptance criteria as pointed out in the iteration planning activity, the branch was recognised as unsuccessful and was moved to another iteration. In such cases, the last successful branch was merged with the main branch to ensure that only the working code was stored.