Everything can be reused

Introduction

The development of human civilization does not express that we are smarter than the ancients. The reason is human can constantly study and copy the available knowledge and the previous experience. In the same way, an outstanding software company needs to reuse the successful experience and technology. However, software reuse does not singly include reuse of technical aspects. The reuse scope can be expanded. Actually, during the software development process, almost everything can be reused, such as technology, management, knowledge, estimating and testing.

Technology reuse

Technology reuse can reduce the total project duration. Currently, the business trend of IT industry is to improve the update speed and the development efficiency rather than to study the technology in every detail. Moreover, the reuse of technology mainly includes the design reuse, component reuse, library reuse, code reuse, etc. [1]

In particular, it can be divided into three parts. Firstly, the reuse can happen within a single project. Reducing the duplicate code is the basic coding ability, and it also is the simplest reuse rule. Secondly, developers have to reuse the open source resources and the shared components. Nowadays, numerous shared resources are available, such as code, components, and softwares. However, developers must consider the copyright issues and test these resources carefully before reuse them. Thirdly, although neither two projects are extremely similar, the reuse can across different projects. No matter what the project is, there exists a lot of content that can be reused.

For example, Microsoft has an Enterprise Library, which provides a set of Blocks. Their projects can directly use these Blocks and obtain the corresponding service. For example, the Data Access Application Block provides the API of data access. Based on this Block, programmers can avoid developing the database access code again.

Management reuse

Microsoft always summarizes its successful experiences based on numerous large projects. The Microsoft Solution Framework (MSF) referenced some of these experiences, which has been recommended to the whole Microsoft and even the software companies around the world. Both the MSF eight principles and its team model are playing an immeasurable role in the current project management area. In addition, for IT industry, there is various development methods can be referenced and used. Such as the Rational Unified Process (RUP), the Agile, the Extreme Programming (XP), etc.

Nevertheless, the project management reuses cannot totally copy the available theoretical models. The reuses that related to their own business characteristics are much more useful than the reuses based on other software companies’ successful experience. Different companies have to summarize the experiences by practice, then specify the best experience into the corresponding process model, which will benefit to their future projects.

Knowledge reuse

Professional knowledge is the basis of customers’ requirements. The aim of technology improvement is to serve these requirements. Business software is a kind of software products that focus on a particular area and required high-level professional knowledge. Such as the financial software, the stock trading software, the construction budget software and the hospital system software. Hence, the developers who response to these kind of projects must have a corresponding professional knowledge. During the development process, poor knowledge will significantly increase the complexity of requirement analysis. Within this situation, developers tend to miss the project direction and only passively respond the customer’s demands.

In addition, customers might not only focus on the company’s technical level, but also play attention on whether the company helps them to reorganize the operational process or not, and whether the software improve their business benefits or not. In order to keep the knowledge superiority, most companies try to hire more employees who are familiar with the special industry. In fact, the best way of solving this problem is to reuse the professional knowledge. For example, arranging the business experts to implement the knowledge documentation, namely, the requirements specifications and the usage manuals. Training is another benefit method that can help all development members to have the appropriate knowledge.

Estimating reuse

In general, project estimation is inaccurate. An accurate estimation requires a deep and comprehensive consideration based on a variety of issues. Currently, there are many estimation methods, such as function point method and KLOC method. These methods are not faulty, but most developers might not be familiar with them and cannot give the full play on their actual effect [3]. In fact, project estimation cannot be handled effortlessly. It depends on the wisdom, the experience and the judgment ability of the employee who will estimate the corresponding value. Hence, the most effective way of improving project estimation is to copy and reuse their outstanding ability.

Testing reuse

Testing reuse [4] is essential and fundamental because it can improve the testing efficiency, increase the software quality and reduce the workload. The test engineers need to frequently reuse the test cases which have already found defects. Moreover, during the new feature testing, testers should reuse the previous test cases based on the available features, in order to make sure that the new feature will not break the original structure.

