Mendebug Database Production

Suatu aplikasi, walaupun sudah go-live di environment production, tetap bisa saja mengalami error dan bug. Bug ini seringkali tidak ditemukan di environment development karena berbagai hal, misalnya variasi data, jumlah data, dan sebagainya.

Langkah pertama ketika kita mengetahui ada bug tentunya adalah melokalisir masalah. Pada kondisi mana saja bug tersebut muncul. Setelah itu, kita dapat memfokuskan pencarian masalah di lokasi tersebut. Ini lebih efisien daripada kita harus menelusuri keseluruhan sistem.

Misalnya kita sudah berhasil melokalisir masalah, yaitu transaksi di bulan tertentu. Langkah selanjutnya adalah memindahkan data production di lokasi tersebut ke environment development. Ini kita lakukan supaya kita bebas bereksperimen dengan data tersebut tanpa khawatir membahayakan data production.

Masalahnya, tools backup database yang tersedia biasanya tidak bisa digunakan untuk mengambil sebagian data. Walaupun bisa (mysqldump menyediakan opsi where untuk membatasi record yang diambil), biasanya terbatas hanya di satu tabel saja. Sedangkan untuk bisa merestore-nya di development, kita butuh semua relasinya.

Sebagai contoh, coba lihat skema berikut.

Untuk mengambil data payment, tentunya kita juga harus menarik data lain yang berelasi dengannya, yaitu di tabel grup loket, loket, payment value, payment info dan fee loket. Ini sangat sulit dilakukan, apalagi kalau data payment tersebut jumlahnya ratusan ribu record.

Untunglah ada tools untuk mengatasi masalah ini, namanya Jailer. Dengan menggunakan Jailer, kita dapat menentukan tabel mana yang akan diambil datanya (payment), kriteria pengambilan (bulan tertentu saja), dan relasi mana saja yang ingin kita ambil. Hasilnya adalah satu set data lengkap dengan dependensinya yang bisa kita restore di development.

Persiapan Jailer

Pertama, tentunya kita unduh dulu Jailer di websitenya. Jangan lupa teriakkan, “Hidup Open Source !!!”, karena aplikasi ini tersedia secara gratis berkat gerakan open source.

Setelah berhasil diunduh, extract ke folder tertentu. Jailer tidak menyertakan driver untuk koneksi ke database, sehingga kita harus sediakan sendiri. Karena saya menggunakan MySQL, saya masukkan file mysql-connector.jar ke dalam folder lib. Kita mengikutkan driver database ke folder Jailer karena nantinya folder ini akan kita pack dan upload ke server production.

Jailer ini akan kita jalankan di mesin development yang sudah terisi skema database. Kita akan coba dulu ambil data di development, kalau sudah sukses baru kita jalankan di production.

Ada dua script untuk menjalankan jailer, yaitu jailerGUI dan jailer. jailerGUI digunakan untuk mendesain pengambilan data, sedangkan jailer adalah antarmuka command line untuk menjalankan pengambilan data. Karena kita ingin mendesain proses pengambilannya, kita gunakan jailerGUI.

1. $ sh jailerGUI.sh

$ sh jailerGUI.sh 

Berikut adalah tampilan awal Jailer.

Jailer memberitahu kita bahwa belum ada data model yang bisa dikerjakan, dan menyarankan kita untuk menganalisa database. Klik Analyze Database. Selanjutnya Jailer akan meminta informasi cara koneksi ke database.


Isikan informasi koneksi database dan driver yang digunakan. Driver yang kita gunakan adalah yang tadi sudah kita copy ke folder lib.


Klik OK untuk menganalisa database.


Setelah itu, Jailer akan menghubungi database untuk mengambil informasi. Lognya akan ditampilkan di log output. Jailer akan memberi tahu kita tabel-tabel yang tidak ada primary keynya. Jailer tidak dapat memproses tabel tanpa primary key.


Klik tabel yang berwarna merah, dan definisikan primary keynya. Primary key yang kita definisikan di sini hanya digunakan Jailer, sehingga tidak perlu khawatir skema aslinya akan berubah.


Setelah itu, klik OK. Jailer akan menampilkan screen Extraction Model Editor. Pilih tabel payment, di dropdown subject, karena inilah tabel yang akan kita gunakan sebagai pusat extraction.


Jailer mendeteksi relasi antar tabel berdasarkan constraint foreign key yang kita pasang di database. Kadangkala ada tabel-tabel yang berelasi, namun tidak ada constraintnya. Entah karena malas mendefinisikan, atau memang sengaja tidak dikaitkan. Kita bisa mendaftarkan relasi tanpa constraint ini dengan membuka lagi Data Model Editor, kemudian klik Add di kotak Association sebelah kanan.

Relasi non Foreign Key

Setelah diklik OK, maka skema relasi di Extraction Model Editor akan berubah sesuai relasi yang ditambahkan. Sama dengan definisi primary key di atas, relasi ini hanya disimpan oleh Jailer dan tidak diaplikasikan ke skema database.

Relasi Payment - Loket

Kita perlu mendefinisikan batasan record payment yang akan diambil, yaitu yang terjadi di bulan Juni 2010. Dalam bentuk SQL, berikut adalah query yang digunakan

1. select * from payment where date_format(paid_date, '%Y-%m') = '2010-06'

select * from payment where date_format(paid_date, '%Y-%m') = '2010-06' 

Kita ambil expression setelah where dan pasang di textfield where dalam Extraction Model Editor.

Restriction

Simpan dulu extraction modelnya.

Save Extraction

Beri nama yang representatif, misalnya payment-201006. Jailer akan menyimpan extraction model ini dalam format csv. Kalau sudah memahami formatnya, kita bisa membuatnya dengan text editor tanpa GUI (kalau mau).

Setelah tersimpan, kita bisa klik Export Data sehingga memunculkan dialog berikut.

Export Data

Di screen tersebut kita bisa mengatur konfigurasi pengambilan data. Bagi saya, nilai defaultnya sudah memadai sehingga tidak ada yang diubah.

Di box paling bawah ada command line yang bisa kita copy-paste untuk dijalankan tanpa GUI. Copy saja isinya ke text file untuk digunakan nanti.

Yang harus kita isi di screen ini adalah textfield Into. Ini adalah nama file yang akan menampung script SQL berisi data yang diinginkan. Isi saja dengan nama payment-201006.sql.

Export Into File

Setelah itu, klik Export Data. Jailer akan segera bekerja dan menampilkan hasilnya dalam bentuk tree.

Hasil Export

Di situ kita bisa lihat berapa row yang akan diambil dari masing-masing tabel.
Seperti kita lihat, cukup signifikan, yaitu 2000an record. Ini disebabkan karena jailer mengambil record secara rekursif tanpa ada batasan.

Setelah dianalisa, kita hanya ingin mengambil tabel-tabel yang berkaitan langsung, yaitu payment, payment_info, payment_value, dan fee_loket. Sedangkan tabel sisanya dapat diabaikan karena bersifat pelengkap atau master data yang sudah ada di database development.

Dengan melihat ke tree-nya, kita bisa memutus relasi fee_loket ke loket, karena dari situlah semua data lain akan ikut terbawa.

Tutup screennya, dan kembali ke Extraction Model Editor.

Membatasi Relasi

Di kotak Association, expand node yang ingin kita putuskan, yaitu fee loket. Klik relasi loket, dan centang checkbox disabled di pojok kiri bawah. Setelah itu, jalankan lagi Export Data.

Warning Restricted Dependency

Jailer akan mengingatkan bahwa dengan membatasi dependensi, referential integrity akan rusak, karena relasi foreign key dari fee_loket ke loket akan terputus. Klik saja Yes, karena di database development kita tabel loket sudah terisi lengkap.

Inilah hasilnya

Hasil Export setelah dibatasi

Seperti kita lihat di atas, kita cuma mendapatkan 84 record dan pengambilan data berhenti di tabel fee_loket.
Periksa output payment-201006.sql di folder Jailer untuk memastikan hasilnya sudah benar.

Setelah sukses dijalankan di database development, compress lagi jailer yang sudah dimodifikasi barusan dan upload ke server production. Setibanya di server production, extract, kemudian jalankan script yang tadi kita copy-paste.

Kalau baru pertama kali dijalankan, script ini akan menimbulkan error sebagai berikut :

view plaincopy to clipboardprint?

