IS Acquisition Development and Implementation Tutorial

3.1 IS Acquisition Development and Implementation

Hello and welcome to the third domain of the Certified Information Systems Auditor (CISA) (Pronounced as: ceesa) Course offered by Simplilearn. This domain will cover information system acquisition, development and implementation. Let us look at the objectives of this domain in the next screen. Objectives After completing this domain, you will be able to Understand and provide assurance that the practices for the acquisition, development, testing and implementation of information systems meet the enterprise’s strategies and objectives. Discuss project management control frameworks Detail configuration and release management Understand system migration and infrastructure deployment practices List project success criteria and risks Understand Post-implementation Review Objectives and Practices We shall look at an overview of this domain in the next screen. Overview Organizations need proper processes and methodologies when creating and changing application systems and infrastructure components. This is what is referred to as life cycle management of information systems. Life cycle management requires thinking from end to end, when it comes to information systems, that is, from the process of planning to acquire, acquiring, using, this includes maintaining the system and finally retiring it or them. The CISA candidate must understand the various concepts and hence be able to identify which elements may represent the greatest risk and which controls are the most effective at mitigating this risk . Let us start with the first topic in this domain in the following screen.

3.2 Knowledge Statement 3.1

In this topic, we will learn about main objective of this domain the concepts under knowledge statement 3.1. We will begin with benefits realization in the following screen. Benefits Realization Practices The CISA candidate should have Knowledge of benefits realization practices (e.g. feasibility studies, business cases, total cost of ownership or TCO and ROI). The objective of IT projects is to realize tangible benefits. Managing these benefits is essential to the success of projects. A cost benefit analysis should be prepared prior to beginning a project. This should estimate all costs and benefits throughout the life of a new system. It is important to note that the IS Auditor should ensure that when a cost benefit analysis is being prepared for a project considered by the management, the risks associated with the project have been assessed and the cost factor includes the cost of necessary controls. The following screen lists the main areas to be covered under this knowledge statement. Main Areas of Coverage The main areas of coverage in this domain area are; business Realization, business Case Development and Approval, benefits Realization Techniques, description of Traditional SDLC Phases and feasibility Study We shall look at benefits realization in the next screen Benefits Realization. Benefits realization is the process by which an organization evaluates technology solutions to business problems. It is a compromise among factors such as, Cost, quality, Development /time delivery, Reliability and dependability. Let us look at the benefits realization technique in the following screen. Benefits Realization Techniques The Benefits realization technique is a concept in which the organization should consider total benefits and total costs throughout the life of the new system . It is also referred to as benefits management. Post implementation review which involves documenting lessons learnt . This can be done 6-18 months after implementation of the system. Benefits realization must be part of governance and management of projects. Let us look at business case development and realization in the next screen. Business Case Development and Realization. Business Case is normally derived from the feasibility study, and contains information for the decision-making process on whether a project should be undertaken; if so, it becomes the basis for a project. A feasibility study on the other hand scopes the problem, outlines possible solutions, and makes a recommendation on what action to take. A business case of sufficient detail for each solution should be developed in order to allow a comparison of costs and business benefits. Let us look at the requirements of a business case in the following screen. Business Case Requirements A business case should answer the question, “Why should this project be undertaken?” as well as being a key element of the decision process throughout the life cycle of any project. It should be reviewed to ensure that it is still valid and be reapproved through departmental planning and approval process, if the business case changes during the project. Let us learn about a feasibility study in the software development lifecycle or SDLC in the next screen. SDLC - Feasibility Study A Feasibility study in business case development scopes the problem, outlines possible solutions, and makes a recommendation on what action to take regarding the undertaking of a project. It defines: the need or problem; possible or alternative solutions to the need; Financial appraisal – which can use different techniques such estimated payback period and return on investment (ROI) , Internal Rate of Return (IRR), among others; expected benefits such as productivity gains and cost reduction; and intangible benefits. Let us continue to understand an SDLC feasibility study in the following screen. SLDC–Feasibility Study (contd.) A feasibility would involve the assessment of: risks associated with the solutions; buy versus develop; time-frame required to implement the solution; whether the current system can be modified to meet the need and availability of vendors for the solutions identified. Other factors to be assessed in a feasibility study are compatibility with the business strategy. The key output of a feasibility study is a comparative report, with all alternatives analyzed and the recommended alternative or solution given. Let us look at the traditional software development lifecycle also known as the waterfall technique in the next screen. Traditional SDLC Phases/Waterfall Model Traditional System Development Life Cycle or the Waterfall model is based on a systematic, sequential approach to software development (largely of business applications). It is the oldest and most widely used methodology for developing systems. The five software development lifecycle (SDLC) phases are: Feasibility study which involves defining the problem and developing the business case justification, requirements definition which involves defining the functional and quality requirements of the desired solution, design stage, which developing baseline system specifications (program and databases), including security plans, development stage which mainly consists of programming and testing and finally implementation which involves deploying the new system, user acceptance testing, and commissioning. In the following screen, we will look at the disadvantages of this approach. Disadvantages of Traditional SDLC The disadvantages with this technique are unrealistic or unanticipated events typical in real programs rarely follow a structured sequence; changing business environment alters user requirements before final delivery and managing requirements to ensure functionality is not compromised. Other disadvantages are user requirements are rarely captured fully at the early stages as required and that working version of the system is only available towards the end, necessitating user patience. However, it should be noted that the key advantage of the waterfall technique is that it provides a template for capturing requirements. In the next screen, we shall look at the SDLC design. SDLC - Design Design involves developing blueprints of the system and its components. The blueprints should show how requirements will be met. Design may involve several iterations to get to the level of detail required for development /coding. The components or modules of design are system flowcharts, data and process flows; input and outputs, screen designs and reports; processing steps and computation rules and program specifications and database file design. Other components are test plans (unit, subsystem/module, integration/system, interfacing, security, backup and recovery); and data conversion plans. Analysts and programmers involved; users are not so much involved in this stage. Let us continue to understand the Design phase in SDLC in the following screen. SDLC—Design (contd.) The software Baseline sets a cut-off point beyond which changes require strict formal approval; guards against scope creep; and introduces software configuration management. The Change control processes ensure new requirements or changes are subject to the same formal review and approval procedures; and prevent uncontrolled entry of new requirements Let us look at SDLC testing in the next screen. SDLC - Testing Testing ensures that; programs function as designed; and operate without malfunction or adverse effect on other system components. There are four general testing levels. The first is unit testing which involves testing individual programs or modules. The second is Interface / integration testing which involves connection of two or more components that pass information. Let us look at the other levels of general testing in the following screen. SDLC–Testing (contd.) Next, comes system testing which involves the collective constitution of the programs or modules as one system. System testing involves various areas such as recovery testing which tests the ability to recover from failure; security testing which looks at access controls and impact on other systems; Load testing looks performance during peak hours (processing with large volumes of data); and volume testing which applies incremental records to determine maximum volume of data the application can process. System testing also includes stress testing that checks the number of concurrent users and/or services that can be supported at a time (by increasing transactions progressively) and performance testing that compares against other equivalent systems and/or benchmarks . The fourth level of testing is the final acceptance testing that is done during implementation, and considers: Quality assurances which are the technical aspects such as documented specifications and technology employed and user acceptance which looks at whether the system is able to satisfy all requirements. Let us look at common testing terminology in the next screen. SDLC – Testing Terminology Alpha and beta testing refers to testing before the program is finished; while alpha testing involves internal users only; beta testing is the last stage of testing that involves a small number of external users. Pilot testing is a test focusing on specific, predetermined aspects of the system. White box testing is a close examination of procedural detail and specific logic paths; while black box testing is an examination of outputs and observable system behavior; disregards internal program structure; and applicable to integration and user acceptance testing. Let us continue to look at different software testing in the following screen. SDLC – Testing Terminology (contd.) Function/validation testing is a testing functionality against detailed requirements while regression testing involves rerunning tests to ensure changes or corrections have not introduced errors; data used should be the same as data used in original system. Parallel testing is feeding test data into two systems and comparing results; while sociability testing involves evaluating impact on existing systems or environment. Automated application testing involves using test data generators to systematically generate random test data; and interactive debugging aids and code logic analyzers are available to assist in testing activities. We shall look at SDLC implementation in the next screen. SDLC – Implementation Implementation involves putting the new system into operation, and involves final acceptance testing. Certification ensures the system meets minimum security requirements as set by the organization. Accreditation is where a senior official in management takes up responsibility and accountability of using the system in operations and the resultant impact. A certification and accreditation before implementation would ensure effectiveness at: mitigating risks to an appropriate level and establishing level of internal control; and providing management accountability on systems effectiveness in meeting intended business objectives. Let us continue the discussion of Implementation in the following screen. SDLC–Implementation (contd.) The final step is the migration to production or live environment, during which: testing is completed; procedures are documented and in place; necessary data is converted into the new system; and user training is completed. In the following screen, we shall look at the SDLC implementation plan. SDLC – Implementation Plan An implementation plan details information such as the staff responsible as the single point of contact (SPOC), the tasks involved, and the process of verifying the tasks documented; the timetable; and back-out procedures to handle any problems encountered. Let us now look at the phases in implementation. The first phase in an implementation is to develop to-be support structures, carry out gap analysis and define roles. The second phase involves establishing support functions with an SLA, Implementation plan and or knowledge transfer plan and training plans. In the following screen, we will understand data migration or porting under the implementation plan. SDLC–Implementation Plan (contd.) Another critical stage in implementation of a new system is data Migration or porting. First it is important to identify what data to convert programmatically and what to convert manually; any necessary data cleansing is carried out, methods to verify conversion, For example; file comparisons, balance comparisons are detailed and parameters for successful conversion, e.g. percentage consistency are documented. It is also important to schedule the sequence of conversion tasks; documentation of audit trails e.g. data mapping; exception reports to capture items not converted automatically and responsibility for verifying and signing off conversion steps. The other actions involve testing conversion programs; and Carry out conversion “dress rehearsals” and control of outsourcing conversion process ensuring nondisclosure, data privacy/destruction and other warranties. Let us look at diagrammatic representation of data migration in the next screen. SDLC – Data Migration This diagram illustrates how data is extracted from the legacy application to a staging layer, the files are loaded and validated and then uploaded to the target system. Proper processes and building tools should be required to extract data from legacy system to target system You will now attempt a question to test what you have learnt so far.

