Chapter 14

1. Chapter 14 Building Information Systems Information Technology For Management 4th Edition Turban, McLean, Wetherbe John Wiley & Sons, Inc. Chapter 14

2. Chapter Objectives • Explain the concept of a systems development life cycle (SDLC). • Compare and contrast prototyping, rapid application development (RAD), joint application design (JAD), object-oriented (OO) development, extreme programming (XP), and traditional SDLC approaches to systems development. • Describe the contributions of component-based development and Web services to building information systems. • Evaluate alternatives (including the adoption of utility computing) to in-house systems development. • Discuss the major strategies, methods, and tools for building e-commerce applications. • Identify advantages and disadvantages of CASE tools. Describe alternative approaches to software process quality improvement. Chapter 14

3. Systems Development Life Cycle Provides a comprehensive formal framework for designing and developing systems for the effective and efficient processing of information. There is no universal, standardized version of the SDLC however a typical eight stage model is shown below. Note that the stages overlap: One stage may start before the previous stage ends. This is in contrast to the traditional waterfall method, in which the work flows through all the tasks in one stage before going on to the next stage. Also note that the processes can go backward more than one stage. SDLC: Formal and disciplined approach to systems development Chapter 14

4. SDLC - Stages • Stage 1: Project initiation.Projects often start when a manager has a problem or sees an opportunity. • Stage 2: Systems Analysis And Feasibility Studies consists of two phases of analysis: systems analysis and feasibility studies. • Systems analysis is the phase that develops a thorough understanding of the existing organization, its operation, and the situation that is causing a problem. Systems analysis methods include: • observation • review of documents • interviews • performance measurement. Chapter 14

5. SDLC – Stages Continued • Feasibility studies calculate the probability of success of the proposed solution and include: • Technology. • Economics. • Organizational factors • Legal, ethical, and other constraints. • Stage 3: Logical Analysis And Design emphasizes the design of system from the user’s point of view. It identifies information requirementsand specifies operations such as input, output, processing and storage. To represent logical processes and data relationships modeling tools such as data flow diagramsand entity-relationship diagramscan be used. The logical design is followed by a physical design. Chapter 14

6. SDLC – Stages Continued • Stage 4: Development or Acquisition the actual development or acquisition of the system. • IS personnel use the specifications to purchase the hardware and software required for the system. • Programmers write code for parts of the system. • Technical writers develop documentation and training materials. • IS personnel test the system • Users test prior to the actual implementation. • Stage 5: Implementation is an important stage; the system can fail here even if it has all the specified functionality. • Users need training • Forms need to be ordered • Help desk needs to be created Chapter 14

7. SDLC – Stages Continued • Stage 5: Implementation - continued • Also requires a conversion from a previous system. Conversion approaches include: • Parallel conversion: The old and new systems operate concurrently for a test period, and then the old system is discontinued. • Direct cutover: The old system is turned off, and the new system is turned on. • Pilot conversion: The new system is implemented in a subset of locations (for example, some of the branches in a large banking chain) and is extended to remaining locations over time. • Phased conversion: Large systems often are built from distinct modules. If the modules were originally designed to be relatively independent, it may be possible to replace the modules one at a time. • Stage 6: Operation. Post production environment. Chapter 14

8. SDLC – Stages Continued • Stage 7: Post-Audit Evaluationreviews the stages and processes to determine best practice methods. • Stage 8: Maintenance. Every system needs two regular types of maintenance: • Fixing of bugs • Regular system updating Therefore it is important that the design and development stages produce systems that are easy to maintain and are flexible enough to handle future expansion, upgrading and capacity increases. Chapter 14

9. Alternatives to SDLC methodologies The traditional SDLC approach works best on projects in which users have a clear idea about their requirements. Projects that require major changes in existing processes, through reengineering or development of new processes or those that build upon inter-organizational and international systems using Web technologies indicate a need for alternatives or supplements to conventional SDLC methodologies. • Some alternatives: • Prototyping • Joint application design (JAD) • Rapid application development (RAD) • Object-oriented development (OO) • Extreme Programming (XP) • Component-based development Chapter 14

10. Alternatives - continued • Prototyping (evolutionary development):Instead of spending a lot of time producing very detailed specifications, the developers find out only generally what the users want. The developers do not develop the complete system all at once. Instead they quickly create a prototype, which either contains portions of the system of most interest to the users, or is a small-scale working model of the entire system. After reviewing the prototype with the users, the developers refine and extend it. This process is continued until the final specifications. • Joint application design (JAD)is a group-based method for collecting user requirements and creating system designs. It is used within the systems analysis and design stages of the SDLC. Unlike the traditional SDLC, where the analysts interview individual users of the new information system to understand their needs JAD has a meeting in which all users meet simultaneously with analysts. During the meeting, all users jointly define and agree upon systems requirements. Chapter 14

11. Alternatives - continued • Rapid application development (RAD)methodologies and tools make it possible to develop systems faster, especially systems where the user interface is an important component. • GUI development environment:the ability to create many aspects of an ap­plication by “drag-and-drop” operations. • Reusable components:a library of common, standard “objects” such as but­tons and dialog boxes. • Code generator.After the developer drags-and-drops the standard objects into the design, the package automatically writes computer programs to im­plement the reports, input screens, buttons, dialog boxes, and so forth. • Programming language:such as BASIC, Object Pascal, or C. Chapter 14

