The Capability Maturity Model (CMM)

Capability Maturity Model disingkat CMM adalah model kematangan kapabilitas) adalah suatu model kematangan kemampuan (kapabilitas) proses yang dapat membantu pendefinisian dan pemahaman proses-proses suatu organisasi. Pengembangan model ini dimulai pada tahun 1986 oleh SEI (Software Engineering Institute) Departemen Pertahanan Amerika Serikat di Universitas Carnegie Mellon di Pittsburgh, Amerika Serikat.
CMM awalnya ditujukan sebagai suatu alat untuk secara objektif menilai kemampuan kontraktor pemerintah untuk menangani proyek perangkat lunak yang diberikan. Walaupun berasal dari bidang pengembangan perangkat lunak, model ini dapat juga diterapkan sebagai suatu model umum yang membantu pemahaman kematangan kapabilitas proses organisasi di berbagai bidang. Misalnya rekayasa perangkat lunak, rekayasa sistem, manajemen proyek, manajemen risiko, teknologi informasi, serta manajemen sumber daya manusia.
Meskipun masih secara luas digunakan sebagai alat umum, pada bidang pengembangan perangkat lunak, CMM telah digantikan oleh CMMI (Capability Maturity Model Integration). CMM sendiri telah diganti namanya menjadi SE-CMM (Software Engineering CMM).

Capability Maturity Model (CMM) adalah suatu kerangka untuk menaksir level kedewasaan (maturity) dari pengembangan sistem informasi dari suatu organisasi serta manajemen proses dan produk. CMM terdiri dari 5 maturity level, antara lain :

- Level 1 – Initial :
Level ini hiasa disebut anarchy atau chaos. Pada pengembangan sistem ini masing – masing developer menggunakan peralatan dan metode sendiri. Berhasil atau tidaknya tergantung dari project teamnya. Project ini seringkali menemukan saat – saat krisis, kadang kelebihan budget dan di belakang rencana. Dokumen sering tersebar dan tidak konsisten dari satu project ke project lainnya.

- Level 2 – Repeatable :
Proses project management dan prakteknya telah membuat aturan tentang biaya projectnya, schedule, dan funsionalitasnya. Fokusnya adalah pada project management bukan pada pengembangan sistem. Proses pengembangan sistem selalu diikuti, tetapi akan berubah dari project ke project. Sebuah konsep upaya dibuat untuk mengulang kesuksesan project dengan lebih cepat.

- Level 3 – Defined :
Standard proses pengembangan sistem telah dibeli dan dikembangkan dan ini telah digabungkan seluruhnya dengan unit sistem informasi dari organisasi. Dari hasil penggunaan proses standard, masing – masing project akan mendapatkan hasil yang konsisten dan dokumentasi dengan kualitas yang baik dan dapat dikirim. Proses akan bersifat stabil, terprediksi, dan dapat diulang.

- Level 4 – Managed :
Tujuan yang terukur untuk kualitas dan produktivitas telah dibentuk. Perhitungan yang rinci dari standard proses pengembangan sistem dan kualitas produk secara rutin akan dikumpulkan dan disimpan dalam database. Terdapat suatu usaha untuk mengembangkan individual project management yang didasari dari data yang telah terkumpul.

- Level 5 – Optimized :
Proses pengembangan sistem yang distandardisasi akan terus dimonitor dan dikembangkan yang didasari dari perhitungan dan analisis data yang dibentuk pada level 4. Ini dapat termasuk perubahan teknologi dan praktek – praktek terbaik yang digunakan untuk menunjukkan aktivitas yang diperlukan pada standard proses pengembangan sistem .

Level – level di atas mempengaruhi level – level di bawahnya.

Lantas, apa yang bisa dimanfaatkan dari penerapan CMM?
Jika melihat tingkatan-tingkatan yang harus dilalui untuk memperoleh “predikat matang” menurut standar CMM maka suatu organisasi harus memiliki road-map dari pengembangan aplikasi softwarenya.
Road-map tersebut harus berangkat dari visi dan misi organisasi sehingga aplikasi softwarenya akan berkembang selaras dengan tujuan-tujuan yang ditetapkan oleh organisasi tersebut.
Selain dari sisi internal, CMM sendiri dapat digunakan untuk mengukur “tingkat kemapanan” sebuah organisasi yang akan direkrut sebagai kontraktor proyek-proyek kita.
Misalkan PT. X ingin mengembangkan aplikasi software ERP untuk internal perusahaannya.
Nah, PT. X kemudian mengundang PT. A, PT. B dan PT. C untuk menjadi calon kontraktor yang akan melaksanakan proses pengembangan hingga transfer pengetahuan.
Dengan menggunakan CMM maka PT. X dapat mengukur “tingkat kemapanan” dari masing-masin calon kontraktor tersebut.
Dari hasil penilaian tersebut maka dapat ditentukan perusahaan mana yang akan menjadi kontraktor berdasarkan Level menurut CMM.
PT. X tentunya akan memilih perusahaan yang sudah mencapai setidaknya Level 4 demi menjamin kesuksesan implementasi proyeknya.
Untuk informasi lebih lanjut mengenai CMM maupun CMMI dapat diakses di situs-situs berikut:
http://www.sei.cmu.edu/cmmi/
http://en.wikipedia.org/wiki/Capability_Maturity_Model#Level_1_-_Ad_hoc_.28Chaotic.29
http://www.opengroup.org/architecture/togaf8-doc/arch/chap27.html
http://www.sei.cmu.edu/cmm/
http://www.sei.cmu.edu/cmm/papers/9001-cmm.pdf

