# Software Development Process Considerations in GNSS-Denied Navigation Project for Drones
## 3 Software Development Process Given for Consideration in This Paper
#### 3.2.1 Preparation Activity
The means provided by the process to support product quality in terms of mentioned quality characteristics were as follows:  
* Task traceability to requirements and vice versa (to support product functional completeness concerning software requirements specification);
* Deriving task acceptance criteria from parent requirement (to support performance efficiency assessment and make sure that the final product reflects its specification, which supports a partial software verification [15; 39]);
* Provide unique identifiers related to software products [13], their version, branch, iteration and documentation set to support error and defect management and project completion and to ease analysis while looking for errors or estimating the impact of proposed or required changes;
* Binding branch and task identifier to a specific part of source code developed during iteration to support analysability, which limits the inspection only to that part of the source code;
* Unifying work style and language usage (modifiability and analysability), in part not dependent on system/software design, supported by the process itself. Addressing coding standards should ensure that everyone in the team \"speaks the same language\" and can support product development or modifications of source code prepared by somebody else from the team without having doubts about the meaning of variables and so on. Functional requirements may be represented as a use case if there is an interaction with an actor as in [40; 41; 42], user story as in [43; 44; 17; 45] or traditional requirement as in [29; 45]. User stories may contain some additional information about quality or acceptance criteria and are prepared following INVEST rules [17; 43] rather than the quality criteria mentioned in [1; 18; 37; 39; 45] for traditional requirements. They shall be transformed, decomposed to other forms and supported by additional information to facilitate analysis or traceability as they may not provide full or detailed specifications [45]. Some more discussion about the meaning of requirements in the project can be found in [15]. After this \"one-time\" activity (assuming all software requirements are prepared before the process starts; otherwise, this activity is repeated for the rest of the requirements) the list of tasks that constitute a product backlog [22, 30] is prepared and iteration planning may now begin. Although the process-assumed requirements are stable before entering the first activity in the process, the process may trigger a need to return and refine requirements on every level, as the knowledge about the problem and possible solutions mature during the project (as a tool of \"adaptation\" [30]). This is not marked explicitly in the software development process itself, as this is rather the matter for the configuration/change management process [1, 6, 15, 29, 46]. A software development plan is one of the inputs needed by the process to facilitate giving some additional (of little importance for this article matter) parameters/data to tasks selected in iteration planning. It is to simplify traceability, task management, results reference (for example, a reference to a file containing a comprehensive report or other information needed to complete the task, etc.) and tracking relationships between tasks (if any).