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

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.

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.

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

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.

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 ).

Gambar 2.3 CMMI komponen model

Komponen-komponen diharapkan menggambarkan apa yang dapat diterapkan organisasi untuk mencapai komponen yang diperlukan.

Komponen-komponen diharapkan juga membimbing mereka yang 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 dan tujuan usahanya. Meskipun ada beberapa batasan

pada apa yang organisasi dapat memilih karena dependensi

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

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.

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

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.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.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)

 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 )

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.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

governance yang dapat membantu auditor, manajemen dan user untuk menjembatani gap antara risiko bisnis, kebutuhan kontrol dan permasalahan-permasalahan 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 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

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

● 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 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).

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

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 ?

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

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

 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.

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

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,

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.

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”

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 :

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.

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

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

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

6. Process Flowchart)

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 Keterangan

Terminal Untuk menggambarkan awal dan akhir proses aliran dokumen

Processing Dipakai untuk pengolahan

aritmatika dan pemindahan data

Preparation

Dipakai untuk memberikan nilai awal dari suatu variable atau counter

Decision Dipakai untuk mewakili operasi

perbandingan logika Predefined

process

Dipakai untuk proses yang detailnya djelaskan secara terpisah , misalnya dalam bentuk subroutine

Garis alir Dipakai untuk menunjukkan aliran

dari program

Penghubung

Menunjukkan penghubung di halaman yang masih sama atau dihalaman lainnya

Input / Output

Mewakili data input atau 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.