BAB II LANDASAN TEORI. 2.1 DEFINISI CMM ( Capability Maturity Model )

7

BAB II LANDASAN TEORI

2.1 DEFINISI CMM ( Capability Maturity Model ) Dalam penelitian untuk membantu organisasi dalam mengembangkan dan mempertahankan

kualitas

produk

dan

layanan.

Software

Engineering

Institute(SEI) telah menemukan beberapa dimensi yang mana setiap organisasi dapat fokus untuk meningkatkan bisnisnya.( CMMI for Development version 1.2 halaman 4 ).

Gambar 2.1 kritikal dimensi dalam CMM Gambar diatas menggambarkan tiga dimensi penting dimana setiap organisasi biasanya berfokus pada: orang/ SDM, prosedur dan metode, dan alat dan peralatan. Capability Maturity Model ( CMM ) adalah sebuah model yang dikembangkan oleh Software Engineering Institute atas permintaan Departement of Defense(DOD) Amerika Serikat dengan tujuan membuat ujian saringan masuk bagi kontraktor yang mendaftarkan diri untuk menjadi konsultan DOD.

http://digilib.mercubuana.ac.id/

8

Model yang paling banyak diadopsi oleh industri perangkat lunak adalah model Capability Maturity Model (CMM) yang dikeluarkan oleh Software Engneering Institute (SEI) pada tahun 1986. Capability Maturity Model membuat 5 level/skala kematangan yaitu : 1. Initial 2. Repeatable 3. Defined 4. Managed 5. Optimized adapun penjelasan singkat mengenai hal tersebut adalah sebagai berikut: Level initial bercirikan sebagai berikut : 1. Tidak adanya manajemen proyek. 2. Tidak adanya quality assurance. 3. Tidak adanya mekanisme menajemen perubahan (change management ). 4. Tidak Ada dokumentasi. 5. Adanya seorang guru yang tahu segalanya tentang perangkat lunak yang dikembangkan. 6. Sangat bergantung pada kemampuan individual. Level Repeatable bercirikan sebagai berikut : 1. Kualitas perangkat lunak mulai bergantung pada proses bukan pada orang. 2. Ada manajemen proyek sederhana. 3. Ada quality assurance sederhana. 4. Ada dokumentasi sederhana. 5. Ada software configuration managemen sederhana. 6. Tidak adanya knowledge managemen. 7. Tidak ada komitment untuk selalu mengikuti SDLC dalam kondisi


9

apapun. 8. Tidak ada statiskal control untuk estimasi proyek. 9. Rentanterhadapperubahanstrukturorganisasi. Level Defined bercirikan : 1. SDLC sudah dibuat dan dibakukan. 2. Ada komitmen untuk mengikuti SDLC dalam keadaan apapun. 3. Kualitas proses dan produk masih bersifat kwantitatif dan bukan kwalitatif ( tidak terukur hanya kira kira saja ). 4. Tidak menerapkan Activity Based Costing. 5. Tidak ada mekanisme umpan balik yang baku. Level Managed bercirikan : 1. Sudah adanya Activity Based Costing dan digunakan untuk estimasi proyek berikutnya. 2. Proses penilaian kualitas perangkat lunak dan proyek bersifat kuantitatif. 3. Terjadi pemborosan biaya untuk pengumpulan data karena data masih dilakukan secara manual. 4. Cenderung bias ( effect thorne pada manusia yaitu ketika diperhatikan perilakunya cenderung berubah ). 5. Tidak adanya mekanisme pencegahan defect. 6. Ada mekanisme umpa balik. Level Optimized bercirikan : 1. Pengumpulan data secara otomatis. 2. Adanya mekanisme pencegahan defect 3. Ada mekanisme umpa balik yang sangat baik 4. Adanya peningkatan kualitas dari SDM dan peningkatan kualitas proses Adapun fungsi atau kegunaan CMM meliputi :


10

