Despite the risks, many companies do not have a formal release process. This article will guide you through some simple steps to verify your software prior to release.
IN THIS ISSUE
Risks sound like disasters, but risks are neither bad nor good. They are only smart or stupid. Stupid risks are chances taken without significant gain if you succeed. Smart risks are ones that will pay off handsomely if you can overcome them. Smart risks are taken by folks who have knowingly made the decision to proceed in the face of risk.
You've probably heard the question about noise in the forest: Does a tree falling in the forest make any noise if no one is there to hear it? Noel Nyman examines the question, "Is a bug a bug if no user can ever make it happen?"
Steve Whitchurch reviews the latest edition of Peopleware: Productive Projects and Teams, by Tom DeMarco and Tim Lister, describing it as a "must-read for all management wannabes, as well as those who are currently leading project teams and organizations."
Brian Marick points to Web resources and email lists that help keep you current with software and computing trends.
RSW Software’s e-Test Suite contains four main components. The reusable scripts recorded with RSW e-Tester (the functional testing tool) feed RSW e-Load (the performance and stress-testing tool). For reporting and analysis purposes, results gathered during performance testing feed to RSW e-Reporter. The final tool, RSW e-Monitor, is responsible for monitoring the status of Websites by sending periodic page requests and validating them against previously recorded results.
Using a sociological theory as his starting point, Technical Editor Brian Marick shows how sometimes systems can encourage local problems to blossom into system-wide catastrophes.
Building an integrated suite of applications can be complicated, especially when several groups are working on the project in different locations. Here are some risks, as well as recommendations for allowing planning, development, and testing artifacts to be shared between disparate groups.
A use case is a sequence of actions performed by a system, which combined together produce a result of value to a system user. Use cases describe the "process flows" through a system based on its actual likely use, so the test cases derived from use cases are most useful in uncovering defects in the process flows during real-world use of the system. Here is an example of how a use case is used to derive and prioritize test cases.
Why would you want to get published? Why take time out from doing real work to share your thoughts with others? After all, didn't we gladly leave writing behind when we got out of school? But when you share your experiences, you play a part in a larger picture, leaving your mark on the world, and advancing your field.
Improving customer satisfaction should be a primary goal of process improvement programs. So how satisfied are our customers? One of the best ways to find out is to ask them. Here are techniques for creating a useful survey and interpreting the results.
The chances of getting use from your ISO 9000 certification are greatly enhanced by a registration effort that reflects the real goals and operating principles of your organization. Here are some lessons on how to tailor your effort.
Managing your ERP Project