posted 09-18-2002 01:51 PM         

------------------

posted 09-19-2002 06:38 AM         

Performance_Engineering_Quick_Review.txt

I'll work on stripping the company proprietary stuff out of my strategy template for you. It might take a day or so depending on how my meeting goes in a few minutes.

posted 09-19-2002 12:07 PM         

When do you need Performance Testing in your project?
When the requirements for your project yield performance-related requirements, you should do a thorough risk analysis to fully understand the risks involved. Performance risks have a potential to seriously delay your project, impact your budget and create significant user dissatisfaction.

Experience and literature show a distinct number of performance-related factors that influence risk to your project, they are:
User count
Obviously, a large number of users will stress the available resources more than a small number. Experience learns us that unexpected results show up when a large group of users become active, system resources run out, network segments choke, servers crash, database contention becomes intolerable etc.
When reviewing the amount of users that the system is going to support, take into account that most systems are used continuously by a relative limited amount of users. Occasionally the systems will be used by a very large group of users (year-end, data entry etc.). Your system should always be able to support the peak usage.
Front Office/Back Office balance
If you work on a system that will support mainly front office type of activities (Talking on the phone with clients while working on their information), the response times of your activities are more critical than when your system supports back office type operations (printing, research etc.).
Throughput
If your system is required to be able to process a certain number of transactions per day/hour etc.
New Architecture/Technology
If you plan to use a new architecture for your system or you are planning to deploy new technology or technology components.
Even small changes to an architecture could trigger unexpected performance results. It is also important to ask the question if the technology and architecture is new for your team.
Team
If you work with designers/developers/contractors who have not been exposed before to the proposed architecture/technology, that is used in other places in your company, it will be a risk factor.
One-shot project
If you have to get your system right the first time.
Future Growth
If it is anticipated that the load your system has to support will grow from small to large.
Dependency on other systems and resources
If your system has to cooperate with other systems that are dependent on your system's performance. Or, if your system has to share resources (servers, network etc.) that have defined capacity limits.

Hope this helps.