Software Process Improvement plan

Transcription

1 UNIVERSITY OF OSLO Software Process Improvement plan TDD Karoline 11/15/2012 INF5181

2 Table of Contents Introduction... 3 Improvement context... 3 The issue... 3 Process improvement method... 3 Improvement goals... 4 Baseline process... 5 Description of the baseline process... 5 Descriptive model... 6 Performance of the baseline process... 8 Target process... 9 Changes... 9 Test driven development... 9 Description of target process... 9 Implementation of target process Measurement and Control Measurement plan Base Measures Derived measures Action plan Success Discussion Underlying rationale of proposed changes Risks of proposed changes Bibliography

3 Introduction In this section the context in which the software process improvement plan (SPI) is going to be conducted will be described. The problem the company struggles with, the method that will be used and the goals that will be set for the improvement will also be further elaborated. Improvement context The company is a small Norwegian software development company. They are consultants and develop software systems for their costumers. The systems they develop are usually around net lines of code (NLOC) and are web based, hosted in the cloud. Because they are such a small company they have no individual test group. Usually everyone works on the same project. The entire company consists of 6 software developers and one manager. They specialize in developing new software. Their main development language is Java and they use spring MVC for developing web solutions. When doing projects they use the scrum model, this is because they are such a small team and because they like the iterative development style. The issue The developers like to postpone the writing of tests because they want to write real code. By real code they mean code that has a functionality they can see. This means that they don t want to waste their time writing automatic tests. This results in the company using a lot of time on manually checking for errors during the development. The company has a policy that all of the code has to be covered by tests so that the delivered software is reliable. Because of this, they have to write automatic tests, but they postpone it to the end of the sprint. They even use more time than necessary because they have forgotten their reasoning when they wrote their code. This results in the same error being search for first manually and then automatically by tests. Process improvement method To improve this problem the software process improvement method that should be used is the plan-do-check-act (PDCA) model as described in Figure 1. This method consists of: 1. Plan what you want to accomplish and how to do it 2. Do what is planned 3. Check the results 4. Act on the results(plan for future improvement) (Ronald Moen) The plan phase will be covered by describing the baseline process, the target process and the implementation of target Figure 1: Plan-do-check-act model (Brunner, 2009) 3

4 process. Do is when the company does the suggested changes. How to check is covered by the measurement plan and act is covered by the action plan. Improvement goals The goal of this SPI is to help the company reduce the effort spent on developing 1 kilo line of code (KLOC) by 10%. This is done by reducing the effort spent on manually searching for errors by at least 80%. By effort is meant number of person hour spent. This has to be done without decreasing the quality of the delivered software. This is measured by number of defects per KLOC. 4

5 Baseline process In this section the elements of the current process are going to be described. The elements in the process and how they are related will be outlined. Description of the baseline process The description of the baseline process will only contain information about the part of the process that will be changed. The activity that is relevant for this particular case is the development activity, which is a part of the sprint in scrum. The development activity consists of a number of sub activities which are functionality implementation, manual error searching and testing. Artifacts sent into this activity are the sprint backlog, which contains the estimated user stories broken down into tasks, functionality and software. The roles involved in the activity are the scrum team and the scrum master. The tools that are used is burn-down chart and meetings. Roles Scrum team: members of the development team o Developer: member of the scrum team Scrum master: member of the team, but acts as the leader when necessary Artifacts Sprint backlog: Collection of user stories that are divided into tasks o User stories: Description of wanted functionality o Tasks: This is the user stories broken down into smaller tasks that should be possible to do in a day. Functionality: Functionality of the software Manually tested functionality: functionality that is manually tested by developer Software without automatic tests Software: The working product from the sprint. Activities Development: The development of the functionality during a sprint o Implement functionality: Functionality defined by a task is implemented o Manually search for errors: Developers manually search their code for errors o Write automatic tests: Tests to check if the functionality implemented is correct. Tools/techniques Daily standup: The scrum team talks about what they did the day before and what they are going to do this day. Represents the start of a new daily scrum. Burn-down chart: A tool to asses how many hours of the estimated time of the sprint that are burned (finished). 5