1. $ ./export-payment-201006.sh
2. 2010-06-28 14:15:08,114 [main] INFO - Jailer 3.4.5
3. 2010-06-28 14:15:08,117 [main] INFO - added 'lib/mysql-connector-java-5.1.6-bin.jar' to classpath
4. 2010-06-28 14:15:08,119 [main] INFO - exporting 'extractionmodel/payment-201006.csv' to 'payment-201006.sql'
5. 2010-06-28 14:15:08,700 [main] INFO - begin guessing SQL dialect
6. 2010-06-28 14:15:08,711 [main] INFO - end guessing SQL dialect
7. 2010-06-28 14:15:08,718 [main] ERROR - Can't find working tables! Run 'bin/jailer.sh create-ddl' and execute the DDL-script first!
8. java.lang.RuntimeException: Can't find working tables! Run 'bin/jailer.sh create-ddl' and execute the DDL-script first!
9. at net.sf.jailer.entitygraph.EntityGraph.create(EntityGraph.java:122)
10. at net.sf.jailer.Jailer.export(Jailer.java:1142)
11. at net.sf.jailer.Jailer.jailerMain(Jailer.java:1064)
12. at net.sf.jailer.Jailer.jailerMain(Jailer.java:989)
13. at net.sf.jailer.Jailer.main(Jailer.java:967)
14. Caused by: java.sql.SQLException: "Table 'ppobgsp_test.JAILER_GRAPH' doesn't exist" in statement "Insert into JAILER_GRAPH(id, age) values (2104021762, 1)"
15. at net.sf.jailer.database.Session.executeUpdate(Session.java:470)
16. at net.sf.jailer.entitygraph.EntityGraph.create(EntityGraph.java:120)
17. ... 4 more
18. Error: java.lang.RuntimeException: Can't find working tables! Run 'bin/jailer.sh create-ddl' and execute the DDL-script first!
19. 2010-06-28 14:15:08,724 [main] ERROR - working directory is /opt/downloads/java/tools/test/integration-test/jailer

$ ./export-payment-201006.sh 2010-06-28 14:15:08,114 [main] INFO   - Jailer 3.4.5 2010-06-28 14:15:08,117 [main] INFO   - added 'lib/mysql-connector-java-5.1.6-bin.jar' to classpath 2010-06-28 14:15:08,119 [main] INFO   - exporting 'extractionmodel/payment-201006.csv' to 'payment-201006.sql' 2010-06-28 14:15:08,700 [main] INFO   - begin guessing SQL dialect 2010-06-28 14:15:08,711 [main] INFO   - end guessing SQL dialect 2010-06-28 14:15:08,718 [main] ERROR  - Can't find working tables! Run 'bin/jailer.sh create-ddl' and execute the DDL-script first! java.lang.RuntimeException: Can't find working tables! Run 'bin/jailer.sh create-ddl' and execute the DDL-script first!  at net.sf.jailer.entitygraph.EntityGraph.create(EntityGraph.java:122)  at net.sf.jailer.Jailer.export(Jailer.java:1142)  at net.sf.jailer.Jailer.jailerMain(Jailer.java:1064)  at net.sf.jailer.Jailer.jailerMain(Jailer.java:989)  at net.sf.jailer.Jailer.main(Jailer.java:967) Caused by: java.sql.SQLException: "Table 'ppobgsp_test.JAILER_GRAPH' doesn't exist" in statement "Insert into JAILER_GRAPH(id, age) values (2104021762, 1)"  at net.sf.jailer.database.Session.executeUpdate(Session.java:470)  at net.sf.jailer.entitygraph.EntityGraph.create(EntityGraph.java:120)  ... 4 more Error: java.lang.RuntimeException: Can't find working tables! Run 'bin/jailer.sh create-ddl' and execute the DDL-script first! 2010-06-28 14:15:08,724 [main] ERROR  - working directory is /opt/downloads/java/tools/test/integration-test/jailer 

Ini disebabkan karena Jailer ternyata membuat beberapa tabel di database untuk kebutuhan internalnya. Ini dapat dilihat pada database development kita.

Tabel Internal Jailer

Untuk menggenerate tabel di atas, kita jalankan jailer dengan opsi create-ddl. Ini akan menghasilkan SQL di layar. SQL ini harus kita jalankan di database production supaya tabelnya terbentuk.

1. $ sh jailer.sh create-ddl
2. DROP TABLE JAILER_ENTITY;
3. DROP TABLE JAILER_DEPENDENCY;
4. DROP TABLE JAILER_SET;
5. DROP TABLE JAILER_GRAPH;
6. DROP TABLE JAILER_CONFIG;
7. DROP TABLE JAILER_TMP;
8. 
   
9. CREATE TABLE JAILER_CONFIG
10. (
11. jversion VARCHAR(20),
12. jkey VARCHAR(200),
13. jvalue VARCHAR(200)
14. ) ;
15. 
    
16. INSERT INTO JAILER_CONFIG(jversion, jkey, jvalue) values('3.4.5', 'magic', '837065098274756382534403654245288');
17. 
    
18. CREATE TABLE JAILER_GRAPH
19. (
20. id INTEGER NOT NULL,
21. age INTEGER NOT NULL
22. 
    
23. -- ,CONSTRAINT jlr_pk_graph PRIMARY KEY(id)
24. ) ;
25. 
    
26. CREATE TABLE JAILER_ENTITY
27. (
28. r_entitygraph INTEGER NOT NULL,
29. 
    
30. PK0 BIGINT , PK1 VARCHAR(255) , PK2 VARCHAR(255) , PK3 INT , PK4 VARCHAR(255) , PK5 BIGINT ,
31. birthday INTEGER NOT NULL,
32. type VARCHAR(120) NOT NULL,
33. 
    
34. PRE_PK0 BIGINT , PRE_PK1 VARCHAR(255) , PRE_PK2 VARCHAR(255) , PRE_PK3 INT , PRE_PK4 VARCHAR(255) , PRE_PK5 BIGINT ,
35. PRE_TYPE VARCHAR(120),
36. orig_birthday INTEGER,
37. association INTEGER
38. 
    
39. -- , CONSTRAINT jlr_fk_graph_e FOREIGN KEY (r_entitygraph) REFERENCES JAILER_GRAPH(id)
40. ) ;
41. 
    
42. CREATE INDEX jlr_enty_brthdy ON JAILER_ENTITY (r_entitygraph, birthday, type) ;
43. CREATE INDEX jlr_enty_upk1 ON JAILER_ENTITY (r_entitygraph , PK0, PK1, PK2, PK3, PK4, PK5, type) ;
44. 
    
45. CREATE TABLE JAILER_SET
46. (
47. set_id INTEGER NOT NULL,
48. type VARCHAR(120) NOT NULL,
49. PK0 BIGINT , PK1 VARCHAR(255) , PK2 VARCHAR(255) , PK3 INT , PK4 VARCHAR(255) , PK5 BIGINT
50. ) ;
51. 
    
52. CREATE INDEX jlr_pk_set1 ON JAILER_SET (set_id , PK0, PK1, PK2, PK3, PK4, PK5, type) ;
53. 
    
54. CREATE TABLE JAILER_DEPENDENCY
55. (
56. r_entitygraph INTEGER NOT NULL,
57. assoc INTEGER NOT NULL,
58. depend_id INTEGER NOT NULL,
59. traversed INTEGER,
60. from_type VARCHAR(120) NOT NULL,
61. to_type VARCHAR(120) NOT NULL,
62. FROM_PK0 BIGINT , FROM_PK1 VARCHAR(255) , FROM_PK2 VARCHAR(255) , FROM_PK3 INT , FROM_PK4 VARCHAR(255) , FROM_PK5 BIGINT ,
63. TO_PK0 BIGINT , TO_PK1 VARCHAR(255) , TO_PK2 VARCHAR(255) , TO_PK3 INT , TO_PK4 VARCHAR(255) , TO_PK5 BIGINT
64. 
    
65. -- , CONSTRAINT jlr_fk_graph_d FOREIGN KEY (r_entitygraph) REFERENCES JAILER_GRAPH(id)
66. ) ;
67. 
    
68. CREATE INDEX jlr_dep_from1 ON JAILER_DEPENDENCY (r_entitygraph, assoc , FROM_PK0, FROM_PK1, FROM_PK2, FROM_PK3, FROM_PK4, FROM_PK5) ;
69. 
    
70. CREATE INDEX jlr_dep_to1 ON JAILER_DEPENDENCY (r_entitygraph , TO_PK0, TO_PK1, TO_PK2, TO_PK3, TO_PK4, TO_PK5) ;
71. 
    
72. CREATE TABLE JAILER_TMP
73. (
74. c1 INTEGER,
75. c2 INTEGER
76. ) ;
77. 
    
78. INSERT INTO JAILER_CONFIG(jversion, jkey, jvalue) values('3.4.5', 'upk', '679547784');