However, many testers cannot achieve to reuse these test cases. The critical reasons are shown as follows. Firstly, the project manager often compresses the testing duration, so only a part of the available test cases can be run. Secondly, many software companies do not attach importance to the testers. Thirdly, the automatic testing tools are still imperfect. Finally, the testing engineers have to continuously carry on the manual testing.

In my opinion, there are two possible methods of improving the testing reuse:
1. Specify the testing process. Testers need to accurately record all the defects and the corresponding test cases.
2. For each testing process, testers should summarize the experiences and lessons that may be reused in the future.

Conclusion

In summary, there exists a lot of methods that can be reused, such as the efficient coding method, the risk identification method, the project management method, the defect detecting method, etc. Certainly, the basic idea of reuse is to summarize the previous experience and use them in the future. That is why the reuse library provides a lot of useful help, which can improve the development speed and the product quality. Moreover, there is not a software company can obtain all the excellent developers and nobody will promise that he can work for one company forever. Therefore, the software companies not only have to pay attention to recruiting the outstanding employees, but also need to keep expanding their reuse library.

References

[1] Sommerville, I. (2004), Software Reuse. Software Engineering, 7th edition. Chapter 18.
[2] Guideline: Software Reuse.
[3] Software Management – Estimating Reuse Feasibility, AcqNotes.
[4] Lonngren, D.D. (2012), Reducing the Cost of Test Through Reuse.

 

Response to article: ‘Developers and testers‘ by s1355673

Introduction

This is the response article of ‘Developers and testers: friends or foes? Using fuzzy set theory to decide on the correct ratio of developers to testers in agile teams [1]by GAN. Firstly, this article will briefly reveal the benefits and the limitations of the original article based on personal opinion. Secondly, it will compare the importance between programmers and test engineers. Thirdly, the required critical skills of test engineers will be elucidated. Finally, this article will justify the basic rules of the software testing progress.

 

Strong points and limitations of the original article

Accordingly, both developers and testers play an indispensable role in the large-scale and long-term software development. There is no doubt that fight and cooperation never stop between developers and testers in the real world. In particular, test engineers can help the programmers to find the risks or bugs, which hide behind the seemingly perfect code. Moreover, they can also prove whether the project is in the right direction or not.

However, when some serious issues appear, both the developers and the testers will shirk the responsibility. For example, if an error is found during the debugging progress, the programmers might argue that the testing is incorrect and they always say: ‘The program works well on my computer’. On the other hand, the test engineers will believe the problem lies in the code rather than in their testing process. Therefore, as GAN said, an outstanding management of developers and testers will impel the weaknesses become strengths.

In addition, one focus of the original article is ‘how to decide on the correct ratio of developers to testers on an agile team’. Unfortunately, the calculation of this ratio value is extremely difficult. Because both the company size, the complexity of the developed software and the length of the project duration will affect the testing progress. In fact, the professional capability level of testing group is much more essential than the number of testing members [2]. The following section will describe the main testing skills.

Finally, GAN said that testers and developers will become one role in the future. This opinion is quite special, but it is absolutely correct. Every developer will easily have the testing skills owing to their familiarity. Furthermore, to hire more testers will highly increase the project budget.

 

Programmers v.s Test Engineers

In the real world, testing is a low-level work in software development and most developers are used to do the testing work before. As a matter of fact, if the salary is unchanged, none programmer will want to change their job to testing. For testers, some of them will agree to join in coding group, but others will not due to their terrible programming skills. Accordingly, most developers look down testers.

In the ideal situation, test engineers also have the outstanding programming skills and their work is comfortable and effortless. However, most of them cannot coding and the testing progress is extremely boring and vague. In particular, testing does not have the clear written requirements. If the testers have some confusing understanding, they have to ask the project manager or a related programmer. Nevertheless, the answers they obtain always are: ‘You do not need to discern this!’, ‘You do not need to understand that!’, ‘You only need to test it by this way!’.

