This Executive Report provides practical advice on how to prepare your organization to take advantage of future changes in software. The software industry has been and will continue to be buffeted by fads and hyped information in addition to truly transformative technology.

The accompanying Executive Report provides practical advice on how to prepare your organization to take advantage of future changes in software. The software industry has been and will continue to be buffeted by fads and hyped information in addition to transformative technology.

If there is one group of people within your IT department that truly deserves respect, it is the one that performs the job of legacy data integration. Legacy data integration is a critical component of your enterprise application integration (EAI) efforts -- one that your organization must master if it is to succeed.

Every large company has hundreds of applications that were developed to solve one problem and are being used today for vastly different purposes. There's the accounting system that was designed to update customer accounts and generate statements that's now being used to provide online customers with information about their account balances.

It has become fashionable to design and develop business systems by starting in the middle, with the latest technological or e-commerce fads, which, supposedly, can solve most business problems.

Business intelligence (BI) decision-support initiatives are expensive cross-organizational endeavors. These initiatives involve extracting and merging disparate business data from online transaction processing systems, from batch systems, and from externally syndicated data sources.

Developing business intelligence (BI) decision-support applications is quite different than developing operational systems or even traditional decision-support systems. BI projects must deal with new tasks, technologies, tools, database designs, and integration requirements.

Business intelligence (BI) software can prevent your company from suffering the next Enron-like meltdown. BI software can even improve homeland security -- at least this is what some vendors' marketing claims purport.

Testing is an activity that we undertake to prove, at a minimum, that we are getting the functionality we expect and, ideally, that the application is robust. The more we test, the more we reduce the risk that the system will produce erroneous results or fail. But the risks we mitigate through testing are not the only risks we face when developing a new system.

Testing is an activity that we undertake to prove, at a minimum, that we are getting the functionality we expect and, ideally, that the application is robust. The more we test, the more we reduce the risk that the system will produce erroneous results or fail. But the risks we mitigate through testing are not the only risks we face when developing a new system.

Testing is an activity that we undertake to prove, at a minimum, that we are getting the functionality we expect and, ideally, that the application is robust. The more we test, the more we reduce the risk that the system will produce erroneous results or fail. But the risks we mitigate through testing are not the only risks we face when developing a new system.

Testing decisions always require tradeoffs between quality and cost. While additional testing increases software quality by reducing the likelihood of failure during operation, testing can be expensive. Test planning, execution, analysis, and correction add time and cost to any software project.

Testing decisions always require tradeoffs between quality and cost. While additional testing increases software quality by reducing the likelihood of failure during operation, testing can be expensive. Test planning, execution, analysis, and correction add time and cost to any software project.

Here are three hard-to-accept realities that you're probably trying to cope with:

Projects begin with high hopes and dreams, which gradually fade away as the quality of the software decays. This process cannot be inevitable. Where, how, when, and by whom should testing happen so we can feel better about a system after a year rather than after a month, and better yet after a decade?

Delivering software to specification and free of major defects has, I dare say, been a dicey endeavor for nearly as long as there has been software to deliver.

Testing is an incredibly important part of any software methodology, agile or otherwise. Experience shows that testing early in development reduces the cost of fixing errors [13] because the problem isn't given the opportunity to snowball out of control.

For corporate IT departments, pressure to cut costs and improve performance has never been greater.

For corporate IT departments, pressure to cut costs and improve performance has never been greater. In most IT shops, development and support of internally developed systems account for at least half of all costs, while new projects have long wait and delivery times. The most immediate pressure is to reduce these delivery times and, if possible, the associated costs.

Is there a single action that could virtually guarantee improvement of software estimation? Well, you might say, if you knew of one, you would have implemented it already. But what if the answer were making software projects smaller and simpler? Undoubtedly, estimating a small project is easier than estimating a large one.