$ sh jailer.sh create-ddl DROP TABLE JAILER_ENTITY; DROP TABLE JAILER_DEPENDENCY; DROP TABLE JAILER_SET; DROP TABLE JAILER_GRAPH; DROP TABLE JAILER_CONFIG; DROP TABLE JAILER_TMP;  CREATE TABLE JAILER_CONFIG (    jversion        VARCHAR(20),    jkey            VARCHAR(200),    jvalue          VARCHAR(200) ) ;  INSERT INTO JAILER_CONFIG(jversion, jkey, jvalue) values('3.4.5', 'magic', '837065098274756382534403654245288');  CREATE TABLE JAILER_GRAPH (    id              INTEGER NOT NULL,    age             INTEGER NOT NULL  --   ,CONSTRAINT jlr_pk_graph PRIMARY KEY(id) ) ;  CREATE TABLE JAILER_ENTITY (    r_entitygraph   INTEGER NOT NULL,     PK0 BIGINT , PK1 VARCHAR(255) , PK2 VARCHAR(255) , PK3 INT , PK4 VARCHAR(255) , PK5 BIGINT ,    birthday        INTEGER NOT NULL,    type            VARCHAR(120) NOT NULL,     PRE_PK0 BIGINT , PRE_PK1 VARCHAR(255) , PRE_PK2 VARCHAR(255) , PRE_PK3 INT , PRE_PK4 VARCHAR(255) , PRE_PK5 BIGINT ,    PRE_TYPE        VARCHAR(120),    orig_birthday   INTEGER,    association     INTEGER  -- ,  CONSTRAINT jlr_fk_graph_e FOREIGN KEY (r_entitygraph) REFERENCES JAILER_GRAPH(id) ) ;  CREATE INDEX jlr_enty_brthdy ON JAILER_ENTITY (r_entitygraph, birthday, type) ; CREATE INDEX jlr_enty_upk1 ON JAILER_ENTITY (r_entitygraph , PK0, PK1, PK2, PK3, PK4, PK5, type) ;  CREATE TABLE JAILER_SET (    set_id          INTEGER NOT NULL,    type            VARCHAR(120) NOT NULL,    PK0 BIGINT , PK1 VARCHAR(255) , PK2 VARCHAR(255) , PK3 INT , PK4 VARCHAR(255) , PK5 BIGINT ) ;  CREATE INDEX jlr_pk_set1 ON JAILER_SET (set_id , PK0, PK1, PK2, PK3, PK4, PK5, type) ;  CREATE TABLE JAILER_DEPENDENCY (    r_entitygraph   INTEGER NOT NULL,    assoc           INTEGER NOT NULL,    depend_id       INTEGER NOT NULL,    traversed       INTEGER,    from_type       VARCHAR(120) NOT NULL,    to_type         VARCHAR(120) NOT NULL,    FROM_PK0 BIGINT , FROM_PK1 VARCHAR(255) , FROM_PK2 VARCHAR(255) , FROM_PK3 INT , FROM_PK4 VARCHAR(255) , FROM_PK5 BIGINT ,    TO_PK0 BIGINT , TO_PK1 VARCHAR(255) , TO_PK2 VARCHAR(255) , TO_PK3 INT , TO_PK4 VARCHAR(255) , TO_PK5 BIGINT      -- ,  CONSTRAINT jlr_fk_graph_d FOREIGN KEY (r_entitygraph) REFERENCES JAILER_GRAPH(id) ) ;  CREATE INDEX jlr_dep_from1 ON JAILER_DEPENDENCY (r_entitygraph, assoc , FROM_PK0, FROM_PK1, FROM_PK2, FROM_PK3, FROM_PK4, FROM_PK5) ;  CREATE INDEX jlr_dep_to1 ON JAILER_DEPENDENCY (r_entitygraph , TO_PK0, TO_PK1, TO_PK2, TO_PK3, TO_PK4, TO_PK5) ;  CREATE TABLE JAILER_TMP (     c1 INTEGER,     c2 INTEGER ) ;  INSERT INTO JAILER_CONFIG(jversion, jkey, jvalue) values('3.4.5', 'upk', '679547784'); 

Setelah tabelnya siap, jalankan kembali script yang error di atas. Berikut outputnya.

1. $ ./export-payment-201006.sh
2. 2010-06-28 14:12:31,175 [main] INFO - Jailer 3.4.5
3. 2010-06-28 14:12:31,190 [main] INFO - added 'lib/mysql-connector-java-5.1.6-bin.jar' to classpath
4. 2010-06-28 14:12:31,191 [main] INFO - exporting 'extractionmodel/payment-201006.csv' to 'payment-201006.sql'
5. 2010-06-28 14:12:32,850 [main] INFO - SQL dialect is MYSQL
6. 2010-06-28 14:12:32,925 [main] INFO - gather statistics after 0 inserted rows...
7. 2010-06-28 14:12:32,966 [main] INFO - reading file 'renew.sql'
8. 2010-06-28 14:12:32,966 [main] INFO - 0 statements (100%)
9. 2010-06-28 14:12:32,967 [main] INFO - successfully read file 'renew.sql'
10. 2010-06-28 14:12:32,977 [main] INFO - exporting payment Where date_format(paid_date,'%Y-%m') = '2010-06'
11. 2010-06-28 14:12:33,028 [main] INFO - day 1, progress: payment
12. 2010-06-28 14:12:33,039 [main] INFO - starting 4 jobs
13. 2010-06-28 14:12:33,040 [main] INFO - gather statistics after 3 inserted rows...
14. 2010-06-28 14:12:33,041 [main] INFO - reading file 'renew.sql'
15. 2010-06-28 14:12:33,042 [main] INFO - 0 statements (100%)
16. 2010-06-28 14:12:33,042 [main] INFO - successfully read file 'renew.sql'
17. 2010-06-28 14:12:33,047 [main] INFO - resolving payment -> payment_info (inverse-FKE25C3F47AB64A229) 1:n on B.id_payment=A.id...
18. 2010-06-28 14:12:33,105 [main] INFO - 66 entities found resolving payment -> payment_info (inverse-FKE25C3F47AB64A229) 1:n on B.id_payment=A.id
19. 2010-06-28 14:12:33,105 [main] INFO - resolving payment -> cetak_ulang (inverse-FK45B985E0AB64A229) 1:n on B.id_payment=A.id...
20. 2010-06-28 14:12:33,126 [main] INFO - 0 entities found resolving payment -> cetak_ulang (inverse-FK45B985E0AB64A229) 1:n on B.id_payment=A.id
21. 2010-06-28 14:12:33,126 [main] INFO - resolving payment -> fee_loket (inverse-FK9632AFFEAB64A229) 1:n on B.id_payment=A.id...
22. 2010-06-28 14:12:33,129 [main] INFO - 3 entities found resolving payment -> fee_loket (inverse-FK9632AFFEAB64A229) 1:n on B.id_payment=A.id
23. 2010-06-28 14:12:33,131 [main] INFO - resolving payment -> payment_value (inverse-FK69DD09F8AB64A229) 1:n on B.id_payment=A.id...
24. 2010-06-28 14:12:33,142 [main] INFO - 12 entities found resolving payment -> payment_value (inverse-FK69DD09F8AB64A229) 1:n on B.id_payment=A.id
25. 2010-06-28 14:12:33,143 [main] INFO - executed 4 jobs
26. 2010-06-28 14:12:33,143 [main] INFO - day 2, progress: payment_info, fee_loket, payment_value
27. 2010-06-28 14:12:33,144 [main] INFO - skip reversal association payment_info -> payment
28. 2010-06-28 14:12:33,144 [main] INFO - skip reversal association fee_loket -> payment
29. 2010-06-28 14:12:33,147 [main] INFO - skip reversal association payment_value -> payment
30. 2010-06-28 14:12:33,147 [main] INFO - starting 1 jobs
31. 2010-06-28 14:12:33,148 [main] INFO - executed 1 jobs
32. 2010-06-28 14:12:33,149 [main] INFO - exported payment Where date_format(paid_date,'%Y-%m') = '2010-06'
33. 2010-06-28 14:12:33,149 [main] INFO - total progress: payment_info, payment, fee_loket, payment_value
34. 2010-06-28 14:12:33,149 [main] INFO - export statistic:
35. 2010-06-28 14:12:33,169 [main] INFO - Exported Rows: 84
36. 2010-06-28 14:12:33,169 [main] INFO - fee_loket 3
37. 2010-06-28 14:12:33,169 [main] INFO - payment 3
38. 2010-06-28 14:12:33,172 [main] INFO - payment_info 66
39. 2010-06-28 14:12:33,172 [main] INFO - payment_value 12
40. 2010-06-28 14:12:33,173 [main] INFO - writing file 'payment-201006.sql'...
41. 2010-06-28 14:12:33,178 [main] INFO - independent tables: payment
42. 2010-06-28 14:12:33,179 [main] INFO - starting 1 jobs
43. 2010-06-28 14:12:33,380 [main] INFO - executed 1 jobs
44. 2010-06-28 14:12:33,380 [main] INFO - independent tables: payment_info, fee_loket, payment_value
45. 2010-06-28 14:12:33,384 [main] INFO - starting 3 jobs
46. 2010-06-28 14:12:33,447 [main] INFO - executed 3 jobs
47. 2010-06-28 14:12:33,447 [main] INFO - cyclic dependencies for:
48. 2010-06-28 14:12:33,447 [main] INFO - starting 0 jobs
49. 2010-06-28 14:12:33,448 [main] INFO - executed 0 jobs
50. 2010-06-28 14:12:33,448 [main] INFO - gather statistics after 84 inserted rows...
51. 2010-06-28 14:12:33,450 [main] INFO - reading file 'renew.sql'
52. 2010-06-28 14:12:33,450 [main] INFO - 0 statements (100%)
53. 2010-06-28 14:12:33,454 [main] INFO - successfully read file 'renew.sql'
54. 2010-06-28 14:12:33,456 [main] INFO - starting 0 jobs
55. 2010-06-28 14:12:33,467 [main] INFO - executed 0 jobs
56. 2010-06-28 14:12:33,486 [main] INFO - file 'payment-201006.sql' written.