3.4 Knowledge Statement 3.2

In this topic, we will learn about the concepts under knowledge statement 3.2. We will begin with project governance mechanisms in the following screen. Project Governance Mechanisms The CISA candidate should have knowledge of project governance mechanisms (e.g., steering committee, project oversight board, project management office). Strong project governance is essential for successful project implementation by ensuring effective and efficient deployment of project resources is enhanced by having adequate project governance mechanisms. The more complex the project, the more elaborate the governance structures and mechanisms. The IS Auditor should be aware of the available business structures that should support and manage a project and the essential constituents of these structures, i.e., who should lead the various committees, who should be members, roles and responsibilities, etc. The following screen lists the main areas to be covered under this knowledge statement. Main Areas of Coverage: The main areas of coverage are Portfolio or Program Management, Project Management Structure, Project Organization Forms and roles and Responsibilities of Groups and Individuals We shall now look at the project management structure in the next screen. Project Management Structure Project Management Structure is the approach taken towards project management. There are many approaches for project management. They are either focused on software development or a more general approach. The different approaches that can be used for project management are: Project Management Body of Knowledge (PMBOK ®) - (IEEE Standard 1490) from PMI Institute, projects In Controlled Environment (PRINCE2 ®) from the office of Government Commerce (OGC) in the UK and International Project Management Association (IPMA) Let us look at the general aspects of various project management approaches in the following screen. IS Project Management An information systems project maybe initiated from any part (division, department or function) of the organization. All projects are time bound (that is, they have start and finish dates) and with each project risk element exists in every project. The project should have specific deliverables and objectives and the project management process should be well designed. For instance, a business process reengineering (BPR) project requires extensive planning to succeed Let us look at a program in the next screen. Program A program is a group of projects and time-bound tasks that are closely linked together through common objectives, a common budget, and intertwined schedules and strategies. Like projects, programs have a limited time frame (start and end date) and organizational boundaries. Let us look at the differences between a program and a project in the following screen. Program vs. Project There are clear differences between a program and a project. Programs are more complex, usually have a longer duration, a higher budget, and higher risks associated with them and are of higher strategic importance than projects. Projects are smaller in terms scope, time and budget. A program can constitute many projects. We shall learn about portfolio or program management in the next screen. Portfolio or Program Management Portfolio or Program management is the application of knowledge, skills, tools and techniques towards a stated objective. Let us consider an example here. A Business Process Reengineering (BPR) or process automation undertaking in an organization can be thought of as a program by virtue of having the characteristics mentioned in the previous screen. It may involve a number of a projects such as, network Infrastructure Upgrade, e.g. creating a wide area network (WAN) to link branches in different countries, states or cities, business application development project such as Payroll, Financial Management System, Customer Relationship Management or CRM system and training of staff to understand the new processes and change in their roles. Let us look at the activities that constitute portfolio or program management in the following screen. Portfolio or Program Management–Activities Portfolio or Program management basically involves controlling time and cost. It consists of initiating, planning, executing, controlling and closing a program, it covers software size estimation, scheduling, allocating resources and measuring productivity. Let us look at an illustration of the roles and responsibilities in a project in the next screen. Project Roles There various stakeholders in a project that includes a steering committee, senior management, project sponsor and user management. The other roles or teams in a project include the project manager, quality assurance, the development team, the user project team, technical infrastructure team and security officers. Let us look at the responsibilities of these roles in the following screen. Roles and Responsibilities In a project, the senior management usually demonstrates commitment and final approval. The user manager is the program and system owner who assigns resources, approves deliverables, and participates in requirements definition, acceptance testing and user training. The program steering committee provides overall direction, appropriately represents all affected parties, and ultimately responsible for costs and timetable. The program sponsor provides funds the program, typically the senior manager of the affected business function, and chairs the Program Steering Committee. The program manager provides day-to-day Program management. Let us look at more roles and their responsibilities in the following screen. Roles and Responsibilities (contd.) The system development management provides technical support for hardware and software environment. The systems development program team are the technical staff who perform program tasks. The user program team are users who perform program tasks. On the other hand security officer ensures adequacy of system controls and compliance to security policies. The quality assurance reviews deliverables for compliance to requirements and defined standards. The IS auditor ensures controls are implemented in the new system. You will now attempt a question to test your knowledge of what you have learned so far.

