BIANCA'S BLOG

1. Klik menu Konsultasi.
2. Isi nama anda pada form yang tersedia, kemudian klik lanjutkan.
3. Setelah itu pilih gejala yang sesuai dengan kondisi anda (gejala fisik, gejala emosional, gejala sikap, gejala pikiran), jika sudah klik lanjutkan.
4. Anda akan melihat hasil konsultasi disertai dengan solusi dari penyakit anda.
5. Selesai.

1. Administrator
   Dengan menggunakan user administrator anda dapat mengelola data-data yang ada seperti data gejala, data solusi, data penyakit, data kasus, dan lain sebagainya.
2. Pasien
   User pasien merupakan user yang hanya dapat melakukan konsultasi pada aplikasi sistem pakar metode CBR ini.

1. Layanan strategis agar Sistem Informasi berkembang cepat

Nama : Bianca Ayu Saraswati
NPM : 1B117083
Kelas : 5 KA 44


Chapter 10
Selecting, Testing, and Auditing IT Applications

INFORMATION TECHNOLOGY (IT) APPLICATIONS are the tools that bring value to computer systems; they drive many if not most of today’s enterprise business processes. These IT applications range from the relatively simple, such as an accounts payable system to pay vendor invoices, to the highly complex, such as an enterprise resource management (ERM) set of multiple interrelated database applica- tions to control virtually all enterprise business processes.

A typical enterprise may use a large and diverse number of production IT applications. These applications support a wide variety of functions within the enter- prise, starting with accounting applications but also including such areas as manu- facturing, marketing, distribution, and others, depending on business activities. These supporting applications may be implemented using a variety of IT technologies, such as centralized systems with telecommunication networks, Internet-based network systems, client-server server-based applications, and even older mainframe batch- processing systems. Some of these applications may have been developed in-house but increasingly large numbers of them are based on purchased software packages installed locally or accessed through Web-based service providers. In-house-developed applications may be written in a programming language such as C# (also called C- sharp) or Visual Basic, a database report-generator language such as SQL, or the object- oriented language Java. Application documentation may range from very complete to almost nonexistent.

IT auditors should survey the active applications and select the more critical and appropriate ones for review. We also discuss approaches to effectively review internal accounting controls in IT applications, using several different types of applications as examples. Finally, the chapter discusses audit approaches for evaluating and testing those application controls as well as techniques for reviewing new applications under development. We focus on the internal control characteristics of different types of applications and on how to select appropriate applications in internal controls reviews. There are many differences from one application to another; this chapter focuses on how an IT auditor should select higher-risk applications as candidates for IT audit reviews, the tools and skills needed to understand and document application internal controls, and, finally, processes to test and evaluate those applications.

IT APPLICATION CONTROL ELEMENTS People not familiar with IT sometimes think of a computer application just in terms of the system’s output reports or the data displayed on terminal screens. However, every application, whether a Web-based service application, an older mainframe system, a client-server application, or an office productivity package installed on a local desktop system, has three basic components: (1) the system inputs, (2) the programs used for processing, and (3) the system outputs. Each of these has an important role in an application’s internal control structure, and an IT auditor should understand these components when reviewing an IT application.

Application Input Components Although an application’s programs process the data, determine the outputs, and have a major impact on controls, an IT auditor should understand the nature and sources of the input components.

Inputs from Data Collection or Other Input Devices The original data collection sheet was the first step in the input chain, and early IT auditors were concerned that all transactions were keypunched correctly. Technology has effectively eliminated those punched-card input records today. Batch-type transactions that must be entered into an application are no longer entered by a specialized ‘‘keypunch’’ or data-entry department. Rather, operational departments use online terminals to enter their transactions for collection and subsequent process- ing. Following a processing schedule, these transactions may be input or collected and updated later in a batch mode. The data entry programs used to capture them often have some transaction-screening capabilities to eliminate any low-level errors common to earlier batch input system An IT auditor reviewing application input controls always should look for some basic internal control elements that should be found in all IT applications. For example, there should be some means of checking that only correct data is entered. A computer program that, through its supporting validation tables, can verify that a product part or employee number is or is not valid cannot easily verify that the current quantity should have been entered as 100 as opposed to 10.s. In many other situations, the entry of a transaction updates files in a real-time mode.

Application Inputs from Other Automated Systems IT applications often are highly integrated, with one application generating output data for processing by another. The transaction entered into one application may impact a variety of other interrelated applications. Thus an error or omission of an input at one point in a chain of applications may impact the processing of another connected application. The IT auditor may be interested in understanding application input controls for application X. However, files from applications A, B, and C may provide inputs to X while D and E provide inputs to applications A and C, respectively. An IT auditor typically does not have the time or resources to review all of these processes and must decide on the most critical ones and assume that the other less critical supporting applications are generating appropriate transactions.

