<commit_before>\chapter{Software development and management processes}
The following chapter explains the software development and management processes that were employed throughout the project. In the following section some of the necessary terminology will be introduced and explained. Subsequently the process description will be given, followed by a comparison to established process models.

\section{Terms}
Here follows a description of terms as used in the current project.

\begin{description}

\item[Agile methods] \label{def:agile} are a set of software development methods that emphasize on adapting to change over following a predetermined plan, continuous customer collaboration over contract negotiation and implementation over documentation.

\item[Extreme Programming] (XP) is an agile software development methodology which favors improving the code and quick responses to customer desires. The customer is involved with the process continuously, and keeps giving feedback on the most recent progress. Releases of new code is also supposed to happen often, so both the customer and the developers are aware what the current progress is, and can give feedback on it. Both the code and requirements are expected to change during the development process. It is incremental in that what the customer wants is implemented swiftly, and stays as a part of the code. It is iterative in that code that is added will likely be subject to change and refactoring during the development process. Constant refactoring and pair-programming is made use of so the quality of the code will be kept as high as possible, as it will be difficult to plan and design for code-quality before production of code starts. 
% like Iterative development except it is faster. Extreme programming uses a cycle based programming system like the Iterative approach. Unlike the Iterative approach it has a checkpoint after each stage, where the code is being released and new customer requirements is added. The customer are often intimately involved in prioritizing and specifying the requirements. Extreme programming enables the possibility to make it so that several developers can produce code, integrate and test it on the same day.  %TODO: FIX
\item[Iterative development] \label{def:incrementalDev} is an approach to software development that is "based on the idea of developing an initial implementation, exposing this to user comment and evolving it through several versions until an adequate system has been developed"\footnote{Sommerville, p32 \cite{sommerville}}. Benefits to iterative development include adaptability to changing requirement and facilitation of feedback. In the negative side, it can be hard to keep an overview of the progress of the entire system, making it harder to plan ahead for deadlines.

\item[Pair programming](PP) \label{def:pairprogram} is a programming technique taken from XP. In PP, coders work in pairs that work on the same workstation. As each line of code is looked at by at least two people, code development simultaneously acts as a review process, making code developed by a programmer pair more reliable and readable than code developed by an individual programmer. For complex coding tasks, the productivity of a programmer pair is normally higher than that of two individual programmers, considering the reduced effort required for bug fixing. For routine tasks, however, productivity is lower in a programming pair.

\item[Plan-driven development] \label{def:plan-driven} is an approach to software development that recommends careful planning of the software development process, work breakdown and scheduling before starting the implementation process. 

\item[Sprint] \label{def:sprint} is the period unit in which work is planned and done. It is customary to operate with sprints of 2-4 weeks, but the current project operated with sprints of 1-2 weeks.

\item[Spike] \label{def:spike} is a sprint spent primarily or solely on non-programming activities, such as research, documentation or planning.

\item[Stand-up] \label{def:dailyScrum} is a meeting in which all the group members explain shortly what they have been doing since the last meeting, what they are planning to do until next time, and any help or advice they need to continue. Stand-ups function as a binding factor that keeps the entire group on the same page, and provides flexibility by giving the opportunity to change the plans and tasks partway through the sprint.

\end{description}

\section{Development process}
\label{def:devProcess}
The customer required an incremental development process where, ideally, a new version of the product could be demonstrated at every weekly customer meeting. Furthermore, plans for the following week were to be sketched in collaboration with the customer at the weekly meeting. With such short-term plans, and as the requirements were still vague and the product to be developed largely experimental, a high degree of flexibility was required. A plan-driven approach was therefore impossible at the beginning of the project. The process model employed in the early stages of development was therefore based on agile methods, and extreme programming in particular. Due to the customer requirements, sprint length was set to one week, with the possibility for two week sprints in certain cases, such as when the customer is unable to show up to a weekly meeting, or the required tasks are more extensive than usual. 

Meetings between the customer and the group normally took place on Fridays, and were followed by a group planning and work session. Stand-ups were originally planned for Wednesdays and Sundays, as these were the only times all the group members were available at the same time. The meetings at Sundays were conducted online, and the Wednesday meetings at the university. The Sunday stand-ups were abolished after a few weeks, as little work had normally been done between the Friday session and the Sunday stand-up. To compensate for the relative low frequency of stand-ups (Agile development teams in full-time work environments normally hold daily stand-ups.) other communication channels, such as e-mail and Trello\footnote{See page \pageref{def:trello} for more information} were heavily used.

