9 2.1 Sistem Informasi
2.1.1 Pengertian Sistem
Menurut William dan Sawyer (2010: 492), sebuah sistem didefinisikan sebagai sekumpulan komponen yang terhubung yang berinteraksi untuk mengerjakan suatu tugas agar dapat menyelesaikan suatu tujuan.
Dull, Gelinas dan Wheeler (2012: 11) menyatakan bahwa “Suatu sistem adalah sekumpulan elemen-elemen yang saling terhubung yang bersama-sama menyelesaikan tujuan-tujuan tertentu.”
Sehingga sistem dapat diartikan sebagai kumpulan beberapa komponen yang berhubungan yang berinteraksi bersama dalam menyelesaikan suatu tujuan tertentu.
2.1.2 Pengertian Informasi
Menurut Yogaswara (2010: 66), informasi dapat didefinisikan sebagai suatu data yang diolah menjadi bentuk yang lebih berguna dan lebih berarti bagi yang menerimanya.
Hall (2013: 9) menyatakan bahwa “Informasi bukan hanya sekumpulan fakta-fakta yang telah diolah yang disusun di dalam suatu laporan. Informasi memicu para pengguna untuk mengambil tindakan yang mendukung tugas-tugas bisnis harian mereka, menyelesaikan permasalahan, dan membuat perencanaan untuk masa mendatang.”
Sehingga informasi dapat diartikan sebagai sekumpulan fakta atau data yang diolah menjadi bentuk yang lebih berguna bagi para penggunanya yang dapat digunakan untuk mendukung tugas-tugas bisnis, menyelesaikan masalah dan membuat perencanaan untuk masa mendatang.
2.1.3 Karakteristik Informasi
Hall (2013: 12) mengatakan bahwa informasi yang berguna memiliki karakteristik sebagai berikut:
1. Relevan (Relevance)
Isi dari suatu laporan atau dokumen harus melayani suatu tujuan seperti untuk mendukung keputusan manajer atau tugas karyawan.
2. Ketepatan Waktu (Timeliness)
Informasi tidak boleh berumur lebih tua dari batasan waktu tindakan yang didukungnya.
3. Keakuratan (Accuracy)
Informasi harus bebas dari kesalahan yang material. 4. Kelengkapan (Completeness)
Tidak boleh ada bagian yang hilang dari informasi yang digunakan untuk suatu keputusan atau tugas.
5. Rangkuman (Summarization)
Informasi harus dikumpulkan sesuai dengan kebutuhan pengguna.
2.1.4 Pengertian Sistem Informasi
Menurut Dull, Gelinas dan Wheeler (2012: 12) sistem informasi adalah sistem buatan manusia yang secara umum terdiri dari sekumpulan komponen berbasis komputer dan komponen manual terintegrasi yang ditetapkan untuk mengumpulkan, menyimpan, dan mengelola data serta untuk menyediakan informasi keluaran bagi pengguna.”
Satzinger, Jackson dan Burd (2012: 4) menyatakan bahwa “Sistem informasi adalah sekumpulan komponen komputer terkait yang mengumpulkan, memproses, menyimpan (biasanya di dalam suatu basis data), dan menyediakan hasil informasi yang dibutuhkan untuk menyelesaikan tugas-tugas bisnis.”
Sehingga sistem informasi dapat diartikan sebagai sekumpulan komponen baik berbasis komputer ataupun manual yang terintegrasi yang digunakan untuk mengumpulkan, memproses, menyimpan (di dalam basis data), dan menghasilkan suatu keluaran berupa informasi yang dapat digunakan untuk menyelesaikan tugas-tugas bisnis.
2.1.5 Jenis-Jenis Sistem Informasi
Bodnar dan Hopwood (2010: 3) membedakan sistem informasi menjadi enam jenis, yaitu:
1. Electronic data processing system (EDP) adalah penggunaan teknologi informasi untuk menjalankan pemrosesan data berorientasi transaksi di suatu organisasi.
2. Management information system (MIS) menggambarkan penggunaan
teknologi informasi untuk menyediakan informasi berorientasi keputusan untuk para manajer.
3. Di dalam decision support system (DDS), data diproses ke dalam suatu format pengambilan keputusan untuk pengguna akhir.
4. Suatu expert system (ES) adalah sistem informasi berbasis pengetahuan yang menggunakan pengetahuan mengenai suatu aplikasi tertentu untuk bertindak sebagai konsultan ahli bagi pengguna akhir.
5. Suatu executive information system (EIS) disesuaikan untuk kebutuhan informasi strategis bagi manajemen tingkat atas.
6. Accounting information system (AIS) didefinisikan sebagai sistem
berbasis komputer yang dirancang untuk mengubah data akuntansi menjadi informasi.
2.2 Sistem Informasi Akuntansi
2.2.1 Pengertian Sistem Informasi Akuntansi
Dull, Gelinas dan Wheeler (2012: 14) menyatakan bahwa “Sistem informasi akuntansi adalah subsistem khusus dari sistem informasi yang memiliki tujuan untuk mengumpulkan, memproses dan melaporkan informasi yang terkait dengan aspek keuangan di dalam kejadian bisnis.”
Menurut Hall (2013: 6), subsistem sistem informasi akuntansi memproses transaksi keuangan dan transaksi non keuangan yang secara langsung mempengaruhi pemrosesan transaksi keuangan.
Sehingga sistem informasi akuntansi dapat diartikan sebagai subsistem dari sistem informasi yang mengumpulkan, memproses transaksi keuangan dan non keuangan yang secara langsung mempengaruhi pemrosesan transaksi keuangan serta melaporkan informasi yang terkait dengan aspek keuangan di dalam kejadian bisnis.
2.2.2 Siklus Transaksi Pada Sistem Informasi Akuntansi
Considine, Parkes, Olesen, Blount dan Speer (2012: 25), membagi siklus transaksi dalam akuntansi menjadi lima siklus, yaitu:
1. Siklus Pendapatan (Revenue Cycle)
Siklus pendapatan adalah pusat untuk kemampuan organisasi dalam menghasilkan kas. Kegiatan dari siklus ini mencakup penerimaan pesanan pelanggan, memeriksa catatan kredit pelanggan yang terdahulu, menyetujui penjualan, pengepakan dan pengiriman barang ke pelanggan, mengirimkan tagihan ke pelanggan dan menerima kas dari pelanggan. 2. Siklus Pengeluaran (Expenditure Cycle)
Siklus pengeluaran merupakan pusat dari aktivitas pembelian organisasai dan bertujuan untuk memperoleh barang dari pemasok untuk memenuhi permintaan pelanggan. Siklus ini juga menangani pembayaran untuk pembelian tersebut.
3. Siklus Produksi (Production Cycle)
Siklus produksi merupakan siklus penting di dalam organisasi manufaktur. Siklus ini bertanggung jawab atas pengelolaan bahan mentah, berkaitan dengan produksi barang jadi, menjadwalkan produksi untuk memastikan stok yang cukup tersedia dan memastikan bahwa penetapan biaya untuk proses manufaktur dilakukan.
4. Siklus Manajemen Sumber Daya dan Penggajian (HR Management and Payroll Cycle)
Siklus ini bertanggung jawab dalam memperoleh pelayanan-pelayanan yang dilakukan oleh karyawan, mengelola karyawan dan membayar upah serta berurusan dengan situasi dimana karyawan meninggalkan organisasi.
5. Siklus Buku Besar dan Pelaporan Keuangan (General Ledger and Financial Reporting Cycle)
Siklus ini merupakan puncak dari siklus-siklus lainnya di dalam organisasi dan melingkupi pemeliharaan catatan-catatan akuntansi organisasi. Siklus ini menerima jumlah data yang banyak dari pembayaran dan siklus pendapatan, dimana siklus ini biasanya menyiapkan dan mengubah jurnal dan akun buku besar.
2.3 Akuntansi Pemerintahan
2.3.1 Undang-Undang Nomor 17 Tahun 2003 tentang Keuangan Negara Undang-Undang Nomor 17 Tahun 2003 tentang Keuangan Negara dalam Pasal 32 mengamanatkan bahwa bentuk dan isi laporan pertanggungjawaban pelaksanaan APBN/APBD disusun dan disajikan sesuai dengan Standar Akuntansi Pemerintahan.
2.3.2 Standar Akuntansi Pemerintahan
Berdasarkan Peraturan Pemerintah No. 71 Tahun 2010 sebagai pengganti Peraturan Pemerintah No. 24 Tahun 2005 tentang Standar Akuntansi Pemerintahan, Standar Akuntansi Pemerintahan, yang selanjutnya disingkat SAP, adalah prinsip-prinsip akuntansi yang diterapkan dalam menyusun dan menyajikan laporan keuangan pemerintah.
2.3.3 Anggaran Pendapatan dan Belanja Negara
Berdasarkan Undang-Undang Republik Indonesia Nomor 27 Tahun 2014 tentang Anggaran Pendapatan dan Belanja Negara Tahun Anggaran 2015, anggaran pendapatan dan belanja negara, yang selanjutnya disingkat APBN, adalah rencana keuangan tahunan pemerintahan Negara yang disetujui oleh Dewan Perwakilan Rakyat.
2.3.4 Rencana Kerja dan Anggaran Kementrian Negara / Lembaga
Berdasarkan Peraturan Menteri Keuangan Republik Indonesia Nomor 136/PMK.02/2014 tentang Petunjuk Penyusunan dan Penelaahan Rencana Kerja dan Anggaran Kementrian Negara / Lembaga, rencana kerja dan anggaran Kementrian Negara / lembaga yang selanjutnya disingkat RKA-K/L adalah dokumen rencana keuangan tahunan Kementrian / Lembaga yang disusun menurut bagian anggaran Kementrian / Lembaga.
2.3.5 Daftar Isian Pelaksanaan Anggaran
Berdasarkan Peraturan Menteri Keuangan Republik Indonesia Nomor 171/PMK.02/2013 tentang Petunjuk Penyusunan dan Pengesahan Daftar Isian Pelaksanaan Anggaran, daftar isian pelaksanaan anggaran yang
selanjutnya disingkat DIPA adalah dokumen pelaksanaan anggaran yang disusun oleh Pengguna Anggaran / Kuasa Pengguna Anggaran.
2.3.6 Pengguna Anggaran / Kuasa Pengguna Anggaran
Berdasarkan Peraturan Menteri Keuangan Republik Indonesia Nomor 171/PMK.02/2013 tentang Petunjuk Penyusunan dan Pengesahan Daftar Isian Pelaksanaan Anggaran, pengguna anggaran yang selanjutnya disingkat PA adalah pejabat pemegang kewenangan penggunaan anggaran Kementrian Negara / Lembaga.
Kuasa pengguna anggaran yang selanjutnya disingkat KPA adalah pejabat yang memperoleh kuasa dari PA untuk melaksanakan sebagian kewenangan dan tanggung jawab penggunaan anggaran pada Kementrian Negara / Lembaga yang bersangkutan.
2.3.7 Belanja Modal dan Belanja Modal Jalan, Irigasi dan Jaringan
Berdasarkan Peraturan Menteri Keuangan Nomor 101/PMK.02/2011 tentang Klasifikasi Anggaran, belanja modal adalah pengeluaran untuk pembayaran perolehan aset dan/atau menambah nilai aset tetap/aset lainnya yang memberi manfaat lebih dari satu periode akuntansi dan melebihi batas minimal kapitalisasi aset tetap/aset lainnya yang ditetapkan pemerintah.
Belanja modal jalan, irigasi dan jaringan adalah pengeluaran untuk memperoleh jalan dan jembatan, irigasi dan jaringan sampai siap pakai meliputi biaya perolehan atau biaya konstruksi dan biaya-biaya lain yang dikeluarkan sampai jalan dan jembatan, irigasi dan jaringan tersebut siap pakai. Dalam belanja ini termasuk biaya untuk penambahan dan penggantian yang meningkatkan masa manfaat, menambah nilai aset, dan di atas batas minimal nilai kapitalisasi jalan dan jembatan, irigasi dan jaringan.
2.3.8 Standar Jurnal Pencatatan atas Belanja Modal
Berikut adalah standar jurnal yang digunakan di dalam pencatatan belanja modal dan konstruksi dalam pengerjaan berdasarkan Peraturan Pemerintah No. 71 Tahun 2010 sebagai pengganti Peraturan Pemerintah No. 24 Tahun 2005 tentang Standar Akuntansi Pemerintahan.
1) Belanja modal jaringan:
Belanja Modal Jaringan xxxxx
Piutang KUN xxxxx
2) Perolehan aset tetap (Korolari Entry):
Jaringan Sebelum Disesuaikan xxxxx
Diivestasikan dalam Aset Tetap xxxxx 3) Konstruksi dalam pengerjaan:
Konstruksi dalam Pengerjaan xxxxx
Diivenstasikan dalam Aset Tetap xxxxx 4) Setelah dilakukan penyelesaian dan telah diserahterimakan:
Diinvestasikan dalam Aset Tetap xxxxx
Konstruksi dalam Pengerjaan xxxxx
Aset Tetap xxxxx
Diivestasikan dalam Aset Tetap xxxxx 5) Penyusutan jaringan:
Diinvestasikan dalam Aset Tetap xxxxx
Akumulasi Penyusutan Jaringan xxxxx 6) Transaksi mutasi barang milik Negara:
Jalan, Irigasi dan Jaringan untuk
diserahkan kepada Masyarakat xxxxx
Cadangan Persediaan xxxxx
2.3.9 Konstruksi Dalam Pengerjaan
Berdasarkan PSAP No. 08 mengenai Akuntansi Konstruksi Dalam Pengerjaan, Konstruksi Dalam Pengerjaan adalah aset-aset yang sedang dalam proses pembangunan.
2.3.10 Laporan Realisasi Anggaran
Berdasarkan PSAP No. 02 mengenai Laporan Realisasi Anggaran, Laporan Realisasi Anggaran (LRA) merupakan salah satu komponen laporan keuangan pemerintah yang menyajikan informasi tentang realisasi dan anggaran entitas pelaporan secara tersanding atas suatu periode tertentu.
2.4 Pajak
2.4.1 Pajak Pertambahan Nilai
Berdasarkan buku karangan Mardiasmo (2011: 273) pajak pertambahan nilai (PPN) didefinisikan sebagai pajak tidak langsung dan dikenakan atas konsumsi dalam negeri. Undang-undang yang mengatur pengenaan Pajak Pertambahan Nilai (PPN) adalah Undang-Undang Nomor 8 Tahun 1983 tentang Pajak Pertambahan Nilai Barang dan Jasa dan Pajak Penjualan atas Barang Mewah sebagaimana telah beberapa kali diubah terakhir dengan Undang-Undang Nomor 42 Tahun 2009. Undang-undang ini disebut Undang-Undang Pajak Pertambahan Nilai 1984 (Mardiasmo, 2011: 274). Mardiasmo (2011: 274-286) menyebutkan beberapa hal yang berkaitan dengan pajak pertambahan nilai, yaitu:
1. Daerah Pabean adalah wilayah Republik Indonesia yang meliputi wilayah darat, perairan, dan ruang udara di atasnya, serta tempat-tempat tertentu di Zona Ekonomi Eksklusif dan landas kontinen yang ada di dalamnya berlaku Undang-Undang yang mengatur mengenai kepabeanan.
2. Impor adalah setiap kegiatan memasukkan barang dari luar Daerah Pabean ke dalam Daerah Pabean.
3. Pajak Masukan adalah Pajak Pertambahan Nilai yang seharusnya sudah dibayar oleh Pengusaha Kena Pajak karena perolehan Barang Kena Pajak dan/atau perolehan Jasa Kena Pajak dan/atau pemanfaatan Barang Kena Pajak Tidak Berwujud dari luar Daerah Pabean dan/atau pemanfaatan Jasa Kena Pajak dari luar Daerah Pabean dan/atau impor Barang Kena Pajak.
4. Barang Kena Pajak adalah barang yang dikenai pajak berdasarkan Undang-Undang PPN 1984.
5. Pengusaha adalah orang pribadi atau badan dalam bentuk apa pun yang dalam kegiatan usaha atau pekerjaannya menghasilkan barang, mengimpor barang, mengekspor barang, melakukan usaha perdagangan, memanfaatkan barang tidak berwujud dari luar Daerah Pabean, melakukan usaha jasa termasuk mengekspor jasa, atau memanfaatkan jasa dari luar Daerah Pabean.
6. Pengusaha Kena Pajak (PKP) adalah Pengusaha yang melakukan penyerahan Barang Kena Pajak dan/atau penyerahan Jasa Kena Pajak yan dikenai pajak berdasarkan Undang-Undang PPN 1984.
Tarif PPN yang berlaku saat ini adalah 10% (sepuluh persen). Sedangkan Tarif PPN sebesar 0% (nol persen) diterapkan atas ekspor BKP Berwujud, ekspor BKP Tidak Berwujud dan Ekspor JKP.
2.5 Pengendalian Internal
2.5.1 Pengertian Pengendalian Internal
Bodnar dan Hopwood (2010: 133) mendefinisikan pengendalian internal sebagai suatu proses—dipengaruhi oleh dewan direksi, manajemen, dan personil lainnya—yang dirancang untuk menyediakan keyakinan yang memadai atas tercapainya tujuan-tujuan dalam kategori berikut ini: (1) keandalan pelaporan keuangan, (2) efektivitas dan efisiensi operasi, dan (3) kepatuhan terhadap hukum dan peraturan yang berlaku.
2.5.2 Tujuan Utama Pengendalian Internal
Menurut Hall (2011: 14), sistem pengendalian internal suatu organisasi terdiri dari kebijakan, praktik dan prosedur untuk mencapai empat tujuan besar, yaitu:
1. Untuk melindungi aset yang dimiliki perusahaan.
2. Untuk memastikan keakuratan dan keandalan catatan dan informasi akuntansi.
3. Untuk mendorong efisiensi operasi perusahaan.
4. Untuk mengukur kepatuhan atas prosedur dan kebijakan yang ditetapkan perusahaan.
2.6 Manajemen Proyek
2.6.1 Pengertian Manajemen Proyek
Berdasarkan The Guide to the Project Management Body of Knowledge (PMBOK® Guide), Marchewka (2015: 4) mendefinisikan manajemen proyek sebagai penerapan pengetahuan, keterampilan, perangkat, dan teknik untuk aktivitas proyek dalam memenuhi kebutuhan proyek.
Satzinger, Jackson dan Burd (2012: 256) menyatakan bahwa “Manajemen proyek adalah mengatur dan mengarahkan orang lain untuk mencapai hasil yang telah direncanakan dalam jadwal dan budget yang telah ditentukan sebelumnya.”
Sehingga dapat disimpulkan bahwa manajemen proyek adalah penerapan pengetahuan, keterampilan, perangkat dan teknik untuk mengelola aktivitas proyek sehingga bisa mendapatkan hasil yang sesuai dengan rencana di dalam jadwal serta budget yang telah ditentukan sebelumnya.
2.6.2 Peranan dalam Manajemen Proyek
Marchewka (2012: 3) menyatakan bahwa berdasarkan proyek dan keterampilan yang dibutuhkan, suatu proyek memerlukan peranan-peranan sebagai berikut:
1. Project manager atau Leader, bertanggung jawab untuk memastikan bahwa semua proses manajemen proyek dan proses-proses yang berkaitan dengan pembuatan produk, jasa, atau sistem ada dan dijalankan secara efisien dan efektif.
2. Project sponsor, dapat merupakan klien, pelanggan atau eksekutif tingkat atas yang memainkan peran pemenang untuk proyek dengan menyediakan sumber daya, membuat keputusan terkait proyek, memberikan arahan, dan secara terbuka mendukung proyek saat diperlukan.
3. Subject matter experts (SME), dapat merupakan pengguna atau orang yang memiliki pengetahuan, keahlian, atau pandangan dalam area fungsional tertentu yang dibutuhkan untuk membantu proyek.
4. Technical experts (TE), diperlukan pada saat merekayasa atau
membangun suatu produk, jasa, atau sistem.
2.6.3 Proses-Proses Pada Manajemen Proyek
Berdasarkan PMBOK® Guide, Marchewka (2015: 29) menguraikan lima kelompok proses manajemen proyek seperti berikut ini (diilustrasikan pada gambar 2.1):
1. Initiating. Proses inisiasi mengisyaratkan awal dari proyek atau suatu fase.
2. Planning. Proses perencanaan membantu merencanakan keseluruhan
proyek dan setiap fase individual.
3. Executing. Di saat suatu fase proyek telah disetujui dan direncanakan, proses pelaksanaan memfokuskan dalam penggabungan orang-orang dan sumber daya untuk menjalankan aktivitas yang telah direncanakan di dalam rencana proyek atau fase.
4. Monitoring and controlling. Proses pemantauan dan pengendalian memungkinkan untuk melakukan pengelolaan dan pengukuran kemajuan terhadap tujuan dan ruang lingkup proyek, jadwal, budget, dan tujuan kualitas.
5. Closing. Proses penutupan menyediakan sekumpulan proses yang secara formal menerima produk, jasa, atau sistem dari proyek sehingga proyek atau fase dapat dibawa ke suatu penutupan yang teratur.
Gambar 2.1 PMBOK®Project Management Process Groups Sumber : Marchewka (2015: 30)
2.7 Flowchart 2.7.1 Flowchart
Nelson, Batalden dan Godfrey (2011: 299), menyatakan bahwa “Flowchart adalah gambaran dari tahapan berurutan dan aliran penunjukkan dari tahapan tersebut yang berada di dalam suatu proses”.
Menurut Romney, Steinbart, Mula, McNamara dan Tonkin (2013: 70), flowchart adalah suatu teknik analitikal yang digunakan untuk mendeskripsikan beberapa aspek dari suatu sistem informasi dengan cara yang jelas, singkat dan logis.
Sehingga dapat disimpulkan bahwa flowchart adalah suatu diagram yang menggunakan simbol-simbol dan garis-garis penghubung yang menggambarkan tahapan yang berurutan serta aliran penunjukkan dari tahapan yang terdapat di dalam suatu proses.
2.7.2 Jenis-Jenis Flowchart
1. Document Flowchart
Document flowchart menerangkan aliran dokumen-dokumen, data dan informasi antara area-area yang bertanggung jawab di dalam suatu organisasi. Suatu document flowchart biasanya berguna dalam menganalisa prosedur pengendalian internal.
2. System Flowchhart
System flowchart menggambarkan hubungan antar input, proses dan output sistem. Suatu input akan diikuti oleh proses yang dilakukan terhadap data. Hasil yang berupa informasi baru merupakan komponen output, yang dapat disimpan untuk digunakan di lain waktu, ditampilkan di layar atau dicetak di kertas.
3. Program Flowchart
Program flowchart menggambarkan urutan dari kejadian logis yang dilakukan oleh komputer dalam menjalankan suatu program. Akuntan menggunakan program flowchart untuk memahami apa yang terjadi dalam pemrosesan komputer sehingga mereka dapat memvalidasi bahwa output (laporan dan buku besar) dengan benar mewakili input (data transaksi).
2.7.3 Simbol-Simbol Flowchart
Gambar 2.2 menampilkan simbol-simbol flowchart menurut Romney, Steinbart, Mula, McNamara dan Tonkin (2013: 71-72). Simbol flowchart dibagi menjadi empat kategori, yaitu:
1. Input/output symbols, menggambarkan perangkat atau media yang
menyediakan input atau mencatat output dari pemrosesan kegiatan. 2. Processing symbols, menampilkan perangkat apa saja yang digunakan
untuk memproses data atau menunjukkan saat suatu proses dilakukan secara manual.
3. Storage symbols, menggambarkan perangkat yang digunakan untuk
menyimpan data.
4. Flow and miscellaneous symbols, menunjukkan aliran data, dimana flowchart berawal dan berakhir, dimana keputusan dibuat, dan kapan suatu catatan penjelas ditambahkan ke dalam flowchart.
2.8 Perencanaan dan Perancangan Sistem Informasi Berorientasi Objek 2.8.1 Pengembangan Sistem
2.8.1.1 System Development Life Cycle (SDLC)
Menurut Marchewka (2015: 34), siklus hidup pengembangan sistem (SDLC) menggambarkan tahapan atau tingkatan berurutan suatu produk atau sistem informasi yang mengikuti selama masa bermanfaatnya. Perencanaan, analisa, desain, implementasi, dan pemeliharaan dan bantuan adalah lima tahapan dasar di dalam siklus hidup pengembangan sistem. 1. Perencanaan (Planning). Tahap perencanaan melibatkan identifikasi
dan tanggapan atas suatu masalah atau kesempatan dan menggabungkan manajemen proyek dengan proses serta aktivitas pengembangan sistem. Proses perencanaan memastikan bahwa tujuan, ruang lingkup, budget, jadwal, teknologi, dan proses, metode serta alat-alat pengembangan sistem ada pada tempatnya.
2. Analisa (Analysis). Tahap analisa mengupayakan untuk mempelajari masalah atau kesempatan secara keseluruhan. Kebutuhan dan persyaratan untuk sistem baru diidentifikasi dan didokumentasikan disini.
Gambar 2.2 Flowchart Symbols
3. Desain (Design). Selama tahap desain, tim proyek menggunakan persyaratan dan model logis “nanti” sebagai input untuk merancang arsitektur untuk mendukung sistem informasi baru. Arsitektur ini meliputi perancangan jaringan, konfigurasi perangkat keras, basis data, antar muka pengguna, dan program aplikasi.
4. Implementasi (Implementation). Tahap implementasi meliputi pengembangan atau pembangunan sistem, pengujian, dan instalasi. Sebagai tambahan, pelatihan, dukungan, dan dokumentasi harus ada. 5. Pemeliharaan dan bantuan (Maintenance and Support). Meskipun
pemeliharaan dan bantuan bukan merupakan tahap yang sebenarnya dari proyek yang berlangsung, tetapi tetap merupakan pertimbangan yang penting. Perubahan di dalam sistem, sebagai bentuk dari pemeliharaan dan peningkatan, seringkali diminta untuk memperbaiki semua kerusakan yang terjadi di dalam sistem (seperti bug), untuk menambah fitur-fitur yang belum digabungkan ke desain aslinya, atau untuk penyesuaian terhadap perubahan lingkungan bisnis. Bantuan, seperti call center atau help desk, dapat juga ditambahkan untuk membantu pengguna sebagai dasar yang dibutuhkan.
2.8.1.2 Unified Modeling Language (UML)
Menurut Lethbridge dan Laganière (2014: 8), Unified Modeling Language (UML) adalah sekumpulan notasi untuk menggambarkan kebutuhan dan rancangan software.
Satzinger, Jackson dan Burd (2012: 46), menyatakan bahwa “UML adalah sekumpulan standar dari konsep dan notasi model yang dikembangkan secara khusus untuk pengembangan berorientasi objek.” Dengan menggunakan UML, analis dan pengguna akhir dapat menggambarkan dan memahami berbagai macam diagram yang digunakan di dalam proyek pengembangan sistem. Model dari komponen sistem yang menggunakan UML terdiri dari:
1. Use case diagram 2. Class diagram 3. Activity diagram
5. Communication diagram
6. Package diagram
2.8.1.3 Unified Process (UP)
Satzinger, Jackson dan Burd (2012: 446) menyatakan bahwa “Unified Process (UP) adalah suatu metodologi pengembangan sistem berorientasi objek yang awalnya ditawarkan oleh Rational Software, yang sekarang merupakan bagian dari IBM.”
2.8.1.4 Unified Process Life Cycle
Menurut Satzinger, Jackson dan Burd (2012: 446), “UP memperkenalkan suatu pendekatan adaptif baru untuk siklus hidup pengembangan sistem yang menggabungkan perulangan-perulangan dan fase-fase.” Seperti yang dapat dilihat pada gambar 2.3, UP menetapkan empat fase siklus hidup: inception, elaboration, construction, dan transition.
1. Fase permulaan (inception phase)
Di dalam fase permulaan, manajer proyek mengembangkan dan menyempurnakan pandangan untuk sistem baru untuk menunjukkan bagaimana sistem baru tersebut akan memperbaiki proses operasi dan menyelesaikan masalah yang ada. Fase ini biasanya diselesaikan dalam satu perulangan. Tujuan fase ini adalah untuk mengembangkan perkiraan visi untuk sistem, membuat kasus-kasus bisnis, mendefinisikan ruang lingkup, dan menghasilkan perkiraan kasar atas biaya dan jadwal. 2. Fase elaborasi (elaboration phase)
Fase elaborasi biasanya melibatkan beberapa perulangan, dan perulangan awal umumnya menyelesaikan identifikasi dan definisi dari semua kebutuhan sistem. Tujuan dari fase elaborasi adalah untuk menyempurnakan visi, mengidentifikasi dan menggambarkan semua kebutuhan, memfinalisasi ruang lingkup, merancang dan mengimplementasikan arsitektur dan fungsi inti, menyelesaikan risiko-risiko tinggi, dan menghasilkan estimasi yang sebenarnya untuk biaya dan jadwal.
Fase pembangunan melibatkan beberapa perulangan yang melanjutkan perancangan dan implementasi sistem. Tujuan dari fase ini adalah untuk mengimplementasi secara berulang elemen-elemen berisiko rendah, dapat ditebak, dan lebih mudah yang masih tersisa serta menyiapkan penyebaran.
4. Fase transisi (transition phase)
Selama fase transisi, satu atau lebih perulangan terakhir melibatkan penerimaan dari pengguna akhir dan beta test, kemudian sistem dapat digunakan untuk operasi bisnis. Setelah sistem digunakan, akan diperlukan bantuan dan pemeliharaan. Tujuan fase ini adalah untuk menyelesaikan beta test dan penyebaran sehingga pengguna dapat memiliki sistem yang bekerja dan dapat memberikan manfaat sesuai dengan yang diharapkan.
Gambar 2.3 Unified Process System Development Life Cycle Sumber : Satzinger, Jackson dan Burd (2012: 446)
2.8.1.5 Unified Process Disciplines
Menurut Satzinger, Jackson dan Burd (2012: 448), “suatu disiplin adalah sekumpulan aktivitas yang terkait secara fungsional yang bersama-sama berkontribusi ke satu aspek proyek pengembangan. Disiplin ini melingkupi business modeling, requirements modeling, design, implementation, testing, deployment, project management, configuration and change management, dan environment. Gambar 2.4 menggambarkan keseluruhan fase siklus hidup UP dengan fase-fase, perulangan, dan disiplin.
Gambar 2.4 UP lifecycle with phases, iterations, and disciplines Sumber : Satzinger, Jackson dan Burd (2012: 449)
2.8.2 Pendekatan Berorientasi Objek (Object Oriented Approach)
Satzinger, Jackson dan Burd (2012: 241) menyatakan bahwa, “pendekatan berorientasi objek adalah pendekatan pengembangan sistem yang memandang sistem informasi sebagai sekumpulan objek yang saling berinteraksi yang bekerja bersama-sama untuk menyelesaikan suatu tugas.” Karena pandangan inilah, object-oriented analysis (OOA) mendefinisikan semua jenis objek yang dibutuhkan pengguna untuk bekerja dan menampilkan interaksi pengguna apa saja yang dibutuhkan untuk menyelesaikan suatu tugas. Object-oriented design (OOD) mendefinisikan semua jenis tambahan objek diperlukan untuk berkomunikasi dengan orang-orang dan perangkat di dalam sistem, menampilkan bagaimana objek berinteraksi untuk menyelesaikan suatu tugas dan menyempurnakan definisi dari setiap jenis objek sehingga dapat diimplementasikan dengan bahasa atau lingkungan tertentu. Object-oriented programming (OOP) berisikan pernyataan-pernyataan tertulis di dalam bahasa pemrograman untuk menetapkan apa saja yang dilakukan oleh setiap objek.
2.9 Modeling Requirement Discipline
2.9.1.1 System Requirements
Menurut Satzinger, Jackson dan Burd (2012: 42), kebutuhan sistem adalah seluruh kegiatan yang harus dapat dilakukan oleh sistem. Kebutuhan sistem mendeskripsikan syarat yang dibutuhkan pengguna dan fungsi yang harus ada di dalam sistem. Kebutuhan sistem terbagi menjadi dua kategori utama, yaitu :
1. Functional requirements, merupakan kebutuhan sistem yang
mendeskripsikan aktivitas atau proses yang harus dilakukan oleh sistem. Functional requirements biasanya terkait langsung dengan use case. 2. Nonfunctional requirements, merupakan karakteristik sistem selain
aktivitas yang harus dilakukan atau didukung. Terdapat empat jenis nonfunctional requirements, yaitu:
a. Usability requirements
Kebutuhan sistem yang mendeskripsikan karakteristik operasional yang berhubungan dengan pengguna, seperti antar muka pengguna, prosedur pekerjaan terkait, bantuan online, dan dokumentasi.
b. Reliability requirements
Kebutuhan sistem yang mendeskripsikan ketergantungan sebuah sistem, perhitungan untuk kegiatan seperti services outages, incorrect processing, dan deteksi dan pemulihan kesalahan.
c. Performance requirements
Kebutuhan sistem yang mendeskripsikan karakteristik operasional yang berhubungan dengan pengukuran workload, seperti throughput dan waktu tanggap.
d. Security requirements
Kebutuhan sistem yang mendeskripsikan akses pengguna ke fungsi-fungsi tertentu dan kondisi-kondisi dimana hak akses dibutuhkan.
2.9.1.2 Activity Diagram
Menurut Satzinger, Jackson dan Burd (2012: 57), activity diagram adalah sebuah diagram alur kerja yang menggambarkan berbagai pengguna (atau sistem) kegiatan, orang yang melakukan setiap kegiatan, dan aliran sekuensial kegiatan ini. Seperti yang ditampilkan pada gambar 2.5, berikut ini adalah simbol-simbol yang terdapat pada activity diagram:
1. Swimlane heading, sebuah area persegi panjang pada activity diagram yang mewakili kegiatan yang dilakukan oleh agen tunggal atau unit organisasi.
2. Starting Activity, sebuah simbol dalam activity diagram yang memiliki fungsi sebagai penanda dimulainya suatu aktifitas.
3. Transition Arrow, sebuah simbol dalam activity diagram yang memiliki fungsi untuk menghubungkan satu aktivitas dengan aktivitas berikutnya. 4. Activity, sebuah simbol dalam activity diagram yang memiliki fungsi
untuk menjelaskan aktifitas yang dilakukan oleh user.
5. Ending Activity, sebuah simbol dalam activity diagram yang memiliki fungsi sebagai penanda berakhirnya suatu aktifitas.
6. Synchronization Bar, simbol yang digunakan dalam activity diagram untuk mengontrol pemisahan atau penyatuan dari aktifitas yang berurutan.
7. Decision Activity, sebuah simbol dalam activity diagram yang digunakan untuk pengambilan keputusan.
Gambar 2.5 Activity Diagram Symbols Sumber : Satzinger, Jackson dan Burd (2012: 58)
2.9.2.1 Domain Model Class Diagram
Menurut Satzinger, Jackson dan Burd (2012: 101), domain model class diagram seperti yang ditunjukkan pada gambar 2.6 adalah UML class diagram yang menunjukkan hal-hal yang penting dalam pekerjaan user yaitu problem domain class, asosiasi, dan atribut. Hubungan antar class disebut asosiasi yang mana dapat dilihat pada gambar 2.7.
Menurut Satzinger, Jackson dan Burd (2012: 102), terdapat dua hirarki dalam notasi class diagram, yaitu :
1. Generalization/Specialization Notation
Merupakan pengelompokkan hal-hal berdasarkan persamaan dan perbedaan. Generalization adalah pengelompokkan hal-hal berdasarkan jenis yang sama, contohnya ada banyak jenis kendaraan seperti mobil, motor, truk, traktor, dan sebagainya. Sedangkan specialization adalah pengelompokkan hal-hal yang berbeda jenisnya, sebagai contoh jenis khusus dari mobil adalah mobil sport, sedan, dan sebagainya.
Gambar 2.6 Domain Model Class Diagram Sumber : Satzinger, Jackson dan Burd (2012: 102)
Gambar 2.7 Multiplicity of Association
Sumber : Satzinger, Jackson dan Burd (2012: 102)
Generalization/Specialization hierarchy digunakan untuk mengurutkan hal-hal umum menjadi lebih khusus. Gambar 2.8 menampilkan notasi hirarki generalisasi/spesialisasi untuk kendaraan bermotor.
2. Whole-Part Hierarchy Notation
Menggambarkan hubungan keterkaitan antara sebuah object dengan komponennya. Terdapat dua jenis whole-part hierarchy yaitu :
a. Aggregation, digunakan untuk mengambarkan sebuah hubungan
antara object dan bagian-bagiannya dimana bagian-bagian tersebut dapat berdiri sendiri secara terpisah. Gambar 2.9 menampilkan asosiasi whole-part (aggregation) antara komputer dan bagian-bagiannya.
Gambar 2.8 Generalization/Specialization Hierarchy Notation for Motor Vehicles
Sumber : Satzinger, Jackson dan Burd (2012: 105)
b. Composition, digunakan untuk menggambarkan hubungan
berdiri sendiri secara terpisah. Gambar 2.10 menampilkan asosiasi whole-part (composition) antara mobil dan bagian-bagiannya.
Gambar 2.9 Whole-part (Aggregation) Association for Computer and Its Parts Sumber : Satzinger, Jackson dan Burd (2012: 107)
Gambar 2.10 Whole-part (Composition) Association for Car and Its parts
2.9.3 Use Cases 2.9.3.1 User Goals
Menurut Satzinger, Jackson dan Burd (2012: 69), satu pendekatan untuk mengidentifikasi use case, yang disebut user goal technique, adalah untuk meminta pengguna untuk menggambarkan tujuan mereka dalam menggunakan sistem baru. User goal technique untuk mengidentifikasi use case meliputi langkah-langkah berikut:
1. Mengidentifikasi semua pengguna potensial untuk sistem baru.
2. Menggolongkan pengguna potensial sesuai dengan peranan fungsional mereka (misalnya pemasaran, penjualan, pengiriman).
3. Selanjutnya menggolongkan pengguna potensial berdasarkan tingkatan organisasi (misalnya operasional, manajemen, eksekutif).
4. Untuk setiap jenis pengguna, dilakukan wawancara untuk mendapatkan tujuan-tujuan khusus yang diinginkan oleh pengguna pada saat menggunakan sistem baru.
5. Membuat daftar preliminary use case yang disusun berdasarkan jenis pengguna.
6. Mencari duplikasi yang memiliki kemiripan nama use case dan menyelesaikan inkonsistensi.
7. Mengidentifikasi dimana jenus pengguna yang berbeda memerlukan use case yang sama.
8. Me-review daftar yang sudah lengkap dengan setiap jenis pengguna dan kemudian dengan stakeholder lainnya yang berkepentingan.
2.9.3.2 Use Case Diagram
Menurut Satzinger, Jackson dan Burd (2012: 69), use case adalah aktivitas-aktivitas yang dilakukan oleh sebuah sistem, biasanya merupakan tanggapan dari permintaan pengguna sistem. Pada penyelesaian tahap elaboration, tim proyek harus mengidentifikasi seluruh use case dan mendeskripsikan rinciannya. Satzinger, Jackson dan Burd (2012: 78) menyatakan bahwa “use case diagram adalah model UML yang digunakan untuk menggambarkan use case dan hubungannya dengan pengguna secara grafis.” Di dalam use case diagram terdapat stick sederhana yang merepresentasikan actor. Figur stick diberikan nama sesuai peran yang dimiliki oleh actor. Use case disimbolkan dengan bentuk oval dengan nama use case didalamnya. Garis penghubung antara actor dan use case mengindikasikan use case yang digunakan oleh actor. Notasi-notasi use case diagram ditampilkan pada gambar 2.11.
Dalam beberapa penggambaran use case diagram, diperlukan adanya relationship yang disebabkan adanya kegiatan yang membutuhkan lebih dari satu use case pada saat pelaksanaannya. Hubungan yang muncul antara use case disebabkan adanya use case lanjutan yang harus dijalankan setelah sebuah use case dijalankan, digambarkan dengan hubungan <<includes>>. Hubungan lainnya dimana use case dijalankan apabila use case sebelumnya
memenuhi suatu syarat tertentu, digambarkan dengan hubungan <<uses>> atau <<extends>>.
Gambar 2.11 Use Case Notation
Sumber: Satzinger, Jackson dan Burd (2012: 81)
2.9.3.3 Use Case Description
Menurut Satzinger, Jackson dan Burd (2012: 122), use case description adalah skenario dari use case diagram, deskripsi detail tahapan skenario yang terjadi dalam sebuah proses tersebut. Use case description digunakan untuk agar dapat lebih mengerti detil tahapan dan agar sistem lebih tepat memenuhi kebutuhan user.
1. Fully Developed Description
Metode yang paling formal untuk mendokumentasikan sebuah use case. Walaupun membutuhkan kerja lebih untuk mendefinisikan semua komponen pada tingkat ini, metode ini sangat baik dalam menggambarkan aliran kegiatan internal untuk use case. Gambar 2.12 menampilkan fully developed description dari skenario telephone order.
Gambar 2.12 Use Case Fully Developed Description Sumber : Satzinger, Jackson dan Burd (2012: 123)
2.10 Design Activities
2.10.1 Design the Environment
Menurut Satzinger, Jackson dan Burd (2012: 163-168), environment adalah semua teknologi yang dibutuhkan untuk mendukung aplikasi perangkat lunak yang sedang dikembangkan.
2.10.1.1 Internal Network-Based System
Menurut Satzinger, Jackson dan Burd (2012: 168), suatu internal network-based system adalah suatu sistem yang digunakan secara eksklusif oleh perusahaan yang membangun atau membelinya. Internal network-based system tidak dapat digunakan oleh setiap orang kecuali karyawan perusahaan yang berlokasi di dalam fasilitas fisik organisasi. Di dalam internal network-based system terdapat suatu hardware environment yang disebut local area network (LAN), yaitu suatu jaringan komputer yang mana pemasangan kabel
dan perangkat kerasnya terbatas pada satu lokasi saja, seperti sebuah bangunan.
2.10.2 Software Architecture
Menurut Satzinger, Jackson dan Burd (2012: 168), konfigurasi di dalam internal network-based system menggambarkan suatu client/server architecture sederhana. Client/server architecture merupakan konfigurasi jaringan komputer antara komputer pengguna dengan komputer pusat yang menyediakan layanan-layanan umum. Komputer yang digunakan oleh pengguna untuk melakukan pekerjaan mereka disebut komputer client, dimana komputer utama disebut komputer server. Ada dua jenis sistem yang dapat dikembangkan di dalam client/server architecture yaitu:
a. Sistem aplikasi desktop.
b. Sistem aplikasi berbasis browser.
2.11 Use Case Realization
2.11.1 Multilayer Design Sequence Diagram
Menurut Satzinger, Jackson dan Burd (2012: 336-348), seperti yang ditampilkan pada gambar 2.13, multilayer design system sequence diagram terdiri dari :
1. First-Cut Sequence Diagram, dimana mengembangkan SSD untuk
menentukan object lain yang mungkin terlibat.
2. The View Layer, melibatkan interaksi manusia dan komputer serta membutuhkan perancangan user interface untuk masing-masing use case.
3. The Data Access Layer adalah kelas yang digunakan untuk menerima dan mengirim data ke database.
Gambar 2.13 Multilayer Design System Sequence Diagram Sumber : Satzinger, Jackson dan Burd (2012: 346)
2.11.2 Updated Design Model Class Diagram
Menurut Satzinger, Jackson dan Burd (2012: 351), updated design class diagram merupakan design class diagram yang dikembangkan untuk setiap layer. Di dalam view layer dan data access layer, beberapa kelas baru harus ditentukan. Domain layer juga memiliki beberapa kelas-kelas baru yang ditambahkan untuk use case controllers. Pada gambar 2.14 ditampilkan design class diagram lengkap untuk kelas-kelas domain layer. Diagram ini menyediakan dokumentasi dari design classes dan berfungsi sebagai blueprint untuk sistem pemrograman.
Gambar 2.14 Updated design class diagram for the domain layer Sumber : Satzinger, Jackson dan Burd (2012: 352)
2.11.3 Package Diagram
Menurut Satzinger, Jackson dan Burd (2012: 353), package diagram seperti yang ditampilkan pada gambar 2.15 adalah sebuah diagram tingkat tinggi yang memungkinkan perancang untuk mengasosiasikan kelas dengan grup yang terkait. Diagram ini digambarkan menjadi three-design layer, yaitu view layer, domain layer, dan data access layer.
Gambar 2.15 Package Diagram
Sumber : Satzinger, Jackson dan Burd (2012: 353)
2.12 Interface 2.12.1 User Interface
Menurut Satzinger, Jackson dan Burd (2012: 189), user interface merupakan bagian-bagian dari suatu sistem informasi yang membutuhkan interaksi pengguna untuk membuat input dan output.
Menurut Satzinger, Jackson dan Burd (2012: 193), terdapat delapan universal guidelines dalam merancang user interface, yaitu:
1. Affordance dan visibility.
Tampilan sistem dari suatu pengaturan khusus harus menunjukkan fungsinya (affordance) dan suatu pengaturan harus terlihat sehingga pengguna mengetahui bahwa suatu pengaturan itu ada (visibility). 2. Memungkinkan pengguna untuk menggunakan shortcut (enable frequent
users to use shortcuts).
Shortcut digunakan untuk mengurangi jumlah interaksi untuk tugas yang dijalankan, sehingga pengguna dapat menghemat waktu. Selain itu,
perancang harus menyediakan fasilitas macro bagi pengguna untuk membuat shortcut mereka sendiri.
3. Memberikan umpan balik yang informatif (offer informative feedback). Umpan balik yang berupa konfirmasi dari sistem sangat penting bagi pengguna sistem, terutama bagi mereka yang bekerja dengan menggunakan sistem sepanjang hari. Contohnya, ketika pengguna ingin menghapus suatu data makan akan muncul dialog box untuk memastikan apakah pengguna sudah yakin data tersebut benar-benar ingin dihapus atau tidak. Akan tetapi, sebaiknya sistem juga tidak memperlambat pekerjaan pengguna sistem dengan menampilkan terlalu banyak dialog box, dimana pengguna harus merespon tiap dialog box.
4. Merancang dialog untuk menghasilkan penutupan (design dialogs to yield closure).
Untuk setiap dialog dengan sistem harus diorganisasikan dengan urutan yang jelas, yaitu dari awal, tengah, dan akhir agar pengguna dapat mempersiapkan dirinya untuk fokus ke tindakan berikutnya.
5. Memberikan penanganan kesalahan yang sederhana (offer simple error handling).
Saat sistem menemukan sebuah kesalahan, pesan kesalahan harus menegaskan secara spesifik apa yang salah dan menjelaskan bagaimana cara untuk menanganinya. Pesan kesalahan juga tidak boleh menghakimi pengguna. Selain itu sistem harus bisa mengatasi kesalahan dengan mudah, contohnya jika pengguna memasukkan ID pelanggan yang salah, maka sistem akan memberitahukan kepada pengguna dan meletakkan kursor pada textbox ID pelanggan yang berisi angka yang telah dimasukkan sebelumnya dan siap untuk diubah.
6. Memungkinkan untuk kembali ke tindakan sebelumnya dengan mudah (permit easy reversal of actions).
Salah satu cara untuk menghindari kesalahan, sebagaimana user menyadari telah melakukan kesalahan, user dapat membatalkan tindakan yang sedang dijalankan dan kembali ke tindakan sebelumya.
7. Mendukung tempat pengendalian internal (support internal locus of control).
Sistem harus membuat user merasa bahwa mereka yang memutuskan apa yang harus dilakukan dan bukan sistem yang mengontrol mereka. 8. Mengurangi muatan memori jangka pendek (reducing short-term
memory load).
Rancangan yang terlalu rumit dan terlalu banyaknya form dapat menjadi beban bagi ingatan pengguna.
2.13 System Security and Control 2.13.1 Integrity Control
Menurut Satzinger, Jackson dan Burd (2012: 393-395), integrity control merupakan mekanisme-mekanisme dan prosedur-prosedur yang dibuat pada sistem aplikasi untuk mengamankan informasi yang ada di dalamnya. Integrity control dibagi menjadi enam, yaitu:
1. Input controls digunakan dengan seluruh mekanisme masukan, dari perangkat elektronik untuk standarisasi masukan menggunakan keyboard. Terdiri dari empat teknik pengendalian, yaitu:
a. Field combination control, me-review beberapa kombinasi dari kolom untuk memastikan bahwa data yang dimasukkan benar.
b. Value limit control, sebuah cara untuk memeriksa angka untuk memastikan bahwa jumlah yang dimasukkan masuk akal.
c. Completeness control, memastikan bahwa semua kolom benar-benar selesai dimasukkan.
d. Data validation control, memastikan bahwa kolom angka yang berisikan kode adalah benar.
2. Access control, kembali kepada kemampuan pengguna untuk
mendapatkan akses ke dalam data.
3. Transaction logging, sebuah teknik dimana setiap terjadi update ke dalam database dicatatkan dengan menggunakan informasi audit seperti ID, tanggal, waktu, data masukan dan tipe update.
4. Complex update control, suatu pengendalian yang dilakukan dengan mengunci catatan untuk melindungi dari multiple update yang dapat menimbulkan masalah.
5. Redundancy, backup and recovery, prosedur yang dirancang untuk melindungi software dan database dari seluruh bencana yang mungkin terjadi.
6. Output control, memastikan bahwa seluruh output diterima oleh orang yang tepat (destination control) dan informasi yang keluar harus akurat, terkini, dan lengkap (completeness, accuracy, and correctness control).
2.14 Kerangka Berpikir
Kerangka berpikir adalah alur berpikir yang disusun secara singkat untuk menjelaskan bagaimana sebuah penelitian dilakukan pertama kali, proses pelaksanaannya sampai hasil akhir dari penelitian tersebut. Kerangka berpikir dapat disusun dalam bentuk narasi atau digambarkan di dalam sebuah diagram (seperti yang ditunjukkan pada gambar 2.16). Berikut ini adalah penjelasan kerangka berpikir dari gambar 2.16:
Di tahap Inception, akan dilakukan pencarian perusahaan yang dapat dijadikan objek penelitian untuk skripsi baik secara online maupun dengan meminta bantuan dari relasi. Pada saat perusahaan sudah didapatkan, surat permohonan ijin penelitian & pengamatan untuk skripsi akan diminta dan diproses di Layanan Mahasiswa Universitas Binus. Sementara proses pembuatan surat tersebut, scenario mengenai kegiatan yang akan dilakukan akan mulai dirancang, seperti mengenai kantor mana yang akan didatangi, bagian apa yang akan diamati, pihak-pihak yang akan diwawancarai dan merumuskan pertanyaan-pertanyaan untuk wawancara. Setelah surat diterbitkan, perusahaan yang akan diteliti akan didatangi, dimana di dalam kasus ini, wawancara dilakukan di Banjarbaru Kalimantan Selatan tepatnya di kantor PT PLN (Persero) Wilayah Kalimantan Selatan dan Kalimantan Tengah tepatnya di Unit Induk Pembangunan dan Listrik Perdesaan. Selain
Gambar 2.16 Kerangka Berpikir
melakukan wawancara untuk mendapatkan permasalahan yang sedang dihadapi perusahaan dalam menjalankan kegiatan operasionalnya, data tentang perusahan juga akan diminta. Dari permasalahan yang berhasil diidentifikasi, topik skripsi akan diketahui dan sistem informasi apa yang akan dirancang untuk perusahaan akan dapat ditentukan. Proposal skripsi akan dapat dibuat dan diajukan ke Jurusan Universitas Binus.
Di tahap Elaboration, proposal skripsi yang telah disetujui akan mulai dikembangkan. Permasalahan yang dihadapi perusahaan akan dirumuskan lebih lanjut dan kebutuhan-kebutuhan perusahaan atas sistem usulan akan mulai dirincikan. Ruang lingkup sistem juga akan difinalisasi agar proses perancangan sistem dapat dilakukan. Setelah itu akan dibuat jadwal yang akan digunakan untuk mengerjakan sistem usulan dimana jadwal ini akan melingkupi seluruh proses pengerjaan skripsi.
Di tahap Construction, hal pertama yang akan dilakukan adalah menyelesaikan Bab 1 skripsi yang merupakan pengembangan dari proposal skripsi. Perbaikan Bab 1 akan dilakukan jika ada masukan atau pendapat dari pembimbing skripsi. Pertemuan untuk berkonsultasi dengan pembimbing skripsi akan dilakukan beberapa kali dan selama proses tersebut akan dibuat Bab 2 dan 3 skripsi. Bab 2 skripsi berisi teori-teori yang mendukung karya tulis atau skripsi tersebut, sehingga akan dicari buku-buku yang terdapat di Perpustakan Binus maupun secara online yang berisikan teori-teori pendukung. Pada Bab 3 skripsi, akan dilengkapi data mengenai perusahaan yang dijadikan objek skripsi. Proses bisnis perusahaan yang berjalan saat ini dan permasalahan yang dihadapi perusahaan juga akan dituliskan. Setelah itu, sistem usulan akan mulai dirancang dengan menerapkan object oriented and design-unified process diciplines oleh Satzinger yang memodelkan requirement discipline dan usecase realization dimana rancangan ini merupakan isi dari Bab 4. Selama proses pembuatan Bab 4, aplikasi sistem usulan juga akan dibangun dengan menggunakan bahasa pemrograman C# dan database MySql. Setelah aplikasi sistem usulan selesai dibuat, akan melakukan pengujian terhadap aplikasi sistem usulan dan akan dilakukan perbaikan apabila terdapat fungsi-fungsi yang belum sempurna. Aplikasi sistem usulan yang telah diperbaiki kemudian akan dibuatkan dokumen-dokumen pendukung mengenai cara penggunaan aplikasi sistem usulan tersebut. Di akhir tahap ini, Bab 5 skripsi akan dibuat dan dilakukan demo aplikasi sistem usulan kepada pembimbing skripsi. Demo aplikasi akan diikuti dengan prasidang skripsi. Setelah dilakukan perbaikin atas aplikasi dan skripsi, skripsi dapat difinalisasi dengan melengkapi dokumen-dokumen yang perlu disertakan di dalam skripsi.
Di tahap Transition, skripsi yang sudah lengkap dan disetujui kemudian akan diserahkan ke Universitas. Dari skripsi-skripsi yang dikumpulkan, Universitas akan menyusun jadwal sidang dan melakukan panggilan sidang kepada mahasiswa. Setelah mengikuti sidang dan dinyatakan lulus, skripsi akan dicetak dan dikumpulkan dalam bentuk hard cover. Pada proses pembuatan skripsi ini, implementasi sistem tidak dilakukan karena pembuatan skripsi umumnya hanya sampai perancangan dan pembangunan aplikasi sistem saja. Tetapi jika dilakukan, maka akan disiapkan aplikasi
sistem usulan untuk digunakan secara nyata oleh perusahaan. Selama proses perubahan dari sistem lama ke sistem baru, perbaikan aplikasi sistem akan dilakukan jika terdapat kesalahan konfigurasi dan instalasi. Selain itu, akan diberikan penjelasan kepada pengguna akhir mengenai cara penggunaan aplikasi sistem secara menyeluruh.
