Software Engineering

Software Engineering Dr. Thomas E. Potok Adjunct Professor UT T. E. Potok - University of Tennessee

Putting it all together T. E. Potok - University of Tennessee

Look for Process Problems • Gather metrics on your software project • LOC per programmer per month • Simple metric to gather • Don’t use for evaluation • Gather in a spreadsheet • Use the metrics, or they are worthless • Periodically check for accuracy T. E. Potok - University of Tennessee

Example Roughly 20 KLOC produced in 12 months T. E. Potok - University of Tennessee

How to use metrics • To find problems with a process, you must measure it • From the measurements, you can then see problems • You can then use the measurements to see if you are fixing the problems T. E. Potok - University of Tennessee

Example T. E. Potok - University of Tennessee

Where is the problem? • Why is JGH producing far less code that his counterparts? • There may be some obvious reasons for this. • He may be the leader of the team and spends far less time writing code than his colleagues. • Or it could be that he is the main technical interface to the customer, • Or, it could be that he has a performance problem that needs to be addressed. T. E. Potok - University of Tennessee

Are there more problems? • You can spend a great deal of time analyzing this information, • for example, why did FEF produce nearly 1000 LOC more than QHR. • If you have information from several projects, and you really understand the way your team works, this can be very valuable T. E. Potok - University of Tennessee

Tracking Status • Suppose the project is expected to be 35 KLOC • The duration of the project is 18 months. • From the data that we have gathered, we can evaluate the status of the project • We can show the status by plotting the duration of the project vs the number of lines of code produced so far on the project. • Then we can estimate show much code we are likely to produce at the end of the project T. E. Potok - University of Tennessee

Project Status Example 35 KLOC in 18 Months 28 KLOC in 18 Months 20 KLOC in 12 Months T. E. Potok - University of Tennessee

Status • There are six months left in the project • So far, 20 KLOC has been produced in 12 months, leaving 15 KLOC to be produced in 6 months • At the current rate, the project requires roughly 5 KLOC of additional code • A reassessment of the project shows that 40 KLOC is needed, rather than 35. • What can be done to get this project on track T. E. Potok - University of Tennessee

Options • Extend the schedule: • It took 12 months to produce about 20K, • therefore it is a safe bet that in 6 months the team can produce 10 KLOC. • So rather than taking 18 months, the project will now take 24 months. T. E. Potok - University of Tennessee

Add People • Lets say that a new programmer can produce about 250 per month once trained on the new project. • Let’s further say it takes a month for the new programmers to get up to speed. • Now the only people qualified to train the new team members are the members of the existing team. • So you will get little to no code produced during the month used to train the new members, leaving you five months, rather than six, to produce 20 KLOC. T. E. Potok - University of Tennessee

Add People • Going back to productivity equations we can determine the number of programmers needed: • We would need to have 16 programmers working for 5 months producing 250 LOC per month, adding 11 programmers • Maybe you get lucky and find 11 programmers looking for a short-term project. • Not to mention that 11 programmers for 5 months is quite a large cost overrun. T. E. Potok - University of Tennessee

Drop Functionality • Evaluate the functions that will be offered by your software project, • Reduce this functionality until you have reached approximately 10KLOC. • This will help you meet your deadlines, but your customers may not be satisfied with the results that you produce. T. E. Potok - University of Tennessee

Step up the Pace • Layout for the team: • They are slackers, • The company’s honor is at stake, • they all will be fired unless they hit the deadline with at least 40 KLOC. • You can enforce • mandatory overtime, • work on weekends, and • promise big bonuses if the goal is met. • You may be able to pull this off, but you may kill moral on your team, and may produce poor quality code. T. E. Potok - University of Tennessee

Start over • You have had a year to work on the project. • Most likely you now know how the project should be developed. • If you throw out what you have done, and start over, you will now be able to develop the project much faster and cheaper. • One big problem with this approach is convincing someone that you have not squandered a year’s worth of funding. T. E. Potok - University of Tennessee