PMRPL : Perbedaan Metodologi, Metoda,....

contoh dari :

1. Framework : SW - CMM --> CMMI Dev
2. Motodologi : SDLC , RUP
3. Metoda : UML, Black Box Testing
4. Prosedur : Change Request

Business Process Reengineering (BRP)

Changes fundamentally how the organization does certain operations

Goal:
Radical redesign of business processes

=========================

Outcome Analysis :
-Consider desirable outcomes from customers’ perspective
-Consider what the organization could enable the customer to do

Technology Analysis :

-Analysts list important and interesting technologies
-Managers list important and interesting technologies
-The group identifies how each might be applied to the business and how the business might benefit

Activity Elimination :

-Identify what would happen if each organizational activity were eliminated
-Use “force-fit” to test all possibilities

TSBD : Dekomposisi

Dekomposisi adalah teknik memecah sebuah relasi menjadi beberapa relasi. Kemudian setelah relasi tersebut dipecah bila digabungkan kembali harus mendapat hasil yang sama, tidak boleh record yang hiulang maupun record tambahan.

Bila kondisi ini terpenuhi maka ini yang disebut Lessloss-join decomposition.

Contohnya sebuah dekomposisi yang non-Lossless-join:

R1 A B X 1 X 2 Y 1

Dekomposisi =>

R2 A X Y

R3 B 1 2

Bila kedua relasi R2 dan R3 digabung kembali maka akan didapat:

R4
A	B
X	1
X	2
Y	1
Y	2

Kondisi ini yang disebut Lossy join decomposition.

Untuk menghindari dekomposisi Lossy-join maka pada relasi hasil dekomposisi harus memiliki attribut yang beririsan. Contohnya adalah pada Relasi StaffBranch diatas didekomposisi menjadi Relasi Staff dan Relasi Branch dimana attribut BranchNo sebagai irisannya.

Ada dua properti penting dalam dekomposisi yaitu Lossless-join Property dan Dependency Preservation Property. Dalam sebuah dekomposisi apakah memenuhi kaidah Lossless-join dan apakah memenuhi kaidah Dependency Preservation.

Masih bingung??? sama saya juga, mari kita lihat lagi.

Untuk mendapatkan dekomposisi yang Lossless-join harus ada attribut yang beririsan namun harus hati hati supaya dekomposisi harus juga Dependency Preserving. Untuk bisa mendapatkan Dependency Preserving syaratnya adalah constraint yang berlaku direlasi awal harus juga berlaku di relasi hasil dekomposisi. Berikut contohnya:

PhoneAddress
Mahasiswa	NoHP	Operator
Wawan	0815 06	Matrix
Wawan	0817 07	Pro XL
Aan	0815 08	Matrix
Nuri	0812 09	Simpati

Tanda “→” dibaca “menentukan”

Relasi PhoneAddress kemudian dengan cara pertama didekomposisi menjadi:

PA1 Mahasiswa NoHP Wawan 0815 06 Yoseph 0817 07 Aan 0815 08 Nuri 0812 09

→

PA2 NoHP Operator 0815 06 Matrix 0817 07 Pro XL 0815 08 Matrix 0812 09 Simpati

Constraint awal adalah {Mahasiswa → NoHP, NoHP → Operator}, kemudian dari dua relasi diatas ada irisan yaitu attribut {NoHP}, dengan demikian ketika kita merujuk salah satu nama Mahasiwa pada relasi PA1 maka kita akan dapat NoHP, berbekal NoHP ketika kita pergi ke PA2 kita bisa mendapat nama Operator.

Sekarang kita pakai cara dekomposisi kedua:

PA1 Mahasiswa NoHP Wawan 0815 06 Yoseph 0817 07 Aan 0815 08 Nuri 0812 09

