# Presentation: 168297

## Software Engineering

- Dr. Thomas E. Potok
- Adjunct Professor UT

## Putting it all together

## 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

## Example

- Roughly 20 KLOC produced in 12 months

## 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

## Example

## 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.

## 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

## 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

## Project Status Example

**35 KLOC in 18 Months**

**20 KLOC in 12 Months**

**28 KLOC in 18 Months**

## 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

## 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.

## 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.

## 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.

## 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.

## 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.

## 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.

## 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.

## 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.

## 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.

## 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.

## 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.

## 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?

## 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

## A Better Solution

- Focus on long-range planning, rather than mid-course corrections.
- Gather metrics
- Analyze information
- Make appropriate changes

## Example

- Only two metrics recorded for the entire projects
- Total Lines of Code
- Total number of Person Years

## Graph of the results

## 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.

## 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.

## 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.

## Summary

- Metrics are essential
- Example of how to analyze and fix problems
- Midcourse corrections are difficult
- Long range planning is a better options