Developer’s time spent in a software project part using the SGD framework

(1)

INOM

EXAMENSARBETE DATATEKNIK, GRUNDNIVÅ, 15 HP

STOCKHOLM SVERIGE 2016,

Developer’s time spent in a software project part using the SGD framework

SIMON CIESLUK

KTH

(2)

Royal Institute of Technology KTH

Developer’s time spent in a software project part using the SGD framework

Simon Ciesluk

(3)

Abstract

Resource management is important for software projects to be successful. Time is one of these resources that needs to be managed. To do this you need to know how time resources are spent. Currently the existence of published material on time resources spent in a software project is almost none.

In this thesis a research was conducted on how time resources are spent by an individual developer in a software project. The Self-Governance Developer framework was the tool used to gather these resources. The purpose was to find out how much and where time resources are spent and improve the own way of working to become a better software engineer. However, the goal of the research was to provide a basis for relevant models like process models, measurement models and SPI models which include or are based on time management.

The research method applied was action research where the author of this thesis was the subject of study. The research was of quantitative type and had an inductive reasoning. Data collection was conducted via action research and literature study. Data evaluation was conducted via an evaluation model. The evaluation model included the following evaluation criteria: (1) sum of time spent on each individual activity within the scope of the project, (2) distribution of the time across activity types on an iteration basis, (3) differences of time spent on various activities in various iterations, and (4) coverage of the developer activities in the SGD Framework.

The results shows how much and where time resources were spent for the developer studied in the research during the part of the project. Still, further research has to be conducted to get more accurate results because there was only one developer studied and the results only show results from that developer. More studies of developers’ work have to be made to get a general overview of how time resources are spent by an individual developer. These studies should then include complete projects.

(4)

(5)

Sammanfattning

Resurshantering är viktigt för att mjukvaru projekt ska lyckas. Tid är en av dessa resurser som måste hanteras. För att göra detta behöver man veta hur tids resurserna går åt. I skrivande stund finns det knappast något publicerat material om hur tids resurser spenderas.

I detta examensarbete genomfördes en undersökning om hur tids resurser spenderas som en individuell utvecklare i ett mjukvaru projekt. Syftet med denna information var att få en bättre förståelse för hur mycket och var tids resurser går åt och förbättra det egna sättet att arbeta för att bli en bättre ingenjör. Dock var målet med undersökningen att tillhandhålla en bas för relevanta modeler som handskas med tidsplanering.

Undersöknings metoden som tillämpades var en “action research” där författaren av detta examensarbete var den som studerades. Undersökningen var av kvantativ typ och hade ett induktivt resonemang. Data samlades in med hjälp av “action research” och litteratur studier. Datat utvärderades med hjälp av en utvärder- ings model. Utvärderingens modelen innehöll följande utvärderings kriterier: (1) summan av spenderad tid på varje individuell aktivitet inom projektets omfång, (2) fördelning av tid mellan olika aktivitet typer på en iteration basis, (3) skillnader av spenderad tid på olika aktiviteter i olika iterationer, och (4) täckning av utvecklar aktiviteter i SGD ramverket.

Resultatet visar hur mycket och var tids resurserna spenderades för den utvecklaren som studerades under projektets gång. Det behövs dock mer forskning för att resultaten ska bli mer exakta eftersom det var bara en utvecklare som studerades och resultaten visar bara resultat från den utvecklaren. Mer arbeten från utvecklare behöver studeras för att få en mer generell överblick hur tids resurer spenderas av en individuell utvecklare. Dessa arbeten bör vara hela projekt.

(6)

(7)

Acknowledgments

I would like to thank Maybe Meetings for letting me perform my bachelor thesis at their company. Thanks to them I have gotten some great experience of working with a professional software project. Special thanks to Simon Persson for assisting me during my time at Maybe Meetings. I would also like thank my supervisor Mira Miroslawa Kajko Mattson for guiding me through the writing process of the thesis.

Finally, I would like to thank my girlfriend for motivating and pushing me to do my best. Also for bearing with me through these busy years studying at KTH.

(8)

(9)

1 Introduction

Time resources are always limited in both software projects and projects in general [2]. Managing time correctly is critical to be successful in the software industry.

Spending the wrong amount of time on something can be devastating, projects can be delayed or even canceled. As Ian Sommerville says in his book, one of the most important goals in most projects is to deliver the software to the customer at the agreed upon time cost [1, p. 594]. However to do it, requires that one knows how much time is spent on different activities.

Time is one of the most important resources to consider in resource management.

It can often be a plastic resource meaning that the supply of the resource cannot be extended contrary to an elastic resources that can be increased or decreased, like human resources or money [2]. To manage your time resources you have to know where, when and on what they are spent. Time can be spent on many things in a software project, for example requirements, design, coding, testing and doc- umentation [3]. To find out how much and where time is spent you must track time spent for each individual activity. Usually different roles are involved in these activities [4], for example the developer role considered in this thesis.

The potential benefits with finding out how much and where time resources are spent by an individual developer, would be that project managers can get a better view of how much time resources are generally spent and the distribution between activities. This can improve their resource management. It will also help software developers improve their own way of working knowing how much time usually will be spent on different activities.

There are material on resource management for both software projects and projects in general [5]. It is highly relevant to publish material on time resources spent because of all the software projects that exists today that could benefit of this kind of material. Knowing how much and where time resources are spent is useful for the persons managing project resources and also for each individual software developer.

1.1 Problem

The problem today is lack of published material on how much and where time resources are spent by an individual developer in a software project. It is possible to gather information on time resources within individual companies and many companies does that. This information is however not often shared with the outside

(12)

world. It is only available within the company. It would be valuable to get a more general overview of how much and where time resources are spent in software projects. The value of this is that companies or persons can use this information to better manage their time resources [6]. It would be most helpful for those that do not already know how much and where their time resources are spent, to see a general overview of how time resources often are spent. For those that do know, it could still be helpful to get a general overview.

1.2 Research Question

In this thesis, the time resources spent by an individual developer in a software project part was researched with the following research question in mind:

• How much time resources are spent by an individual developer in a software project part and how are these resources distributed?

This research question will guide the research towards the goal of the project.

1.3 Purpose