3.6 Knowledge Statement 3.3

In this topic, we will learn about the concepts under knowledge statement 3.3. Let us discuss project management control frameworks, practices and tools in the following screen. Slide 45: Project Management Control Frameworks, Practices and Tools The CISA candidate should have knowledge of project management control frameworks, practices and tools. The project manager’s skill set should be commensurate with the project at hand. To manage all the relevant parameters of a large project, project management practices, tools and control frameworks are required. Projects need to be managed on hard, soft and environmental factors. The following screen lists the main areas to be covered under this knowledge statement. Slide 46: Main Areas of Coverage The main areas of coverage in this knowledge area are project Objectives , initiation of a Project, Project Planning, Project Controlling, Closing a Project, Description of Traditional SDLC phases and development Methods. The other areas to be covered are use of Structured Analysis, Design and Development Techniques , infrastructure Development, process Improvement Practices , business Process Reengineering and Process Change Projects, ISO 9126 and capability Maturity Model Integration Let us look at project organizational forms in the next screen. Slide 47: Project organizational forms Project management structure is the approach taken towards project management. Project context and environment can be divided into time and social contexts. There are 3 project organizational forms. In the influence form, the project Manager has no formal authority, only has a staff function and only has an advisory role. In a pure project form the project Manager has formal authority, at times special working area provided from normal office. In a matrix project organization the management authority shared between project manager and departmental heads. Let us look at Project objectives in the following screen. Slide 48: Project Objectives There are various objectives of a project. The main objectives are those objectives that contribute to the success of the project such as faster transaction time. Additional project objectives are objectives that are not directly related to the main results of the project but may contribute to project success (e.g., business unit reorganization in a software development project). Non-objectives add clarity to scope and make project boundaries become clearer. These objectives can be defined normally using an Object Breakdown structure. Let us learn more about communication in project management structure in the next screen. Slide 49: Project Communication On initiating a project management process, communication may be achieved in a number of ways depending on its size and complexity as shown below. There are 3 project Communication types. The first in one-on-one meetings. This facilitate two-way communication between project team members and the project manager. Secondly the project manager can organize kick off meetings. This is used by project manager to inform team of what of what has to be done for the project and project start workshops which ensure communication is open and clear, allow buy-in from stakeholders. The project can also use a combination of the three communication types In the following screen, we will look at project culture. Slide 50: Project Culture Project culture represents the norms and rules of engagement of the project. It is the common understanding or the orientation expected of the team. Project culture development /influencing method include establishment of a project mission statement, project name and logo, project office or meeting place, project intranet, project team meeting rules and communication protocols and project specific social events. We shall look at project management practices and initiation in the next screen. Slide 51: Project Management Practices and Project Initiation Project Management Practices is the application of knowledge, skills, tools and techniques to a broad range of activities to achieve a stated objective such as meeting the defined user requirements, budgets and deadlines for an IS project. There are 5 project management processes that is initiating, planning, executing, controlling and closing the project. We will continue to discuss Project Management practices and project initiation in the following screen. Slide 52: Project Management Practices and Project Initiation (cont.) Projects have three key intertwining elements; deliverables, duration and budget. These should have positive correlation. Quality of the deliverables is a key consideration for the project steering committee or the project sponsor. Project initiation is done by a project manager or a sponsor gathering all information required to gain project approval. This will become the Terms of Reference or Project Charter The project charter contains; objective of the project, stakeholders of the expected and project manager and sponsor. The approval of the Project Initiation document (PID) or a Project Request Document (PRD) is authorization of the project to begin. In the following screen, we will learn about software size estimation as part of the project management practices and initiation. Slide 53: Software Size Estimation Software size estimation refer to methods of determining the relative physical size of application software to be developed. They guide allocation of resources, and estimation of time and cost required in order to compare the total effort required by the resources. Traditionally done with single-point estimations (i.e. based on a single parameter) such as Source Lines of Code (SLOC). For complex system SLOC have proven to be limited affecting cost, schedule and quality metrics. To address this, Multiple-Point Estimation has been designed a good example being the Function point analysis (FPA). We will continue to learn about software size estimation in the following screen. Software Size Estimation (contd.) Function Point Analysis is an indirect measure of the size of an information system (software size) based on number and complexity of inputs, outputs, files, external interfaces and queries. Complexity adjustments (i.e. rating factors) are used based on analysis of reliability, criticality, complexity, reusability, changeability and portability etc. Let us look software cost estimation in the next screen. Software Cost Estimation Software cost estimation is a consequence of software size estimation and involves estimation of programs at each phase. Automated techniques for cost estimation of projects can be used at each phase of system development. Some of the components that have to be considered when using these techniques include; Source code language; Execution time constraints; Main storage constraints; Data storage constraints and computer access. Other factors include target machine used for development; security environment; and staff experience We shall look at budgets and schedules in the next screen. Budgets and Schedules Scheduling involves establishing the sequential relationships among tasks: logically, with allowance for parallel tasks, while taking into account allocation of resources. Budgeting involves estimating amount of effort required in human and machine hours The schedule can be graphically represented using various techniques such as Gantt charts, the Critical Path Method (CPM), Program Evaluation Review Technique (PERT) diagrams. These tools should be revisited to verify compliance and identify variances. Variances and variance analysis including cause and corrective action should be reported to management on a timely basis. Let us look at the critical path methodology in the next screen. Critical path methodology (CPM) This diagram shows that a project can be represented as a network where activities are shown as branches connected at nodes immediately preceding and immediately following activities. It is important to note that a delay in the critical path will translate to a delay in the whole project. Let us learn about project evaluation review technique or PERT in the next screen Program Evaluation Review Technique (PERT) Program evaluation review technique (PERT) is used for planning and control. It involves estimation of time and resources required, and detailed scheduling (timing and sequence). See the diagram on the screen for an illustration. We shall learn about Gantt charts in the next screen. Gantt Charts Gantt charts are a Graphical representation of scheduled task as illustrated in the diagram on the screen. Let us learn about timebox management in the next screen. Timebox Management Timebox management is a project management technique for defining and deploying software deliverables within a relatively short and fixed period of time, and with predetermined specific resources . There is a need to balance software quality and meet the delivery requirements within the timebox or time window. It is well suited for prototyping or rapid application development and is aimed at preventing cost overruns and schedule delays. In Timebox management, quality is often compromised for time, while key features may include interfaces for future integrations. The main advantage of this technique is that it prevents project cost overruns and delays from scheduled delivery. Let us look at project controlling activities in the next screen. Project Controlling Activities Project controlling activities include management of scope, resource usage and risk. New requirements of the project should be documented and if approved allocated the appropriate resources. To manage scope the deliverables are broken down to a proper documentation in a component management database (CMDB) and changes to scope will always lead to changes in activities hence impacting deadline and budget. As such there is need to formally handle changes. Let us look at the change management process in detail in the following screen. Change Management Process The Change Management Process starts with a formal change request containing a clear description of the requested change and reasons for change. Change request is submitted to the project manager (copies stored in project file). The change Advisory Board then evaluates the change request (on behalf of the sponsor) and decides whether to recommend the change, if accepted the project manager updates the project plan to reflect the requested change. The project sponsor after evaluating the new plan may accept or reject the recommendations of the Change advisory board. We shall look at resource usage management in the next screen. Resource Usage Management Resource usage is the process by which the project budget is being spent. It checks if actual spending is in line with planned spending, resource usage must be measured and reported. Every budget and project plan presupposes a certain "productivity" of resources and Delivers the expected quality of the outcome/deliverable. Earned Value Analysis (EVA) technique can be used to check this. It involves comparing the following continuously; budget to date, actual spending to date. Let us look at an example for resource usage in the following screen. Resource Usage Management – Example Let us take an instance of monitoring the daily progress (productivity) of 3 day job by a programmer. If a task is planned to take 24 man-hours, then it is implied that the resource being deployed is capable of finishing that task in 23 man-hours and, at the same time, delivering results at a satisfactory quality level. Let us look at risk management in the next screen Risk Management Risks are the possible negative events or conditions that would disrupt relevant aspects of the project. There are two main categories of project risk: those that impact the project itself. The project manager is responsible for mitigating this risk. Think of it as risks within the project. And those that impact the business benefits and therefore endanger the reasons for the project's very existence, the project sponsor is responsible for mitigating this risk Think of it as business risk of the project. Let us look at the risk management process steps in the following screen. Risk Management Process Steps The risk management process steps include identification of risks: assessment and evaluation of risks, management of risks: monitoring of risks and review and evaluate risk management process We shall look at how to close a project once it has been completed in the next screen Closing a Project A project should have a finite life so, at some point, it is closed and the new or modified system is handed over to the users and or or the system support staff. The project sponsor should be satisfied that the system produced is acceptable and ready for delivery. Custody of contracts may need to be assigned, and documentation archived or passed on to those who will need it. Survey the project team, development team, users and other stakeholders to identify any lessons learned that can be applied to future projects. The following screen discusses the post project review in project closure. Closing a Project – Post Project Review In Post project review the lessons learned and an assessment of project management processes used are documented and referenced, in the future, by other project managers or users working on projects of similar size and scope. It is important to note that project management practice descriptions and related concepts and theories behind best practices have been brought together in what are called "body of knowledge" reference libraries (BoKs). Certification schemes have subsequently been based upon such BoKs. Let us look at process improvement practices in the next screen ? Process Improvement Practices Business processes require improvements, which are accomplished with practices and techniques. Benchmarking is a continuous, systematic process of evaluating products or services or processes against best practices. It aims at improving business processes. Structured Analysis, Design and Development Techniques provide a framework for representing the data and process components of an application using various graphic notations at different levels of abstraction, until the abstraction level that enables programmers to code the system is reached. We shall briefly discuss business process reengineering in the next screen. Business Process Reengineering Business Process Reengineering (BPR) as defined by Seth and King, is a set of interrelated work activities characterized by specific inputs and value-added tasks that produce specific customer focused outputs. Business processes consist of horizontal work flows that cut across several departments or functions." BPR is a response to competitive and economic pressures, and customer demands. It involves automating processes to reduce manual intervention and manual controls. It needs to suit business requirements for benefits to be realised. Let us continue with BPR in the following screen. Business Process Reengineering BPR has been noted for its success in cost savings; streamlining of operations; and advantages of centralization and results in changes in business conduct. The steps in a BPR program are: define the areas to be reviewed, develop a Program plan, understand the process under review, re-design and streamline the process, implement and monitor the new process and establish a continuous improvement process. Let us look at ISO 9126 in the next screen. ISO 9126 ISO 9126 (Pronunciation hint I-S_O nine thousand, one hundred and twenty six) is an international standard to assess the quality of software products. It provides the definition of the characteristics and associated quality evaluation process to be used when specifying the requirements for, and evaluating the quality of, software products throughout their life cycle. Let us look at the attributes evaluated under ISO 9126 in the following screen. ISO 9126 (contd.) The attributes evaluated include; functionality on the existence of a set of functions and their specified properties, reliability on the capability of software to maintain its level of performance under stated conditions for a stated period of time, usability on the effort needed for use and on the individual assessment of such use by a stated or implied set of users. Other attributes reviewed are efficiency on the relationship between the level of performance of the software and the amount of resources used under stated conditions, maintainability on the effort needed to make specified modifications and portability on the ability of software to be transferred from one environment to another . Let us look at Software Capability maturity model in the next screen. Software Capability Maturity Model The Capability Maturity Model (CMM) for Software is a process maturity model or framework that helps organizations improve their software life cycle processes. CMM helps organisations: improve their software life-cycle processes; and prevent excessive Program schedule delays and cost overruns. It guides software organisations in selecting process improvement strategies by determining current process maturity, and identifying most critical issues to quality and improvement. It defines five maturity levels: Initial; Repeatable, Defined, Managed, and Optimizing. Let us look at capability maturity model integration in the following screen. Capability Maturity Model Integration Capability Maturity Model Integration (CMMI) was conceived as a means of combining the various models into an integrated set. CMMI also describes five levels of maturity, although the descriptions of what constitutes each level differ from those used in the original CMM. ISO 15504 is also known as SPICE (Software process improvement and capability determination)- It is based on CMM and is similar to CMMI . You will now attempt a question to test your knowledge of what we have covered so far.

