CISA Domain 3 – Information Systems Acquisition, Development and Implementation- PART 3

PART 3 – CISA Domain 3 – Information Systems Acquisition, development and implementation

What are the roles and responsibilities of each individual in IS environment?
What are project management practices?
What are the methods of software size estimation? (1) SLOC and, (2) FPA
How to measure project time frame? (1) Gantt Charts, (2) CPM and (3) PERT
What is traditional SDLC approach?
What are the various approaches of test plans? (1) Bottom-up, and (2) Top-down

1. Roles and Responsibilities:

Senior Management – Demonstrates commitments to the project and approve the resources
User management – Assumes ownership of the project and resulting systems, allocates qualified resources, and actively participates in business process redesign, system requirement definitions, test case development, acceptance testing and user training
Project steering committee – It provides overall directions and also responsible for all deliverables, project cost, and schedules
Project sponsor – Providing funding for the project.
Systems development management – Provides technical supports for hardware and software environment by developing, installing User project team – Completes assigned task, communicates effectively with user by actively involving them in the development process as a subject matter expert.
Security officer – Ensures that systems controls and supporting processes provide an effective level of protection based on data classifications
Quality assurance – person who review results and deliverables within each phase and at the end of each phase and confirm compliance requirement and operating the requested systems.
Project manager – Day to day management and leadership of the project
Systems development project team – Completes assigned task, communicates effectively with user by actively involving them in the development process.

*Points to remember:* The CISA candidate should be familiar with general roles and responsibilities of groups or individuals involved in the systems development process.

2. Project Management practices:

Project management 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, budget and deadlines for an IS project
Project management knowledge and practices are best described in terms of their component processes of
- Initiating,
- Planning,
- Executing and controlling and
- Closing a project
Initiation of the project
- Initiated by project manager or sponsor
- often be compiled into terms of reference or a project charter that states the objective of the project, the stakeholders in the system to be produced, and the project manager and sponsor
- Approval of a project initiation document (PID) or a project request document (PRD) is the authorization for a project to begin
Project planning
- The project manager should determine the following as part of project planning
  - Project scope
  - The various tasks that need to be performed to produce the expected business application system
  - The sequence or the order in which these tasks need to be performed
  - The duration or the time window for each task
  - The priority of each task
  - The IT resources that are available and required to perform these tasks
  - Budget or costing for each of these tasks
  - Source and means of funding
- System Development Project Cost Estimation
  - The following are the four methods in determining the cost of system development project:
    - Analogous estimating
    - Parametric estimating
    - Bottom-up estimating
    - Actual costs
- Software size estimation
  - Relates to methods of determining the relative physical size of the application software to be developed
  - Can be used as a guide for the allocation of resources, estimates of time and cost required for its development, and as a comparison of the total effort required by the resources available
  - Methods of software sizing
- Single line of code (SLOC) –
  - The traditional and simplest method in measuring size by counting the number of lines of source code, measured in SLOC, is referred to as kilo lines of code (KLOC)
- Functional Point Analysis (FPA) –
  - Indirect measurement of software size
  - It is based on the number and complexity of inputs, outputs, files, interfaces and queries.
  - A multiple point technique widely used for estimating complexity in developing large business applications.
  - Five functional points – user inputs, user outputs, user inquiries, files and external interfaces.

*Points to remember:* The CISA candidate should be familiar with concepts of SLOC and FPA and should be able to differentiate between the two. CISA question will be based on a scenario where the candidate should be able to justify on the method of software estimation. A reliable technique for estimating the scope and cost of a software-development project – Functional Point Analysis (FPA)

- Scheduling and establishing the time frame
  - While budgeting involves totaling the human and machine effort involved in each task, scheduling involves establishing the sequential relationship among tasks.
  - The schedule can be graphically represented using various techniques such as
    - Gantt charts,
    - Critical Path Methodology (CPM) or
    - Program Evaluation Review Technique (PERT) diagrams.
- Gantt charts:
  - Constructed to aid in scheduling the activities (tasks) needed to complete a project
  - The charts show when an activity should begin and when it should end along a timeline.
  - Gantt charts can also reflect the resources assigned to each task and by what percent allocation.
  - Gantt charts can also be used to track the achievement of milestones or significant accomplishments for the project such as the end of a project phase or completion of a key deliverable.