$ ./export-payment-201006.sh 2010-06-28 14:12:31,175 [main] INFO   - Jailer 3.4.5 2010-06-28 14:12:31,190 [main] INFO   - added 'lib/mysql-connector-java-5.1.6-bin.jar' to classpath 2010-06-28 14:12:31,191 [main] INFO   - exporting 'extractionmodel/payment-201006.csv' to 'payment-201006.sql' 2010-06-28 14:12:32,850 [main] INFO   - SQL dialect is MYSQL 2010-06-28 14:12:32,925 [main] INFO   - gather statistics after 0 inserted rows... 2010-06-28 14:12:32,966 [main] INFO   - reading file 'renew.sql' 2010-06-28 14:12:32,966 [main] INFO   - 0 statements (100%) 2010-06-28 14:12:32,967 [main] INFO   - successfully read file 'renew.sql' 2010-06-28 14:12:32,977 [main] INFO   - exporting payment Where date_format(paid_date,'%Y-%m') = '2010-06' 2010-06-28 14:12:33,028 [main] INFO   - day 1, progress: payment 2010-06-28 14:12:33,039 [main] INFO   - starting 4 jobs 2010-06-28 14:12:33,040 [main] INFO   - gather statistics after 3 inserted rows... 2010-06-28 14:12:33,041 [main] INFO   - reading file 'renew.sql' 2010-06-28 14:12:33,042 [main] INFO   - 0 statements (100%) 2010-06-28 14:12:33,042 [main] INFO   - successfully read file 'renew.sql' 2010-06-28 14:12:33,047 [main] INFO   - resolving payment -> payment_info (inverse-FKE25C3F47AB64A229) 1:n on B.id_payment=A.id... 2010-06-28 14:12:33,105 [main] INFO   - 66 entities found resolving payment -> payment_info (inverse-FKE25C3F47AB64A229) 1:n on B.id_payment=A.id 2010-06-28 14:12:33,105 [main] INFO   - resolving payment -> cetak_ulang (inverse-FK45B985E0AB64A229) 1:n on B.id_payment=A.id... 2010-06-28 14:12:33,126 [main] INFO   - 0 entities found resolving payment -> cetak_ulang (inverse-FK45B985E0AB64A229) 1:n on B.id_payment=A.id 2010-06-28 14:12:33,126 [main] INFO   - resolving payment -> fee_loket (inverse-FK9632AFFEAB64A229) 1:n on B.id_payment=A.id... 2010-06-28 14:12:33,129 [main] INFO   - 3 entities found resolving payment -> fee_loket (inverse-FK9632AFFEAB64A229) 1:n on B.id_payment=A.id 2010-06-28 14:12:33,131 [main] INFO   - resolving payment -> payment_value (inverse-FK69DD09F8AB64A229) 1:n on B.id_payment=A.id... 2010-06-28 14:12:33,142 [main] INFO   - 12 entities found resolving payment -> payment_value (inverse-FK69DD09F8AB64A229) 1:n on B.id_payment=A.id 2010-06-28 14:12:33,143 [main] INFO   - executed 4 jobs 2010-06-28 14:12:33,143 [main] INFO   - day 2, progress: payment_info, fee_loket, payment_value 2010-06-28 14:12:33,144 [main] INFO   - skip reversal association payment_info -> payment 2010-06-28 14:12:33,144 [main] INFO   - skip reversal association fee_loket -> payment 2010-06-28 14:12:33,147 [main] INFO   - skip reversal association payment_value -> payment 2010-06-28 14:12:33,147 [main] INFO   - starting 1 jobs 2010-06-28 14:12:33,148 [main] INFO   - executed 1 jobs 2010-06-28 14:12:33,149 [main] INFO   - exported payment Where date_format(paid_date,'%Y-%m') = '2010-06' 2010-06-28 14:12:33,149 [main] INFO   - total progress: payment_info, payment, fee_loket, payment_value 2010-06-28 14:12:33,149 [main] INFO   - export statistic: 2010-06-28 14:12:33,169 [main] INFO   - Exported Rows:     84 2010-06-28 14:12:33,169 [main] INFO   -     fee_loket                      3 2010-06-28 14:12:33,169 [main] INFO   -     payment                        3 2010-06-28 14:12:33,172 [main] INFO   -     payment_info                   66 2010-06-28 14:12:33,172 [main] INFO   -     payment_value                  12 2010-06-28 14:12:33,173 [main] INFO   - writing file 'payment-201006.sql'... 2010-06-28 14:12:33,178 [main] INFO   - independent tables: payment 2010-06-28 14:12:33,179 [main] INFO   - starting 1 jobs 2010-06-28 14:12:33,380 [main] INFO   - executed 1 jobs 2010-06-28 14:12:33,380 [main] INFO   - independent tables: payment_info, fee_loket, payment_value 2010-06-28 14:12:33,384 [main] INFO   - starting 3 jobs 2010-06-28 14:12:33,447 [main] INFO   - executed 3 jobs 2010-06-28 14:12:33,447 [main] INFO   - cyclic dependencies for: 2010-06-28 14:12:33,447 [main] INFO   - starting 0 jobs 2010-06-28 14:12:33,448 [main] INFO   - executed 0 jobs 2010-06-28 14:12:33,448 [main] INFO   - gather statistics after 84 inserted rows... 2010-06-28 14:12:33,450 [main] INFO   - reading file 'renew.sql' 2010-06-28 14:12:33,450 [main] INFO   - 0 statements (100%) 2010-06-28 14:12:33,454 [main] INFO   - successfully read file 'renew.sql' 2010-06-28 14:12:33,456 [main] INFO   - starting 0 jobs 2010-06-28 14:12:33,467 [main] INFO   - executed 0 jobs 2010-06-28 14:12:33,486 [main] INFO   - file 'payment-201006.sql' written. 

Selesai sudah, data yang kita inginkan ada di file payment-201006.sql, siap diunduh dan dijalankan di database development.

Semoga bermanfaat, kalau ada yang kurang jelas, silahkan baca tutorial resminya.

sumber : Blog Endy

Danau cantik dari Bencana

Tak lengkap rasanya jika Anda berkunjung ke Sumatera Utara tidak mampir sejenak ke Danau Toba, danau vulkanik yang merupakan danau terbesar di Indonesia, bahkan Asia Tenggara. Pesona eksotisnya berupa hamparan danau luas laksana lautan dengan pepohonan rindang dan perbukitan yang menawan. Danau ini berukuran 1700 meter persegi dengan kedalaman kurang lebih 450 meter dan terletak 906 meter di atas permukaan laut, di tengah danau terdapat Pulau Samosir yang tak kalah menariknya menjadi objek kunjungan wisata.

Dalam kunjungannya pada 1996, Pangeran Bernard dari Belanda bahkan menyatakan kekagumannya pada panorama indah danau ini. “Juallah nama saya untuk danau ini. Saya tak dapat melukiskan betapa indahnya Danau Toba,” katanya antusias.