The process model incorporated a liberal approach to pair-programming, where coders formed programming pairs only for tasks deemed complex. Another principle that was taken from XP was that of collective ownership of the code. Emphasizing the fact that nobody "owns" a particular class made it easier for the group members to accept changes when demanded, thus ensuring development agility\footnote{In the Javadocs, every class has a listed author that can be contacted if any future developer has any questions regarding the code in that class. While this may break the principle of collective ownership, the "author" of a class selected after development were finished, so as to not interfere with the development process.}.

The task assignment procedure was largely agile: After the weekly sprint planning meeting, the individual group members could choose which tasks they would like to work on in the following sprint. Tasks were thus assigned in a first-come first-served fashion. When a member finished one task, a new one would be taken. The Group Leader only had to assign tasks in exceptional cases.

Some elements of extreme programming were not employed in the development process, particularly when it comes to testing. XP advocates \emph{Test-Driven Development} (TDD), where automated unit tests\footnote{See the testing chapter for details on unit testing} are developed before the corresponding code is written. As no group members had any experience in test automation or TDD, employing such an approach appeared to entail more challenges than benefits. 

After Easter several changes in the circumstances prompted a change in development methodology. These included:
\begin{itemize}
\item A much clearer definition of the requirements and the project goals had gradually emerged.
\item The time left until the final deadline had decreased significantly.
\item The number of potential tasks left had remained close to constant throughout the semester, as finishing one task often leads to insights as to what can be done further.
\item The group had attained a better understanding of its own work process. 
\item Significant integration and system testing was needed.
\end{itemize}
These circumstances revealed the necessity for as well as the possibility to make concrete plans, and prioritize between the potential tasks. Therefore,  the development model was changed to a plan-driven approach that still enforced incremental delivery. Some flexibility was still maintained, by making a buffer of optional tasks in case of delays or unforeseen requirement changes. Useful elements from XP were still preserved, such as pair programming and individual choice of tasks.

\input{MeetingCustomerSupervisor}
\section{Plans}	

Nearing the end of every sprint, the customer and group agreed upon the content of the following sprint. This list has been placed in Appendix \ref{tab:sprintList}, and provided a short summary of what was accomplished in a particular time-frame. 

The customer favoured a user-oriented development method which focused on first developing a complete mock-up GUI, and base development of data models and back-end functionality on what the GUI requires to function properly. Development of the back-end model should in this method proceed "top-down", in that functionality that directly influences user experience should be implemented before more fundamental, data-manipulating methods. Advocates of this development method claim that first developing the GUI puts user-friendliness in focus, and constrains which functions are required in the back-end, so that no superfluous methods need to be implemented. On the downside, this may cause some of the back-end methods to be down-prioritized due to time constraints.

A radically different approach would be a "bottom-up" method that focuses on first developing the most challenging and novel parts of the system, in particular algorithms for step detection and calculation of fall risk scores. This method would only start developing increasingly more user-oriented functionality when the more fundamental methods have been verified. An advantage of this method is that it allocates all the time necessary to master the complex issues first. On the other hand, this could cause development of the user-oriented features to be neglected due to time constraints. 

In fact, the difference between these two approaches only reveals itself in the product when time constraints force certain features to be down-prioritized. Implementation and verification of fall risk assessment features\footnote{Acceptance testing confirmed that the users shared this impression, see section \ref{def:accTesting} for details.} was one of them due to this project followed a user-oriented development method. GUI development got a lot more attention in accordance to the customers wishes. If a "bottom-up" method had been used, it seems likely that the project would have resulted in well-tested and extensive fall risk assessment components, but with little or no GUI intended for the target group. 

\section{Team Roles and Organization}
%Extreme programming advocates a flat structure, where every member of the group were considered to be capable and willing to work at all the tasks, and as such there was not much place for specific roles among the group. However, to make sure that no area was neglected, some sort of overview was required, and three roles were therefore defined. Common for the roles is that they entail responsibilities for a particular domain, but provide no advantages.<commit_msg>Moved and elaborated on TDD in XP<commit_after>\chapter{Software development and management processes}
The following chapter explains the software development and management processes that were employed throughout the project. In the following section some of the necessary terminology will be introduced and explained. Subsequently the process description will be given, followed by a comparison to established process models.