3.8 Knowledge Statement 3.4

In this topic, we will learn about the concepts under knowledge statement 3.4. We will begin with risk management practices in the following screen. Risk Management Practices The CISA candidate should have an understanding of risk management practices applied to projects. Proper risk management is required in order to minimize the consequences and the likelihood that the project fails to achieve its goals. Major issues include: scope/deliverables, quality, budget and time. Risk management is a continuous process, not a one-time activity, since risk profiles will change over time. The main area covered here is risks associated with software development. It is important to note that as a “controls expert”, the IS Auditor will be expected to ensure that business risk is considered by the project during all phases of development. We shall look at risks associated with software development in the next screen. Risks Associated with Software Development In Software Development Risks, business risk or benefit risk is the likelihood that the new system may not meet the users' business needs, requirements and expectations. Project risk or delivery risk is where the project activities to design and develop the system exceed the limits of the financial resources set aside for the project and, as a result, it may be completed late, if ever. In the following screen, we will understand the levels at which software project risk exists. Levels of Software Project Risk Software project risks exist at multiple levels: Within the project – e.g, risks associated with not identifying the right requirements to deal with the business problem or opportunity that the system is meant to address, With suppliers - For example, failure to clearly communicate requirements and expectations, resulting in suppliers delivering late, at over expected cost and/or with deficient quality or within the organization - e.g, stakeholders not providing needed inputs or committing resources to the project. Risks can also exist with the external environment – e.g, impacts on the projects caused by the actions and changing preferences of customers or with the technology chosen - technology risk. For example, sudden displacement of technology by one more cost efficient. You will now attempt a question to test your knowledge of what we have covered so far.