Ada tujuh kabupaten di sekeliling danau, yakni Simalungun, Toba Samosir, Tapanuli Utara, Humbang Hasundutan, Dairi, Karo, dan Samosir yang memiliki panorama alam indah dan menjadi lokasi tujuan wisata. Umumnya wisatawan menikmati keelokan Danau Toba dari Parapat di Simalungun dan Tuktuk Siadong di Pulau Samosir.

Diperkirakan Danau Toba terjadi saat ledakan sekitar 73 ribu-75 ribu tahun lalu dan merupakan letusan super volcano (gunung berapi super) yang paling baru. Bill Rose dan Craig Chesner dari Michigan Technological University memperkirakan bahwa bahan-bahan vulkanik yang dimuntahkan gunung itu sebanyak 2.800 km³, dengan 800 km³ batuan ignimbrit dan 2.000 km³ abu vulkanik yang diperkirakan tertiup angin ke barat selama dua minggu.


Debu vulkanik yang ditiup angin telah menyebar ke separuh bumi, dari Cina sampai ke Afrika Selatan. Letusannya terjadi selama satu minggu dan lontaran debunya mencapai 10 km di atas permukaan laut.

Kejadian ini menyebabkan kematian massal dan, pada beberapa spesies, juga diikuti kepunahan. Menurut beberapa bukti DNA, letusan ini juga menyusutkan jumlah manusia sampai sekitar 60% dari jumlah populasi manusia bumi saat itu, yaitu sekitar 60 juta manusia. Letusan itu juga ikut menyebabkan terjadinya zaman es, walaupun para ahli masih memperdebatkannya.

Setelah letusan tersebut, terbentuk kaldera yang kemudian terisi oleh air dan menjadi yang sekarang dikenal sebagai Danau Toba. Tekanan ke atas oleh magma yang belum keluar menyebabkan munculnya Pulau Samosir. Ketika menikmati keindahan danau ini, Anda mungkin tak membayangkan bahwa pesona yang terjadi berasal dari bencana dahsyat letusan gunung berapi yang mendatangkan ketakutan dan kengerian ketika itu.
Perjalanan darat ke Danau Toba, tepatnya ke Parapat, memakan waktu empat sampai lima jam dari Medan. Tersedia bus atau travel yang langsung menuju Parapat. Rutenya melewati Lubuk Pakam, Tebing Tinggi, dan belok ke arah Pematang Siantar. Sepanjang perjalanan, kita disuguhi panorama perkebunan kelapa sawit dan karet.

Apabila menggunakan kereta api, dari Medan pilih rute menuju Pematang Siantar. Dari sini perjalanan dilanjutkan menggunakan bus ke Parapat. Waktu tempuhnya satu jam.


Untuk tempat menginap dan tinggal lebih lama menikmati keindahan Danau Toba, tersedia banyak hotel dan penginapan. Di Parapat, sedikitnya ada 900 kamar hotel berbagai jenis, mulai dari bintang empat hingga homestay, di Tuktuk juga tak berbeda. Baik di Parapat maupun Tuktuk, wisatawan dapat langsung menikmati danau dari pinggirannya. Tarif hotel di Tuktuk dan Parapat bervariasi, sesuai tipikal turis yang datang. Mulai dari Rp 30 ribu hingga Rp 500 ribu per malam tergantung tipe hotel.

Sebuah perusahaan travel bahkan menawarkan menikmati keindahan Danau Toba dari udara, yakni menggunakan paralayang. Setiap wisatawan diberi kesempatan terbang menggunakan paralayang dari kawasan pegunungan Tongging, Kabupaten Tanah Karo, Sumatera Utara. Bagi para wisatawan yang ingin mencoba paralayang akan ditemani seorang instruktur berpengalaman, namun tentunya penentuan bisa terbang atau tidak tergantung pada kondisi cuaca dan angin.

Tidak hanya itu, menikmati keindahan matahari terbit dan terbenam bisa Anda nikmati dari pesisir danau. Dari dataran tinggi Karo di sebelah utara, keelokan danau terlihat memanjang dipandang dari Sikodonkodon. Namun, hanya ada satu resor di sini. Di sisi barat, pemandangan danau dan Pulau Samosir dapat dengan sempurna disaksikan dari Tele. Ada gardu pandang di ketinggian sekitar 1.000 meter dari permukaan laut untuk menikmati senja di Danau Toba.

sumber

Menjadikan KIPI Indonesia diminati oleh Organisasi Piranti Lunak Indonesia

1. Pendahuluan

Departemen Perindustrian (Deperin) bersama Asosiasi Piranti Lunak Telematika Indonesia (Aspiluki), tahun 2008 akan mengeluarkan Kematangan Industri Perangkat lunak Indonesia (KIPI) versi 1.0. CMM versi Indonesia ini diharapkan dapat menjadi standar Indonesia dalam meningkatkan proses pengembangan perangkat lunak bagi perusahaan-perusahaan di Indonesia. Menurut Ketua Asosiasi Pengembang Perangkat Lunak Indonesia (Aspiluki) Djarot Subiantoro, pertimbangan itu diambil bersama Deperin karena untuk meraih sertifikasi CMM Internasional perusahaan lokal perlu mengeluarkan biaya besar dan memakan waktu lama. Sementara itu, kualitas dan ketersediaan infrastruktur untuk lingkungan bisnis software masih di tingkat dasar. Saat ini secara nasional terdapat 250 perusahaan pengembang software/ ISV (Independent Software Vendor) dan akan terus berkembangan hingga mencapai 500 dalam lima tahun kedapan, di mana untuk merebut pasar yang lebih luas perlu mengadopsi standar CMM yang saat ini baru dimiliki dua perusahaan dan yang tertinggi baru pada tingkat III yang sertifikasinya diberikan organisasi yang diotorisasi Software Engineer Institute (SEI).

Berbicara masalah pangsa pasar software, salah seorang pakar di bidang informasi teknologi, Romi Satrio Wahono mengatakan bahwa dari sekitar Rp. 600 miliar pasar software, jatah untuk software lokal hanya sekitar Rp. 100 miliar. Hal ini dikarenakan software lokal tidak mampu bersaing dengan software asing. Ada beberapa faktor yang menyebabkannya antara lain :
- Keterbatasan pengetahuan dalam software development, sehingga begitu software diukur dari seluruh proses pengembangan akan kedodoran dan kalah bersaing.
- Kurangnya ide dalam produk dan inovasi, hal ini berhubungan dengan kurangnya sarana penghubung dengan pihak yang membutuhkan software. Kebutuhan mungkin ada, tetapi antara yang membutuhkan dan pengembang tidak bertemu. Perusahaan asing kebanyakan memiliki expert khusus untuk membaca kebutuhan pasar dan bergerak mencari pasar, serta membuat sarana koneksi bagi pihak yang membutuhkan dan pihak yang mengembangkan.
- Kurangnya keterlibatan pemerintah untuk melindungi pengembang software lokal. Seperti di Jepang, dimana pemerintahannya mendukung penuh software lokal officenya, sehingga secara defacto menguasai pasar aplikasi office disana.
- Keterbatasan modal usaha. Ini berhubungan dengan perusahaan software rata-rata tidak bankable, banyak yang berumur muda, tidak memiliki aset nyata yang bisa digunakan sebagai agunan pinjaman ke bank. Akhirnya dalam projek-projek besar, software house kita banyak bertumbangan karena banyak projek yang berbasis ke kualifikasi perusahaan.

Sedangkan untuk prospek kedepan hasil riset IDC menunjukkan, dalam periode 2004 hingga 2009 sektor teknologi informasi (TI) di Indonesia akan membutuhkan sekitar 1.100 perusahaan TI baru yang dapat menyerap 81.000 tenaga kerja. Sekitar 29.9 persen dari total pekerja TI ini akan terlibat dalam membuat produk software lokal, mendistribusikan produk asing dan memberi layanan custom development. IDC juga memprediksi perkembangan bisnis TI di Indonesia akan memberikan penghasilan pajak sebesar 1.1 miliar dollar AS kepada pemerintah jika dikelola dengan serius. Ini merupakan kesempatan baik untuk dijadikan motivasi untuk menumbuhkan semangat pengembangan software lokal di Indonesia. Pasar sudah ada, tinggal bagaimana strategi untuk meraihnya.

Disamping peluang ada 2 level tantangan yang dihadapi oleh industri software di Indonesia, menurut penelitian yang dilakukan oleh Departemen Komunikasi dan Informasi. Ke 2 tantangan tersebut adalah :
• Tantangan di level Industi

