# Software Development Process Considerations in GNSS-Denied Navigation Project for Drones
## 3 Software Development Process Given for Consideration in This Paper
#### 3.2.5 Problems Related to the Proposed Solution  
There is no rose without thorns. Although the process was designed to support many aspects of drone software development in the target environment and for specific needs, the solution needed further improvement based on data and collected conclusions. During the drone software development process, we encountered a few problems or obstacles that influenced overall process performance and made it difficult to follow. Each identified problem was given an identifier P1, P2, etc., to support referencing in further text. Problems were mainly related to the following:  
* P1: new task being created \"on the fly\" in an advanced development phase. As the team consisted only of software developers, it was not easy to foresee and prepare correct and stable software requirements before development started. Of course, uncertainty is the source of changes. Uncertainty is related to the project goal and other factors described earlier in the paper. There are still functionality and quality elements we can identify and freeze earlier to minimise the risk and number of changes. This may be pointed out by project objectives [9; 50] and key performance indicators (KPI) related to it [9; 22] or measures of effectiveness (MOE) [15; 51] or measures of suitability (MOS) [15; 51]. As claimed in [52], developers often fall into an \"implementation trap\" [52], focusing on solution space rather than problem space, so requirements prepared by such individuals caught in such a trap are not abstract (free of implementation) [53] and they need to be changed later.
* P2: new tasks (incidents) being created due to a given software release failed tests. This problem was related to handling new tasks (\"incident\" type in our version of GitLab) that were created due to failed tests performed on a given software release, not failed during unit tests conducted by the developer himself. The hard part was how to address changes in ongoing iteration if it appeared that correction was crucial for not delaying other tests planned for a given time and not to break the currently opened branch to avoid merge conflicts.
* P3: Applied branching strategy required discipline to be followed by individual developers. Not following this led to merge conflicts and missing or overwriting code problems.
* P4: Choosing tasks to complete in \"free order\" impacted the test plan and schedule slips. If the test plan for example foresaw that function A or function B was a subject of a particular test run [44], this could require removing that function from the run or changing the schedule if at least one task corresponding to a function (as described in Section 3.2.1) could not be completed on time. To avoid this, the process required providing a little bit of \"control\" in deciding which tasks were to be performed in the following iteration.  
These problems were encountered during the project performing in a specific environment while developing software for the drone navigation system. Other issues may appear and disappear or their impact may be negligible in different environments.