3.10 Knowledge Statement 3.5

In this topic, we will learn about the concepts under knowledge statement 3.5. We will begin with IT Architecture related to data, applications and technology in the following screen. IT Architecture Related to Data, Applications and Technology The key knowledge area that a CISA should grasp is that of IT architecture related to data, applications and technology (For example, distributed applications, web-based applications, web services, n-tier applications) . Enterprise Architectures describe an organization’s structure, including business processes, information systems, human resources and organizational units. Enterprise Architectures are supported or served by IT Architectures e.g., n-tier, client-server, web-based and distributed components. The main area of coverage is Components of enterprise architecture The IS Auditor must understand the role of these components and how control objectives are met across all components to determine whether risk is sufficiently mitigated by these controls. Let us learn about business application systems in the next screen. Business Application Systems There are many different application systems that an auditor will encounter in the course of their job. Such applications ranges from e-commerce applications, point of sales, business intelligence systems and so on. Some of these are displayed on the screen. We shall look at electronic commerce in the next screen. Electronic Commerce (Ecommerce) Electronic Commerce or e-commerce refers to buying and selling online, usually via the internet, using technology to enhance the processes of commercial transactions. There are various E-commerce models such as business-to-customer (B-to-C); business-to-business (B-to-B); business-to-employee (B-to-E); business-to-government (B-to-G);customer-to-government (C-to-G); and exchange-to-exchange (X-to-X). Let us look at e-commerce architecture in the next screen. Electronic Commerce Architecture E-commerce can be implemented in a 2-tier architecture where you have the client browser and web-server; or a 3-tier architecture where you , client browser, web-server, and database server; and Integrate web channel with a business’ internal legacy systems and systems of its business partners. The e-commerce component-based systems that use middleware around an application server,to meet the challenge of diverse technologies). systems relying on multiple computer platforms- “n-tiered” e.g. client browser, web server (handle web content), Application server (business logic) and database (data storage). Let us continue to understand e-commerce architecture in the following screen. Electronic Commerce Architecture (contd.) Application server : provide services such as data management, security & transaction management) XML (extensible mark-up language): facilitates electronic publishing and allows storing of any kind of structured information. Let us look at e-commerce risks in the following few screens. Electronic Commerce Risks The risks involved in e-commerce transactions can be classified into five categories. The first is Confidentiality where unknown vendors are provided with personal information (e.g. credit card on purchase) which can be stolen. Data integrity is the second risk where data in transit and in storage exposed to unauthorized alteration or deletion.(hacking ebusiness system). Thirdly availability; an e-commerce requirement requires an up time of 24/with any outage being highly noticeable and eventually leading to loss of business. There is also the risk of authentication and nonrepudiation; requires a trusted business relationship - to avoid man-in-the-middle attacks , which may be difficult to implement in an e-commerce site. The last risk is that power shift to customers; Ease of shift between suppliers, requires reengineering of business processes. The following screen lists the requirements of e-commerce. Electronic Commerce Risks (contd.) Ecommerce Requirement include, a business case (IT as an enabler) around the 4 Cs: customers, costs, competitors and capabilities, a clear business purpose, improved costs through technology and top-level commitment. Other requirements include business process re-configuration and Links to legacy systems, typically through middleware Electronic Commerce Risks (contd.) One of the major risk is transaction authorization where matters of legal liability between partners may be put in a trading partner agreement. Other risks include; loss of business continuity, Unauthorized access to electronic transactions; matters of legal liability between partners may be put in a trading partner agreement, deletion or manipulation of transactions prior to or after establishment of application controls; loss or duplication of EDI transmissions; and improper distribution of EDI transactions while in the possession of third parties. Electronic Commerce Risks (contd.) Key controls are; virus protection. continuity planning, continuous review / audit of controls, digital Signatures, firewalls mechanisms, public key infrastructure: Certificate Authority (CA), Registration Authority (RA), Certificate Revocation List (CRL), Certification Practice Statement (CPS) and recognition of breaches –Intrusion Detection System (IDS) Electronic Commerce Risks (contd.) Key controls that can be used to address e-commerce risks also include: Security mechanisms and procedures that provide security architecture for ecommerce (e.g. firewall, PKI, encryption, certificates and password management), firewalls mechanisms, process of identification of participants in ecommerce applications, Other processes are those for change management in ecommerce presence, detection controls: system logs and intrusion detection systems, Let us learn about electronic data interchange in the next screen. Electronic Data Interchange (EDI) Electronic Data Interchange (EDI) is an electronic means for transmitting business documents between organisations in a standard machine - recognizableor processable format. It is used to transmit business transactions between organisations with dissimilar computer systems. It is the use of computers and telecommunications to exchange data between computer applications in a structured format that does not require manual intervention. The benefits of EDI are less paperwork; fewer errors during information exchange; improved information flow; no unnecessary re-key of data; and fewer delays in communication as well as improved invoicing and payment processes. We shall continue learning about electronic data interchange in the next screen. Electronic Data Interchange (EDI) (contd.) This diagram illustrates how a buy would go about purchasing items from the seller in cases where there is EDI. Let us look at EDI requirements in the next screen. EDI Requirements and Approaches The general requirement of an EDI are a system software: communication / transmission, translation, and storage; application software that performs business activities; and access to standards: document standards and partner profiles. Electronic data interchange can be implemented traditionally or via the web. Let us look at the EDI process in the following screen. EDI Process Moving data in a batch transmission process through the traditional EDI involves three functions within each trading partner’s computer system: The communications handler is used in transmitting and receiving electronic documents between trading partners; the EDI interface is used manipulating and routing data between the application system and the communications handle: the EDI translator is used to translates data between the standard ANSI format and a trader’s proprietary format. Other components are application interface which moves electronic transactions to and from application systems, and performs data mapping; or appplication system – processing the data to be sent to or received from the trading partner. You will now attempt a question to test your knowledge of what we have covered so far.

