Wednesday, August 27, 2008

Software Development Life Cycle Models

I was asked to put together this high-level and traditional software life cycle information as a favor for a friend of a friend, so I thought I might as well share it with everybody.

The General Model

Software life cycle models describe phases of the software cycle and the order in which those phases are executed. There are tons of models, and many companies adopt their own, but all have very similar patterns. The general, basic model is shown below:

Each phase produces deliverables required by the next phase in the life cycle. Requirements are translated into design. Code is produced during implementation that is driven by the design. Testing verifies the deliverable of the implementation phase against requirements.

Requirements

Business requirements are gathered in this phase. This phase is the main focus of the project managers and stake holders. Meetings with managers, stake holders and users are held in order to determine the requirements. Who is going to use the system? How will they use the system? What data should be input into the system? What data should be output by the system? These are general questions that get answered during a requirements gathering phase. This produces a nice big list of functionality that the system should provide, which describes functions the system should perform, business logic that processes data, what data is stored and used by the system, and how the user interface should work. The overall result is the system as a whole and how it performs, not how it is actually going to do it.

Design

The software system design is produced from the results of the requirements phase. Architects have the ball in their court during this phase and this is the phase in which their focus lies. This is where the details on how the system will work is produced. Architecture, including hardware and software, communication, software design (UML is produced here) are all part of the deliverables of a design phase.

Implementation

Code is produced from the deliverables of the design phase during implementation, and this is the longest phase of the software development life cycle. For a developer, this is the main focus of the life cycle because this is where the code is produced. Implementation my overlap with both the design and testing phases. Many tools exists (CASE tools) to actually automate the production of code using information gathered and produced during the design phase.

Testing

During testing, the implementation is tested against the requirements to make sure that the product is actually solving the needs addressed and gathered during the requirements phase. Unit tests and system/acceptance tests are done during this phase. Unit tests act on a specific component of the system, while system tests act on the system as a whole.

So in a nutshell, that is a very basic overview of the general software development life cycle model. Now lets delve into some of the traditional and widely used variations.

Waterfall Model

This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall model.

Advantages

  • Simple and easy to use.
  • Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.
  • Phases are processed and completed one at a time.
  • Works well for smaller projects where requirements are very well understood.

Disadvantages

  • Adjusting scope during the life cycle can kill a project
  • No working software is produced until late during the life cycle.
  • High amounts of risk and uncertainty.
  • Poor model for complex and object-oriented projects.
  • Poor model for long and ongoing projects.
  • Poor model where requirements are at a moderate to high risk of changing.

V-Shaped Model

Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more so than the waterfall model though. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation.

Requirements begin the life cycle model just like the waterfall model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering.

The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together.

The low-level design phase is where the actual software components are designed, and unit tests are created in this phase as well.

The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.

Advantages

  • Simple and easy to use.
  • Each phase has specific deliverables.
  • Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.
  • Works well for small projects where requirements are easily understood.

Disadvantages

  • Very rigid, like the waterfall model.
  • Little flexibility and adjusting scope is difficult and expensive.
  • Software is developed during the implementation phase, so no early prototypes of the software are produced.
  • Model doesn’t provide a clear path for problems found during testing phases.

Incremental Model

The incremental model is an intuitive approach to the waterfall model. Multiple development cycles take place here, making the life cycle a “multi-waterfall” cycle. Cycles are divided up into smaller, more easily managed iterations. Each iteration passes through the requirements, design, implementation and testing phases.

A working version of software is produced during the first iteration, so you have working software early on during the software life cycle. Subsequent iterations build on the initial software produced during the first iteration.

Advantages

  • Generates working software quickly and early during the software life cycle.
  • More flexible – less costly to change scope and requirements.
  • Easier to test and debug during a smaller iteration.
  • Easier to manage risk because risky pieces are identified and handled during its iteration.
  • Each iteration is an easily managed milestone.

Disadvantages

  • Each phase of an iteration is rigid and do not overlap each other.
  • Problems may arise pertaining to system architecture because not all requirements are gathered up front for the entire software life cycle.

Spiral Model

The spiral model is similar to the incremental model, with more emphases placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral.

Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase.

Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.

In the spiral model, the angular component represents progress, and the radius of the spiral represents cost.

Advantages

  • High amount of risk analysis
  • Good for large and mission-critical projects.
  • Software is produced early in the software life cycle.

Disadvantages

  • Can be a costly model to use.
  • Risk analysis requires highly specific expertise.
  • Project’s success is highly dependent on the risk analysis phase.
  • Doesn’t work well for smaller projects.

The Seven Pillars of Coffee Brewing Wisdom


