EXAMENSARBETE INOM DATATEKNIK, GRUNDNIVÅ, 15 HP STOCKHOLM, SVERIGE 2019

Line of Code Software Metrics Applied to Novice Software Engineers

MICHAEL PALMÉ

FELIX TOPPAR

KTH SKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP

Line of Code Software Metrics Applied to Novice Software Engineers

Palm´e,Michael Toppar, Felix [email protected] [email protected]

June 2019

Abstract

In the world of modern software engineering, there are certain metrics used to measure size and effort of projects. This provides insight to how engineers work, however when it comes to novice engineers there is little to no documentation. Without enough documentation this becomes a problem when trying to make predictions on projects involving novice software engi- neers, since there simply is not enough previous work on the area involving novice software engineers.

The problem is that there is very little research available when it comes to how novice software engineers efficiency compares to more experienced software engineers. This makes it difficult to calculate predictions on software projects where novice engineers are involved. So how do novice engineers distribute their time and effort in a software development project? The purpose is to find out how the time is distributed in a workplace involving novice software engineers. Further is to learn more of the differences between how novice and experienced software engineers distribute their time and effort in a project. The goal of this thesis is to improve the understanding of how novice software engineers contribute to a software project. In this work, a case study has been done with two novice engineers at a workplace in order to learn more about how novice engineers contribute to a software project. In this case study, a quantitative research method was adapted using the Line of Code software metric to document how the novice engineers distributed their time.

The results of the case study showed that the two novice engineers spent far more time coding than planning and that they wrote code faster than the average experienced engineer.

Abstrakt

I den moderna mjukvaruingej¨orsv¨arlden s˚afinns det vissa metriker som anv¨andsf¨oratt m¨atastorleken och anstr¨angningenav ett projekt. Med detta s˚af˚arman insikt om hur ingenj¨orerarbetar, men n¨ardet kommer till nyut- bildade mujukvaruingenj¨orers˚asaknas det dokumentation. Utan tillr¨ackligt med dokumentation s˚ablir det snabbt ett problem n¨arman f¨ors¨oker planera projekt som involverar nyutbildade mjukvaruingenj¨orer,detta eftersom att det saknas information i omr˚adetn¨ardet g¨allerjust hur nyutbildade mjuk- varuingenj¨orerarbetar.

Problemet ¨aratt det finns v¨aldigtlite unders¨okningtillg¨anglign¨ardet kommer till hur effektiva oerfarna mjukvaruingenj¨oreri j¨amnf¨orelsemed mera erfarna ingenj¨orer.Detta g¨ordet sv˚artatt ber¨aknaoch f¨orutsp˚ahur mjuk- varuprojekt utvecklas n¨aringenj¨orerna¨armera oerfarna. S˚ahur f¨ordelar oerfarnba mjukvaringenj¨orersin tid och var finns det st¨orstaanstr¨angningen vid ett arbete i ett mjukvaruprojekt. Menigen med detta arbete ¨aratt ta reda p˚ahur tiden som l¨aggsp˚aett mjukvaruprojekt distrubieras p˚aen arbetsplats med nyutbildade mjukvaruin- genj¨orer. M˚aletmed detta arbete ¨aratt f¨orb¨attraf¨orst˚aelsenang˚aendehur nyut- bildade mjukvaruingenj¨orerbidrar till ett mjukvaruprojekt. I det h¨ararbetet s˚ahar en fallstudie gjorts med tv˚astycken nyutbildade mjukvaruingenj¨orerf¨oratt unders¨oka hur nyutbildade ingenj¨orerbidrar till ett mjukvaruprojekt. Fallstudien f¨oljerdessa tv˚aingenj¨orerp˚aen arbet- splats d¨aren kvantitativ unders¨okningg¨orsmed hj¨alpav Line of Code mjuk- varumetriken som anv¨andsf¨oratt dokumentera hur ingenj¨orernaf¨ordelade sin tid p˚aarbetsplatsen.

Resultaten av fallstudien visade att dessa tv˚anyutbildade ingenj¨orer spenderade mycket mer tid ˚atkodande ¨an˚atplanerande, och att de skrev kod snabbare ¨anden genomsnittliga erfarna ingenj¨oren.

Acknowledgements

We would like to extend our gratitude to Qopla, who let us work with them at their office during the duration of this study. It was the first time either of us had worked in a professional software engineering environment. As such, it was very educational and we are now optimistic about the future and our post-graduation endeavors.

Contents

1 Introduction 4 1.1 Background ...... 5 1.2 Problem ...... 6 1.3 Purpose ...... 6 1.4 Goal ...... 7 1.4.1 Benefits, ethics and sustainability ...... 7 1.5 Collaborators ...... 7 1.6 Delimitations ...... 8 1.7 Outline ...... 8

2 Metrics in Software Engineering 10 2.1 Size ...... 10 2.1.1 Line of code ...... 11 2.2 Activities ...... 12 2.3 Effort ...... 13 2.4 Related work ...... 13

3 Research Method 18 3.1 Research strategy ...... 18 3.2 Action research ...... 18 3.3 Research phases ...... 19 3.3.1 Literature study ...... 19 3.3.2 Preparatory work ...... 19 3.3.3 Programming ...... 19 3.3.4 Conclude and analyze ...... 20 3.4 Respondents ...... 20 3.5 Validation threats ...... 20

2 4 Definitions for Lines of Code, Activities in the Workplace, and Effort 22 4.1 Lines of code ...... 22 4.2 Activities in the workplace ...... 26 4.3 Effort ...... 33

5 Results 34 5.1 The data ...... 34 5.2 Analysis ...... 35

6 Final Discussion and Future Work 38

A The Original Definition of a Line of Code 42

B The Original Activity List 44

3 Chapter 1

Introduction

Engineering implies measuring, this is a fact. Let us think of a successful business. In order for the business to be successful the business needs to max- imize profit. One way for the business to do this is by constantly keeping track on which products are selling and which are not. Based on the numbers the business can then determine which products to invest in. Another way for the business to maximize profits is by monitoring and measuring changes in the revenue when increasing or decreasing the number of employees that the business have. These are two of an almost countless amount of measure- ments a business can perform in order to be successful.

Let us hypothetically imagine another business that is struggling, be- cause they fail to make smart decisions. Now, this business is not lazy, the employees work even longer hours than in the more successful business. So how can this be? The answer might seem ridiculous, but in this case the reasons are that the failing business can not keep track on which products are selling and which are not. Furthermore the business can not figure out the optimal number of employees to have. In short the business have been slacking when it comes to logging the sales-data. Therefor this struggling business are missing measurements needed in order to be able to compete with the more successful business.

