Chapter 9: Software Acquisition

1. Chapter 9: Software Acquisition IS Security, Audit, and Control (Dr. Zhao) MBAD 7090

2. Objectives • Be aware of the software acquisition process and its importance • Understand how to evaluate and review the software acquisition process IS Security, Audit, and Control (Dr. Zhao)

3. Overview • An organization’s goal for acquiring software is to effectively and efficiently support one or more business process. • IT Audit and Management must include the critical control processes to support and protect the organization. IS Security, Audit, and Control (Dr. Zhao)

4. Software Acquisition Process • Defining the information and system requirements • Identifying alternatives • Feasibility analysis • Risk analysis • Ergonomic requirements • Selection process • Buying the selected software • Completing final acceptance IS Security, Audit, and Control (Dr. Zhao)

5. Defining the Information and System Requirements • System requirements describe needs or objectives for the system • Problem to be solved • Business and system goals • System processes to be accomplished • Deliverables and expectations for the system • The information flow of the system • Defining the information being given to the system to process • Information to be processed within the system • Information expected out of the system IS Security, Audit, and Control (Dr. Zhao)

6. Gathering the Information and System Requirements • Interview: • Managers • Expected users • IT management and staff • Other affected parties • Review related documentations • Observe related business processes • Research other companies in a related industry IS Security, Audit, and Control (Dr. Zhao)

7. Requirements Document • A System Requirement Document contains: • Intended users • Scope and objectives • System goals and objectives • Feasibility analysis • Assumptions made • Expected system functions • System attributes • Context or the environment that system will reside IS Security, Audit, and Control (Dr. Zhao)

8. Identifying Alternatives • Off-the-shelf solutions • In-house development • Contracted development • Outsourcing from another company IS Security, Audit, and Control (Dr. Zhao)

9. Off-The-Shelf Solutions • Commercially available product that requires organizations: • Adapt to the system’s functionality • Customize the product • “Don’t build if you can buy.” IS Security, Audit, and Control (Dr. Zhao)

10. Off-The-Shelf Solutions Advantages Disadvantages • Shorter implementation time • Use of proven technology • Availability of technical expertise outside of the company • Available maintenance and support • Easier to define costs • Incompatibility with company’s requirements • Long-term reliance on a vendor • Specific hardware and software requirements • Limitations on use or changes to product IS Security, Audit, and Control (Dr. Zhao)

11. When Selecting a Vendor System • Should be taken into consideration: • Stability of vendor company • Volatility of system upgrades • Existing customer base • Vendor’s ability to provide support • Required support software • Required modifications to software IS Security, Audit, and Control (Dr. Zhao)

12. Contracted Development Procure personnel to develop or customize a system. Advantages Disadvantages • Provides control over costs and implementation schedule • Technical expertise of vendor • Higher labor costs compared to in-house staff • Contract staff turnover • Business viability of vendor • Additional maintenance costs • Lack of organizational understanding IS Security, Audit, and Control (Dr. Zhao)

13. Outsourcing Development Another company develops the system for your organization. Advantages Disadvantages • Focus on core competencies • Cost-effective • Quickly respond to business needs • Technical expertise is greater • Increased reliance on a vendor • Decreases the ability to acquire the expertise and experience of vendor IS Security, Audit, and Control (Dr. Zhao)

14. Feasibility Analysis • Defines the constraints/limitations for each alternative: • Economically • Technically • Operationally • Legally • Politically IS Security, Audit, and Control (Dr. Zhao)

15. Economic Feasibility • Cost/benefit justification: • Expenses: • Start-up infrastructure • Support staff • Software • Training, communications • Benefits: • Cost and error reduction • Increased speed and response time • Better efficiency and effectiveness IS Security, Audit, and Control (Dr. Zhao)

16. Technical Feasibility • Evaluates consistency of proposed system with the technical strategy: • Needed hardware, software, and network resources • Technical expertise requirements to support proposed system • Provide reliability and growth IS Security, Audit, and Control (Dr. Zhao)

17. Operational Feasibility • How well the proposed system solves business problems or provides business opportunities • Extent of organizational changes • Personnel • Business processes • Products/services offered IS Security, Audit, and Control (Dr. Zhao)