1. Boiling causes bitterness, so never boil coffee.
It should be brewed between 90°C - 96°C.
2. Do not reheat coffee.
Make it fresh each time you serve it, and make only as much as you
plan to drink. Coffee holds its flavor best 86°C.
3. Use freshly drawn, cold water.
Water is 98 % of every cup; consider using a water filter or bottled
water if your water tastes peculiar.
4. Do not reuse grounds.
What remains are the unpleasant bitter component of the coffee.
5. Use the correct grind for your coffeemaker.
Too fine a grind will cause overextraction and bitterness, or clog your
brewer. Too coarse a grind will cause watery coffee.
For drip brewers, the appropriate grind should allow the coffee to
finish dripping in several minutes.
6. For the best results, we recommand using 10 g of ground coffee for
each 180 mL of water.

Keep these proportions consistent, regardless of the quantity you
make. To moderate your's coffee strength, simply add hot water after
brewing.
7. Coffee can be kept warm over a burner for only about 20 minutes
before the flavor becomes unpleasant.

An air pot or vacuum server will keep coffee hot and delicious for
much longer periods of time.


Note : For The Coffee Lover

Tuesday, August 26, 2008

Aristo Munandar Berdiri pada Sisi Rakyat

Di Sisi Rakyat

Aristo Munandar Berdiri pada Sisi Rakyat
Oleh H.St. Zaili Asril,

PU Padek Sebagian pejabat politik/pemerintah di daerah (pimpinan/anggota DPRD, gubernur dan bupati/walikota, dan sekretaris/kepala instansi teknis daerah) ternyata masih memiliki semangat/mindset dan pengambilan posisi serta pola/cara kerja rezim Orde Baru. Menyusun sendiri apa yang menurut pejabat baik dilakukan untuk rakyat, belum merealisasikan apa keinginan/harapan rakyat. Bupati Aristo Munandar mungkin termasuk di antara sedikit yang sudah reformis/demokratis/otonomis!?