Undoubtedly, this situation will cause the testing job to become useless. Moreover, the project manager and programmers have to handle and complete a lot of testing work. Such as the managers have to check whether the project is in the correct direction or not. Moreover, they need to teach the testers how to plan a useful test case, which will meet the requirements and the technical characteristics. Hence, in order to reduce the testing cost and increasing the testing efficiency, some developers will be involved in the testing progress. In fact, testing plays a pushing role in software development, it not only can rectify the direction and the defect, but also can reduce the rework risks. That is why the testers should have the following required and professional skills.

 

The required skills of test engineers.

Teters Skills

Figure 1 [3] indicates the skills that testers should have. Actually, most testers only understand the ‘test theory and method’ and realize some of the ‘business knowledge’. For other skills, their cognitive might almost be zero. That is why testers have to accept the discrimination of programmers and the company’s disregard. However, the skills that are listed in this figure might be too much. If a test engineer has all these skills, he tends to leave the testing job. Thus, the following rules can appear.

 

The basic rules of the software testing progress

Mainly, there are seven rules that might improve the testing efficiency and effect.

  • Rule 1: The real difficulty of testing.

The complicated of software testing is not less than developing. Some testers might insist that the testing progress is to click their mouse on the completed user interface. For the highest testing, they merely need to comprehend some performance testing tools, such as LoadRunner. In fact, according to the above figure, testers at least satisfy ‘Essential skills’ and ‘Advanced skills’. If they do not have these skills, the testing cannot be smoothly performed.

  • Rule 2: Rejected the second-hand requirements.

‘Second-hand requirements’ are the requirements that testers identify them from their manager, but not from the customers. It will reduce the accuracy rate and expand the tricky level of testing. The way of directly obtained first-hand demand is that all testers should be involved in the requirements analyzing.

  • Rule 3: Rejected be involved in the project in midway.

Numerous projects will arrange the testing members at the late stage, and these testers might be responsible for another project testing at the same time. Undoubtedly, testers must join in the whole project life cycle, namely, each project should at least have a ‘complete’ test engineer.

  • Rule 4: Testing decides whether the defect exists or not.

During the testing progress, if a tester finds a defect that is not recognized by developers, the following situations might occur.

  1. Owing to the poor experience and limited knowledge, the tester will be convinced by the programmer and agree that the project is completely perfect.
  2. The project manager will deliver the final decision. However, most managers used to be the developers before, so finally the defect might not be recognized.
  3. Customers will give the final decision.
  4. According to the majority rule. Testing members are certainly in the minority part of the group, so that the defect will not be accepted.

In fact, the testers should make this decision. Because their opinions are closer to customers and they require the responsibility and power of making a correct judgment, which can enhance their working enthusiasm. Moreover, hiding defect is equal to a time bomb is buried in the project.

  • Rule 5: Daily testing

Every tester should install the software development tool on their own computers. They need to acquire the developed code every day and process the compilation. Namely, this is the front work of the final testing. It will avoid the terrible situation that all the dilemmas appear just before the project delivery [4].

  • Rule 6: Do not need to write the exhaustive test cases.

The common and simple work does not need the documentation. Only the complex, error-prone and intricate contents require the response test cases. Furthermore, the job of test case description is to point out the key testing process rather than including every step in details. When the condition is mature, the company may gradually establish a test case library, which allows the testers to learn and use.

  • Rule 7: The available resources between testing and developing.

If both the programmers and the testers can understand the work of each other, the project cost might reduce and the development progress will become more efficient [5]. Currently, most developers do not have the testing conscious. And a great number of test engineers are not familiar with the software development. Hence, the project manager should train the coding capacity of some outstanding testers and let the programmers to respond some testing jobs of the project. In addition, the basic principle is that the programmers cannot test the modules which are developed by themselves.

 

Conclusion

In summary, testing is not a low-technical work, in contrary, the importance and difficulty of testing are no less than software design. It is one of the most critical parts of project development, which can ensure the correct direction. In addition, testing cannot be carried out at the late stage of the project. Therefore, all the testers should improve their ability of the above testing skills. Moreover, the project managers should track the project based on the testing principle and provide the improved opportunities and the decision-making power to the test engineers. Finally, the programmers need to humbly and carefully check their work. Any potential defects should be taken seriously.

 