→

PA2 Mahasiswa Operator Wawan Matrix Yoseph Pro XL Aan Matrix Nuri Simpati

Constraint awal adalah {Mahasiswa → NoHP, NoHP → Operator}, kemudian dari dua relasi diatas ada irisan yaitu attribut {Mahasiswa}, ketika kita merujuk salah satu nama Mahasiwa pada relasi PA1 maka kita akan dapat NoHP, berbekal NoHP kita tidak dapat mendapat nama Operator pada relasi PA2.

Dekomposisi cara kedua diatas juga Lossless-join karena memiliki attribut irisan {Mahasiswa} tapi tidak Dependency Preserving karena constraint yang berlaku pada awal relasi sebelum didekomposisi tidak berlaku lagi.

Untuk ringkasnya lihatyang beriku tini:

• Ada sebuah Relasi: R = (A, B, C)
  Constraint F = {A → B, B → C}
  • Dapat didekomposisi dalam dua cara.
• Cara pertama: R1 = (A, B), R2 = (B, C)
  • Lossless-join decomposition: R1 → R2 = {B} dan B → BC
  • Dependency preserving
• Cara kedua: R1 = (A, B), R2 = (A, C)
  • Lossless-join decomposition: R1 → R2 = {A} dan A → AB
  • Not dependency preserving

Apa itu dependency (ketergantungan)? Dependency secara garis geras ada dua macam yaitu Functional Dependency dan Multivalued Denpendency.

TSBD: NORMALIZATION

Normalizationis a technique for producing a set of suitable relations that support the data requirements of an enterprise.
Characteristics of a suitable set of relations include:
the minimalnumber of attributes necessary to support the data requirements of the enterprise;
minimalredundancy with each attribute represented only once with the important exception of attributes that form all or part of foreign keys.
The benefits of using a database that has a suitable set of relations is that the database will be:
easier for the user to access and maintain the data;
take up minimal storage space on the computer

Normalisasi Tabel

Pada OLTP (online transaction processing), normalisai adalah suatu upaya penting yang dilakukan untuk menghindari agar tidak terjadi redundansi data yang bisa berakibat kepada anomali update. Anomali update meliputi anomali insert, anomali delete, anomali modification. Untuk lebih jelasnya bisa dilihat ilustrasi dari contoh berikut :

---------------------------------------------------------

StaffBranch = {staffNo, sName, position, salary, branchNo, bAddress }

Staff = {staffNo, sName, position, salary, branchNo }

Branch = {branchNo, bAddress}

---------------------------------------------------------

Berdasarkan atas contoh tabel (relation) di atas, data yang terkait staf dan cabang dapat direpresentasikan dalam dua cara :

• Cukup disediakan satu tabel, yaitu StaffBranch
• Disediakan dua tabel, yaitu Staf dan Branch

Pada tabel StaffBranch terdapat redundansi data cabang, dimana detil dari cabang terjadi pengulangan untuk setiap staf. Sebaliknya, informasi cabang hanya muncul sekali untuk setiap cabang pada tabel Branch, dan hanya branchNo yang berulang di dalam tabel Staff untuk merepresentasikan lokasi kerja staf.

Bagaimana anomali bisa terjadi pada StaffBranch?

• Contoh 1 : Misalkan terjadi transaksi penambahan (insert) staf baru, maka yang dilakukan tidak cukup hanya mengisi data staf tetapi berikut data cabangnya. Jika data cabang untuk staf baru sudah ada sebelumnya, maka ada kemungkinan pengisian ulang data cabang dengan nilai yang berbeda. Dengan demikian, akan terjadi inkonsistensi data cabang.
• Contoh 2 : Misalkan terjadi transaksi penghapusan data (delete) staf dan pada target record tidak terdapat pengulangan data cabang, proses akan berdampak pada hilangnya data cabang yang mestinya tidak ikut terhapus.
• Contoh 3 : Misalkan terjadi transaksi perubahan/modifikasi (update) data cabang untuk data cabang yang mengalami perulangan. Proses bisa menimbulkan inkonsistensi data jika proses perubahan tidak untuk seluruh record terkait.

Untuk melakukan proses normalisasi, perlu dipahami terlebih dahulu konsep utama dalam normalisasi yaitu ketergantungan fungsional (functional dependency). Functional dependency adalah hubungan antar antribut di dalam suatu tabel. Jika A dan B adalah atribut-atribut yang ada di dalam tabel R, B tergantung secara fungsional terhadap A, jika setiap nilai A di dalam R berelasi hanya dengan satu nilai B (ditulis A àB). Dalam hal ini, A disebut sebagai determinant.