The purpose of the research was to find out how time resources are spent by an individual developer in a software project part. The thesis contains valuable information about how much and where time resources are spent, also discussing the available models to achieve this. The tool used during the research for gathering time resources was the Self-Governance Developer framework. The information gathered should be used to discipline developers and improve their own way of working.

1.4 Goals

The goal of the research was to provide a basis for relevant models like process models, measurement models and SPI models which include or are based on time management. With this basis it should be possible to build or improve these relevant models in order to better manage developers time resources in software projects.

1.5 Commissioned Work

The subject of study was hired by the company Maybe Meetings AB as a backend engineer for their mobile application. The assignment was to work on their server functionality. The tasks included both adding functionality and improving the

(13)

Figure 1: The timeline of the project.

1.6 Scope and Limitations

The research was conducted at a company developing an mobile application for the iOS platform. This software project have a team of six members that all work with their part of the project. The focus of the research was on the developer role in a software project.

The research was limited to only one developer within a part of a limited project.

The developer had no previous experience in the software engineering industry which should be considered in the results. The software project was already about 75% finished when the research started. The software project began in January and the research started in the end of Mars. At the end of the May was the research finished but the software project was still ongoing. As illustrated in Figure 1, the research will just take into account part of a software project. There was no further involvement in the software project and by July the seventh was it finished.

1.7 Research Method

The research method applied was action research, the structure of the action research process [10] was followed where the author of this thesis was the subject of study. The research was of quantitative type, meaning that numerical data were collected and analyzed using mathematically based methods [8]. In this case it was time spent on activities in a software project that were collected and later analyzed. The research had an inductive reasoning, starting with observations and ending with theories. Data collection was conducted via action research and literature study. The subject of study was selected with the convenience sampling method. Data evaluation was conducted via an evaluation model including four evaluation criteria.

(14)

1.8 Ethics

During the research was confidential information obtained from the company where the research was conducted. This information was not shared with the outside world, only within the company. The thesis does not specify exactly what work has been done but instead describe the work in form of SGD activities, explained in Chapter 4.

1.9 Sustainability

The research will consider the sustainability problem with the three pillars of sustainability [12]:

• Social sustainability

• Environmental sustainability

• Economic sustainability

The problem today is the big focus on economic sustainability when it is more important that we care for our planet and an environmental sustainability. Creating a good economic sustainability could possible move the focus to the other pillars.

From an economic viewpoint, knowing how time resources are spent can save money and improve the economy of a company. Unnecessary time resources spent can be avoided and spent on better activities. A company with a good economy can focus more on environmental sustainability and also on social factors like social well being.

1.10 Social Benefits

A social benefit of knowing how time resources are spent is the increased productivity for software companies. The increased productivity comes from making the developers more efficient with their time resources which makes it possible to be more productive. Increased productivity can improve the standard of living from both a commercial and consumer perspective [13]. It is possible to decrease the prize of the developed products, making the consumers wealthier and business more profitable.

1.11 Target Group

This thesis has two main target groups. These are the industry and academia.

(15)

management and self-discipline. Regarding the academia, the conducted research about how time resources are spent as an individual developer can be of use for relevant researches about time management, measurement models, process models and SPI models. The fact that there are no published material on this matter makes it possible for this thesis to provide a basis for further research in the area.

1.12 Thesis Outline

The thesis consists of the following chapters:

Chapter 2: Research Methodology: This chapter provides a description of the research methodology. Covering the research methods applied, research phases, sampling methods and research instruments.

Chapter 3: Extended Background : This chapter covers the necessary theories to understand the research.

Chapter 4: The Self-Governance Developer Framework : This chapter describes the framework used in the research to keep track on time resources spent.

Chapter 5: Presentation of the Research Results: This chapter presents the research results.

Chapter 6: Analysis and Discussion: This chapter analyzes and discusses the presented results from the research.

Chapter 7: Conclusions and Future Work : This chapter provides conclusions and discuss future work.

(16)

(17)

2 Research Methodology

This chapter presents the research methodology. First there are an overview of the research strategy. Then a description and motivation of the research type, followed by a presentation of the phases conducted during the research. There are also a description of the sampling method and research instruments used during the research. The last section presents the evaluation criteria as a part of the evaluation model.

2.1 Research Strategy

An appropriated research strategy had to be made to find out how much and where time resources are spent by an individual developer in a software project. Due to the time limit of the thesis is it very important to have a proper research strategy to be as effective as possible.

The research strategy is illustrated in Figure 2. It includes the following com- ponents: (1) Research Methods, (2) Research Phases, (3) Research Instruments and (4) Sampling Methods. The research was of quantitative type with inductive reasoning. An action research was conducted with three main phases: (1) a literature study phase, (2) a research phase, and (3) an evaluation phase. The research instruments used were the SGD framework, Scrum and time. The sampling method was of non-probability type, the convenience sampling method.

2.2 Research Type

The research type can be described with the following three key words: (1) action research, (2) quantitative research and (3) inductive reasoning. More about these in the next sections.

2.2.1 Action Research

The research method applied was an action research where the author of this thesis was the subject of study. The steps included in the action research process are the following [10]:

• Selecting a focus

• Clarifying theories

• Identifying research questions

(18)

Figure 2: Overview of the research strategy.

• Collecting data

• Analyzing data

• Reporting results

• Taking informed action

Following the action research process provides a good guideline for the workflow.

Due to the iterative nature of action research was the collecting and analyzing data steps done in several iterations, with a total of seven iterations. More iterations means more responsiveness. The larger data amount, the better the result.

Traditional research could have been an alternative but because the research question arose from the supervisor of this thesis was it more relevant with an action research [11]. It was a research question based on the needs of the supervisor for continual improvement in her own work.

(19)

2.2.2 Quantitative Research

The research type was chosen naturally due to the fact that numerical data (time) had to be collected and analyzed to fulfill the goal and purpose of the research.

This type of research is called quantitative research [8]. The alternative would be a qualitative research, but due to the more textual nature of such a method was it not suitable [9]. The research was about numerical data and statistics, therefore should the research be of quantitative type. Being of a quantitative type, the research could be described as a systematic empirical investigation of an observable phenomena via statistical techniques. The aim of the research was to get a better understanding of how time resources are spent by an individual developer in a software project. Data collection was conducted via action research and literature study. The collected data was analyzed to get this better understanding and to come up with a theory about how time resources are spent.