SEMANGAT dan pengambilan posisi serta pola/cara kerja para pejabat politik/pemerintahan di daerah (gubernur dan bupati/walikota) dan pejabat politik (pimpinan/anggota DPRD) di era reformasi/demokratisasi dan otonomi daerah ini — paling tidak dalam pemahaman Cucu Magek Dirih, memang jauh berbeda dengan semangat dan pengambilan posisi serta pola/cara kerja di era rezim Orde Baru. Sebagian pimpinan/anggota DPRD dan kepala daerah/pejabatnya kelihatan sudah cenderung mengubah semangat dan pengambilan posisi serta pola/cara kerja mereka, tapi, sebagian lainnya masih melakukan dengan semangat/mindset dan pengambilan posisi serta pola/sara kerja Orde baru. Mungkin mereka tidak sepenuhnya menyadari dan tahu/mengerti apa yang salah/keliru— tidak tahu apa yang harus diubah!? Gubernur dan sebagian bupati/walikota masih membuat/menyusun sendiri kebijakan/regulasi dan mensosialisasikan. Tak dipertimbangkan kalau apa-apa kebijakan/regulasi yang dibuat/susun ternyata bukanlah harapan/keinginan rakyat/masyarakat — mereka yang terkait/terkena kebijakan/regulasi. Di masa rezim Orde Baru, pemerintah dan kepala daerah/pejabat (sekretaris daerah dan pimpinan instansi teknis) membuat/menyusun apa mereka sangka baik bagi rakyat/masyarakat. Rakyat/masyarakat mereka posisikan harus/dipaksa menerima bersih. Peduli apa, rakyat suka atau tidak/sesuai atau tidak. Yang dibuat demi rakayat!? Aspirasi hanya gonggongan — drama politik dimainkan. Menggonggonglah anjing/kafilan akan lewat — gonggong anjing hanya untuk memperindah drama politik!? Ada kepala daerah (gubernur dan bupati/walikota dan wali nagari) yang punya semangat/mindset dan berposisi serta bekerja reformis/demokratis/otonomis, tapi, sebagian pejabatnya (sebagian sekretaris daerah) masih belum berubah dan masih dengan semangat/mindset dan berposisi serta bekerja layak rezim Orde Baru!. Mereka memerintah/berkuasa daripada melayani/memfasilitasi dan mencerdaskan — walau mereka berpidato/berceramah/berwacana good local governance!? Seretaris daerah harus melayani/memfasilitasi/melancarkan hubungan kepala daerah dengan kepala dinas/badan/kantor dan sebaliknya, dan atau antara kepala daerah dengan rakyat/masyarakat dan sebaliknya — ada yang merasa jadi atasan kepala dinas/badan/kantor dan bahkan merasa “lebih menentukan” daripada kepala daerah! Saat menyampaikan orasi budaya/refleksi tahun 2006/2007 di Galanggang Hawa, nagari Lasi, kecamatan IV Angkat candung, kabupaten Agam — hampir ke puncak gunung Merapi, Minggu (31/12), dan bersama Bupati Agam Aristo Munandar — gubernur diwakili Kepala Biro Umum Yumler Lahar, pengurus dan anggota Persindo, dan masyarakat Lasi, Cucu Magek Dirih menyingung soal semangat/mindset dan pengambilan posisi serta pola/cara kerja sebagian pejabat politik/pemerintahan atau khsususnya kepala daerah dan para pejabat yang masih rezim Orde Baru tersebut. Cucu mengharapkan kepala/sekretaris daerah mengubah semangat/minset dan pengambilan posisi serta pola/cara kerja menjadi reformis/demokratis/otonomis. Karena, itu adalah konsekuensi logis dari reformasi/demokratisasi/otonomi daerah! Dalam konteks reformasi/demokratisasi/otonomi daerah, seharusnya kepala daerah dan pejabat pelayanan/fasilitasi serta kepala dinas/badan/kantor harus mengubah semangat/mindset dan pegambilan posisi serta pola/cara kerja mereka. Secara semangat/minset harus mengambil kebijakan/membuat regulasi mengacu kebutuhan/kepentingan rakyat. Mereka harus memandang dari posisi rakyat/masyarakat berada dan menjaring kehendak/harapan rakyat dengan mencer daskan dan merealisasikan. Pola/cara kerja kepala/sekretariat daerah dan kepala dinas/kantor/badan mestilah berbentuk/bersifat melayani dan memfasilitasi serta mencerdaskan rakyat/masyarakat. Mereka mutlak meninggalkan bentuk-bentuk/sifat-sifat/cara-cara berkuasa/memerintah, dan menyusun sendiri kebijakan/regulasi, baru kemudian mensosialisasikan. BUPATI Agam Aristo Munandar, mungkin termasuk sedikit kepala daerah yang sudah berubah semangat/mindset dan pengambilan posisi serta pola/cara kerjanya menjadi reformis/demokratis/otonomis. Merespon Cucu Magek Dirih di tengah sengatan hawa dingin pada detik-detik menjelang tahun 2007 itu, ia menceritakan bagaimana kodrat kepemimpinan selaku kepala daerah/bupati di kabupaten Agam — kepemimpinan Bupati Aristo dapat dinisbahkan berendah hati dan melayani serta mencermati keinginan/harapan rakyatnya — kemudian berusaha merealisasikan. Mungkin itu sebab ia terpilih secara langsung untuk periode ke-2 (2005-2010). Ia seorang pekerja keras dan mendatangi rakyatnya walau harus berjalan kaki berkilometer/mendaki bukit terjal. Ia menjadikan masjid pemberdayaan ekonomi kerakyatan/pengentasan keluarga miskin Secara gamblang Aristo menyebut kodratnya melayani kepentingan/memenuhi kebutuhan rakyat/masyarakat. Ia tahu memang demikian posisinya sebagai kepala daerah pilihan rakyat. Ia menceritakan, bagaimana ia selalu berada di sisi/memandang dari posisi rakyat/masyarakatnya. Dengan begitu, ia tahu apa yang menjadi harapan/keinginan rakyat/masyarakatnya. Memang adakala ia harus menecerdaskan dulu rakyat/masyarakatnya untuk memperjelas apa sesungguhnya yang menjadi harapan/kehendak rakyat/masyarakatnya. Ia pun berterusterang menjelaskan bahwa kemampuan/ketersediaan dana pemerintah sanat terbatas. Jadi, tidak semua harapan/kehendak rakyat/masyarakatnya dapat direalisasikan segera — dengan begitu rakyat/masyarakat jadi paham! Aristo menandaskan, untuk membuat pemerintah daerah kabupaten Agam mencapai progress/performance yang baik, harus terlebih dahulu memperkuat pemerintahan nagari — juga dengan melibatkan stake holders di nagari. Aristo membantu pemerintah nagari menyusun program pembangunan nagari dengan mendampingi mereka. Ia meminta stafnya (sekretariat daerah dan kepala dinas/kantor/badan/lembaga kabupaten) serta membahas dana untuk nagari bersama nagari/persatuan wali-wali nagari (Perwana). Agenda pemberdayaan ekonomi kerakyatan/pengentasan keluarga (KK) miskin menggunakan masjid sebagai sentra. Di masjid, kata Buoati Aristo, semua komponen masyarakat berkumpul. Tidak hanya pengurus, tapi, juga ninik-mamak/alimulama/cerdik pandai berkumpul — dengan semangat kekitaan/keberagamaan pula. Begitulah Aristo menyadari — mungkin sekaligus filosofi kepemimpian dalam masyarakat Minangkabau bahwa pemimpin didahulukan salangkah/ditinggikan sarantiang. Sebagai kepala daerah pilihan rakyat, ia adalah pemimpin di era reformasi/demokrasi/otonomi daerah, yang diharapkan mamou menjaring apa yang menjadi keinginan/harapan rakyatnya dan berusaha merealisasikannya secara bertahap. Ia menyadari kondratnya harus berdiri di sisi masyarakatnya dan memandang kebutuhan/kepentingan dan masalah serta perkembanan sebagaimana mayarakatnya memandang. Dari situ Aristo Munandar dapat merumuskan/memformulasikan tujuan/sasaran/target dan kebijakan/regulasi strategi/program/pendekatannya. Mungkin itu sebabnya, Aristo tidak hanya mendapat dukungan dari staf, tapi, terutama justeru dari masyarakatya. SUNGGUH, tidak mudah untuk mengubah semangat/mindset dan pengambilan posisi serta pola/cara kerja menjadi reformis/demokratis/otonomis karena kita memiliki pimpinan daerah/birokrasi yang sudah terlanjur terbentuk selama tiga dasawarsa dengan semangat/mindset dan pengambilan posisi serta pola/cara kerja rezim Orde baru. Harus ada sikap dan keberanian serta kejujuran pada diri sendiri untuk menyadari apa dan mana yang salah/keliru dalam penataan penyelenggaraan pemerintahan/pembangunan dan kesediaan mengubahnya — bukan tidak bisa! Apalagi perubahan tidak hanya sebatas wacana/retorika dan dalam kenyataan pejabat politik/pemerintahan daerah yang berbusa menyebut perubahan itu masih memiliki semangat/mindset dan pengambilan posisi serta poola/cara kerja masih rezim Orde Baru! Di Galanggang Hawa, nagari Lasi, kecamatan IV Angkek Canduang, kabupaten Agam, hampir ke puncak gunung Marapi, di antara desiran angin gunung yang dingin menjelang detik-detik pergantian tahun 2006 ke 2007, Bupati Aristo kelihatan inspiratif berbicara tentang kodrad pemerintahan daerah kabupaten agam di era reformasi/demokratisasi/otonomi daerah. Kelihatan ia sadar/yakin sepenuhnya akan posisi — dan influensi/konsekuensi/implikasi logis sebagai kepala daerah pilihan rakyat. Ia memang masih menyebut beberapa tantangan — kebelumsamaan persepsi penyelenggara pemerintahan/pembangunan, tapi, hal itu memang memerlukan kesabaran dalam proses perubahan/kesabaran membeli waktu. Bukankah, kalau perubahan dilakukan dengan cepat/keras, itu revolusi namanya!*** zailiasril@yahoo.com

