Information Systems Technology Ross Malaga "Part III - Building and Managing Information Systems" III 11 Copyright © 2005 Prentice Hall, Inc MANAGING THE DEVELOPMENT AND PURCHASE OF INFORMATION SYSTEMS
Copyright © 2005 Prentice Hall, Inc LEARNING GOALS Explain the purpose of systems development methodologies. Describe the major phases of the traditional systems development life cycle. Describe alternative systems development methodologies and when a company should use them. Explain how organizations purchase and outsource information systems.
Copyright © 2005 Prentice Hall, Inc Developing and Purchasing Information Systems The Bead Bar needs digital cameras and new software to share bead designs. –Meredith – Software development needs to run smoothly and not disrupt business –Suzanne – Needs to be easy to use –Leda – Wants to know if COTS is available to do the job –Mitch – Wants flexibility for expansion to cruise ships –Julia – Wants to make sure cost is not too high and good ROI –Rachel – Can this help us to better understand our operations? –Jim – How do we juggle employee schedules to cover both work and system development activities? –Abe – How will this new system interface with our existing hardware, software, and networks? How much will it cost to maintain? Bead Bar Consultant
Copyright © 2005 Prentice Hall, Inc Systems Development Methodologies How to develop the “blueprints” for building an information system Systems development methodologies (SDM) –The process companies go through to develop and maintain an information system –Improve the systems development process –Lead to high-quality systems
Copyright © 2005 Prentice Hall, Inc Traditional Systems Development Life Cycle (SDLC) Seven phases (also called the waterfall model) –Planning– Testing –Systems Analysis– Implementation –Systems Design– Maintenance –Development Usually complete one phase before beginning the next Problem in later phase may require return to previous phase
Copyright © 2005 Prentice Hall, Inc. 11-6
Copyright © 2005 Prentice Hall, Inc Planning Feasibility analyses –Technical – Do the technologies exist to solve the problem? –Economic – Can the organization afford the system and will it provide an adequate ROI? –Operational – Assesses the human element of the proposed system Resistance to change Organizational politics –Schedule – Is the proposed development time line realistic?
Copyright © 2005 Prentice Hall, Inc Systems Analysis Systems analyst works with company to understand the problem fully and detail the requirements of the proposed solution Tools and techniques –Data flow diagrams (DFDs) Start with high level process Add more levels with increased levels of detail –Computer-Aided Software Engineering (CASE) Software that eases the systems development process
Copyright © 2005 Prentice Hall, Inc. 11-9
Copyright © 2005 Prentice Hall, Inc Detailed Data Flow Diagram
Copyright © 2005 Prentice Hall, Inc Systems Design Describe in detail how to build the system –Logical systems design Details the system’s functionality Structure chart – overall, top-down representation of system’s modules –Physical systems design Specifies all of the actual components used to implement the logical design Design frozen at end of this phase –Scope creep –Feature creep
Copyright © 2005 Prentice Hall, Inc Development Programming process is usually the most difficult and time consuming. Organization may choose to purchase software or outsource the programming tasks. Flowcharts often used to map program logic.
Copyright © 2005 Prentice Hall, Inc
Copyright © 2005 Prentice Hall, Inc Testing Programmers test modules – stub testing Development team tests how modules work together – unit testing System testing –Verification – system works in simulated environment –Validation – system works in real working environment
Copyright © 2005 Prentice Hall, Inc Implementation Data conversion User training Implementation strategy –Direct cutover –Parallel conversion –Pilot testing –Staged conversion
Copyright © 2005 Prentice Hall, Inc Maintenance Maintenance counts for as much as 80% of the total cost of an information system Tasks –Correct errors found during implementation –System enhancements Incremental upgrades Addition of major new features
Copyright © 2005 Prentice Hall, Inc Problems with Traditional SDLC SDLC is time consuming SDLC is costly SDLC is rather inflexible SDLC gets users’ inputs ONLY during systems analysis and implementation phases
Copyright © 2005 Prentice Hall, Inc Prototyping Development team uses limited set of user requirements to quickly build a working model of the proposed system – a prototype. Users work with prototype and provide feedback. The development team revises the prototype based on user feedback. Process continues until the users are satisfied with the system or until system turns out to be not feasible. Final system developed from prototype.
Copyright © 2005 Prentice Hall, Inc
Copyright © 2005 Prentice Hall, Inc Joint Application Development (JAD) Workshop that brings together users and development team to define system requirements and develop a prototype Less time for analysis than SDLC Helps alleviate conflicting requirements Greater user involvement leads to greater user acceptance of final system
Copyright © 2005 Prentice Hall, Inc Rapid Application Development (RAD) Combines JAD, prototyping, and integrated CASE (ICASE) tools to decrease the time for systems development ICASE – provide code generating capability –Tool can produce a completed program based on the diagrams developed by systems analysts
Copyright © 2005 Prentice Hall, Inc Object-Oriented Analysis and Design (OOAD) Object focus instead of process focus OOAD identifies each object in the system and its properties and procedures Advantages –Reduces time to develop system –Can lead to high-quality systems
Copyright © 2005 Prentice Hall, Inc Purchasing Software Commercial off-the-shelf (COTS) –Less expensive –May not contain all the needed features Phases in COTS SDLC –System planning –Systems analysis –Request for proposals –Proposal evaluation –Implementation –Maintenance } here is the difference
Copyright © 2005 Prentice Hall, Inc Request for Proposal (RFP) Details the requirements for the new systems and invites interested parties to submit a proposal for the system Sections in an RFP –Summary of existing systems –Specific description of the features of the new system –Proposal evaluation criteria –Budget constraints –Timetable for deliverables –Details of other miscellaneous information
Copyright © 2005 Prentice Hall, Inc Evaluating Proposals Specific requirements Demonstrations Benchmarks
Copyright © 2005 Prentice Hall, Inc Outsourcing Transfers responsibility for a specific information technology function to an outside vendor Advantages –Specialists provide service at reduced cost –Specialists attract high-quality people in their area –Allows company to focus on core businesses rather than IT Key component is the Service Level Agreement (SLA)
Copyright © 2005 Prentice Hall, Inc Bead Bar Consultant How Information Systems Development Issues Affect the Bead Bar –Meredith – Quality systems can give us a competitive advantage –Suzanne – End user involvement is key for system success –Leda – Developing new systems quickly will enable us to react to changing markets and attract new franchisees –Mitch – We want to extend this to cruise ships ASAP –Julia – Outsourcing would enable use to control costs
Copyright © 2005 Prentice Hall, Inc Bead Bar Consultant (continued) –Miriam – Using an RFP helps make better decisions –Rachel – DFD provides better understanding of operations –Jim – We will need a new policy on end user software development –Abe – Choosing which SDM, outsourcing, RFPs, and SLA all affect my job
Copyright © 2005 Prentice Hall, Inc Learning Goals Summary In this chapter you have learned: T he purpose of systems development methodologies The major phases of the traditional systems development life cycle The alternative systems development methodologies and when a company should use them How organizations purchase and outsource information systems