Pada level ini tantangan yang dihadapi, antara lain :
- Kemudahan yang dialami pelaku-pelaku industri lokal dalam hal pengembangan dan penyebaran software juga dialami oleh pelaku-pelaku industri software dari negara-negara lain. Sehingga secara kemudahan tersebut relatif tidak memberikan keunggulan kompetitif terhadap pelaku industri software lokal. Bahkan, pada segmen-segmen pasar dengan produk generik, peluang industri lokal sangat kecil, karena pangsa pasar bisa dipenuhi oleh perusahaan multinasional yang sudah menguasai pasar terlebih dahulu.
- Software merupakan produk yang sangat kompleks, di mana pasar tidak bisa mudah menilai tawaran software dari perusahaan baru. Tuntutan pasar terhadap reputasi dan brand (merek) menjadi rintangan tersendiri bagi pengembang-pengembang software lokal untuk masuk ke segmen pasar yang lebih tinggi, yang sementara ini dikuasai oleh pemain-pemain asing, menjadi lebih sulit. Apa lagi untuk aplikasi yang mission critical, kebanyakan pasar nasional lebih mengandalkan pada vendor-vendor asing yang sudah punya nama.
- Industri software telah memberikan kesempatan pada banyak pelaku industri lokal. Untuk melayani segmen pasar terbawah, industri software memiliki rintangan masuk (barrier to entry) yang rendah. Ini ditunjukkan kebanyakan perusahaan software lokal melayani segmen pasar ini. Namun, karena persaingan di sini sangat tinggi, dan pemain-pemain baru terus bermunculan dan bersedia dibayar lebih rendah dari pemain lama, maka pemain lama yang tidak bisa tumbuh, tidak bisa melayani segmen pasar yang lebih tinggi, akan tersisih dari industri.

• Tantangan di level Organisasi

Industri software merupakan industri baru, yang memiliki karakteristik yang berbeda dengan industri manufaktur. Pengalaman keberhasilan di industri manufaktur tidak bisa ditiru untuk membesarkan bisnis software. Perbedaan ini menimbulkan persoalan-persoalan di level organisasi sebagai berikut:
- Banyak orang meyakini bahwa untuk memulai usaha di bidang software relatif mudah dan murah dilakukan, karena tidak ada ketergantungan pada barang-barang modal yang mahal. Ini ditunjukkan dengan banyaknya orang-orang muda yang baru lulus universitas, bahkan juga yang belum lulus, mendirikan perusahaan software. Kemudahan ini dipercaya siapa saja, termasuk orang-orang yang bekerja di perusahaan software, sehingga mereka bisa merasa mudah untuk keluar dan mendirikan perusahaan baru. Akibatnya yang terjadi adalah kebanyakan perusahaan software tidak tumbuh, tidak mampu menjaga programer-programer yang senior untuk pergi dan mendirikan usaha sendiri atau pindah ke perusahaan lain. Karena itu yang perlu dicari oleh perusahaan software lokal adalah mencari sistem insentif yang tepat, untuk menjaga loyalitas karyawannya.
- Produksi software tidak tergantung pada mesin, sehingga proses produksinya tidak bisa disandarkan pada sesuatu yang yang berwujud (tangibel), seperti mesin-mesin produksi. Pengembangan software secara bersama menuntut kemampuan membagi dan menata kerja yang lebih rumit, karena produknya bukan benda. Banyak perusahaan software lokal hanya mampu menyelesaikan pengembangan software-software dengan tim-tim kecil, karena rumitnya mengelola tim besar dalam produksi software.

Terkait dengan penerapan KIPI versi 1.0, dimana sosialisasi telah mulai dilakukan, ada beberapa hal yang perlu dipertanyakan : pertama sudah sejauh mana tingkat kesiapan badan (lembaga) pelaksana KIPI ini ?, karena bila melihat tugas yang akan dilakukan sangat berat sekali, antara lain : (1) membangun dan membina hubungan dengan mitra yang akan membantu dalam pelaksanaan pelatihan dan/atau pelaksanaan appraisal, (2) melaksanakan ujian dan memberikan sertifikat ketua penilai/lead appraisal KIPI kepada perorangan, (3) melaksanakan ujian dan memberikan sertifikat pelatihan kepada mitra sehingga dapat memberikan pelatihan KIPI, (4) menerima data hasil penilaian dari tim appraisal untuk dikaji dan kemudian memberikan sertifikat hasil appraisal kepada perusahaan pengembang perangkat lunak yang dinilai, (5) membuat materi pelatihan KIPI dan melakukan pembaharuan sesuai dengan kebutuhan. Tugas-tugas tersebut memerlukan koordinasi dan tanggung jawab yang besar di dalam pelaksanakan pelatihan dan pemberian sertifikat dari hasil penilaian dan pengkajian. Seperti diketahui untuk hal yang menyangkut “koordinasi dan kewenangan” masih menjadi masalah di Indonesia, terutama menyangkut birokrasi dan transparansi. Kedua adalah bagaimana mengusahakan agar KIPI diminati oleh organisasi perangkat lunak Indonesia ?. Seperti telah dikemukakan sebelumnya, bahwa dari 250 organisasi pengembang software Indonesia, hanya ada dua yang memiliki sertifikat CMM, lalu bagaimana dengan KIPI, apakah nasibnya sama dengan CMM ?, dimana hanya diminati oleh bebearapa organisasi pengembang perangkat lunak di Indonesia.

Oleh karena itu, terkait dengan masalah bagaimana agar KIPI diminati oleh para organisasi pengembang perangkat lunak, maka perlu beberapa strategi yang harus dilakukan. Dan ini akan dibahas lebih lanjut di dalam makalah ini.

2. Sekilas CMM versi Indonesia (KIPI)

KIPI merupakan standar yang diadopsi dari CMMI versi 1.0, digunakan untuk menilai tingkat kematangan pengembang perangkat lunak di Indonesia. Latar belakang yang mendasari pembentukan KIPI adalah :
• Mendorong industri perangkat lunak di Indonesia untuk meningkatkan kinerja perusahaannya
• Model yang ada saat ini tidak semuanya cocok untuk karakteristik industri perangakat lunak di Indonesia karena masalah jumlah pegawai dan biaya sertifikasi yang mahal dari CMM/CMMI
• Untuk meningkatkan daya saing nasional di pasaran global.

Dengan adanya standar ini diharapkan perusahaan perangkat lunak ::
- Dapat meningkatkan kualitas terhadap berbagai proses yang ada di dalam perusahaan
- Terbentuknya visi yang sama terhadap semua elemen yang ada dalam perusahaan, sehingga meningkatkan kualitas dan memperlancar komunikasi dalam berbagai lapisan dalam struktur organisasi perusahaan
- Dapat meningkatkan efisiensi biaya dan waktu

Inovasi yang dilakukan pada KIPI versi 1.0 ini adalah memecah level CMM dari 5 menjadi 10, pertimbangannya adalah karena pemain industri perangkat lunak dalam negeri mayoritas terdiri dari perusahaan-perusahaan kecil. Dengan pembagian 10 level diharapkan bisa memetakan kematangan perusahaan-perusahaan lebih akurat. Disamping itu juga dengan level yang banyak diharapkan perusahaan-perusahaan kecil dapat lebih terpacu untuk naik tingkat dalam waktu yang lebih singkat ketimbang 5 level tapi butuh waktu dan biaya yang lebih besar dan lama.

Standar KIPI versi1.0 terdiri dari 22 area proses dengan rincian sebagai berikut :
- Level 1. merupakan level persiapan, dimana proses pengembangan perangkat lunak dilakukan dengan cara adhoc dan hasilnya tidak dapat diprediksi.
- Level 2 merupakan level awal, pada level ini terdapat 4 key practice Area (KPA) yang harus dipenuhi, antara lain :
o Menajemen kebutuhan
o Perencanaan proyek
o Pengawasan dan kontrol proyek
o Manajemen konigurasi.
- Level 3 merupakan level pengulangan, dimana terdapat 3 KPA, antara lain :
o Menajemen perjanjian penyaluran
o Jaminan mutu kualitas produk dan proses
o Penilaian dan analisa.
- Level 4 merupakan level terdifinisi, disini terdapat 2 KPA, antara lain :
o Manajemen proyek terintegrasi
o Manajemen resiko.
- Level 5 merupakan level terencana, dimana terdapat 2 KPA, terdiri atas :
o Definisi proses organisasi
o Pelatihan organisasi.
- Level 6 merupakan level terorganisasi dengan 2 KPA, meliputi :
o Fokus proses organisasi
o Analisis keputusan dan resolusi.
- Level 7 merupakan level terintegrasi dengan 2 KPA, meliputi :
o Integrasi produk
o Pengembangan kebutuhan.
- Level 8 merupakan level teruji dengan 3 KPA, meliputi :
o Solusi teknis
o Validasi
o Verifikasi.
- Level 9 merupakan level terkelola dengan 2 KPA, meliputi :
o Menajemen penyebab dan resolusi
o Pengembangan proses organisasi.
- Level 10 merupakan level optimal dengan 2 KPA, meliputi :
o Analisa penyebab dan resolusi
o Pengembangan dan inovasi organisasi.