18. Legal and Contractual Feasibility • Reviews logical or contractual obligations: • Legal constraints • Federal and state law • Industry laws • Pre-existing conditions that prohibit the use of the software IS Security, Audit, and Control (Dr. Zhao)

19. Political Feasibility • How well the internal organization will accept the new system • Includes an assessment of desire for new system and its fit within the corporate culture IS Security, Audit, and Control (Dr. Zhao)

20. Conducting a Risk Analysis • Reviews the security • Threats • Potential vulnerabilities • Impacts • Controls review • Systematic or automated reviews • Audit trails • An example IS Security, Audit, and Control (Dr. Zhao)

21. Defining Ergonomic Requirements • Provide a work environment that is safe and efficient for employees: • Workplace design: • Monitor • Keyboard and mouse • Prevent repetitive motion injuries IS Security, Audit, and Control (Dr. Zhao)

22. Selection Process • Identifying the best match between the alternatives and your requirements: • Request for Information (RFI) • Asks vendors to respond to questions • Request for Bid (RFB) • Selection solely based on cost and schedule requirements • Contract terms are non-negotiable or fixed • Request for Proposal (RFP) • States the minimally acceptable requirements and the evaluation criteria for selection: • Functional • Technical • Contractual • Deadline for vendor response IS Security, Audit, and Control (Dr. Zhao)

23. RFP Components • Background on company and its environment • Important dates • Contact names for RFP questions • Instructions for response format • Specific requirements for system • Technical requirements • Vendor requirements • Evaluation • Done by committee using a list of objective selection criteria (user and system requirements) • An example IS Security, Audit, and Control (Dr. Zhao)

24. Vendor Contract Terms & Conditions • Functional definition • Screen and report layouts • Hardware and system software requirements • Conversion requirements • System performance • Vendor staffing • Testing procedures • Schedule dates for milestones • Maintenance and support • Documentation • An example IS Security, Audit, and Control (Dr. Zhao)

25. Final Acceptance • Acceptance plan is included in the contract • Defines the terms and conditions of acceptance • Final payment is withheld under completion of vendor responsibilities IS Security, Audit, and Control (Dr. Zhao)

26. Case Discussion • Please read the scenario in the handout and answer the following questions: • How would you gather the requirements for the system? • Please identify important information and system requirements. • Describe two or three alternatives that should be considered. • Choose one alternative, and explain how you would perform a feasibility analysis. • Who would you recommend to be on the acceptance testing team? IS Security, Audit, and Control (Dr. Zhao)

27. Auditor involvement • Risks with buying software: • Selected solution does not satisfy the intended purpose • Selected solution is not technically feasible • Increased costs, missed deadlines, or neglected requirements • IT Audit provides an objective evaluation of the processes and procedures in place and whether the acquisition was in compliance with institutional processing and operating procedures IS Security, Audit, and Control (Dr. Zhao)

28. Software Acquisition Controls • Alignment with company’s business strategy • Defined requirements • Feasibility studies • Conformity with existing infrastructure • Security and control requirements • Buy in from user • Functionality, operational, acceptance, and maintenance requirements • Supplier viability IS Security, Audit, and Control (Dr. Zhao)

29. Information Requirements • Current and complete • Requirements gathered too far in advance tend to become outdated • Revising requirements can result in changes to scope, expectations, costs, and project success • Prototypes misperceptions Back IS Security, Audit, and Control (Dr. Zhao)

30. Security and Control Requirements • Selected solution adheres to company security policies and regulations • Performed by company security officer • Policies and requirements are fully documented • Performed by company security officer and management IS Security, Audit, and Control (Dr. Zhao) Back

31. Supplier Viability Vendor requirements: • Stability • Volatility of system upgrades • Existing customer base • Ability to provide support • Required software or modifications to base software • Financial condition • Risk of acquisition • Likelihood of exiting the market • Reputation for responsiveness to problems IS Security, Audit, and Control (Dr. Zhao)

32. Due Audit Plan - This deliverable must include the following components • Audit scope • Risk assessment (including list of appropriate laws/regulations) • Audit approach (interview versus testing) • Sequencing of the audit activities to be performed • Document request list • List of individuals that would be subject to interview (listed by role or responsibility) • Due: November 10, 5:00pm • Please submit the electronic version to kzhao2@uncc.edu IS Security, Audit, and Control (Dr. Zhao)