In Part II we introduced three types of information technology applications: organizational systems, man¬agerial support systems, and electronic commerce applications, including interorganizational systems. Until the late 1980s, most business applications such as these were software applications customized for a specific firm. If an organization had its own informa¬tion systems (IS) professionals, these custom applica¬tions were most likely developed in-house by these IS specialists. If an organization did not have the resources or IS expertise to develop custom applica¬tions, an outside vendor would be employed to either provide IS contract personnel on a temporary basis or to completely develop the customized application for the organization.
Our focus for this chapter is the process of devel¬oping customized applications in-house by IS profes¬sionals. We describe two overall approaches: the traditional systems development life cycle (SDLC) approach and an evolutionary prototyping approach. Many characteristics of these two approaches to sys¬tem development, and the newer techniques described in this chapter, also hold true for application develop¬ment approaches used within software houses. A key difference is that with customized application devel¬opment for a specific business, users must playa key role in both the Definition and construction phases of the development cycle. In chapter 11 we will focus on the process for purchasing systemS
SYSTEMS Development LIFE CYCCLE MOTHODOLOGY
We turn now to a detailed discussion of the systems life cycle for in-house application development by IS professionals. The traditional life cycle process for developing customized applications is referred to as the systems development life cycle (SDLC). As dis¬cussed in Chapter 9, the life cycle concept recognizes that large systems are major IT investments and the development of a system may continue even after it is implemented. Although systems built in the 1980s can still be found in today's organizations, the typical system over a decade old has been modified multiple times in order to keep current with the changing needs of the organization. The SDLC process therefore includes a maintenance step.
The SDLC approach is but one of several alterna¬tive approaches to developing systems. We have cho¬sen to focus on this approach first for three reasons.
First, the SDLC approach provides a baseline for understanding what is involved in developing an application system, whether by IS professionals in your organization, by IS professionals in a software firm, or by some combination of in-house and vendor IS specialists. Even if you purchase the system (see Chapter 11) or develop it yourself (see Chapter 12), you need to understand the elements of the traditional approach and both the user-manager and end-user roles in that approach. The SDLC approach includes not only process steps, but a framework for project management. Second, this traditional approach is often the primary approach for a large strategic sys¬tem. Because your competitors can quickly implement the same purchased solution that you do, purchased systems are unlikely to provide a sustainable compet¬itive advantage. However, customized applications that exploit a particular strategic strength are much more difficult for either a competitor or a vendor to develop. Large organizations today still rely on their IS staffs to both develop and support strategic appli¬cations that have become an organization's key means for survival.
Third, as described in Chapter I, the responsibili¬ties for identifying the need for new applications and effectively implementing them are in the hands of today's user-managers. Line managers are responsible for determining what systems to develop, for making the business case that justifies the cost of the system, for helping to specify what the system will do and how it will enable organizational processes, for managing the changes involved in implementing the new system, and for making sure that it is used to achieve the envi¬sioned bene5ts for the organization. Recent research has shown that the IT management knowledge of line managers is related to the progressive use of IT within an organization (Boynton, Zmud, and Jacobs, 1994). Further, as we will see in Part IV, in many large orga¬nizations the IS managers and professionals who develop and support business applications actually report to senior managers who are line managers, rather than to a senior IS manager.
The SDLC Steps
In Chapter 9 we introduced the three phases of the systems life cycle process: Definition, Construction, and Implementation. This basic life cycle approach is simple in concept, but there is substantial complexity in using it to develop a high-quality, customized applica¬tion. Over the past three decades, SDLC methodol¬ogies have evolved that describe in detail the activities required for each phase. Each SDLC-based methodol¬ogy specifies the modeling tools to be used at each stage of the process, and IS professionals are trained if! the use of these tools. Several of these tools-data flow diagrams, structure charts, E-R models, data dictionaries-were introduced and illustrated in Chapter 9.
In this chapter we will describe a generic SDLC methodology that includes three phases and eight steps. This template is shown in Figure 10.1. The SDLC is also referred to as the "waterfall" model (Boehm, 1981): The outputs from one step are inputs to the next step.
However, the reader should be;: warned that the initial approval/prioritization process and the specific labeled steps in Figure 10.1 typically vary across orga¬nizations. Your organization may have a total of five steps or ten steps, and the SDLC or "waterfall" methodology may also have its own unique name. Nevertheless, an organization's internally developed SDLC methodology should essentially map into the steps for each of the three phases in Figure 10.1, and our discussion below will provide you with a useful template for the SDLC process.
The overall thrusts of the three phases of the SDLC are quite straightforward. For customized application development, the Definition phase is criti¬cal: It defines precisely what the system must do in process, IS resources are assigned to the project and the formal SDLC process begins. For large pro¬jects, the initial approval may only be an endorse¬ment to proceed with a feasibility analysis. The documents for the feasibility analysis then become the basis for a decision on whether or not to make that capital investment.
Definition Phase
Feasibility Analysis. For this first step of the SDLC process, a project manager and one or more systems analysts are typically assigned to work with business managers to prepare a thorough analysis of the feasibility of the proposed system. Three different types of feasibility will be assessed: economic, opera¬tional, and technical feasibility.
The IS analysts work closely with the sponsoring manager who proposed the system, and/or other busi¬ness managers, to define in some detail what the new system will do, what outputs it will produce, what inputs it will accept, how the input data might be obtained, and what databases might be required. An important activity is to define the scope or boundaries of the system-precisely who would it serve, what it would do, as well as what it would not do-and what data processing would and would not be included. The IS analyst is primarily responsible for assessing the technical feasibility of the system, based on a knowl¬edge of current and emerging technological solutions, the IT expertise of in-house personnel, and the antici¬pated infrastructure needed to both develop and sup¬port the proposed system. The business manager is primarily responsible for assessing the operational feasibility of the system. In some organizations busi¬ness analysts who are knowledgeable about IT but are not IT professionals playa lead role in this process.
Both business managers and IS analysts work together to prepare a cost benefit analysis of the pro¬posed system to determine the economic feasibility. Typical benefits include costs to be avoided such as cost savings from personnel, space, and inventory reductions; new revenues to be created; and other ways the system could contribute business value over¬all. However, for many applications today, some or all of the major benefits may be intangible benefits; they are hard to measure in dollars. Examples of intangible benefits include better customer service, more accu¬rate or more comprehensive information for decision making, quicker processing, or better employee morale. (See the "Managing an SDLC Project" sec¬tion later in this chapter for a further discussion of system justification.)
The IS analyst takes primary responsibility for establishing the development costs for the project. This requires the development of a project plan that includes an estimated schedule in work-weeks or months for each step in the development process and an overall budget estimate through the installation of the project. Estimating these project costs and sched¬ules is especially difficult when new technologies and large system modules are involved. (Note that these costs usually do not include user department costs, which may be substantial during both the Definition and Implementation phases.)
The deliverable of the feasibility analysis step is a document of typically 10 to 20 pages that includes a short executive overview and summary of recommen¬dations, a description of what the system would do and how it would operate, an analysis of the costs and benefits of the proposed system, and a plan for the development of the system. Sometimes referred to as a systems proposal document, this document is typi¬cally first discussed and agreed to by both the execu¬tive sponsor and the IS project manager and then reviewed by a management committee that has author¬ity for system approvals and prioritization.
Before additional steps are undertaken, both IS and user-managers need to carefully consider whether to commit the resources required to develop the pro¬posed system. The project costs up to this point have typically been modest in relation to the total project costs, so the project can be abandoned at this stage without having spent much money or expended much effort. As described above, the approval of a large sys¬tem request may not actually occur until after the com¬pletion of a formal feasibility analysis. For large projects, the executive sponsor of the application is typically responsible for the presentation of a business case for the system before the approving body.
Requirements Definition. If the document pro¬duced from the feasibility analysis receives the neces¬sary organizational approvals, the requirements definition step is begun. Both the development of the "right system" and developing the "system right" are highly dependent on how well the organization con¬ducts this step in the SDLC process. This requires heavy participation on the part of user management. If this step is not done well, the wrong system may be designed or even built, leading to both disruptive and costly changes later in the process.
Although in the past new systems often auto¬mated what had been done manually, most of today's systems are developed to do new things and/or to do old things in entirely new ways. While the executive sponsor plays a key role in envisioning how IT can be used to enable change in what her people do and how they do it, the sponsor is often not the manager who helps to define the requirements of the new system. Rather, the sponsoring manager must make sure that those who will use the system and those managers responsible for the use of the new system are involved in defining its detailed requirements.
Also referred to as systems analysis or logical design, the requirements definition focuses on proc¬esses, data flows, and data interrelationships rather than a specific physical implementation. The systems analyst(s) is responsible for making sure these require¬ments are elicited in sufficient detail to pass on to those who will build the system. It may appear easy to define what a system is to do at the level of detail with which systems are often described by system users. However, it is quite difficult to define what the new system is to do in the detail necessary to write the computer code for the system. Many business applica¬tions are incredibly complex, supporting different functions for many people or processes that cross mul¬tiple business units or geographic locations. Although each detail may be known by someone, no one person may know what a new system should do in the detail necessary to describe it. This step can therefore be very time-consuming and requires analysts who are skilled in asking the right questions to the right people and in conceptual system design techniques. In addi¬tion, there may be significant disagreements among the business managers about the nature of the applica¬tion requirements. It is then the responsibility of the IS project manager and analysts to help the relevant user community reach a consensus. Sometimes outside consultants are used to facilitate this process.
Further, some new applications are intended to provide decision support for tasks that are ill¬structured. In these situations, managers often find it difficult to define precisely what information they need and how the application will be used by them to support their decision-making. Their information needs may also be highly variable and dynamic over time. As noted in Chapter 9, many of today's large systems development projects may also arise ill con¬junction with reengineering an organization's business processes. Redesign of the organization, its work processes, and the development of a new computer system may be going on in parallel. The ideal is to first redesign the process, but even then the work processes are seldom defined at the level of detail required for a new business application.
Because defining the requirements for a system is such a difficult and a l:rucial task, analysts rely on a number of techniques and approaches. Examples of these were described in detail in Chapter 9. Later in this chapter we also describe an evolutionary prototyp¬ing approach that can be used to help define systems requirements-in particular for the user interface.
The deliverable for the requirements definition step is a comprehensive system requirements docu¬ment that contains detailed descriptions of the system inputs and outputs, and the processes used to convert the input data into these outputs. It typically includes several hundred pages with formal diagrams and out¬put layouts, such as shown in Chapter 9. This docu¬ment also includes a revised cost/benefit analysis of the defined system and a revised plan for the remain¬der of the development project.
The system requirements document is the major deliverable of the Definition phase of the SDLC. Although IS analysts are typically responsible for drafting and revising the requirements specifications document, business managers are responsible for making sure that the written requirements are correct and complete. Thus, all relevant participants need to carefully read and critique this document for inaccu¬racies and omissions. Case studies have shown that when key user representatives do not give enough attention to this step, systems deficiencies are likely to be the result.
The deliverable from this step is typically subject to approval by business managers for whom the system is being built as well as by appropriate IS managers. Once formal approvals have been received, the system requirements are considered to be fixed. Any changes to the requirements typically must go through a formal approval process, requiring similar sign-offs and new systems project estimates. All key participants therefore usually spend considerable time reviewing these documents for accuracy and completeness.
Construction Phase
System Design. In this step, IS specialists design the physical system, based on the conceptual requirements document from the Definition phase. System design involves deciding what hardware and systems software will be used to operate the system, designing the structure and content of the databases that the system will use, and defining the processing modules (programs) that will comprise the system and their interrelationships. A good system design is a crit¬ical contribution, because the technical quality of the system must be designed into the system-it cannot be added later during the build process.
As shown in Figure 10.3, a quality system in¬cludes adequate controls to ensure that its data are accurate and that it provides accurate outputs. It pro¬vides an audit trail that allows one to trace transactions from their source and confirm that they were correctly handled. A quality system is highly reliable; when something goes wrong, the capability to recover and resume operation without lost data or excessive effort is planned for. It is also robust-illsensitive to minor variations in its inputs and environment. It provides for interfaces with related systems so that common data can be passed back and forth. It is highly effi¬cient, providing fast response, efficient input and out¬put, efficient storage of data, and efficient use of computer resources. A quality system is also flexible and well documented for both users and IS specialists. It includes options for inputs and outputs compatible with its hardware and software environment, and can be easily changed or maintained. Finally, it is user friendly: easy to learn and easy to use, and it never makes the user feel stupid or abandoned.
Figure 10.3 Characteristics of High Quality Systems
To ensure that the new system design is accurate and complete, IS specialists often "walk through" the design first with their colleagues and then with knowl¬edgeable user-managers and end-users, using graphi¬cal models such as described in Chapter 9. This type of technique can help the users understand what new work procedures may need to be developed in ordp.r to implement the new system.
The major deliverable of the system design step is a detailed using document that will be given to pro¬grammers. Models created by various development tools, such as diagrams of the physical structure of the system, are also an important part of the deliverable The documentation of the system will also include detailed descriptions of all databases and detailed specifications for each program in the system. Also included are a plan for the remaining steps in the Con¬struction phase. Again, this document is typically approved by both user and IS managers before the sys¬tem is actually built.
System Building. There are two activities involved in building the system-producing the computer programs and developing the databases and files to be used by the system. These activities are performed by IS specialists. The major involvement of users is to answer questions of omission or help interpret requirements and design documents. The procurement of any new hardware and support soft¬ware (including the database management system selection) is also part of this step, which entails con¬sultation with IS planners and operations personnel.
System Testing. Testing is a major effort that may require as much time as writing the code for the system. This step involves testing first by IS specialists, fol¬lowed by user testing. First, each module of code must be tested. Then the modules are assembled into subsys¬tems and tested. Finally, the subsystems are combined and the entire system is integration tested. Problems may be detected at any level of testing, but correction of the problems becomes more difficult as more compo¬nents are integrated together, so experienced project managers build plenty of time into the project schedule to allow for problems during integration testing. The IS specialists are responsible for producing a high quality system that also performs efficiently.
The users of the system are also responsible for a critical type of testing-user acceptance testing. The objective here is to make sure that the system performs reliably and doe~ what it is supposed to do in a user environment. This means that users must devise test data and procedures that completely test the system, and then they must carry out this extensive testing process. Plans for this part of the application testing should begin after the requirements definition phase. Case studies have shown that end-user partici¬pation in the testing phase can contribute to end-user commitment to the new system, as well as provide the basis for initial end-user training.
Both user and IS management must sign off on the system, accepting it for production use, before it can be installed. Documentation of the system is also a major mechanism of communication among the var¬ious members of the project team during tht> develop¬ment process: Information systems are simply too complex to understand by verbally describing them.
Once the users sign off on this part of the testing, any further changes typically need to be budgeted out¬side of the formal development project-that is, they become maintenance requests.
Implementation Phase Strong IS business relation¬ships are essential for successful implementation efforts. In fact, potential political problems (such as described in Chapter 8) need to be anticipated and dealt with before the Implementation phase.
Installation. Both IS specialists and users play critical roles in the installation step, which includes building the files and databases and converting rele¬vant data from old systems to the new system. Depending on the extent to which the data already exists within the organization, some of the data con¬version burden may also fall on users. In particular, data in older systems may be inaccurate and incom¬plete, and considerable user effort may be required to "clean it up." The clean-up process, including the entering of revised data, can be a major effort for user departments. Sometimes the clean-up effort can be accomplished in advance. In other situations, however, the data clean-up is done as part of the new system implementation. This means users have a lot of data verifications to check and conversion edits to resolve, sometimes without the benefit of additional staff, as they also learn the new system.
Another crucial installation activity is training the system's end-users, as well as training other users impacted by the new' system. If this involves motivateing people to make major changes to their behavior patterns, planning for this motivation process needs to start well before the Implementation phase. User par¬ticipation in the earlier phases can also help the users prepare for this crucial step. Similarly, user training needs to be palmed and carefully scheduled so that people are prepared to use the system when it is installed, but not trained so far in advance of the installation that what they learned is forgotten. If user resistance to proposed changes is anticipated (see Chapter 8), this potential situation needs to be addressed during training or earlier.
Installing the hardware and software is the responsibility of the IS organization. This can be a challenge when the new system involves technology that is new to the IS organization, especially if the technology is on the "bleeding edge." The major prob¬lems in system installation, however, usually lie in adapting the organization to the new system enchanting how people do their work.
Converting to the new system may be a difficult process for the users because the new system must be integrated into the activities of the organization. The users must not only learn how to use the new system, but also change the way that they perform their work. Even if the software is technically perfect, the system will likely be a failure if people do not want it to work or do not know how to use it. The conversion process therefore may require attitudinal changes. It is often a mistake to assume that people will change their behavior in the desired or expected way. On the other hand, not all user reactions can be planned for; some may require improvisatory responses by management as the unexpected is encountered (Orlikowski and Hofman, 1997).
Several strategies for transitioning users from an old system to a new one are commonly used (see Fig¬ure lO.4). This is a critical choice for the effective implementation of the system and needs to be chosen well in advance of the Implementation phase by a decision-making process that includes both IS and user-managers. Good management understanding of the options and tradeoffs for the implementation strategies discussed below can reap both short-term and long-term implementation benefits.
In the parallel strategy, the organization continues to operate the old system in parallel with the new sys¬tem until the new one is working sufficiently well to discontinue the old. This IS a conservative conversion strategy, because it allows the organization to continue using the old system if there are problems with the new. However, it can also be a difficult strategy to manage because workers typically must operate both the old system and the new while also comparing the results of the two systems to make sure that the new system is working properly. When discrepancies are found, the source of the problem must be identified and corrections initiated. Parallel conversion can therefore be very stressful. A parallel strategy also may not even be feasible due to changes in hardware and software associated with the new system.
The pilot strategy is an attractive option when it is possible to introduce the new system in only one part of the organization. The objective is to solve as many implementation problems as possible before imple¬menting the system in the rest of the organization. For example, in a company with many branch offices, it might be feasible to convert to the new system in only one branch office and gain experience solving data conversion and procedural problems before installing the system companywide. If major problems are encountered, companywide implementation can be delayed until they are solved. Pilot approaches are especially useful when there are potentially high tech¬nological or organizational risks associated with the project.
For a large, complex system, a phased conversion strategy may be the best approach. For example, with a large order processing and inventory control system, the firm might first convert order entry and simply enter customer orders and print them out on the company forms. Then it might convert the warehouse inventory control system to the computer. Finally, it might link the order entry system to the inventory sys¬tem and produce shipping documents and update the inventory records automatically. The downside to this approach is that it results in a lengthy implementation period. Extra development work to interface new and old system components is also typically required. On the other hand, a phasing strategy enables the firm to begin to archive some benefits from the new system more rapidly than under other strategies.
In the cold turkey (or cutover) strategy the organi¬zation totally abandons the old system when it imple¬ments the new. In some industries, this can be accomplished over holiday weekends in order to allow for a third day for returning to the old system in the event of a major failure. The cold turkey strategy has greater inherent risks, but it is attractive when it is very difficult to operate both the old and new systems simul¬taneously. Some also argue that the total "pain is the same" for a system implementation, whether imple¬mented cold harked or not, and this strategy moves the organization to the new operating environment faster.
Combinations of the above four strategies are also possible. For example, when implementing system modules via a phased conversion strategy, one still has the option of a parallel or cold turkey approach for converting each phase of the system. Similarly, a pilot strategy could include a parallel strategy at the pilot site.
Operations. The second step of the Implemen¬tation phase is to operate the new application in "production mode." In the operations step, the IS responsibility for the application is turned over to computer operations and technical support personnel. The project team is typically disbanded, although one or more members may be assigned to a support team.
New applications are typically not moved into production status unless adequate documentation has been provided by the project manager. Implementing a large complex system without documentation is highly risky. Documentation comes in at least two flavors: system documentation for IS specialists who operate and maintain the computer system and user documentation for those who use the system.
Successful operation of an application system requires that people and computers work together. If the hardware or software fails or people falter, system operation may be unsatisfactory. In a large complex system there are thousands of things that can go wrong, and most companies operate many such sys¬tems simultaneously. It takes excellent management of computer operations to make sure that everything works well consistently and to contain and repair the damage when things do go wrong.
In Part IV we consider what it takes to success¬fully schedule and run large applications on a large computer system in what is typically referred to as a data center.
Maintenance. Maintenance refers to the process of making changes to a system after it has been put into production mode, i.e., after the opera¬tions stage of its life cycle. The most obvious reason for maintenance is to correct errors in the software that were not discovered and corrected prior to its ini¬tial implementation. Usually a number of bugs in a system do elude the testing process, and for a large complex system it may take many months, or even years, to discover them. Changes may also be required to adapt the system to changes in the environment the organization, other systems, new hardware and systems software, and government regulations. Another major cause for maintenance is the desire to enhance the system. After some experience with a new system, managers typically have a number of ideas on how to improve it, ranging from minor changes to entirely new modules. The small changes are usually treated as maintenance, but large-scale additions may need approval as a new development request.
Because both business and technology environ¬ments change rapidly, periodic changes to large sys¬tems are typical. In fact, the total costs over a typical system's life cycle have been estimated to be about 80 percent on maintenance, and only 20 percent on the original development of the application. As a result, many IS organizations have to allocate a significant number of their IS specialists to maintaining systems, rather than developing new ones. In the early 1990s, maintenance resources were consuming as high as 75 percent of the total systems development resources in many large organizations (see figure 10.5). The IS
Figure 10.5 Percent of Development Resources Devoted to Maintenance organization is responsible for making the required changes in the system throughout its life, as well as for eliminating any bugs that are identified prior to starting to use the new system in a production mode.
To make a change in a system, the maintenance programmer must first determine what program(s) must be changed and then what specific parts of each program need to be changed. The programmer must also understand the logic of the part of the code that is being changed. In other words, one must understand the system in some detail in order to change it.
Because systems can be very complex, the system documentation is critical in providing the necessary level of understanding. This brings up another diffi¬culty-the documentation must be changed when the system is changed or the documentation will provide misleading information about the system rather than assistance in understanding it. Most programmers are primarily interested in programming and are not rewarded for updating the documentation, so in many IS organizations the documentation of old systems becomes outdated and includes inaccuracies.
further, when changes are made in complex sys¬tems, a ripple effect may be encountered such that the change has an unanticipated impact on some other part of the system. for example, a change in a pro¬gram can affect another program that uses the output from the first program. A change to a line of code can affect the results of another line of code in an entirely different part of that program. Another change must be made to correct those problems and that change may cause unanticipated problems elsewhere.
Another major problem with maintenance is that most IS professionals prefer to work on new systems using new technologies, rather than maintain old sys¬tems. Maintenance is therefore often perceived as low status work, although it is critical to the business. Maintenance is often the first assignment of a newly hired programmer, and most organizations do not have mechanisms in place to ensure that really good main¬tenance people are rewarded well.
From the perspective of the user-manager, the major problems with maintenance are getting it done when it i., needed and dealing with the problems caused by new system problems introduced as part of the maintenance process. A high proportion of opera¬tional problems are caused by errors introduced when making maintenance changes. Changes to production systems need to be carefully managed. Maintenance changes are typically made to a copy of the production system and then fully tested before they are imple¬mented. An effective change management process for changing from an older to a newer version of the sys¬tem is critical to avoid introducing large numbers of new problems when maintaining operational systems.
If adequate numbers of IS specialists are not available for systems maintenance projects, the man¬ager often must suffer long delays before needed changes are made. Figure 10.6 graphically displays the widening gap that can occur between the organi¬zation's needs and the system's performance over time. Also, as a system gets older and is repeatedly patched, the probability of performance problems becomes even greater and reengineering or replace¬ment solutions may be required. (These are discussed in more detail in Part IV)
At the end of this chapter we address a special maintenance issue that is requiring large capital investments and creating even more of a shortage of IS professionals at the end of the I Q90s: the Year 2000 maintenance problem.
Most application systems are developed by a tempo¬rary project team. When the system project is com¬pleted, the team is disbanded. Most project teams include representatives from both the IS organization and relevant user departments. If the system will be used by several organizational units or by several levels of people within a unit, the project team may include representatives from each of these organiza¬tions and levels. In addition to an IS project leader and at least one systems analyst, IS team members include programmers, data administration specialists, tele¬communications specialists, and others
Figure 10.6
The Widening Gap between the Organization's Needs and the System's Performance
The project team also may vary in membership during the systems life cycle: A few members may be assigned full-time to the project for its entirety, whereas others may join the project team only tem¬porarily as their specific knowledge or skills are required. As described at the beginning of the chapter, it is also not unusual for IS specialists from outside firms who specialize in furnishing contract analysts or programmers to work on development project teams alongside the client firm's IS personnel.
In this section we describe in some detail four dif¬ferent roles that are critical to the success of an SDLC project. Two of these roles are user management roles: the user sponsor and the user champion. Two other roles require IS skills: the project manager and the systems analyst.
Historically, the project manager was an IS man¬ager. Today, however, a user-manager with IT man¬agement skills may be the project manager, or a project may have two project managers: a user-manager responsible for all user activities and managing the change processes and an IS manager who is the technical director of the project. Responsible for the activities of all IS specialists
Whether or not this role is shared, the project manager is held responsible or the success of the pro¬ject-for delivering a quality system, on time, and within budget. Managing stems project typically involves coordinating e efforts of many persons from different organizational units, some of whom work for the project only on a part-time or temporary basis. Some guidelines for whether the manager of a specific project should one from the IS organization, user organization, or both, are provided in the "Choos¬ing the Project Manager(s)" sidebar.
The project manager must plan the project, deter¬mine the SDLC tasks that must be carried out and the skills required for each task, and estimate how long each will take. The tasks then must be sequenced and people assigned to each in order to meet the project schedule. The project manager is also responsible for obtaining the necessary personnel to carry out the pro¬ject plan; the quality and skills of the people are just as important as their numbers for producing a high quality system, on time, and within budget. Today's project manager also typically relies on project man¬agement tools to monitor and control progress on the project. The system documentation produced at each step of the project also provides a major tool for com¬munication across team members and for assessing the quality of the development effort throughout the life cycle.
Because an IS project manager may have no authority over users assigned to the project team, as well as some of the IS specialists, the project leader needs to be skilled not only as a project manager, but also as a team leader, communicator, effective motiva¬tor, and negotiator. Frequently, the project manager must also build a cohesive team out of people from many backgrounds and several different organiza¬tional units. If there has been a history of conflict and distrust between the IS organization and the user community or between different user departments involved, the project manager may have to devote sub¬stantial effort to team-building activities and reaching consensus.
Most organizations require that systems for which an SDLC process is appropriate have an executive sponsor of the new system. The sponsor participates in the justification of the system, funds the approved project, and plays a role in seeing that the promised benefits of the system are achieved after it is installed. The sponsor also typically takes responsibility for ensuring that the appropriate user-manager represen¬tatives are assigned to the project team. The user representatives on the project team must be knowl¬edgeable about their business unit's system needs and must have the authority needed to make decisions for the business unit they represent; achieving effective user participation is absolutely critical. Because the most capable representatives often cannot be easily spared by the business unit, the system sponsor needs to take an active role in arranging for the best user rep¬resentatives possible to be freed up enough from their normal duties to participate on the project team.
Another critical user-manager role is the user champion. The SDLC process is long and expensive, subject to many hazards. In addition, user participa¬tion on a systems project team is also a temporary assignment, and often only a part-time one. Users who have other full-time responsibilities must often make time for the project by ignoring other daily responsi¬bilities. Problems may arise that require exceptional efforts or additional resources to overcome. Without an effective champion who pushes the project forward, helps remove obstacles, and never lags in enthusiasm, the development project is unlikely to be successfully completed. In some situations the executive who spon¬sors the system also serves as its champion. However, when the executive sponsor is too far removed from the activities impacted by the system or from the end-users of the system, the champion role may not receive enough attention if left to the sponsor.
Systems analysts, who are usually members of an IS organization, work with user-managers and end-users to determine the feasibility of the new system and to develop the system requirements. During the Construction phase, they work with other IS special¬ists in designing the system, and they supervise the writing of the computer code. A good systems analyst has problem-solving skills, a knowledge of IT capa¬bilities, and an understanding of the business. The role of the systems analyst needs to be played well in order for multiple user perspectives to be taken into account and for conflicts between different managers to be resolved without any supervisory authority to do so. Sometimes the systems analyst also helps to serve as a check and balance for IS specialists eager to work with new, but unproven, technologies.
Managing an SDLC Project
SDLC project success is typically measured by three primary criteria: system quality, time-to-completion, and project cost. Below we first discuss five character¬istics of SDLC projects that have been associated with successful customized development projects: manage¬able project size, justification methods that go beyond traditional financial analysis, accurate requirements definition, obtaining and keeping user buy-in, and change management. Then we briefly describe efforts directed at software quality improvement by the Soft¬ware Engineering Institute.
Manageable Project Size Experience has shown convincingly that huge projects requiring hundreds of work-years of development effort are almost never successful. On the other hand, projects that take a few technical people a year or less to complete are man¬ageable and are quite likely to be successful. Thus, large systems must be broken down into relatively independent modules, each of which provides its own benefits and stand's on its own merits. The overall systern can then be built as a sequence of small, manage¬able projects, rather than as a single monster project.
Justification Methods New application projects need to be justified as capital investments. A simplified example of a traditional justification approach is pre¬sented in Figure 10.7. Here the costs and benefits of systems are projected as cash flows in order to analyze the return on investment and payback period. In this example, the payback period to recoup a projected $550,000 development investment is a little over four years. The net present value at a discount rate of 15 perce-nt is $71,000 over a six-year time period, and the return on investment (the interest rate that makes the present value equal zero over this time period) is 20.6 percent.
Traditional financial justification works best for systems that improve the efficiency of operations. Today, however, companies are investing in new applications intended to improve the effectiveness of individuals, groups, departments, and entire organiza¬tions, and these traditional economic measures do not work well (lIS Analyzer, 1987). In particular, when potentially large intangible benefits are involved, tra¬ditional financial analysis becomes much less suitable.
Managers and IS researchers have therefore developed alternatives to techniques such as Return on Investment (ROI) calculations for evaluating new application development efforts as capital invest¬ments. One approach to dealing with intangibles is to assign relative weights to impacts (positive weights) and risks (negative weights) of the proposed system (Parker and Benson, 1987 and Pastore, 1992). An example of a scoring system using this approach, in which traditional financial measures account for only 25 out of the 100 positive points available, is provided in the sidebar "A Scoring System for Project Goals and Risks." Several approaches for evaluating strate¬gic IT investments, in particular, have been recom¬mended by Clemons (1991). These range from ranking alternatives without ROI to taking into account competitor reactions.
Accurate Requirements Definition The SDLC "waterfall" process is based on the premise that requirements for a new system can be defined in detail at the beginning of the process. The downside is that if the requirements are not well defined, then there may be large cost overruns, and the system may be unsatis¬factory. Easy studies have shown that about half of the total number of requirements errors (or omissions) are typically detected in the Requirements Definition step. Further, as shown in Figure 10.8, experience at IBM, GTE, and TRW indicates that an error detected in the Implementation phase costs about 150 times as much to fix as an error detected in the Definition phase. Every effort must therefore be put into obtaining as accurate a requirements definition document as possi¬ble. This requires systems analysts skilled in eliciting requirements, as well as skilled in process and data representation techniques. It also requires access to business users knowledgeable about both current busi¬ness operations and the envisioned system.
User Buy-in Both user-managers and end-users need to understand the potential benefits of the proposed system and be dedicated to contributing first to the development effort and then to sustained usage of the new system. As described above, user management needs to be committed to funding as well as to devoting significant amounts of time and effort to the development project. Sometimes managers are assigned full-time to the project team, but usually their work on the project is in addition to regular responsi¬bilities. Although not every project team has end-users as formal team members, end-users frequently par¬ticipate by providing information about current work processes or procedures, and evaluating screen designs from an end-user perspective. IS researchers have found that user involvement is associated with user acceptance and system usage (e.g., Hartwick and Barki, 1994). Case studies have also shown that end-user buy-in can be critical to the initial implementa¬tiell of a new computer system.
Beath and Orlikowski (1994) have pointed out that systems development managers also need to rec¬ognize that assumptions about IS-user relationships are embedded in systems development methodologies. For example, the ETHICS method and the Soft Sys¬tems Methodology are specifically designed to facili¬tate more user involvement.
Change Management At the end of the Definition phase, most organizations institute a strict change process for any modifications to the original require¬ments document. Although this helps ensure a high quality system and keeps the development effort on schedule, this process becomes dysfunctional if it results in the installation of a system that is obsolete. A process to identify and evaluate proposed system changes during the course of the SDLC project is therefore critical to its success.
Each proposed change must be evaluated in terms of how it impacts the system under development and how it will affect the project schedule and budget. Most changes will add to the project time and cost, so making enhances either involves trade-offs or the project budget and completion date may need to be renegotiated. Managing change means having a mech¬anism in place that involves the right organizational members to make good decisions about ,whether to make the change or postpone it until the maintenance step of the life cycle. Of course, system implementa¬tion also requires managing organizational changes. Because managing change in general is an important capability of all IS organizations, we delay its discus¬sion until Part IV
Improving the Software Process A framework that describes the key elements of an effective software process, as well as an evolutionary path for organiza¬tions to move from an ad hoc, immature process to a mature, disciplined one has been developed by the Software Engineering Institute (SEl) (see Figure 10.9). The inability of firms to manage the systems develop¬ment process has been identified as a major contrib¬uting factor to poor software quality. In a mature software organization, roles and responsibilities within the process are clear, participants understand the value of consistently following a disciplined process, and there is a broad-scale, active involvement in software quality improvement activities. The key principle is to improve quality by preventing problems, not just reacting to them (Bollinger and McGowan, 1991).
SDLe Advantages and Disadvantages
The SDLC process is a highly disciplined approach to the development of large, complex applications for one or more business units. A summary of the advantages and disadvantages of the SDLC approach is pro¬vided in Figure 10.10 and is discussed below.
Figure 10.9 The SEI Process-Maturity Framework [Bollinger and McGowan, 1991]. © 1991 IEEE.
In the hands of competent IS specialists and knowledgeable user-managers, the SDLC process sets up formal steps with clear IS and user roles, formal checkpoints, and tools for development and project management. The tools and rigorous discipline associ¬ated with an SDLC methodology help project leaders produce a well-engineered system on time and within budget.
The major disadvantages are inherent in the methodology. First, the success of the project is depen¬dent on the accurate and complete specification of detailed reqUirements at the beginning of the develop¬ment process (Definition phase). There are several seri¬ous problems with this dependency. For example, many new systems are conceived in response to per¬ceived problems, and, because the managers involved may have only an incomplete understanding of what an information system must do to alleviate these prob¬lems, it may be necessary to try several approaches before discovering an effective one. New types of deci¬sion support systems, for example, often arc directed at providing support for ill-structured problems. Another problem is that the business environment is changing so rapidly that there will be significant differences in business needs between the time the requirements are specified and the time the system IS installed.
Second, the SDLC process as described previ¬ously is a time-consuming process and therefore a costly process. In the 1980s, the typical systems pro¬ject took more than a year; many took several years. Third, a strong commitment from top management is required. This is because the SDLC process is both lengthy and costly and requires a significant level of participation on the part of user-management. Fourth, the SDLC process requires that a full costJbenefit analysis be developed based on a conceptual Defini¬tion phase. When it is difficult to specify the system requirements or many of the benefits are intangibles, the justification process can be difficult to accomplish using traditional approaches such as ROI calculations. When new technologies are involved, it is often diffi¬cult to estimate the project costs and to adequately assess the technical and operational feasibility.
In the next section we will look at an alternative approach to systems development that addresses some of these disadvantages.
Traditional life cycle development using an SDLC process is based on the fundamental premise that sys¬tem design and programming are so expensive and time-consuming that efforts in these areas must be minimized. Thus, .the system requirements must be completely specified in detail before the Construction phase is begun. Once the requirements have been agreed upon, changing them leads to significant pro¬ject delays and costs.
In the second half of the 1980s, the growing avail¬ability of fourth-generation nonprocedural languages and relational database management systems offered an alternative approach. These tools make it possible to more quickly build a system and then change or redo the system after users have tried it out and dis¬covered its inadequacies. Thus, rather than first defin¬ing the system and then building it, the system can evolve based upon the user's experience and under¬standing gained from the previous versions. This approach is very powerful because, while most people find it very difficult to specify in great detail exactly what they need from a new system, it is quite easy for them to point out what they like or do not like about a system they can tryout and use.
This general approach is most commonly known as evolutionary development, or prototyping. How¬ever, the prototyping concept can be applied to a process in which only a "toy" system is developed for the user to try out, as well as to a real system that employs actual data. In addition, sometimes only a part of area system is prototyped. For example, pro¬totype input and output screens are often developed for users to work with as part of the requirements definition or detailed design steps.
Below we first discuss prototyping as an evolu¬tionary methodology that is an alternative to the tradi¬tional SDLC methodology: its steps, the roles, project management considerations, and its overall advan¬tages and disadvantages. This approach is particularly attractive when the requirements are hard to define, when a critical system is needed quickly, or when the system will be used infrequently (or even only once)-so that operating efficiency is not a major con¬sideration. These are characteristics that often apply to new types of managerial support systems. Prototyping also provides a practical way for organizations to experiment with systems where the probability of suc¬cess is unclear but the rewards of a successful system appear to be quite high.
At the end of this section, we will also describe two ways in which prototyping can be used within an SDLC process to increase the likelihood that the sys¬tem requirements are well defined.
Figure 10.11 presents the steps for an evolutionary methodology for developing a new, working system. The process begins with the identification of the basic requirements of the initial version of the system (step 1). The analystlbuilder(s) and user(s) meet together and agree on the inputs, the data processing, and the system outputs. These are not complete detailed requirements; rather, this is a starting point for the sys¬tem. If several builders and users are involved, a joint application design (lAD) session may be used to determine requirements (see lAD description under "Newer Approaches" section below).
In step 2 the system builders produce an initial prototype system according to the basic requirements agreed on in step I. The system builders select the software tools, locate the necessary data and make these data accessible to the system, and construct the system using higher level languages. This step should take from a few days to a few weeks, depending on the size and complexity of the system.
When the initial prototype is completed, it is given to the user with instructions similar to the following: "Here is the initial prototype. I know that it is not what you really need, but it's a beginning point. Try it and write down everything about it that you do not like or that needs to be added to the system. When you get a good list, we will make the changes you suggest."
Step 3 is the user's responsibility. He or she works with the system, notes the things that need to be improved, and then meets with the analyst/builder to discuss the changes. In step 4 the builder modifies the system to incorporate the desired changes. In order to keep everyone actively involved, speed is important. Sometimes the builder can sit down with end user anew! make the changes immediately; for larger systems, the changes may take several weeks. Steps 3 and 4 are repeated until the user is satisfied with the current version of the system. These are iterative steps within the prototyping process. When the user is satisfied that the prototype has been sufficiently developed, step 5 begins.
Step 5 involves evaluating the final prototype as an operational system. It s110uld be noted, however, that not all prototypes become operational systems. That is, it may be decided that the prototype system should simply be thrown away. For example, it may be decided that no additional costs should be devoted to the application because a system could not be devel¬oped that solved the original problem. That is, the pro¬totyping process helped the organization decide that the system benefits do not outweigh the additional development and/or operational costs or that the expense of developing an operationally efficient sys¬tem is too high. At this point it could also be decided that the system will be implemented, b'.lt that the sys¬tem needs to be built using ditTerent tools in order to achieve performance efficiencies.
If the prototype is to become an operational sys¬tem, in step 6 the builder completes the Construction phase by making any changes necessary to improve operational efficiency and to interface the new appli¬cation with the operational systems that provide it with data. This is also the step in which all necessary controls, backup and recovery procedures, and the necessary documentation need to be completed. If the prototype is only slightly modified, this step differs from the end of the Construction phase of an SDLC methodology in that most (or all) of the system has already been tested. Step 7 is similar to the Imple¬mentation phase of the SDLC: The new system is installed and moved into operational status. This is likely to be a much easier Implementation phase than under the traditional SDLC process, and at least some of the intended users are already experienced users. Step 7 also includes maintenance. Because of the advanced tools that likely were used to build it, changes may be easier to make.
The Prototyping Roles
The same four roles described for the SDLC method¬ology are relevant for an evolutionary methodology, and there are new roles. An executive sponsor is still responsible for justifying the system and acquiring the necessary resources to develop the system. However, because the initial development costs for a prototype are usually substantially less than for a fully con¬structed system, justification may be easier. When small systems are involved, prototyping may reduce these costs to the point where they come within the normal discretionary spending authority oflower level managers, so a high-level executive sponsor may not even be required.
The user champion role differs in that the proto¬type can be used to "sell" the system to other users. Different versions of the prototype can be used by one or more users. Because there is continuous user involvement with the various versions of the system, the champioi1's role as a change agent begins much earlier in the development process; it is quite different in the SDLC process, where users must be prepared for changes involving a new system that they have not yet seen.
Managing an evolutionary development process is clearly a joint IS and user management responsibil¬ity. Whether the project leader role is carried out by IS alone, by user-managers, or by both IS and user managers, both IS and user management need to jointly determine when to continue to request revi¬sions to a prototype and when to end the iterative try¬out-and-revise steps. The user-manager needs to determine whether or not a satisfactory solution has been developed, and the IS manager needs to deter¬mine whether or not all relevant technology capabili¬ties have been explored.
Because only basic requirements are being defined, the systems analyst and prototype builder (which may be one and the same) need to have some skills different from those required for the SDLC process. Techniques to elicit abstract requirements and an emphasis on detailed documentation under the SDLC process are replaced by a heavy reliance on skills to build systems quickly using advanced tools. The initial prototypes are assessed more in terms of their look-and-feel from a user perspective and less in terms of technical quality from a systems performance perspective. Interactions between IS specialists and users center around creative development solutions and personal user reactions to concrete system inter¬faces and outputs.
If different from the champion, the user who tries out the prototype and suggests changes also plays a critical role.
Managing a Prototyping Project Managing new development projects with a method¬ology based on an iterative or evolutionary process requires a different mindset than managing projects using an SDLC methodology based on a highly struc¬tured development approach. IS project managers and system builders need to approach the project differ¬ently: The objective is to respond quickly to user requests with a "good enough" prototype multiple times, rather than produce a tightly engineered actual system at the outset of the project. This may require some cultural changes within the IS organization. IS professionals who have built their careers on skills and attitudes required by an SDLC approach may need to acquire new skills for prototyping approaches.
IS managers also find managing prototyping projects more problematic because it is difficult to plan how long it will take, how many iterations will be required, or exactly when the system builders will be working on the system. Project managers need to have sufficient IS resources available for system building in order to quickly respond to user requests for system changes within an agreed-upon timetable. Users who will be trying out each prototype version must be committed to the process and must be willing and able to devote the time and effort required to test each prototype version in a timely fashion. IS managers may rightfully feel that they have less control over the scope of the project. One of the potential hazards of prototyping is that the ikrative steps will go on and on and that the project costs will keep accumulating. Good working relationships between IS personnel and users responsible for the project are required to move to the prototype evaluation step (step 5) at the optimal time. Joint IS-user accountability would appear to be a key to success for these types of projects.
Depending on the software tools used to build the prototype, the operational efficiency of a prototype that is evaluated in step 5 may be significantly inferior to systems developed using the traditional SDLC methodology. Technical standards established by the organization also may not be rigorously followed, and the documentation may be inadequate. A substantial investment in CASE tools (see below), database man¬agement tools, and IS specialist training may be required before an IS organization can successfully implement the end-prototype as the final system.
Prototyping Advantages and Disadvantages The advantages of the evolutionary development methodology address the disadvantages inherent in the SDLC methodology. First, only basic system requirements are needed at the front end of the project. This means that systems can be built using an evolu¬tionary approach that would be impossible to develop via an SDLC methodology. Further, prototyping can be used to build systems that radically change how work is done, such as when work processes are being redesigned cr a totally new type of managerial support tool has been envisioned but never seen. It is virtually impossible to define requirements for these kinds of systems at the beginning of a systems development process. Prototyping also allows firms to explore the use of newer technologies, because the expectations under an evolutionary methodology are that the builders will get it right over multiple iterations, rather than the first time.
Second, an initial working system is available for user testing much more quickly. In some cases a work¬ing prototype may actually be used by user-managers to respond in some way to a current problem or at least to quickly learn that a given systems approach will not be the best solution. Although the complete process may take several months, users may have a working prototype in a few weeks or months that allows them to respond to a problem that exists now and is grow¬ing in importance; often a user-manager cannot wait many months, let alone years, for a particular system to be built.
Third, because of the more interactive nature of the process, with hands-on use of working system models, strong top-down commitment based on a well-substantiated justification process may be less necessary at the outset of the project. Instead, the costs and benefits of the system can be derived after experi¬ence' with an initial prototype.
Fourth, user acceptance of an application devel¬oped with an evolutionary process is likely to be higher than with an SDLC process. The final version of the system is more likely to meet the needs of the business, and the evolutionary process results in more active involvement and joint control of the process on the part of the user.
The disadvantages of an evolutionary methodol¬ogy are related to the evolutionary build process. The end-prototype typically lacks some of the security and control features found in a system developed with an SDLC process. It also does not undergo the same type of rigorous testing. Documentation is typically also less complete because of the iterative nature of the process. In the past the operational inefficiencies of fourth-generation tools also contributed to the inade¬quacies of end-prototypes. However, with recent advancell1ents in hardware and software tools for developers and end-users, these issues have become much less important than implementing a system that meets user needs. As described previously, these potential deficiencies are assessed in step 5 and cor¬rected in step 6 of the evolutionary methodology in
Figure 10.11.
Figure 10.11.
The only other potential disadvantage is related to managing user expectations. Frequently, a prototype system appears to be so useful that users are reluctant to wait for a weil-functioning, well-Jocumented oper¬ation:lI system. It is easy to see how users can become impatient with lengthy IS development processes that require 10ls of preliminary conceptual work once they have been exposed to evolutionary methodol¬ogies. As described in the next section, this is why prototyping within an SDLC process has become a common practice.
As fourth-generation tools have become common¬place, the incorporation of a few steps of an evolu¬tionary process into an SDLC methodology has also become common. Here we describe two ways that prototyping is commonly incorporated into an SDLC process.
First, a prototype is used to help users define the system requirements for user interfaces in the Defini¬tion phase of an SDLC process. As shown in Figure 10.12, the SDLC process still begins with a feasibility analysis. But for the requirements definition step (step 2), IS specialists use screen painting tools to pro¬duce initial versions of screens and reports that users can experiment with. This is an example of a toy sys¬tem prototype in which the screen designs are not con¬nected to a live database. After the requirements have been determined with the help of the prototype, the remainder of the steps in the SDLC process remain the same. However, the system builders can also make use of the screens during the design and build steps and may actually use computer code generated by the pro¬totyping tools in the final system.
The second way prototyping is used is more com¬plex and includes a pilot implementation of a working prototype. This type of pi lot differs from the pilot con-Figure 10.12 SDLC with Prototyping to Dcfiue Requirements
version strategies discussed for the Implementation phase of the SDLC process. Rather, the intent here is to use a scaled-down prototype in only a minimal number of locations within the organization in order to assess its feasibility in an operational setting. As shown in Figure 10.13, the Definition phase of the SDLC process is replaced by three steps of an evolu¬tionary approach. After basic requirements are deter¬mined (step 1), a working prototype is developed (step 2). The initial prototype may not use "live" data, but is sufficiently developed to demonstrate a technical solution using hardware and software components that has not been used before in a real-world setting by the
Figure 10.13 Combination Prototyping and SDLC Life Cycle
developers and users. In step 3 the prototype is extended to become a working prototype that can be piloted with a subset of the targeted users.
This combination prototyping/piloting approach is especially useful for large, risky projects that involve technological and/or organizational risks. For example, one major objective may be to demonstrate the basic capabilities or provide a proof-of-concept test of a technical solution. A second major objective may be to get buy-in to the proposed system by exec¬utive sponsors. By working with a prototype with live data, user-managers can evaluate the potential benefits :md risks of the new appiication in an operational set¬ting. The expectation is that this prototype, developed at minimal cost, will be changed significantly if an operational system is built. For example, changes in functionality based on using the pilot, as well as changes in the technology, are anticipated before the final system will be implemented at all locations. The prototype is used to help "sell" the system to key users and to those who have budgeting authority.
If the pilot is successful, a formal SDLC process begins with step 4. What was learned in the step 3 pilot using the system prototype becomes the system design specifications for building the actual system. The learning from the pilot step also helps users pre¬pare for the organizational changes needed to imple¬ment the full system. The remaining steps match the typical SDLC process.
The demands for speedier development of new appli¬cation systems have steadily increased over the past decade. In this section we briefly discuss four examples of approaches that have been shown to result in faster development of high-quality customized applications.
Joint application design (JAD) is a technique in which a team of users and IS specialists engage in an intense and structured process to develop system requirements or review a major system design deliver¬able. A lAD session could last several hours or could be held over several consecutive days. It is often held at a location removed from the participants' usual workplace so they can concentrate on this task without interruption. The technique is used within an SDLC methodology as well as within an evolutionary methodology. It is also one of several techniques and tools associated with rapid application development and may involve the use of a computer-assisted soft¬ware engineering tool.
The primary objective of the lAD technique is to minimize the total time required for information gath¬ering from multiple participants. It provides a forum for user representatives to work through areas of dis¬agreement; this is especially important when cross¬functional systems are being developed. The lAD session is led by a facilitator who is not only skilled in systems analysis and design techniques, but is also skilled in managing group interactions. A person out¬side the organization is sometimes used in this facili¬tator role in order to have a neutral third party who can resolve conflicts and keep the group focused on the lAD session outcomes. An additional benefit associ¬ated with the use of this technique, then, is the achievement of a shared understanding among user¬managers and IS specialists.
Computer-assisted software engineering
(CASE) refers to a collection of software tools used to automate some or all phases of an SDLC process. Most CASE tools are designed to support one or more structured development methodologies (see Chapter 9) and have a pricetag anywhere from $5,000 to $15,000 per workstation (lIS Analyzer, 1993).
Not all CASE tools have the same functionality.
Some are only front-end analysis tools (upper-CASE) that support the Definition and system design steps of the SDLC. For example, an early entry in the front¬end CASE marketplace was Excelerator by Intersolv. ExceJerator provided a set of integrated tools to support the development of system specifications, production of the system documentation, and manage¬ment of the project. In addition to screen and report generators, it has an intelligent drawing tool to support the development of diagrams for process and data modeling. The CASE tool maintains a comprehensive database (repository) of all diagrams, data element specifications, processing logic, and other documenta¬tion associated with the project and makes it electron¬ically accessible to all members of the project team with the appropriate security levels. For example, a data dictionary entry is automatically generated for each data flow and each data store in a data flow diagram (process model). CASE systems also include various design analyzers that check for violations of system decomposition rules and other consistency checks. CASE systems often include interfaces to fourth-gen¬eration languages to make it easier to build a proto¬type system.
Lower-CASE tools are back-end code generators that automate some of the building steps of the SDLC by generating computer code from high-level specifi¬cations. These tools can also be used to automate maintenance: Changes in computer code can be gen¬erated from changes in system designs. There are also full-cycle CASE systems called Integrated-CASE or I-CASE tools that combine front-end and back-end functions to produce a working system. In the sidebar "Life-Cycle Software Development Tools;' we describe a tool based on the methodology of IS guru lames Martin, marketed by Sterling Software.
CASE tools have been reported to have a major impact on system development productivity-includ¬ing faster development and improved system quality during the initial development process. In the early 1990s, for example, there were reports of development times cut to one-third of the time required for tradi¬tional methods (liS Analyzer, 1992). However, the ini¬tial introduction of CASE tools into an organization requires a major commitment by management to a structured development methodology that is embed¬ded within the CASE tool. The start-up costs are also high due to the need for substantial IS specialist train¬ing costs.
Early users have reported that it may take several years before the benefits of CASE implementation outweigh its costs. If an organization is changing its methodology as it introduces a CASE tool, the cultural changes for an IS professional can be significant. Orlikowski (1989) has found that IS specialists inter¬ested in a technical career may be more resistant to CASE tool implementation than those on a manager¬ial career path. This appears to be due to the lack of flexibility of many of the tools. A lack of compatibil¬ity across CASE tools has also been an implementa¬tion barrier. Although the adoption of CASE tools within U.S. companies has been slower than originally expected, a high penetration has been forecast for the end of the 1990s.
Rapid application development (RAD) is a methodology based upon the use of lAD, prototyping, and Integrated-CASE (I-CASE) tools with the objec-
[Adapted from www.sterling.com and www.ti.com]
tive of rapidly producing a high quality system. The RAD methodology includes the three life cycle phases, combining the SDLC sequence with an itera¬tive, continuous improvement approach. I-CASE tools are used to support rapid prototyping, and lAD sessions are used for design reviews. Unlike the evo¬lutionary methodology discussed in this chapter, the end-prototype becomes the actual system.
RAD is a methodology that works well in a busi¬ness environment characterized by rapid change. The smaller design teams and shorter development times associated with RAD also can lead to lower develop¬ment costs. Some organizations adopting RAD approaches require that all projects fit within a short timebox-such as six months (Clark et aI., 1997). However, an accelerated approach also has its down¬sides. For example, programming and formatting stan dards may be sacrificed, and the system component~ may need further development to be reusable.
Object-Oriented (0-0) methods also hold great promise for producing better systems at less cost, and tools to support this approach are becoming more readily available. However, the learning curve associ¬ated with the adoption of object-oriented technology is even greater than the learning curve associated with CASE tools. Nevertheless, by the second half of the 1990s, success stories of large-scale systems using 0-0 approaches began to appear (LaBoda and Ross, 1997). As discussed in Chapter 9, the productivity gains associated with 0-0 technologies are primarily due to the reusability of the system components. How¬ever, 0-0 analysis requires that analysts learn new concepts, terminology, and representation methods, and the development of reusable objects requires con¬siderable expertise. By the end of the decade, compa¬nies are expected to be purchasing libraries of objects from vendors and using these objects to quickly develop applications that are more customized than is feasible with the typical purchased package.
SPECJAL [S5UE: YEAR 2000 MAINTENANCE
The turn of the century has created significant chal¬lenges for systems development managers and an unanticipated demand for IS programmers skilled in older languages such as COBOL. This is because more than two decades ago, when computer systems had much less memory and storage space than they have today, information systems were designed to use a two-character forn1at for calendar year fields. More specifically, dates were stored in a six-digit date field, such as MMDDYY, in order to conserve on processing and storage.
Why did this convention become a major mainte¬nance problem as we approached the Year 2000? Dates are used in calculations for a wide variety of business processes. Because only a two-digit year field is stored, calculations involving the year 2000 (and beyond) involve only the stored two digits. For exam¬ple, in 1999 the difference from 1995 will be calcu¬lated as 4 (99 minus 95), whereas in 2000 the difference will be. calculated as -95 (00 minus 95). This means that, for example, when a credit card expiration date, retirement benefit, or product delivery date is calculated for the year 2000, an error will occm. Unfortunately, easy technological solutions (referred to in the field as "silver bullets") are not aV3ilable. Instead, date-based calculations and logic statements within old applications must be identified, rewritten, and tested, and the revised system must be implemented before the date error becomes a problem for the business process supported by that application.
Why wasn't this obvious problem corrected sooner? IS specialists have of course known there was a potential problem for some time. However, many of the systems that need to be revised were developed well over a decade ago. Until organizations got closer to the calendar dates when Year 2000 calculations would become a problem, it was difficult to get orga¬nizational funding for the clean-up effort. Significant maintenance dollars are requiredjust for the organiza¬tion to maintain the status quo; the ROI for Year 2K projects is measured in terms of business survival, not growth in business revenues (Wiliiamson, 1996). Further, some of these older applications are being replaced by new applications that are "Year 2K com¬pliant." Major software vendors such as SAP began to include the avoidance of the year 2K problem in their software advertisements by the mid-1990s.
"It s not even as satisfying as fixing a roof We get absolutely nothing out of it. We get to stay in business, that salt." -John Lutz, president of Mason Shoe, New York Times, April 7, 1997 Public awareness of the Year 2K maintenance problem increased dramatically in the mid-1990s. For example, the average business employee of 1998 knew that the date problem affects both computer hardware and software, including ATM machines, air traffic systems, and wftware programs that calculate credit card payments (see sidebar "Year 2000 Predic¬tions"). Estimates for 1997 global costs for Year 2K fixes range from $300 billion to twice that amount, and actual costs are expected to be even higher due to litigation costs for Year 2K glitches. One can safely predict that not all tested changes will be fault-free; that's why some enterprising firms are selling Year 2K Insurance.
By early 1998, some IS-related impacts of the Year 2K problem were already observable. Software
Bank vaults refuse to open.
Building security systems fail, refusing to read coded cards or keys.
Production schedules at all kinds of manufacturing facilities are corrupted by improper date-coding.
• Automatic elevator programs crash, freezing high¬rise elevators.
Airline flight schedules are thrown into disarray because of flaws in the air traffic control system computers.
houses were advertising Year 2K "ready" applications that could not only help a firm avoid fixing an old legacy system, but also could help achieve new bene-
Figure 10.14 Typical Workload for Large Year 2K Projects
Building security systems fail, refusing to read coded cards or keys.
Production schedules at all kinds of manufacturing facilities are corrupted by improper date-coding.
• Automatic elevator programs crash, freezing high¬rise elevators.
Airline flight schedules are thrown into disarray because of flaws in the air traffic control system computers.
houses were advertising Year 2K "ready" applications that could not only help a firm avoid fixing an old legacy system, but also could help achieve new bene-
Figure 10.14 Typical Workload for Large Year 2K Projects
fits. CIO's were being warned to also assess Year 2K compliai1ce of their suppliers, customers, and other business partners (Kirsner, 1998). Retired COBOL programmers had reportedly come out of retirement as a result of the lure of short-term jobs with big pay¬checks. Major consulting firms also reported turning down requests for Year 2K maintenance projects by client firms because of their lack of skilled IS resources to assign to these types of projects. Class¬action suits against technology vendors have already been filed in anticipation of software problems (Gunn, 1998).
In addition to contributing to a global shortage of IS professionals, what are some of the other antici¬pated IS management impacts of the Year 2000 crisis? Because 60 percent of the typical effort of a Year 2K project is directed at testing the changes in production systems (see Figure 10.14), organizations have reported greatly improving their testing processes. In general, there has also been a greater endorsement of a standard methodology and a repeatable process (Williamson, 1996). A likely outcome, then, is both improved processes and better project management skills within IS organizations.
System development by the IS department using the life cycle methodology is the traditional way to obtain new computer systems and to maintain them. Devel¬opment by the IS organization using some or all of the SDLC methodology steps is still the most viable approach when the system is large, complex, and serves multiple organizational units and when suitable packaged software is not available. Development by
the IS organization using some or all of the evolution¬ary methodology steps is a more effective approach when multiple versions of a prototype system can be used to help users and IS specialists move cost effec¬tively from a set of basic requirements to a fully ftmc¬tional system design. Today, a prototyping approach is often incorporated into an SDLC process to exploit the system definition strengths of the evolutionary approach and the system construction and implemen¬tation strengths of the SDLC approach. A combination proto typing/piloting approach is especially useful when the systems project is characterized by major technological and/or organizational risks. New meth¬odologies that exploit the advantages of both the SDLC and prototyping are also being pursued by today's organizations.
Whether traditional SDLC, prototyping, or some combination of the two is used, it is the responsibility of both user-managers and IS specialists to ensure that the system that is installed meets the needs of the busi¬ness at the time of installation. IS specialists typically hold primary responsibility for all system building and the conduct of the project on a day-to-day basis, while sharing the overall responsibility for managing the project with user management. User-managers are relied on to sponsor the system and champion its development and implementation, and to participate actively in the development process. If the user spon¬sor and user champion roles are not played well, users will suffer on a day-to-day basis as they attempt to achieve the envisioned benefits with a suboptimal system.
The responsibilities of user sponsors, user cham¬pions, and user representatives for customized appli¬cation development projects include the following:
• conceptualizing how a new system can benefit the business
• justifying the new system to the organization, including establishing a business value for potential intangible benefits
• championing the new system throughout the devel¬opment process and assigning user-managers and end-users to participate
• participating in the definition of a system's require¬ments and either reviewing all formal written requirements specifications to ensure they are com¬plete and accurate or testing system prototypes to
ensure they are functional system solutions that match the business needs• conceptualizing how a new system can benefit the business
• justifying the new system to the organization, including establishing a business value for potential intangible benefits
• championing the new system throughout the devel¬opment process and assigning user-managers and end-users to participate
• participating in the definition of a system's require¬ments and either reviewing all formal written requirements specifications to ensure they are com¬plete and accurate or testing system prototypes to
• adopting joint project leadership roles as necessary
• conducting rigorous user acceptance testing
• redesigning the organization to take advantage of the new system and managing the organizational changes before, during, and after implementation
• overseeing effective use of the new system over its life, including the timely initiation of maintenance requests
1. Describe the steps in the systems development life cycle (SDLC) as presented in this chapter.
2. Describe the user-manager roles in each step of the SDLC.
3. Describe the role of the IS specialists in each step of the SDLC.
4. Describe how the SDLC methodology is also a project management tool.
• overseeing effective use of the new system over its life, including the timely initiation of maintenance requests
1. Describe the steps in the systems development life cycle (SDLC) as presented in this chapter.
2. Describe the user-manager roles in each step of the SDLC.
3. Describe the role of the IS specialists in each step of the SDLC.
4. Describe how the SDLC methodology is also a project management tool.
5. What are the characteristics of a high-quality application system?
6. Describe the role of documentation in the SDLC methodology.
7. Describe the four different strategies for conver¬sion to a new application system.
6. Describe the role of documentation in the SDLC methodology.
7. Describe the four different strategies for conver¬sion to a new application system.
8. Why is an accurate requirements definition a critical success factor when using the SDLC approach?
9. Describe the steps of an evolutionary methodol¬ogy when prototyping is used as part of the devel¬opment process. How does this differ from the SDLC process described in Question I?
10. Describe the disadvantages of an SDLC process.
Which disadvantages are addressed by a prototyp¬ing approach?
11. Describe two ways that a prototyping approach is used within the traditional SDLC methodology.
9. Describe the steps of an evolutionary methodol¬ogy when prototyping is used as part of the devel¬opment process. How does this differ from the SDLC process described in Question I?
10. Describe the disadvantages of an SDLC process.
Which disadvantages are addressed by a prototyp¬ing approach?
11. Describe two ways that a prototyping approach is used within the traditional SDLC methodology.
12. Define JAD and CASE, and comment on how they can be used in projects developed with either the traditional SDLC process or the evolutionary method.
13. Describe what was meant by references to a Year 2K problem prior to the end of 1999.
L Discuss the strengths and weaknesses of the SDLC methodology for developing application systems.
2. Your IS department believes that it is responsible for making sure the requirements of the system are properly defined, but in this chapter the user¬manager's responsibility for defining require¬ments is emphasized. How can you reconcile these two points of view?
3. There have been many failures in the development of application systems using the traditional SDLC. Discuss what might be some of the pri¬mary reasons for this high failure rate.
4. Discuss some of the approaches that can be used to justify an application system when most of its benefits are intangible.
5. Describe the role of the systems analyst in the development of an application system using the SDLC. Then compare it to the role of the systems analyst for a prototyping approach.
6.' Some IS specialists contend that end-prototypes are poor technical solutions. Comment on why this may be true.
7. Discuss why an application might be built using prototyping as part of the SDLC methodology, rather than by an evolutionary methodology alone.
8. Discuss the roles of the executive sponsor and user champion in the in-house development of a customized application. Under what situations might these roles be played by the same or differ¬ent persons?
9. Discuss the role of the project manager in the in¬house development of a customized application. Under what situations might IS managers and user-managers serve as co-leaders of a project?
L Discuss the strengths and weaknesses of the SDLC methodology for developing application systems.
2. Your IS department believes that it is responsible for making sure the requirements of the system are properly defined, but in this chapter the user¬manager's responsibility for defining require¬ments is emphasized. How can you reconcile these two points of view?
3. There have been many failures in the development of application systems using the traditional SDLC. Discuss what might be some of the pri¬mary reasons for this high failure rate.
4. Discuss some of the approaches that can be used to justify an application system when most of its benefits are intangible.
5. Describe the role of the systems analyst in the development of an application system using the SDLC. Then compare it to the role of the systems analyst for a prototyping approach.
6.' Some IS specialists contend that end-prototypes are poor technical solutions. Comment on why this may be true.
7. Discuss why an application might be built using prototyping as part of the SDLC methodology, rather than by an evolutionary methodology alone.
8. Discuss the roles of the executive sponsor and user champion in the in-house development of a customized application. Under what situations might these roles be played by the same or differ¬ent persons?
9. Discuss the role of the project manager in the in¬house development of a customized application. Under what situations might IS managers and user-managers serve as co-leaders of a project?
10. In many companies there is a history of a lack of trust between the IS department and the user com¬munity. Pretend that you are a user champion for a new system in an organization with such a history. 'What can you do to help overcome this lack of trust and help IS specialists work well with users so that this system development project is a success?
11. It has been said that a system withuut good docu¬mentation is worthless. Provide support for this statement. Then comment on how today's advanced tools may avoid this problem.
12. Discuss how some modern tools (such as CASE), techniques (such as JAD), and methods (such as RAD) help today's IS organizations overcome the disad-;antages of the traditional SDLC methodology.
13. According to some observers, Year 2K projects resulted in better project management and sys¬tems testing skills within the IS professional com¬munity. Explain why this may be true.
1987. "The new economics of computing." liS Analyzer 25 (September): 10.
1992. "From application development to software engineer¬ing." liS Analyzer 30 (July): 7.
11. It has been said that a system withuut good docu¬mentation is worthless. Provide support for this statement. Then comment on how today's advanced tools may avoid this problem.
12. Discuss how some modern tools (such as CASE), techniques (such as JAD), and methods (such as RAD) help today's IS organizations overcome the disad-;antages of the traditional SDLC methodology.
13. According to some observers, Year 2K projects resulted in better project management and sys¬tems testing skills within the IS professional com¬munity. Explain why this may be true.
1987. "The new economics of computing." liS Analyzer 25 (September): 10.
1992. "From application development to software engineer¬ing." liS Analyzer 30 (July): 7.
Beath, Cynthia M., and Wanda 1. Orlikowski. 1994. "The contradictory structure of systems development method¬ologies: Dcconstructing the IS-user relationship in infor¬mation engineering." Information Systems Research 5 (December): 350-377
Boehm, Barry. 1976. "Software engineering." IEEE n-ans¬actions on Computers C-25 (December): 1226-1241.
Boehm, Barry. 1976. "Software engineering." IEEE n-ans¬actions on Computers C-25 (December): 1226-1241.
Boehm, Barry. 1981. Soffl.vare Engineering Economics.
Englewood Cliffs, N.J.: Prentice-Hall.
Bollinger, Terry B. and Clement McGowan. 1991. "A criti¬cal look at sofnvare capability evaluations." IEEE Soft¬Il'Qre (July I): 25--46.
Boynton, Andrew c., Robert W. Zmud, and Gerry C. Jacobs. 1994. "The influence of IT management practice un IT use in large organizations." MIS Quarterly 18 (Septem¬ber): 299-318.
Englewood Cliffs, N.J.: Prentice-Hall.
Bollinger, Terry B. and Clement McGowan. 1991. "A criti¬cal look at sofnvare capability evaluations." IEEE Soft¬Il'Qre (July I): 25--46.
Boynton, Andrew c., Robert W. Zmud, and Gerry C. Jacobs. 1994. "The influence of IT management practice un IT use in large organizations." MIS Quarterly 18 (Septem¬ber): 299-318.
Broder, John M., and Laurence Zuckerman. 1997. "Com¬puters are the future but remain unready for it." New York Times (April 7): I, 11.
Clark, Charles E., Nancy C. Cavanaugh, Carol V Brown, and V Sambamurthy. 1997. "Building change-readiness capabilities in the IS organization: Insights from the Bell Atlantic experience." MIS Quarterly 21 (December): 425--455.
Clemons, Eric. 1991. "Evaluation of strategic investments in information technology." Communications of the ACM 34 (I): 23-36.
Colter, Mel A. 1984. "A comparative examination of sys¬tems analysis techniques." MIS Quarterly 8 (March): 51-66.
Clemons, Eric. 1991. "Evaluation of strategic investments in information technology." Communications of the ACM 34 (I): 23-36.
Colter, Mel A. 1984. "A comparative examination of sys¬tems analysis techniques." MIS Quarterly 8 (March): 51-66.
Davis, Gordon B. 1982. "Strategies for information require¬ments determination." IBM Sy:stems Journal 21 :4-30.
DeMarco, Tom. 1982. Controlling Software Projecl:s. New York: Yourdon Press, Inc.
Fedorowicz, Jane, and Janis Gogan. 1997. "Metropolitan Transportation Authority: On track with the year 2000 project?" PH Case Series for Management Infor¬mation Systems. Edited by Joyce Elam, Prentice-Hall. (www.prenhall.com/elam)
Gane, Chris, and Trish Sarson. 1979. Structured Systems Analysis: Tools and Techniques. Englewood Cliffs, N.J.:
Prentice-Hall, Inc.
Gunn, Eileen P. 1998. A new legal target: The millennium bug. Fortune 137 (April 27): 438.
Hartwick, Jon, and Henri Barki. 1994. "Measuring user participation, u~er involvement, and user attitude." MIS Quarterly 18 (March): 59-79.
Kirsner, Scott. 1998. "The Ripple Effect." CIO II (April 1): 28-32.DeMarco, Tom. 1982. Controlling Software Projecl:s. New York: Yourdon Press, Inc.
Fedorowicz, Jane, and Janis Gogan. 1997. "Metropolitan Transportation Authority: On track with the year 2000 project?" PH Case Series for Management Infor¬mation Systems. Edited by Joyce Elam, Prentice-Hall. (www.prenhall.com/elam)
Gane, Chris, and Trish Sarson. 1979. Structured Systems Analysis: Tools and Techniques. Englewood Cliffs, N.J.:
Prentice-Hall, Inc.
Gunn, Eileen P. 1998. A new legal target: The millennium bug. Fortune 137 (April 27): 438.
Hartwick, Jon, and Henri Barki. 1994. "Measuring user participation, u~er involvement, and user attitude." MIS Quarterly 18 (March): 59-79.
LaBoda, Douglas M., and Jeanne W. Ross. 1997. "Travelers Property Casualty Corporation: Building an object environment for greater competitiveness." Center for
Information Systems Research, Sloan School of Man¬agement, MIT, WP No. 301.
Orlikowski, Wanda J. 1989. "Division among the ranks: The social implications of CASE tools for system develop¬ers." Proceedings of the Tenth International Conference on Information Systems: 199-210.
Orlikowski, Wanda 1., and Debra J. Hofman. 1997. "An improvisational model for change management: The case of groupware technologies." Sloan Management Review 38 (Winter): 11-22.
Pastore, Richard. 1992. "Many happy returns." CIO 5 (June 15): 66-74.
Radding, Alan. 1992. "When non-IS managers take con¬trol." Datamation 38 (July I): 55-58.
Robey, Daniel. 1987. "Implementation and the organiza¬tional impacts of information systems." Interfaces 17 (May-June): 72-84.
Sterling Software. Web site at http://www.sterling.com. Texas Instruments. Web site at http://www.ti.com. Williamson, Miryam. 1996. "Will your systems survive the
year 2000?" CIO 9 (September 15): 53f.
Information Systems Research, Sloan School of Man¬agement, MIT, WP No. 301.
Orlikowski, Wanda J. 1989. "Division among the ranks: The social implications of CASE tools for system develop¬ers." Proceedings of the Tenth International Conference on Information Systems: 199-210.
Orlikowski, Wanda 1., and Debra J. Hofman. 1997. "An improvisational model for change management: The case of groupware technologies." Sloan Management Review 38 (Winter): 11-22.
Pastore, Richard. 1992. "Many happy returns." CIO 5 (June 15): 66-74.
Radding, Alan. 1992. "When non-IS managers take con¬trol." Datamation 38 (July I): 55-58.
Robey, Daniel. 1987. "Implementation and the organiza¬tional impacts of information systems." Interfaces 17 (May-June): 72-84.
Sterling Software. Web site at http://www.sterling.com. Texas Instruments. Web site at http://www.ti.com. Williamson, Miryam. 1996. "Will your systems survive the
year 2000?" CIO 9 (September 15): 53f.
