# Software Development Process Considerations in GNSS-Denied Navigation Project for Drones
## 5 Conclusions  
The general idea of a process and its importance for the project was addressed in this article. The explanation of the drone software development process was presented and its implementation in the particular environment was comprehensively addressed. The pros and cons of the proposed approach were discussed. The addressed process was a unique approach performed during drone navigation software development in a specific environment. It grouped individuals reluctant to formalise any activity and without experience in following a planned process during software development. Our environment, dominated by software developers oriented in source code development only, instead of the reluctance to formalisation, is also characterised by the lack of software architects and overall experience in developing software architectures. As a result, we found a solution how to ensure some important quality characteristics like functional completeness and correctness, time behaviour and resource utilisation, analysability, modifiability and testability by the process of design and tool utilisation. This enabled the product quality to be planned (to the mentioned extent), monitored and consciously controlled during product development without overwhelming team members. This was the reason why it was very important to us to make sure the process was accepted by our environment and, as a result, we found a metric that allowed us to assess this acceptance. Traditional approaches, as documented in [6] or [13], assume that the verification process is the point where we verify whether we built the system right. This is usually performed after product realisation. The proposed approach moves the part of verification activities to the product realisation step, yet simultaneously ensures the traceability of tasks, branches and releases to source requirements. Deriving acceptance criteria from requirements to tasks acceptance criteria allowed marking a source requirement as \"completed and verified\" when all tasks related to a given requirement were closed. It resulted in much less time spent on system and components verification later. Functional completeness and correctness, usually ensured by requirements themselves are ensured by the proposed solution by transforming lower-level requirements into tasks for the team. This ensures that no requirement will be missed or wrongly understood by the developer. Required time behaviour and resource utilisation is supported by deriving required values from lower-level requirements to task acceptance criteria. The task will then stay open until those criteria are satisfied. Modifiability and testability, although usually ensured by modular architecture and other architectural means, in the proposed solution are facilitated by ensuring traceability from releases, single branches, tasks, requirements and related problems if any are reported. This approach significantly sped up error corrections or code modifications required, e.g., due to problem P1, creating tasks \"on the fly\", as the developer responsible for a piece of source code was able to track all the way back to find an error or to assess modification impact. The _Stp_ and _Sdeg_ values related to process acceptance helped us to assess the direction of process changes performed during the project. Those values are currently lagging indicators. The fact that the existence of a value shows if the process is more or less accepted, also implies that there are some environmental factors that decide whether a given process will be implemented in a given environment or not. These factors require further investigation and research and thus will be the subject of future work. Unveiling the factors will help design the process from the beginning to be easy to implement in a given environment so that the lagging indicator, uncovered in this paper, will only be a metric confirming the future design.