2.2.3 Inductive Reasoning

The research had a bottom up approach or in another word inductive reasoning.

This means that the research started with observations and ended with more general conclusions and theories [18]. The alternative would be deductive reasoning which means that the research have a top-down approach instead. Then the research would have started with theories and ended with more specific observations to confirm the theories [18]. A deductive reasoning would not fit the need of the research because observations had to be conducted first to in the end get some general conclusions and theories about how time resources are spent by an individual developer in a software project. An image showing the differences of inductive versus deductive reasoning is shown in Figure 3.

2.3 Research Phases

The research had the following phases, a literature study phase followed by a research phase and concluded with a evaluation phase, as shown in Figure 4. The action research steps mentioned before were included during these phases.

2.3.1 The Literature Study Phase

The literature study phase included the three first steps of the action research process: (1) selecting a focus, (2) clarifying theories, and (3) identifying research questions.

The research started by selecting a focus for the research. After considering different approaches for the research was it decided that the research would be about

(20)

Figure 3: Inductive vs Deductive reasoning.

how time resources are spent in software projects. To get a better understanding of the subject some literature studies were conducted, including reading about software development, time resources, resource management, the SGD Framework and Scrum.

Reading studies about time resources and resource management was to understand the problem considered by the research. It is important to be well informed when writing a thesis of this kind. Much information was gathered from the web and books.

The SGD Framework was studied thoroughly to get a better understanding of the framework before starting to use it. It is important that the framework is well understood for the research to be as successful as possible. A paper about the framework were read to get the necessary knowledge [7].

The agile software development framework Scrum was also studied because the company follows their own variant of Scrum. The purpose of studying Scrum was to get a good start when working with the company and their way of working.

(21)

Figure 4: Overview of the research phases.

(22)

Figure 5: Overview of the work flow with seven iterations 2.3.2 The Research Phase

This section provides an overview of the research phase consisting of three activities: (1) collecting data, (2) compiling weekly results and (3) analyze weekly results.

This phase covered the following steps of the action research process: (1) collecting data and (2) analyzing data.

To collect data, work had to be conducted at the company. An assignment was given and then it was implemented and tested with the SGD framework. After delivery was a new assignment given and so on. It was a iterative work flow, as shown in Figure 5. Seven iterations was conducted before the end of the research.

On a daily basis notes were taken to keep track of the activities conducted and time consumed on them. The tool used for this was the software program Toggl, using this tool is it possible to keep track of what has been done and how long time it took [17]. At the end of the work day, the data collected were translated into SGD activities and the time consumed were inserted into a time report sheet, see Figure 6. This time report sheet have one row for each of the SGD activities.

There is also a column for each day of the week. For every week there is a sheet like this.

(23)

Figure 6: Part of the time report used for collecting data.

(24)

Every week all results gathered that week were compiled into a self-assessment document, see Appendix A. In this document there are a table for every week with the time spent for each of the activity categories. There are also a result section with a short overview of what has been done during the week.

In the self-assessment document, see Appendix A, there are an analysis of each of the weeks results. The analysis includes what went well and bad, mistakes and improvements. The mistakes section consider both individual mistakes, team mistakes and mistakes by the leader. The improvements section provides content for all parts mentioned before.

2.3.3 The Evaluation Phase

The evaluation phase consisted of two activities: (1) compiling the results on the whole project, and (2) analysis of the whole project results. This phase included the following steps in the action research process: (1) analyzing data, (2) reporting results, and (3) taking informed action.

At the end of the research phase, all data collected were in sheets as mentioned before. By using mathematical methods was the data compiled into the final results. It went from several sheets for each week to one big sheet with results for the entire project. Diagrams were also created to get a better picture of the results.

The final results for the entire project was later analyzed to answer the research question and discuss what has been learned.

2.4 Sampling Methods

The sampling method used in the research was of non-probability type, a convenience sampling [19]. This is because the author of this thesis was the subject of study and it is of availability reasons that this is the case. It would be better with a sampling method of probability type. If there was access to several developers, they could have been randomly chosen to participate in the study in order to make the results as accurate as possible.

2.5 Research Instruments

The research instruments used during the research are the following: (1) Scrum, (2) the SGD framework and (3) time measured in hours. Scrum was an essential instrument because it was the method used at the company to manage the project work. It was used as a guideline to work as effective as possible and to complete the project before the deadline.

(25)

The SGD framework was the main instrument during the study. It was used to keep track of conducted activities and the time spent on them, as mentioned before. Without the framework it would be necessary to create own activities and categories similar to the SGD activities described in Chapter 4. Luckily, the framework provided this kind of material and made the research easier to conduct.

Time was the most important instrument in the research because that is what was measured and managed. The entire thesis is about time so it was definitely an important instrument during the research.

2.6 Evaluation Criteria

The evaluation criteria was used to evaluate the project work and are part of the evaluation model. The evaluation criteria for this project are the following:

• Evaluation Criteria 1: Sum of time spent on each individual activity within the scope of the project. The total time spent for each of the activities should be compiled and then analyzed to find out how much time is spent on each activity.

• Evaluation Criteria 2: Distribution of the time across activity types on an iteration basis. This means that the time spent for each activity category should be compiled for each week. The results should be analyzed to see how much time is spent on each category for each week.

• Evaluation Criteria 3: Differences of time spent on various activities in various iterations. The meaning of this is that at the end of the project should the time spent for each activity each week be complied into a diagram.

The results should be analyzed to find out if the activities were similarly distributed at the beginning as at the end of the project or if there was any observed differences.

• Evaluation Criteria 4: Coverage of developer activities in the SGD Frame- work. This means that at the end of the project should it be checked if there was any activities conducted that is not included in the SGD framework.

2.7 Experience Gained

Many things has been learned during the process of conducting and writing this thesis. The most valuable experience gained is how the daily work of an developer looks like in a professional project. This kind of experience makes you more ready

(26)

for the next step in life when starting to work for a company as a developer.

Another experience gained is the hard work that has to be done when writing a thesis like this and it really helps having someone guiding you through the process.

(27)

3 Extended Background

This chapter consists of background information starting with basic theories about software development and agile methods. Then are time resources, time measurement, and time management theories explained. The chapter ends with a section about feedback to the work.

3.1 Software Development

Software development can be divided into two main categories: (1) "Traditional"