The two text segments above noted the importance of measuring within a business. But this importance also applies to engineering, in particular software engineering. In software engineering it is important to minimize the time it takes to produce a production quality line of code. Doing this

4 allows a software business to finish projects faster and thereby increasing the profit. One way is to find circumstances in which an employee can produce a higher amount of lines of codes. These circumstances can then be replicated making the employee more efficient. There exists many different methods and metrics on how to achieve this [13]. A popular metric and the metric this bachelor thesis will be focusing on is called The Line Of Code (LOC) software metric.

However this metric lacks studies, reports and data when it comes to its application on to novice software engineers, which makes the measurements harder to conduct. One way to think about it, is to reflect back to the first two text segments. Imagine that the struggling business employs only novice engineers and is now falling behind because of the lack of data when it comes to the application of the LOC metric. While the successful business employs no novice engineers and is therefor gaining an advantage because of the larger amount of data available on the application of the metric.

1.1 Background

In most businesses, it is desirable to measure as much as possible within a company in order to keep track of efficiency and other attributes. When it comes to software engineering it is relevant to measure the size of software projects. But how can this be measured? As it turns out, the most popular way of measuring size of a software project is to count ”lines of code”. To the reader who is unfamiliar with the world of programming this might seem like a very reasonable thing to do, and it definitely made sense back in the 1970s when the metric ”lines of code” was invented. This was during a time when programmers used punch cards to input their code (where one card usually corresponded to one line of code), and ”line-oriented” programming languages were the status quo. However in modern times it is actually a quite vague and tricky metric, since there are so many definitions of what could count as a line of code (as well as the total amount of lines of code being dependant on programming language, frameworks used, and type of software system being programmed). Despite this, counting lines of code remains the standard due to no better option existing, and it is certainly a better metric than no metric at all.

5 Programming speed and time distributed by the workers are also impor- tant statistics to document. Given that a definition for the size of a software project exists (lines of code), calculating the programming speed of a worker only requires someone to document the time spent coding, and then divide the size with the time spent. Programming speed could also be described as ”effort”. Effort can be calculated in more intricate ways than the one described just now, involving other parameters decided internally. These methods are further elaborated on in chapter 2.

The time distribution is a bit trickier to document. This is because in order to document the time distribution, one must first decide what activi- ties it should be possible for time to be distributed to. Depending on what activities are decided, the average day of a programmer could be described in different ways. For example, one could have many activities involving writing code (such as writing code, compiling code, searching for bugs, and fixing bugs), or one could have just one activity labeled ”coding” where all time regarding programming is allocated. Depending on the particular project and workplace, it varies how detailed the activities ought to be.

1.2 Problem

There is little research done when it comes to novice engineers and their effi- ciency compared to experienced engineers, making it difficult to compare the two and to calculate predictions on software projects where novice engineers are involved. This issue warrants the question; How do novice engineers dis- tribute their time and effort in a software development project?

1.3 Purpose

The purpose of this research is to find out how the time is distributed in a workplace involving novice software engineers. This may provide a basis to make predictions more accurate and reliable than possible today when it comes to how novice engineers spend their time in a software project.

6 The purpose is further to learn more of the differences between how novice and experienced software engineers distribute their time and effort in a project.

1.4 Goal

The goal of this thesis is to improve the understanding of how novice software engineers contribute to a software project. In the bigger picture the goal is to make businesses more aware of how novice engineers distribute their time and effort, by producing data and conclusions.

1.4.1 Benefits, ethics and sustainability This thesis has the intention of helping future software engineering students that are new to the professional environment. The result in this report is replicable and applicable to other students and help them in planning what- ever projects they may be working on.

The result might also be of use to employers, so that they may get a bet- ter idea of what to expect when hiring students working on their bachelor’s thesis, or just when hiring new software engineers in general.

1.5 Collaborators

Apart from the two novice software engineers studied in this work (who are also the authors of this thesis), there was a company involved at which all the programming was done and data collected.

This company is named “Qopla” and is located in Stockholm, Sweden. Qopla has a partnership with a middle-sized restaurant chain, and works with developing and maintaining their cash register system.

7 The restaurant in question uses a point of sale system, which makes infor- mation about purchases well documented, allowing the opportunity to create detailed reports in the cash register system with relevant information that the restaurant might want to analyze.

1.6 Delimitations

This thesis delves into effort per line of code for a specific project with two specific undergraduate students. This thesis does not go into areas such as what project methods might have been more efficient, or how different code standards and systems impact the result. The existing code structure was defined before the start of this thesis, and as such the software development was required to follow the same pattern.

1.7 Outline

The remainder of this thesis is as follows.

• Chapter 2: Metrics in Software Engineering.

In this chapter an extended background is presented, including dif- ferent metrics that are popular in the field of software engineering and how they have changed historically. Related work is also presented and motivated. • Chapter 3: Research Method.

In this chapter the research strategy will be explained. There will also be an explanation about the adapted quantitative methodology. Fur- thermore the chapter contains a sub-chapter explaining the different research phases, respondents, validations threats and research instru- ments used within the study. • Chapter 4: Definitions for Lines of Code, Activities in the Workplace, and Effort.

8 In this chapter the definitions for ”line of code”, ”effort”, and ”ac- tivities” are explained as well as motivated.

• Chapter 5: Results.

Chapter 5 contains the data from the case study, as well as an analysis and comparison of the data.

• Chapter 6: Final Discussion and Future Work.

Here there is a discussion about what future work could be done to further this work.

9 Chapter 2

Metrics in Software Engineering

There are a few many different concepts that needs to be introduced in order to get a sufficient understanding about the topic at hand. In section 2.1 the concept of size will be explained. Thereafter, section 2.2 discusses more detailed the concept of activities. In section 2.3 there will be an explanation on how size and activities can be viewed together as effort. Lastly, section 2.4 contains a view into the related works.

2.1 Size

Size in and of itself does not say anything, in order for this word to make sense there needs to be some underlying knowledge about what subject and topic are being discussed. In software engineering size often refer to the scale of a program, how big it is. [12]

So how does one interpret the concept of size when it comes to software engineering? There are a few different ways to think about it. A normal and a somewhat uninformed way is to look at the functionality that the program offers. Naturally a program that offers more features and more intricate de- signs usually have size that is larger, right? Not so fast.

It is a fact that the size of different features in different programs vary. Meaning a program with a size 2MB can contain more features than a pro-

10 gram with a size of 10MB. Clearly there is not one clear way to define size by looking at the functionality or the actual size in memory that a program occupies.

