1. © 2007 Prentice Hall, Inc.1 Using Management Information Systems David Kroenke Systems Development Chapter 6

2. © 2007 Prentice Hall, Inc.2 Learning Objectives Know the characteristics of systems development. Understand what professional systems analysts do. Understand how program development and system development differ. Learn the major challenges of systems development.

3. © 2007 Prentice Hall, Inc.3 Learning Objectives (Continued) Know the nature and phases of the classical systems development cycle (SDLC). Know the nature and development tools used for rapid application development (RAD). Know the nature and phases of object-oriented development (OOD) using unified process (UP). Understand the nature and advantages of extreme programming (XP).

4. © 2007 Prentice Hall, Inc.4 Systems Development Fundamentals Systems development is defined as a process for creating and maintaining information systems. Developing an information system involves all five components: hardware, software, data, procedures, and people.

5. © 2007 Prentice Hall, Inc.5 Figure 6-1 System Development vs. Program Development

6. © 2007 Prentice Hall, Inc.6 Thinking Big About Systems Development Many students are new to the systems development process due to working with personal computer tools. The scope of work is large with large-scale corporate information systems and may be global with different languages and cultures.

7. © 2007 Prentice Hall, Inc.7 Thinking Big About Systems Development (Continued) Management of resources is a critical success factor. Comprehensive processes are required for project staff to follow and adhere to in order to successfully meet project and systems objectives.

8. © 2007 Prentice Hall, Inc.8 Three sources for software are: Off-the-self Off-the shelf-with adaptation Tailor-made Information systems are never off-the-shelf due to the involvement of company’s people and resources. Thinking Big About Systems Development (Continued)

9. © 2007 Prentice Hall, Inc.9 You must construct or adapt procedures to fit your business and people. It does not matter how you obtain the computer programs. Thinking Big About Systems Development (Continued)

10. © 2007 Prentice Hall, Inc.10 Information System Maintenance For information systems, maintenance means: Either fixing a system to make it do what is expected Or adapting the system to a changing requirement.

11. © 2007 Prentice Hall, Inc.11 Systems Development Challenges Systems development is difficult and risky. Many projects are never finished. Some projects finish 200 or 300 percent over budget. Some projects finish on schedule and within budget but do not meet their goals.

12. © 2007 Prentice Hall, Inc.12 Systems Development Challenges (Continued) Difficulties in determining requirements Changes in requirements Scheduling and budgeting difficulties Changing technology Diseconomies of scale

13. © 2007 Prentice Hall, Inc.13 Systems Development Processes or Methodologies There are however many systems development processes we are concerned with: Systems development life cycle (SDLC) Rapid application development (RAD) Object-oriented systems development (OOD) Extreme programming (XP) Information systems differ, no single process works for all situations.

14. © 2007 Prentice Hall, Inc.14 Scales of Information Systems System TypeDescription PersonalSupports one person with limited set of requirements WorkgroupSupports a group of people normally with a single application EnterpriseSupports many workgroups with many different applications InterenterpriseSupports many different organizations with many different cultures, different countries and heritages

15. © 2007 Prentice Hall, Inc.15 Systems Development Life Cycle The numbers of phases used by organizations vary. We use five phases. System definition Requirements analysis Component design Implementation System maintenance (fix or enhance)

16. © 2007 Prentice Hall, Inc.16 Figure 6-2 Phases in the SDLC

17. © 2007 Prentice Hall, Inc.17 System Definition Phase Tasks Define project Goals and objectives Scope–statement of work Assess feasibility Cost (budget) Schedule Technical Organizational feasibility Form a project team Project manager In-house IT staff Outside consultants and staff (as needed) User representatives (management and staff)

18. © 2007 Prentice Hall, Inc.18 Figure 6-3 SDLC System Definition Phase

19. © 2007 Prentice Hall, Inc.19 Requirement Analysis Phase Tasks The most important phase in the system development process is determining system requirements. If the requirements are wrong, the system will be wrong. If the requirements are determined completely and correctly, then the design and implementation will be easier and more likely to result in success. Seasoned and experienced system analysts know how to conduct interviews to bring such requirements to light.

20. © 2007 Prentice Hall, Inc.20 Figure 6-4 SDLC Requirements Analysis Phase

