Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-1 MANAGING INFORMATION TECHNOLOGY 7 th EDITION CHAPTER 9 METHODOLOGIES FOR CUSTOM.

Similar presentations


Presentation on theme: "Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-1 MANAGING INFORMATION TECHNOLOGY 7 th EDITION CHAPTER 9 METHODOLOGIES FOR CUSTOM."— Presentation transcript:

1 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-1 MANAGING INFORMATION TECHNOLOGY 7 th EDITION CHAPTER 9 METHODOLOGIES FOR CUSTOM SOFTWARE DEVELOPMENT

2 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-2 METHODOLOGIES FOR CUSTOM SOFTWARE DEVELOPMENT Large firms purchase software packages whenever feasible, but development of custom software still highly important Custom methodology also used by software companies who develop products for many different buyers Approaches for developing custom applications: - Traditional Systems Development Life Cycle (SDLC) - Prototyping - Rapid Application Development (RAD) - Agile Development

3 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-3 SYSTEMS DEVELOPMENT LIFE CYCLE Systems development life cycle (SDLC) -Highly structured process for developing customized applications -Requires a lot of documentation and formal reviews at end of each major step -Output from one step = input to next step (Waterfall model) SDLC Waterfall

4 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-4 SYSTEMS DEVELOPMENT LIFE CYCLE SDLC Waterfall: 8 Steps in 3 phases Figure 9.1

5 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-5 SYSTEMS DEVELOPMENT LIFE CYCLE Typical SDLC project costs by Steps in 3 Phases

6 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-6 SDLC DEFINITION PHASE Feasibility Analysis (3 types) Technical Operational Economic Definition Phase

7 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-7 SDLC DEFINITION PHASE Primary responsibility of the IS analyst Based on: - Knowledge of current and emerging technological solutions - IT expertise of in-house personnel - Anticipated infrastructure needed to both develop and support the proposed system Technical Feasibility

8 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-8 SDLC DEFINITION PHASE Operational Feasibility Primary responsibility of the business manager Entails assessing the degree to which a proposed system addresses the business issues that gave rise to the idea for a new information system Economic Feasibility Business managers and IS analysts work together to prepare a cost/benefit analysis IS analyst responsible for establishing the developmental costs for the project

9 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-9 SDLC DEFINITION PHASE Typical Deliverable:10-20 page document: - Executive overview and recommendations - Description of what system would do and how it would operate - Analysis of costs and benefits - Development plan Feasibility analysis

10 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-10 SDLC DEFINITION PHASE Focuses on processes, data flows, and data interrelationships rather than a specific physical implementation Requirements are gathered by: - Interviewing individuals or work groups - Reviewing documents - Observing employees doing their jobs Requirements Definition

11 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-11 SDLC DEFINITION PHASE Deliverable = systems requirements document: - Detailed descriptions of inputs and outputs, processes used to convert input data to outputs - Formal diagrams and output layouts - Revised cost/benefit analysis - Revised plan for remainder of project Approved by business managers before next phase begins Requirements Definition

12 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-12 SDLC CONSTRUCTION PHASE Begins only after the systems requirements document from the Definition phase is approved Three steps: - System design - System building - System testing Construction Phase

13 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-13 SDLC CONSTRUCTION PHASE Includes: - Deciding what hardware and software to use - Designing structure and content of databases - Defining programs and their interrelationships Critical step for quality system: System Design

14 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-14 SDLC CONSTRUCTION PHASE Deliverable: detailed design document - Models, such as diagrams of system’s physical structure - Descriptions of databases - Detailed specification for each program in the system - Plan for the remaining steps of the Construction phase System Design

15 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-15 SDLC CONSTRUCTION PHASE Includes: - Producing the computer programs - Developing or enhancing the databases and files to be used by the system -Procuring new hardware and support software Documentation is a major mechanism of communicating among members of the project team System Building

16 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-16 SDLC CONSTRUCTION PHASE Time-intensive step (if executed well) - Each module of code is tested - Modules are assembled into subsystems and tested - Subsystems are combined and entire system is integration tested System Testing – by IS specialists

17 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-17 SDLC CONSTRUCTION PHASE System Testing – by Users Who might participate in User Testing? User Acceptance Testing: Ensures that the system performs reliably and does what it is supposed to do in the user environment

18 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-18 SDLC IMPLEMENTATION PHASE Success of this phase is highly dependent upon business manager involvement - Installation - Operations - Maintenance Implementation Phase

19 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-19 SDLC IMPLEMENTATION PHASE Includes: - Building files and databases - Converting relevant data from one or more old systems to the new system - Training system users Installation Installations that involve converting data from an old system to a new one can be as difficult to implement as systems to automate totally new functions or processes

20 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-20 SDLC IMPLEMENTATION PHASE Four Approaches to Convert from an old System: Parallel: organization operates old system in parallel with new system until new system is working sufficiently Pilot: new system is introduced to only one part of the organization first Installation Phased: new system is implemented one component at a time Cutover: old system is totally abandoned as soon as the new system is implemented Fig 9.4