Because there is not a straight line between the size of a program and its functionality/memory size one has too look at different ways how to interpret the concept. In comes line of code. The code that builds a software program is written on lines, these lines can then be counted to measure the size. As one can reason, it is not without its flaws, but it is a common way to measure the size of a software program. [11]

2.1.1 Line of code Source line of code or just line of code(LOC) are an actual line of code that is used in a software program. The size of a program can be measured by counting all the lines that the program contains.

Okay, so we now know that the size of a software program are determined by counting all the different lines of code within that program. But here is the crux, can we be sure that a program with a larger size contains more lines of code? To answer this question one has to know how the code lines are being counted. There are many different ways LOC can be counted depend- ing on variables like programming language, coding and counting standards etc. [11] Another crux to think about is also how should the lines be counted. Should they be counted by hand? Or with some kind of tool? There are a few different tools programmers can use to count lines of code such as CLOC [2] or LocMetrics [4]. Once the standards and tools have been chosen, only then can a programmer in a useful way count the lines that the program contains thus finding the size of the program. When the size of the program is de- termined, how reliable is it? What does it say? Imagine now that another program is written, this program when counted, arrives an equal amount of lines of code. So we now know that these to programs have the same size, right? Not so fast, in order to compare the size of two or more software pro- grams, the programs needs to have adapted the same counting standards and tools when counting the lines of code. Only then can an true and meaningful comparison take place.

11 By comparing two code segments one can with this strategy get a size measurement and thus determine which segment is larger and which is smaller. It is not necessarily true that the bigger segment took longer time, was more complex or that it fulfilled more functionality than the smaller segment. Other than knowing which is bigger and smaller the concept of lines of code alone does not provide any useful meaning. In order to use the size of a pro- gram in any real way we need to introduce new concepts, such and activities and effort which will be introduced in section 2.2 and 2.3 respectively.

2.2 Activities

As notioned in chapter 1(Introduction), the goal to minimize time per line of code is something that is highly sought after both for companies and for private developers. On that note when talking about software engineering and the line of code software metric there needs to be a standard under which activities the time should be measured. There are plenty of activities a programmer take part in given a normal day. So how do you determine under which activities to perform the measuring?. Just as in the line of code concept the implementation can vary, and usually companies have their own standards on what to count. When developing a software program there are many different types of activities to consider, some less obvious than others. When deciding what activities to measure there are preliminary, planning, coding, testing, delivery activities and many more to keep in mind [10]. One thing to keep in mind is that measuring the time spent on these activities can take time. Setting up a custom measuring standard in addition to performing the actual measurements is something that can be quite costly depending on the adapted measurement method. The benefits by measuring very detailed activities can be something very useful and can provide a clearer picture on which individual activities to optimize. However in order to make measur- ing activities like this profitable there needs to be a measurement method in place. The more detailed the activities the more detailed the method needs to be.

Measuring the time spent on big and easily definable activities can be done manually without much work, by recording time stamps containing start and end values. However with more specific and details activities manually measuring is something that becomes increasingly harder. For activities that

12 are slightly more specific there are a few tools developers can use, one of them WakaTime [5], which offers automated time tracking. But with more specific activities, these tools might miss the needed customization, and here developers will probably have to create their own tool that can meet the requirements.

2.3 Effort

Effort is a term that combines lines of code and activities. By viewing the amount of lines of code while also viewing the time spent on what activities, it is possible to measure effort. The most intuitive way to do this is to sim- ply divide the amount of lines of code with time spent to calculate the lines of code per unit of time. This method happens to be the method which is used in this thesis, but there are other ways to calculate effort as well. One popular method makes use of the formula E = aSb, where E is the effort cal- culated, S is the size measured as lines of code, a is a productivity parameter and b is an economic scaling parameter [15]. However, this method requires that the parameters a and b are decided beforehand. This is done internally within the company, deeming what is appropriate given the circumstances of that particular company.

2.4 Related work

There exists previous work that touches on the subject of lines of code, measuring the size of a software project, and effort estimations. These works can be related to this thesis, and in this sub-chapter those that are referenced will be listed and briefly motivated as to why they are used in this thesis.

• Analysis Of Source Lines Of Code(SLOC)Metric [6].

This report provides a comprehensive view to understand what SLOC metric do and how much one can rely on SLOC metric. This report discussed the advantages/disadvantages with the SLOC metric. Fur- thermore the report delved into the programming language differences, counting tools, and even the physiology of the programmer. For ex- ample the report mentioned that a lack of cohesion with the program

13 functionality is one of the many disadvantages of the line of code soft- ware metric. Meaning that a more experienced engineer might be able to write a program with the same functionality with far less code. Be- cause of this a program with less lines of code could contain more functionality than a program with the equal amount of lines of code. The author argues that because of this, the line of code software metric is a poor choice when it comes to measuring the productivity of a in- dividual. Because of good reasoning and broad self-evident statements this report worked as a useful instrument when it came to determining a line of code metric methodology for this project.

• A SLOC counting standard [11]

This paper argues that one of the biggest problems with the line of code software metric are that there are no standards in place. This was something that the two student could agree on after completing the lit- erature study. Furthermore the author argues the importance of having a well defined global counting standard while being forthright and open about the difficulties presented in the setting of such a standard. The two students learned that counting the physical lines might not be the best, because different programmers used different line-breaks, brack- ets, and so on. The author then presented a broad counting standard, containing what type of code statements to count. This standard served as inspiration of the line of code metric counting standard defined for this project as seen in Chapter 3.3.1.

• Software Engineering Economics [7]

This reference is relevant because it brings up many methods used to determine cost in a software engineering project in detail. Although it is a pretty old book, some methods such as the ”COCOMO” method (brought up and described earlier in chapter 2.2.1) are still very rele- vant today. Even if this method is not applied to this particular work, it is still interesting and relevant to include in the conversation about the history of line of code and effort.

14 • Measuring architectural complexity [8]

This rather short paper is good to include since it speaks of other uses for lines of code than just measuring productivity and effort. This reference speaks briefly about how to evaluate the complexity of a pro- gram using SLOC. Specifically, the reference mentions that by looking at how the SLOC numbers change over time, it is possible to identify a projects hot spots, which usually indicates an area in the code where there is architectural instability.

• Software size measurement: A framework for counting source state- ments [12]

This report is relevant because it contains the definition for what should count as a line of code, which is adapted for this paper. The adapted definition with its choices and changes is motivate in chapter 3, but is based on this reference.

• Effort Estimations Based on Lines of Code and Function Points in Soft- ware Project Management [13]

