# Software Development Process Considerations in GNSS-Denied Navigation Project for Drones
## 3 Software Development Process Given for Consideration in This Paper
#### 3.2.4 Retrospective  
Retrospective [9; 30] meetings took place after each iteration. There were frequent meetings performed on the last day of ongoing iteration. Their goal was to conclude the job performed during iteration, to check together achieved results from their acceptance criteria or definition of completed point of view and to talk about the future improvements of the process or technical performance of the product. Additionally, the meeting helped to identify gaps and obstacles that stopped us from doing something (for example, IT environment limitations, missing tolls, etc. ), and to address proposed changes. The goal of retrospective meetings in the drone software development process was to achieve inspection and adaptation. According to the SCRUM Guide [30], we should be transparent to ensure all team members understand the expectations, the goals, the processes we are going through and their role in this \"journey\". The more the transparency, the better for inspection. Then, we can inspect. If we inspect, we can conclude. If we conclude, we can improve and learn. Then, we adapt. There is no adaptation without transparency and inspection. The relationship between these pillars is visualised in Figure 7.  
The relationships clearly pointed out that transparency was the key to achieving the other two values. The process defined in this paper supported transparency and inspection in some aspects. Retrospective meetings, except for talking with the team, concluding together, discussing and resolving or addressing problems, were conducted as shown in Figure 8.  
Figure 7: Relationships between three scrum pillars. The first task in the activity was the project's task completion assessment. This task was based on an interview with the developer responsible for the project's task and mutual verification of achieved results. The general acceptance criteria for every projects' task, no matter if some of them were derived from the parent requirement or not, were as follows:  
* Code is compiling and working;
* Code complies with coding standards;
* Tests are performed on the code and passed;
* Code is documented with Doxygen and the updated document is placed in a dedicated subdirectory in the repository;
* Code is aligned with software design; if not, the design is already updated before finishing a task. If the job performed within the task met its acceptance criteria, the task was assumed to be completed and marked as finished. For the overall endeavour, not every task corresponded only with requirements or finished with a piece of source code being prepared. Some tasks depended on analysis that needed to be performed before source code development or were related to environment and hardware resource preparation. These tasks had additional acceptance criteria defined while taking the task to the iteration backlog. Such tasks did not generate a new branch but were bound to another task that ended up with the source code to facilitate relationships, work completion and error tracking. If any task was assessed as not meeting the acceptance criteria, it was moved to the product backlog and it was preferred to be finished in the very next iteration if possible (sometimes, to complete the task, we needed to perform other tasks first, but this relationship was invisible at a glance). In Figure 8, a task completion assessment is divided into two parts: task completion assessment and code review. If a task was not related to a source code development, the code review was not applied. The process assumed that the number of such tasks was limited only to a few. That is why it is not highlighted in Figure 8 with a separate path bypassing code review and other tasks in the activity. If a task was completed, its branch may be merged into the main branch.