21 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-21 SDLC IMPLEMENTATION PHASE New application that is operational is referred to as in “production mode” Project team is disbanded at this time or shortly thereafter Requires two types of documentation - System documentation for IS specialists who operate and maintain the system - User documentation for those who use the system Operations

22 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-22 SDLC IMPLEMENTATION PHASE The process of making changes to a system after it has been put into “production mode” Reasons for maintenance Correct errors in the system Adapt the system to changes in the business environment Enhance or improve the system beyond the original system requirements Maintenance

23 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-23 SDLC IMPLEMENTATION PHASE In the past, maintenance step has incurred about 80% of total costs over a system’s life In the 1990s, systems development resources heavily devoted to system maintenance versus new system development: - 75% to run and maintain existing systems - 35% to build/buy new systems Maintenance

24 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-24 SDLC IMPLEMENTATION PHASE Common Problems: - Documentation may not be updated when changes to the system are made, causing problems for future maintenance -Changes to one part of the system may have an unanticipated effect on other parts of the system (i.e., a ripple effect ) -Programmers generally prefer new development, not maintenance, so work may go to least experienced programmers Maintenance

25 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-25 SDLC IMPLEMENTATION PHASE Business managers need to be aware that: -Maintenance can introduce new errors into the system -If IT resources not available, there may be long delays before a requested system change is worked on, creating gaps in system performance and the needs of an organization Maintenance

26 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-26 SYSTEMS DEVELOPMENT LIFE CYCLE Usually a temporary team for specific project Includes appropriate representatives from business units, as well as IS personnel Led by project manager -Usually from IS, but can be from business unit (or both) -Responsible for success of project: delivering quality system on time and within budget The SDLC project team

27 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-27 SYSTEMS DEVELOPMENT LIFE CYCLE 1. Manageable project size 2. Accurate requirements definition Cost of corrections increases as development life cycle advances 3. Executive sponsorship Three project characteristics associated with successful outcomes:

28 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-28 SYSTEMS DEVELOPMENT LIFE CYCLE Advantages and Disadvantages

29 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-29 PROTOTYPING METHODOLOGY Prototyping Is a type of evolutionary development process: enables creation of system (or part of system) quickly, then system is revised after initial trial(s) by user(s) Takes advantage of fourth generation procedural languages and relational database management systems Can be used as a complete alternative to the SDLC or within an SDLC process

30 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-30 PROTOTYPING METHODOLOGY Examples of Prototyping goals: “First-of-a-series” – a completely operational prototype used as a pilot “Selected features” – only some essential features included in prototype, more added later

31 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-31 PROTOTYPING METHODOLOGY The Prototyping Steps:

32 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-32 PROTOTYPING METHODOLOGY IS team members who can quickly build systems using advanced tools Business users committed to working closely with IS developers to try out and refine prototype Project Team:

33 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-33 PROTOTYPING METHODOLOGY Only basic requirements needed at front end Used to develop systems that radically change how work is done, so users can evaluate Allows firms to explore use of new technology Working system available for testing more quickly Less strong top-down commitment needed at front end Costs and benefits can be derived after experience with initial prototype Initial user acceptance likely to be higher Advantages:

34 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-34 PROTOTYPING METHODOLOGY End prototype may lack security and control features needed for the final system May not undergo rigorous testing Final documentation may be less complete More difficult to manage user expectations Disadvantages:

35 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-35 PROTOTYPING METHODOLOGY Prototyping within an SDLC Definition Phase 1.To help users define system requirements – such as input and output screens

36 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-36 PROTOTYPING METHODOLOGY Prototyping within an SDLC Definition Phase 2.Used for a pilot implementation of a working prototype before Construction using SDLC approach

37 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-37 RAPID APPLICATION DEVELOPMENT (RAD) Hybrid methodology: combines aspects of SDLC and prototyping Goal = produce a system more quickly than an SDLC alone

38 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-38 RAPID APPLICATION DEVELOPMENT (RAD) A common RAD technique is: JOINT APPPLICATION DEVELOPMENT (JAD) Team of users and IS specialists engage in an intense and structured process in order to minimize total time required for gathering information from multiple participants

39 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-39 RAPID APPLICATION DEVELOPMENT (RAD)

40 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-40 CASE TOOLS Computer Aided Software Engineering (CASE) Any software tool used to automate one or more steps of a software development methodology

41 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-41 AGILE DEVELOPMENT Alternative methodology for smaller projects Based on four key values: - Simplicity - Communication - Feedback - Courage AGILE Manifesto

42 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-42 AGILE DEVELOPMENT eXtreme programming (XP) - Programmers write code in pairs - Use simple design and frequent testing - Three program design characteristics: 1.System must communicate everything you want to communicate 2.System must contain no duplicate code 3.System should have the fewest number of components as possible

43 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-43 AGILE DEVELOPMENT Well-orchestrated movement of project updates between team members -Similar to the coordination in a rugby scrum -Emphasizes: - Independent project teams - Coordination and communication between and within teams - Iterative and continuous monitoring of work -Highly efficient work methods Approach utilizes: - Daily Scrum meeting - Scrum of Scrum meeting - Sprint planning meeting - Sprint review meeting Scrum Rugby Scrum

