Chapter 16. System Development Process

Transcription

1 Chapter 16 System Development Process Every information system is developed through a process with a particular composition. Steps of this process cover defining the system goals, analyzing existing business and its system support, and creating a system improvement or a new system. As IS and business processes are interrelated, system development implies some change in business. Or put another way, in order to change business processes, IS have to be changed. System development involves many parties and possibly significant resources. Although coming up with a well-designed system is the goal commonly shared, it is not easy to accomplish. This chapter discusses the system development process, and some principles of good system design. Getting Control over System Development All modern organizations have some IS staff that takes care of organizational IS. The larger the organization, the larger the size of IS staff. There may be a separate IS department that employs databases specialists, programmers, network experts, user support staff, and system analysts, to name a few typical IS jobs. Larger IS departments do not only take care of current systems but they also work on improving these systems and building new ones. If the IS function does not have the system development capability, the company hires system developers (consultants) to do the job. When IS were introduced in business on a large scale in the 1960s, the systems development was rather chaotic. Every company or consultant had their own way of developing systems. Gradually, a process with defined steps emerged and became the standard. It was called waterfall model or structured methodology. More recently, newer models emerged aiming at shortening the development time. In any model, system developers have to perform certain activities. These will be explained in the following discussion. The basic system development process is represented in Figure 1. In brief, a system development process start with setting the goals the IS needs to meet, proceeds to exploring current business and data management in order to identify problems and solutions, and moves to making or purchasing software. Then, the software is put on hardware, tested, revised as needed, and the system (or just a part of it) is released to users.

2 This process apparently has a clear composition, which is why it was called structured methodology when it was introduced. Each process step was supposed to cover a certain period of time taking weeks or months. The steps were called phases, and they ran in sequence one after another, with no turning back. The transition to a new phase was defined by a time schedule rather than by deciding whether all the work was completed well. For these reasons, the methodology has been called waterfall based on the idea that the water can flow just downward. A year or more could lapse between the start and the end point of the process. The waterfall process did a good job for many years. However, business accelerated and could not afford such long development times. IT changed as well as programming tools, which allowed for a faster system development. A system that was built via the waterfall model and took two or more years to develop turned to be obsolete at the time of release. All this motivated a search for more rapid methodologies. Several such methodologies have been created and successfully used. The waterfall model is still useful for smaller projects. All the new methodologies of systems development are fast. They still use the same development activities (plan, analyze, design, etc.). However, these are applied to smaller parts of a system rather than a system as a whole. Therefore, an IS is approached in a piecemeal fashion, usually starting from core functionality and expanding to other functions over time. For example, a system function is coded, and then a part of the database supporting it is developed. At the same time, another developer can create a screen (or a screen part) for accessing this function. This whole system part is then tested, revised if necessary, and then developers proceed to the next system part. This way, a whole system function can be developed within days. Figure 1. System development process System Planning The system planning is the activity of defining business goals that a system needs to meet. Remember that IS are tools for improving the organization (business processes) and business performance. Therefore, the goals before an IS can be to optimize process design, improve process performance (both studied previously) or to define new processes. For example, new processes in our time keep emerging in the domain of B2B e-commerce, such as logistics that is part of electronic supply chains. New marketing processes that reach out to social media also keep emerging.

