# Software Development Process Considerations in GNSS-Denied Navigation Project for Drones
## 4 Process Metrics
### Standard Metrics Used to Evaluate Process  
The standard metrics applied to evaluate the process focused on two values used to support future estimations and planning future iterations. These were as follows:Individual velocity (\(V_{Ind}\));  
* Team velocity (\(V_{T}\)). Individual velocity was calculated by dividing the number of closed tasks by one person in a given iteration and it was expressed in [tasks/iteration]. It was useful for estimating the time remaining to close all tasks related to the software components assigned to an individual and to correct time estimations needed to complete tasks in an iteration. It also helped to decide how many tasks an individual could take for one iteration concerning the declared time available, as mentioned in Section 3.2.2:  
\[V_{Ind}=\frac{\sum_{0}^{i}T_{clmd}}{i}\]  
where  
\(i\) = number of closed iterations;  
\(T_{clmd}\) = number of tasks closed by an individual in closed iterations;  
\(V_{Ind}\) = individual velocity expressed in [tasks/iteration]. Individual velocity (\(V_{Ind}\)) was influenced by problems _P3_ and _P4_ mentioned in Section 3.2.5. Not following the branching strategy (problem _P3_) made it more difficult for developers to complete tasks, as they required more time to resolve conflicts or missing code. Choosing tasks to complete in free order (problem _P4_) resulted in work being blocked by the need for another task to be completed first (e.g., due to lack of data source or entry point). The total number of closed tasks equalled the number of tasks closed by any individual team member. Team velocity was calculated by dividing the total number of closed tasks by the number of closed iterations:  
\[T_{cTeam}=\sum_{0}^{n}T_{cInd}\]  
where  
\(n\) = number of individuals in the development team (team size);  
\(T_{clmd}\)--as above;  
\(T_{cTeam}\) = total number of tasks closed by the team in closed iterations. Then, the team velocity (\(V_{T}\)) was computed with a given formula:  
\[V_{T}=\frac{T_{cTeam}}{i}\]  
where all symbols are explained above. The number of iterations left (\(I_{left}\)) to complete the project was estimated as follows:  
\[I_{left}=\frac{V_{T}}{T_{o}}\]  
where  
\(V_{T}\) is as above;  
\(T_{o}\) is number of open tasks left. The number of iterations left to complete the project was calculated as required or when significant changes in team velocity were noticed. Team velocity (\(V_{T}\)) helped estimate the overall time needed to complete the project. Problems _P1_ and _P2_ mentioned in Section 3.2.5, unfortunately, impacted estimations because the number of opened tasks was rising, making previous estimations invalid. Low individual or team velocity values had an impact on estimations alerting possible schedule slips. We could calculate the required team velocity by dividing the number of tasks at the beginning of the development by the time to complete them all expressed in iterations (if we needed to determine the required number of tasks completed per iteration). See Figure 9 for a visualisation of the actual team velocity impact on schedule. As the proposed process preparation of tasks to be completed was assumed to be a single-time activity performed before development began (see Section 3.2.1), it was easy to calculate the required team velocity, as the number of tasks to be completed was considered stable or stable in the most part (see Section 3.2.1 and assumption about % of stable requirements). Given that, problem P1 related to creating new tasks on the fly was a little bit of a challenge, as also mentioned in Section 4.2. Schedule slips in the mentioned GNSS-denied navigation project targeted for drones were a kind of a trap. As the developed solution was targeted at drones, it was also planned to be tested on a drone. This, however, was dependent on weather conditions. Moving a schedule further toward months characterized by rains and strong winds would result in a much bigger schedule slip than estimated. Not only schedule slips were the result of low team velocity.