44 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-44 SOURCING SOFTWARE PROJECTS Outsourcing is an alternative for: Computer and Network Operations Application Development (and Maintenance) Onshore outsourcing: contracting with companies within the same country or region Offshore outsourcing: contracting with companies not within the same country or region - Special risks include: language and cultural barriers, risk of piracy of intellectual property - Best alternative for application development outsourcing when system requirements are well defined and remain stable

45 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-45 SOURCING SOFTWARE PROJECTS Potential Advantages of Application Outsourcing in General - Makes use of technical expertise not available in-house - Temporarily expands capacity of IS workforce to complete projects more quickly -Frees up internal IS resources to work on strategic or proprietary projects Potential Advantages of Offshore Outsourcing in General - Lower labor costs and 24/7 availability

46 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-46 SOURCING SOFTWARE PROJECTS Outsourcing Applications: some best practices - Manage expectations, not staff - Take explicit actions to integrate the offsite workers - Communicate frequently - Use a project management office - Begin small - Use secure and redundant communication links - Hire legal expertise for offshore contracts

47 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-47 USER APPLICATION DEVELOPMENT (UAD) Application development by non-IS professionals has grown rapidly with the introduction of user tools (hardware and software) During the 1970s most IS managers did not expect PCs to be used in a corporate setting -Many PCs were purchased by business managers without the IS organization’s involvement -The primary motivator was a new type of PC application: spreadsheet programs Over time, small applications using database software (such as Microsoft Access) also were commonly developed by end users

48 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-48 USER APPLICATION DEVELOPMENT (UAD) Advantages of UAD -Users do not have to explain their information requirements to an analyst from an IS unit who is not familiar with the business context -Users do not have to wait for IS resources to be assigned to work on their application project - Business managers have more control over the development costs and timelines

49 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-49 USER APPLICATION DEVELOPMENT (UAD) Disadvantages of UAD - Less attention typically given by user developer to application controls (security, data quality) - Loss of opportunities for application integration -User developed applications are more likely to “reinvent” functionality found in other applications and opportunities to share data across applications are missed. - Increased operational risks due to a job change of the user developer

50 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-50 COMMON DATA QUALITY PROBLEMS IN SPREADSHEETS. Mechanical errors Typing errors, pointing errors or other simple slips Have a high chance of being caught Logic errors Incorrect formulas due to choosing the wrong algorithm or creating the wrong formula to implement the algorithm Eureka errors refer to easy-to- proof errors Cassandra errors are difficult-to-proof Omission errors Things left out of the model that should be there These are difficult errors to detect Qualitative errors Flaws that do not produce immediate quantitative errors, but can lead to quantitative errors later

51 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-51 MAGNITUDE OF SPREADSHEET ERRORS Fidelity's Magellan Fund example "During the estimating process, a tax accountant is required to transcribe the net realized gain or loss from the fund's financial records (which were correct at all times) to a separate spreadsheet, where additional calculations are performed. The error occurred when the accountant omitted the minus sign on a net capital loss of $1.3 billion and incorrectly treated it as a net capital gain on this separate spreadsheet. This meant that the dividend estimate spreadsheet was off by $2.6 billion....” - J. Gary Burkhead

52 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-52 USER APPLICATON DEVELOPMENT (UAD) The Sarbanes-Oxley Act (SOX) has created additional quality concerns and organizational risks: Spreadsheets and applications that use financial information are subject to audit and must be protected by the proper controls

53 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-53 PRE-ASSESING THE POTENTIAL UAD RISKS Three types of risk factors should be considered when deciding whether an application should be user-developed or developed by an IS professional:

54 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-54 GUIDELINES FOR USER DEVELOPERS Use a development methodology appropriate to the application, based on three application characteristics: 1.Scope ( personal, work unit) 2.Size 3.Complexity of the business problem

55 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-55 GUIDELINES FOR USER DEVELOPERS Ask important questions during the Definition and Construction phases, such as these:

56 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-56 GUIDELINES FOR USER DEVELOPERS Avoid two common problems: 1.Not doing enough testing - Thorough testing should take extensive time and effort 2.Not providing sufficient documentation - Multi-user applications especially need relatively detailed documentation

57 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-57 GUIDELINES FOR USER DEVELOPERS Some lessons from other user developers: -Stay in touch with end users throughout the project -The prototyping methodology is useful but development is still time consuming -Intricate, hard-to-find bugs often show up at end of development - Managing user expectations is crucial

58 Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-58 COPYRIGHT All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Printed in the United States of America. Copyright © 2012 Pearson Education, Inc. Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall


Download ppt "Copyright © 2011 Pearson Education, Inc. publishing as Prentice Hall 9-1 MANAGING INFORMATION TECHNOLOGY 7 th EDITION CHAPTER 9 METHODOLOGIES FOR CUSTOM."

Similar presentations


Ads by Google