PERFORMING AN APPLICATION CONTROLS REVIEW: PRELIMINARY STEPS
Once an application has been selected for review, IT audit should gain a more detailed understanding of the purpose or objectives of that application, the technology approaches used, and the relationship of the application to other related processes.    It may be necessary for the assigned IT auditor to do some background reading and study special technical aspects of that application. Auditors often can acquire this knowledge by reviewing past audit workpapers and applications documentation and by interviewing IT and user personnel. As an early step in this review process, IT audit should perform a walk-through of the application to better understand how it works and how its controls function. These preliminary steps will allow an IT auditor to develop specific audit tests of the application’s more significant controls.

COMPLETING THE IT APPLICATION CONTROLS AUDIT Usually more difficult for an IT auditor to define than the objectives for an IT audit of general controls, thespecific audit objectives supporting a detailed IT application audit can vary depending on whether the review covers a single application or is a module of a larger business process, such as an ERP system. The IT auditor’s review strategy depends on whether (1) the application primarily uses purchased or in-house-developed software components; (2) the application is integrated with others or is a separate process; (3) it uses Web-based service providers, client-server or older, legacy computer system methods; and (4) its controls are largely automated or require extensive human intervention actions.

AUDITING APPLICATIONS UNDER DEVELOPMENT It is often much more efficient for an IT auditor to review an IT application for its internal controls while it is being developed and implemented rather than after it has been placed into production. The role of the IT auditor here is similar to that of a building inspector reviewing a new construction project: It is difficult to make constructive recommenda- tions regarding the completed building. Even if some problems were found, the inspector would be under considerable pressure not to identify ones that would require significant portions of the building to be torn down and rebuilt. Rather, the building inspector identifies problems during construction and suggests how they can be corrected before completion. Similarly, the effective IT auditor should suggest corrective actions to improve system controls along the way. It is easier to implement changes during an application implementation process than after it has been completed and the system has been placed into production.

Objectives and Obstacles of Preimplementation Auditing
The concept of preimplementation reviews was first proposed by the then-new profes- sion of what was called EDP auditing in the early 1970s; at that time, many traditional internal auditors were opposed to this approach. Traditionalists argued that if an auditor reviewed an application in advance of its implementation, it would be difficult to come back later and review that same application after implementation. The argument was that if an IT auditor had ‘‘blessed’’ the internal controls of a system under development, how could that same auditor come back later and perform a critical review? Over the years, there have been many changes to the application development process. New applications frequently are based on vendor-supplied software components, and internal auditing standards, as discussed in Chapter 3, allow an internal auditor also to act as a consultant. IT auditors have also grown to accept preimplementation reviews, acting as auditors and not consultants.

IT auditors, however, face four major obstacles when reviewing new applications under development:

1.‘‘Them versus us’’ attitudes. Although IT audit and general management both may accept the concept, IT management often expresses wariness or even resent- ment when IT audit announces its plan to review an application that is under development and still has many details yet to be worked out. The announcement ‘‘Hello, I’m from IT audit, and I am here to help you’’ may not be received favorably. Good preimplementation review procedures can establish respect for IT audit’s role and add value in the development process. An IT auditor who spends many hours reviewing a complex new application with some potential control-related issues and who concludes only that ‘‘Documentation needs to be improved’’ will not be viewed as having added much value to the process.

2. IT auditor role problems. The IT auditor’s role must be clearly understood by all parties and might be defined as:

Ø  An extra member of the implementation team. The systems design team invites the IT auditor to design review meetings. However, that IT auditor will be more of an observer than a typical member of that team. The auditor’s objective is to gather data regarding key controls and processing procedures for a subsequent audit report.
Ø  A specialized consultant. Sometimes an IT auditor can become so involved in the systems design and development process that he or she is viewed as just another design team consultant making recommendations during the course of the implementation process. IT audit should take care to not be viewed in that light. Following the standards foran IT auditorasanenterprise consultant, asdiscussed in Chapter 3, an IT auditor should act primarily as an independent reviewer providing help to the team, not as a specialized consultant who is part of the design process.
Ø  An internal controls expert. In any review, IT audit always should make certain that a review of internal controls is included in the new project. However, the auditor should not be the primary designer of those controls. Otherwise, he orshe may have problems reviewing the completed application and its controls at some later date.
Ø  An occupant of the ‘‘extra chair.’’ Sometimes an IT auditor does not do a proper level of preparatory work during a preimplementation review. Systems management may request an auditor to review various materials and attend design review meetings. An IT auditor who does not prepare but simply attends these meetings too frequently provides no real contributions. Nevertheless, if problems occur in the future, management may say ‘‘But IT audit was there!’’
Ø  State-of-the-art awareness needs. New systems applications often involve new technologies or business processes. IT auditors should be involved in their own continuous education programs to better understand state of the are issues. A general understanding of new technologies may require some additional IT auditor homework—reading vendor manuals and other documentation.
Ø  Many and varied preimplementation candidates. The typical larger enterprise may have a significant number of new application projects that are potential candidates for preimplementation reviews. These projects will all have different start times, durations, and completion dates. An IT auditor needs to perform an ongoing risk assessment to select the most appropriate new review candidates.