3.12 Knowledge Statement 3.6

In this topic, we will learn about the concepts under knowledge statement 3.6. We will begin with IT Acquisition practices in the following screen. IT Acquisition Practices The CISA candidate should have a grasp of the knowledge of IT acquisition practices (e.g., evaluation of vendors, vendor management, escrow) . The use of vendors can speed a project and potentially reduce total costs. However, use of vendors add risks, especially if the vendor is single or sole-source provider . Proper vendor management can reduce/ prevent problems caused by picking a vendor that is unable to achieve the required solution or timescale and by ensuring that contracts address business needs and do not expose the business to unnecessary risk. The following screen lists the main areas of coverage under this knowledge statement. Main Areas of Coverage The main area of coverage is infrastructure Development/ Acquisition Practices, hardware acquisition and system Software Acquisition It is important to note that the IS Auditor must understand: the importance of requirements specification that forms the request for proposal (RFP); the need for required security and other controls to be specified, the essential elements of vendor selection to ensure that a reliable and professional vendor is chosen and the essential contents of the contract – most notably, the need, as appropriate, for an escrow agreement to be in place. The right to audit must also be addressed in the contract. Let us look at hardware acquisition in the next screen. Hardware Acquisition The selection of a computer hardware and software environment frequently requires the preparation of specifications for distribution to hardware/software (HW/SW) vendors and criteria for evaluating vendor proposals. The specifications are sometimes presented to vendors in the form of an invitation to tender (ITT), also known as a request for proposal (RFP). Let us discuss specifications to consider while acquiring hardware in the following screen. Hardware Acquisition (contd.) When acquiring a system, the specifications should include the following: organizational descriptions indicating whether the computer facilities are centralized or decentralized, distributed, outsourced, manned or lights-out. Other considerations are information processing requirements , hardware requirements, system software applications, support requirements, adaptability requirements , constraints and conversion requirements. Let us look at the considerations for hardware or software acquisitions in the following screens. Hardware Acquisition (contd.) When purchasing or acquiring hardware and software from a vendor, consideration should be given to the following: testimonials or visits with other users, provisions for competitive bidding,analysis of bids against requirements and comparison of bids against each other using predefined evaluation criteria. Other factors to be considered are: analysis of the vendor's financial condition, analysis of the vendor's capability to provide maintenance and support (including training), review of delivery schedules against requirements, Hardware Acquisition (contd.) Considerations for hardware acquisitions also extend to analysis of hardware and software upgrade capability, analysis of security and control facilities, evaluation of performance against requirements, review and negotiation of price, review of contract terms (including right to audit clauses) and preparation of a formal written report summarizing the analysis for each of the alternatives and justifying the selection based on benefits and cost Let us look at software acquisition in the next screen. System Software Acquisition When selecting new system software, a number of business and technical issues must be considered including: business, functional and technical needs and specifications, cost and benefits, compatibility with existing systems, security and demands of existing staff. Other factor s to be taken into consideration are training and hiring requirements, future growth needs, impact on system and network performance and open source code vs. proprietary code We shall look at the infrastructure development or acquisition practices in the next few screens. Infrastructure Development/Acquisition Practices The challenges to information and communication technology (ICT) Infrastructure development and acquisition include: alignment with corporate standards, security, integration with existing systems, IT industry trends, scalability and flexibility. Other factors include maintainability (cost effective), standardised hardware and software and Return on investment, cost and operational efficiency. Infrastructure Development/Acquisition Practices (contd.) The phases in ICT Infrastructure Development and Acquisition are review of existing architecture, analysis and design, functional requirements, proof of concept, procurement, implementation planning, delivery and installation In the following slide we will look at the contents of a typical Request for Proposal. Request for Proposal Process The request for proposal requires that the chosen vendor product should come as close as possible to meeting the defined requirements of the system and that the project management should check vendor-supplied references to validate the vendor’s claims of product performance and completion of work done by the vendor. Other matters that should be reviewed selecting a vendor in the request for proposal process involves reviewing the financial viability of the vendor, and availability of complete and reliable documentation. Let us continue to understand the RFP process in the following slide. Request for Proposal Process (contd.) The RFP process should also check the availability of vendor support, source code availability, number of years of experience of the vendor, number of clients using the same product and acceptance testing of the product. You will now attempt a question to test what you have learnt so far.