This report is relevant because it delves into the area of both line of code and effort estimation, which is the same area that is being dis- cussed here. Even though the methodology presented in this report was not adapted due to it being deemed inappropriately complex given the size of the project, the report itself provided good insight on how to look at effort. This reference also has some valuable insights that have been used in the introduction (see chapter 1), as well as providing interesting information about the history of measuring effort based on lines of code using diagrams.

• Software engineering education: a roadmap [14]

Even though this paper is quite old it provides useful insight when it comes to software engineering education. The report raised con- cerns about a educational misalignment with the continuously growing software field. This paper was used to gain a wider understanding how novice software engineers adapt to the workforce. This reference is used

15 as some background information to the area of this report, drawing pos- sible parallels between the education system for software engineers and their performance as novices in the workplace.

• Estimating Software Project Effort Using Analogies [15]

This report is relevant because it discusses the method of determining effort through analogies. Since we are discussing predicates for deter- mining effort, this is quite interesting when talking about the history of line of code effort, and what methods have been used in the past to evaluate these metrics. However the topic discussed here is deemed too advanced (by us authors) to be applied to this papers method of determining effort. This is because estimating effort by analogies re- quires creating a mathematical model with certain features, which is outside the scope (and ability) of this paper.

16

Chapter 3

Research Method

This chapter describes the research method used in this study. Chapter 3.1 involves the research strategy used. Chapter 3.2 and 3.3 are regarding the method choice and the different research phases. Finally Chapter 3.4 and 3.5 are about the respondents involved and validation threats.

3.1 Research strategy

The research area that this thesis is targeting is quite unexplored. There is not much information about the line of code metric adapted to novice soft- ware engineers. This meant that the learning of the material was easy, but the time it took to find the information on the topic turned out the more difficult. The chosen research strategy involves defining a research method, research phases, respondents, and validation threats. The research method that was chosen is a quantitative method on a case study.

3.2 Action research

Classical Action research is based on the idea that true knowledge are knowl- edge that can developed through action. The primary reason to adapt an action research methodology is to help the actor in improving and or refining his or her actions. [9]. The actors in this study are the two software engineers.

18 3.3 Research phases

The study was split into four research phases. Literature study, prepara- tory work, programming and conclude and analyze. The first two phases was conducted in parallel. Because of this the time could be well spent and the knowledge gain could be maximized. This chapter explains the four phases containing the parallel phases Literature study(3.3.1) and Prepara- tory work(3.3.2), well as the following two phases Programming(3.3.3) and Conclude and analyze(3.3.4).

3.3.1 Literature study The first phase of the research phases was a literature study. This involved finding relevant existing work on the research area to get an overview on the subject of line of code, effort, activities. The literature study also involved searching for existing work on how novice engineers compare to experienced engineers in the workplace, although this search yielded no valuable results.

3.3.2 Preparatory work The preparatory work involved getting familiar with the programming en- vironment at the workplace and installing the required software. It also involved learning about the particular work methods of the company Qopla.

This phase also involved agreeing upon definitions for what should count as a line of code, what activities should be used, and how effort should be calculated. These definitions can all be viewed in chapter 4.

3.3.3 Programming For the duration of the case study, the two novice engineers were given a software system component to program at the workplace. The details of the software system component will not be discussed, other than it was regarding the back end programming of a dashboard interface to a cash register system.

19 At the end of each work day, the engineers would recollect and document how much time they spent on each activity, and allocate that much time to the corresponding activity in a spreadsheet.

3.3.4 Conclude and analyze The final phase of the research phases was to conclude and analyze the data collected throughout the case study. This can be viewed in detail in chapter 5, where the results are analyzed and discussed as well as being compared to other data.

3.4 Respondents

This section is regarding the choice of respondents in the case study, that is to say the two novice software engineers. The two engineers were students at KTH, Royal Institute of Technology where they at the time were on their final semester of their undergraduate program. There was no method re- garding the choice of these respondents, as they are the same people as the authors of this thesis.

3.5 Validation threats

Validity is a very important attribute for research to have. This is why it is important to discuss potential validation threats that were present during the research, and what precautions were taken to avoid them. For this thesis, there were some validation threats of concern. One such threat is regarding the method of counting the lines of code. There was a code repository system used in this work, which has the ability to count the lines of code added to a branch. This became a little problematic since that systems definition of what to count was not the same as the one in this thesis. The solution became to manually deduct the lines of code which were abundant, where there is a possibility of human error and therefore it becomes a validation threat.

20 Another validation threat is the method of which time spent was at- tributed to activities. This was done at the end of each workday by recol- lecting how time had been spent during the day. It goes without saying that there is a risk for human error here, which makes it a validation threat.

21 Chapter 4

Definitions for Lines of Code, Activities in the Workplace, and Effort

This chapter presents the definitions for a line of code and effort, as well as the list of activities that is used in this work. This chapter also provides motivation as to how these definitions were agreed upon.

4.1 Lines of code

The methodology adapted in this study was quite straightforward, since the actual work performed at the workplace are disconnected from this thesis study, most of the methodology was to determine how to define different counting standards.

The first thing to establish was a counting standard for what to count as a line of code. When setting these definitions the students had to take into consideration many different factors. Such as what development environment the code was being produced in. This factor alone could heavily effect the amount of code written. With smarter text editors and frameworks which provide plenty of way of live improvements such as code generation and large functional libraries. Another factor to take into consideration could be what type of measurement tools that are available. It is clear that you can not

22 count what you can not measure, this will be reflected more upon further down in this subsection. The last important factor that will be mentioned when determining what to count as lines of code are what coding languages are being used. There exists a ton of different coding languages which all have its weaknesses and advantages. A simple quick-sort algorithm would take hundreds of lines to write in Assembly while in Elixir or Erlang (two functional programming languages) it is doable with just a few dozen of lines. Therefor it is important to define if the counting method of different languages should vary or not.

So lets look at the chosen method when it comes to what to count. To get a good overall understanding on what could be relevant to count the follow- ing definition checklist for statement inspired by Park, Robert E technical report ’Software Size Measurement: A Framework for Counting Source’ was used. [12]

Statement type

 1-1:Executable order of precedence. These types of code statements are usually very common in software development, especially in the applied language Java, and usually does not provide any difficulties when counting.

 1-2:Non-executable. These types of statements are usually not presented in Java develop- ment and deemed not relevant to count.

 1-3:Declarations. These types of statements are a core part of Java development and easy to count.

 1-4:Compiler directives. These types of statements does not play a vital role in a ’high-level’ language like Java, they are more common in language like C. Most text editors and frameworks already come with predefined compiler direc- tives so these code statements are usually handled behind the scenes.

 1-5:Comments. Comments are a very useful tool in all software development, but it does