12. Alternatives – continued • Object-oriented development (OO) is a fundamentally different view of computer systems than that found in traditional SDLC approaches. It begins not with the task to be performed, but with the aspects of the real world that must be modeled to perform that task. • Extreme programming (XP)is a discipline of software development based on values of simplicity, communication, and feedback. XP teams use a simple form of planning and tracking to decide what should be done next. Focused on business value, the team produces the software in a series of small, fully integrated releases that pass all the tests the customer has specified. Chapter 14

13. Alternatives – Component Based Development Component-based development is the evolution beyond objects. They are self-contained packages of functionality that have clearly defined, open interfaces that offer high-level application services. These business objects provide major chunks of application functionality (e.g., pre-programmed workflow, transaction processing, and user event notification) that can be connected together to create complete business applications. Chapter 14

14. Alternatives – Web Services A major application of Web services is systems integration, one of the major activities performed in systems development. The concept of components is based on the idea of gluing them together. Applications need to be integrated with databases and with other applications, users need to interface with data warehouses, business partner applications and databases must communicate, etc. • Web services are based on a family of key protocols • XML Language. Extensible Markup Language • SOAP. Simple Object Access Protocol • WSDL. The Web Services Description Language • UDDI. Universal Description, Discovery and Integration • Security protocols (SAML, XKMS, …) Chapter 14

15. System Development Alternatives Many organizations are using approaches that shift the construction of systems from their information systems department to others. • End-User Development:Let users build their own systems • Outsourcing:Outsource the entire systems development process • Purchasing:(“Themake-or-buy decision”)Let users use off-the-shelf software packages. • Utility computing,consists of a virtualized pool of “self-managing” IT resources (computing power and storage capacity) that can be dynamically allocated for any application Chapter 14

16. System Development Alternatives The buy decision Chapter 14

17. E-Business Application Development The diversity of e-business models and applications, which vary in size from a small store to a global exchange, requires a variety of development methodologies and approaches. • There are several options for developing e-business (e-biz) applications: • Buying an existing package can be cost-effective and timesaving in comparison to in-house application development. • Leasing is advantageous over buying in those cases where extensive maintenance is required, or where the cost of buying is very high. • Develop in-house. • Build from scratch. • Build from components. • Enterprise application integration Chapter 14

18. Finally - Plan the Project List the Activities, Events & Milestones that make up the Project. • Installing a new Business System • Order signed • Cabling installed • Equipment delivered • Data conversion • End-user training Chapter 14

19. MANAGERIAL ISSUES • Importance. Some general and functional managers believe that system development is a technical topic that should be of interest only to technical people. This is certainly not the case. Appropriate construction of systems is necessary for their success. Functional managers must participate in the development process and should understand all the phases. They must also participate in the make-or-buy decisions and software selection decisions. Inappropriate development methodologies can result in the system’s failure. • Building interorganizational and international information systems. Building systems that connect two or more organizations, or one organization that operates in different countries, can be very complicated. You need to carefully plan for such systems, considering different requirements and cultures. In addition to planning, the analysis, design, and other phases of system development must take into account the information needs of the various parties. One of the major problems with international systems is that what is ethical or legal in one country may be unethical or illegal in another. • Ethical and legal issues.Developing systems across organizations and countries could result in problems in any phase of system development. A special difficulty exists with Internet-related projects, where legislation is still evolving. Chapter 14

20. MANAGERIAL ISSUES Continued • User involvement.The direct and indirect users of a system are likely to be the most knowledgeable individuals concerning requirements and which alternatives will be the most effective. Users are also the most affected by a new information system. IS analysts and designers, on the other hand, are likely to be the most knowledgeable individuals concerning technical and data-management issues as well as the most experienced in arriving at viable systems solutions. The right mixture of user involvement and information systems expertise is crucial. • Traditional approaches vs. prototyping.The traditional development approach stresses detailed, lockstep development with established decision points. Prototyping stresses flexible development based on actual use of partially functional systems. Experience has shown that the traditional approach can be better for low-risk, environmentally stable, and technology-simple situations; prototyping is often better under the opposite conditions. • Tool use by developers.Development tools and techniques can ensure that developers consider all necessary factors and standardize development, documentation, and testing. Forcing their use, on the other hand, may unnecessarily constrain innovation, development efficiency, and personnel productivity. Chapter 14

21. MANAGERIAL ISSUES Continued • Quality assurance vs. schedules.Quality counts in the short term and the long term, but it can lengthen development and increase developmental costs. Trying to meet tight development schedules can induce poor quality with even worse schedule, cost, and morale problems. • Behavior problems.People use information systems and often become quite used to how existing systems work. They may react to new systems in unexpected ways, making even the best technically designed systems useless. Changes brought about by information systems need to be managed effectively. Of special interest is the issue of motivating programmers to increase their productivity by learning new tools and reusing preprogrammed modules. • Perpetual development.Information systems are designed to meet organizational needs. When they don’t accurately meet these needs, or these needs change, information systems need to be redeveloped. Developing a system can be a major expense, but perpetually developing a system to maintain its usefulness is usually a much more expensive. • Risk level.Building information systems involves risk. Systems may not be completed, completed too late, or require more resources then planned. The risk is large in enterprise systems. Chapter 14