\section{Terms}
Here follows a description of terms as used in the current project.

\begin{description}

\item[Agile methods] \label{def:agile} are a set of software development methods that emphasize on adapting to change over following a predetermined plan, continuous customer collaboration over contract negotiation and implementation over documentation.

\item[Extreme Programming] (XP) is an agile software development methodology which favors improving the code and quick responses to customer desires. The customer is involved with the process continuously, and keeps giving feedback on the most recent progress. Releases of new code is also supposed to happen often, so both the customer and the developers are aware what the current progress is, and can give feedback on it. XP furthermore advocates \emph{Test-Driven Development} (TDD), where automated unit tests\footnote{See the testing chapter for details on unit testing} are developed before the corresponding code is written. Both the code and requirements are expected to change during the development process, but the functionality of each unit remains the same. It is incremental in that customer requirements wants are implemented swiftly, and stays as a part of the code. It is iterative in that code that is added will likely be subject to change and refactoring during the development process. Constant refactoring and pair-programming is made use of so the quality of the code will be kept as high as possible, and the automated unit tests ensure that the system still performs the expected functions, even after extensive refactoring. 

\item[Iterative development] \label{def:incrementalDev} is an approach to software development that is "based on the idea of developing an initial implementation, exposing this to user comment and evolving it through several versions until an adequate system has been developed"\footnote{Sommerville, p32 \cite{sommerville}}. Benefits to iterative development include adaptability to changing requirement and facilitation of feedback. In the negative side, it can be hard to keep an overview of the progress of the entire system, making it harder to plan ahead for deadlines.

\item[Pair programming](PP) \label{def:pairprogram} is a programming technique taken from XP. In PP, coders work in pairs that work on the same workstation. As each line of code is looked at by at least two people, code development simultaneously acts as a review process, making code developed by a programmer pair more reliable and readable than code developed by an individual programmer. For complex coding tasks, the productivity of a programmer pair is normally higher than that of two individual programmers, considering the reduced effort required for bug fixing. For routine tasks, however, productivity is lower in a programming pair.

\item[Plan-driven development] \label{def:plan-driven} is an approach to software development that recommends careful planning of the software development process, work breakdown and scheduling before starting the implementation process. 

\item[Sprint] \label{def:sprint} is the period unit in which work is planned and done. It is customary to operate with sprints of 2-4 weeks, but the current project operated with sprints of 1-2 weeks.

\item[Spike] \label{def:spike} is a sprint spent primarily or solely on non-programming activities, such as research, documentation or planning.

\item[Stand-up] \label{def:dailyScrum} is a meeting in which all the group members explain shortly what they have been doing since the last meeting, what they are planning to do until next time, and any help or advice they need to continue. Stand-ups function as a binding factor that keeps the entire group on the same page, and provides flexibility by giving the opportunity to change the plans and tasks partway through the sprint.

\end{description}

\section{Development process}
\label{def:devProcess}
The customer required an incremental development process where, ideally, a new version of the product could be demonstrated at every weekly customer meeting. Furthermore, plans for the following week were to be sketched in collaboration with the customer at the weekly meeting. With such short-term plans, and as the requirements were still vague and the product to be developed largely experimental, a high degree of flexibility was required. A plan-driven approach was therefore impossible at the beginning of the project. The process model employed in the early stages of development was therefore based on agile methods, and extreme programming in particular. Due to the customer requirements, sprint length was set to one week, with the possibility for two week sprints in certain cases, such as when the customer is unable to show up to a weekly meeting, or the required tasks are more extensive than usual. 

Meetings between the customer and the group normally took place on Fridays, and were followed by a group planning and work session. Stand-ups were originally planned for Wednesdays and Sundays, as these were the only times all the group members were available at the same time. The meetings at Sundays were conducted online, and the Wednesday meetings at the university. The Sunday stand-ups were abolished after a few weeks, as little work had normally been done between the Friday session and the Sunday stand-up. To compensate for the relative low frequency of stand-ups (Agile development teams in full-time work environments normally hold daily stand-ups.) other communication channels, such as e-mail and Trello\footnote{See page \pageref{def:trello} for more information} were heavily used.