Reference

[1] GAN (2014), Developers and testers: friends or foes? Using fuzzy set theory to decide on the correct ratio of developers to testers in agile teams.
[2] Whelan, D. (2009), Agile Testing: The Role Of The Agile Tester.
[3] Tutorialspoint.com, “Software Testing Tutorial“, Simply Easy Learning
[4] Bach, J. (1999), “Risks and Requirements Based Testing“, IEEE Computer Society, pp. 113-114.
[5] Kaner, C., Hendrickson, E. & Brock, J.S. (2001), “MANAGING THE PROPORTION OF TESTERS TO (OTHER) DEVELOPERS“, Northwest Software Quality

 

Earned Value Management is not a mathematical game

Introduction

During the development process of a large software project, the project management team has to constantly track the implementation of its plan and calculating the deviation of its schedule and budget. An outstanding progress tracking method can easily control the software development risk. Certainly, Earned Value Management (EVM) is a common method, which will comprehensively consider the scope, cost and schedule of projects (Robert, 2007) [1]. Moreover, it will help the project managers to evaluate the project performance and the developing trend.

In general, the EVM principle might suitable for any project within any industry. However, software projects are extremely special because it is quite difficult to determine their requirements and design. Additionally, their budget and schedule cannot be changed frequently. Thus, these characteristics tend to increase the complexity of EVM implement. Accordingly, the research and application of EVM will be limited, unclear, abstract and inscrutable (Scheid, 2013) [2]. This article will analyze EVM in a relaxed, simple and practical way.

To begin with a story

The following story might help readers understand the basic of EVM.

Assume that the requirement was to cut down 800 trees within 10 days and the current resource was a woodcutter who can cut 10 trees down per hour. Soon afterwards, the project manager determined the project plan, which was that the woodcutter should work 8 hours per day and for each working hour, he could get £‎10. To sum up, 80 trees could be felled down every day and the total duration would be 10 days and the cost would be £‎800.

According to the analysis, even the simplest plan requires the consideration of these factors:

  • The number and the ability of employees. (1 woodcutter, 10 trees per hour)
  • The daily working hours. (8 hours per day)
  • The daily situation of project completion. (80 trees per day)
  • The total duration and cost of the project. (10 days, £‎800)

After planning, the project began. The actual situation of the first three days might be this.
[DAY1] The woodcutter spent 8 hours to cut down 80 trees.

[DAY2] The woodcutter spent 8 hours to cut down 100 trees.
[DAY3] The woodcutter was really tired, he spent 8 hours to cut down 60 trees.

In particular, these content will be concerned during the project tracking.

  • What is the difference between the planning time and the actual working time.
  • What is the difference between the planning progress and the actual progress.

For example:
[DAY1] The actual progress completely meets the plan.

Completion rate: 100%.
[DAY2] The actual duration is as same as the plan and the task is over-done.
Completion rate: 125%.
[DAY3] The actual duration is consistent with the plan, but the task is unfinished.
Completion rate: 75%.

Unfortunately, the following progress is not optimistic.
[DAY4] The woodcutter was sick. He only worked 4 hours and cut down 20 trees.
[DAY5] The progress was more terrible. The woodcutter worked 4 hours and cut 10 trees.
[DAY6, 7, 8] The woodcutter applied for sick leave.
[DAY9] The woodcutter returned to work. He worked 8 hours and cut down 80 trees.
[DAY10] The project is seriously behind schedule. So, two new woodcutter were hired by the manager. Three employees worked 12 hours (4 overtime hours, requires double pay) and cut down 360 trees.
[Final Result] 710 trees were cut. The total cost was £880. Therefore, The project cannot be completed before the deadline and it was over budget.

Actually, for the general projects, the salary can be determined in two different ways.

  • Based on the working time. (£10 per hour)
  • Based on the working progress. (£1 per tree)