3.14 Knowledge Statement 3.7

In this topic, we will learn about the concepts under knowledge statement 3.7. Let us look at requirement analysis and management practices in the next screen Requirements Analysis and Management Practices The CISA candidate should have knowledge of requirements analysis and management practices (e.g., requirements verification, traceability, gap analysis, vulnerability management, security requirements). Tracking and monitoring requirements ensure that project resources are focused on the correct tasks. Requirements gathering is one of the most critical and difficult activities of the development life cycle. Requirements should be prudent; feasible; cost-effective; and above all, aligned with business strategy, plans and policies Requirements should be documented to facilitate the understanding of the developers and formally approved and frozen (baselined) to prevent scope creep. The main area of coverage is the requirements Analysis in SDLC Let us look at requirement analysis in the SDLC process in the following screens. Requirements Analysis in SDLC Requirements Analysis involves identifying and specifying requirements of the system chosen. Decisions are made on: system processes; user requirements and interaction; information criteria (effectiveness, efficiency, confidentiality, integrity, availability,compliance, reliability); and system operating environment (that is, operating system). Requirements Analysis in SDLC (contd.) It also involves: determining stakeholders’ expectations; conflict resolution and prioritisation of issues; defining system boundaries and interaction with the environment; iteratively translating user requirements into system requirements; structured documentation of requirements; and conflict resolution with regards to resource allocation. Requirements Analysis in SDLC (contd.) User involvement is critical and can be done by nominating representatives from affected user departments. It is necessary to obtain commitment; and ensures full benefit from the system. An important tool for creation of a general preliminary design is an Entity Relationship Diagram (ERD). Let us look at the key outputs of the analysis stage in the following screen. Key Outputs of Requirements Analysis A key output at the analysis stage is a preliminary system design that: is presented to user management for approval and endorsement; and prevents using resources on developing a system that does not meet requirements. The program schedule, which helps secure: commitments from systems developers; and necessary resources from affected departments. IS auditors when reviewing the SDLC process look out for, user involvement; and consideration of security requirements, audit trails. Let us look at the ERD diagram in the next screen. Entity Relationship Diagram (ERD) The Entity Relationship Diagram (ERD) depict system data and how these data interrelate. The ERD is used as an analysis tool to obtain an understanding of the data a system needs to capture and manage; represents a logical data model; can be used as a design tool to document the actual database schema; in which case it will represent the physical data model. Let us look at the characteristics of an ERD in the following screen. ERD Characteristics The characteristics of ERD are that is composed of entities (rectangular boxes) and relationships (diamond shapes) where entities have attributes (theses are, properties or characteristic. For example is a university setting an entity holding student records may have attributes like StudentID, Name and Age, among others. The primary key uniquely identifies each instance of the entity while the foreign key is one or more attribute held in an entity that map to the primary key of the related entity. The image on the screen illustrates an ERD. You will now attempt a question to test what you have learnt so far.

3.16 Knowledge Statement 3.8

In this topic, we will learn about the concepts under knowledge statement 3.8. Let us discuss project success criteria and risks in the following screen. Project Success Criteria and Risks The CISA student should have knowledge of project success criteria and risks. Each project has unique success criteria based on the expectations of its stakeholders. The project sponsor is a key stakeholder who defines such success criteria. One technique to describe success criteria and deliverables is called the object breakdown structure. Success criteria allow the project manager to focus on those risks that are most important for the successful completion of the project. The main areas of coverage are the v-model and object Breakdown Structure Let us understand the V-model in the following screen. V-model The verification and validation model or V-model, also emphasizes the relationship between development phases and testing levels. A risk in any software development project is that the final outcome may not meet all requirements. The V-model approach ensures that potential mistakes are corrected early and not solely during final acceptance testing. Let us learn about the object breakdown structure in the next screen. Object Breakdown Structure (OBS) Object Breakdown Structure (OBS) represents the components of the project in graphical or tabular form . It can help management and project team members better visualize the scope and objectives of the project. An illustration of the OBS is displayed on the screen. Let us continue to understand the OBS in the following screen. Object Breakdown Structure (contd.) An OBS can help, especially when dealing with nontangible project results such as organizational development, to ensure that a material deliverable is not overlooked. After the OBS has been compiled or a solution is defined, a work breakdown structure (WBS) is designed to structure all the tasks that are necessary to build up the elements of the OBS during the project. The WBS represents the project in terms of manageable and controllable units of work, serves as a central communications tool in the project, and forms the baseline for cost and resource planning. In contrast to the OBS, the WBS does not include basic elements of the solution to build, but shows individual work packages (WPs) instead.

3.17 Knowledge Statement 3.9

In this topic, we will learn about the concepts under knowledge statement 3.9. Let us look at control objectives and techniques in the next screen. Control Objectives and Techniques The CISA candidate should have knowledge of control objectives and techniques that ensure completeness, accuracy, validity and authorization of transactions and data. Poor controls over data input, processing, storage or output increase the risk of loss to an enterprise. The main areas of coverage are input/Origination Controls, processing Procedures and Controls and output Controls The IS Auditor must be aware of the need for controls to ensure the authorization, accuracy and completeness of data input to, processing by and output from computer applications and know what types of control techniques are available at each level and how each may be evidenced in the form of reports, logs and audit trails. We sh

Find our CISA®- Certified Information Systems Auditor Online Classroom training classes in top cities:

Name Date Place
CISA®- Certified Information Systems Auditor 8 May -30 May 2021, Weekend batch Your City View Details
CISA®- Certified Information Systems Auditor 11 Jun -3 Jul 2021, Weekdays batch Seattle View Details
  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*