3 While a new business process represents an improvement in the organization of a company, its goal is to improve the revenue side or the quality of customer service. So, any improvement has the ultimate economic goals. In the for-profit sector, business planning of IS must address the costs and financial returns expected from an IS. Capital budgeting models are used, as it will be discussed in the chapter on IS economy. Business planning subsequently gives way to more technical activities discussed below. System Analysis The system analysis is the activity of understanding the present business processes and supporting systems if these exist. This is the concept of As-Is state discussed in Chapter 8. A system analyst analyzes present organizational processes (design, performance) in order to identify potential problems, that is, what needs to be fixed. The system analyst approaches both end-users and managers to interview them and learn about their informing needs. The system analyst also observes the ongoing work and examines business documents and communications. The result of this effort is a set of data diagrams and process diagrams (and possibly some others) that portray the As-Is state of an IS and corresponding business processes. The first goal of a system analyst is to understand what the problems are. Then, the system analyst defines point by point the desired state of an IS and corresponding business processes. This is called system requirements. In Chapter 8, system requirements were implied in terms of the To-Be system. Therefore, a system requirement is a definition of a to-be system aspects that can be: a system function a data model a non-functional characteristic. The skills of data- and process analysis studied in this course are the core of system analysis. A system function is represented with the process diagram. A data model is represented with the schema when the analyzed database is relational. And non-functional characteristics (processing speed, memory size, etc.) are expressed in text format. System Design The system design is the activity of defining system components that will meet system requirements resulting from system analysis. While the system analysis identifies what problems need to be addressed in order to improve an IS or build a new one, system design defines how to do it. Therefore, system analysis is a creative work of identifying solutions for business and system problems. System analysts get design ideas by looking at comparable systems, learning from software vendors, the literature, and based on their experience.

4 New design typically includes the data model, application software, and user interface. Hardware upgrade or change is complimentary. The As-Is diagrams are revised and new diagrams and other documents created to show new design. Constructing System The system construction is the activity of physically making a system by implementing system design into software. That is why this activity is also called system implementation. (Note that the system is not put out at work yet, which is what some people think when they use the word implementation in everyday language.) Apparently, application software is in the focus of the system construction activity. Software can be written or purchased as the so called off-the-shelf software, and then put together according to the design created. In newer rapid models of system development, various techniques are used to ensure that the development speed does not compromise the quality of software (see the window). Installing and Testing System The system installation is the activity of setting up software, hardware and facilities into the operational stage. Software is mounted on hardware, cabling completed, and spaces for the system equipment arranged. When a system is built piece a piece in rapid methodologies, the system is installed as it gradually grows. System testing is the activity of evaluating the performance of the installed system. There are several tests, such as unit testing by experts, system testing by experts, and acceptance testing by users. In rapid methodologies, the usual test to be performed first is unit testing. It is performed by experts who assess the workings of an individual system function. For example, in a sales management system of a wholesale company, one function can be Create a customer order. A tester would try to determine if the function accepts and stores all the needed data, then whether the complete record is retrieved upon user request. Another function could be Set a credit limit for customer. A tester would try to determine if issuing a customer order above the limit would be prevented by the system. System testing is performed also by experts in order to determine if all system functions work on a sample dataset. There are different system tests. One is by loading it with a normal

5 number of users; another test is by overloading the system to determine what may fail under stress. Users are in charge of acceptance testing. This test is similar to system testing in the scope. However, order in which system functions are called is arbitrary. Many principles of good design surface on this test (see the section below). The test can always bring surprises because it is difficult to predict entirely the user behavior and what will/will not get a passing grade. For example, the system may have good functionality but may not pass on the ease of use (i.e., the user interface aspect; more below). System Deployment Methods Deploying a system refers to releasing the system to users for regular use. This is when the main development stops, and the production stage of a system s life starts. This activity is also called system roll-out, going live, and otherwise. An IS can be released in a direct deployment manner (Figure 2). This means that the old system is completely switched off and the new system turned on. This is a clear-cut method that leaves no doubt as to what is the system of choice. It may also save the money, since just one system is run. However, this method comes at a higher risk since there is no assurance that the new system will function perfectly. Figure 2. Direct deployment Parallel deployment is an optional method aiming at reducing the risk of direct deployment. The old and the new system are run at the same time. In Figure 3, the parallel use transpires between the time points New in and Old out. So, if something fails in the new system, the old system compensates without any delay. However, this method doubles everything data entry, processing resources, and labor. Therefore, the costs are also doubled. The method is suitable for high-stakes domains, such as banking. The direct and parallel methods can be combined so that the new system is switched in part, the equivalent part of the old system is run for some time, and then switched off. Risks and costs are more balanced this way. Figure 3. Parallel deployment Maintaining System in Production Stage Once the system is rolled out to regular use, the development continues in a smaller scope. The system maintenance refers to the activity of correcting system errors and making smaller additions to software and hardware.