methodologies and (2) Agile methods. This thesis will only focus on agile methods that was used during the research. An overview of process activities during software development is described in the next section.

3.1.1 Process Activities

The process activities during software development can vary a bit between methodologies but it is essentially the same. The common activities involved in the process of software development are the following [1, pp. 36-43]:

• Software specification - This is the activity where the requirements are set, often resulting in a requirements document that all parts have agreed upon.

The requirements are often divided into two levels, a high-level statement for the costumers and end-users, and a low-level system specification with more details for the developers. In a agile method is the requirements specification often redefined in each iteration.

• Software design and implementation - This activity is about converting the system specification into an executable system. Every aspect of the system should first be designed and then translated into code.

• Software validation - The activity where you check if the system meets up to the requirements and costumer expectations. This can be done with program testing but also with checking processes, such as inspections and reviews.

• Software evolution - This activity includes maintenance and further development as requirements and costumer needs change. Software engineering is an evolutionary process where software changes over time.

3.1.2 Agile Methods

One of the main ideas of agile methods is to have incremental development and delivery [1, p. 59]. This means that the work is divided into iterations with their

(28)

own set of goals. The agile methods share some basic principles described below [1, p. 60].

• Customer involvement - Costumers should be involved in the development process, give requirements and evaluate the work for each iteration.

• Incremental delivery - The software should be developed in iterations where the costumer decides what the requirements are for each iteration.

• People not process - The members of the team should be seen and heard.

The skills of each individual should be utilized. Everyone should also be able to develop their own ways of working.

• Embrace change - Be ready for changes in the system, design the system to be able to handle these changes.

• Maintain simplicity - Do not make the software or development process to complicated. Keep it as simple as possible.

There are many agile methods but one of the most popular is Scrum. It is a general agile method where the focus is on managing iterative development instead of more technical approaches [1, p. 72]. The key concept of Scrum is the sprint cycles [1, p. 73]. A sprint cycle is a phase where planning, development and delivery takes place in a iterative fashion. The key characteristics of a sprint is the following [1, p. 73]:

• Sprints have a fixed length of normally 2-4 weeks.

• The product backlog is the starting point for each sprint. It is a list of work that has to be done. This list have to be reviewed in order to prioritize and calculate risks. This is called the assessment phase. The costumer should be involved in this phase to set the requirements for the sprint.

• The next step is the selection phase to select what should be developed during the sprint.

• The work is divided between the team members. On daily basis there are short meetings to track progress. The team is separated from the costumer and stakeholders when it is decided what should be done. This is because the team should be able to work without distraction. The "Scrum master"

takes care of all communication outside the team.

• At the end of the sprint, the work that has been done is reviewed and presented to the stakeholders.

(29)

3.2 Introduction to Resources

Resources are always limited and you cannot do without them. It is a constant struggle for resource managers to manage the resources in the most efficient way to complete the project as fast as possible. There are four main resources that should be considered during software development [2]:

• Human resources - The employees of a company.

• Computer resources - The available computer hardware, software, documen- tation, supplies and support services.

• Financial resources - The available amount of money a company can spend.

• Time - The available amount of time a company can spend.

Resources can be viewed from four standpoints [2]:

• Availability - There are resources that does not become less available when used as human resources. Then there are resources that get less available the more they are used as time and money.

• Place of availability - Immovable resources that cannot be moved, such as computer resources in some cases and movable resources that can be moved like money and human resources.

• Elasticity - Elastic resources that can be increased and decreased, such as human resources and money. Plastic resources cannot be extended like time.

• Shared and dedicated - A shared resource are needed just for certain times during a project, for example database administrators. A dedicated resource is used during the entire project, such as programmers.

3.3 Time Resources

Time is the most important resource in a project [14]. The importance of time resources can be described with the following quote: "time is the scarcest resource, and unless it is managed, nothing else can be managed.", as Peter F. Drucker writes in his book The Essential Drucker: The Best of Sixty Years of Peter Drucker’s Essential Writings on Management (Collins Business Essentials) [15]. The meaning of this is that time is limited and can not be extended, it is not possible to create more time. You have to work with what you got and make the most of it. Every project has to spend time resources to achieve its goal. The important part is to manage it well or everything will collapse. In a software project is time as important as in any other project. There are deadlines that most be met. Time has to be managed efficiently in order to deliver at agreed upon time.

(30)

3.4 Time Measurement

Time can be measured in seconds, minutes, hours, weeks, month, etc. It can also be measured in man-hours, man-weeks, man-months and so on. To be efficient at time management you need to know how much and where your time is spent.

Without knowing how your time is spent you can not see where the problem lies and managing your time will be really hard. It is in fact fairly easy to keep a log of conducted work and time spent on it. All you need is a timer and some tool to take notes of what has been done. This log can later on be analyzed every week, month or whatever is best suitable to find out where you need to improve.

There are many tools and software to keep track of time spent on activities. First of is the classic paper and pen with a timer of some sort. This is very efficient and accessible, no need to have any devices around. The more modern choice is some kind of software tool. There are many to choose from by just doing a Google search. The one used in this research was Toggl [17].

3.5 Time Management

Some general rules for efficient time management [16] is to have clear goals, create smaller steps for achieving the goals, and review your progress to find out where to improve. It is also important to prioritize and organize your work. Making lists with what to do when and in which order is one simple way to achieve this. There are several other ways to manage your time resources.

When managing time you have to estimate where the resources will be spent.

If you have tracked your time is it possible to use that information in order to predict where the resources will go. The PROBE method [20] suggests that first should the total time for the job be estimated and then using historical data estimate the time for each of the phases during development. The phases to consider are planning, design, design review, code, code review, compile, unit test, and post work phases.

The reason for managing your time is to be more efficient at the work you do.

Time is a limited resource as mentioned before, that makes it very important to be as efficient as possible with the time you got. Managing time efficiently means more work done in less time.

A new framework to manage developers individual work is soon to be published.

It is called the Self-Governance Developer Framework. It can be used to track time of specified activities conducted as a developer, more about it in Chapter 4.

(31)

3.6 Feedback to the Work

The theory covered in previous chapter is to get a basic knowledge of the area in order to understand the research. The research is connected with the theory in the following way. Software development processes and agile methods was used during the research at the company. It was a software project using the agile method Scrum to manage the project. To understand how software development works some theory is needed.