23 not provide any additional functionality and was therefore deemed not to be counted.

 1-6:Blank lines. Without blank lines a program becomes vary messy and it is therefore a vital part of a software developers tool set. With that said, just like with comments, they do not provide any additional functionality to the program and are therefore deemed not to be counted.

How produced

 2-1:Programmed. All code that is programmed and not specifically mentioned in this checklist should be counted.

 2-2:Generated with source code generators. Modern text editors and frameworks usually provide a very helpful feature to generate source code. Since tools like this enhances software developers code output, is commonly used and in most cases availability to everyone, the decision to count generated source code was taken.

 2-3:Converted with automated translators. Modern text editors and frameworks usually provide a very helpful feature to convert code with automated translators. Since tools like this enhances software developers code output, is commonly used and in most cases availability to everyone, the decision to count code converted with automated translators was taken.

 2-4:Copied without change. It is generally bad practice to copy code without changing it. But then again it might be situations where it is a good choice, therefor the decision to count these types of code was taken.

 2-5:Reused without change. If a section of code is reused it should not be counted. Since most modern programs are continuously being executed it is not feasible to count every single line of code each time it is being executed. Therefor the decision to not count reused code without change was taken.

24  2-6:Modified. If a code section is modified, only the modified part of the code section should be counted.

 2-7:Removed. If a line of code is removed no counting should take place. One could argue that the functionality of the program usually change when code a removed. That is of course true and in many cases it could be in- teresting to count removed code. For example in debugging when a single line of code can be removed to solve the bug. But in this specific case when the students produced new functionality, they might have had to remove old code, and therefore counting these lines might skew the results in a negative direction. Therefor the decision to not count removed code was taken.

Origin

 3-1:New work: no prior existence. New work with no prior existence should always be counted as long as it is in accordance with the other items in this list.

 3-2:Prior work: taken or adapted from. Taken work sounds bad but many times it is something software devel- opers should aim to use, there is no reason to reinvent the wheel. With that said, how can one tell if the work is taken? After further reasoning around prior work it became quite clear that taken or adapted prior work should be counted.

Usage

 4-1:In or as part of the primary product. This point is highly relevant and depends on the actual product. In this specific case for the two students the decision to count was taken.

 4-2:External to or in support of the primary product. This point is highly relevant and depends on the actual product. In this specific case for the two students the decision to count was taken.

25 Going forward there needed the be a standard on how the students should do the actual counting. Here the questions on what tools to use become rele- vant. There are many different things to take into consideration. Is it doable to count the lines manually? If so more questions arise, such as how big the program is, is it even smart to count thousands of lines , and of course the risk of losing accuracy. If the option to use a counting tool is chosen, a factor to take into consideration is the configuration of the counting tool that are being used, is this a program that the students should program themselves to match the defined counting standard, or should some third-party counting tool be used. Furthermore the tool in question need to be able to determine which programmer has written the code and if the code is new or old.

The decided method ended up being a mixture consisting of manual counting and a counting tool. The chosen counting tool was GitHub.There are plenty of different counting tools out there, such as CLOC or LocMetrix. These are great tools that have a more complex, all be it general definition of the line of code software metric. But again because of the time restrictions and the predicted size of the software program to be developed, these tools and others was not compatible with the specific counting standard defined above. The decision to use GitHub was taken because it is a very widely used version control system and it provides simple but clear merge reports. These reports contain lines added, removed and changed. Given this fact the decision to use Githubs merge report together with the defined counting standard to count the number of lines of code was taken.

4.2 Activities in the workplace

Time has been distributed into different activities which will now be shown in a checklist, where the activities we decided to keep are marked with an X, and the rest are not. Each item in the list is shortly motivated as to why it was kept or not kept. Please note that the template from where this checklist originated from was divided into different types of activities such as planning activities and preparatory activities and more. The types of activities where we decided not to keep any activities for the entire category will not be in- cluded here, but in appendix B (due to the entire list being over 90 items long, and is quite uninteresting).

26 Preliminary activities

 PR- 1: Review and agree on the overall or part of the project plan.

This activity is kept simply because before the work had even begun, time had already been distributed into this activity. Agreeing on the project plan is quite crucial for the project to come through.

 PR-2: Revise and ensure that the technology to be used is tested and understood.

This activity is retained because it was necessary at the beginning of the project to understand the environment of which the work would be done.

 PR-3: Revise and understand any appropriate internal (organizational) and external standard(s).

This activity is kept since the programming that the two software en- gineers did was not done from scratch, but rather as an additional component to an already existing system. Therefore there were al- ready certain standards decided, which needed to be upheld.

 PR-4: Learn/relearn the organizational implementation and unit (de- veloper) testing way of working.

This activity was not kept because it was determined that in a small software project such as the one documented in this report, it is not realistic that time is spent on this activity.

27  PR-5: Review and revise your personal implementation and unit (de- veloper) testing way of working.

This activity was not kept because it was determined that in a small software project such as the one documented in this report, it is not realistic that time is spent on this activity.

 PR-6: Other, specify

No activities were thought of that might be appropriate for this group of activities.

Planning Activities

 PL-1: Review the requirement(s) for the unit(s) to be developed.

It was decided not to keep this activity even though there was consid- erable time spent with it. This is because of the activity ”PL-3 Resolve unclear questions and uncertainties”. All time that would have gone to PL-1 has instead gone to PL-3 because it was decided that there are too many activities in this list regarding clarifying objectives. It is not necessary for that to be more than one activity, so PL-3 is used for all of them since it is phrased more generally.

 PL-2: Prepare (make) and/or review the design specification(s) for the unit(s) to be developed.

This activity was not kept since it was decided to be too tedious to constantly distinguish writing code and discussing code, since the two software engineers worked as a pair and were constantly communicat- ing while coding. That is not to say that no time has gone into this activity, only that that time has instead been written down in ”C-1 Write/rewrite your code.”.

28  PL-3: Resolve unclear questions and uncertainties.

This activity functions as a collective activity for any time an uncer- tainty had to be resolved with the employer. This involves questions on the topic of: design, efficiency, requirements and whatever other problems might have been discussed during the course of this work.

 PL-4: Determine and document your implementation and unit (devel- oper) testing goals.

The unit testing done in this work was very minimal, so there was al- most no time spent discussing the goals of the testing. The little time that was spent asking the employer for requirements of the unit tests, is attributed to PL-3.

 PL-5: Determine your implementation and unit (developer) testing strategy.

Although there was some minimal time spent on this activity, it was decided that the time might as well be attributed to PL-3. This is be- cause of the strategy of the unit testing being decided by the employer, who had specific requirements and ideas for the unit testing (although very minimal unit tests all the same).

 PL-6: Determine appropriate implementation and testing practices.