Undoubtedly, any wise managers will not consider the first one. Because it will highly reduce the work efficiency and another one can certainly control the total cost. Nevertheless, for software projects, the salary cannot be calculated by the immeasurable progress. Typically, most software companies will use the working hour to count the salary. That is why in this story, working time was the salary standard.

As a result of this, project tracking is a status measurement of the project milestones, tasks and activities [3]. Managers have to continuously monitor the completion status by collecting and calculating the statistical data. Thus, the benefits of EVM are more and more outstanding.

Three Basic Elements: PV, AC, EV

Based on the story, the following three project tracking points must be focused.

  • The completed situation of tasks in the plan.
  • The actual situation. Such as the current usage of time and cost.
  • The completion situation of tasks in actual.

However, neither the customers or boss will pay their attention on whether the employees are sick or not; whether the programmers work overtime or not. In general, most customers only care about that can the requirements be delivered on time. The amount of project benefit achievement will be the greatest concern of the boss. For that reason, the three basic elements of EVM are using money as their quantitative unit. In other word, PV, AC and EV respectively quantified the three above points [4].

Based on the felling story.
The Planed Value (PV) is 8 hours * 10 days * £‎10 = £‎800.
4 days later, the actual work of the woodcutter is 8 hours + 8 hours + 8 hours + 6 hours = 30 hours. So the Actual Cost (AC) is 30 hours * £‎10 = £‎300.
Finally, due to the task is to cut down 800 trees and only 80 trees + 100 trees + 60 trees + 20 trees = 260 trees have been cut down. So the completion rate is 260 trees / 800 trees = 32.5% and the Earned Value (EV) is 32.5% * £800 = £260.

In summary, PV responses the planning of tasks. AC indicates the actual investment of tasks. EV displays the actual completion situation of tasks [4]. On the other hand, money might not be a suitable unit of measurement. Because every employee has their own salary standard, which is confidential.

There are two ways to solve this issue.

  • Comprehensive cost

Putting the various cost together, such as the utility bills, the site fees, the salary of all employees, etc. Then equally divided it to every staff who will directly involve in the project development.
For example, a company needs to pay the following costs every day, namely, £50 for utility bills, £150 for site fees, £800 for salary, £600 for the others. Moreover, there are 9 programmers and a manager who are working for the project. And they will work 8 hours per day. So the comprehensive cost is (£50 + £150 + £800 + £600) / 10 people / 8 hours = £20 / hour.

  • Working hours

Using working hours to express these values and do not transform them into costs.

Moreover, a project will include several tasks and each task will have their own PV, AC and EV values. The initial state of these three values is zero. As the project progressed, they will keep accumulating and increasing.
The following figure shows four different situations of task completion:

PV-AC-EV

Four Measurement Value: CV, SV, CPI, SPI

These measurement indicators will predict the development trends of cost and schedule [4].

  • Cost Variance: CV = EV – AC
  • Schedule Variance: SV = EV – PV

If the result is zero, the progress will be completely consistent with the plan. The positive result indicates that the cost is under budget and the actual progress is ahead of schedule. The negative result indicates that the cost is over budget and actual progress is behind schedule.

  • Cost Performance Indicator: CPI = EV / AC
  • Schedule Performance Indicator: SPI = EV / PV

If the result is one, the progress will be completely consistent with the plan. If the value is greater than 1, then the cost will be under budget and the actual progress will be ahead of schedule. If the value is smaller than 1, then the cost will be over budget and the actual progress will be behind schedule.

In simple terms, the higher the numbers are, the better the results are.

For examples (still based on the felling story):
The PV, AC and EV have been figured out in the previous section. In detail, four days later, the three basic elements of the project are: PV = £800, AC = £300 and EV = £260. So, the four measurement indicators can be calculated:
CV = £‎260 – £‎300 = -£‎40
SV = £‎260 – £‎800 = -£‎540
CPI = £‎260 / £‎300 = 0.867
SPI = £‎260 / £‎800 = 0.325
Therefore, after four days, the project was over budget and seriously behind schedule.

Estimate At Completion (EAC)