1. Menilai tingkat kematangan sebuah organisasi pengembang perangkat lunak. 2. Memfilter kontraktor yang akan menjadi pengembang perangkat lunak. 3. Memberikan arah untuk peningkatan organisasi bagi top managemen di dalam sebuah organisasi pengembang perangkat lunak Sebagai alat bantu untuk menilai keunggulan kompetitif yang dimiliki sebuah perusahaan dibandingkan perusahaan pesaingnya. 2.2 CMMI ( Capability Maturity Model Integrasi ) Capability Maturity Model Integration atau CMMI (bahasa Indonesia: Integrasi Model Kematangan Kemampuan) adalah suatu pendekatan perbaikan proses yang memberikan unsur-unsur penting proses efektif bagi organisasi.( http://id.wikipedia.org/wiki/CMMI ). Capability Maturity Model Integrasi (CMMI) menyediakan kesempatan untuk menghindari atau menghilangkan stove pipes ( kompor pipa ) dan hambatan melalui terintegrasinya model yang melintasi disiplin ilmu. CMMI untuk Pengembangan terdiri dari praktek terbaik yang membahas pengembangan dan pemeliharaan, kegiatan diterapkan pada produk dan jasa. Agenda tersebut membahas praktek yang mencakup siklus hidup produk dari konsepsi melalui pengiriman dan pemeliharaan. Penekanannya adalah pada pekerjaan yang diperlukan untuk membangun dan memelihara total produk.


11

Gambar 2.2 sejarah perkembangan CMM/CMMI Praktek-praktek terbaik ( best practices ) dalam model CMMI telah melalui sebuah peninjauan proses yang sangat luas. CMMI versi 0.2 adalah publikasi terakhir dan digunakan dalam percontohan kegiatan. Tim pembuat CMMI telah dievaluasi lebih dari 3.000 permintaan perubahan untuk membuat CMMI versi 1.0. Tak lama kemudian dirilis versi 1,02 yang tergabung dalam beberapa perbaikan kecil. Versi 1.1 digabungkan dengan perbaikan dipandu dengan umpan balik dari awal digunakan, dengan lebih dari 1.500 permintaan perubahan disampaikan sebagai bagian dari Tinjauan umum, dan ratusan komentar sebagai bagian dari pengendalian perubahan proses. CMMI versi 1.2 yang dikembangkan menggunakan masukan dari hampir 3.000 perubahan permintaan diajukan oleh pengguna CMMI. Lebih dari 750 dari mereka permintaan diarahkan pada konten model CMMI. ( CMMI for Development version 1.2 halaman 8 ).


12

Gambar 2.3 CMMI komponen model Komponen-komponen

diharapkan

menggambarkan

apa

yang

dapat

mereka

yang

diterapkan organisasi untuk mencapai komponen yang diperlukan. Komponen-komponen

diharapkan

juga

membimbing

melaksanakan perbaikan atau melakukan penilaian. diharapkan komponen termasuk praktik tertentu/spesifik dan generik. Sebelum gol dapat dicapai dengan baik, ada praktek-praktek yang menjelaskan, atau alternatif yang bisa diterima bagi mereka, yang hadir dalam perencanaan dan implementasi proses di organisasi. Representasi terus menerus memungkinkan organisasi untuk memilih fokus

dari

upaya

perbaikan

prosesnya

dengan

memilih

proses

yang

bidang atau set area proses saling terkait. Yang paling menguntungkan organisasi pada

apa

dan

tujuan

yang

usahanya.

organisasi

Meskipun

dapat

ada

memilih

beberapa karena

batasan

dependensi

antara area proses, organisasi memiliki kebebasan yang cukup besar dalam nya seleksi.


13

Representasi dipentaskan menyediakan jalur yang telah ditentukan peningkatan dari tingkat kematangan 1 sampai 5 tingkat kematangan yang melibatkan mencapai tujuan dari area proses pada setiap tingkat kematangan. Untuk mendukung mereka yang menggunakan representasi bertahap, area proses yang dikelompokkan berdasarkan tingkat kematangan, menunjukkan daerah mana proses pelaksanaannya untuk mencapai setiap tingkat kematangan.

Gambar 2.4 proses area kapabilitas dan kematangan CMMI menangani jalan yang harus ditempuh suatu organisasi untuk bisa mengelola proses yang terpetakan dengan baik, yang memiliki tahapan terdefinisi baik. Asumsi yang berlaku di sini adalah bahwa dalam organisasi yang matang, dimungkinkan untuk mengukur dan mengaitkan antara kualitas produk dan kualitas proses.


14

Terlepas model mana yang dipilih oleh suatu organisasi, praktek-praktek terbaik CMMI harus disesuaikan oleh masing-masing organisasi tergantung pada sasaran bisnisnya. Organisasi tidak dapat memperoleh sertifikasi CMMI, melainkan dinilai dan diberi peringkat 1-5. Hasil pemeringkatan penilaian ini dapat dipublikasikan jika dirilis oleh organisasi penilainya.

Tabel 2.1 membandingkan tingkat kemampuan dan kematangan Perhatikan bahwa pada level empat dari tingkat yang sama pada kedua representasi. Perbedaannya adalah bahwa tidak ada tingkat kematangan 0 untuk tahap

representasi,

dan

pada

tingkat

1,

tingkat

kemampuan

adalah

telah dilakukan kinerja, sedangkan tingkat kematangan adalah awal. Oleh karena itu, mulai titik berbeda untuk dua representasi. Ingat bahwa kematangan/maturity tingkat 2 sampai 5 menggunakan istilah yang sama seperti kemampuan/capability tingkat 2 sampai 5. Ini memang disengaja karena konsep tingkat kematangan dan tingkat kemampuan saling melengkapi. Tingkat kematangan digunakan untuk mengkarakterisasi relatif perbaikan organisasi ke set area proses, dan tingkat kemampuan mencirikan organisasi relatif ke area proses individu perbaikan.( CMMI for Development version 1.2 halaman 36 ).


15

Sebuah area proses adalah sekelompok praktek terkait di daerah yang, ketika dilaksanakan secara kolektif, memenuhi satu set tujuan/gol dianggap penting untuk membuat perbaikan di daerah itu. Adapun penjelasan rinci CMMI 22 key process area adalah sebagai berikut : ( sumber : http://id.wikipedia.org/wiki/CMMI ) 1.Manajemen Persyaratan (REQM, Requirements Management) SG (specific goal) 1 Mengelola Persyaratan 

SP 1.1 Memperoleh Pemahaman terhadap Persyaratan



SP 1.2 Memperoleh Komitmen terhadap Persyaratan



SP 1.3 Mengelola Perubahan Persyaratan



SP 1.4 Memelihara Keterlacakan Dua Arah dari Persyaratan



SP 1.5 Mengidentifikasi Ketidakkonsistenan antara Pekerjaan Proyek dan Persyaratan

2.Perencanaan Proyek (PP, Project Planning) SG 1 Membangun Estimasi 

SP 1.1 Mengestimasi Lingkup Proyek



SP 1.2 Membangun Estimasi Hasil Kerja dan Atribut Tugas



SP 1.3 Mendefinisikan Proyek Siklus Hidup



SP 1.4 Menentukan Estimasi Kerja dan Biaya

3.Pengawasan dan Pengendalian Proyek (PMC, Project Monitoring and Control) SG 1 Mengawasi Proyek terhadap Rencana 

SP 1.1 Mengawasi Parameter Perencanaan Proyek



SP 1.2 Mengawasi Komitmen



SP 1.3 Mengawasi Risiko Proyek


16



SP 1.4 Mengawasi Manajemen Data



SP 1.5 Mengawasi Keterlibatan Pemangku Kepentingan



SP 1.6 Mengadakan Tinjauan Kemajuan



SP 1.7 Mengadakan Tinjauan Tenggat

4.Manajemen

Kesepakatan

Pemasok

(SAM,

Supplier

Agreement

Management) SG 1 Membangun Pemasok Kesepakatan 

SP 1.1 Menentukan Tipe Pengadaan



SP 1.2 Memilih Pemasok



SP 1.3 Membangun Kesepakatan Pemasok

5.Pengukuran dan Analisis (MA, Measurement and Analysis) SG 1 Menyelaraskan Kegiatan Pengukuran dan Analisis 

SP 1.1 Membangun Sasaran Pengukuran



SP 1.2 Menentukan Ukuran



SP 1.3 Menentukan Pengumpulan Data dan Prosedur Penyimpanan



SP 1.4 Menentukan Prosedur Analisis

6.Penjaminan Kualitas Proses dan Produk (PPQA, Process and Product Quality Assurance) SG 1 Mengevaluasi Proses dan Hasil Kerja secara Objektif 

SP 1.1 Mengevaluasi Proses secara Objektif



SP 1.2 Mengevaluasi Hasil Kerja dan Layanan secara Objektif

7.Manajemen Konfigurasi (CM, Configuration Management) SG 1 Membangun Basis 

SP 1.1 Mengidentifikasi Item Konfigurasi


17



SP 1.2 Membangun Sistem Manajemen Konfigurasi



SP 1.3 Membuat atau Merilis Basis

8.Pengembangan Persyaratan (RD, Requirements Development) SG 1 Mengembangkan Persyaratan Pelanggan 

SP 1.1 Menggali Kebutuhan



SP 1.2 Mengembangkan Persyaratan Pelanggan

9.Solusi Teknis (TS, Technical Solution) SG 1 Memilih Solusi Komponen Produk 

SP 1.1 Mengembangkan Solusi Alternatif dan Kriteria Pemilihan



SP 1.2 Memilih Solusi Komponen Produk

10.Integrasi Produk (PI, Product Integration) SG 1 Menyiapkan Integrasi Produk 

SP 1.1 Menentukan Urutan Integrasi



SP 1.2 Membangun Lingkungan Integrasi Produk



SP 1.3 Membangun Prosedur dan Kriteria Integrasi Produk

11.Verifikasi (VER, Verification) SG 1 Menyiapkan Verifikasi 

SP 1.1 Memilih Hasil Kerja untuk Diverifikasi



SP 1.2 Membangun Lingkungan Verifikasi



SP 1.3 Membangun Prosedur dan Kriteria Verifikasi

12.Validasi (VAL, Validation) SG 1 Menyiapkan Validasi


18



SP 1.1 Memilih Produk untuk Divalidasi



SP 1.2 Membangun Lingkungan Validasi



SP 1.3 Membangun Prosedur dan Kriteria Validasi

13.Fokus Proses Organisasi (OPF, Organizational Process Focus) SG 1 Menentukan Peluang Perbaikan Proses 

SP 1.1 Membangun Kebutuhan Proses Organisasi



SP 1.2 Menilai Proses Organisasi



SP 1.3 Mengidentifikasi Perbaikan Proses Organisasi

14.Definisi Proses Organisasi (OPD, Organizational Process Definition) +IPPD SG 1 Membangun Aset Proses Organisasi 

SP 1.1 Membangun Proses Standar



SP 1.2 Membangun Deskripsi Model Siklus Hidup



SP 1.3 Membangun Kriteria dan Pedoman Penyesuaian



SP 1.4 Membangun Repositori Pengukuran Organisasi



SP 1.5 Membangun Pustaka Aset Proses Organisasi



SP 1.6 Membangun Standar Lingkungan Kerja

15.Pelatihan Organisasi (OT, Organizational Training) SG 1 Membangun Kapabilitas Pelatihan Organisasi 

SP 1.1 Membangun Kebutuhan Pelatihan Strategis



SP 1.2 Menentukan Kebutuhan Pelatihan yang Merupakan Tanggung Jawab Organisasi



SP 1.3 Membangun Rencana Taktis Pelatihan Organisasi



SP 1.4 Membangun Kapabilitas Pelatihan

16.Manajemen Proyek Terintegrasi (IPM, Integrated Project Management) +IPPD ( Integrated Product and Process Development )


19

SG 1 Menggunakan Proses Terdefinisi dari Proyek 

SP 1.1 Membangun Proses Terdefinisi dari Proyek



SP 1.2 Menggunakan Aset Proses Organisasi untuk Perencanaan Kegiatan Proyek



SP 1.3 Membangun Lingkungan Kerja Proyek



SP 1.4 Mengintegrasikan Rencana



SP 1.5 Mengelola Proyek Menggunakan Rencana Terintegrasi



SP 1.6 Berkontribusi untuk Aset Proses Organisasi

17.Manajemen Risiko (RSKM, Risk Management) SG 1 Menyiapkan Manajemen Risiko 

SP 1.1 Menentukan Sumber dan Kategori Risiko



SP 1.2 Mendefinisikan Parameter Risiko



SP 1.3 Membangun Strategi Manajemen Risiko

18.Analisis dan Resolusi Keputusan (DAR, Decision Analysis and Resolution) SG 1 Mengevaluasi Alternatif 

SP 1.1 Membangun Pedoman untuk Analisis Keputusan



SP 1.2 Membangun Kriteria Evaluasi



SP 1.3 Mengidentifikasi Solusi Alternatif



SP 1.4 Memilih Metode Evaluasi



SP 1.5 Mengevaluasi Alternatif



SP 1.6 Memilih Solusi

19.Kinerja Proses Organisasi (OPP, Organizational Process Performance) SG 1 Membangun Basis dan Model Kinerja 

SP 1.1 Memilih Proses



SP 1.2 Membangun Ukuran Kinerja Proses



SP 1.3 Membangun Sasaran Kualitas dan Kinerja Proses


20



SP 1.4 Membangun Basis Kinerja Proses



SP 1.5 Membangun Model Kinerja Proses

20.Manajemen Proyek Kuantitatif (QPM, Quantitative Project Management) SG 1 Mengelola Proyek Secara Kuantitatif 

SP 1.1 Membangun Sasaran Proyek



SP 1.2 Menyusun Proses Terdefinisi



SP 1.3 Memilih Subproses yang Akan Dikelola Secara Statistik



SP 1.4 Mengelola Proyek Kinerja

21.Inovasi dan Penerapan Organisasi (OID, Organizational Innovation and Deployment) SG 1 Memilih Perbaikan 

SP 1.1 Mengumpulkan dan Menganalisis Proposal Perbaikan



SP 1.2 Mengidentifikasi dan Menganalisis Inovasi



SP 1.3 Perbaikan Percontohan



SP 1.4 Memilih Perbaikan untuk Diterapkan

22.Analisis dan Resolusi Penyebab (CAR, Causal Analysis and Resolution) SG 1 Menentukan Penyebab Kecacatan 

SP 1.1 Memilih Data Kecacatan untuk Analisis



SP 1.2 Menganalisis Penyebab

2.3 COBIT ( Control Objectives for Information Technology ) COBIT adalah suatu panduan standar praktik manajemen teknologi informasi yang dimana menjadi sekumpulan dokumentasi best practices untuk IT


21

governance yang dapat membantu auditor, manajemen dan user untuk menjembatani gap antara risiko bisnis, kebutuhan kontrol dan permasalahanpermasalahan teknis. COBIT dikembangkan oleh IT Governance Institute, yang merupakan bagian dari Information Systems Audit and Control Association (ISACA). COBIT memberikan arahan ( guidelines ) yang berorientasi pada bisnis, dan karena itu business process owners dan manajer, termasuk juga auditor dan user, diharapkan dapat memanfaatkan guideline ini dengan sebaik-baiknya. COBIT Framework terdiri atas 4 domain utama: 1. Planning & Organisation :Domain ini menitik beratkan pada proses perencanaan dan penyelarasan strategi TI dengan strategi perusahaan. 2. Acquisition &Implementation :Domain ini menitik beratkan pada proses pemilihan, pengadaaan

dan penerapan teknologi

informasi

yang

digunakan. 3. Delivery &Support :Domain ini menitik beratkan pada proses pelayanan TI dan dukungan teknisnya. 4. Monitoring& Evaluation :Domain ini menitik beratkan pada proses pengawasan pengelolaan TI pada organisasi. COBIT mempunyai model kematangan(maturity models) untuk mengontrol proses-proses TI dengan menggunakan metode penilaian(scoring) sehingga suatu organisasi dapat menilai proses-proses TI yang dimilikinya dari skala nonexistent sampai dengan optimised (dari 0 sampai 5). Pendekatan ini diambil berdasarkan maturity model software engineering institute, terhadap tingkatan dalam model ini dikembangkan untuk tiap 34 proses COBIT.


22

COBIT menyediakan praktek yang baik di seluruh domain dan kerangka proses dan menyajikan kegiatan-kegiatan yang dikelola dengan baik dan dalam struktur yang logis. Praktek yang baik COBIT yang mewakili konsensus para ahli. mereka adalah sangat lebih berfokus pada kontrol, kurang pada eksekusi. Praktek ini akan membantu mengoptimalkan IT-enabled investasi, memastikan pengiriman pelayanan dan memberikan ukuran dan penilaian terhadap sistem ketika terjadi hal-hal yang salah. COBIT bermanfaat bagi auditor karena merupakan teknik yang dapat membantu dalam identifikasi IT controls issues. COBIT berguna bagi IT users karena

memperoleh

keyakinan

atas

kehandalan

sistem

aplikasi

yang

dipergunakan. Untuk kesuksesan TI terhadap kebutuhan bisnis, manajemen harus menempatkan

sistem

pengendalian

internal

atau

kerangka

kerja

di

dalam perusahaan. Kerangka pengendalian COBIT memberikan kontribusi untuk kebutuhan ini dengan: 1. Membuat link dengan kebutuhan bisnis (!) 2. Mengorganisasikan kegiatan TI ke dalam model proses yang berlaku umum 3. Mengidentifikasi sumber daya TI yang besar untuk dimanfaatkan 4. Mendefinisikan tujuan pengendalian manajemen untuk dipertimbangkan Orientasi bisnis COBIT terdiri dari menghubungkan tujuan bisnis untuk tujuan TI, menyediakan metrik dan model kematangan untuk mengukur prestasi mereka, dan mengidentifikasi tanggung jawab terkait bisnis dan TI proses internal. Fokus Proses COBIT digambarkan oleh model proses yang membagi IT menjadi empat domain dan 34 proses sesuai dengan tanggung jawab bidang perencanaan, membangun, menjalankan dan memantau, memberikan pandangan end-to-end TI. Konsep arsitektur enterprise membantu mengidentifikasi sumber


23

daya penting bagi keberhasilan proses, yaitu, aplikasi, informasi, infrastruktur dan manusia. Singkatnya, untuk memberikan informasi bahwa perusahaan perlu untuk mencapai tujuannya, sumber daya TI membutuhkan pengelolaan oleh satu set group proses secara alami .

Gambar 2.5 Hubungan komponen2 dalam COBIT Lingkup kriteria informasi yang sering menjadi perhatian dalam COBIT adalah: ● Effectiveness : Menitikberatkan pada sejauh mana efektifitas informasi dikelola dari data-data yang diproses oleh sistem informasi yang dibangun. ● Efficiency : Menitikberatkan pada sejauh mana efisiensi investasi terhadap informasi yang diproses oleh sistem. ● Confidentiality : Menitikberatkan pada pengelolaan kerahasiaan informasi secara hierarkis. ● Integrity : Menitikberatkan pada integritas data/informasi dalam sistem. ● Availability : Menitik beratkan pada ketersediaan data/informasi dalam sistem informasi.


24

● Compliance : Menitik beratkan pada kesesuaian data/informasi dalam sistem informasi. ● Reliability : Menitik beratkan pada kemampuan/ketangguhan sistem informasi dalam pengelolaan data/informasi. Sedangkan fokus terhadap pengelolaan sumber daya teknologi informasi dalam COBIT adalah pada: Applications, Information, Infrastructure, People. Kerangka kerja COBIT ini terdiri atas beberapa arahan ( guidelines ), yakni: 1. Control Objectives: Terdiri atas 4 tujuan pengendalian tingkat-tinggi ( high-level control objectives ) yang tercermin dalam 4 domain, yaitu: planning & organization , acquisition & implementation , delivery & support , dan monitoring . 2. Audit Guidelines: Berisi sebanyak 318 tujuan-tujuan pengendalian yang bersifat rinci ( detailed control objectives ) untuk membantu para auditor dalam memberikan management assurance dan/atau saran perbaikan. 3. Management Guidelines: Berisi arahan, baik secara umum maupun spesifik, mengenai apa saja yang mesti dilakukan, terutama agar dapat menjawab pertanyaan-pertanyaan berikut: ● Sejauh mana Anda (TI) harus bergerak, dan apakah biaya TI yang dikeluarkan sesuai dengan manfaat yang dihasilkannya? ● Apa saja indikator untuk suatu kinerja yang bagus? ● Apa saja faktor atau kondisi yang harus diciptakan agar dapat mencapai sukses ( critical success factors )? ● Apa saja risiko-risiko yang timbul, apabila kita tidak mencapai sasaran yang ditentukan? ● Bagaimana dengan perusahaan lainnya – apa yang mereka lakukan?


25

● Bagaimana Anda mengukur keberhasilan dan bagaimana pula membandingkannya? COBIT Framework memasukkan juga hal-hal berikut ini: ● Maturity Models – Untuk memetakan status maturity proses-proses TI (dalam skala 0 – 5) dibandingkan dengan “the best in the class in the Industry” dan juga International best practices ● Critical Success Factors (CSFs) – Arahan implementasi bagi manajemen agar dapat melakukan kontrol atas proses TI. ● Key Goal Indicators (KGIs) – Kinerja proses-proses TI sehubungan dengan business requirements ● Key Performance Indicators (KPIs) – Kinerja proses-proses TI sehubungan dengan process goals

Gambar 2.6 prinsip dasar COBIT COBIT dikembangkan sebagai suatu generally applicable and accepted standard for good Information Technology (IT) security and control practices . Istilah “ generally applicable and accepted ” digunakan secara eksplisit dalam pengertian yang sama seperti Generally Accepted Accounting Principles (GAAP).


26

Dapat dimulai dengan menentukan area-area yang relevan dan berisiko paling tinggi, melalui analisa atas ke-34 proses tersebut. Sementara untuk kebutuhan penugasan tertentu, misalnya audit atas proyek TI, dapat dimulai dengan memilih proses yang relevan dari proses-proses tersebut. Lebih lanjut, auditor dapat menggunakan Audit Guidelines sebagai tambahan materi untuk merancang prosedur audit. Singkatnya, COBIT khususnya guidelines dapat dimodifikasi dengan mudah, sesuai dengan industri, kondisi TI di Perusahaan atau organisasi Anda, atau objek khusus di lingkungan TI. Sedangkan para manajer memperoleh manfaat dalam keputusan investasi di bidang TI serta infrastrukturnya, menyusun strategic IT Plan, menentukan information

architecture,

dan

keputusan

atas

procurement

(pengadaan

/pembelian) aset. CobiT dikeluarkan oleh ITGI dapat diterima secara internasional sebagai praktek pengendalian atas informasi, IT dan resiko terkait.

Gambar 2.7 Definisi target gol TI dan arsitektur dalam perusahaan

2.3.1 Maturity Models Sebuah kebutuhan dasar bagi setiap perusahaan adalah untuk memahami status sendiri sistem TI dan memutuskan tingkat manajemen dan kontrol apa yang perusahaan harus sediakan. Untuk menentukan tingkat yang tepat, manajemen


27

harus bertanya sendiri: Seberapa jauh kita harus pergi, dan apakah biaya telah sesuai dengan manfaatnya? Manajer senior di perusahaan-perusahaan korporasi dan publik semakin diminta untuk mempertimbangkan seberapa baik TI dikelola. Sebagai tanggapan dengan ini, bisnis membutuhkan pengembangan untuk perbaikan dan mencapai tingkat yang tepat dari manajemen dan kontrol atas informasi infrastruktur. Sementara beberapa berpendapat bahwa ini bukan hal yang baik, mereka perlu mempertimbangkan keseimbangan biaya dan manfaatnya. Adapun pertanyaan yang terkait adalah: •Apakah yang telah dikerjakan oleh industri dan bagaimana menempatkan dalam hubungan dengan mereka? •Apakah

industri

menerima

praktek

yang

baik,

dan

bagaimana

menempatkan dengan praktek-praktek ini? •Berdasarkan perbandingan ini, apakah bisa dikatakan berbuat cukup? •Bagaimana kita mengidentifikasi apa yang diperlukan dan harus dilakukan untuk mencapai tingkat yang memadai dari manajemen dan kontrol atas proses TI ?

Gambar 2.8 Grafik posisi kematangan dalam TI proses


28

Menggunakan maturity model dikembangkan untuk setiap dari 34 COBIT TI proses,manajemen dapat mengidentifikasi : • Kinerja sebenarnya dari perusahaan sekarang ini • Status saat ini dengan perbandingan industri yang ada • Target perusahaan untuk perbaikan kedepan ingin menjadi apa • diperlukan pertumbuhan antara 'apa adanya' dan 'to-be' COBIT digunakan untuk menjalankan penentuan atas IT dan meningkatkan pengontrolan IT. COBIT juga berisi tujuan pengendalian, petunjuk audit, kinerja dan hasil metrik, faktor kesuksesan dan model kedewasaan.

Gambar 2.9 Grafik representasi kematangan model

Tabel 2.2 General level kematangan


29

Model maturity adalah cara untuk mengukur seberapa baik pengembangan proses manajemen, yaitu bagaimana mampu mereka sebenarnya. Bagaimana berkembang dengan baik atau kemampuan mereka harus terutama tergantung pada TI tujuan dan bisnis yang mendasari kebutuhan yang mereka dukung. Berapa kemampuan yang benar-benar digunakan sangat tergantung pada pengembalian yang perusahaan inginkan dari investasi. Misalnya, akan ada kritis proses dan sistem yang perlu keamanan yang lebih ketat. Disisi lain derajat dan kecanggihan kontrol yang perlu diterapkan dalam proses

lebih

didorong

oleh

selera

risiko

perusahaan

dan

persyaratan kepatuhan yang berlaku.

Gambar 2.10 Tiga dimensi kematangan Model maturity yang dibangun mulai dari model kualitatif generik (lihat gambar13) yang pada prinsipnya mengikuti atribut yang ditambahkan secara meningkat melalui tingkat: 

Kesadaran dan komunikasi



Kebijakan,rencana dan prosedur



Peralatan dan otomatisasi



Keterampilan dan keahlian


30



Tanggungjawab dan akuntabilitas



Penetapan tujuan dan pengukuran

Untuk meringkas, sumber daya TI yang dikelola oleh proses TI untuk mencapai target TI yang merespon kebutuhan bisnis. Ini adalah dasar prinsip dari kerangka COBIT, seperti yang digambarkan oleh kubus COBIT.

Gambar 2.11 Kubus COBIT 2.5 PMBOK ( Project Manajement Body of Knowledge ) Proyek perangkat Lunak adalah suatu pekerjaan yang dikerjakan oleh organisasi berskala kecil/besar ( dalam kebutuhan dana/SDM ) yang bersifat unik untuk kebutuhan organisasi. dengan memperhatikan : 1.

batasan waktu

2.

bersifat unik/tidak dikerjakan secara internal

3.

melibatkan vendor / konsultan

Dikarenakan besarnya invest TI dengan planning yang tidak matang, schedule yang selalu mundur dan quality control yang tidak sesuai.


31

Dalam PMBOK tahapan dalam proyek perangkat lunak secara custom adalah sebagai berikut: 1. Initiation : adalah tahapan inisisasi yaitu proses pertama yang dipergunakan untuk menandai awal proyek. Dokumen 2 dalam tahapan inisiasi adalah PRF, Project Chapter, CRF dan lain2nya. 2. Planning : Proses kedua mengenai

persyaratan yang berisi tentang

clients, project name, code, version, author, position dan lain2nya. Proses ke tiga Vendor manajement selection: tentang vendor2 yang terpilih dalam penanganan proyek. 3. Executing : Proses ke empat mengenai development project berisi penjadwalan pembangunan proyek, pengujian sistem secara terintegrasi (SIT). Proses ke lima pengujian berdasarkan hasil pemakaian oleh pengguna ( UAT ). 4. Implementation : Proses ke enam melakukan perencanaan implentasi sistem secra langsung. ( IMPLAN ), review proses , penyerahan dan pelatihan. Proses ke tujuh me review hasil pengujian, implementasinya dan penutupan proyek perangkat lunak. Adapun beberapa istilah yang perlu dipahami dalam tahapan2 proyek adalah sebagai berikut: A. Bussiness Requirement Documentation ( BRD ) Adalah rincian solusi bisnis untuk proyek termasuk dokumentasi kebutuhan pelanggan dan harapan. Jika inisiatif bermaksud untuk memodifikasi yang sudah ada (atau memperkenalkan baru) perangkat keras / perangkat lunak, BRD baru harus dibuat. Proses BRD dapat dimasukkan


32

dalam Six Sigma DMAIC (define, mengukur, menganalisa, memperbaiki, kontrol) budaya. Banyak perusahaan memiliki proses di tempat untuk membantu manajemen dan pelaksanaan proyek. Satu kesempatan untuk perbaikan melibatkan membuat perkiraan yang wajar dari seberapa besar sebuah proyek dan berapa banyak akan biaya. Ada banyak nama yang berbeda untuk alat digunakan dengan proses ini: bisnis spesifikasi kebutuhan, persyaratan spesifikasi atau, cukup, kebutuhan bisnis. Bisnis persyaratan adalah kegiatan kritis suatu perusahaan yang harus dilakukan untuk memenuhi tujuan organisasi,namun tetap solusi independen. B. Functional Specification Development Sebuah

spesifikasi

fungsional

(juga,

spesifikasi

fungsional,

spesifikasi, spesifikasi fungsional dokumen (FSD), fungsional persyaratan spesifikasi, atau spesifikasi program, atau Produk Persyaratan Dokumen "PRD") dalam sistem rekayasa dan pengembangan perangkat lunak merupakan dokumentasi yang menggambarkan perilaku yang diminta dari rekayasa sistem. Dokumentasi biasanya menggambarkan apa yang dibutuhkan oleh pengguna sistem serta sifat diminta input dan output (misalnya dari sistem perangkat lunak). C. Implementation Plan ( IMPLAN ) Rencana Implementasi adalah alat manajemen untuk ukuran kebijakan tertentu, atau paket kebijakan, yang dirancang untuk membantu lembaga untuk mengelola dan memantau pelaksanaan efektif. Rencana implementasi dimaksudkan untuk menjadi scalable dan fleksibel; mencerminkan tingkat urgensi, kompleksitas inovasi, dan / atau sensitivitas yang terkait dengan ukuran kebijakan tertentu. Agen diharapkan melakukan penilaian di daerah ini, namun tingkat detail harus cukup untuk memungkinkan lembaga tersebut untuk secara efektif mengelola pelaksanaan tindakan kebijakan. Minimal, rencana harus mencerminkan standar yang diuraikan dalam Panduan untuk Rencana Pelaksanaan Persiapan,


33

D. Project Request Form ( PRF ) Sebuah formulir permintaan yang diisi oleh user untuk permintaan baru atau modifikasi aplikasi. E. Project Plan ( PP ) Setelah sebuah proyek didefinisikan, langkah selanjutnya adalah merencanakan proyek yang dimaksud. Perencanaan proyek ini biasanya dalam

bentuk

dokumen

perencanaan

manajemen

proyek

(project

management plan). Pada intinya, perencanaan manajemen proyek ini adalah deskripsi detail dari definisi proyek yang telah dibuat. Perencanaan proyek secara umum berisi: tujuan & ruang lingkup proyek (scope management), waktu pengerjaan atau jadwal proyek (time management), rencana anggaran biaya proyek (cost management), kualitas proyek (quality management), sumber daya proyek (resource management), manajemen resiko (risk management), perencanaan komunikasi (communication management), pengadaan

(procurement

management),

serta

integrasi

(integration

management. F. Request Form Change ( RFC ) Formulir yang digunakan untuk menjelaskan permintaan perubahan pada aplikasi. Proses Pengendalian Perubahan adalah penting untuk keberhasilan pengiriman proyek. Proses Change Control memastikan bahwa setiap perubahan diperkenalkan ke lingkungan proyek dengan tepat didefinisikan, dievaluasi dan disetujui sebelum implementasi. G. Sistem Integration Test ( SIT ) Pengujian sistem secara ter integrasi apakah berjalan lancar sesuai yang direncanakan pada tahapan sebelumnya. H. User Acceptance Test ( UAT ) Pengujian berdasarkan pemakaian oleh user apakah masih ada kekurangan dari penerimaaan sistem. 2.5 VISUAL BASIC 6.0


34

Visual Basic adalah salah satu bahasa pemrograman komputer. Bahasa pemrograman adalah perintah perintah yang dimengerti oleh komputer untuk melakukan tugas-tugas tertentu. Bahasa pemrograman Visual Basic, yang dikembangkan oleh Microsoft sejak tahun 1991, merupakan pengembangan dari pendahulunya yaitu bahasa pemrograman BASIC (Beginner’s All-purpose Symbolic Instruction Code) yang dikembangkan pada era 1950-an. Visual Basic merupakan salah satu Development Tool yaitu alat bantu untuk membuat berbagai macam program komputer, khususnya yang menggunakan sistem operasi Windows. Visual Basic merupakan salah satu bahasa pemrograman komputer yang mendukung object (Object Oriented Programming = OOP). Visual Basic merupakan bahasa pemrograman yang sangat mudah dipelajari, dengan teknik pemrograman visual yang memungkinkan penggunanya untuk berkreasi lebih baik dalam menghasilkan suatu program aplikasi. Ini terlihat dari dasar pembuatan dalam visual basic adalah FORM, dimana pengguna dapat mengatur tampilan form kemudian dijalankan dalam script yang sangat mudah. 2.5.1 Konsep Dasar Pemrograman Dalam Visual Basic 6.0 Konsep dasar pemrograman Visual Basic 6.0, adalah pembuatan form dengan mengikuti aturan pemrograman Property, Metode dan Event. Hal ini berarti: 1. Property: Setiap komponen di dalam pemrograman Visual Basic dapat diatur propertinya sesuai dengan kebutuhan aplikasi. Property yang tidak boleh dilupakan pada setiap komponen adalah “Name”, yang berarti nama variabel (komponen) yang akan digunakan dalam scripting. Properti “Name” ini hanya bisa diatur melalui jendela Property, sedangkan nilai peroperti yang lain bisa diatur melalui script seperti Command1.Caption=”Play” Text1.Text=”Visual Basic”


35

Label1.Visible=False Timer1.Enable=True 2. Metode: Bahwa jalannya program dapat diatur sesuai aplikasi dengan menggunakan metode pemrograman yang diatur sebagai aksi dari setiap komponen. Metode inilah tempat untuk mengekpresikan logika pemrograman dari pembuatan suatu prgram aplikasi. 3. Event: Setiap komponen dapat beraksi melalui event, seperti event click

pada

command

button

yang

tertulis

dalam

layar

script

Command1_Click, atau event Mouse Down pada picture yang tertulis dengan Picture1_MouseDown. Pengaturan event dalam setiap komponen yang akan menjalankan semua metode yang dibuat. Dalam pemrograman berbasis obyek (OOP), perlu memahami istilah object, property, method dan event sebagai berikut :  Object : komponen di dalam sebuah program  Property : karakteristik yang dimiliki object  Method : aksi yang dapat dilakukan oleh object  Event : kejadian yang dapat dialami oleh object Sebagai ilustrasi dapat menganggap sebuah mobil sebagai obyek yang memiliki property, method dan event. Perhatikan gambar berikut :


36

Gambar 2.12 Konsep pemrograman dengan obyek Implementasinya dalam sebuah aplikasi misalnya kita akan membuat form, maka form tersebut memiliki property, method, dan event. Sebagaimana pemrograman visual lain seperti Delphi dan Java, VB juga bersifat event driven progamming. Artinya kita dapat menyisipkan kode program pada event yang dimiliki suatu obyek. 2.6

UML ( Unified Modeling Language ) Use Case Diagram Untuk model sistem aspek yang paling penting adalah untuk menangkap

perilaku dinamis. Untuk memperjelas sedikit di rincian, perilaku dinamis berarti perilaku sistem saat berjalan / beroperasi. Jadi hanya perilaku statis tidak cukup untuk model sistem perilaku yang agak dinamis lebih penting daripada perilaku statis. Dalam UML ada lima diagram tersedia ke alam model dinamis dan use case diagram adalah salah satunya. Sekarang karena kami harus membicarakan bahwa diagram use case adalah dinamis di alam harus ada beberapa faktor internal atau eksternal untuk membuat interaksi. Para agen internal dan eksternal dikenal sebagai aktor. Jadi gunakan diagram kasus yang terdiri dari aktor, kasus penggunaan dan hubungan mereka.


37

Diagram ini digunakan untuk memodelkan sistem / subsistem dari sebuah aplikasi. Diagram penggunaan tunggal kasus menangkap fungsionalitas tertentu dari suatu sistem. Jadi untuk model nomor seluruh sistem diagram use case digunakan. Tujuan dari use case diagram adalah untuk menangkap aspek dinamis dari suatu sistem. Tapi definisi ini terlalu umum untuk menggambarkan tujuan. Karena lainnya empat diagram (aktivitas, urutan, kolaborasi dan Statechart) juga memiliki tujuan yang sama. Jadi kita akan melihat ke dalam beberapa tujuan tertentu yang akan membedakannya dari lainnya empat diagram. Gunakan diagram kasus digunakan untuk mengumpulkan persyaratan sistem termasuk pengaruh internal dan eksternal. Persyaratan ini sebagian besar persyaratan desain. Jadi ketika sistem dianalisis untuk mengumpulkan fungsionalitas use case siap dan pelaku diidentifikasi. Sekarang ketika tugas awal adalah diagram lengkap menggunakan kasus dimodelkan untuk menyajikan pandangan luar. Jadi secara singkat, tujuan diagram use case dapat sebagai berikut: 

Digunakan untuk mengumpulkan persyaratan dari suatu sistem.



Digunakan untuk mendapatkan pandangan luar dari suatu sistem.



Identifikasi faktor eksternal dan internal yang mempengaruhi sistem.



Tampilkan berinteraksi antara persyaratan adalah aktor. Diagram Gunakan kasus dianggap untuk kebutuhan analisis tingkat tinggi

dari suatu sistem. Jadi, ketika persyaratan sistem dianalisis fungsi ditangkap dalam kasus digunakan. Sekarang hal-hal kedua yang relevan dengan kasus penggunaan adalah aktor. Aktor dapat didefinisikan sebagai sesuatu yang berinteraksi dengan sistem. Para aktor bisa menjadi pengguna manusia, beberapa aplikasi internal atau mungkin ada beberapa aplikasi eksternal. Jadi secara singkat ketika kami


38

merencanakan untuk menggambar diagram use case kita harus memiliki item berikut diidentifikasi. 

Fungsi untuk diwakili sebagai use case



Aktor



Hubungan antara kasus penggunaan dan aktor.

Diagram Gunakan kasus diambil untuk menangkap kebutuhan fungsional dari suatu sistem. Jadi setelah mengidentifikasi item di atas kita harus mengikuti pedoman berikut untuk menggambar diagram use case efisien. 

Nama use case sangat penting. Jadi nama harus dipilih sedemikian rupa sehingga dapat mengidentifikasi fungsi dilakukan.



Berikan nama yang cocok untuk aktor.



Tampilkan hubungan dan ketergantungan dengan jelas dalam diagram.



Jangan mencoba untuk mencakup semua jenis hubungan. Karena tujuan utama diagram adalah untuk mengidentifikasi persyaratan.



Gunakan diperhatikan ketika pernah diminta untuk menjelaskan beberapa poin penting.

2.7

FLOWCHART

Flowchart adalah penggambaran secara grafik dari langkah-langkah dan urut-urutan prosedur dari suatu program. Flowchart menolong analis dan programmer untuk memecahkan masalah kedalam segmen-segmen yang lebih kecil dan menolong dalam menganalisis alternatif-alternatif lain dalam pengoperasian. Flowchart biasanya mempermudah penyelesaian suatu masalah khususnya masalah yang perlu dipelajari dan dievaluasi lebih lanjut. 1. Flowchart terbagi atas lima jenis, yaitu : 2. Flowchart Sistem (System Flowchart) 3. Flowchart Paperwork / Flowchart Dokumen (Document Flowchart)


39

4. Flowchart Skematik (Schematic Flowchart) 5. Flowchart Program (Program Flowchart) Process Flowchart)

6.

Program flowchart adalah salah satu yang dapat didefinisikan sebagai bagan yang menjelaskan secara rinci langkah – langkah dari proses program ( Jogiyanto, HM : 1990 ). Simbol – Simbol Flowchart Diagram Simbol

Nama symbol Terminal

Processing

Keterangan Untuk menggambarkan awal dan akhir proses aliran dokumen

Dipakai

untuk

pengolahan

aritmatika dan pemindahan data

Dipakai untuk memberikan nilai Preparation

awal dari suatu variable atau counter

Decision

Predefined process

Garis alir

Dipakai untuk mewakili operasi perbandingan logika Dipakai

untuk

yang

detailnya djelaskan secara terpisah , misalnya dalam bentuk subroutine Dipakai untuk menunjukkan aliran dari program Menunjukkan

Penghubung

proses

penghubung

di

halaman yang masih sama atau dihalaman lainnya


40

Mewakili data input atau output Input / Output

Gambar 2.13 Simbol – Simbol Flowchart 2.8

DATABASE Microsoft Acces Aplikasi Database memungkinkan pemakai aplikasi berinteraksi dengan

informasi yang tersimpan pada Database. Database menyediakan struktur informasi yang memungkinkan berbagai data diantara beberapa aplikasi. Visual Basic mendukung aplikasi database. Microsoft Access adalah aplikasi yang dapat digunakan untuk membuat aplikasi database dalam waktu yang relatif singkat. Umumnya Microsoft acces digunakandalam pembuatan aplikasi dalam skala kecil, seperti program untuk kasir pada sebuahkoperasi, aplikasi penjualan toko, membuat billing warnet dll. Berikut adalah komponen yang ada di Microsoft access a.Tabel berfungsi untuk menyimpan data b. Query berfungsi untuk memanipulasi data c. Form berfungsi untuk frontend aplikasi. d. Report berfungsi untuk membuat laporan e. Macro berfungsi untuk melakukan satu atau beberapa fungsi. f. Switchboard berfungsi untuk mendisign Menu UtamaDari fungsi-fungsi di atas.


BAB II LANDASAN TEORI. 2.1 DEFINISI CMM ( Capability Maturity Model )

Recommend Documents