Time resources, time measurement and time management are key concepts for the research and therefore included as theory. Without the knowledge of the concepts is it hard to understand what the research is about.

(32)

(33)

4 The Self-Governance Developer Framework

The following chapter gives a description of the framework used in the research to manage time resources. It starts with an overview of the framework, followed by the SGD process model with the included SGD activities used in the research. This chapter is needed to understand the framework used during the entire research, how it was used is described in Chapter 4.

4.1 The SGD Framework Overview

The Self-Governance Developer Framework can be used by software developers to assist them in their daily work by self-managing, monitoring and controlling their own assignments. The SGD framework is divided into two parts, the SGD process model and my SGD process. The first includes the SGD process categories and activities. My SGD process consists of the developers own activity spaces with zero to many activities [7]. An image illustrating the framework can be seen in Figure 7.

Figure 7: The SGD Framework.

(34)

4.2 The SGD Process Model

There are three main SGD process parts included in the SGD process model, (1) pre-work, (2) work, and (3) post-work. For each of these process parts there are several activity categories with associated activities. It is not necessary to use all of the activities or perform them in any specific order [7]. The SGD activities were used in the research because it provided all types of developer activities during software projects. This was useful for the research when tracking time resources spent. It also made it easier to distinct what actually had been done.

The next sections gives a short description of the SGD categories and activities.

The purpose of this is to give a better understanding of what type of activities where considered during the research.

4.2.1 The Pre-Work Activities

The pre-work activities consists of the activities that usually happen before the work activities. There are preliminary and planning activities as seen in Figure 8 [7].

Preliminary Activities

The preliminary activities consists of activities to understand methodologies, tech- nologies, standards, ways of working and commitments [7]. They are usually conducted before starting implementation and testing work. The reason for that is because they provide developers with the resources needed to perform high quality work. It is important to understand the project plan before getting to work (see activity PR-1 in Figure 8) to avoid problems later. Revising and ensuring that the technology is understood will save time later on (see activity PR-2 in Figure 8). Understanding organizational standards and ways of working makes it easier to start working in a correct way (see activities PR-3, PR-4 in Figure 8). It is also important to check your own way of working to match with the organizational way of working (see activity PR-5 in Figure 8).

Planning Activities

The planning activities includes activities for reviewing the necessary documents, determining ways of conducting the work, and planning the work [7]. Developers should review the necessary documents to understand the scope of their work. The documents to read are requirements and design specifications (see activities PL-1, PL-2 in Figure 8). While reviewing the documents or in any other activity where questions or uncertainties appear should they be resolved to avoid any misun- derstanding and/or confusion (see activity PL-3 in Figure 8). Understanding the

(35)

Figure 8: Pre-Work Activities.

requirements and design specifications aids developers determine implementation and testing goals, strategies and practices that will guide them in their planning (see activities PL-4 - PL-6 in Figure 8). Planning the work is very important to preform as good as possible and avoid problems in the work phase. Their are a lot of planning that can be done to achieve this (see activities PL-7 - PL-13) in Figure 8.

4.2.2 The Work Activities

The work activities consists of activities to prepare for coding and testing, actual coding, testing the code, evaluate the tests and debug the code [7]. These activities are conducted after the pre-work activities.

(36)

Figure 9: Work Activities.

(37)

Preparatory Activities

The preparatory activities includes activities to prepare for the implementation work by looking at low-level designs, test case designs, stubs and drivers, and testing environment [7]. The activities will help developers to become ready for writing and testing code. Preparing and reviewing low-level designs helps developers to create the best possible solution for the task at hand (see activities P-1, P-2 in Figure 9). The test case design should be determined, created and revised to be prepared for testing (see activities P-3 - P-5 in Figure 9). The testing environment should also be prepared and checked if it is appropriate for the work to be conducted, to avoid problems later on (see activity P-7 in Figure 9).

Coding Activities

The coding activities includes writing/rewriting code and compiling it [7]. The code should be based on the low-levels designs to minimize the risk of not meeting the given requirements. There are also activities for recording compilation errors and detected defects to help developers monitor their work, evaluate the quality of the code and help them learn from their own mistakes (see activities C-1 - C-4 in Figure 9).

Testing Activities

The testing activities includes the testing activities themselves and control of the test cases [7]. There are dynamic and static testing and test results recording included in the testing activities (see activities T-4 - T-6 in Figure 9). Controlling the test cases means checking if the code meet the given requirements and/or designs. It also involves checking the test cases for problems that have been noticed after coding (see activities T-1 - T-3 in Figure 9).

Evaluative Activities

The evaluative activities includes analyzing the testing results and determining the next step (see activities E-1, E-2 in Figure 9). The activities should be conducted directly after testing to make sure they have a good workflow [7].

Debugging Activities

The debugging activities includes identifying the source of errors and determining solutions to solve the errors (see activities D-1, D-2 in Figure 9). It is important to debug for the errors and identify the source to prevent similar errors to occur again [7].

(38)

Figure 10: Post-Work Activities.

4.2.3 The Post-Work Activities

The post-work activities include activities that are conducted after the work activities has been done which includes self-assessment and delivery (see activities in Figure 10). Developers should make a self-assessment of their work in order to improve as a developer and reflect upon what has been done. They should include both mistakes and improvements to avoid similar mistakes. This will help them become more effective and efficient [7].

(39)

5 Presentation of the Research Results

To get a better perspective of the results will a brief overview be presented of what had been done in the software project before the research started. When the research started there was an iOS application and a server with some of the desired functionality. The work that was conducted during the research was on the server. Almost all basic functionality was already there so it was mostly about adding the missing functionality and improving the work that had already been done.

The research consisted of seven iterations, all a week long. During these iterations was there three main assignments that was conducted. The first one was to update deprecated code on the server. The second one was to develop support for notifications on the server. The last one was never finished but it was about adding some Instagram API features to the server. The software project was still ongoing when the research was over.

The presentation of the research results will follow the evaluation model described in Section 2.6. A note to consider is that some activities that were left blank either was not conducted at all or a very small amount of time was spent on them so it did not felt necessary to include it during the daily time reports.

5.1 Sum of Time Spent on Each Individual Activity Within the Scope of the Project