6 Descriptive model The different roles, artifacts, activities and tools/techniques can be illustrated in a descriptive model of the process. This is to better understand how the sprint is conducted. To understand the different shapes of the diagram, take a look at Figure 2. Figure 2: A description of the different shapes Figure 3 is an overview of how the development activity looks like from the outside. Figure 3: Overview of the development activity To get a better understanding of the different sub-activities in the development activity Figure 4 will be helpful. This figure is only a description of how the functionality is implemented. Not a description of everything that is done during the development of the software. 6

7 Figure 4: Detailed description of the sub-activities in the development activity 7

8 Performance of the baseline process Each person monitors with a time management software how much time he uses on the implementation itself and how much time he uses on manually searching for errors in the code that is written. This is measured during the sprints. The management of the company collects the numbers and finds that for 1000 NLOC, an average of 19 person hours are used manually searching for errors. This is during the development and does not include test writing. It is also found that an average of 66 person hours is used on developing 1000 NLOC during the sprints. Measurements also show that on average 2 errors are reported for 1000NLOC 6 months after delivery. 8

9 Target process In this section the elements in the baseline process that will be changed are described. How the new process looks like will also be elaborated. Changes In stead of writing the tests at the end and doing a lot of manual testing, test driven development (TDD) should be applied in the development activity. This means moving the test writing from the end of the sprint to in front of the functionality implementation and removing the manual error searching activity. Test driven development There are 3 steps in TDD. 1. Red - Write a test that does not work 2. Green Write code to get the test to pass, 3. Refactor Eliminate duplications created when getting the test to work (Beck, 2003) This has to be done for all of the code. Testing frameworks like mockito can be used to test user interfaces. The code should not even know that it is not communicating with a regular user. By doing this, possible errors can be identified before they emerge. And when you get errors, the tests will tell you exactly where they are. Description of target process They use Scrum as before, but with TDD as a tool in the development activity. This is described in Figure 5. Figure 2 explains the different shapes in the model. Figure 5: Development activity with TDD as a tool 9

10 To get a more detailed description of the development activity, take a look at Figure 6. This model shows how a developer chooses a task, writes the test, sends the failing test as an input to the code writing, get the test to pass, refractors, then continues to do this until the sprint is done, and out comes the tested sprint deliverable. Figure 6: Detailed description of the development activity using TDD 10

11 Implementation of target process In this section the implementation of the target process is described. When you are suggesting changes to the process it is important to take into account when the process is supposed to be changed and who is in charge of the changes. What steps need to be taken to implement the changes is described in Table 1. What When Who How Get support from management Communicate changes to developers Allocate resources for training Training Start using the new process As soon as possible Management Present the improvement plan As soon as the management is convinced After the changes has been presented to the developers Start as soon as possible after the resources has been allocated and when workshops are available After training is complete, and the developers starts a new project Table 1: Steps before implementing changes The manager will be responsible for communicating the changes and developers need to conform to this Management Developers Developers, management Explain the developers the reason and the expected results of the changes Get resources Coding kata Pair programing Workshops Apply the changes to process 11

12 Measurement and Control In this section the details of the measurement plan is described. This is done by describing how the measurements are taken and how to control the measurements. Measurement plan To reach the improvement goals, you have to measure the current results and the results after the improvement plan has been initiated. Because it takes time to get to know the new way of working, the improvement usually won t be seen right away. The team needs time to adapt to the new way to work. Two sprints will be needed before the final measurements are evaluated. To find out if less time is used on manual error searching, one needs to measure the effort as done in Table 2 and average it, as done in Table 6. The code length also needs to be found as described in Table 3 so that you can derive the averages. It is important that the same measurement script is used each time so that the measures are objective. To measure quality the number of errors needs to be measured as described in Table 4 and then the derived average quality as described in Table 7 needs to be found. The overall time spent on developing as described in Table 5 and the average effort spent on developing in all sprints in the project as described in Table 8 also needs to be measured so that the improvement can be found. Base Measures Characterizes an empirical property and requires no prior measurement of another property. Manual error searching effort Entity Manual error searching Attribute Effort Unit Person hour Range [0, ) When is it measured When sprints are done Who collects data Developer How is it collected Time management program Who is responsible for data integrity Scrum master Table 2: Manual error searching effort Code length Entity Code Attribute Length Unit Kilo lines of code(kloc) Range (0, ) When is it measured When sprints are done Who collects data Scrum master How is it collected Measurement script Who is responsible for data integrity Scrum master Table 3: Code length 12

