Deb Dorman (deborah_dorman@mail.amsinc.com)

Lorrie Boyd (lorrie_boyd@mail.amsinc.com)

Introduction

This paper discusses predicting the affects of change, which is specifically a problem with Business Transaction Processing Systems (BTPS. First we discuss the characteristics of BTPS systems themselves in three areas: the business use of the systems, the size of the systems, and the demographics of the team developing the systems. Then we present the problem, predicting the affects of change, and discuss it. While there are ways to address some of the issues in this problem, no one solution seems to provide the whole answer. Finally, we present biographies of the authors.

Characterize business transaction processing systems (BTPS)

Business use of the systems

These systems are used to manage daily operations of a business. As such, they are very high volume, and high access with multiple users. Thousands of transactions will need to be processed per day, with many people updating similar data, and with demands for constant system availability. In addition, the daily operations of a business represent interrelated functions where pieces of the system have complex consequences outside their own boundary.

For example, the authors recently developed an object oriented system which automated maintenance management, purchasing, inventory, payroll processing and contradictory union pay rules, space management and capital projects. This system was used by architects, mechanics, accountants and managers and was the primary support for a major development and maintenance organization. Another system the authors also developed manages the worldwide borrowing and lending of securities, including calculating commissions and fees on all transactions, and maintaining complex business processing rules to determine which accounts are used for loan transactions.

Size of the systems

The systems the authors are describing are just plain big. For example, the following characteristics are specific to the systems described above, as well as most large scale BTPS:

• 300 - 500 tables in a relational database (the majority of complex BTPS do not use object-based databases due to their level of maturity as compared to relational databases);
• 400 - 500 application infrastructure classes;
• 450 - 650 business model classes, each an average of 3 - 4 classes deep in a hierarchy;
• 100 - 200 screens (each of which is made up of 1 - 5 view classes depending on the complexity of the screen and the level of reuse achieved in the system);
• 10 - 20 interfaces with other systems usually running on different platforms.

Demographics of the team

These huge and complex systems are developed by bright, young, inexperienced teams. New development and object oriented development attracts the brightest and the eagerest programmers, with most of the team being just out of school and having no extensive programming experience. The average age is usually in the early 20s. The project manager, lead architect, and lead developer may have one, or in rare cases, two prior similar implementations, but the bulk of the team will be new to this kind of system.

This has accountability consequences. Young programmers tend to consider programming fun rather than challenging, scientific work. When problems arise, their mentality is to find a quick solution so they can move on, with little regard to elegance or robustness. They are frustrated by recurring problems because they have not yet learned how to diagnose and fix them. Nor have they learned that many times, recurrent problems are symptoms of a much larger problem. Compounding this is the relative ease of use of programming languages today which lends itself nicely to many programmers coming from entirely non-technical backgrounds. This breed of programmers does not understand how computers work or how computer programs work, and while many of them are brilliant analysts, they may not have the capacity for understanding computer science.

For example, on both systems referenced above, the average team age was 23. Only about 1/4 of the development team had a background in computer science; an additional 1/4 had a background in another technical discipline, leaving half the team with no technical background whatsoever.

Describe a particular BTPS problem you do not know how to solve and give a detailed example

Problem Statement: Predicting affects of changes.

Problem Description

In object development, changes to objects are rarely independent. Changes to parent objects may ripple to any objects lower in the hierarchy, depending on how the lower objects use inheritance. Changes in message use or protocol affect both the sender and the receiver. Completing a given task generally invokes a chain of messages involving numerous objects. In addition, one of the first things we learn when studying objets is to maximize reuse.

With such an interrelated structure, it is difficult to predict the affects of changes. Problems in reused objects ripple. Using a common object incorrectly or in a new way can have unpredictable consequences. Fixing a bug by changing code at any level of the inheritance hierarchy may have unrelated affects in unexpected places. This ripple affect is most destructive when these changes are made at or near the top of the inheritance hierarchy.

This is further complicated by the inexperience which characterizes OO development teams. Most object teams attract bright, inexperienced programmers. These people are terrific at using computers; they grew up playing games on computers. Yet, they are undisciplined and naïve. They expect programming to be easy and have not experienced the discipline of a large interrelated team.

How do you predict the ripple affects of changes? How do you ensure you have tested thoroughly so as to catch any unexpected ripple effects? How do you discipline a young team to manage the affects of changes?

Forces

• Bright, inexperienced programmers using OO tools develop code very, very quickly
• Careless changes in a large OO system can cause unpredictable and surprising problems elsewhere
• Testing must evaluate all aspects of the system which have changed. If these cannot be predicted, the testing cannot be effective.
• Even the best design documentation will miss a message or two, or will not be kept up to date. Often, there is scant design documentation since the eager team thinks they can just start coding. It is difficult to know exactly what is affected by every line of code in a large system.

Example

During the system test phase of a major OO development, new test releases were created twice a week. Initially, new releases completely failed with frequency. The affects of changes in the release could not be predicted. Therefore, the test team implemented a standard procedure to first regression test all basic transactions to validate any new release. This meant that with each new release, the test team spent approximately 16 person-hours testing basic functions which may not have been changed with the release, such as adding a new employee, to verify that the basic functions worked. When the basic functions did not work, testing halted until the ripple affects could be fixed.

On a second large scale OO development project, it was determined that one of the core objects (i.e., an object with which almost all other objects interact, but did not inherit from) needed to be completely restructured. The changes were so major that it did not make sense to continue coding several other parts of the system until the changes were complete. We did not have the time to determine which errors were caused by the ripple affect of changing the core object and which ones were caused by the 'local' code changes. Work which might have been unrelated halted since ripple affects of change could not be predicted.

Solution

While there are ways to address some of the issues discussed above, no one solution seems to provide the whole answer.

We have implemented the following approaches in an attempt to solve this problem. None are complete. We hope the OOPSLA workshop can provide a more in depth answer.

• Automate basic regression tests. Always include a test suite of basic tests before each new image.
• Focus your team so that one person works exclusively in one area. Then, most of the consequences should stay within that person's own code, and human nature will force discipline.
• Do as detailed a design as you possibly can.
• Establish accountability all the way up the team structure to focus on quality.

Author's background

The authors are consultants and developers of Business Transaction Processing Systems. Ms. Dorman has 10 years experience and has led teams in implementing systems ranging from satellite systems to banking systems. She is currently the development manager on a dental management system to be implemented across the country. Ms. Boyd has over 20 years experience as system architect in business systems ranging from maintenance to telecommunications. She is currently mentoring several OO and new development projects.