This activity was not kept, since the two engineers in question did not have the freedom to decide these things. There were already standards and practises in place when the work began, and so the time that would have gone into this activity has instead gone into activity PR-3.

29  PL-7: Identify standards to be used for meeting your goals.

This activity was not kept because it was agreed that it is quite un- clear. Any work standards that were maintained during the course of the work, were not kept through discussions and meetings, but rather though trial and error.

 PL-8: Set your own personal deadlines to be met during your imple- mentation and unit (developer) testing work.

This activity was not kept because it was not part of the project plan to have personal deadlines, and hence no time was spent on this activ- ity. Furthermore, the two software engineers do not see how spending time on creating a personal deadline would make that deadline easier to reach.

 PL-9: Estimate effort and resources required for carrying out your work.

No time was spent estimating effort or resources required for the work since no time pressure was ever felt by the two software engineers in this work. If there had been some pressures, then it might have been necessary to spend time on this activity.

 PL-10: Schedule your work.

This activity was not kept since the only scheduling done during the course of the work, was the two software engineers agreeing on what days to write this thesis, and what days to do the programming work. Which is to say, a negligible amount of time.

30  PL-11: Review your implementation and unit (developer) testing plan to ensure that it is realistic and achievable.

This activity was not kept simply it was decided that no time was needed to be spent on this, due to the very minimal requirements that the employer had for unit testing. Any time that might have been spent on this has instead been attributed to PL-3.

 PL-12: Identify risks related to your plan.

No time was spent on this activity and was thus not kept.

 PL-13: Plan for managing any identified risks.

No time was spent on this activity and was thus not kept.

 PL-14: Other, specify

No activities were thought of that might be appropriate for this group of activities.

Coding Activities of a Developer Role

 C-1: Write/rewrite your code.

This activity is kept, and is also the activity with the most time at- tributed to it. All coding done by the two software engineers (including writing unit tests) is written down as time spent in this activity.

31  C-2: Compile/ recompile your code as required.

It was decided that it is very tedious to keep track of time spent compil- ing, and also quite uninteresting for the result to know the time spent compiling. As such, this activity was not kept.

 C-3: Make notes on your compilation errors, if necessary.

This activity was not kept since it was agreed that the time spent mak- ing notes on compilation errors would be greater than the time spent fixing the same compilation errors, and also serve no purpose.

 C-4: Make notes on your defects.

This activity was not kept since it was agreed that the time spent mak- ing notes on defects would be greater than the time spent fixing the same defects. Also, since there were only two software engineers in- volved in the work, the benefit of writing notes in general decreases, since there is nobody else to read them. Further, it was agreed that it would be more efficient to simply fix the defects instead of spending time on writing notes.

 C-5: Other, specify

No activities were thought of that might be appropriate for this group of activities.

There were five additional lists of activities in the original template which once again, can be viewed in the appendix for the curious reader. In general, the thinking behind what activities to keep or not are decided by the size of the work, and the desire to not waste too much time pondering about time distribution on such a granular level (hence why the unit of time for documenting is hours and not minutes).

32 4.3 Effort

The definition used for effort in this thesis is the amount of lines of code written per hour. That is to say, the size of the project divided by the time spent on the project.

33 Chapter 5

Results

In this work a case study has been performed using a quantitative research method. This case study involved two novice software engineers enrolled at KTH, Royal institute of Technology in their final year of their undergraduate studies. This chapter presents the data documented in the case study, as well as an analysis.

5.1 The data

In this section the data recorded in the case study is presented. Table 5.1 shows all the kept activities and their associated times spent on them. Due to the length of the labels of the activities, they cannot fit inside the table and are instead presented here for your convenience.

The data in table 5.1 shows that there was two hours spent reviewing and agreeing on the overall project plan. Eight hours were spent revising and ensuring that the technology to be used in the workplace is tested and understood. Nine hours were spent revising and understanding any appro- priate internal and external standards. Sixteen and a half hours were spent resolving unclear questions and uncertainties. Finally, one hundred and fifty hours were spent writing or rewriting code. This accumulates to a total of 185,5 hours spent in the workplace. Furthermore, the final amount of lines of code written is 1376, and the effort (lines of code written per hour approx- imately) is 7,4.

34 Activities Time spent (hours) Review and agree on the overall or part of the project plan. 2 Revise and ensure that the technology to be used is tested and understood. 8 Revise and understand any appropriate internal (organizational)and external standard(s). 9 Resolve unclear questions and uncertainties. 16,5 Write/rewrite your code. 150

Total 185,5

Table 5.1: The recorded hours per activity

5.2 Analysis

In an article written on successfulsoftware.net [3], there are some claims re- garding how long it can take for a professional programmer to write one line of code. Before we get into the specifics, it must be mentioned that the article uses its own definition for a line of code, which can be found at the bottom of the article. The numbers presented in the article seem to be quite reliable, with sources vouching that the numbers were produced in measurements of productivity.

A few examples are mentioned, and the results are that in one day, it can be expected that 10 to 125 lines of code are written per day depending on the nature and size of the software project. The variance of the amount of code written per day is a result of varying definitions of lines of code, according to the article. The data presented in the article can be alternatively presented as between 0,4 and 5,2 lines of code in an hour, as opposed to the result of 7,4 lines of code written per hour in this paper. If it is a smaller software project, it seems from the article that the amount of lines of code per hour increases, but the data in this report is still showing less time needed per line of code.

What conclusions can be drawn from this comparison? One could make claims that it is a result of carefulness, complexity of the program, the amount of programmers involved, or even the inability of inexperienced engineers to compress their code.

35 However, this article does not suggest so as it is merely presenting its own data. Furthermore, it has proven quite difficult to find field studies of line of code and effort where comparable data is provided.

When trying to figure out what the average amount of lines of code are per hour and workplace, there seem to exist many comments, opinions and articles claiming different numbers. However when performing a closer in- spection, most of these statements and opinions lacks actual references in forms of studies or data to back up the their claims. Based on this, it is clear that most of the opinions and statements when it comes to the efficiency and results of the line of code software metric, usually refers to personal ex- periences instead of an actual representative study. Looking at this at first glance might leave you scratching your head. But, one and probably the biggest reason why this is the case is: The line of code software metric stan- dards vary, meaning what to count, how to count, what coding languages are being used, and the list just keeps on going. Therefore many compa- nies, projects and teams all use different methodology. Just like the specific tailor made method adapted for the work presented in this report. If this is the case, future work based on field-studies of the line of code software metric, not only for novice software engineers should contain a much larger test sample consisting of engineers applying the same methodology to the metric. This way, one would get more reliable results and might be able to give answers to some of the debated conclusions mentioned above.

