1 / 50

Information Systems Technology

Information Systems Technology. Chapter 11: Managing The Development And Purchase Of Information Systems. Systems Development Methodologies. How to develop the “ blueprints ” for building an information system Systems development methodologies (SDM)

nuri
Download Presentation

Information Systems Technology

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Information Systems Technology Chapter 11: Managing The Development And Purchase Of Information Systems

  2. 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

  3. Traditional Systems Development Life Cycle (SDLC) • Seven phases (also called the waterfall model) • Planning • Systems Analysis • Systems Design • Development • Testing • Implementation • Maintenance

  4. Traditional Systems Development Life Cycle (SDLC) • Five phases • Investigating/Planning • Systems Analysis • Systems Design • Development • Programming or Acquisition • Testing • Implementation • Maintenance

  5. Systems Development Life Cycle (SDLC) • Usually complete one phase before beginning the next • Problem in later phase may require return to previous phase • Traditional Approach

  6. Incremental Commitment A strategy in systems analysis and design in which the project is reviewed after each phase and continuation of the project is rejustified in each of these reviews

  7. Investigation/Planning • Feasibility analyses • Technical – • Do the technologies exist to solve the problem? • Do we have the skills to develop/use the technology? • Economic – • Can the organization afford the system and will it provide an adequate ROI? • Costs/Benefits • Tangible vs Intangible • One time versus re-occurring • Operational – Assesses the human element of the proposed system? • Personnel Skills • Schedule – Is the proposed development time line realistic?

  8. Other Types of Feasibility • Legal and Contractual • Political

  9. Legal and Contractual Feasibility • The process of assessing potential legal and contractual ramifications due to the construction of a system • International systems: cross-borders laws and regulations

  10. Political Feasibility The process of evaluating how key stakeholders within the organization view the proposed system

  11. Project Scope • General Project Information • Problem/Opportunity Statement • Project Objectives • Project Description • Business Benefits • Project Deliverables • Estimated Project Duration

  12. Systems Analysis • Systems analyst works with company to understand the problem fully and detail the requirements of the proposed solution

  13. Requirements Analysis • Questionnaires • Interviews • Observation of Workers • Document Analysis

  14. Interviews vs Questionnaires CharacteristicsInterviewsQuestionnaires Information Richness High Medium to Low Time Required Can be extensive Low to Moderate Expense Can be high Moderate Follow-up Questions High Limited Confidentiality Little High Potential Audience Limited Number Can be large Involvement of subject Active Passive

  15. Worker Observation vs Document Analysis CharacteristicsObservationDocument Information Richness High Low Time Required Can be extensive Low to Moderate Expense Can be high Low to Moderate Follow-up Questions High Limited Confidentiality None Varies Potential Audience Limited Can be biased by which documents were kept Involvement of subject Varies None

  16. Systems Design • Describe in detail how to build the system • Logical systems design – what the user wants • Details the system’s functionality – user viewpoint • Structure chart – overall, top-down representation of system’s modules • Physical systems design – How to do what the user wants • Specifies all of the actual components used to implement the logical design • Database • Hardware • Networks

  17. Systems Design • Design frozen at end of this phase • Scope creep • Feature creep

  18. 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.

  19. Programming Alternatives • Purchase a packaged system • Outsource development – customized system

  20. Types of Testing • Manual • Inspection • Walk-throughs • Automated • Stub • Unit • System • Volume • Acceptance

  21. Types of Testing • Inspection • Formal group activities where participants manually examine code for occurrences of well-known errors, syntax, logic • Where is the read next record • Dates • Negative Logic • Function of the code is not tested

  22. Types of Testing • Walkthroughs • Manual check of the function of code • “Random” group of programmers • Who selects the programmers • Should the BOSS be at the walk through • Checks consistency of code with coding standards • When • Before computer testing • After computer testing

  23. Automated 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

  24. Stub Testing • Each module is tested alone in an attempt to discover any errors in its code • Test each line of code

  25. Unit Testing • The process of bringing together all of the modules that a program comprises for testing purposes.

  26. System Testing • Bringing together of all of the programs that a system comprises for testing purposes in a top down fashion • Start with the control module

  27. Volume Testing • Increase size of file • Increase number of users • Impact on storage/response issues

  28. Stress Testing • Tries to break the hardware system. • Impact on other systems • Problems with concurrent users

  29. Recovery Testing • Can a corrupt file be recreated? • Amount of lost data • Backing up of data • Full versus Incremental • Timing • How long/how many of the backups should be saved?

  30. Acceptance Testing • The process whereby actual users test a completed information system

  31. Software Testing Issues • Who should do the testing • programmers • professional tester • the end user • Testing Strategies: • Black box • White box • Alpha • Beta

  32. Alpha/Beta Testing • Alpha Testing • Using simulation data • Beta testing • Using real data • Done by user in the user environment

  33. Test Scripts • Using simulation data • Create a test case to ensure that each line of code will be tested

  34. Test Scripts • Identify test case • Specify in detail desired outcomes of test case • Specify in detail actual outcomes of test case • Resolve discrepancies, if any • Who should do this? • To whom should the discrepancy be reported? • Log the results

  35. Implementation • Data conversion • User training • Implementation strategy • Parallel conversion • Direct cutover • Pilot installation • Staged conversion

  36. Parallel Installation Running the old information system and the new one at the same time until management decides the old system can be turned off

  37. Parallel Conversion • Both the old and new systems are operated together until IS, end users, and managers determine that the new system is functioning correctly • Output of one system is compared to the output of the other • Old system can be considered a backup for the new system if there is a massive problem • Use with CRITICAL applications

  38. Parallel Conversion • Advantages • Safest • Strong end user satisfaction and approval • Disadvantages • Cost of using two systems • Computer time and personnel resources • End users are oppose to double work for IS validation

  39. Plunge or Direct Installation Changing over from the old information system to a new one by turning off the old system when the new one is turned on

  40. Plunge Conversions • Stop the old and start the new • Use if the old system is no longer available • hardware failure • massive user requirement changes

  41. Plunge Conversion • Advantages • Cheapest • Easiest from user viewpoint • Disadvantages • Riskiest (no backup in case of severe error) • Requires extensive planning and testing

  42. Pilot of Single Location Installation Trying out a new information system at one site and using the experience to decide if and how the new system should be deployed throughout the organization

  43. Pilot Conversions • Test the new system out in part of the firm • Use with “brand new” applications in the firm • Use with new hardware • Similar to the concept of test marketing

  44. Pilot Conversion • Advantages • Negative impart of software error is minimized • Personnel in trial area can assist other personnel in the changeover • Disadvantages • IS specialists must maintain two systems

  45. Phased Installation Changing from the old information system to the new one incrementally, starting with one or a few functional components and then gradually extending the installation to cover the whole new system

  46. Phased Installation • Install a few functions at a time • Example: student record system • Registration • Textbooks • Student Transcripts • Graduation Validation

  47. Staged Conversions • Implement part of an application at one time • Gradual implementation is preferred with very large and complex systems

  48. Staged Conversions • Advantages • Users can reap the benefits of part of the system before the entire system is completed • Users see part of the system faster • An error in one part of the system can be corrected in the other parts before implementation • Disadvantages • May need interfaces between new and old system ($$, time to develop interfaces)

  49. 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

More Related