In this section is the sum of time spent on each individual activity within the scope of the project presented. The first evaluation criteria results can be seen in Figure 11 showing the sum of time spent on each individual activity. As can be seen, the time spent on each individual activity are very spread out. Some activities required no time resources while others required much. Writing code was the activity that most time resources was spent on, with 58,75 hours spent of the total 158,5 hours for the entire project. That is about 37% of the total time spent on coding.

In the preliminary activities were most time spent on revising and ensuring that the technology used was tested and understood. Resolving unclear questions and uncertainties was the planning activity most time was spent on. The preparatory activity that most time was spent on was preparing and reviewing the low-level designs of the code that was written or changed. Looking at unit testing activities the time was most spent on performing dynamic testing by executing code. Most

(40)

evaluation work was on analyzing unit testing results. Identifying the source of errors was the debugging activity most time was spent on. During self-assessment most time was spent on assessing the development work.

5.2 Distribution of the Time Across Activity Types on an Iteration Basis

In this section is the distribution of the time across activity types on an iteration basis presented. The results for the second evaluation criteria can be seen in Ap- pendix A. There are the time spent for each activity category every week. The first week most time was spent on preliminary and planning activities. The activities that was not conducted were preparatory, testing, evaluative, self-assessment and delivery activities. The second week most time was spent on coding and debugging.

The activities that were not conducted were preparatory and delivery activities.

The third week most time was spent on planning and coding. The activities that was not conducted were preliminary and delivery activities. The fourth week most time was spent on coding and the activities that was not conducted were preliminary and evaluative activities. The fifth week most time was spent on coding and the activities that was not conducted were preliminary, evaluative and debugging activities. The sixth week most time was spent on coding and the activities that was not conducted were preliminary activities. The seventh week most time spent on coding and the activities that was not conducted were preliminary, preparatory and evaluative activities.

5.3 Differences of Time Spent on Various Activities in Var- ious Iterations

In this section is the differences of time spent on various activities in various iterations presented. The results for the third evaluation criteria can be found in Appendix B. There are diagrams for each activity category with all associated activities. The diagram shows the differences of time spent on various activities in various iterations. As can be seen in Figure 12 the preliminary activities only occurred during the first two weeks. Where the activities (PR-1) reviewing and agreeing on the overall project plan, (PR-4) learning the organizational implementation and unit testing way of working, and (PR-5) reviewing and revising my personal implementation and testing way of working, only was conducted the first week. The activity (PR-2) revising and ensuring that the technology that was used was tested and understood, was conducted both two weeks.

The planning activities in Figure 13 have some spikes at week 3 and week 5 where

(41)

Figure 11: Sum of time spent on each individual activity within the scope of the project

(42)

there was a higher rate of planning done. As can be seen some planning have occurred every week.

The preparatory activities in Figure 14 starts to be conducted at the third week.

There can we see that (P-1) preparing and reviewing the low-level designs of the code, was conducted more and more until the fifth week where it peeks then the sixth week less time was spent and then no time was spent the seventh week. The activity (P-4) creating and revising my unit test case base, was conducted a small amount of time on week 3 and 6.

The coding activities in Figure 15 had only one conducted activity. The activity (C-1) writing code, was conducted every week and it was more and more time spent on coding until the peek at week 5.

The unit testing activities in Figure 16 was not conducted the first week. The activity (T-4) performing dynamic testing by executing code, was most time spent on in week 7, during week 2 and 4 some time was also spent on the activity. Week 6 was the only week when some time was spent on the activity (T-5) performing static testing by reviewing your code. The activity (T-1) checking whether the unit test case base meets the given requirements and design, was some time spent on during week 3, 4 and 6 but not during week 2, 5 and 7.

The evaluative activities in Figure 17 was mostly conducted during week 2 and a small amount of time in week 6. The activity (E-1) analyzing the unit testing results, was also conducted some minutes in week 3. The activities was not conducted at all during week 1, 4, 5 and 7.

The debugging activities in Figure 18 had some spikes at week 2, 4 and 7. The activity (D-1) identifying the source of errors, had almost equally time spent during week 2, 4 and 7. During week 3 and 6 was there almost no time spent on the activity and on week 5 there was no time at all spent. The activity (D-2) determining solutions for eliminating the sources of errors, had most time spent on it in week 2 and then it was not much time spent on it again until week 7.

The self-assessment activities in Figure 19 was conducted all week except the first one. During week 2 and 4 were more self-assessment done. The activities (A-2) and (A-3) had equally time spent each week.

The delivery activity in Figure 20 was not conducted until week 4 where most of the time was spent the activity. During week 5-7 the same amount of time was

(43)

spent each week on the activity.

5.4 Coverage of Developer Activities in the SGD Frame- work

In this section is the coverage of developer activities in the SGD framework presented. The result for the fourth evaluation criteria can be found in Figure 11 showing the sum of time for all activities. Twenty of the activities were not conducted but there was not a single activity conducted that was not included in the SGD framework.

The following activities were not conducted:

1. Revise and understand any appropriate internal (organizational) and exter- nal standard(s).

2. Determine and document your implementation and unit (developer) testing goals.

3. Identify standards to be used for meeting your goals.

4. Set your own personal deadlines to be met during your implementation and unit (developer) testing work.

5. Estimate effort and resources required for carrying out your work.

6. Schedule your work.

7. Review your implementation and unit (developer) testing plan to ensure that it is realistic and achievable.

8. Identify risks related to your plan.

9. Plan for managing any identified risks.

10. Prepare (make) an impact analysis of your low-level design(s).

11. Determine the types of unit (developer) test cases and their order.

12. Revise the existing unit (developer) regression test base, if relevant.

13. Create or modify stubs and drivers, if required.

14. Prepare your unit (developer) testing environment and check whether it is appropriate for you work.

(44)

15. Compile/ recompile your code as required.

16. Make notes on your compilation errors, if necessary.

17. Make notes on your defects.

18. Check whether the unit (developer) regression test base meets the given requirements and design.

19. Remedy requirements problems in your unit (developer) regression and/or test cases base, if any.

20. Record/write down test results.

(45)

6 Analysis and Discussion

In this chapter are the results of the research analyzed and discussed. The results are analyzed according to the evaluation criteria. Improvements are discussed and also validity threats. One week is equal to one iteration as mentioned in previous chapter.

