Case Study: A Telephone Switching System [G7.2.1] zProblem: A big telecommunications company wishes to upgrade their existing telephone switching system to double its existing capacity while maintaining the same level of reliability.

Telephone Switching System (continued) zScenario: The existing system was created by one electrical engineer and developed by him and two other engineers in assembly language for an Intel When launched the system contained 50,000 lines of assembly code. It was being maintained by 30 software engineers. The three original developers were still with the company and were the main source of information about the system.

Questions About the Telephone Switching System zWhat are the limitations of the existing system? zHow would you go about upgrading the system to double its capacity?

Limitations of Existing System zThe processor can no longer cope with the future CPU demands in telephone switching. However, a change in processors (say to a Pentium) implies a substantial rewrite of the assembly language program. zAdvanced routing algorithms normally require the use of sophisticated dynamic data structures which cannot be easily programmed in assembly code.

Limitations of Existing System (continued) zSupport of recent programming techniques, such as inheritance and information hiding, are not supported in 8080 assembler. A 50,000 line assembly language program without much program is costly to maintain (30 full time software engineers…) zMaintenance is very dependent on the three original engineers zThere is a high overhead in training new staff. Almost no fresh CS graduates have incentive to learn Intel 8080 assembly code. However, using a different computer platform involves retraining current staff.

What Actually Happened zThe development of the new system followed a waterfall life cycle. zThere was a trivial requirements study phase, specifying the required increase in capacity. The three original engineers did a feasibility study and design for the new system. yNew hardware platform, but used much of the original system structure (subsystems and their functionality)

What Actually Happened (continued) zA simulator of the new hardware was built and used extensively in the feasibility study and module development. zAlthough many defects were found during integration and testing, they were all local to individual subsystems. Since no major design errors were encountered, the development cycle was fairly linear. zThe system was quite successful.

More Questions about the Telephone Switching System zWhat factors were important in the success of this project? zWhat are the major problems with the new system? zIs it possible to plan for the retirement of a system during its planning stages? zHow could the telephone switching system have done this? zWhat would be the benefits of such a plan?

Case Study: A Budget Control System [G7.2.2] zProblem: Build a software system for a small, high-tech software consulting and development company that monitors whether the financial transactions involved in the various software projects are proceeding according to the original budgets.

Budget Control System (continued) zScenario: The budget control activity often needs to be customized to the particular activity of an organization. While the budget control activity is related to other administrative activities (like payroll), unlike these, budget control is based on both objective data, such as time and cost, and on subjective data, such as estimates of the value of work in progress. Since staff may be on several projects at once its hard to assign costs to each project.

Questions about the Budget Control System zHow would you approach this problem? For example, what kind of software engineering paradigm would you use to develop the system? zCan you guess what actually happened?

What Actually Happened zA team consisting of a software engineer and a senior administrator was formed to perform feasibility analysis of the system. zBecause of the nature of the business, it was found that a precise statement of the requirements for an automated budget control system could not be formulated. Such a statement could only be reached after some experience, trial, and error.

What Actually Happened (continued) zThe team decided to employ the prototyping paradigm to develop the budget control system. Initially it focused on organizational rather than technical aspects: yidentified information relevant to budget control and its source ydefined procedures for collecting this information (e.g., staff were asked to record the time the spent on each project).

What Actually Happened (continued again) zTwo months were needed to understand the budget control process well enough so a prototype could be implemented. The prototype used a spreadsheet and manual data entry. zThe first prototype was in operation for four months. During that period, it was used to understand the problems of budget control and design solutions that would yield better support tools.

What Actually Happened (one last time) zThen a second prototype was built on using a fourth generation environment that supported high-level query facilities, flexible data formats, and simple computation. zWhen the system was put into production, two independent systems existed; the existing administrative system (on a minicomputer) and the new budget control prototype (on a PC). The administrative system provided partial information to the budget control system.

More Questions about Budget Control zWould you do anything differently? zIf you were doing a budget control system for a large company would you do anything differently?