3. Minim Sertifikat CMM/CMMI
CMM (Capability Maturity Model)/ Integration dikembangkan pertama kali oleh SEI (Software Engineering Institute) yang berbasis di Carnegie Mellon University in Pittsburgh berdasarkan pesanan dari Departemen Pertahanan Amerika Serikat. CMM dikembangkan sebagai alat ukur dalam menguji para calon kontraktor yang akan direkrut oleh Departemen Pertahanan Amerika Serikat dalam melaksanakan kontrak pekerjaan pengembangan aplikasi perangkat lunak komputer di lembaga tersebut.
Jika disetarakan dengan standar yang ditetapkan oleh Badan Standarisasi Internasional (ISO), maka CMM dapat disetarakan dengan ISO 9001 (bagian dari seri ISO 9000). Dimana ISO 9000 adalah standar yang ditetapkan bagi industri jasa dan manufaktur dari sisi sistem kendali mutu yang efektif. Sedangkan ISO 9001 diperuntukkan secara khusus sebagai standar dalam pengembangan dan pemeliharaan aplikasi perangkat lunak. Perbedaan yang cukup mendasar antara CMM dan ISO 9001 adalah pada fokus item pengujian atas sebuah proyek pengembangan aplikasi perangkat lunak komputer. ISO 9001 lebih fokus pada standar minimum yang wajib dipenuhi dalam proses pengembangan software yang berkualitas. Sedangkan CMM dikembangkan sebagai framework yang dapat digunakan secara berkelanjutan dalam peningkatan proses dibandingkan hanya sekedar menetapkan standar minimum yang harus dipenuhi dalam memenuhi sebuah software yang berkualitas.
Secara sederhana, CMM dapat diibaratkan sebagai tolok-ukur dalam menentukan tingkat “kematangan” sebuah aplikasi perangkat lunak komputer. “Tingkat Kematangan” disini berarti semakin tinggi levelnya maka semakin baik kemampuan setiap elemen organisasi dalam mengembangkan dan mengelola softwarenya. Level disini didasarkan pada standar yang ditetapkan oleh CMM yang terdiri atas 5 (lima) tingkatan, yaitu : initial, repeatable, defined, managable, optimizing, kecuali tingkat initial, setiap tingkatan mempunyai beberapa key process area (KPA) yaitu bidang yang harus menjadi perhatian sebuah organisasi untuk meningkatkan proses dalam pengembangan perangkat lunaknya.
Secara umum, standar CMM tingkat II mempersyaratkan standar proses
pengembangan software, di tingkat berikutnya ISV disyaratkan kemampuan
melaksanakan proses atau prosedur secara konsisten. Di tingkat IV, ISV harus mampu dalam pengembangan dan menggunakannya secara konsisten, baru di tingkat V, ISV harus mampu meningkatkan kualitas dan kemampuan organisasi serta semua potensinya.

Terkait dengan sertifikasi standar internasional yang dimiliki oleh perusahaan perangkat lunak Indonesia, khususnya sertifikat CMM/CMMI, jumlahnya sangat minim sekali, dimana dari 250 perusahaan hanya 2 perusahaan atau sekitar 0.8%. Kondisi ini tentu saja memperhatikan bila dibandingkan dengan India, dimana dari 80 perusahaan yang bersertifikat CMM level 5 di dunia, 60 diantaranya berada di negara India. Artinya 75% CMM level 5 berada di negara India.

Bila melihat kondisi di atas mungkin menimbulkan tanda tanya besar bagi kita mengapa begitu minimnya jumlah pengembang yang memiliki sertifikat, bukankah sertifikat ini sangat bermanfaat bagi perusahaan dalam rangka meningkatkan kualitas terhadap proses yang ada, serta meningkatkan daya saing dalam penyerapan pasar. Informasi terakhir dari Aspiluki menunjukan bahwa dari 310 juta dolar Amerika peluang pasar piranti lunak, hanya 20% yang dikuasi oleh pengembang lokal .

Ada beberapa alasan mengapa mereka tidak begitu “peduli” dengan standar yang ada, diantaranya :
- Masalah biaya, dimana untuk mendapatkan sertifikasi pertingkat bisa mencapai 40 hingga 70 ribu dolar Amerika atau sekitar 400 hingga 700 juta rupiah, harga tersebut tentulah tidak sedikit dan sangat kontras dengan masalah modal usaha yang sedang dihadapi oleh perusahaan pengembang perangkat lunak di Indonesia.
- Masalah kedua adalah waktu, dimana waktu yang dibutuhkan untuk implementasi CMM/CMMI sangat lama, sekitar 12 bulan, dengan penerapannya dapat menggunakan beberapa cara, antara lain : menyewa assesor resmi yang telah bersetifikat CMM untuk melakukan evaluasi secara formal atau mengirim pegawai/karyawan untuk mengikuti training CMM kemudian melakukan internal asessement.
- Faktor lainnya yang juga menjadi masalah adalah tidak adanya kesadaran dari para organisasi pengembang perangkat lunak Indonesia mengenai arti pentingnya standar dalam rangka memberikan kepercayaan kepada stakeholder, terkait dengan jaminan kualitas terhadap produk yang dihasilkan.
- Dan terakhir adalah tidak adanya kewajiban bagi para pengembang apabila ingin berpartisipasi dalam setiap tender, baik itu untuk instansi pemerintah maupun swasta.

4. Strategi KIPI Untuk Menjaring Minat

Belajar dari permasalahan yang ada pada minimnya pemegang sertifikasi standar CMM/CMMI, maka perlu membuat strategi bagaimana agar para organisasi pengembang perangkat lunak dapat berminat untuk ikut dalam KIPI versi 1.0. Strategi tersebut antara lain :

• Kemudahan Administrasi Pengurusan

Hal pertama yang diharus dilakukan berkaitan dengan pelaksanaan implemetasi KIPI adalah kemudahan di dalam administrasi registrasi peserta KIPI. Seperti diketahui masalah pengurusan administarsi (perijinan) masih menjadi “masalah” di negeri ini, oleh karena itu untuk mempercepat di dalam pengurusan sertifikasi KIPI ini, semua instansi yang terkait harus mempersiapkan diri secara matang, mulai dari pendaftaran, pelaksanaan sampai kelurganya sertifikat, sehingga tidak ada lagi keluhan yang menyangkut administratif. Kalau perlu semuanya dilaksanakan secara online dan transparan.

Alternatif lainnya dapat juga menyerahkan pengelolaan standar KIPI ini pada pihak lain yang indepedent, dimana tidak terkait dengan pihak manapun, sehingga lebih objektif dan tidak birokratif.

• Sosialisasi Efektif

Hal kedua yang harus dilakukan adalah mensosialisasi KIPI secara efektif. Sosialisasi ini sangat penting agar KIPI dapat dikenal di lingkungan perusahaan pengembang perangkat lunak maupun di lingkungan instansi pemerintah. Sayangnya setahun setelah KPI versi 1.0 diproklamirkan oleh Departemen Perindustri dan Asosiasi Perangkat Lunak Indonesia, tidak ada dokumen resmi yang membahas mengenai KIPI versi 1.0 ini, baik di situs Deperin maupun Aspiluki. Oleh karena itu perlu dibuatkan forum khusus di kedua situs tersebut, agar masyarakat tahu mengenai arti pentingnya standar tersebut, baik bagi pengembang perangkat lunak, maupun bagi instansi pemerintah ataupun swasta.

Untuk sosialisasi secara langsung perlu di agenda secara khusus oleh departemen perindustrian dan Aspiluki, terutama berkaitan dengan sponsor, pendanaan, pihak yang diundang dan lokasi penyelenggaraan. Kita tahu untuk instansi pemerintah ada keterbatasan dalam penganggaran, oleh karena itu harus didukung oleh pihak swasta, sehingga sosialisasi ini dapat berjalan secara efisien dan efektif.

Adapun hasil yang diharapkan dari sosialisasi ini adalah kesadaran dari para pengembangan dan pengguna produk pengembangan mengenai arti pentingnya peningkatan kualitas produk lokal agar dapat bersaing dengan produk asing. Ini tentu saja akan memberi keuntungan secara tidak langsung kepada negara dalam hal penyediaan lapangan kerja dan pendapatan dari sektor pajak. Hal lain yang juga perlu mendapat perhatian adalah menghilangkan resistensi mengenai keengganan menggunakan standar lokal karena sudah ada standar internasional seperti CMM yang sudah diakui secara luas.