Karakteriktik dari ketergantungan fungsional pada normalisasi adalah :

• Berelasi satu dan hanya satu (1:1).
• Berlaku (terjaga konsistensinya) untuk kapan saja.
• Nontrivial. Trivial dependency adalah ketergantungan fungsional dimana non determinant tergantung pada superset. Contoh StaffNo, StaffAddress → StaffAddress adalah trivial selama StaffAddress → StaffAddress.

Selain memahami ketergantungan fungsional, beberapa jenis ketergantungan berikut ini perlu untuk diketahui :

• Trivial dependency, adalah ketergantungan fungsional dimana non determinant tergantung pada superset. Contoh StaffNo, StaffAddress → StaffAddress adalah trivial selama StaffAddress → StaffAddress.
• Full functional depencey, adalah ketergantungan dimana non determinant tergantung penuh pada (seluruh) determinant. Misalkan OrderNo, PoductNo → Price.
• Transitive dependency, adalah suatu hubungan ketergantungan fungsional yang terjadi secara tidak langsung.Contoh A → B, B → C, maka secara tidak langsung terjadi ketergantungan A → C.

Dalam proses normalisasi, perlu juga memahami konsep beberapa tingkatan nilai kunci (key) berikut ini:

· Superkey, adalah sebuah atribuat atau sebuah himpunan atribut yang secara unik dapat mengidentifikasi record dalam tabel. Contoh informasi keahlian staf dalam tabel StaffSkill bisa memiliki superkey StaffNo, StaffAddress, Skill, atau cukup StaffNo, Skill.

· Candidate key, adalah superkey yang tidak terdapat subset yang merupakan superkey.Dari kedua contoh superkey di atas, candidate key yang tepat adalah StaffNo, Skill.

· Primary key, adalah candidate key yang terpilih untuk mengidentifikasi nilai yang unik dalam suatu tabel.

· Alternate key, adalah candidate key yang tidak terpilih.

Tahapan normalisasi :

· UNF (unnormalized form), adalah tabel yang masih memiliki satu atau lebih kelompok berulang (repeating group).

· 1NF (first normal form), adalah tabel yang hanya terdapat satu dan hanya satu nilai untuk irisan baris dan kolomnya. Diperoleh dengan menghilangkan kelompok berulang pada UNF, antara lain dengan membentuk tabel baru pada kelompok yang berulang dengan menyertakan (kopi) kuncinya.

· 2NF (second normal form), adalah tabel yang seluruh non determinannya bergantung penuh (bukan subset) pada determinant, jadi tidak terjadi partial dependency. Diperoleh dengan menghilangkan partial dependency dengan membentuk tabel baru yang menyertakan determinannya.

· 3NF (third normal form), adalah tabel yang tidak terdapat hubungan transitive di dalamnya. Diperoleh dengan menghilangkan transitive dependency dengan membentuk tabel baru yang menyertakan determinannya.

· BCNF(Boyce–Codd Normal Form), adalah tabel yang memiliki persyaratan 3NF dengan tambahan batasan determinan harus candidate key.Perbedaan antara 3NF dengan BCNF adalah (misalkan untuk relasi A → B), pada 3NF B boleh sebuah atribute primary key dan A bukan candidate key, sedangkan pada BCNF untuk relasi tersebut A harus candidate key. Dengan demikian BCNF tentu 3NF, tetapi 3NF belum tentu BCNF.

· 4NF (fourth normal form), adalah tabel yang memiliki persyaratan BCNF dan non-trivial MVD(multivalued dependency). Contoh di dalam tabel BranchStaffOwner terdapat relasi MVD branchNo → StaffName, OwnerName. Antara StaffName dan OwnerName masing-masing independen. Jadi untuk 4NF bisa dikembangkan menjadi branchNo → StaffName dan branchNo → OwnerName.

· 5NF (fifth normal form), adalah tabel yang tidak memiliki join dependency.Kasus ini jarang terjadi.

· Higher normal forms.

Dalam suatu proses normalisasi kemungkinan bisa terjadi lompatan kondisi dari suatu level normal ke dua atau bahkan lebih level di atasnya. Hal ini lebih besar kemungkinannya pada tabel-tabel atau entitas-entitas memiliki relationship yang sederhana, atau dengan kata lain jumlah entitas yang terkait sedikit. Misalkan pada proses normalisasi 1NF ke 2NF telah dilakukan proses penghilangan partial depency, dan hasilnya terbentuk relationship baru yang bisa saja sudah tidak terdapat transitive depdendency, atau bahkan sudah memenuhi kriteria level di atasnya.Namun demikian, validasi normalisasi masih penting untuk dilakukan untuk bisa lebih memastikannya.