3. Information Systems Acquisition, Development, and Implementation
• Project cost estimation methods
• Analogous estimate:
• The cost of a new project is estimated on the basis of experience of prior projects.
• This is the quickest estimation method.
• Parametric estimate:
• Past data is used to leverage statistical data (such as estimated hours and technological requirements) to estimate
cost.
• It is considered more accurate than analogous estimates.
• Bottom-up estimate:
• Detailed cost estimates of each activity are drawn up and the sum of all activities are considered to produce a cost
estimate for the project.
• This is the most accurate estimate, but it is a time-consuming activity.
• Actual costs:
• This is the same as analogous estimation, where the actual cost of past projects is extrapolated to estimate costs.
4. Information Systems Acquisition, Development, and Implementation
• Software size estimation methods
• Source Lines of Code (SLOC):
• SLOC is a traditional way of estimating software size on the basis of a single parameter, such as the number of lines of
code. However, this may not be effective in the case of complex systems with functionality other than code.
• Such functionality could include diagrams, objects, database queries, or graphical user interfaces.
• Function Point Analysis (FPA):
• FPA is an indirect technique to estimate the size of software.
• Function points are a unit of measurement for software size, just like time is measured in hours or distance in miles.
• To arrive at a function point, different factors are considered, such as the complexity of the design, input, processing,
outputs, and modules and their interactions.
• FPA is more consistent and appropriate than SLOC.
• COCOMO:
• COCOMO stands for Constructive Cost Model. It can be considered as an advanced version of SLOC.
• In COCOMO, apart from the number of lines of code, the complexity of the system is also considered in drawing up the
estimation.
5. Information Systems Acquisition, Development, and Implementation
• Project evaluation methods
• Critical path methodology
• The Critical Path Method (CPM) is used to estimate the duration of the project. Any project will have a minimum of one
critical path.
• A critical path is determined by identifying the longest path of dependent activities.
• The time required to finish the critical path is the shortest possible time required for finishing the project.
• No slack time will be available for the activities on the critical path.
• Slack time is the time that acts as a buffer or extra time, and an activity can be delayed up to the limit of the slack time
without impacting the overall project completion date.
• Project managers concentrate on activities with zero slack time (that is, those on the critical path), and if the critical
path duration can be reduced then it will help to minimize the overall project duration.
• Program Evaluation Review Technique (PERT)
• Like CPM, PERT is also a technique used to estimate estimate project duration.
• The difference between PERT and CPM is that while CPM considers only a single scenario, PERT considers three
different scenarios (optimistic (best), pessimistic (worst), and normal (most likely)) and on the basis of those three
scenarios, a single critical path is arrived at.
• PERT is considered more accurate and appropriate than CPM for calculating estimates of project duration.
6. Information Systems Acquisition, Development, and Implementation
• Project evaluation methods
• Earned Value Analysis
• The objective of Earned Value Analysis (EVA) is to measure the progress of the project at any given point in time, to
forecast the completion date and the final cost, and to analyze any variance in the budget.
• EVA determines and evaluates the following factors on a periodic basis:
• What is the actual spending up to the present date, compared to the budget?
• What is the estimated completion time?
• What is the estimated total expenditure?
• EVA helps to forecast the schedule date and expected cost and to determine the variance of cost and schedule at any
given point during the project.
• In EVA, it is assumed that a project can reasonably be completed within the original schedule
• For example, a development team has spent eight hours of activity on the first day against a budget of 24 hours (over
three days). The projected time to complete the remainder of the activity is 20 hours, so according to EVA, project is 4
hrs behind its schedule.
• Timebox management
• The benefit of timebox management is that it ensures the timely completion of the project and thus prevents project
cost overruns.
• Timebox management is heavily applied in prototyping and rapid application development (RAD) where time
management is very critical.
• It helps to save time by integrating system and user acceptance testing. However, a quality assurance process will still
need to be carried out.
7. Information Systems Acquisition, Development, and Implementation
• Project objectives, OBS, and WBS
• Object Breakdown Structure (OBS) is one of the commonly accepted approaches for defining the project objectives.
• OBS is a combination of separate components and their interaction with each other.
• The next step is to design a Work Breakdown Structure (WBS).
• WBS provides individual components of work to be done. It helps with cost and resource planning.
• OBS includes solutions, whereas WBS includes individual processes.
• Role of the IS auditor in project management
• To determine system objectives and requirements and to identify areas of control
• To determine major risks associated with the project and the relevant controls to be implemented to mitigate these
• To determine the appropriateness of the approach/methodology adopted for the SDLC To determine whether quality
assurance and UATs are conducted before deployment of the system
• To determine the controls to be implemented to ensure the integrity of the production resources
• To determine the adequacy of the post-implementation review process
8. Information Systems Acquisition, Development, and Implementation
• Business cases and feasibility analysis
• It is very important to consider the business case and feasibility analysis before undertaking any new project.
• Business cases
• A business case is a justification for a proposed project.
• The business case is prepared to justify the effort and investment in a proposed project.
• It captures the reasoning for initiating a project or task.
• Generally, the business case is the precursor to the start of the project.
• The business case is a key element in decision-making for any project.
• Development of the business case is the responsibility of the project sponsor.
• The proposed ROIs, along with any other expected benefits, are the most important consideration for decision-making
in any new project.
• Feasibility analysis
• A feasibility study is an analysis that takes various factors into account, including economic, technical, and legal factors,
to ascertain the likelihood of completing the project successfully.
• The feasibility study should consider how the project will impact the organization in terms of risk, costs, and benefits.
• It helps to assess whether a solution is practical and achievable within the established budgets and schedule
requirements.
• IS auditor's role in business case development
• Reviewing the approval process for initiation of the project
• Reviewing the process followed for the development of the business case and feasibility study
• Reviewing the process followed for the evaluation of various alternatives
• Reviewing the appropriateness of the cost justification/benefits projected
• Determining whether the business case and feasibility analysis are aligned with the business objectives
9. Information Systems Acquisition, Development, and Implementation
• Business cases and feasibility analysis
• It is very important to consider the business case and feasibility analysis before undertaking any new project.
• Business cases
• A business case is a justification for a proposed project.
• The business case is prepared to justify the effort and investment in a proposed project.
• It captures the reasoning for initiating a project or task.
• Generally, the business case is the precursor to the start of the project.
• The business case is a key element in decision-making for any project.
• Development of the business case is the responsibility of the project sponsor.
• The proposed ROIs, along with any other expected benefits, are the most important consideration for decision-making
in any new project.
• Feasibility analysis
• A feasibility study is an analysis that takes various factors into account, including economic, technical, and legal factors,
to ascertain the likelihood of completing the project successfully.
• The feasibility study should consider how the project will impact the organization in terms of risk, costs, and benefits.
• It helps to assess whether a solution is practical and achievable within the established budgets and schedule
requirements.
• IS auditor's role in business case development
• Reviewing the approval process for initiation of the project
• Reviewing the process followed for the development of the business case and feasibility study
• Reviewing the process followed for the evaluation of various alternatives
• Reviewing the appropriateness of the cost justification/benefits projected
• Determining whether the business case and feasibility analysis are aligned with the business objectives
10. Information Systems Acquisition, Development, and Implementation
• System development methodologies:
• A system development methodology is a structure that organizations use for the design, development, and implementation of
new systems.
• SDLC models
• Traditional waterfall
• This approach is useful when prototypes are required to understand the design and requirements of the proposed
system.
• It works well when requirements are well defined and do not undergo frequent changes.
• Agile development
• Agile means "the ability to move quickly and easily".
• In the Agile method, programmers do not spend much time on documentation. They can write a program straight away.
• The objective of the Agile approach is to produces releasable software in short iterations without giving much
importance to formal paper-based deliverables.
• SDLC Phases
• Phase 1 – Initiation/ Feasibility :Objective, purpose and scope of the system is discussed, finalized and documented.
• Phase 2 – Development / Acquisition: In this phase, alternatives are evaluated and the system is developed or acquired
from a third party.
• Phase 3 – Implementation In this phase, the system is tested and migration activities are carried out.
• Phase 4 – Operations / Maintenance: In this phase, regular updates and maintenance is carried out for upkeep of the
system.
• Phase 5 - Disposal In this phase: obsolete systems are discarded by moving, archiving, discarding or destroying
information and sanitizing the hardware and software.
• Prototyping
• In the prototyping approach, the system is developed through trial-and-error methods.
• A prototype is basically a preliminary version of a system to test a concept or process or assumptions about
functionality, design, or internal logic.
11. Information Systems Acquisition, Development, and Implementation
• System development methodologies:
• Rapid Application Development
• A well-trained team of developers
• Prototypes
• Sophisticated tools and software for modeling, prototyping, and component reusability
• A central repository
• Object-Oriented System Development (OOSD)
• programming technique with an objective to make program code that is reusable and maintainable.
• An object is basically a small piece of code in a program.
• The system is developed via the use and combination of different objects.
• OOSD uses a technique known as encapsulation, in which objects interact with each other.
• Encapsulation provides enhanced security for data.
• The ability of two or more objects to interpret a message is termed as polymorphism.
• Component-based development
• In component-based development, ready-made components (objects) are assembled together to design and develop a
specific application.
• As developers are not required to write programming code, they can concentrate on business functionality.
• Component-based development supports multiple development environments.
• Components can interact with each other irrespective of their programming language.
• As components are already available, it saves considerable time and cost in the development
• Software reengineering is the process of updating a system to enhance the system functionality to make the system better
and more efficient.
• Reverse engineering is the process of the detailed analysis and study of a system with the objective to develop a similar
system
12. Information Systems Acquisition, Development, and Implementation
• Control identification and design
• Check digits
• A check digit is an extra digit used for error detection.
• A check digit is arrived at by a mathematical algorithm. It is added to the original data to ensure that data is not
altered.
• It helps to ensure that the original data is not tampered or altered.
• Check digits help to prevent transposition and transcription errors.
• The example for use of a check digit is the bank account numbers assigned to customers.
• Parity bits
• Parity bits are used to verify complete and accurate data transmission.
• Parity bits are used as the simplest form of error-detecting code when data is transferred from one computer to
another:
• Checksums
• Checksums work on the same principle as parity bits but they have the capability to recognize complex errors
through advanced mathematical formulas.
• Cyclic Redundancy Checksums (CRC)/
• Redundancy Checksums are a more advanced version of checksums that work by increasing the complexity of
the arithmetic.
• Forward error control
• Forward error control works on the same principle as redundancy checksum.
• In addition to detecting the error, they have capability to correct the error. It helps the receiving computer to
correct the error.
13. Information Systems Acquisition, Development, and Implementation
• Data integrity principles
• Atomicity:
• The principle of atomicity prescribes that a transaction is either processed completely or should not be processed at all.
• In the case of an error or interruption, partial processing, if any, should be rolled back.
• Consistency:
• The principle of consistency prescribes that all integrity conditions must be applied to each transaction of the database.
• Isolation:
• The principle of isolation prescribes that each transaction should be separated from other transactions.
• Durability:
• The principle of durability prescribes that the database should be resilient enough to survive any system failures.
• Limit checks
• Limit checks restrict the data input up to a certain predefined limit.
• Data is checked for one limit, either upper or lower, as in, data should not be greater than 100.
• Limit checks are input control. These are a form of preventive control to restrict invalid input into the system. It ensures that
only data within predefined limit can enter the system.
• Automated systems balancing
• Automated systems balancing reconciles the total input with the total output.
• Any difference will be shown as an error for further investigation and correction.
• Automated system balancing helps to determine whether any transactions are lost during processing as any mismatch in
input and output will be highlighted for further investigation.
• Sequence checks
• Sequence checks involve testing a list of items or files of records for correct ascending or descending sequences based on
predefined requirements.
• For example, it checks whether vouchers are in sequence and thus prevents the duplication of the vouchers.
14. Information Systems Acquisition,
Development, and Implementation
• Information Systems Implementation
• Testing Methodologies:
• Unit testing:
• Unit tests include tests of each separate
program or module.
• Testing is generally conducted by developers
themselves.
• It is conducted as and when a program or
module is ready and it does not need to wait
until the completion of the entire system.
• Unit testing is done via a white box approach
wherein internal program logic is tested.
• Integrated testing
• An integrated test examines the integration or
connection between two or more system
components.
• The purpose of the integration test is to validate
accurate and correct information flow between
the systems.
15. Information Systems Acquisition, Development, and Implementation
• System testing
• System testing tests the entire system's capabilities.
• It covers end-to-end system specifications. It covers functionality tests, recoverability recoverability tests, security tests, load tests,
volume tests, stress tests, and performance tests.
• Final acceptance testing
• Final acceptance testing consists of two tests, a Quality Assurance Test (QAT) and a User Acceptance Test (UAT).
• Regression testing
• The meaning of regression is to return to an earlier stage.
• The objective of a regression test is to confirm that a recent change has not introduced any new faults and other existing features
are working correctly.
• It must be ensured that the same data (which was used in earlier tests) is used for the regression test.
• This will help to confirm that there are no new errors or malfunctions.
• sociability testing
• The objective of the sociability test is to ensure that the new system works as expected in the existing infrastructure without any
adverse impact on other existing systems.
• The application works as expected in the specified environment where other applications run concurrently.
• Pilot testing
• A pilot test is a small-scale preliminary study to understand and evaluate system functionality and other aspects.
• A pilot test is conducted for only a few units or a few locations to evaluate the feasibility.
• The objective of the pilot test is to determine the feasibility of the new system before full-fledged implementation.
• Parallel testing
• Parallel testing involves the testing of a new system and comparing the results of a new system with that of an old system.
• The objective of parallel testing is to ensure that the new system meets the requirements of the user.
• White box testing
• In white box testing, program logic is verified.
• To conduct a white box test, appropriate knowledge of the relevant programming language is a must.
16. Information Systems Acquisition, Development, and Implementation
• Black box testing
• In black box testing, the emphasis is on the
functionality of the system:
• To conduct a black box test, knowledge of the
relevant programming language is not
mandatory.
• Black box testing is generally a feature of
user acceptance tests and interface tests.
• Alpha testing – conducted by internal user
• Beta testing – conducted by external user. To be
done after alpha testing.
17. Information Systems Acquisition, Development, and Implementation
• System Migration:
• Parallel changeover
• In this method, the new and old systems are operated in parallel for some time.
• Once the users are confident about the new system, the old system may be discontinued.
• Phased cchangeover
• In this method, changes are implemented in a phased manner. The system is broken into different phases. Each old phase is
gradually replaced by a new phase.
• Abrupt changeover
• In this method, a new system is implemented from a cut-off date and the old system is completely discontinued once the new
system is implemented.
• This process is also known as direct cutover.
• This is considered the riskiest approach with no scope for rollback if the new system fails.
18. Information Systems Acquisition, Development, and Implementation
• A post-implementation review is the process of determining and evaluating the performance of the system against the
requirement and objective defined in the business case.
• The post-implementation review is conducted once the project is implemented and completed.
• Objectives:
• To determine the extent to which a project met its objectives and addressed the originally defined requirements
• To determine the cost-benefit analysis and return on investment
• To determine the lessons learned from the project to improve future projects
• The project development team and business users should jointly conduct a post-implementation review.
• From the IS audit perspective, the post-implementation review is conducted to determine the adequacy and effectiveness of
the system.
• The IS auditors' prime focus is to determine the controls built into the new system.
