Systems development fall 2006


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 2
  • Systems development fall 2006

    1. 1. Systems Development MIS 503Management Information Systems MBA Program
    2. 2. SYSTEMS DEVELOPMENTLIFE CYCLE METHODOLOGY Systems development life cycle (SDLC) – a highly structured approach for development of new customized software applications Page 385
    3. 3. SYSTEMS DEVELOPMENTLIFE CYCLE METHODOLOGYThe SDLC Project Team• Usually temporary• Includes personnel from IS and business units• Has a project manager – Traditionally from IS – Can be from business unit – May be one from each – Responsible for success of project – delivering quality system on time and within budget Page 393
    4. 4. SYSTEMS DEVELOPMENTLIFE CYCLE METHODOLOGYThe SDLC Project Team• Includes systems analysts – Have critical roles – Work closely with business managers and end users – Have problem-solving skills, knowledge of IT capabilities, strong business understanding• Has a business sponsor and a champion Page 394
    5. 5. Managing Change• The ability to manage change is critical to the success of systems development. – The new or modified systems created during systems development will inevitably cause change. – Managing change requires the ability to recognize existing or potential problems.
    6. 6. Significant QuoteThere is nothing more difficult to plan, moredoubtful of success, nor more dangerous to managethan the creation of a new information system. Forthe initiator has the enmity of all who would profitfrom the preservation of the old system and merelyluke warm defenders in those who would gainfrom the new one.
    7. 7. Establishing Objectives for Systems Development• Systems development objectives should be supportive of, and aligned with, organizational goals.• There are four kinds of objectives that should be considered: – Performance objectives. – Cost objectives. – Control objectives. – Complexity objectives.
    8. 8. Systems Development Methodologies• A key factor in completing a successful systems development project is to adopt a methodology.• A methodology is a way of doing things.
    9. 9. Systems Development Methodologies• A systems development methodology is an assortment of rules and standards that govern the approach taken to all tasks associated with systems development.• In structured systems development the systems development tasks are broken down into small, easily managed parts.
    10. 10. Systems Development Methodologies• Top-down design means the entire system can be viewed as a layered set of descriptions, each of which could be decomposed, or “peeled back,” to reveal more detailed specifications for smaller parts of the system.
    11. 11. Structured Walkthrough• A structured walkthrough is a planned and pre-announced review of the progress of a particular project deliverable--a specific project outcome, a structure chart, or a human procedure.• The walkthrough helps team members review and evaluate the program of components of a structured project.
    12. 12. SYSTEMS DEVELOPMENTLIFE CYCLE METHODOLOGY The SDLC Steps ws al revie rm nsi ve fo p is exte jor ste teristic ach ma ch arac nd of eKey ed at e ir requ Figure 10.1 The Systems Development Page 386 Life Cycle
    13. 13. SYSTEMS DEVELOPMENTLIFE CYCLE METHODOLOGY The SDLC Steps t e spen -front tim later sive up hanges exten nsive c ro ach: id expe LC app to avo o f SD irements ark uHallm ining req rmdete Figure 10.2 Cost Breakdown for $1 Million Page 386 SDLC Project
    14. 14. SYSTEMS DEVELOPMENTLIFE CYCLE METHODOLOGYThe SDLC StepsSDLC: – Most often requires a lot of documentation – Outputs from one step inputs to next – Often referred to as the “waterfall” model Page 386
    15. 15. SYSTEMS DEVELOPMENTLIFE CYCLE METHODOLOGYDefinition Phase – Feasibility Analysis • Types of feasibility – economic, operational, and technical • 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 Page 387-388
    16. 16. SYSTEMS DEVELOPMENTLIFE CYCLE METHODOLOGY Definition Phase – Requirements Definition• Focuses on logical design: processes, data flows, and data interrelationships – not specific physical implementation• Deliverable – system 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 Page 388
    17. 17. Significant Quote Brook’s Law:Adding manpower to a late software project makesit later! (Frederick P Brooks Jr.)Hofstadters Law: It always takes longer than youthink, even when you take Hofstadters Law intoaccount. (Douglas Hofstadter)
    18. 18. SYSTEMS DEVELOPMENTLIFE CYCLE METHODOLOGYConstruction Phase ism of han ss r mec nt proce• System Design sa majo lopme ti on i ing deve• enta n dur System Building um Doc unicatio m• com System Testing Figure 10.3 Characteristics Page 389 of High Quality Systems
    19. 19. SYSTEMS DEVELOPMENTLIFE CYCLEMETHODOLOGYImplementation Phase• Installation• Operations• Maintenance Page 390
    20. 20. Implementation Phase – InstallationParallel StrategyParallel StrategyParallel StrategyParallel Strategy Figure 10.4 Implementation Strategies Page 391
    21. 21. Implementation Phase – Maintenance Figure 10.5 Percent of Development Page 392 Resources Devoted to Maintenance
    22. 22. Implementation Phase – Maintenance Figure 10.6 The Widening Gap Between Page 392 Organization’s Needs and System’s Performance
    23. 23. Significant Quote Bove’s Theorem:The remaining work to finish in order to reachyour goal increases as the deadline approaches.Walking on water and developing software froma specification are easy if both are frozen. (Edward V Berard)
    24. 24. SYSTEMS DEVELOPMENTLIFE CYCLE METHODOLOGYSDLC Advantages and Disadvantages Figure 10.8 Advantages and Disadvantages Page 395 of Traditional SDLC Approach
    25. 25. Significant Quote Deadline Dan’s Demon:Every task takes twice as long as you think it willtake. If you double the time you think it will take,it will actually take four times as long. Meskimens LawThere is never time to do it right, but there isalways time to do it over
    26. 26. Causes of Maintenance• Some major causes of program maintenance are: – New requests from stakeholders, users, and managers. – Bugs or errors in the program. – Technical and hardware problems. – Corporate mergers and acquisitions. – Governmental regulations.
    27. 27. Significant QuoteNixons LawThe man who can smile when things gowrong has thought of someone to blame.Flons axiomThere does not now, nor will there ever, exista programming language in which it is theleast bit hard to write bad programs. (Lawrence Flon)
    28. 28. Trends in Systems Development
    29. 29. Operational and Rapid Prototyping• An operational prototype is a prototype that works.• A partially operational prototype has some components that are operational.• A rapid prototype allows system stakeholders and users to see a mockup of the subsystem much faster, which enables earlier changes.
    30. 30. PROTOTYPINGMETHODOLOGY• Prototyping approach: – Takes advantage of availability of fourth generation procedural languages and relational database management systems – Enables creation of system (or part of system) more quickly, then revise after users have tried it – Is a type of evolutionary development process Page 396
    31. 31. PROTOTYPINGMETHODOLOGY• Prototyping examples: – Input and output screens developed for users to test as part of requirements definition – “First-of-a-series” – a completely operational prototype used as a pilot – “Selected features” – only some essential features included in prototype, more added later – Prototyping used as a complete alternative to traditional SDLC methodology Page 396
    32. 32. PROTOTYPINGMETHODOLOGY• Prototyping used as a complete alternative to traditional SDLC methodology: – Good when requirements hard to define – Good when system needed quickly – Impractical for large, complex applications Page 396
    33. 33. The Prototyping Steps Figure 10.9 The Prototyping Life Cycle Page 397
    34. 34. PROTOTYPING METHODOLOGY Prototyping Advantages and Disadvantages• Advantages: – 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 higher Page 398-399
    35. 35. PROTOTYPINGMETHODOLOGYPrototyping Advantages and Disadvantages• Disadvantages: – End prototype often lacks security and control features – May not undergo as rigorous testing – Final documentation may be less complete – More difficult to manage user expectations Page 399
    36. 36. PROTOTYPINGMETHODOLOGYPrototyping within an SDLC Process Figure 10.10 SDLC with Prototyping Page 399 to Define Requirements
    37. 37. PROTOTYPINGMETHODOLOGYPrototyping within an SDLC Process Figure 10.11 Prototyping/Piloting Replaces Page 399 SDLC Definition Phase
    38. 38. NEWER APPROACHES Rapid Application Development (RAD)• Hybrid methodology – aspects of SDLC and prototyping• Goal is to produce a system in less than a year Figure 10.12 Four-Step RAD Cycle Page 400
    39. 39. NEWER APPROACHESRapid Application Development (RAD)Joint application design (JAD) – a technique inwhich a team of users and IS specialists engage inan intense and structured process in order tominimize the total time required for gatheringinformation from multiple participants Page 400-401
    40. 40. NEWER APPROACHESRapid Application Development (RAD)Joint application design (JAD) – a technique inwhich a team of users and IS specialists engage inan intense and structured process in order tominimize the total time required for gatheringinformation from multiple participantsComputer-aided software engineering (CASE) –any software tool used to automate one or moresteps of a software development methodology Page 400-401
    41. 41. NEWER APPROACHESRapid Application Development (RAD) (Adapted from Valacich, George, and Hoffer, 2001) Figure 10.13 Types of CASE Tools Page 401
    42. 42. NEWER APPROACHESRapid Application Development (RAD) Figure 10.14 RAD Advantages Page 402 and Disadvantages
    43. 43. NEWER APPROACHESAgile Software Development Discipline• Alternative methodology for smaller projects• Based on four key values: – Simplicity – Communication – Feedback – Courage• One type: Extreme Programming (XP) – Programmers write code in pairs – Use simple design and frequent testing Page 402
    44. 44. THE MAKE-OR-BUY DECISION • Decision should be made jointly by business managers and IS professionals • Advantages of purchasing: – Cost savings – Faster speed of implementation • Disadvantages of purchasing: – Seldom exactly fits a company’s needs – Often forces trade-offs Page 406
    45. 45. PURCHASING METHODOLOGY The Purchasing Steps Figure 11.1 The Purchasing Process Page 407
    46. 46. PURCHASING METHODOLOGY Initiating the Purchasing Process Figure 11.2 Comparison of Costs and Page 407 Building vs. Purchasing a System
    47. 47. PURCHASING METHODOLOGY Establish Criteria for Selection Figure 11.3 Key Criteria for Page 408 Software Package Selection
    48. 48. PURCHASING METHODOLOGY Develop and Distribute the RFP Request for proposal (RFP) – a formal document sent to potential vendors inviting them to submit a proposal describing their software package and how it would meet the company’s needs Page 409
    49. 49. PURCHASING METHODOLOGYEvaluate Vendor Responses to RFP and Choose Package • Evaluation steps: – Review vendors’ responses from RFPs – Request demonstrations of leading packages – Request references from users of software packages in other companies – Assess how well package capabilities satisfy company’s needs – Understand extent of any additional development efforts or costs to tailor software – Make decision Page 410-411
    50. 50. PURCHASING METHODOLOGYEvaluate Vendor Responses to RFP and Choose Package Figure 11.6 Matching Company Needs Page 411 with Capabilities of the Package
    51. 51. PURCHASING METHODOLOGY Construction Phase • If no software package modifications required: – Skip system design and building steps – Move directly to system testing – Develop any necessary process changes • If software package is modified: – Consider contracting with vendor or a third party for changes versus modifying in-house – Determine if changes are required to other existing company systems Page 413
    52. 52. PURCHASING METHODOLOGYProject Team for Purchasing Packages – Business managers and users – IS professionals – Project manager – usually a business manager – Software vendor personnel – Sometimes includes a third-party implementation partner – Purchasing specialists – Attorneys Page 414-415
    53. 53. PURCHASING METHODOLOGY Purchasing Advantages and Disadvantages Figure 11.7 Advantages and Disadvantages Page 416 of Purchasing Packaged Software
    54. 54. NEW PURCHASING OPTION:APPLICATION SERVICEPROVIDERS (ASPs)• New trend beginning 2000s• Purchasing option: purchaser elects to use a “hosted” application rather than to purchase the software application and host it on its own equipment• ASP is an ongoing service provider• Company pays third party (ASP) for delivering the software functionality over the Internet to company employees and sometimes business partners Page 418
    55. 55. NEW PURCHASING OPTION:APPLICATION SERVICEPROVIDERS (ASPs)• Some advantages: – Cost savings and faster speed of implementation – Usually involves monthly fees rather than large infrastructure investment• Disadvantages: – Dependence on an external vendor for both software and ongoing operations – Good assessment of required service levels even more critical Page 418-419
    56. 56. Potential Problems for Systems Development• Solving the wrong problem.• Poor problem definition and analysis.• Poor communication.• A project that is too ambitious.• A lack of top management support.• A lack of management and user involvement.
    57. 57. Potential Problems for Systems Development• Failure to use a standard systems development approach.• Inadequate or improper systems design.• Poor testing and implementation.• A lack of concern for maintenance.
    58. 58. Success Factors in Systems Development• Clearly defined organizational goals.• A sharp focus on, and clear understanding of, the most important business problems or opportunities.• Clearly defined systems development objectives.• Support of top-level managers. Involvement of users at all stages.• Use of a proven systems development method.• Creating or aligning incremental systems benefits with normal user work activities so as to provide incentives for effective system interaction.• Managing change.• A simple and straightforward design.• Good training programs for all involved.
    59. 59. Global Sourcing• The process of deciding where in the world a firm’s activities will be performed and who will perform the activities. – Fundamentally any activities that does not require direct customer contact, extensive local knowledge, or complex interactions can be sourced anywhere
    60. 60. Global Resourcing
    61. 61. Outshoring and Outsourcing
    62. 62. Definition of Outsourcing• IS outsourcing is the commissioning of part or all of the IS activities an organization needs, and/or transferring the associated human and other IS resources, to one or more external IS suppliers• IS Offshoring is the commissioning of part or all of the IS activities an organization needs to one or more other countries• IS Insourcing is the sourcing of a business function within the firm (e.g., Kingland Systems)
    63. 63. IS Outsourcing• Four Types of Outsourcing Relationships: Support Reliance Alignment Alliance
    64. 64. Outsourcing GridExtent of Substitution by Vendors High Reliance Alliance Support Alignment Low Low High Strategic Impact of IS Applications
    65. 65. Outsourcing Decision Variables• Relationships• Division Among Suppliers and Contracts• Management Structure• Operational Structure• Internal Organization of Outsourcing Coordination
    66. 66. Horizontal and Vertical Integration• Diversification - • Specialization - increasing the reducing the number number of products of products and and services services• Differentiation - • Integration - aka ‘disintegration’ - performing a larger decreasing the number of phases in number of the production chain subsequent phases in the production chain
    67. 67. Backward Vertical Disintegration• Car manufacturer purchasing pre- assembled engines instead of purchasing and assembling the component parts themselves• Decreasing the number of phases a firm performs by commissioning another entity within the production chain to perform those functions