Monday, July 14, 2008

Information Technology Audit Process

Information technology audit process:

Contents :
1 Generally Accepted Auditing Standards (GAAS)
2 IT Audit Process Overview
3 Phases of an IT Audit
3.1 Establish the Terms of the Engagement
3.2 Preliminary Review
3.3 Establish Materiality and Assess Risks
3.4 Plan the Audit
3.5 Consider Internal Control
3.6 Perform Audit Procedures
3.7 Issue the Audit Report
4 Planning the Audit
4.1 Materiality
4.2 Risk Assessment
4.2.1 Documentation of Risk Assessment
4.3 The Audit Plan
4.4 Planning Memo
5 Evaluation of Internal Controls
5.1 General Controls
5.2 Application Controls
5.3 Tests of Controls
6 Audit Procedures
6.1 Audit Sampling
6.1.1 Selecting the Sample
6.1.2 Evaluation and Documentation of Samples
6.2 Computer Assisted Auditing Techniques (CAATs)
6.3 Evidence
7 Completing the Audit
7.1 Reporting
7.1.1 Types of Reports
7.2 Audit Documentation
7.3 Follow Up Activities
7.4 Assessing the Audit
8 Resources
9 See also

Generally Accepted Auditing Standards (GAAS)
In 1947, the American Institute of Certified Public Accountants (AICPA) adopted GAAS to establish standards for audits. The standards cover the following three categories:
General Standards – relates to professional and technical competence, independence, and professional due care.
Field Work Standards – relates to the planning of an audit, evaluation of internal control, and obtaining sufficient evidential matter upon which an opinion is based.
Reporting Standards – relates to the compliance of all auditing standards and adequacy of disclosure of opinion in the audit reports. If an opinion cannot be reached, the auditor is required to explicitly state their assertions.

IT Audit Process Overview
The auditor must plan and conduct the audit to ensure their audit risk (the risk of reaching an incorrect conclusion based on the audit findings) will be limited to an acceptable level. To eliminate the possibility of assessing audit risk too low the auditor should perform the following steps:
Obtain an Understanding of the Organization and its Environment: The understanding of the organization and its environment is used to assess the risk of material misstatement/weakness and to set the scope of the audit. The auditor’s understanding should include information on the nature of the entity, management, governance, objectives and strategies, and business processes.
Identify Risks that May Result in Material Misstatements: The auditor must evaluate an organization’s business risks (threats to the organization’s ability to achieve its objectives). An organization’s business risks can arise or change due to new personnel, new or restructured information systems, corporate restructuring, and rapid growth to name a few.
Evaluate the Organization’s Response to those Risks: Once the auditor has evaluated the organization’s response to the assessed risks, the auditor should then obtain evidence of management’s actions toward those risks. The organization’s response (or lack thereof) to any business risks will impact the auditor’s assessed level of audit risk.
Assess the Risk of Material Misstatement: Based on the knowledge obtained in evaluating the organization’s responses to business risks, the auditor then assesses the risk of material misstatements and determines specific audit procedures that are necessary based on that risk assessment.
Evaluate Results and Issue Audit Report: At this level, the auditor should determine if the assessments of risks were appropriate and whether sufficient evidence was obtained. The auditor will issue either an unqualified or qualified audit report based on their findings.