- Critical Path Methodology (CPM):
  - the critical path is the sequence of activities whose sum of activity time is longer than that for any other path through the network
  - Critical path are important because if everything goes according to the schedule, their duration gives the shortest possible completion time for the overall project
  - Activities that are not in the critical path have slack time
  - Slack time – It is defined as the amount of time a task can be delayed without causing another task to be delayed or impacting the completion date of the overall project.
  - Activities on a critical path have zero slack time, and conversely, activities with zero slack time are on a critical path
- Program Evaluation Review Technique (PERT):
  - CPM-type technique which uses three different estimates of each activity duration in lieu of using a single number for each activity duration.
  - The three estimates are then reduced (applying a mathematical formula) to a single number and then the classic CPM algorithm is applied
    - First one – Most optimistic one (if everything went well
    - Second one – Most likely scenario
    - Third one – Most pessimistic or worst-case scenario

*Points to remember:* A program evaluation review technique that considers different scenarios for planning and control projects – Program Evaluation Review Technique (PERT)

Project executing and controlling:

The controlling activities of the project includes:
- Management of scope changes
- Management of resource usage
- Management of risk
  - The risk management process consists of five steps:
    - Identify risk
    - Access and evaluate risk
    - Manage risk
    - Monitor risk
    - Evaluate the risk management process
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 user
- When closing a project, there may still be some issues that need to be resolved, ownership of which needs to be assigned
- The project sponsor should be satisfied that the system produced is acceptable and ready for delivery

3. Traditional SDLC approach:

Also referred to as the waterfall technique
Traditional system Development Life Cycle Approach
- Phase 1 – Feasibility Study:
  - Includes development of a business case, which determine the strategic benefits of implementing the system either in productivity gains or in future cost avoidance
  - Intangible factors such as readiness of the business users and maturity of the business processes will also be considered and assessed.
  - This business case provides the justification for proceeding to the next phase.
- Phase 2 – Requirements definition – Define the problem or need that requires resolution and define the functional and quality requirements of the solution system
- Phase 3A – Software selection and acquisition (Purchased systems) – Based on requirements defined, prepare a request for proposal outlining the entity requirements to invite bids from suppliers
- Phase 3B – Design (In-house development) – Based on the requirements defined, establish a baseline of system and subsystem specifications that describe the parts of the system, how they interface, and how the system will be implemented using the chosen hardware, software and network facilities.
- Phase 4A – Configuration (purchased systems) – Configure the system, if it is a packaged system, to tailor it to the organization’s requirements. This is best done through the configuration of system control parameters, rather than changing program code.
- Phase 4B – Development (In-house development) – Use the design specifications to begin programming and formalizing supporting operational processes of the System
- Phase 5 – Final testing and implementation – The system also may go through a certification and accreditation process to assess the effectiveness of the business application in mitigating ris
- Phase 6 – Post implementation – Following the successful implementation of a new or extensively modified system, implement a formal process that assesses the adequacy of the system and projected cost benefit or ROI measurements vis-à-vis the feasibility stage findings and deviations

4. Approaches of test plans:

Bottom-up approach:
- a testing strategy in which the modules at the lower level are tested with higher modules until all the modules and aspects of the software are tested properly
- Benefits of bottom-up approach:
  - No need for stubs or drivers
  - Can be started before all programs are complete
  - Errors in critical modules are found early
Top-down approach:
- High-level modules are tested first and then low-level modules and finally integrating the low-level modules to a high level to ensure the system is working as intended.
- Benefits of top-down approach:
  - Tests of major functions and processing are conducted early
  - Interface errors can be detected sooner
  - Confidence is raised in the system because programmers and users actually see a working system

*Points to remember:* The type of approach to the development of organizational policies is often driven by risk assessment – Bottom-up approach The MOST appropriate method to ensure that internal application interface errors are identified as soon as possible – Top-down approach

Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8, Part 9

AUTHOR
Aswini Srinath ()
Writer And Editor

“ I am a qualified Chartered Accountant based out of Chennai, with 8+ years of experience in various roles in finance domain including CA Practice, financial reporting and auditing. I have always been keen to challenge myself by exploring potential capabilities outside of my core competency. Picked up Information Security as one such thing. Cleared CISA with 2nd Rank in ISACA Chennai Chapter in 2019. Since then, i have been sharing my learning and experience to a small group of avid followers, helping them prepare for their CISA exams. This article is also one such attempt, where I summarize the key areas in each domain based on the importance and weightage from an exam point of view. “