Undoubtedly, every stakeholder wants to know the final cost of projects. EAC can predict the completion cost during the development process.

The estimation formulas of EAC are [4]:
EAC = AC + Future Cost
Future Cost = Unfinished Work / CPI
Unfinished Work = Budget at Completion (BAC) – EV
The formula simplification is:
EAC = AC + (BAC – EV) / CPI = AC + (BAC – EV) / (EV / AC) = BAC * AC / EV

Thus, if the current CPI can be kept, the project final cost will be as same as this EAC result. According to the CPI definition [5], managers should ensure that the CPI value is greater than or equal to 1.

For examples (again, the felling story):
After the first four days, AC = £300, EV = £260 and BAC = £800. So, the final cost of the project can be estimated: EAC = £800 * £300 / £260 = £923. Hence, this manager will face to the discontent of his boss owing to the additional cost.

Idealization situation

If the poor manager in the story knows the EVM method, he might predict the final situation before day 5 and discover an appropriate method of risk response.
Then, the ending of this story may be changed.
[DAY5] Firstly, let the woodcutter go home to take a rest. Secondly, looking for new employees. Thirdly, changing the project plan and adding an incentive method (if the daily progress of each worker is more than 80 trees, a £5 reward will be paid for every 10 additional trees).
[DAY6] Hired two new woodcutters, they worked 8 hours and cut down 240 trees. The additional bonus was £40.
[DAY7] They worked 8 hours and cut down 240 trees. The additional bonus was £40.
[DAY8] They worked 2 hours and cut down 60 trees.
[Final Result] The project was completed and it could be delivered to the customer two days before the deadline. The total cost of the project was £720, which was £80 lower than the budget.

Actual situation

The above discussion supports that EVM can digitize and visualize the project management. It will make every beginner extremely excited. Nevertheless, the actual result and the practical effect are quite hard to meet these positive ideas.

The common situations will be shown as follows.

  • Incorrect project planning or terrible project tracking

Numerous software projects not only forget to create the complete record, but also lack a detailed plan. That is why the three basic values (PV, AC and EV) cannot be counted. Thus, the project tracking might never achieve by using EVM.

  • Lacking an effective and simple method to collect the actual data

PV can be counted by using the ‘Microsoft Project’ and EV can be calculated by updating the progress record. However, AC will be really difficult to collect. Because the project members, such as programmers cannot easily complete the statistics of their actual work.

  • Software projects are special

Because the requirements of software projects are always changing, the project plan cannot be fully confirmed at the beginning and the PV value will often be adjusted. Moreover, AC and EV will also fluctuate frequently. So the measurement values (CV, SV, CPI, SPI and EAC) are uncertain. Consequently, the benefit of EVM is not obvious.

  • Additional workload

The project plan will include its development plan, coding plan, testing plan, training plan, etc. They will be responded by different employees. If the purpose is to track the PV, AC and EV values, first the managers have to unify and quantify them. Undoubtedly, it will bring a large number of additional workload.

  • Require professional knowledge of software engineering

EVM also requires some professional knowledge of software engineering. For instance, the manager needs to know the work breakdown structure (WBS) [7], which is a hierarchical breakdown structure of all tasks. In addition, the project main schedule (PMS)[8] will always be shown as a Gantt Chart, which relates to the task progress. However, most software companies will only focus on the coding ability of their programmers. This will increase the difficulty of software engineering management.

Make Earned Value Management useful and practical

Back to the fundamental question: why use EVM? The above discussion proves that the higher the measurement values are, the better the situations are. However, is it always positive when CPI and SPI around 100%? Is it always favorable when CV and SV greater than zero? In fact, these numbers cannot clarify all the issues. Although they might be positive and large, the project will still encounter several serious troubles. Such as its plan might miss a critical task and then the PV value will become meaningless. Actually, the purpose of EVM is to compare the plan and the implementation. So a useful EVM must require a correct project plan [6].