6.1 Analysis of Sum of Time Spent on Each Individual Ac- tivity Within the Scope of the Project

An analysis of the results for the sum of time spent on each individual activity within the scope of the project was conducted. Coding was the activity that most time was spent on which was expected. As a software developer there will be much coding which can be seen in the results. However it was not expected that 37%

of the total time spent would be on coding. The reason for this was that I was inexperienced of writing professional code. The code had to be rewritten many times to reach the code quality required by the company. That consumed much time resources. There was also much time spent on resolving unclear questions and uncertainties. As an junior software developer is it hard to always understand what to do and how to do it. That is why much time resources was spent on that activity. The activity preparing and reviewing the low-level designs of the code to be written or changed was conducted many times which is connected with amount of time spent on coding. I had to look at the low-level design many times while coding to know what to do. Identifying the source of errors also took much time, which was kind of expected due to the fact of my inexperience of working with big software projects.

6.2 Analysis of Distribution of the Time Across Activity Types on an Iteration Basis

An analysis of the results for the distribution of the time across activity types on an iteration basis was conducted. It was expected that the first week would involve many preliminary and planning activities. The second week had also expected results with more work activities. The absence of preparatory activities the first two weeks is because I just started coding without doing any preparatory activities and then later learned from my mistake and started doing them. At the fourth week was the first delivery and that is because I had no code to deliver until that.

The first four weeks was like training weeks. After that I started to deliver at a daily basis to get better feedback on my work. The evaluative activities were not conducted every week because there was not much testing results that could be

(46)

evaluated. Most of the tests were just to see if it worked or not. There was not much to analyze, therefore the lack of evaluative activities. The last week was the week with most testing, that is why I had to deliver everything that I had done and test it first to make sure it works and if not mention that before delivering.

6.3 Analysis of Differences of Time Spent on Various Activ- ities in Various Iterations

An analysis of the results for the differences of time spent on various activities in various iterations was conducted. Only differences that stood out and have not been mentioned before were included in the analysis. During week 3 and 5 was more planning conducted which was because of the start of new assignments, then more planning had to be done to understand what to do. The reason for that the activity (P-1) preparing and reviewing the low-level designs of the code, was conducted more and more was because the there was also more coding every week until week 5 where both the activities had most time spent on them. When coding I had to look at the low-level design many times to know what to do. The activity (T-4) performing dynamic testing by executing code, was conducted many times the last week because of mentioned reason before, everything had to be tested before delivery.

6.4 Analysis of Coverage of Developer Activities in the SGD Framework

An analysis of the results for the coverage of developer activities in the SGD framework was conducted. The reason for twenty activities being left out is that everyone works in their own way and I did not conduct most of these activities during the part of the software project that I was there. Some of the activities were conducted but the time spent on them was not included in the daily reports due to the very small amount of time spent. One example is compiling my code, I did that but it took only seconds every time so it did not felt necessary to include it. It is good that the SGD framework included all conducted activities but it is hard to tell if that will always be the case due to the scope of the research.

6.5 Discussion and Improvements

The distribution of my work was far from perfect. I could have distributed my work in a better way by following the SGD framework more strictly. There was activities that I did not conduct that possibly could have improved my own way of working. For example was it many SGD planning activities I did not conduct,

(47)

one of them was scheduling my work and I think that could have helped my work being more structured. I think that with a better plan of what to do everyday will more work be done because less time will be spent on thinking about what task to do next.

The biggest problem during my time working for the company was the communication with the other developers because they worked mostly remote, meaning that they was working from home or somewhere else, not at the office where I mostly sat. To communicate with them I had to chat with them which worked fine but it could be better. Some problems would be easier to talk about in person.

To solve this I started to join their weekly evening meetings that all team members attended. I then had a chance to talk with them in person and discuss my questions and uncertainties. This improved my own of way of working very much.

I solved my problems quicker and delivered more frequently. One improvement I suggest is that you should meet your team members as much as possible to keep a solid communication between each other. The best would be if the team was always seated together as strongly advised by Henrik Kniberg [21, p.57]. He writes that everybody should be able to talk to each other without shouting or leaving the desk and everybody should be able to see each other.

The SGD framework proved to be a good framework for this kind of research. It provided everything that was needed to manage my time spent during the project.

I have no improvements to suggest regarding the SGD framework.

6.6 Validity Threats

The four validity threats considered are credibility, transferability, dependability, and confirmability. The meaning of the credibility criteria is that the research results are credible or believable. The transferability criteria means that the research results can be generalized or transferred to other contexts or settings. The dependability criteria means that the research describes how changes affected the study. The confirmability criteria means that the research results could be con- firmed by others. The scope of the research is a credibility threat because the research only focuses on a single developer within just a small part of a software project. The result would be more valid if the research included more developers and combined their results. The bigger your sample size is, the more precise the results are [22]. The developers should also conduct a whole software project, from the beginning to the end. This is to get a better view of how resources are spent during the different phases in a software project. To deal with this validity threat should the research be seen as the beginning of a bigger research that may or may not be conducted in the future.

(48)

Regarding transferability is the research context and the assumptions central to the research well described. The person that wishes to transfer the results then have to decide if it makes sense or not. The dependability of the research was dealt with by being very accurate with the daily time reports. To enhance the confirmability are the results well documented and can easily be checked or rechecked if needed.

(49)

7 Conclusions and Future Work

Managing time resources efficiently are very important to successfully complete a software project. Knowing how much time is spent and how it is distributed, is the key to success. When I searched for published material about how time resources are spent by an individual developer, was nothing found. The lack of published material on this matter made us formulate a research question about how much time resource are spent and how it is distributed by an individual developer in a software project. To address the research question, I conducted a research using the SGD framework. The social benefit of this research are the possibility of increased knowledge about time spent on individual developer work. If the developers can manage their time resources well will their productivity increase.

This can lead to that companies can decrease the prize of the developed products, making the consumers wealthier and business more profitable. The standard of living can be improved from both a commercial and consumer perspective [13].

The research was of quantitative type and had an inductive reasoning. Data collection was conducted via literature study and action research. Data evaluation was conducted via the specified evaluation criteria. The selection of the subject of study was by the convenience sampling method due to availability reasons.