13 Code quality Entity Code Attribute quality Unit defects Range [0, ) When is it measured 6 months after delivery Who collects data Costumer How is it collected Costumer reports big and small errors Who is responsible for data integrity Manager Table 4: Code quality Development effort Entity Development Attribute Effort Unit Person hour Range (0, ) When is it measured During development Who collects data Developers How is it collected Time management software Who is responsible for data integrity Scrum master Table 5: Development effort Derived measures Uses one or more base measures. This measurement requires the measurement of two or more attributes. It combines the attributes using a mathematical model. Average manual error searching effort Entity Manual error searching Attribute Average effort Unit (Error searching effort / KLOC) Range [0, ) When is it measured After product is completed Who collects data Manager How is it collected Gathers base measures Who is responsible for data integrity Manager Table 6: Average error searching effort Average quality Entity Code Attribute Average quality Unit (Defects/KLOC) Range [0, ) When is it measured 6 months after delivery Who collects data Manager How is it collected Gathers base measures Who is responsible for data integrity Manager Table 7: Average quality 13

14 Average development time Entity Development Attribute Average effort Unit (Development effort/kloc) Range (0, ) When is it measured After project is completed Who collects data Manager How is it collected Gathers base measures Who is responsible for data integrity Manager Table 8: Average development time Action plan The actions depending on the success/failure of the SPI will be described. This is according to act in the plan-do-check-act method. (Ronald Moen) After two scrum projects the success or failure of the SPI can be determined. The first sprint will be mostly training and getting used to the new way of developing software. The second sprint will be refinement of the new way. In the third sprint, the skill should be properly evolved and the wanted improvement should be seen. This is when the success or failure is determined. Success The SPI plan will be considered a success when Manual error searching effort is reduced by at least 80% o Less than 2 hour is spent on manual error searching The quality of the products are better or the same o Error rate <3 per 1000NLOC The overall time spent on developing functionality is reduced by 10% If this is reached during the second scrum project, the SPI will be considered a success. If the wanted improvement is not reached the company is still encouraged to keep the improved process because there are a lot of other benefits involved with using TDD as presented in the Discussion. 14

15 Discussion In this section the underlying idea of the SPI are introduced and potential risks involved with the SPI are presented. Underlying rationale of proposed changes The reason why TDD is suggested as the improvement is because it is a well tested method that is widely used by a lot of big and small development companies. One could suggest just writing the tests first, without using the TDD technique, but using TDD is said to come with a lot of other benefits as well: Eliminate duplication Less complex code Watch dog for future changes Validate that the implementation matches the requirements Easier to change the code Write tests early as a down payment for future technical debt Easy to modify (Levison, 2008) TDD is a well suited method because it forces the developers to write tests before they implement functionality. Not only is manual error searching made redundant but it also forces the developers to find out what functionality is going to be implemented, before they start writing code. Risks of proposed changes When a change like this is implemented there are a lot of risks involved. This is because change is hard. The developers are often perfectly happy with how they already do things and it is hard to make them change their ways. This is a big risk related to changing the process. The developers had already decided that they did not like to write tests and therefore postponed the test writing until the end. This suggests that the developers themselves had a saying in how their development process was conducted. To take this power away from the developers is a risky thing to do. If the developers are not properly convinced that the changes are for the best, the changes might result in reluctance among the developers. Because the developers are the ones that has to conduct the changes, support is very crucial. To get their support, they need to be convinced that the change is a good one that will benefit them. How to do this is presented in the action plan. Code quality depends on the quality of the tests. The people that wrote the tests before are the same people that write the tests now. This is why the quality of the code should not be reduced by this, it might even be improved, but this is not proven. 15

16 Bibliography Beck, K. (2003). Test-Driven Development: By example. United States: Addison Wesley. Brunner, M. (2009, April 16). Building an Electrical Maintenance Program. Retrieved November 13, 2012, from The asset Rliability Road Map: Levison, M. (2008, October 14). Advantages of TDD. Retrieved November 1, 2012, from Agile pain relief consulting: Ronald Moen, C. N. (n.d.). Retrieved November 15, 2012, from Evolution of the PDCA Cycle: 16