Phases of an IT Audit
The audit process can be broken down into the following audit phases:

Establish the Terms of the Engagement
This will allow the auditor to set the scope and objectives of the relationship between the auditor and the organization. The engagement letter should address the responsibility (scope, independence, deliverables), authority (right of access to information), and accountability (auditees’ rights, agreed completion date) of the auditor.

Preliminary Review
This phase of the audit allows the auditor to gather organizational information as a basis for creating their audit plan. The preliminary review will identify an organization’s strategy and responsibilities for managing and controlling computer applications. An auditor can provide an in depth overview of an organization’s accounting system to establish which applications are financially significant at this phase. Obtaining general data about the company, identifying financial application areas, and preparing an audit plan can achieve this.

Establish Materiality and Assess Risks
In order to plan the audit, a preliminary judgment about materiality and assessment of the client’s business risks are made to set the scope of the audit.

Plan the Audit
Proper planning of the audit will ensure the audit is conducted in an effective and efficient manner. When developing the audit plan, the auditor should take into consideration the results of their understanding of the organization and the results of the risk assessment process.

Consider Internal Control
An internal control system should be designed and operated to provide reasonable assurance that an organization’s objectives are being achieved in the following categories: effectiveness and efficiency of operations, reliability of financial reporting, and compliance with applicable laws and regulations.
To develop their understanding of internal controls, the auditor should consider information from previous audits, the assessment of inherent risk, judgments about materiality, and the complexity of the organization’s operations and systems.
Once the auditor develops their understanding of an organization’s internal controls, they will be able to assess the level of their control risk (the risk a material weakness will not be prevented or detected by internal controls).

Perform Audit Procedures
Audit procedures are developed based on the auditor’s understanding of the organization and its environment. A substantive audit approach is used when auditing an organization’s information system.

Issue the Audit Report
Once audit procedures have been performed and results have been evaluated, the auditor will issue either an unqualified or qualified audit report based on their findings.

Planning the Audit
IS Standard 050 (Planning) states, “The IT auditor should plan the information systems audit coverage to address the audit objectives and comply with applicable laws and professional auditing standards.”
One of the first tasks an auditor must do when planning the audit is to develop a working budget. The IT audit manager must know the capabilities of the audit staff assigned to the project. In addition to budgeted time needed to perform the audit, the IT audit manager should also budget time needed to train the audit staff (if needed) and allow time for any error correction purposes.
While planning the audit, the auditor decides what level of audit risk (the risk of reaching an incorrect conclusion based on the audit findings) he or she is willing to accept. The more effective and extensive the audit work is, the less the risk that a weakness will go undetected and the auditor will issue an inappropriate report. Audit risk is dependent on the auditors assessed levels of inherent risk (the susceptibility of an audit area to error which could be material, assuming there are no related internal controls), control risk (the risk a material weakness will not be prevented or detected by internal controls), and detection risk (the risk substantive tests will not detect an error which could be material). These risks are determined when the auditor performs a risk assessment of the organization.
Additionally, in order to evaluate whether an IT audit has been successful, the auditor must first identify the intended scope and objectives of the audit to test management’s assertions on their information systems. To meet the audit objectives, and to ensure that audit resources will be used efficiently, the auditor will need to establish levels of materiality. The auditor should consider both qualitative and quantitative aspects in determining materiality. An assessment of risk should be made to provide reasonable assurance that all material items will be adequately covered during the audit work. This assessment should identify areas with relatively high risk of existence of material problems.

Materiality
In assessing materiality, the IT auditor should consider:
The aggregate level of error acceptable to management, the IT auditor, and appropriate regulatory agencies.
The potential for the cumulative effect of small errors or weaknesses to become material.
While establishing materiality, the auditor may audit non-financial items such as physical access controls, logical access controls, and systems for personnel management, manufacturing control, design, quality control, and password generation.
While planning the audit work to meet the audit objectives, the auditor should identify relevant control objectives and determine, based on materiality, which controls should be examined. Internal control objectives are placed by management and identifies what the management strives to achieve through their internal controls.
Where financial transactions are not processed, the following identifies some measures the auditor should consider when assessing materiality:
Criticality of the business processes supported by the system or operation.
Cost of the system or operation (hardware, software, third-party services)
Potential cost of errors.
Number of accesses/transactions/inquiries processed per period.
Penalties for failure to comply with legal and contractual requirements.