36

Chapter 6

Final Discussion and Future Work

When trying to measure projects or programs in software engineering, met- rics such as lines of code and effort are used to measure size and efficiency. This is of course valuable since it provides interesting information for em- ployers. However there is a lack of data in this particular area when novice software engineers are involved. This becomes a problem since in the ever growing profession of software engineering, more and more novice engineers are entering the workplace and it can be difficult to know what to expect from them as opposed to experiences software engineers.

In an attempt to better understand how novice software engineers dis- tribute their time in the workplace, a case study has been performed in this work with a quantitative research method. This is with the hope to improve the understanding of how novice software engineers contribute to software projects, by providing data and insight.

Software engineering just like any other field has much to gain from mea- suring the efficiency of workers in order to make prediction for future projects. This technique is very common, but the problem arises when novice software engineers are involved. Since there is a lack of research when it comes to novice engineers, suddenly it is considerably harder to make predictions.

This report attempts to help solve this problem by providing quantitative research and analysis on a case study involving two novice engineers, with the

38 goal improve the understanding of how novice software engineers contribute to a software project. This in turn may enable accurate predictions to be made with novice engineers.

The purpose of making predictions more accurate regarding novice engi- neers has arguably not been achieved, due to a lack of substantial conclusions. There are simply not enough novice engineers involved in the study in order for the quantitative data to bear any weight.

There is room for future work in the area of line of code documentation for inexperienced software engineers. Although data was documented and produced, due to the small amount of engineers involved in this work any conclusions that may be drawn in this report are quite ungrounded (for now). However, if a larger scale study were to take place in the future with tens of inexperienced and experienced software engineers with the same adapted methodology. Then the results retrieved from that following study would have had much more merit. There might even be connections with the re- sults in this paper, but for now it is simply not reasonable to draw any major conclusions from one specific software project, with two specific novice soft- ware engineers.

To wrap things up, a fun little epilogue using a Sir Winston Churchill paraphrase that answers the question: Why do people still use the line of code software metric? The line of code metric is the worst software metric except for all those other metrics that have been tried from time to time. [1]

39 References

[1] Churchill. https://richardlangworth.com/worst-form-of-government. Accessed: 2019-06-05.

[2] Cloc. http://cloc.sourceforge.net/. Accessed: 2019-06-22.

[3] How much code can a coder code? https://successfulsoftware.net/2017/02/10/how-much-code-can-a- coder-code/. Accessed: 2019-05-30.

[4] Locmetrics. http://www.locmetrics.com/. Accessed: 2019-06-22.

[5] Wakatime. https://wakatime.com/. Accessed: 2019-07-04.

[6] Kaushal Bhatt, Vinit Tarey, Pushpraj Patel, Kaushal Bhatt Mits, and Datana Ujjain. Analysis of source lines of code (sloc) metric. Inter- national Journal of Emerging Technology and Advanced Engineering, 2(5):150–154, 2012.

[7] Barry W Boehm et al. Software engineering economics, volume 197. Prentice-hall Englewood Cliffs (NJ), 1981.

[8] Grady Booch. Measuring architectural complexity. IEEE software, 25(4):14–15, 2008.

[9] Paulo S´ergioMedeiros dos Santos and Guilherme Horta Travassos. Ac- tion research use in software engineering: An initial survey. In Pro- ceedings of the Third International Symposium on Empirical Software Engineering and Measurement, ESEM 2009, October 15-16, 2009, Lake Buena Vista, Florida, USA, pages 414–417, 2009.

40 [10] Mira Miroslawa Kajko-Mattsson and Gudrun Jeppesen. Self-governance developer framework. In THIRD INTERNATIONAL CONFERENCE ON ADVANCES AND TRENDS IN SOFTWARE ENGINEERING (SOFTENG 2017), pages 103–109. International Academy, Research and Industry Association (IARIA), 2017.

[11] Vu Nguyen, Sophia Deeds-Rubin, Thomas Tan, and Barry Boehm. A sloc counting standard. In Cocomo ii forum, volume 2007, pages 1–16. Citeseer, 2007.

[12] Robert E Park. Software size measurement: A framework for counting source statements. Technical report, Carnegie-Mellon Univ Pittsburgh Pa Software Engineering Inst, 1992.

[13] K Koteswara Rao and TVM Rao. Effort estimations based on lines of code and function points in software project management. IJC- SNS International Journal of Computer Science and Network Security, 8(6):358–356, 2008.

[14] Mary Shaw. Software engineering education: a roadmap. In ICSE- Future of SE Track, pages 371–380, 2000.

[15] Martin Shepperd and Chris Schofield. Estimating software project effort using analogies. IEEE Transactions on software engineering, 23(11):736–743, 1997.

41 Appendix A

The Original Definition of a Line of Code

Source:

Park, Robert E. Software size measurement: A framework for counting source statements. No. CMU/SEI/92-TR-20. Carnegie-Mellon Univ Pitts- burgh Pa Software Engineering Inst, 1992.

42 Definition Checklist for Source Statement Counts

Definition name: Physical Source Lines of Code Date: 8/7/92 (basic definition) Originator: SEI

Measurement unit: Physical source lines ✔ Logical source statements Statement type Definition ✔ Data array Includes Excludes When a line or statement contains more than one type, classify it as the type with the highest precedence. 1 Executable Order of precedence -> 1 ✔ 2 Nonexecutable 3 Declarations 2 ✔ 4 Compiler directives 3 ✔ 5 Comments 6 On their own lines 4 ✔ 7 On lines with source code 5 ✔ 8 Banners and nonblank spacers 6 ✔ 9 Blank (empty) comments 7 ✔ 10 Blank lines 8 ✔ 11 12 How produced Definition ✔ Data array Includes Excludes 1 Programmed ✔ 2 Generated with source code generators ✔ 3 Converted with automated translators ✔ 4 Copied or reused without change ✔ 5 Modified ✔ 6 Removed ✔ 7 8 Origin Definition ✔ Data array Includes Excludes 1 New work: no prior existence ✔ 2 Prior work: taken or adapted from 3 A previous version, build, or release ✔ 4 Commercial, off-the-shelf software (COTS), other than libraries ✔ 5 Government furnished software (GFS), other than reuse libraries ✔ 6 Another product ✔ 7 A vendor-supplied language support library (unmodified) ✔ 8 A vendor-supplied operating system or utility (unmodified) ✔ 9 A local or modified language support library or operating system ✔ 10 Other commercial library ✔ 11 A reuse library (software designed for reuse) ✔ 12 Other software component or library ✔ 13 14 Usage Definition ✔ Data array Includes Excludes 1 In or as part of the primary product ✔ 2 External to or in support of the primary product ✔ 3