• Biaya Murah Waktu Singkat

Salah satu faktor terbesar keengganan para organisasi pengembang tidak berminat untuk mengambil sertifikat CMM/CMMI adalah besarnya biaya yang harus dikeluarkan. Dimana untuk biaya pertingkat sebesar 400 hingga 700 juta rupiah. Melihat biaya sebesar ini rasanya tidak mudah bagi para pengembang untuk ikut ambil bagian, khususnya bagi perusahaan yang bermodal kecil. Oleh karena itu bercermin dari masalah besarnya biaya yang harus dikeluarkan untuk mendapatkat sertifikat CMM/CMMI, maka untuk KIPI seharusnya lebih murah dari standar internasional, kalau bisa sesuai dengan kemampuan masing-masing perusahaan. Hal ini ditujukan untuk membantu para pengembang software bermodal kecil untuk mengikuti sertifikasi KIPI.

Di dalam CMM/CMMI hal yang berkaitan dengan biaya ini terutama berhubungan dengan pembayaran lead assessor dan pelatihan. Dimana masing-masing dibayar dengan menggunakan standar internasional dalam satuan dollar Amerika. Untuk KIPI mungkin lead assessor lokal dan pelatihannya dapat dibayar dengan menggunakan standar lokal dengan satuan rupiah. Hal ini mungkin dapat mengurangi biaya di dalam pengurusan sertifikat KIPI.

Disamping biaya, faktor lainnya yang juga mendapat perhatian bagi pengelola KIPI adalah waktu penyelesaian implementasi KIPI. Bila CMM/CMMI membutuhkan waktu 12 bulan, maka KIPI harus lebih cepat dari CMM/CMMMI. Ini dimaksudkan agar perusahaan tidak terbuang waktunya hanya untuk mengurusi masalah sertifikasi. Untuk itulah diperlukan mekanisme yang jelas di dalam pengurusan sertifikasi ini dengan menghilangkan banyak birokrasi, caranya mungkin melalui regristrasi secara online.

• KIPI Sebagai Syarat Peserta Tender

Di dalam penyelenggaraan tender pengadaan perangkat lunak, terutama yang selama ini diselenggarakan oleh instansi pemerintah, tidak ada persyaratan yang mewajibkan bahwa peserta tender harus memiliki sertifikat standar kualitas. Persyaratan hanya berdasarkan atas pengalaman dan kualifikasi perusahaan. Oleh karena itu untuk memaksa agar pengembang mempunyai sertifikat, maka pemberlakuan persyaratan tersebut perlu dilakukan, seperti ungkapan yang menyatakan “ikut karna terpaksa”, hal ini dapat dijuga diterapkan di dalam implementasi KIPI versi 1.0. Dimana setiap perusahaan pengembang perangkat lunak disyaratkan untuk mempunyai sertifikat KIPI sesuai dengan level yang dibutuhkan, walaupun ini tidak diwajibkan di dalam keputusan presiden no. 80 tahun 2003 tentang pengadaan barang dan jasa, tapi demi kebaikan untuk mendapatkan peserta yang memiliki kualitas di dalam proses pengembangan perangkat lunak, hal ini bisa saja menjadi syarat tambahan yang diminta oleh instansi penyelenggaran tender. Untuk memberlakukan persyaratan ini tentu harus ada koordinasi antara instansi pemerintah, Deperin dan Aspiluki. Sehingga dalam pelaksanaannya dapat berjalan dengan baik.

• Insentif dari Pemerintah
Untuk merangsang agar pengembang dapat ikut di dalam standar KIPI adalah dengan memberikan insentif. Salah satu insentif yang diberikan dapat berupa pengurangan pajak bagi pengembang yang dapat meningkatkan kualitas produk perangkat lunaknya melalui peningkatan level KIPI yang telah dicapainya. Ini untuk memotivasi pengembang agar terus meningkatkan level yang dimilikinya ke level yang lebih tinggi. Hal ini dilakukan agar perusahaan yang mempunyai level tertinggi KIPI dapat beralih dengan mudah ke standar CMM/CMMI. Seperti diketahui pengembangan dan rekayasa teknologi informasi memerlukan biaya yang tidak sedikit. Hal ini berlaku pula dalam pengembangan industri perangkat lunak. Oleh karena itu, adanya insentif dari pemerintah akan merangsang minat swasta untuk mengembangkan kompetensi di sektor industri ini. Hal semacam ini juga dilakukan oleh-negara-negara lain yang sudah sangat maju industri teknologi informasinya. Seperti yang dilakukan oleh pemerintah India, dimana perusahaan-perusahaan India yang bergerak di bidang Teknologi Informasi diberikan bantuan finansial pada saat pengembangan untuk jangka waktu tertentu, dan lewat dari waktu yang sudah ditentukan, perusahaan yang bersangkutan harus menghasilkan devisa dalam jumlah minimum yang sudah ditentukan. Apabila hal ini tidak tercapai, maka perusahaan tersebut harus mengembalikan uang yang sudah diterima dari pemerintah. Contoh lainnya adalah Malaysia, dimana setiap perusahaan yang melakukan investasi di Multimedia Super Corridor (MSC) akan memperoleh banyak kemudahan-kemudahan, antara lain kemudahan perizinan dan perpajakan.
• Menciptakan Budaya Standar

Salah faktor yang menyebabkan software lokal kalah bersaing dengan software asing, seperti yang dikemukakan oleh Romi, adalah keterbatasan di dalam pengembangan software, sehingga pada pada saat sofware diukur dari seluruh proses akan kalah bersaing. Untuk mengatasi hal tersebut perlu kiranya menggalangkan ”budaya standar”. Hal ini telah dilakukan di India, dimana setiap pengembang software diwajibkan menggunakan standar CMM dalam setiap proses pengembangan software. Manfaat yang dapat kita lihat sekarang bahwa India menguasai 75% level 5 CMM.

Dengan tersedianya perusahaan industri software dalam negeri yang berstandar tinggi tentu akan dapat membuka peluang yang lebih besar dalam konteks upaya kolaborasi maupun kerjasama lainnya dengan perusahaan Multi National Company (MNC).

• Proteksi terhadap Produk Lokal

Keberhasilan pelaksanaan KIPI sangat ditentukan oleh komitmen pemerintah untuk terus mendukung implementasi KIPI dan melindungi industri perangkat lunak indonesia terhadap serbuan produk asing. Seperti telah diuraikan di atas bahwa hampir 80% pasar perangkat lunak dalam negeri dikuasi oleh perusahaan asing. Hal ini disebabkan oleh ketidakpercayaan konsumen atas produk perangkat lunak lokal. Oleh karena itu untuk membantu para pengembang perangkat lunak Indonesia harus ada kebijakan pemerintah mengenai pembatasan produk perangkat lunak asing, terutama produk-produk yang telah banyak dihasilkan oleh pengembang lokal. Dengan adanya kebijakan ini diharapkan pengembang lokal akan berlomba meningkatkan kualitas produknya guna memenuhi pasar lokal.

5. Kesimpulan

Standar CMM versi Indoensia atau Kematangan Industri Perangkat Lunak Indonesia (KIPI) telah dikeluarkan oleh Pemerintah Indonesia dengan tujuan untuk meningkatkan kualitas pengembang software lokal sehingga dapat bersaing dengan pengembang software asing.

Permasalahan biaya mahal, waktu yang lama, tidak adanya kesadaran dan kewajiban bagi pengembang perangkat lunak untuk memiliki standar, menyebabkan minimnya standar internasional yang dimiliki oleh pengembangan perangkat lunak Indonesia.

Belajar dari permasalahan yang ada terkait dengan implementasi KIPI versi 1.0 perlu dirancang suatu strategi khusus agar dapat menarik minat para pengembang perangkat lunak Indonesia untuk ikut serta memiliki standar KIPI versi 1.0. Strategi tersebut diantaranya :
• Kemudahan di dalam pengurusan administrasi sertifikasi KIPI.
• Melakukan sosialisasi secara efektif
• Biaya murah dan dapat diselesaikan dengan waktu singkat
• KIPI digunakan sebagai salah satu syarat wajib pagi para pengembang perangkat lunak, apabila ingin mengikuti tender yang dilakukan oleh instansi pemerintah.
• Insentif dari pemerintah bagi pengembang yang dapat meingkatkan level KIPInya.
• Menciptakan budaya standar untuk menghasilkan software yang berkualitas, sehingga dapat bersaing dengan software asing.
• Proteksi terhadap produk asing terutama produk-produk yang telah banyak dihasilkan oleh pengembang lokal.

sumber