Risk Assessment
A risk is any event or action, generated internally or externally, which prevents an organization from achieving its goals and/or objectives. Risks affect control objectives in the areas of data integrity and accuracy, timeliness of the information for decision making, ability to access the system, and confidentiality/privacy of information, to name a few. Risk assessment allows the auditor to determine the scope of the audit and assess the level of audit risk and error risk (the risk of errors occurring in the area being audited). Additionally, risk assessment will aid in planning decisions such as:
The nature, extent, and timing of audit procedures.
The areas or business functions to be audited.
The amount of time and resources to be allocated to an audit.

Documentation of Risk Assessment
Once the assessed level of risk has been determined, the auditor should document the following in their work papers:
A description of the risk assessment technique used.
The identification of significant risks.
The risks the audit is going to address.
The audit evidence used to support the IS auditor’s assessment of risk.

The Audit Plan
The audit plan details the audit objectives and steps the auditor must take to ensure all of the important issues in the audit are covered. The audit plan includes:
The auditor’s understanding of the client.
Potential audit risks.
A basic framework for how the audit resources (budgeted audit hours) are to be allocated throughout the audit.
Audit procedures to be performed.
The objective of the audit plan is to assist the auditor in conducting an effective and efficient audit.

Planning Memo
A planning memo outlines for the auditee the tone and course of action the IT audit manager plans to take. The memo outlines for the auditee the areas within the audit the auditor is planning to spend most of their time, and it gives the auditee the opportunity to voice any concerns.

Evaluation of Internal Controls
COSO defines internal control as, “a process, influenced by an entity’s board of directors, management, and other personnel, that is designed to provide reasonable assurance in the effectiveness and efficiency of operations, reliability of financial reporting, and the compliance of applicable laws and regulations”. The auditor evaluates the organization’s control structure by understanding the organization’s five interrelated control components. They include:
Control Environment Provides the foundation for the other components. Encompasses such factors as management’s philosophy and operating style.
Risk Assessment Consists of risk identification and analysis.
Control Activities Consists of the policies and procedures that ensure employees carry out management’s directions. Types of control activities an organization must implement are preventative controls (controls intended to stop an error from occurring), detective controls (controls intended to detect if an error has occurred), and mitigating controls (control activities that can mitigate the risks associated with a key control not operating effectively).
Information and Communication Ensures the organization obtains pertinent information, and then communicates it throughout the organization.
Monitoring Reviewing the output generated by control activities and conducting special evaluations.
In addition to understanding the organization’s control components, the auditor must also evaluate the organization’s General and Application controls.

General Controls
General controls relate to the overall information-processing environment and has a large effect on the organization’s computer operations. Types of general controls include:
Organizational Controls - includes segregation of duties controls.
Data Center and Network Operations Controls – ensures the proper entry of data into an application system and proper oversight of error correction.
Hardware & Software Acquisition and Maintenance Controls – includes controls to compare data for accuracy when it is input twice by two separate components.
Access Security Controls – ensures the physical protection of computer equipment, software, and data, and is concerned with the loss of assets and information through theft or unauthorized use.
Application System Acquisition, Development, and Maintenance Controls - ensures the reliability of information processing.
Managerial controls- To ensure that there is no unauthorised access to IT assets.

Application Controls
Application controls apply to the processing of individual accounting applications and help ensure the completeness and accuracy of transaction processing, authorization, and validity. Types of application controls include:
Data Capture Controls – ensures that all transactions are recorded in the application system, transactions are recorded only once, and rejected transactions are identified, controlled, corrected, and reentered into the system.
Data Validation Controls – ensures that all transactions are properly valued.
Processing Controls – ensures the proper processing of transactions.
Output Controls – ensures that computer output is not distributed or displayed to unauthorized users.
Error Controls – ensures that errors are corrected and resubmitted to the application system at the correct point in processing.
Application controls may be compromised by the following application risks:
Weak security
Unauthorized access to data and unauthorized remote access
Inaccurate information and erroneous or falsified data input
Misuse by authorized end users
Incomplete processing and/or duplicate transactions
Untimely processing
Communication system failure
Inadequate training and support

Tests of Controls
Tests of controls are audit procedures performed to evaluate the effectiveness of either the design or the operation of an internal control. Tests of controls directed toward the design of the control focuses on evaluating whether the control is suitably designed to prevent material weaknesses. Tests of controls directed toward the operation of the control focuses on assessing how the control was applied, the consistency with which it was applied, and who applied it. In addition to inquiring with appropriate personnel and observation of the application of the control, an IT auditor’s main focus when testing the controls is to do a re-performance of the application of the control themselves.

Audit Procedures
Audit procedures are specific tasks (audit tests) performed by the auditor to gather evidence to determine if specific audit objectives are being met. IS Auditing Standard 060 (Performance of Audit Work) states, “During the course of the audit, the IT auditor should obtain sufficient, reliable, and relevant evidence to achieve the audit objectives. The audit findings and conclusions are to be supported by appropriate analysis and interpretation of this evidence.”
An auditor must design, select, evaluate, and document sample evidence in order to meet the requirements of “sufficient, reliable, and relevant evidence” and “supported by appropriate analysis”.