Preimplementation Review Objectives A key objective of application preimplementation auditing is to identify and recom- mend control improvements such that they can be potentially installed during the application development process. However, rather than just assuming that a new IT project is a given and then reviewing its controls, IT audit also should aim to review the justification and definition of the new development project. There should be a good project management system in place that properly plans development steps and measures actual progress against those planned steps. For major projects, IT audit can evaluate the adequacy of project development controls used for the particular application. This preimplementation phase is also an excellent time for an IT auditor to gain an understanding of the new application sufficient to design future automated audit tests and to define the CAATTs as discussed in Chapter 13. Whether the implementation involves a vendor software package or an application developed in- house, IT auditors should gain overall understandings of all aspects of those applica- tion projects.

Preimplementation Review Problems Preimplementation reviews often present IT audit with some very serious review and scheduling problems, including too many review candidates given limited IT audit resources. IT auditors sometimes make the mistake of announcing their intent to review all new applications and all major modifications prior to implementation. In a larger enterprise, dozens or even hundreds of user requests for new or major revision projects may be initiated regularly. IT audit will have no time for comprehensive preimple- mentation reviews and only time for little more than nominal rubber-stamp approval signatures.

Preimplementation Review Procedures Many of the same audit procedures discussed in other chapters for IT internal controls  reviews can also be followed for reviews of new applications under development. All too often, IT auditors argue that applications under development are somehow ‘‘different.’’ However, as fluid and subject to ongoing developmental change as applications under development are, many of the same control objectives and  procedures  discussed  previ- ously for IT applications are quite appropriate for these reviews. IT auditors should tailor their preimplementation reviews along the various phases a new project’s development, starting with initial project initiation, to requirements definitions  definition,  to  develop- ment and testing, and finally to  implementation.  These  same  basic  steps  apply  whether the application is a major in-house-developed one, a  vendor  service-based  software  package, or a user-led set of desktop applications. The only difference is on emphasis depending on the application development approach.

IMPORTANCE OF REVIEWING IT APPLICATION CONTROLS An IT auditor should place a major emphasis on reviewing the supporting IT appli- cations when performing reviews in other areas of the enterprise. Even though good general or interdependent IT control procedures may be in place, individual application controls may not all be that strong. An enterprise’s applications may have been developed through a series of compromises among users or without any level of proper quality assurance. To evaluate IT application controls properly, IT audit needs a good understanding of both IT procedures and the specific control and procedural character- istics of each application area.
The effective IT auditor should spend a substantial amount of audit effort reviewing and testing controls over specific IT applications and new applications in the develop- ment process. Such reviews will provide assurance to general management that applications are operating properly and to IT management that their design and controls standards are being followed, allowing them to place greater reliance on    the output results of such applications. An understanding of application control reviews is a key skill requirement for all IT auditors.

NOTES:

1. Developed in the 1960s, the computer programming language COBOL stands for Common Business Oriented Language. It is still used today as a key programming language.

2.Numerous textbooks and references describe object-oriented programming. A search on the Internet will provide many references.

Nama : Bianca Ayu Saraswati
NPM : 1B117083
Kelas : 5KA44

1. Pengertian Penelitian Eksploratif
Penelitian eksploratif adalah salah satu jenis penelitian sosial yang tujuannya untuk memberikan sedikit definisi atau penjelasan mengenai konsep atau pola yang digunakan dalam penelitian. Dalam penelitian ini, peneliti belum memiliki gambaran akan definisi atau konsep penelitian. Peneliti akan mengajukan what untuk menggali informasi lebih jauh. Sifat dari penelitian ini adalah kreatif, fleksibel, terbuka, dan semua sumber dianggap penting sebagai sumber informasi.

2. Tujuan Penelitian Eksploratif
Tujuan dari penelitian ini adalah untuk menjadikan topik baru lebih dikenal oleh masyarakat luas, memberikan gambaran dasar mengenai topik bahasan, menggeneralisasi gagasan dan mengembangkan teori yang bersifat tentatif, membuka kemungkinan akan diadakannya penelitian lanjutan terhadap topik yang dibahas, serta menentukan teknik dan arah yang akan digunakan dalam penelitian berikutnya.

3. Kelebihan Penelitian Eksploratif
Kelebihan dari penelitian ini adalah tatacara atau langkah-langkah penelitiannya tidak terstruktur baku seperti penelitian deskriptif, dan jauh lebih luwes dapat diubah-ubah sesuai situasinya.

4. Kekurangan Penelitian Eksploratif
Kekurangan dari penelitian ini adalah harus memerlukan penelitian lanjuta, sehingga penelitian ini tidak bisa langsung selesai tetapi harus ada lanjutannya.


5. Contoh Penelitian Eksploratif
Contoh penelitiannya adalah misalnya, penelitian tentang etos kerja masyarakat suku Dayak di pedalaman Kalimantan.


Sumber :
https://id.m.wikipedia.org/wiki/Penelitian_eksploratif

1. Bagaimana Sariwangi bisa bangkrut?

1. Terlambat

• BPK RI

• Keuangan BPKP (Badan Pengawasan dan Pembangunan)

• LPAI