The process model incorporated a liberal approach to pair-programming, where coders formed programming pairs only for tasks deemed complex. Another principle that was taken from XP was that of collective ownership of the code. Emphasizing the fact that nobody "owns" a particular class made it easier for the group members to accept changes when demanded, thus ensuring development agility\footnote{In the Javadocs, every class has a listed author that can be contacted if any future developer has any questions regarding the code in that class. While this may break the principle of collective ownership, the "author" of a class selected after development were finished, so as to not interfere with the development process.}.

The task assignment procedure was largely agile: After the weekly sprint planning meeting, the individual group members could choose which tasks they would like to work on in the following sprint. Tasks were thus assigned in a first-come first-served fashion. When a member finished one task, a new one would be taken. The Group Leader only had to assign tasks in exceptional cases.

Some elements of extreme programming were not employed in the development process. While the development model was incremental, it was not iterative. In other words, a particular method is not expected to change a lot once completed. As no group members had any experience in test automation or TDD, and because TDD is intended for iterative approaches with extensive refactoring, employing such an approach appeared to entail more challenges than benefits.

After Easter several changes in the circumstances prompted a change in development methodology. These included:
\begin{itemize}
\item A much clearer definition of the requirements and the project goals had gradually emerged.
\item The time left until the final deadline had decreased significantly.
\item The number of potential tasks left had remained close to constant throughout the semester, as finishing one task often leads to insights as to what can be done further.
\item The group had attained a better understanding of its own work process. 
\item Significant integration and system testing was needed.
\end{itemize}
These circumstances revealed the necessity for as well as the possibility to make concrete plans, and prioritize between the potential tasks. Therefore,  the development model was changed to a plan-driven approach that still enforced incremental delivery. Some flexibility was still maintained, by making a buffer of optional tasks in case of delays or unforeseen requirement changes. Useful elements from XP were still preserved, such as pair programming and individual choice of tasks.

\input{MeetingCustomerSupervisor}
\section{Plans}	

Nearing the end of every sprint, the customer and group agreed upon the content of the following sprint. This list has been placed in Appendix \ref{tab:sprintList}, and provided a short summary of what was accomplished in a particular time-frame. 

The customer favoured a user-oriented development method which focused on first developing a complete mock-up GUI, and base development of data models and back-end functionality on what the GUI requires to function properly. Development of the back-end model should in this method proceed "top-down", in that functionality that directly influences user experience should be implemented before more fundamental, data-manipulating methods. Advocates of this development method claim that first developing the GUI puts user-friendliness in focus, and constrains which functions are required in the back-end, so that no superfluous methods need to be implemented. On the downside, this may cause some of the back-end methods to be down-prioritized due to time constraints.

A radically different approach would be a "bottom-up" method that focuses on first developing the most challenging and novel parts of the system, in particular algorithms for step detection and calculation of fall risk scores. This method would only start developing increasingly more user-oriented functionality when the more fundamental methods have been verified. An advantage of this method is that it allocates all the time necessary to master the complex issues first. On the other hand, this could cause development of the user-oriented features to be neglected due to time constraints. 

In fact, the difference between these two approaches only reveals itself in the product when time constraints force certain features to be down-prioritized. Implementation and verification of fall risk assessment features\footnote{Acceptance testing confirmed that the users shared this impression, see section \ref{def:accTesting} for details.} was one of them due to this project followed a user-oriented development method. GUI development got a lot more attention in accordance to the customers wishes. If a "bottom-up" method had been used, it seems likely that the project would have resulted in well-tested and extensive fall risk assessment components, but with little or no GUI intended for the target group. 

\section{Team Roles and Organization}
%Extreme programming advocates a flat structure, where every member of the group were considered to be capable and willing to work at all the tasks, and as such there was not much place for specific roles among the group. However, to make sure that no area was neglected, some sort of overview was required, and three roles were therefore defined. Common for the roles is that they entail responsibilities for a particular domain, but provide no advantages.
{'fraction_non_alphanumeric': 0.029916166645389167, 'fraction_numerical': 0.0005106600280863015, 'mean_word_length': 5.036475725661443, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 6, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3933811', 'n_tokens_mistral': 4916, 'n_tokens_neox': 4715, 'n_words': 3501}