Audit Sampling
Audit sampling is the application of an audit procedure to less than 100% of the population to enable the IT auditor to evaluate audit evidence within a class of transactions for the purpose of forming a conclusion concerning the population. When designing the size and structure of an audit sample, the IT auditor should consider the audit objectives determined when planning the audit, the nature of the population, and the sampling and selection methods.

Selecting the Sample
The auditor should select the sample items in such a way that they are representative of the population. The most commonly used sampling selection methods are:
Statistical Sampling Methods
Random Sampling – ensures that all combinations of sampling units in the population have an equal chance of selection.
Systematic Sampling – involves selecting sampling units using a fixed interval between selections with the first interval having a random start.
Non-Statistical Sampling Methods
Haphazard Sampling – the auditor selects the sample without following a structured technique.
Judgmental Sampling – the auditor places a bias on the sample. For example, selecting only sampling units over a certain value.
The selection of the sample size is affected by the level of sampling risk that the IT auditor is willing to accept. Sampling risk is the risk the auditor’s conclusion may be different from the conclusion that would be reached if the entire population were subjected to the same audit procedure. The two types of sampling risk are:
The Risk of Incorrect Acceptance – the risk that a material misstatement is assessed as unlikely, when in fact the population is materially misstated.
The Risk of Incorrect Rejection – the risk that a material misstatement is assessed as likely, when in fact the population is not materially misstated.
Once the sample items have been selected to be tested, the auditor can begin audit tests using Computer Assisted Auditing Techniques (CAATs), which will be discussed shortly.

Evaluation and Documentation of Samples
The performance and evaluation of a sample must address the following issues:
The effect of not being able to apply a planned procedure to a sample item.
A projection of the sample results to the population being tested, then comparing those results with the planned amounts.
Appropriate consideration to the assessed level of sampling risk must be performed.
SAS 39 requires the auditor to adequately consider qualitative aspects of misstatements, such as the nature and cause of the misstatement and the possible relationship of the misstatements to other phases of the audit.
The auditor must document in their work papers the sampling objectives and the sampling process used. The work papers should include the source of the population, the sampling method used, sampling parameters, items selected, details of audit tests performed, and conclusions reached.

Computer Assisted Auditing Techniques (CAATs)
Further information: Data analysis (information technology)
CAATs are used to test application controls as well as perform substantive tests on sample items. Types of CAATs include:
Generalized Audit Software (GAS) – allows the auditor to perform tests on computer files and databases.
Custom Audit Software (CAS) – generally written by auditors for specific audit tasks. CAS is necessary when the organization’s computer system is not compatible with the auditor’s GAS or when the auditor wants to conduct some testing that may not be possible with the GAS.
Test Data – the auditor uses test data for testing the application controls in the client’s computer programs. The auditor includes simulated valid and invalid test data, used to test the accuracy of the computer system’s operations. This technique can be used to check data validation controls and error detection routines, processing logic controls, and arithmetic calculations, to name a few.
Parallel Simulation – the auditor must construct a computer simulation that mimics the client’s production programs.
Integrated Test Facility – the auditor enters test data along with actual data in a normal application run.

Evidence
Through the use of CAATs, the auditor will be able to obtain evidence to support their final conclusions developed on the audit. Audit evidence should be sufficient, reliable, relevant, and useful in order for the auditor to form an opinion and to support their findings and conclusions. If the auditor cannot form an opinion based on the audit evidence obtained, the auditor should then obtain additional audit evidence. Procedures used to gather audit evidence varies depending on the information system being audited. The auditor should select the most appropriate procedure for the audit objective. The following procedures should be considered:
Inquiry and/or Observation
Inspection
Reperformance
Monitoring
The audit evidence gathered by the auditor should be documented and organized to support the auditor’s findings and conclusions. Finally, when an auditor believes that sufficient audit evidence cannot be obtained, the auditor should disclose this fact as a scope limitation within the audit report.

Completing the Audit
Before choosing the appropriate audit report, the auditor must consider the following issues:
Review for Subsequent Events – two types of subsequent events require an evaluation by the auditor. They include:
Type I events – events that provide additional evidence about the conditions that existed at the date of the balance sheet.
Type II events – events that provide evidence about conditions that did not exist at the date of the balance sheet, but arose after that date.
Audit procedures used to review for subsequent events include asking management whether any unusual adjustments to their information systems have been made during the subsequent events period (after the completion of the audit, but before the audit report is issued), or obtaining a representation letter from management.
Final Evidential Evaluation Processes – audit steps performed by the auditor in this phase to determine the most appropriate audit report includes obtaining a representation letter, reviewing work papers, final assessment of audit results and obtaining an independent review of the engagement.
Communications with the Audit Committee and Management – communications should include significant audit adjustments, the auditor’s judgments about the quality of the entity’s accounting principles, disagreements with management, major issues discussed with management before the auditor was retained, difficulties encountered during the audit, and fraud involving senior management. Also, the auditor should discuss the draft of the audit report with management to give management the chance to correct any weaknesses or deficiencies before they are reported and released to the public. The auditor may decide to do this in the form of a Management Comment Letter.
Subsequent Discovery of Facts Existing at the Date of the Auditor’s Report – Auditing standards 561 provides guidance for auditors when facts have come to the auditor’s attention about the organization’s processes that might have affected the report had they known about them.
The auditor’s conclusion and findings, which are based on documented evidence, must be objective, measurable, complete, and relevant. The findings are disclosed to management in formal statements, typically an audit report. Any recommendations must be provided for each audit finding for the report to be useful to management.

