1 / 69

Session 4 – Systems Development Controls

Session 4 – Systems Development Controls. Risks in systems development Systems development process Systems development controls . “ You must be the change you want to see in the world.” - Mahatma Gandhi. Some Statistics on Project Failures. 40% of projects are not completed

Download Presentation

Session 4 – Systems Development Controls

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. Session 4 – Systems Development Controls • Risks in systems development • Systems development process • Systems development controls EECS4482 2016

  2. “You must be the change you want to see in the world.” - Mahatma Gandhi EECS4482 2016

  3. Some Statistics on Project Failures • 40% of projects are not completed • 70% of projects are behind schedule or over budget • 80% of projects fail to deliver all of the expected benefits Source: The Gartner Group EECS4482 2016

  4. Runaway Project • A large private company wrote off $5 million of systems development cost when the new CEO determined that a system that had been under development for 2 years was not going to make it. This led to firing of executives, layoff, bonus cancellation and a pay freeze. EECS4482 2016

  5. Runaway Project EECS4482 2016 The Heathrow Airport Terminal 5 new baggage handling system produced wrong flight status information to the baggage crew. This resulted in bags not getting loaded to the right planes. This cost the airlines $50 million in lost profit.

  6. Runaway Project • After more than four years of hard work and half a billion dollars spent, Trilogy, FBI’s project to modernize its technology infrastructure, has had little impact on the Bureau's antiquated case-management system, which today remains a morass of mainframe green screens and vast stores of paper records. As Senator Judd Gregg observed, "the software, which runs the hardware, is a huge problem. EECS4482 2016

  7. Reasons Organizations Fail to Achieve AIS Acquisition Objectives • Lack of senior management attention. • Shifting user needs. • Lack of standard project management and system development methodologies. • Resistance to change. • Lack of user participation. • Inadequate testing and user training. EECS4482 2016

  8. Risk Factors in Systems Development • Incomplete implementation – high because of the magnitude of a typical project. EECS4482 2016

  9. Risk Factors in Systems Development • Implementing unauthorized system – High because of the different stages at which authorization should be sought. • Implementing inaccurate system – high because of complexity. • Untimely implementation – high because of magnitude. EECS4482 2016

  10. Systems Development Controls • A controlled systems development process is required to mitigate the risks of incomplete, inaccurate, unauthorized, untimely or inefficient systems development. • This process should be documented in a standard corporate systems development methodology that emphasizes documentation, justification, approval, review, monitoring, user involvement and testing. EECS4482 2016

  11. Required Phases of Systems Development • Problem recognition • Feasibility study • System proposal • Analysis of existing system • Project planning • User requirement definition – includes application controls EECS4482 2016

  12. Phases of Systems Development • System architecture – includes general controls • System design – expands application controls • Install infrastructure in development and test environments. • Programming • Testing EECS4482 2016

  13. Phases of System Development • Policies and procedures • Training • Install production infrastructure • Conversion and implementation • Post-implementation review EECS4482 2016

  14. 1. Recognition of a need or problem • New services may be required for customers • There may be a need to keep up with the competition • Government regulations, changing business conditions or simply the passage of time may result in the need for massive changes EECS4482 2016

  15. Problem Recognition • Business area responsible • IT should be involved • Management has to approve before the next phase EECS4482 2016

  16. Feasibility Study • Operational – Can the organization structure accommodate a new solution? • Technical – Does the organization have the technical reach to develop and operate the solution? • Financial – Does the organization have the financial means to develop, acquire and operate the solution? • Financial feasibility is the most important as operational and technical feasibilities affect finance. EECS4482 2016

  17. Feasibility Study • A “champion” or “sponsor” is emotionally and organizationally committed to the system • Key is the manager’s and organization’s attitude toward their employees and the fit with the organizational culture EECS4482 2016

  18. Feasibility Study • Business area responsible • Not applicable for regulatory related problems like HST or IFRS • IT should be involved • The system sponsor (system owner) has to approve EECS4482 2016

  19. System Proposal • Business area should prepare. • Includes proposed solution. • Includes business case. • Management approval, many levels depending on $ of initial cost + annual net cost. • Annual net cost does not include increase in revenue or cost reduction that are subject to uncertainty. It is net only of the sure cost reductions. • May have to go as high as IT steering committee or even the board. EECS4482 2016

  20. Business Case • Be wary of soft savings like salary savings, will position be redeployed or eliminated? • Discount for uncertainty caused by timing remoteness. • Project size increases risk of benefits not materializing. EECS4482 2016

  21. Business Case • Business area should prepare. • Finance should review. • Be wary of intangible benefits, which are usually more uncertain. • Cost avoidance is more certain. • Cost reduction (operation) is less certain as it is harder to take things away than to refuse to give in the first place. EECS4482 2016

  22. System Analysis • Systems analysts should perform, report to project manager. • Project manager is appointed by project sponsor who is the system sponsor. • Project manager should approve. EECS4482 2016

  23. Devise a Project Plan • System sponsor appoints project manager • The project plan includes a broad plan for the entire development, as well as a specific plan for needs analysis—the next acquisition step. The project plan typically includes: • Estimated project scope. • Recommended acquisition team structure, members, and leaders. • Subsequent phases and timetables. • Required tasks. • Required personnel skills. • Sources of required information. • Estimated analysis costs. • Timetable and estimated costs for the entire acquisition and implementation. EECS4482 2016

  24. Project Plan • Should include a GANTT chart that depicts the required tasks by phase, who do what and when, and how much resources, and what deliverables. • This is an extremely useful tool for monitoring project progress. EECS4482 2016

  25. GANTT Chart EECS4482 2016

  26. PERT Chart • This tool shows project activity dependencies. Useful to assess the impact of failed or late activities. • PERT stands for project evaluation and review technique. • This chart displays the critical path, i.e., the path of predecessor dependent activities that will take the longest duration. Any delay in an activity on this path will delay the project. EECS4482 2016

  27. Sample PERT Chart EECS4482 2016

  28. Project Plan • Project manager prepares. • Reviewed by business areas and CIO. • Approved by project sponsor. EECS4482 2016

  29. Effective Project Management • A risk management program to identify and handle risks associated with each project. • Division of the project into manageable chunks, often called phases. Phases should be subdivided into steps, and steps into tasks. • Documentation and approval of work accomplished in one phase before working on the next phase. EECS4482 2016

  30. User Requirements • Detailed and in writing, prepared by user representatives. • Should include application controls. • IT department should review. • Should define the system’s processing logic • Signed off by IT department (including security) and stakeholders. EECS4482 2016

  31. Requirements documentation • This is a detail-oriented stage • Types of information prepared includes: • Info required • Functions required • Input protocols • Reports • Screen layouts EECS4482 2016

  32. System Architecture • Define system boundary. • Define infrastructure, hardware, system software. • Will system be Internet enabled? • Network diagrams EECS4482 2016

  33. System Architecture • What locations will system operate in and support? • Focuses on infrastructure • Responsibility of the IT department, signed off by project manager, business areas and IT security. • Should include general controls. EECS4482 2016

  34. System Design • Design system logic, input requirements and output to meet user requirements in the context of the system architecture. • Includes file layout, database design, report layout, system narrative, entity relationship diagram, and system flowcharts. • Focuses on system functions. EECS4482 2016

  35. System Design • Based on user requirements so can be carried out concurrently with architecture. • Entity relationship diagrams used to show relationship between entities (tables) for database design. • Detailed narrative points that expand user requirements, e.g., providing the detailed formulae for construction cost calculation. EECS4482 2016

  36. System Design • Performed by designers. • Expand application controls in terms of audit trail and how controls are exercised by the system and people. • Reviewed and signed off by user representatives, project manager, IT security and programming manager. EECS4482 2016

  37. Flowchart EECS4482 2016

  38. Entity-Relationship (E-R) Diagram EECS4482 2016 AIS, 2014

  39. Programming • Considered to be a technical process that creates a functional system based on documented requirements • There is also a creative element involved in successful programming EECS4482 2016

  40. Testing • Types of testing: • Unit • String • System integration • Acceptance • Testing may be done by programmers, quality assurance personnel or users EECS4482 2016

  41. Testing • Unit testing – one program at a time, done by programmer, done in personal libraries and development environment. • String testing – several related programs together, done by programmers and peers, in the development library (environment). • Integration testing – Entire system or a major part of a system, done by independent testers, in the test library and environment. Signed off by user areas, project manager, IT security. EECS4482 2016

  42. Policies and Procedures • User procedures • Accounting procedures • Computer Operations procedures • Update disaster recovery plan EECS4482 2016

  43. User Acceptance Testing • User acceptance testing – Entire system + procedures + user interfaces + user environment + system capacity, done by user representatives. This is the most comprehensive level and the last gate in testing. Includes testing for compliance with policies. Will repeat the more important functions tested in system integration testing. Signed off by project sponsor, project manager and IT security. • Performed in the staging library and environment (live simulation). EECS4482 2016

  44. Training • Training plan • Training material • Classroom sessions • Self-helped training EECS4482 2016

  45. Conversion and implementation • Conversion planning • Conversion testing • Conversion • Conversion verification EECS4482 2016

  46. Conversion and implementation • Several conversion and implementation methods • Parallel • Direct cutover • Pilot study • Phased EECS4482 2016

  47. Parallel Approach • Runs the new system and old system concurrently. • Safest but costliest. • Not practical for real time systems. EECS4482 2016

  48. Pilot Approach • Implements the new system on selected business units to test the water. • Retail outlets may use it on one store.- • If the water is OK, full scale implementation. EECS4482 2016

  49. Phase Approach • Implement the new system by functions. • Gradual implementation. • May be less practical for integrated systems. EECS4482 2016

  50. Direct Cut-over • Full scale implementation. • Quickest but riskiest. • OK if fallback is readily available. • Increasingly popular because of increasing use of e-commerce or integrated systems and increasing IT power to facilitate quick fallback. EECS4482 2016

More Related