15. Selecting Development Procedures
(c) Copyright Custom Decision Support, Inc. (2001, 2002)
The Information Systems function policies must include the desired methods of system development. This is a critical part of the overall operational plan for the IS function. The following notes discuss the issues in selecting and managing software and systems development programs. It is intended to review the underlying issues. Further discussion of the process and methods can be found in standard Information Systems Management reference books.
Project management procedures are selected to provide assure the firm that the development of the systems will not only meet objectives but do so in an acceptable manner and produce the desired results.
Assuring that the resulting system provides value to the organization is the critical consideration for development procedures. This is often not obvious to the developers in general and the Information Systems staff in particular. Almost all systems need to be integrated into existing organizations with specific established procedures and outputs. The initial specifications usually do not consider the full range of these issues. The development methodology needs to fold in these considerations to assure value-added. The trick is assigning that responsibility.
Costs are always a key consideration in developing procedures. A goal, clearly, is to reduce the cost of development. However, cost reduction should not come at the price of reduce quality. This is a control issue to provide a cost-effective method to develop the system. Here we sometimes have to balance cost and timing.
Control of information and hardware system implies responsibility for maintenance and support. Tight systems control assures the compatibility and consistency. While "senseless consistency may be the Hob-Goblins of small minds," consistency in itself has value in information systems by reducing the need for duplication and assure availability across systems.
Typically, cost is related to time for development. Efficiency relates to both cost reduction but also to timing. Total costs typically increase with the time for development. This includes increased costs for the development but also the lost opportunity to use the resulting system.
A key value of a defined development methodology is to assure that control measures are enforced. Costs and programs need to be kept under-control and run-away cost -escalation prevented. In order to assure this type of control, the process, itself, must be secured. For some methodologies this is easy to secure and therefore, easier to provide management reassurance of cost control. Other, however, are not.
The process of systems development can be thought of as a seven-stage process running from initial analysis through maintenance. While it is convenient to discuss this process as sequential and linear, in reality steps are often done simultaneous and iteratively. How these process stages are carried out is determined by the process methods selected. It should be noted that all seven stages need not be carried out by the same resources. Some stages may be carried out internally while others are out-sourced.
Typically, the objectives and goals of a system must be described in terms of the benefits and functions expected by the users and clients of the future system. These are referred to as the specifications. These may be described technically but usually as a function. For example, the system must provide this or that capabilities; obtain data from the existing databases and run on the existing facilities.
This, often general, specifications set the needs of the system but rarely do they cover the full range technical issues that need to be determined. The system requirements represent the technical description of what the system needs to do and how it must be constrained. They are the technicians' view of the end-point specifications of the system.
The purposes of the analysis phase of the development process are to:
1. Develop and write clear and extensive requirements for the system based on the specifications and the existing constraints;
2. Scope-out the resource requirements for building or buying the appropriate system;
3. Usually, the selection of development tools and languages is included; and
4. Estimate the cost, resources and timing for the development system.
The results of the analysis phase should be an outline of the requirements for the future system. During the design phase, that outline is filled in with the specific programming details. Depending on the specific tools that will be used, this can involve general data-flow or specific programming algorithms and input/output diagrams. In particular, file structures need to be specified and checked at this stage. This is the world of data-dictionaries, data entity and data-flow diagrams. It should be noted that data requirements need to be set at this stage.
Implementation is the world of installation of software and programming. In this stage, the design is converted to an operating system. While we often think about the programming issues, far more effort in often required in the preparation and conversion of data for the new application. It is not unusual for data preparation to be far more expensive and time consuming than the programming process. Operational and internal documentation is usual prepared during this phase and is often necessary for completion of the project where a large number of developers/ programmers are involved.
Testing must be as extensive as needed. Typically, there are three stages of testing:
1. Internal or micro testing focuses on the operations of each of the sub-components of the systems. This is called functional testing and usually is limited to the operation of particular links of algorithms in the system.
2. "Alpha" testing focuses on the uses of the total system or major components by internal testers acting as users. This is often done by the programmers and future systems administrators. It usually focuses on meeting system requirements.
3. "Beta" testing involves actual users in testing the system. The focus of this testing should be on ease of use and the fulfillment of the users expectations. Systems are often not fully functional when beta testing starts. However, they should be fully functional by the end of the process giving Beta testers sufficient time to examine the future released version of the system on actual data.
It must be noted that failure to fully test systems is usually the contributing cause of failure and disappointing results. During this stage user documentation and tutorials are usually prepared. Both the program and the documentation need to be reviewed usually by Beta testers.
During the roll-out stage the system is made operational. This can be a fairly long process with concurrent operation of legacy systems. The roll-out process may also be regional and along functional groups. In large firms, the roll-out process often starts with a small test organization and is only rolled out to the rest of the organization when it is proved successful in the small test group. The roll-out process usually also contains initial training and support.
While it is assumed that the Beta testing process will show up all problems, it rarely does. For the most part the Beta testers are heavy, power, users not the typical user of the system. Problems generally arise from miss-understandings between in the specifications and the requirements. Needed facilities almost always arise. A difficulty with this is control of costs against what the Information Systems development people would refer to as "requirements creep." However, it is often the failure in analysis to understand the scope of the needs of the users that give rise to these problems.
In addition to handling the refitting issues of the system, the users often need continuing training, particularly in respect to the unesolved issues. User documentation and tutorial are usually refined during this stage.
The final stage of the development process is maintenance and support. While this is often considered outside the development process, its planning is critical for the successful adoption of the system. System maintenance typically focuses on the continuation of the usefulness of the system. Often changes in users and platforms require modification of the applications. There is generally a need for expanding files and databases as well as maintaining compatibility with new capabilities.
Finally, there is almost always changes and addition to the database and the training of new users that fall under the support requirements. Often the Maintenance and Support functions are undertaken by a different staff than the other stages in the process. As such, it is necessary that a procedure of transfer is developed, funded and carefully undertaken.
Each actual procedure for developing software tends to be unique with specific control rules and policies. However, there are a number of general development methods, which have been proposed as archetypes for these processes. Below are six general processes that are both used as such, and are models for other mixed methods.
The "Water Fall" method is the traditional procedure for major Information software systems development. It consists of separating and limiting client approval to the initial stages of a strictly linear development process. The IS function develops the requirements but the client is required to approve. Final consent is then required immediately before roll-out based on meeting the requirements. All responsibility for the systems value added is, therefore, with the client. The IS function responsibility is only in meeting the requirements for the system at the agreed upon price and timing.
The "Water Fall" method grew out of the need to build complex accounting and financial control systems. The responsibility that the systems perform the required tasks clearly still rests on the developers. However, the value of the resulting system is in the hands of the financial function, which must attest to the validity the resulting computations.
Control of the process and the resulting system, including maintenance of the system, but not the data is fully in the hands of IS. Because of the linear nature of the process and the initial approval of the requirements, this process is the simplest to manage and should be the most economical. It should be noted that due to the high degree of control in the process, it is very compatible with the desired operational functions of accounting and finance. It's greatest weakness takes place when the specifications and requirements are not fully identified during the initial analysis. Failure in the early stage to fully appreciate the environment and needs for the system can easily result in a useless exercise in misunderstanding and wasted resources.
The "Spiral" method is designed to increase client control of the process and to assure that the resulting system provides value-added. In this method, the process of systems development is divided into multiple stages, each of which must be approved by the client. This process focuses on periodic review of the requirements and design to enable changes and inclusions in the system prior to its completion. However, the basic structure is still linear and similar to the "Water Fall" method.
It is assumed, in both methods that the final system can be designed directly from the analysis phase without major modifications. The changes instituted by the Spiral method reviews are expected to be minor but important changes. The danger, of course, is introducing requirement or feature "creep." Given the opportunity, organizations will normally find additional things and capabilities that are desirable in a system. This enviably results in increase cost and delayed systems. But also provides a means of early cancellation of projects before major costs are incurred. Furthermore, with multiple reviews, there is greatly likelihood that the final result will not have fatal flaws. This method is particularly useful for multi-year programs where staff and management may change several times during the development process.
"I know it, when I see it" is the center focus of the "Prototyping" method. This approach is theoretically characterized by two major phases: (1) the development of a series of prototypes systems, and (2) the development of the final system based on the properties and requirements of the final prototype. The purpose of the prototypes is to demonstrate the characteristics of a functional system in such a way as to help client identify the needed specifications. The development of prototypes is usually a team effort with the client working closely with the developer in build alternative approaches.
This method is particularly useful when the design of the user interface is critical for providing value of the resulting system. Value-added responsibility is shared between the developer and the client. While the ultimate goal is to develop a final fully functional and documented system based on the prototype, often the final prototype is adopted as the final system. This results in systems, which are poorly documented and often operationally inefficient.
In many cases, the systems development involves installing a general application package and then modifying it for the specific needs of the client. This has become a standard procedure with large Enterprise Data Systems such as SAP.
This process is often split into the decision to use the general application package and then a semi-independent process of designing and implementing modifications to make it perform adequately. For large scale programs, the acquisition authority exists outside of IS, often with senior management. However, in almost all cases, IS acts as the advocate for the adoption and general gives technical approval. The fixing stage, however, can follow any of the other processes but is often handled as a "panic" operation of "getting things to work." Because of the high level authority in acquisition, it is often difficult to assign responsibility of assuring value-added.
Many systems are build by developer-clients locally. These are often not fully designed but build out of separate pieces and assemble and fixed. This is an engineering approach and is well suited for small systems with limited application span and life. Value-added responsibility and process and systems control are typically held locally. While these systems are viewed as being developed by a single user-developer, in reality, development is often a team activity. Usually a general prototyping approach is used with a designer/programmer building the system and user or gate-keeper helping to redefine it. As with the initial development, maintenance and changes (fixes) are done locally without center IS support.
Process reengineering focuses on the identification of value. The underlying idea is to change the work process in such a way as to maximize the value usually in the form of reduced costs. Traditionally, this has been an engineering function with Information Systems acting as an enabler. However, this leaves Information Systems in a passive function while the underlying driver of improvement is likely to be information technology. In many cases, only the Information System function is aware of the capabilities of the emerging technologies to reduce costs. As such, it is often desirable to have Information Systems lead the Process Reengineering activity. By doing so, IS assumes value added responsibility along with the operational groups and clients.
Process methodology needs to be selected in order to assure effective and efficient results.
The degree of centralization and decentralization of the organization places a major part in the choice of development processes as does the degree of out-sourcing. This sets the location of both value-added responsibility and the financial control. For fully decentralized IS functions, control is with the department and therefore, only methods which supports decentralization of control are used. However, in most cases the organizations are a blend of centralized systems expertise and decentralized financial authority. Often a "matrix" organization is imposed with Information Systems specialists reporting directly to the IS function but work and "indirectly" report to the operational function. In this case, often multiple processes are used depending on the complexity of the activity.
As is true in almost all cases, the Golden Rule applies: "He who pays the gold, makes the rules." The objective of the function is not to take control of the project from the client, but to allow the effective and efficient control of the project by the client at the level that is desired. The problem takes place when the resources are not controlled by the user/client but by the senior management. This is particularly the case for large projects, such as Enterprise Data Models, where the funding is often coming from the offices of the CFO or even the CEO for the firm. IS is often set up as a "cost center" where the budget is handled as burden to the total firm. As such, support of projects is as often a political exercise as a value-added issue. This makes the issues of control and methodology even more important.
A major difference in methodologies is the extent of Information Systems accountability in assuring value-added and providing control. While there are large differences how each methodology is applied, there is a tendency of each to provide different levels of IS value-added responsibility and Control. This is shown on the chart below:
For large programs, IS typically wants strong control but with low Value Added accountability. This is the traditional systems development process, the Water Fall Method, where IS is only responsible for meeting requirements for which it had originally developed. With small projects decentralized control and value-added accountability is usually preferred. These are usually the "build and fix" methods. Prototyping methods usually represent much higher value-added accountability but with low control.
As previously noted, it is insufficient to have a well-defined process, it must be also maintained. For management purposes, exceptions almost always exist. But they must be controlled. If we allow every project to be an exception, no standard process will exist. This would be even worse than not having a standard process at all, since it conveys the impression that such a general process is enforce.
Typically, most systems groups face at least three types of projects, (1) small fixes to existing large systems, (2) developing new small-specialized systems, and (3) building large-scale systems and programs. Most concern for formal process development methodologies tend to focus on the large-scale systems where control is critical. It is not unusual to have organizations try to impose the same process on the smaller projects with unfortunate results. Large organization overhead is usually imposed with that methodology greatly increasing costs and charge rates. Furthermore, time delays and a "feeling of interference" takes place. As such, small projects are often considered exceptions. This often involves the great majority of projects, though only a minority of the resources spent.
In order to avoid chaos of having no operating procedures for exception, it is usually preferred to provide some control mechanism. Unfortunately, many IS functions simply try to "wash their hands" over the exceptions and allow decentralized groups to do their own thing. This produces an extensive collection of incompatible systems and inaccessible databases. This comes back to IS as the organization tries to establish an Enterprise Database system. It is, therefore, preferable for methodologies to be established both for the large projects and for most of these exceptions. However, it should be noted, in some cases, it is still usually preferred to let the group alone. This is particularly the case with technical research and engineering functions.