6 Errors in software ( software bugs ) are almost inevitable, no matter how much effort is put in assuring the software quality. These bugs must be corrected as part of system maintenance. As well, the system is regularly evaluated with regard to the rate of adoption, user satisfaction, and costs and business. User-identified problems must be fixed as part of system maintenance. Furthermore, system modifications may be inspired by changes in business needs. For example, an increase in operations calls for enlarging the data storage. New reports may need to be programmed in order to answer new business questions. In addition, attending to system security requires continuous interventions. Adding new software and hardware can also be initiated by vendors and by changes in technology. All these are instances of system maintenance. Good System Design As the purpose of an IS is to enable informing of the user, an effective IS not only fits well with its corresponding business process but it also has to be adopted and appreciated by the users, and enabling them for efficient work. Specifically, a well-designed IS minimally needs to: Do the work it is planned to support Be easy to learn and use Support efficient work. To do the work it is planned for, a system has to fit well with the corresponding business process or processes. Process steps are system steps, and the other way around. Systems not only store and create data, but TPS/MIS literally carry out operations, DSS perform difficult decision making steps, and so on. A well-designed IS should also be easy to learn how to use and to actually use. This is the user interface responsibility. Paying attention to the user perspective has become very important with the widespread use of IS. Sometimes, huge investments just partially (if at all) pay back because users reject the system. User interface may be a big reason for this. This is discussed more in the chapter on system adoption. At this point, let us focus on several important aspects of the ease of learning and use: menu design, screen complexity, navigation, and error correction. A good user interface has quality menu design. This means that screen items, such as labels and buttons are intuitive. Typical errors are in using a technical language users do not understand or inscribing button with images that make no common sense. Also, the sequence of screens to be used in completing a single task should not be too long.

7 Screens should be reasonably complex rather containing an excessive amount of items. Some ERPS provide bad examples in this respect. Simpler screens enhance the visibility of items and are easier to learn and actually use. A good user interface almost never gets a user confused or lost in moving around and executing the desired procedures. This movement of users is called navigation. The term is borrowed from physical environments. It applies well to simple online stores as well as to complex systems that simulate geographical areas. Second Life is one such system which simulates streets, cities, countries, and beyond a whole virtual world. (Figure 4). Note that different people may have different ways of finding and remembering their way in physical space. This may have similarities with their navigation within the graphical space created by user interface screens. This space is sometimes called cyberspace and Second Life is a perfect example of it. Some studies indicated gender differences in navigation. For example, women were better at navigating according to various tokens (images, labels, etc.) that they could link mentally in whole networks. In contrast, men were better in a linear navigation based on geographical poles. The last item of learn/use easiness refers to easy tracking and correction of errors a user can commit in navigation. For example, if a user gets lost, she should be able to go easily a step back or to restart the whole procedure if so desired. Figure 4. A screen from the Second Life Website Finally, the third characteristic of good user interface has to do with enabling efficient execution of users work. As just discussed, a good user interface is the necessary condition for a quick work. Well-designed application software is another. Non-technical characteristics of a system also contribute (e.g., fast hardware, and fast data transfer) since these directly impact on process performance aspects of time and cost. Good system design is always important to achieve. But accomplishing it is not easy, which even the brief discussion above demonstrates. Usually, there are trade-offs between design aspects. For example, rich system functionality may fit well with the corresponding business processes, while on the other hand such functionality requires more complex screens. This is

8 usually the case with ERPS. Or visibility of the part of screen where the output is displayed may come at the expense of a complex menu structure. This applies to differences between the drop-down menus in earlier versions of MS Office as opposed to the current tabs-based menus. In any case, good system design remains a worthy goal to pursue with every new IS. Questions for Review and Study 1. List activities of the basic system development process. 2. What is system requirement, how is it created, and what would be an example of it? 3. Discuss system analysis. 4. How is system design different from systems analysis? 5. How is an IS tested? 6. Why is system maintenance important? Give an example. 7. Discuss two principles of good system design. 8. What is user navigation and what does it depend on? Provide an example.