Figure 2-2 Example of One Page of a Completed Checklist

8 CMU/SEI-92-TR-20 Appendix B

The Original Activity List

Source:

KAJKO-MATTSSON, Mira Miroslawa; JEPPESEN, Gudrun. Self-Governance Developer Framework. In: THIRD INTERNATIONAL CONFERENCE ON ADVANCES AND TRENDS IN SOFTWARE ENGINEERING (SOFTENG 2017). International Academy, Research and Industry Association (IARIA), 2017. p. 103-109.

44 6. Providing and managing time reports During the project, you will have to report your effort on a daily basis. Use the template in the “My time_MyName_Date” file and deliver it to canvas on a daily basis. The file should be delivered every working day before 23.55. Make sure that your name and date is included in your file name. For instance, name your files Karl_Johansson_170503.

Appendix A SGD DEVELOPER data to be collected on a daily basis

Preliminary Activities Activities Person-minutes Toghether with (No of people) PR- 1: Review and agree on the overall or part of the project plan. (This may be either one-off or continuous activity!) PR-2: Revise and ensure that the technology to be used is tested and understood. PR-3: Revise and understand any appropriate internal (organizational) and external standard(s). PR-4: Learn/relearn the organizational implementation and unit (developer) testing way of working. PR-5: Review and revise your personal implementation and unit (developer) testing way of working. PR-6: Other, specify

Planning Activities of a Developer Role Activities Person-minutes Toghether with (No of people) PL-1: Review the requirement(s) for the unit(s) to be developed. PL-2: Prepare (make) and/or review the design specification(s) for the unit(s) to be developed. PL-3: Resolve unclear questions and uncertainties. PL-4: Determine and document your implementation and unit (developer) testing goals. PL-5: Determine your implementation and unit (developer) testing strategy. PL-6: Determine appropriate implementation and testing practices. PL-7: Identify standards to be used for meeting your goals. PL-8: Set your own personal deadlines to be met during your implementation and unit (developer) testing work. PL-9: Estimate effort and resources required for carrying out your work. PL-10: Schedule your work. PL-11: Review your implementation and unit (developer) testing plan to ensure that it is realistic and achievable. PL-12: Identify risks related to your plan. PL-13: Plan for managing any identified risks. PL-14: Other, specify

Preparatory Activities of a Developer Role Activities Person-minutes Toghether with (No of people) P-1: Prepare(make) and/or review your low-level design(s) of the code to be written or changed. P-2: Prepare (make) an impact analysis of your low-level design(s). P-3: Determine the types of unit (developer) test cases and their order. P-4: Create and/or revise your unit (developer) test case base. P-5: Revise the existing unit (developer) regression test base, if relevant. P-6: Create or modify stubs and drivers, if required. P-7: Prepare your unit (developer) testing environment and check whether it is appropriate for you work. P-8: Other, specify

Coding Activities of a Developer Role Activities Person-minutes Toghether with (No of people) C-1: Write/rewrite your code. C-2: Compile/ recompile your code as required. C-3: Make notes on your compilation errors, if necessary. C-4: Make notes on your defects C-5: Other, specify

Unit Testing Activities of a Developer Role Activities Person-minutes Toghether with (No of people) T-1: Check whether the unit (developer) test case base meets the given requirements and design. T-2: Check whether the unit (developer) regression test base meets the given requirements and design. T-3: Remedy requirements problems in your unit (developer) regression and/or test cases base, if any. T-4: Perform dynamic testing by executing code. T-5: Perform static (human) testing by reviewing your code. T-6: Record/write down test results. T-7: Other, specify

Evaluative Activities of a Developer Role Activities Person-minutes Toghether with (No of people) E-1: Analyze your unit (developer) testing results. E-2: Depending on the unit (developer) testing results, determine your next step(s). E-3: Other, specify

Debugging Activities of a Developer Role Activities Person-minutes Toghether with (No of people) D-1: Identify the source of (an) error(s). D-2: Determine solution(s) for eliminating the sources of error(s). D-3: Other, specify

Self-Assessment Activities (Document aside your self-assessment results) Activities Person-minutes Toghether with (No of people) A-1: Assess your own development work. A-2: Identify causes of your mistakes. A-3: Identify improvement areas in your own way of working. A-4: Other, specify

Delivery of a Developer Role Activities Person-minutes Toghether with (No of people) S-2: Deliver your code. S-3: Other, specify

Appendix B Table for collecting NON-DEVELOPER data on a daily basis

Managing Requirements of a Non-Developer Role Activities Person-minutes Toghether with (No of people) REQ 1: Identify requirements REQ 2: Analyze requirements REQ 3: Change requirements REQ 3.1: Identify impact of change (time it takes to identify changes everywhere in the system) REQ 3.2: Make change(s) (time it takes to make changes everywhere in the system) REQ 4: Plan requirements REQ 4.1: Estimate effort REQ 4.2: Prioritize requirements REQ 4.3: Other planning activities related to requirements (specify) REQ 5: Other, specify

Design of a Non-Developer Role Activities Person-minutes Toghether with (No of people) DES 1: Design system or system component (high-level design) DES 2: Analyze design DES 3: Change design DES 3.1: Identify impact of change (time it takes to identify changes everywhere in the system) DES 3.2: Make change(s) (time it takes to make changes everywhere in the system) DES 4: Other, specify

NON-DEVELOPER Level Testing, acceptance, system, integration testing Activities Person-minutes Toghether with (No of people) TEST 1: Define tests TEST 2: Analyze tests TEST 3: Change tests TEST 3.1: Identify impact of change (time it takes to identify changes everywhere in the system) TEST 3.2: Make change(s) to tests (time it takes to make changes everywhere in the system) TEST 4: Other, specify Project management of a Non-Developer role Activities Person-minutes Toghether with (No of people) PROJ-MAN 1: Plan project/part of project (iteration) PROJ-MAN 2: Analyze project/ project plan /part of project (iteration) PROJ-MAN 3: Change project plan /part of project plan (iteration) PROJ-MAN 4: Evaluate your project work PROJ-MAN 5: Manage risks PROJ-MAN 5.1: Identify risks PROJ-MAN 5.2: Analyze risks PROJ-MAN 5.3: Manage risks PROJ-MAN 6: Customer-related activities, specify PROJ-MAN 7: Other, specify

TRITA-EECS-EX-2019:584

www.kth.se