# Presentation: 287382

## Software Engineering

- Dr. Thomas E. Potok
- Adjunct Professor UT
- Research Staff Member ORNL

## Agenda	

- Project review
- More on risk management

## More on Risk

- Software development methodologies that deal with risk
- Spiral model directly
- Iterative model indirectly

## When do you focus on risk?

- First the nature of the project dictates the level of risk management necessary
- If the project has challenging requirements
- Safety
- Performance
- Complexity
- Size
- A simple small project may not need much risk management

## When to focus on risk

- Next, are development concerns
- Do you have the right people
- Can you do the work within schedule and budget
- Is the problem well understood
- You may have a small simple project that your team is incapable of developing

## Methods for assessing risk

- Understanding the requirements
- Are there high-risk requirements that are not stated
- Example
- “We just need a simple accounting system developed”
- “Oh yeah, it will be used in court to prove fraud”

## Selecting a methodology

- Spiral
- Driven by risk
- However, it can be expensive
- Iterative
- Perform small parts to the project
- Rework levels may be high

## Work scheduling

- Schedule the most complex problems early
- Finding a fatal error early in the project saves a great deal of time and effort
- Finding a fatal error at the end of a project is a disaster
- Use prototypes where necessary
- Use expert assistance where necessary

## Use proper teams

- Keep teams small
- Large teams need higher levels of communication
- Communicating complex ideas is difficult
- Use established, well working teams
- Time and effort is needed on the project, not in team building

## Design

- Keep is simple
- If the design has to be complex
- Use state-transition diagrams
- Use design reviews
- Use prototyping

## Proper focus

- Don’t optimize for performance if performance in not an issue
- An array is far easier than a linked list
- Don’t optimize for space, if you do not have space limitations
- An array is much easier than a hash table
- Don’t optimize for fault tolerance, if you do not have fault tolerance problems
- Optimize on a simple, easy to understand solution
- Unnecessarily complex solutions raise the likelihood of project failure

## Coding Risks

- Make sure the language used in known by the other team members
- Is stable, and able to perform the needed functionality
- Netscape and Java
- Is available to the customer
- Performs adequately

## Common Problems

- System developed on a Unix platform, that does not work well on Windows
- A new component is developed in C, yet the rest of the system has been written in COBOL
- A graphics library is written using Java 1.0, but does not work with Java 1.1 without a major rewrite.

## Management Risks

- A difficult problem
- Management has over committed a project, or people
- Management does not understand the project risks
- Management is inexperienced in leading a project

## Some Help

- A key problem is misunderstanding
- Challenger disaster can be traced to poor communication to management
- Clearly state the problem as if speaking with a non-technical person, with detailed background
- State the risks in terms of dollars and cents

## More help

- Offer to help the manager in weak areas
- Do some of the project estimating and planning
- Do the risk analysis on the project
- View yourself as a project asset
- Meet one-on-one with your manager to provide your input
- Avoid correction or challenges in public meetings.
- If you are not successful, change projects

## Example

- Typical interaction
- Programmer to manager: “We can’t do the project because the interface is broken!”
- Manager to programmer: “You need to be creative, clearly there is an answer”
- Programmer to programmer: “Our manager is an idiot”
- Manager to manager: “Our programmers are lazy and looking for easy outs”

## Example

- Better interaction
- Programmer to manager: “The AMI project is fairly easy, however, the information in their database does not match at all with we need. I have spend a few days researching the best possible approaches, and I don’t see a good solution. I think the entire project may be unachievable. Would you like me to put together a presentation to better explain this problem?”
- Manager to programmer: “Yes, I would like to see that immediately. If we have a problem, I need to know right away.”

## Example

- Better interaction continued...
- Programmer to programmer: “Our manager wants a presentation on how fouled up the foundation database is, I will need some help”
- Manager to manager: “I think one of our programmers has found a serous problem, do we have any database experts that can help?”

## Use the management chain

- You clearly state the problem, and your management ignores the problem
- Talk with your peers, and advisors
- If you know you are right
- Ask your manager if you could talk with his or her manager
- Make sure your case is clear and compelling

## Last resort

- You believe that the challenger will explode
- People will be killed
- The space program will be crippled for years
- What do you do?
- Write a tersely worded memo to your manager?
- Leave a voice mail with your manager’s manager?
- Call the president of the company?
- Call the president, the news papers, the TV stations?
- If you know disaster is coming, and you don’t do everything within your power to prevent it, _you have failed_

## The big picture

- Gather requirements
- Look for high risk items
- Look at complexity
- Generate project size estimates
- Evaluate ability to produce code to meet the users needs
- Are the requirements clear, understood, and doable?
- Can the project be done for a reasonable price?
- Are the requirements going to be shifting or changing?
- Do you have the proper resources?

## The big picture

- Develop a project plans
- Is the plan doable based on history (productivity rates, COCOMO values, expert opinion)
- Is the development environment suitable for the project (Unix development for a windows project)
- Are the external commitments reasonable
- Is the team suitable for the task
- Select a methodology
- Not necessary one that is familiar, but one suited for the environment

## The big picture

- Develop a design
- Avoid unnecessary complexity
- Avoid gold plating
- Prototype, review, and model complex designs
- Develop the code
- Select an appropriate language
- Review and test complex code

## The big picture

- Be prepared to cancel the project if the risks outweigh the benefits!
- Report potential problems early, and with proposed solutions.
- Management is far more receptive to early options, than late excuses
- Never sugar coat potential problems!

## Summary

- Understanding the risks associated with a project is essential to the success of a project
- The more aspects of  a project that are not understood, the higher the chance that blind luck with guide the project