BAB 2 LANDASAN TEORI
2.1. Teori Umum 2.1.1. Analisis Pengertian analisis menurut Roberta M. Roth, Alan Dennis dan Barbara Haley Wixom (2013, p. 102) adalah proses memecah satu kesatuan menjadi bagianbagian dengan maksud untuk lebih memahami sifat, fungsi, dan hubungan antar bagian. Dengan adanya bagian-bagian yang telah dipecah menjadi lebih detail itu, pembuatan dan pemeliharaan sistem akan menjadi lebih mudah dan terarah karena dianalisis per bagian secara detail. Pengertian analisis menurut Charles S. Wasson (2006, p. 574) adalah “A structured investigation or examination using a proven methodology”. Analisis adalah sebuah investigasi atau pengujian terstruktur menggunakan metodologi yang
telah
terbukti.
Dengan
begitu,
kebenaran
dari
analisis
dapat
dipertanggungjawabkan karena menggunakan metodologi yang telah terbukti. Menurut Davis dan Yen (2010, p. 18), “Structured analysis is a front-end methodology that allows users and/or systems analysts to convert a real-word problem into a pictorial diagram or other logical representation that can subsequently be used by the systems developers and/or programmers to design an information system. Structured design is concerned with physical design based on the results of structured analysis. More generally, structured analysis transforms the abstract problem into a feasible logical design, while structured design concentrates on converting the logical design into a physical information system”. Dengan melakukan analisis terstruktur akan memungkinkan pengguna ataupun sistem analis untuk mengubah semua permasalahan kedalam bentuk representasi logis yang dapat digunakan oleh para pengembang sistem atau programmer untuk merancang sistem yang diinginkan. Desain yang terstruktur sendiri memiliki kaitan yang erat dengan desain fisik dimana diperoleh berdasarkan hasil analisis. Secara umum, analisis mengubah masalah abstrak menjadi desain logis yang lebih jelas.
9
10 Menurut Davis dan Yen (2010, pp. 19-20), berikut merupakan tahapan yang dilakukan pada saat proses analisis berjalan:
Gambar 2. 1 Langkah Utama Dalam Proses Analisis Terstruktur Sumber: (The Information System Consultant's Handbook, 2010)
1. Mempelajari lingkungan bisnis saat ini Tujuan dari tahap ini adalah untuk mempelajari sistem yang lama dengan menjalankan analisis fungsional end-user untuk menentukan kebutuhan akan sistem yang baru serta menjalankan analisis kebutuhan untuk memastikan apakah sistem yang baru benar-benar dibutuhkan. 2. Memodelkan sistem yang lama Objektif dari tahap ini adalah untuk membangun model logis yang menangkap esensi dari lingkungan saat ini dengan mengeleminasi detail operasional dan fisikal. 3. Memodelkan sistem yang baru Berdasarkan model sistem yang lama, peningkatan model logis untuk sistem yang baru terbuat. User requirement yang baru ditambahkan, requirement yang berlebihan dieliminasi dan dikonsolidasi, serta requirement yang sudah ada di update lebih lanjut. Pada akhirnya, data flow harus dapat diverifikasi.
11 4. Memodelkan lingkungan fisik yang baru Detail fisik yang diperlukan ditambahkan kembali ke desain logis yang baru yang telah dibuat dilangkah sebelumnya. Secara lebih lanjut, opsi desain seperti hardware, software, platform dan interface diidentifikasi. 5. Mengevaluasi alternatif Selama tahap ini berlangsung, estimasi biaya, penjadwalan, estimasi kebutuhan resources, analisis cost benefit serta parameter serupa dipersiapkan untuk setiap desain menggunakan tools yang disepakati. 6. Memilih desain yang terbaik Alternatif terbaik dipilih menggunakan tools yang disepakati oleh para sistem analis. 7. Membuat spesifikasi yang terstruktur Menyiapkan rekomendasi untuk persetujuan manajemen dan juga untuk menyediakan dokumentasi untuk desain yang terstruktur.
2.1.2. Testing Menurut Limaye (2009, p. 70), testing merupakan suatu kegiatan yang dilakukan untuk mengetahui apakah kebutuhan perangkat lunak dan spesifikasi desain, yang didukung oleh strategi pengujian dan pendekatan dalam melakukan pengujian yang bergantung pada asumsi dan resiko pengembangan, pengujian dan penggunaan. Dalam proses pengujian suatu perangkat lunak ataupun suatu produk, dibutuhkan sebuah tim yang akan independen, dimana mereka akan melakukan serangkaian kegiatan menurut job-desk yang dimilikinya dalam proses pengujian tersebut. Ada beberapa pendekatan tim penguji, salah satunya adalah tim penguji independen. Pada pendekatan ini, tim penguji biasanya tidak melaporkan hasil dari pengujian yang dilakukan kepada masing-masing tim nya, dalam arti semua hasil dari pengujian yang dilakukan akan dilaporkan kepada manajer senior atau kepada klien.
12
Gambar 2. 2 Struktur Organisasi Tim Penguji yang Independen Sumber: (Software Testing: Principles, Techniques and Tools, 2009)
Adapun kelebihan dari pendekatan tim penguji yang independen menurut Limaye (2009, pp. 90-91) adalah berikut sebagai berikut: 1. Tim penguji tidak dibawah tekanan dalam penyampaian produk, mereka dapat memanfaatkan waktu yang cukup untuk melaksanakan pengujian yang lengkap sesuai dengan iterasi dan cakupan yang telah dibuat untuk melaksanakan pengujian. 2. Tim penguji tidak dibawah tekanan untuk menemukan bug atau error pada perangkat lunak pada saat proses pengujian, tetapi mereka harus menemukan bug atau error tersebut sebelum produk atau perangkat lunak tersebut diberikan kepada klien. 3. Detail dari produk atau perangkat lunak diperoleh dari proses pemikiran tim pengembang dan tester yang berbeda. 4. Mendapatkan pedoman dan bimbingan dari seorang ahli yang dibutuhkan oleh tim penguji untuk melakukan pengujian yang efektif. Sedangkan kekurangan dari pendekatan tim penguji independen adalah sebagai berikut: 1. Selalu ada gap antara tim penguji dan tim pengembang karena adanya pemikiran yang berbeda. Sinergi tim dapat hilang karena menurut tim pengembang apa yang telah dibuat oleh mereka tidak sesuai dengan apa yang diinginkan oleh tester. 2. Tester mungkin tidak mendapatkan pemahaman yang baik tentang proses dalam produk atau perangkat lunak, karena ada proses yang disembunyikan oleh tim pengembang. Tester diperlakukan sebagai orang luar.
13 3. Terkadang, manajemen mungkin cenderung berlebihan terhadap satu tim, baik tim pengembang maupun tim pengujian, sehingga tim lain merasa bahwa mereka tidak memiliki nilai di dalam organisasi tersebut.
2.1.3. Laporan Keuangan Menurut PSAK NO.1 Paragraf ke 7 (Revisi 2009), laporan keuangan adalah suatu penyajian terstruktur dari posisi keuangan dan kinerja keuangan suatu entitas yang bertujuan untuk memberikan informasi mengenai posisi keuangan, kinerja keuangan, dan arus kas entitas yang dapat memberikan manfaat bagi sebagian besar kalangan pengguna laporan dalam pembuatan keputusan ekonomi. Pada dasarnya sistem akuntansi yang ada, dirancang untuk menghasilkan informasi baik bagi pihak internal mapun eksternal. Informasi dalam laporan keuangan yang diberikan bagi pihak eksternal umumnya lebih ringkas dibandingkan informasi yang dilaporkan kepada pihak internal. Hal ini dikarenakan sebagian besar perusahaan tidak ingin mengungkapkan setiap detail dari keuangan internal perusahaan kepada pihak luar perusahaan. Laporan keuangan menurut Sogiono, Soenarno, dan Kusumawati (2009, pp. 6-7) merupakan hasil akhir dari kegiatan akuntansi (siklus akuntansi) yang mencerminkan kondisi keuangan dan hasil operasi perusahaan. Pihak-pihak yang berkepentingan dalam laporan keuangan adalah pihak internal maupun pihak eksternal. 1. Pihak internal Bagi manajemen, berkepentingan langsung dan sangat membutuhkan informasi
keuangan
pengkoordinasian
untuk
tujuan
(coordinating),
dan
perusahaan,
dengan
pengendalian perencanaan
(controlling),
(planning)
suatu
perusahaan. Bagi
pemilik
melakukan
analisis
laporan
keuangannya, pemilik dapat menilai berhasil atau tidaknya manajemen dalam memimpin perusahaan. 2. Pihak eksternal Bagi investor, memerlukan analisis laporan keuangan dalam rangka penentuan kebijakan penanaman modalnya. Yang terpenting adalah tingkat imbalan hasil (return) dari modal yang telah atau akan ditanam dalam suatu perusahaan tersebut.
14 Bagi kreditur, merasa berkepentingan terhadap pengembalian atau pembayaran kredit yang telah diberikan kepada perusahaan, mereka perlu mengetahui kinerja keuangan jangka pendek (likuiditas), dan profitabilitas dari perusahaan. Bagi pemerintah, informasi ini sangat berguna untuk tujuan pajak dan juga oleh lembaga lain seperti statistik. Bagi karyawan, berkepentingan dengan laporan keuangan dari perusahaan tempat mereka bekerja karena sumber penghasilan mereka bergantung pada perusahaan yang bersangkutan. Adapun 3 laporan keuangan yang utama menurut Stice, Stice, dan Skousen (2007, pp. 10-11) dimana dianggap sebagai centerpiece bagi akuntansi keuangan disebutkan sebagai berikut: 1. Laporan Balance Sheet Balance sheet atau neraca berisikan sumber daya suatu perusahaan seperti asset, kewajiban perusahaan atau liabilities, serta selisih bersih antara harta dan kewajiban perusahaan, dimana merepresentasikan modal dari pemilik perusahaan. Neraca dihasilkan dalam kurun periode waktu tertentu yang diinginkan perusahaan. 2. Laporan Laba Rugi Income statement atau laba rugi menghasilkan laporan dimana menjelaskan aset bersih perusahaan yang didapatkan dari transaksi bisnis yaitu pendapatan bagi perusahaan, konsumsi aset bersih yaitu pengeluaran bagi perusahaan dan selisihnya yang disebut net income atau laba bersih. Laporan keuangan merupakan usaha terbaik dari akuntan dalam mengukur performa ekonomi suatu perusahaan untuk periode tertentu. Laba rugi dihasilkan dalam suatu interval waktu tertentu. 3. Laporan Arus Kas Statement of cash flows atau laporan arus kas berisikan jumlah kas yang dihasilkan dan dikonsumsi oleh perusahaan melalui tiga jenis aktivitas diantaranya; operating, investing, dan financing. Laporan arus kas merupakan laporan keuangan yang sangat objektif karena terisolasi dari perkiraan akuntansi dan penilaian yang diperlukan untuk menyiapkan neraca dan laporan laba rugi.
15 Laporan keuangan sendiri bukanlah akhir dalam tujuan pelaporan tetapi dimaksudkan untuk menyediakan informasi yang berguna dalam keputusan bisnis dan ekonomi. Tujuan dari laporan keuangan tidak kekal, tujuan tersebut dipengaruhi oleh lingkungan ekonomi, legal, politik, dan sosial dimana laporan keuangan tersebut mengambil tempat. Tujuan tersebut dijabarkan oleh Stice, Stice, dan Skousen (2007, p. 23) sebagai berikut: 1. Usefulness Tujuan keseluruhan bagi laporan keuangan adalah untuk menyediakan informasi yang berguna dalam pengambilan keputusan. Laporan keuangan harus memberikan informasi yang bermanfaat bagi investor, kreditor serta pengguna lain yang berpotensi untuk melakukan investasi, kredit, dan keputusan serupa lainnya. 2. Understandability Laporan keuangan tidak bisa dan seharusnya tidak disajikan terlalu sederhana untuk dapat dimengerti oleh semua pihak. Sebaliknya, tujuan dari understandability disini adalah untuk menyadari adanya pengguna laporan keuangan yang cukup ahli, yaitu seseorang yang memiliki pemahaman akuntansi dan bisnis serta seseorang yang berkeinginan untuk belajar dan menganalisis informasi yang disajikan. 3. Target audience: investors and creditors Walaupun banyak pengguna potensial atas laporan keuangan, tujuan pelaporan keuangan ditujukan terutama kepada investor dan kreditor. Investor dan kreditor harus bergantung pada suatu batasan dalam informasi yang terdapat pada laporan keuangan periodik dimana disediakan oleh perusahaan. Dengan kata lain, informasi yang bermanfaat bagi investor dan kreditor pada umumnya akan bermanfaat pula bagi pihak eksternal yang lain seperti pelanggan dan pegawai. 4. Assessing future cash flows Secara umum, investor dan kreditor tertarik terutama pada laporan arus kas perusahaan di masa mendatang. Kreditor berharap prinsip bunga dan pinjaman dibayarkan dalam bentuk tunai. Sementara investor mengharapkan dividen kas dan arus kas yang memadai dapat memungkinkan perusahaan untuk bertumbuh secara konsisten. Dengan begitu, laporan keuangan harus
16 menyediakan informasi yang berguna dalam menilai jumlah, waktu serta ketidakpastian atau resiko dari perspektif arus kas dimasa mendatang. 5. Evaluating economic resources Laporan keuangan juga harus menampilkan informasi mengenai aset perusahaan, kewajiban perusahaan dan modal dari pemilik untuk membantu investor dan kreditor serta pengguna lain dalam mengevaluasi kekuatan dan kelemahan financial perusahaan serta likuiditas dan solvabilitas (kemampuan membayar) perusahaan. 6. Primary focus on earnings Informasi mengenai pendapatan perusahaan yang diukur dengan akuntansi akrual, biasanya memberikan dasar peramalan masa depan yang lebih baik dibandingkan dengan informasi mengenai penerimaan kas dan pengeluaran uang tunai saat ini. Jadi, tujuan laporan keuangan ditujukan untuk pengambilan keputusan, khususnya dalam bidang ekonomi, baik dalam kredit maupun investasi. Ketika ada satu atau lebih entitas menjadi entitas anak dari suatu entitas induk, maka dilakukan konsolidasi untuk menyajikan informasi keuangan dari suatu kelompok perusahaan sebagai satu kesatuan ekonomi. Maka dari itu, konsolidasi membawa dua entitas yang sebelumnya terpisah ke dalam pengendalian dengan tim manajemen tunggal. Menurut PSAK No. 4 (Revisi 2009), Laporan keuangan konsolidasi adalah suatu laporan keuangan suatu kelompok usaha yang disajikan sebagai suatu entitas ekonomi tunggal. Penyusunan laporan keuangan konsolidasi disusun dengan mengunakan kebijakan akuntansi yang sama untuk transaksi, peristiwa, dan keadaan yang sama atau sejenis. Tujuan dari pembuatan laporan keuangan konsolidasi menurut Bastian (2005, p. 239), pada umumnya digunakan untuk menyediakan informasi mengenai posisi keuangan, hasil usaha, dan arus kas dari suatu kelompok perusahaan secara keseluruhan. 2.1.4. Rancangan Form Form merupakan sebuah tampilan dimana pengguna berinteraksi dengan sistem atau aplikasi. Tujuan utama dari pembuatan form ini adalah untuk memungkinkan pengguna menjalankan setiap tugas dalam kebutuhan pengguna (user requirement). Pada dasarnya, dalam membangun atau mendesain suatu
17 form, harus berdasarkan keinginan atau kebutuhan dari pengguna sistem. Hal ini dimaksudkan agar pengguna dapat mengetahui tujuan dari form tersebut dan dapat mempermudah pengguna dalam menggunakannya. Menurut Dixit dan Kumar (2007, p. 242), “A form is a business document that contains some predefined data and may include some areas where additional data are to be filled in. An instance of a form is typically based on one database record. Report is a business document that contains only predefined data; it is a passive document used solely for reading or viewing. A report typically contains data from many unrelated records or transactions.” Form merupakan suatu dokumen bisnis yang berisikan data standar yang sudah ditetapkan dan beberapa form juga mengandung area dimana terdapat datadata tambahan yang harus diisi. Sedangkan report adalah dokumen bisnis yang hanya berisikan data standar yang sudah ditetapkan. Report merupakan dokumen yang bersifat pasif dan digunakan hanya untuk membaca atau melihat aspekaspek tertentu. Pada umumnya, isi dari report mengandung data dari beberapa records yang tidak berhubungan sedangkan sebuah form berisikan data hanya dari satu record seperti data tentang seorang pelanggan, sebuah order atau data mengenai seorang karyawan. Sedangkan menurut Goyal (2011, p. 123), tujuan dari melakukan desain terhadap form input data adalah untuk mempermudah dalam melakukan entry data, proses input data menjadi lebih logis, dan tidak ada kesalahan yang mungkin terjadi pada saat proses input data. Adapun beberapa perinsip menurut Fatta (2007, p. 153), yang harus diingat dan beberapa hal yang harus dihindari dalam melakukan pengembangan terhadap form, yaitu: 1. Tampilan yang baik tidak mengharuskan pengguna untuk mengingat tampilan tersebut. 2. Menampilkan apa yang dimengerti oleh pengguna atau visualisasi keadaan dari sistem sekarang. 3. Tidak menampilkan terlalu banyak informasi dan terlalu banyak pilihan. 4. Tidak menampilkan terlalu sedikit informasi, terlalu sedikit pilihan, dan tanpa konteks 5. Tidak mengeksploitasi struktur menu standar yang sudah familiar dengan perangkat lunak yang sering digunakan user.
18 Form yang tercetak dapat diklasifikasikan secara umum berdasarkan peranannya dalam suatu sistem. Berikut adalah klasifikasi form menurut Gupta dan Malik (2005, p. 133). 1. Action form: berfungsi untuk meminta pengguna untuk melakukan aksi untuk mendapatkan hasil. Contoh: Purchase Order Form, Shop Order. 2. Memory form: merupakan record dari data historis yang terdapat di dalam sebuah file, dikeluarkan sebagai acuan, dan berfungsi sebagai kontrol dalam detail kunci. Contoh memory form adalah inventory records, purchase records. 3. Report form: memandu supervisor dan administrator lain dalam kegiatan mereka. Report form menyediakan data dalam sebuah proyek atau pekerjaan. Contoh hasil dari report form adalah laporan laba rugi, laporan analisis penjualan. Menurut Gupta dan Malik (2005, pp. 127-128), sebuah desain form harus fokus terhadap beberapa hal, diantaranya adalah sebagai berikut: 1. Kontrol terhadap jumlah data Desain form yang efektif harus selalu melakukan kontrol terhadap kuantitas dari data yang akan menjadi masukan dalam sistem. Yang perlu diperhatikan dalam mengontrol jumlah data adalah persiapan data dan proses dalam melakukan entry data yang bergantung terhadap user. Selanjutnya adalah dengan mengurangi kebutuhan untuk input, dalam arti analis akan
mempercepat keseluruhan
proses,
mulai dari
proses
penangkapan data sampai data tersebut diproses untuk menyediakan hasil kepada pengguna. 2.
Menghindari penundaan Bottleneck merupakan sebutan bagi penundaan yang terjadi ketika proses penyiapan data sampai melakukan entry data. Menghindari bottleneck ketika melakukan desain form harus selalu menjadi salah satu catatan penting untuk seorang analis.
3.
Menghindari eror pada data Salah satu penyebab eror pada data disebabkan oleh kuantitas dari data. Hal ini dapat dihindari dengan mengurangi volume data yang harus masuk untuk setiap transaksi. Selain itu, desain yang dibuat oleh analis dapat mempengaruhi tingkat eror. Oleh sebab itu, analis harus
19 memperhatikan dan memenuhi semua kriteria yang dibutuhkan dalam membuat sebuah form. 4.
Menghindari tahapan yang berlebihan Tahapan yang berlebihan dapat mempersulit pengguna. Seorang analis harus dapat mengidentifikasi dan membuat semua proses dapat terintegrasi dengan aplikasi lain atau tools lain sehingga dapat dijalankan bersamaan tanpa memperbanyak proses yang harus dilakukan.
5.
Mempertahankan proses yang praktis Yang harus dipahami dan diterapkan dalam mendesain sebuah form yang isinya kompleks dan detail namun harus memberikan tampilan yang mudah dipahami oleh pengguna. Dengan adanya tampilan yang mudah dipahami, maka pengguna merasa nyaman dalam menggunakannya. Selain itu, analis harus mampu untuk menyediakan kontrol terhadap masalahmasalah yang mungkin terjadi pada saat penggunaan form tersebut. Dengan begitu, maka pengguna dapat menghindari kerumitan, karena telah disediakan berbagai alternatif yang dapat membantu mereka.
2.2. Teori Khusus 2.2.1. Cognos TM1 Cognos TM1 merupakan sebuah tools untuk mempermudah perusahaan dalam melakukan perencanaan, penganggaran, peramalan, analisis, dan sebuah perangkat lunak untuk melakukan scorecarding. Balance scorecard adalah sebuah konsep untuk melakukan pengukuran terhadap aktivitas-aktivitas operasional pada sebuah perusahaan atau organisasi, baik dalam skala besar maupun kecil, yang sejalan dengan sasaran yang lebih besar dalam hal visi dan strategi perusahaan itu sendiri. Pada awalnya, balance scorecard ditujukan untuk mengatasi berbagai masalah yang berfokus terhadap aspek keuangan. Dengan adanya balance scorecard yang terintegrasi dan kemampuan manajemen strategi, maka perusahaan dapat memantau metrik kinerja dan menyelaraskan sumber daya yang ada dengan tujuan dari perusahaan atau organisasi sesuai dengan keadaan yang berlangsung saat ini maupun kedepan. Cognos TM1 digunakan juga sebagai tools untuk mempermudah proses konsolidasi. Sebagai contoh, konsolidasi laporan keuangan dari anak perusahaan
20 kepada induknya. Tujuan dari akun konsolidasi pada sebuah entitas ekonomi menurut Dagwell, Wines, & Lambert (2007, p. 247) adalah untuk memungkinkan pengguna tujuan umum dari laporan keuangan untuk menilai performa, posisi keuangan, serta melakukan pembiayaan dan investasi pada entitas ekonomi atau anak perusahaan, daripada hanya mengandalkan akun individual untuk melakukan back-up terhadap anak perusahaan. Dengan Cognos TM1, perusahaan dapat menganalisis data, membuat modelmodel bisnis seperti model keuntungan atau profitability model, yang digunakan untuk mencerminkan lingkungan bisnis kedepan yang semakin berkembang. Adapun keunggulan-keunggulan lain dari Cognos TM1 adalah sebagai berikut: 1. Perencanaan dan analisis yang kuat Membuat dan melakukan analisis rencana yang baik, mengenai anggaran, dan perkiraan di masa yang akan datang. 2. Integrasi scorecard dan strategi manajemen Dengan adanya hasil dari scorecard yang terintegrasi, maka perusahaan dapat menentukan strategi perusahaan kedepan dan menjadikan hasil dari scorecard tersebut sebagai acuan untuk memprediksi kemungkinankemungkinan yang akan terjadi selanjutnya. Scorecard juga dapat menjadi acuan untuk memastikan bahwa rencana yang strategis dan manajemen pengukuran yang tepat dapat menyelaraskan modal dengan peluang bisnis yang ada. 3. Model yang fleksibel Dapat mengembangkan dan menggunakan perencanaan, mulai dari yang mudah sampai yang rumit dan melakukan analisis model berdasarkan lingkungan yang sedang terjadi saat ini. Model yang fleksibel juga membantu organisasi dalam melakukan pemantauan metrik kinerja untuk satu atau lebih perencanaan setiap server dari satu panel kontrol. 4. Keterlibatan dengan banyak pengguna Pengguna di keseluruhan organisasi dapat terlibat dalam perencanaan serta partisipasi dan kolaborasi yang tinggi akan memberikan pengetahuan yang lebih bagi perusahaan. Pengguna dapat memeriksa status rencana dan memasukkan dan mengirimkan rencana-rencana kedepan dengan mudah, dan manajer dapat memberikan kontribusi dengan meninjau, menyetujui, atau menolak dari jarak jauh.
21 5. Berbasis Cloud (Pilihan) Menyediakan semua solusi fungsi dengan berbasis cloud yang dapat diakses dengan menggunakan interface IBM Concert.
2.2.2. Authorization Test Authorization menurut Kim dan Salomon (2012, p. 32) merupakan proses pemberian hak untuk menggunakan asset teknologi informasi, sistem, aplikasi, dan data perusahaan kepada user yang spesifik. Langkah pertama untuk mengontrol akses adalah dengan membuat kebijakan untuk mendefinisikan aturan authorization. Authorization adalah proses dalam menentukan seseorang yang memiliki akses terhadap suatu komputer dan sumber daya jaringan. Pada umumnya authorization dibuat berdasarkan job rules, background screening, dan berbagai kebutuhan pemerintahan. Pengujian terhadap authorization bertujuan untuk memastikan apakah user dapat masuk ke dalam sistem dan apakah telah ada pembagian tugas atau bagian apa saja yang dapat diakses oleh user-user tertentu (adanya pembatasan bagi useruser tertentu, terutama hal yang menyangkut hal vital bagi perusahaan, contohnya penggajian, keuangan di mana hal tersebut tidak dapat diakses oleh sembarang orang). Hal itu merupakan suatu bagian penting yang harus diuji oleh tim proyek sebelum sistem tersebut go-live. Masalah siapa saja user yang berhak dan tidak berhak untuk mengakses data-data tertentu, tim proyek menyerahkan masalah tersebut kepada klien saat pertama kali sistem baru dibuat. Klien dapat mendiskusikan hal tersebut dengan tim proyek mengenai hal-hal apa saja yang lebih baik dibatasi aksesnya. Setelah mendapat daftar tetap mengenai apa saja yang boleh diakses oleh tiap-tiap user, tim proyek mengatur hal tersebut dalam sistem pada saat building. Untuk menguji apakah hal tersebut telah masuk ke dalam sistem secara benar, diperlukan adanya authorization testing. Authorization testing dilakukan pada saat structural testing dan unit testing. Authorization testing dilakukan pada saat sistem telah selesai dibuat dan sebelum diberikan kepada user untuk digunakan (go-live). Hal ini dilakukan agar apa yang diuji dalam authorization testing adalah apa yang akan diberikan kepada klien. Maksudnya adalah agar sistem yang diuji sudah benar-benar selesai dan tinggal melakukan pengujian saja. Berikut ini adalah tabel menurut (Perry W. E., 2006) :
22
Tabel 2. 1 Authorization Test Factor Test Factor
Authorization
Stress Execution Recovery Structural Testing
Operations Compliance Security
X
Requirements
X
Regression Error Handling Functional
Manual
Testing
Support Intersystems Control Parallel
Unit Testing
X
Dalam melakukan pengujian, terutama pengujian mengenai authorization, ada beberapa keprihatinan yang harus diperhatikan. Menurut (Perry W. E., 2006), hal-hal yang perlu diperhatikan adalah:
Tabel 2. 2 Testing Concenrns Matrix Test Factor
Authorization
Requirements
Authorization rules defined
Design
Authorization rules designed
Program
Authorization rules implemented
Test
Compliance testing
Operation
Data changes during installation prohibited
Maintenance
Preserve authorization rules
23 2.2.3. User Acceptance Test Dalam membangun suatu sistem, penting bagi tim proyek untuk mengetahui apakah sistem yang mereka buat atau kembangkan telah sesuai dengan apa yang diharapkan oleh klien. Untuk mengetahui hal tersebut, tim proyek harus melakukan uji coba testing dengan mengacu pada harapan klien. Harapan klien untuk suatu sistem biasanya ditetapkan di awal pengerjaan atau pembuatan dari suatu sistem. Harapan – harapan yang telah ditetapkan ini merupakan tolak ukur yang membuat tim proyek mengetahui apa saja yang masih kurang dari suatu sistem yang dibuat itu. Menurut Pulusuri (2008, p. 62), user acceptance test dilakukan untuk memeriksa apakah produk perangkat lunak sudah siap untuk digunakan oleh customer. Pengujian ini dikatakan selesai apabila telah dilakukan oleh user yang bersangkutan. Sebelum melakukan pengujian ini, developer harus menyediakan sebuah test case yang menunjukkan kualitas dan penerimaan sebuah produk. User acceptance test ini dibuat sebagai sebuah skenario nyata melalui validasi aspek fungsionalitas maupun non-fungsionalitas dari produk perangkat lunak. Adapun definisi user acceptance dari Naik dan Tripathy (2008) adalah kegiatan yang dilakukan atau direalisasi oleh pihak klien untuk memastikan bahwa sistem memenuhi kriteria yang tertera pada kontrak atau perjanjian sebelum pihak klien melakukan sign off yang menyatakan bahwa sistem sudah sesuai dengan kriteria yang diinginkan oleh pihak klien. Menurut Perry (2006), acceptance test juga dilakukan sebagai pengujian formal yang dilakukan untuk menentukan bahwa sebuah sistem perangkat lunak telah memenuhi kriteria dan untuk memungkinkan klien untuk menerima sistem. Menurut Roberta M. Roth, Alan Dennis dan Barbara Haley Wixom (2013, pp. 453-454), acceptance testing dibagi menjadi 2 tahap yaitu alpha testing dan beta testing. Perbedaan dari kedua testing ini terletak pada data yang digunakan saat pengujian. Alpha testing menggunakan data buatan (dummy) sedangkan beta testing menggunakan data asli (real). Pada umumnya, acceptance testing yang digunakan adalah alpha testing di mana pengujian dilakukan oleh user sendiri untuk memastikan mereka menyetujui sistem tersebut. Pengujian dengan menggunakan alpha testing bersumber dari system tests yang telah dilakukan sebelumnya. Pengujian dengan alpha testing bertujuan untuk menjamin bahwa user telah menyetujui sistem tersebut. Sedangkan beta testing
24 dilakukan jika sistem tersebut bersifat penting, di mana user terus memantau sistem bila terdapat eror atau peningkatan yang bermanfaat. Acceptance testing sangat penting peranannya bagi keberhasilan sistem. Hal ini disebabkan karena sudut pandang pertama yang dibayangkan oleh user yaitu ketika mereka pertama kali mencoba sistem tersebut, yaitu pada saat acceptance testing itu. Oleh karena itu, acceptance testing ini harus dilaksanakan dengan sebaik-baiknya dan harus melalui system testing yang sukses terlebih dahulu. Menurut William E. Lewis (2009, p. xiii), tahapan di dalam acceptance testing di bagi menjadi 4 tahap, yaitu : 1.
Melengkapi acceptance test planning.
2.
Melengkapi acceptance test case.
3.
Meninjau kembali atau menyetujui acceptance test plan.
4.
Melaksanakan acceptance test.
Pada tahap pertama yaitu melengkapi acceptance test planning, tim proyek membuat terlebih dahulu rencana acceptance test yang akan dijalankan. Apa saja yang akan dilakukan pada saat acceptance test, semua dijabarkan secara lengkap. Pada tahap kedua yaitu melengkapi acceptance test case, disini tim proyek menjelaskan mengenai urutan tahapan-tahapan yang akan di lakukan didalam acceptance test. Langkah apa yang harus dilakukan setelah tahapan sebelumnya selesai. Semua terhubung menjadi suatu test case yang dapat mempermudah tim proyek dalam melakukan acceptance test. Kegiatan yang dilakukan pada tahap ketiga yaitu meninjau kembali atau menyetujui acceptance test plan. Pada tahap ini, project leader akan meninjau terlebih dahulu tahapan-tahapan yang telah disusun oleh tim proyek agar diketahui apakah acceptance test tersebut telah sesuai dan cocok dengan sistem yang yang akan diuji. Bila belum sesuai, project leader akan mengembalikan rencana tersebut kepada tim proyek untuk diperbaiki atau diulang penyusunannya. Namun, bila rencana tersebut telah sesuai maka project leader akan menyetujui rencana tersebut sehingga tim proyek dapat melanjutkan ke tahap selanjutnya. Pada tahap keempat atau tahap terakhir, tim proyek akan melaksanakan acceptance test yang telah disetujui oleh project leader. Acceptance test ini turut mengikutsertakan user sebagai pengguna sistem untuk menguji sistem tersebut. Hal itu disebabkan karena acceptance test ini bertujuan untuk mengetahui apakah
25 sistem yang dibuat ini telah memenuhi ekspektasi yang diharapkan oleh user tersebut. Mengenai data yang akan digunakan dalam acceptance test ini, akan bergantung pada jenis acceptance test apa yang digunakan. Bila sedang melakukan alpha test, maka data yang digunakan adalah data dummy. Sedangkan bila sedang melakukan beta test, maka data yang akan digunakan adalah data real. Kriteria dari acceptance test ini adalah untuk menjaga kestabilan produk saat produk tersebut dirilis, menunjukkan keuntungan-keuntungan dari produk perangkat lunak saat diberikan kepada klien, dan memastikan bahwa produk perangkat lunak tersebut sudah sesuai dengan kriteria atau requirement yang diinginkan oleh pihak klien. Acceptance testing di desain untuk menentukan apakah perangkat lunak yang menjadi objek untuk melakukan pengujian telah sesuai dengan kriteria sehinga dapat digunakan oleh klien. Pengujian yang terpusat pada struktur dan kriteria juga dapat gagal dalam pengukuran terhadap kecocokan dari klien, dan dengan demikian gagal juga untuk melakukan pengujian terhadap value dari aplikasi otomatis untuk bisnis. Untuk memenuhi kecocokan tersebut, ada empat kriteria menurut Perry (2006, p. 492), yaitu: 1.
Data Data tersebut harus andal atau terpercaya, mempunyai ketepatan waktu, konsistensi yang tinggi, dan kegunaan data yang akan digunakan dalam aplikasi otomatis.
2.
People Keterlibatan people, dalam hal ini adalah tester dan juga klien yang mengikuti kegiatan pengujian menjadi point yang penting, dan juga sebagai unsur dari proses pengujian. Pengetahuan dan keahlian dari people sangat dibutuhkan untuk mendukung proses ini. Setelah melakukan proses pengujian, kegiatan pelatihan juga dilakukan sebagai pendukung agar klien dapat menggunakan produk yang telah dibuat sesuai dengan prosedur dan proses bisnisnya.
3.
Structure Melakukan pengembangan yang tepat dari sistem aplikasi untuk mengoptimalkan teknologi dan memenuhi kriteria dari klien.
4.
Rules
26 Prosedur harus diikuti sesuai dalam pengolahan data. Dengan adanya prosedur, maka proses pengujian akan berjalan dengan lebih terstruktur. Dalam melakukan user acceptance test, ada beberapa kegiatan dan peran yang akan dilakukan, diantaranya adalah sebagai berikut: 1.
Klien, selaku orang yang dapat menentukan keberhasilan dari user acceptance test, harus terlibat dan melakukan acceptance test.
2.
Project manager harus berpartisipasi selama proses acceptance test dengan klien (jika diperlukan).
3.
Tim development harus menyelesaikan bugs dari laporan yang diberikan oleh pihak klien.
4.
Mendapatkan customer sign off.
5.
Memberikan pelatihan kepada klien (jika pelatihan merupakan komponen perjanjian kerja).
6.
Memperbarui project data collection sheet.
2.2.4. System Development Life Cycle Untuk membangun suatu sistem dibutuhkan adanya tahapan-tahapan yang jelas dan terperinci mengenai apa saja yang harus dilakukan agar sistem tersebut dapat berjalan sesuai dengan tujuan yang telah ditentukan sebelumnya. Tanpa adanya tahapan yang jelas mengenai apa yang harus dilakukan, suatu sistem tidak akan dapat selesai dengan hasil yang telah diharapkan. Selain itu, proses pengerjaan sistem akan berputar-putar dan mungkin akan memakan waktu yang lebih banyak daripada proses yang telah memiliki tahapan yang jelas. Oleh karena itu, dibutuhkan adanya suatu pedoman yang memuat tahapantahapan yang dapat dijadikan standar untuk menentukan tahapan-tahapan apa saja yang perlu diambil untuk membuat suatu sistem agar tujuan dibuatnya sistem tersebut dapat tercapai dengan sebaik-baiknya. Pengertian System Development Life Cycle (SDLC) menurut Joshua Boyde dan Steven Lipke (2012, p. 49) adalah “System/Software Development Life Cycle (SDLC) – is a project life cycle that is tailored specifically towards the creation, alteration, and maintenance of software applications, hardware platforms and information technology systems.”
27 Berdasarkan pengertian tersebut, System Development Life Cycle (SDLC) adalah suatu life cycle yang memfokuskan diri pada sistem. Mulai dari proses pembuatan, perubahan, dan pemeliharaan suatu sistem sehingga sangat cocok untuk menjadi pedoman dalam membuat suatu sistem. Untuk memahami lebih lanjut mengenai System Development Life Cycle (SDLC), kita harus paham terlebih dahulu mengenai tahap-tahap yang diperlukan dalam SDLC. Beberapa orang menulis bahwa tahap SDLC dibagi menjadi 5 tahap, namun tidak sedikit orang yang menjabarkan tahap-tahap tersebut menjadi 7 tahap. Menurut Kenneth dan Julie (2014, p. 32), mereka membagi SDLC menjadi 7 tahap atau phase, yaitu: 1.
Identifying problems, opportunities, and objectives.
2.
Determining human information requirements.
3.
Analyzing system needs.
4.
Designing the recommended system.
5.
Developing and documenting software.
6.
Testing and maintaining the system.
7.
Implementing and evaluating the system.
Gambar 2.2 Tahapan dalam System Development Life Cycle (SDLC) Sumber: (System Analysis and Design, 2014)
28 Walaupun ketujuh tahapan tersebut terlihat seperti berdiri sendiri, namun beberapa aktivitas dapat mulai bersamaan dan bisa di ulang. 1.
Identifying Problems, Opportunities, and Objectives. Tahap ini merupakan tahap pendahuluan untuk membuat sebuah sistem. Tahap yang sangat critical dimana users, analis dan system managers harus bekerja sama menentukan terlebih dahulu apa saja masalah, peluang, dan tujuan yang ingin dicapai dalam membuat sistem tersebut. Analis harus berhati-hati dalam tahap ini agar mereka tidak perlu mengulang kembali ke awal bila terjadi masalah atau jika apa yang telah mereka tentukan sebelumnya (contohnya tujuan yang ingin dicapai) kurang tepat. Hal itu tentu tidak diinginkan oleh semua anggota tim proyek dan sebaik mungkin harus dihindari. Tujuan, masalah dan peluang yang akan timbul dalam suatu sistem saling berkaitan satu sama lain. Dengan ditentukannya tujuan yang ingin dicapai oleh dibuatnya suatu sistem, seorang analis dapat menyimpulkan apakah masalah dan peluang yang dimiliki oleh sistem itu dapat mendukung tercapainya tujuan tersebut. Selain itu, tahap ini merupakan tahap yang penting dimana manajemen dapat memutuskan apakah proyek ini akan berlanjut atau tidak. Banyak faktor yang dapat memicu suatu proyek sistem tidak dilanjutkan lagi, salah satunya karena tujuan yang ingin di capai oleh perusahaan ternyata belum membutuhkan peranan dari sistem tersebut atau jika dana yang dimiliki oleh klien ternyata terbatas dan tidak dapat mencukupi untuk terus melanjutkan pembuatan sistem tersebut.
2.
Determining Human Information Requirements Pada tahapan ini, analis akan mencari tahu apa saja yang dibutuhkan oleh user agar dapat menggunakan sistem yang akan dikembangkan ini dengan sebaik-baiknya. Bagaimana sistem tersebut dapat mendukung pekerjaan klien, apa yang user butuhkan dari suatu sistem, apa batasan yang dimiliki oleh user dan sebagainya.
3.
Analyzing System Needs Dalam tahapan ini, analis melakukan analisis atas apa saja kebutuhan sistem yang diperlukan untuk menyelesaikan masalah. Dengan diketahuinya kebutuhan yang diperlukan oleh sistem, analis
29 dapat membuat proposal rekomendasi apa saja yang perlu dilakukan terhadap sistem tersebut. 4.
Designing the Recommended System Bila proposal rekomendasi itu disetujui oleh manajemen, analis akan mendesain sistem sesuai dengan apa yang telah disetujui. Mulai dari desain tampilan sampai desain databasenya.
5.
Developing and Documenting Software Dalam tahapan ini, analis akan bekerja sama dengan programmer
untuk
mendokumentasikan
sistem.
Analis
harus
mendokumentasikan mulai dari bagaimana cara menggunakan sistem sampai kegunaan dari sistem tersebut. Hal itu bertujuan untuk memudahkan klien dalam memahami lebih jauh tentang sistem tersebut dan dapat menggunakannya dengan semaksimal mungkin. 6.
Testing and Maintaining the System Dalam tahapan ini, tim proyek yaitu analis dan programmer akan melakukan uji coba atau testing terhadap sistem sebelum diserahkan kepada klien. Uji coba itu berguna untuk mencari kesalahan
yang
mungkin
masih
ada
didalam
sistem
dan
memperbaikinya. Untuk pertama kali, mereka akan menggunakan data dummy dalam proses uji coba baru setelah itu menggunakan data aktual dari klien. 7.
Implementing and Evaluating the System Pada tahap terakhir dalam sistem SDLC ini, analis memiliki peran serta untuk membantu mengimplementasikan sistem informasi sistem. Pada tahapan ini, akan ada training yang dilakukan oleh user yang bertujuan agar dapat lebih memahami sistem tersebut. Segala macam kesalahan yang mungkin timbul dalam tahapan ini akan menjadi tanggung jawab analis. Selain implementasi, dalam tahapan ini ada juga evaluasi yang bertujuan untuk melihat kembali apakah sistem yang telah dibuat ini masih memiliki kendala dan apakah sistem ini telah memenuhi tujuan yang diinginkan oleh klien.
30