The results suggests that as an individual software developer was most of the time spent on coding, resolving unclear questions and uncertainties, preparing and reviewing the low-level designs of the code to be written and changed, and identifying the source of errors. There was activity types that were conducted every week through the project and there was other activity types that were only conducted certain weeks. Every week was not the same, the activities had many differences of time spent in various iterations.

The scope of this thesis makes the need for the results to be further explored, because there was only one developer that was studied. This makes it hard to draw general conclusions about how much and where time resources are spent by an individual developer.

The SGD framework was found very useful to conduct this kind of research. It included all necessary activities and provided good guidelines of how to work as an developer. There was some activities included in the framework that was not conducted but that can be concluded that all have their own way of working.

Some improvements were discussed, first of was the distribution of the work that

(50)

could have been improved by following the SGD framework more strictly. The most important improvement was to have better communication with the team, the suggested solution for this was to always have the team seated together instead of working remotely. There was not any improvements suggestions for the SGD framework due to the fact that it worked very well for this research.

At the end of the research can it be concluded that the research results could be used as a basis for relevant models such as process models, measurement models, SPI models and therefore has the goal of the research been reached. The research question has also been answered by the research results showing how much time resources was spent by an individual developer in a software project and how these resources were distributed.

In future work more developers have to track their time on activities to get better research results. If there are results from several developers’ work then it is possible to analyze where time resources are generally spent. This research only studied one developer and the results only show results from that developer. More studies of developers’ work have to be made to get a general overview of how time resources are spent by an individual developer. These studies should include complete software projects and not only part of it as in this thesis.

(51)

References

[1] Software Engineering (9th edition), Ian Sommerville

[2] Bright Hub Project Management, "Managing Your Resources Throughout Your Software", 2013. Available: http://www.brighthubpm.com/resource- management/18939-resource-management-in-software-project-management- part-i/.

[3] Husson University Online, "What Is the Software Development Life Cycle?", Available: http://online.husson.edu/software-development-cycle/

[4] "Breaking Down Software Development Roles", Avail- able: http://zimmer.csufresno.edu/ sasanr/Teaching- Material/SAD/breaking%20down%20software%20development%20roles.pdf [5] BizMerlin, "Resource Management Process", Available:

http://www.bizmerlin.com/resource_management_process.php

[6] Hubstaff Blog, "Should Companies Track Employees’ Time?", Available:

http://blog.hubstaff.com/companies-track-employees-time/

[7] The Self-Governance Developer Framework, Mira Miroslawa Kajko Mattson [8] SAGE Publishing, "Introduction to quantitative research", 2010, Available:

http://www.sagepub.in/upm-data/36869_muijs.pdf

[9] Qualitative Research Methods Overview, Available:

http://www.ccs.neu.edu/course/is4800sp12/resources/qualmethods.pdf

[10] "The Action Research Process", Guiding School Improvement with Action Research, Richard Sagor, 2000, Chapter 1

[11] "About Action Research", University of San Diego, Available:

https://www.sandiego.edu/soles/centers-and-research/action-research/about- action-research.php

[12] thwink.org, "The Three Pillars of Sustainability", Available:

http://www.thwink.org/sustain/glossary/ThreePillarsOfSustainability.htm [13] Boundless, "The Importance of Productivity", Available:

https://www.boundless.com/economics/textbooks/boundless-economics- textbook/economic-growth-20/productivity-98/the-importance-of- productivity-368-12465/

(52)

[14] Business Truths, "Time is your important resource", Available:

http://www.businesstruths.com/articles/your-most-important-resource-is- your-time/

[15] Sources of Insight, "Know Thy Time", Available:

http://sourcesofinsight.com/know-thy-time/

[16] University of Kent, "HOW TO MANAGE YOUR TIME EFFECTIVELY", Available: https://www.kent.ac.uk/careers/sk/time.htm

[17] Toggl features, Available: https://www.toggl.com/features

[18] Research Methods Knowledge Base, "Deduction & Induction", 2006, Avail- able: http://www.socialresearchmethods.net/kb/dedind.php

[19] CIRT, "Sampling Methods", Available: https://cirt.gcu.edu/research/developmentresources/

research_ready/quantresearch/sample_meth

[20] The Personal Software Process, Watts S. Humphrey, 2000, Available:

http://www.sei.cmu.edu/reports/00tr022.pdf

[21] Scrum and XP from the Trenches, Henrik Kniberg

[22] Intermediate Statistics For Dummies, Deborah Rumsey, PhD

Developer’s time spent in a software project part using the SGD framework

Developer’s time spent in a software project part using the SGD framework

SIMON CIESLUK

Royal Institute of Technology KTH

Developer’s time spent in a software project part using the SGD framework

Simon Ciesluk

Abstract

Sammanfattning

Acknowledgments

Contents

1 Introduction

1.1 Problem

1.2 Research Question

1.3 Purpose

1.4 Goals

1.5 Commissioned Work

1.6 Scope and Limitations

1.7 Research Method

1.8 Ethics

1.9 Sustainability

1.10 Social Benefits

1.11 Target Group

1.12 Thesis Outline

2 Research Methodology

2.1 Research Strategy

2.2 Research Type

2.3 Research Phases

2.4 Sampling Methods

2.5 Research Instruments

2.6 Evaluation Criteria

2.7 Experience Gained

3 Extended Background

3.1 Software Development

3.2 Introduction to Resources

3.3 Time Resources

3.4 Time Measurement

3.5 Time Management

3.6 Feedback to the Work

4 The Self-Governance Developer Framework

4.1 The SGD Framework Overview

4.2 The SGD Process Model

5 Presentation of the Research Results

5.1 Sum of Time Spent on Each Individual Activity Within the Scope of the Project

5.2 Distribution of the Time Across Activity Types on an Iteration Basis

5.3 Differences of Time Spent on Various Activities in Var- ious Iterations

5.4 Coverage of Developer Activities in the SGD Frame- work

6 Analysis and Discussion

6.1 Analysis of Sum of Time Spent on Each Individual Ac- tivity Within the Scope of the Project

6.2 Analysis of Distribution of the Time Across Activity Types on an Iteration Basis

6.3 Analysis of Differences of Time Spent on Various Activ- ities in Various Iterations

6.4 Analysis of Coverage of Developer Activities in the SGD Framework

6.5 Discussion and Improvements

6.6 Validity Threats

7 Conclusions and Future Work

References