21. © 2007 Prentice Hall, Inc.21 Obtain User Approval Once the requirements have been specified, the users must review and approve them before the project continues. The easiest and cheapest time to alter the information system is in the requirements phase. Changing a requirement in the implementation phase may require weeks of reworking applications components and the database.

22. © 2007 Prentice Hall, Inc.22 Component Design Phase Each of the five components is designed in this stage. The team designs each of the five components by developing alternatives. Each alternative is evaluated against the requirements. Typically the best alternative that meets the requirements is selected.

23. © 2007 Prentice Hall, Inc.23 Figure 6-5 SDLC: Component Design Phase

24. © 2007 Prentice Hall, Inc.24 Hardware Design The team determines specifications for the hardware that they would want to acquire. The team is not designing hardware. Typically, a large scale company will have some sort of networking infrastructure.

25. © 2007 Prentice Hall, Inc.25 Hardware Networking Alternatives PC or LANs over the public Internet Three separate point-to-point leased lines Lease time on some type of PSDN Create Virtual Private Network (VPN) over the Internet

26. © 2007 Prentice Hall, Inc.26 Program Design Depends on the source of the programs Off-the-self-the team must determine candidate products and evaluate them against requirements Off-the-shelf with alteration programs-the team identifies products to be acquired off- the-shelf and then determines the alterations required.

27. © 2007 Prentice Hall, Inc.27 Program Design (Continued) Custom-design programs-the team produces specifications (documentation) for writing program code

28. © 2007 Prentice Hall, Inc.28 Database Design When constructing a database: Convert the database design to a data model If off-the-shelf database, little design is needed

29. © 2007 Prentice Hall, Inc.29 Procedure Design Procedures must be developed for system users and operations personnel to follow. These procedures typically address: Normal operations Backup of transactions and data System failure recovery

30. © 2007 Prentice Hall, Inc.30 Figure 6-6 Procedures to Be Designed

31. © 2007 Prentice Hall, Inc.31 Design of Job Descriptions Job descriptions are needed for both users and operations personnel. New information systems may require new jobs. Organizations may have to add new duties and responsibilities due to information systems changes and enhancements.

32. © 2007 Prentice Hall, Inc.32 Implementation Phase Tasks in this phase are to build, test, and convert the users to the new system. System user training and procedures are verified.

33. © 2007 Prentice Hall, Inc.33 Figure 6-7 SDLC: Implementation Phase

34. © 2007 Prentice Hall, Inc.34 Implementation System Phase Testing System testing consists of testing the integrated components of the system as a complete working system. Test plans are developed based on system requirements and are used to verify that the system works as expected.

35. © 2007 Prentice Hall, Inc.35 Implementation System Phase Testing (Continued) Testing and retesting consumes huge amounts of labor. Automated testing is used to reduce testing labor and reduces testing time. Many IT professionals work today as testing specialists under Product Quality Assurance (PQA).

36. © 2007 Prentice Hall, Inc.36 Implementation System Phase Testing (Continued) Beta testing allows future system users to try out the new system on their own. Normally products in the beta test are complete and fully functioning with few errors.

37. © 2007 Prentice Hall, Inc.37 Implementation Phase System Conversion There are four ways to implement system conversion: Pilot–Implement the entire system on a limited portion of the business Phase–New system is installed in pieces across the organization Parallel–New system runs in parallel with the old system for a while Plunge–The old system is turned off and the new system is turned on immediately

38. © 2007 Prentice Hall, Inc.38 Figure 6-8 Design and Implementation for the Five Components

39. © 2007 Prentice Hall, Inc.39 Maintenance Phase Work done in this phase is to fix the system to work correctly or adapt the system to changes in requirements.

40. © 2007 Prentice Hall, Inc.40 Figure 6-9 SDLC System Maintenance Phase

41. © 2007 Prentice Hall, Inc.41 Maintenance Phase Tasks Record requests for change System failures Enhancement requests Prioritize requests Failure fixing Patches Service packs Enhancements New releases

42. © 2007 Prentice Hall, Inc.42 Problems with the SDLC Systems development seldom works so smooth. There is sometimes a need to crawl back up the waterfall. Difficulty of documenting requirements in a usable way. Scheduling and budgeting is difficult especially for large projects with large SDLC phases.