Reporting
IS Auditing Standard 070 (Reporting) states, “The IT auditor should provide a report in an appropriate form, upon the completion of the audit. The report should state the scope, objectives, period of coverage, and the nature, timing, and extent of the audit work performed. The report should state the findings, conclusions, and recommendations and any reservations, qualifications or limitations of scope that IT auditor has with respect to the audit.”

Types of Reports
Unqualified Audit Report
This type of report is used when the auditor has gathered sufficient evidence, the audit was performed in accordance with GAAS, and no scope limitations were encountered.
Unqualified Audit Report with Explanation
This type of audit report is required when the auditor’s wording needs to be modified possibly due to an emphasis of a matter or an organization’s lack of consistency when processing information.
Qualified Report
The auditor’s opinion will be qualified due to a scope limitation or an organization’s departure from GAAP, even though the overall financial statements having been fairly presented.
Qualified Report with Disclaimer
The auditor disclaims an opinion because there is insufficient competent evidence to form an opinion or because there is a lack of independence.
Qualified Report with an Adverse Opinion
The auditor issues this report because the organization’s financial statements are not presented fairly and were not developed in conformance with GAAP.

Audit Documentation
Working papers (audit documentation) is the formal collection of auditors notes, documents, flowcharts, correspondence, results of observations, plans and results of tests, the audit plan, minutes of meetings, computerized records, data files or application results, and evaluations that document the auditor activity for the entire audit period. The audit report is also included in the work papers. Work papers are essential to support the auditor’s findings and recommendations as stated in the audit report.

Follow Up Activities
Once the auditor has reported their findings and recommendations to management, the IT auditor should request and evaluate relevant information to conclude whether appropriate action was taken by management in a timely manner. The nature, timing, and extent of the follow-up activities should take into account the importance of the reported findings and the impact on the organization if corrective action has not been taken. Depending on the scope of the audit, the IT auditor may rely on an internal auditor to perform the follow-up activities.

Assessing the Audit
The audit and working papers should be evaluated based on the following criteria by a partner or senior manager:
Completeness – An audit must cover every element of the audit subject.
Pertinence – The audit should be free of extraneous or unnecessary elements.
Accuracy – All elements of the audit must be precise and error-free.
Appropriate Conclusions, Findings and Recommendations – The audit must present appropriate conclusions and findings that lead to recommendations reflecting workable and timely solutions to audit objectives.
Follow-up to Findings and Recommendations – The value of the audit must be assessed to assure that the findings and recommendations, reflecting workable and timely solution have been achieved to some quantifiable degree and have provided value to the organization.

Resources
Auditing & Assurance Services, William F. Messier, Jr., 3rd Edition, page 45
Information Technology Control and Audit, Frederick Gallegos, Sandra Senft, et al, 2nd Edition, page 577
Auditing & Assurance Services, William F. Messier, Jr., 3rd Edition, page 55
Auditing & Assurance Services, William F. Messier, Jr., 3rd Edition, page 60 and Information Technology Control and Audit, Frederick Gallegos, Sandra Senft, et al, 2nd Edition, page 72
IS Auditing Standard S5 Planning - 04 Risk Assessment
IS Auditing Guideline G6 Materiality Concepts for Auditing Information, Paragraph 2.1.2
IS Auditing Guideline G6 Materiality Concepts for Auditing Information, Paragraph 2.1.5
IS Auditing Guideline G13 Use of Risk Assessment in Audit Planning, Paragraph 2.1.3
IS Auditing Guideline G13 Use of Risk Assessment in Audit Planning, Paragraph 2.3.4 & 2.3.5
IS Auditing Guideline G13 Use of Risk Assessment in Audit Planning, Paragraph 2.5.3
Guest speaker Mike Simpson, May 16, 2005
Auditing & Assurance Services, William F. Messier, Jr., 3rd Edition, page 263
AU 350.01
IS Auditing Guideline G10 Audit Sampling, Paragraph 2.3.1
SAS No. 39
Auditing & Assurance Services, William F. Messier, Jr., 3rd Edition, page 304
IS Auditing Guideline G10 Audit Sampling, Paragraph 2.4.1
Auditing & Assurance Services, William F. Messier, Jr., 3rd Edition, page 276
IS Auditing Guideline G2 Audit Evidence Requirement, Paragraph 3.2.1