Therefore, the project success tends to be impacted by these main factors, which are the ability and the expertise of all members, the orderliness and the preciseness of whole project development, the complexity and the innovation of every requirement, etc. In particular, the essence of EVM is to understand the meaning of PV, AC and EV, rather than to pursue the precise values which are calculated by the mathematical formulas. EVM is not a mathematical game. All calculated values must be supported by numerous objective facts. Otherwise, unclear results are better than the accurate values and abstraction will be better than quantification.

In conclusion, based on the specificity of software project development, the three basic EVM elements can be summarized and analyzed as follows.

  • Planed Value
    Reducing the PV value is the most effective way of project success. Based on the requirements that are uncertain and changeable, design and coding progress cannot be clearly determined. Hence, every clever idea of the programmers will solve many problems and decreases the workload. Moreover, the usage of advanced tools, the reuse of software and the choice of correct programming language will also be helpful.
  • Actual Cost
    An efficient working state can reduce the AC values. It will be improved by using several methods, such as incentives, skill training, technical meeting, expert advice, etc.
  • Earned Value
    An obvious standard of every task completion will increase the EV values. So managers should break down the large task into several small tasks and try to avoid long duration tasks. Futhermore, the completion rate can be simplified into two states, namely, completed (EV = 100%) or not completed (EV = 0%).

To end with the same story

If the manager of the felling story can understand the real purpose of EVM, he could consider these issues at the start of the project.

  • How to reduce PV by using clever methods. (Use chainsaw as new tool)
  • How to decrease AC by improving the work efficiency. (Training in chainsaw usage)
  • How to improve EV by clearly defining the tasks in details. (Arrange daily task)

According to these considerations, the story will be changed like this:
[DAY1] Firstly, analyzing the project requirement and made a plan. Secondly, bought a chainsaw, which cost £80. Thirdly, hired a woodcutter then spent additional £20 for a two hours chainsaw training. Finally, arranged the daily task: cut down 100 trees in 6 hours. Daily result: task complete.
[DAY2] Daily task: cut down 200 trees in 8 hours. Daily result: task complete.
[DAY3] Customers changed their requirement, 200 additional trees had to cut down within the project duration. Daily task: cut down 220 trees in 8 hours. Daily result: task complete.
[DAY4] Daily task: cut down 240 trees in 8 hours. Daily result: task did not complete, the woodcutter cut down 220 trees.
[DAY5] Daily task: cut down 220 trees in 8 hours. Daily result: task complete.
[DAY6] Daily task: cut down 40 trees in 2 hours and then spent 6 hours to test the wood of 1000 trees. Daily result: task complete.
[Final Result] Although the requirement had been changed, the project still successfully completed in only 6 days, which meant that it could be delivered four days before the deadline. In addition, the total cost was: £10 * 8 hours * 6 days + £80 + £20 = £580, which was £420 lower than the budget.

Summary

As a consequence, according to this simple and funny felling story, which throughout the whole article. EVM has been obviously defined and analyzed. In short, EVM does not only represent the mathematical formulas and values, but also plays a distinguished role in project tracking. This article describes EVM by using a practical and comprehensive way, in order to give a positive feeling to all people who are interested in software engineering management. Without doubt, EVM is not complex, boring and useless. It is the method that can effectively track the progress of software development.

Bibliography

[1] R.A. Marshall, “The Contribution of Earned Value Management to Project Success on Contracted EffortsJ. Contract Management, pp. 21–33, Summer, 2007.
[2] Scheid, J. (2013), How Earned Value Management is Limited.
[3] JB Danforth Company Proprietary, Project Tracking and Control.
[4] Nagrecha, S. (March, 2002), “An introduction to Earned Value Analysis
[5] Dummies, Earned Value Management Terms and Formulas for Project Managers.
[6] Sulaiman, T. & Smits, H. (2007), Measuring Integrated Progress on Agile Software Development Projects.
[7] Office of Management, Budget and Evaluation (Jun, 2003), Work Breakdown Structure, Department of Energy, U.S.
[8] Glen, M. C. (1995),A GUIDE TO NETWORK ANALYSIS.