43. © 2007 Prentice Hall, Inc.43 Rapid Application Process (RAD) Basic idea is to break up the design and implementation phases of the SDLC into smaller pieces. Design and implement the pieces using as much computer assistance as possible.

44. © 2007 Prentice Hall, Inc.44 Figure 6-10 Martin’s RAD Process

45. © 2007 Prentice Hall, Inc.45 RAD Characteristics Design / implement / fix development process Continuous user involvement throughout Extensive use of prototypes Joint Application Design (JAD) CASE Tools

46. © 2007 Prentice Hall, Inc.46 Prototypes Another RAD characteristic is the use of prototypes. A prototype is a mock-up of an aspect of the new system. A prototype could be one of the following: Form Report Database query Other elements of the user interface

47. © 2007 Prentice Hall, Inc.47 Figure 6-11 Example of Prototype Form

48. © 2007 Prentice Hall, Inc.48 Figure 6-12 Data of Prototype Form in Figure 6-11

49. © 2007 Prentice Hall, Inc.49 Joint Application Design JAD is another key element of RAD. JAD came about because development wanted to incorporate feedback and testing earlier in the development process. A JAD session is a design meeting of short duration, perhaps an afternoon or a day or two at most. The goal is to keep the scope of the component small enough that the design can be completed in a short period.

50. © 2007 Prentice Hall, Inc.50 CASE and Visual Tools A CASE tool is a computer system to aid in the development of computer programs or systems. CASE tools vary in their features and functions. CASE tools have a repository that contains documents, data, prototypes, and program code for the software or system under development.

51. © 2007 Prentice Hall, Inc.51 Figure 6-13a Visual Web Page Development

52. © 2007 Prentice Hall, Inc.52 Figure 6-13b Code Behind Visual Web Page

53. © 2007 Prentice Hall, Inc.53 Figure 6-14 Visual Programming Tool Example

54. © 2007 Prentice Hall, Inc.54 Object-Oriented Systems Development Object-Oriented Development (OOD) came about from the discipline of object-oriented programming. Object-Oriented Programming (OOP) is a discipline for designing and writing programs.

55. © 2007 Prentice Hall, Inc.55 Object-Oriented Systems Development (Continued) Unified Modeling Language (UML) is a series of diagramming techniques that facilitates OOP development. UML does not require or promote any particular process. Unified Process (UP) was designed for use with UML.

56. © 2007 Prentice Hall, Inc.56 Unified Process Phases Three of the five phases are similar to the SDLC phases. The inception phase is similar to the first part of the SDLC definition phase. The transition phase is similar to the conversion step in SDLC implementation. The maintenance phase is similar to maintenance in the SDLC.

57. © 2007 Prentice Hall, Inc.57 Unified Process Elaboration Phase The elaboration phase is where developers construct and test the framework and architecture of the new system. This phase addresses the aspects of the system that have the most risk and uncertainty.

58. © 2007 Prentice Hall, Inc.58 Figure 6-15 Stages in the Unified Process

59. © 2007 Prentice Hall, Inc.59 Figure 6-16 Use Case Example

60. © 2007 Prentice Hall, Inc.60 Unified Process Construction Phase The construction phase is where developers design, implement, and test the easier, lower- risk features and functions that were not addressed during elaboration. After all features and functions have been completed in the construction phase, the system is ready for deployment.

61. © 2007 Prentice Hall, Inc.61 Figure 6-17 Unified Process Principles

62. © 2007 Prentice Hall, Inc.62 Extreme Programming An emerging technique for developing computer programs Not useful for large scale development systems that require business processes and procedures Iterative style and distinguished by: Customer centric Just-in-time-design Paired programming

63. © 2007 Prentice Hall, Inc.63 Figure 6-18 Comparison of Development Techniques

64. © 2007 Prentice Hall, Inc.64 Summary Systems development is the process of creating and maintaining information systems and are tailor-made. Major challenges of systems development include: Determining requirements Changes in requirements Difficulties in scheduling and budgeting Changing technology Diseconomies of scale

65. © 2007 Prentice Hall, Inc.65 Summary (Continued) Three systems development methodologies are: Systems Development Life Cycle (SDLC) Rapid Application Development (RAD) Object-Oriented Development (OOD) Extreme Programming (XP) is an emerging technique for developing computer programs in very short iterations of two weeks or less.