Don’t Worry, Be Happy • Ignore it, maybe it will fit itself • This is the most common and the easiest approach to the problem. • Just continue along, nervously ask the team if they are going to make it. • The team lead will tell you it will be tight, but they will make it. • The lead programmer will tell you that there is no way, but no one listens to him anyway. • Maybe you will get lucky and the team will pull it out, or maybe you will not be so lucky. T. E. Potok - University of Tennessee

So What to do? • Extending the schedule is usually not an option. • There are many software producers and if you cannot produce on schedule then someone else will. • This is the same with dropping functionality. • It is very difficult to drop functions that a customer has requested. • It may be that you can drop some very low priority functions that perhaps the customer has not requested. T. E. Potok - University of Tennessee

So What to do? • Redesigning the project is always a very tough sale. • Why would some one pay you to redo a project that you have just blown? • Ignoring the problem and hoping that it goes away is totally irresponsible. • In most cases you will come to the end of the project over budget, under function, and behind schedule. • Your only recourse is throw yourself at the mercy of your customer and management. T. E. Potok - University of Tennessee

Recommendation • Consider adding people to a project. There are some very general components that an average programmer can assist with. • Access to a database, • Graphical-user-interface • Create web access. • Most programmers can perform these tasks with little knowledge of the general problem being solved. • The biggest problem with adding people to a project is determining who will pay for the additional cost. T. E. Potok - University of Tennessee

More Recommendations • Browbeating the team to produce at double the rate they are currently producing is not a very attractive option, but it is an option. • It does have some advantages, • such as no additional cost, • if successful, it will meet the original function and schedule. • The real key to this decision is whether the team is capable of producing at this rate. T. E. Potok - University of Tennessee

Team Productivity • Can the team double its productivity? • This is a fairly subjective evaluation that requires a very good understanding of the capabilities of the members of the team. • For example, the team may currently be producing at only 30% of its maximum capacity, therefore, a significant increase in productivity is certainly possible. • Of course there is the obvious question of why they are producing at such a low rate? T. E. Potok - University of Tennessee

How to proceed • See if the team is up for the challenge. • If so, then put a contingency plan of adding people if they could not meet the challenge. • If the team is not up to it, then • add people, • tell management and the customer that we are having difficulties, but we think we can contain them. • Schedule regular status meetings, so that the customer is well aware of the progress, • Let the customer to know that we are working hard to fix the problems T. E. Potok - University of Tennessee

A Better Solution • Focus on long-range planning, rather than mid-course corrections. • Gather metrics • Analyze information • Make appropriate changes T. E. Potok - University of Tennessee

Example • Only two metrics recorded for the entire projects • Total Lines of Code • Total number of Person Years T. E. Potok - University of Tennessee

Graph of the results T. E. Potok - University of Tennessee

Analysis • The project represented by the hollow square • Produced 45.2 KLOC • By the equivalent of 22.7 people in one year, • Roughly 166 LOC per person-month. • The hollow circle project • Produced 12 KLOC • With 26 person-years of effort, • A dismal 38 LOC per programmer-month. T. E. Potok - University of Tennessee

More Analysis • These two projects show that teams within this organization are capable of producing within a broad productivity range well below the national average. • To arbitrarily choose a productivity rate of 250 LOC per person-month will most likely result in missed schedules. • It could be that choosing a rate of 166 LOC per person-month might be too high as well, since this rate is high as compared to other projects. T. E. Potok - University of Tennessee

Back to the example • If a team is going to be producing 30 KLOC, the projection line above provides an estimate how much effort will be required. • The natural log of 30 KLOC is 3.4 KLOC which maps to roughly 2.6 ln(effort). • This is easily converted to exp(2.6) which equals roughly 13.5 person-years, or 162 programmer-months. • If you spread this effort over 18 months, (i.e., 162 Programmer-months/18 months) this gives a need for an average of 9 programmers on the team. • The current team has an average of 7 programmers, which according to our model will not be enough. T. E. Potok - University of Tennessee

Summary • Metrics are essential • Example of how to analyze and fix problems • Midcourse corrections are difficult • Long range planning is a better options T. E. Potok - University of Tennessee

Software Engineering