66. © 2007 Prentice Hall, Inc.66 Key Terms and Concepts Analysis paralysis Beta testing Brooks’s Law CASE tool Code generator Computer-assisted software/systems engineering Cost feasibility Extreme programming (XP) Incremental development Joint application design (JAD) Maintenance Object-oriented development (OOD) Object-oriented programming (OOP) Organizational feasibility Paired programming Parallel installation Patch Phased installation Pilot installation

67. © 2007 Prentice Hall, Inc.67 Key Terms and Concepts Plunge (direct) installation Product quality assurance (PQA) Prototype Rapid application development (RAD) Repository Schedule feasibility Service pack System analyst System conversion System analysis and design Systems development Systems development life cycle (SDLC) Technical feasibility Test plan Unified Modeling Language (UML) Unified process (UP) Use case Visual development tools Waterfall

68. © 2007 Prentice Hall, Inc.68 Ethics Guide–Estimation Ethics Estimation Ethics occurs when a company agrees to produce a system or product for less than it knows the project will require. For example, there is an agreement between buyer and seller to build an information system for 50K, when good estimating techniques indicate it will take 75K to build the system. If the contract for the system is written for a fixed cost, the developer will eat the costs. This strategy is used if the contract opens up other business opportunities that are worth the 25K loss.

69. © 2007 Prentice Hall, Inc.69 Ethics Guide–Estimation Ethics (Continued) Buy-ins always involve deceit. Most would agree that buying in on a time- and-material project, planning to stick it to the customer with the full cost later is unethical and wrong. Opinions on buying-in on a fixed-priced contract vary. Some say buying-in is always deceitful and should be avoided.

70. © 2007 Prentice Hall, Inc.70 Ethics Guide–Estimation Ethics (Continued) What about in-house projects? Do the ethics change if an in-house development team is building a system for use in-house? These issues become even stickier if team members disagree about how much the project will cost. Suppose you are a project manager of an exciting new project and you know that not all costs for every aspect of the project are included in the estimate and you do nothing about it. Is your behavior unethical?

71. © 2007 Prentice Hall, Inc.71 Problem Solving Guide–Aim For What You Focus on what you want and where you want to go. Put your attention on the desired outcome, and manage your efforts to that outcome. Requirements: What do you want the new system to do? Without accurate requirements, the system cannot be built. As a future user, your most important systems development task is to manage your requirements. You need a system for tracking requirements. If the project is too big for all the requirements to be known, build the system incrementally.

72. © 2007 Prentice Hall, Inc.72 Opposing Forces Guide–The Real Estimation Process Estimates are developed using whatever technique you want. Your estimate goes in with the estimates of all the other team leaders and the project manager sums all those estimates together and produces an overall estimate for the project. Estimates are what they are; you can’t knock off a month or two without some problem.

73. © 2007 Prentice Hall, Inc.73 Opposing Forces Guide–The Real Estimation Process (Continued) Most software developers are optimists and schedule things as if everything will go as planned and not account for the unforeseen such as: Vacations Sick days Training Reviews All other things we do in addition to writing software

74. © 2007 Prentice Hall, Inc.74 Security Guide–Security and Systems Development A secure information system is one in which only authorized users can take authorized actions. The process of creating a secure system can be summarized in the following five steps: Decide how users will be authenticated. Determine user groups. List primary features and functions of the system. Determine how restrictions will be enforced. Allocate permissions to user groups for specific features and functions.

75. © 2007 Prentice Hall, Inc.75 Reflections Guide–Dealing with Uncertainty Principles for communicating with IT personnel after the billing disaster. Business users, and IS would take responsibility for the success of new systems. Users would actively work with IS Personnel throughout systems development, especially during the requirements phase. Users would take an active role in project planning, project management, and project reviews. No development phase would be considered complete until the work was reviewed and approved by user representatives and management.

76. © 2007 Prentice Hall, Inc.76 Reflections Guide–Dealing with Uncertainty (Continued) Principles for communicating with IT personnel after the billing disaster (continued) Users would actively test the new system. All future systems would be developed in small increments. After the billing disaster, senior management understood what needed to be done. They made these practices a priority, and over time user resistance was mostly overcome.