Kriteria Keberhasilan Proyek Perangkat Lunak

Standish Group telah melakukan penelitian parameter keberhasilan proyek perangkat lunak dengan mengidentifikasi alasan-alasan yang menyebabkan kegagalan proyek perangkat lunak. Untuk keperluan tersebut, proyek PL diklasifikasikan ke dalam 3 tipe resolusi yaitu resolusi tipe 1 untuk proyek sukses, resolusi tipe 2 untuk proyek challenged dan resolusi tipe 3 untuk proyek yang rusak (gagal).

Proyek dikatakan sukses (success), bila proyek tersebut bisa diselesaikan tepat waktu, biaya tidak berubah dengan fitur dan fungsi seperti yang direncanakan semula. Sementara yang termasuk tipe proyek challenged bila proyek tersebut mampu diselesaikan, namun biaya operasionalnya melebihi perkiraan, waktu penyelesaiannya menjadi molor serta menawarkan fitur dan fungsi yang lebih sedikit dari yang direncanakan. Sedangkan proyek impaired, bila proyek tersebut dibatalkan karena ada beberapa hal yang terjadi selama masih dalam proses pengembangan.

Aspek yang paling penting dari penelitian yang dilakukan Standish Group adalah menemukan sebab-sebab mengapa proyek gagal. Untuk keperluan ini jajak pendapat dilakukan pada manajer eksekutif IT untuk ditanyai pendapatnya tentang mengapa proyek bisa sukses. Ada tiga alasan utama yang bisa menyebabkan proyek PL sukses, yaitu keterlibatan pengguna (user involvement), dukungan manajemen eksekutif (executive management support) dan pernyataan jelas dari kebutuhan (a clear statement of requirement). Memang ada beberapa kriteria yang lain, namun jika tiga elemen tersebut sudah pada tempatnya, maka kesempatan poyek akan sukses jauh lebih besar. Sebaliknya, bila hal tersebut tidak terpenuhi potensi gagal bisa meningkat tajam.

Tabel 1. Kriteria Proyek Sukses

Dalam jajak pendapat tersebut, responden juga diminta pendapatnya tentang faktor apa saja yang menyebabkan proyek challenged, hasilnya seperti terlihat dalam tabel 2.

                                  Tabel 2. Kriteria Proyek Challanged   

          

Hasil jajak pendapat tentang opini mengapa proyek menjadi rusak dan terancam dibatalkan, faktor terbesar dikarenakan daftar kebutuhan yang kurang lengkap serta terlalu sedikitnya keterlibatan pengguna.

                                      Tabel 3. Kriteria Proyek Impaired

        

3 Kunci Sukses Proyek Perangkat Lunak

          Ada tiga faktor yang umumnya mempengaruhi keberhasilan sebuah proyek perangkat lunak (PL). Masing-masing merupakan faktor kunci yang membentuk sebuah tripod dari suatu proyek, sehingga ketiga kakinya harus berada dalam posisi yang benar agar tripod tersebut dapat berdiri kokoh. Kaki-kaki tersebut merupakan konotasi dari ketiga faktor kritis yang berperan dalam kesuksesan sebuah proyek  PL yaitu  top management support, a sound  methodology dan solid technical leadership.

Top Management Support

Dukungan manajemen puncak dianggap sebagai faktor sukses yang paling penting. Tanpa komitmen penuh dari menejemen puncak, ketika timbul masalah dalam proyek (musibah yang tidak bisa dielakkan) bisa menyebabkan kolaps. Personil manajemen dalam organisasi yang mengerjakan proyek sistem harus berada di barisan paling depan untuk mengatasi penyimpangan yang terjadi secara serius. Mereka perlu dipersiapkan untuk menemukan sebab-sebab yang tampak maupun yang tidak tampak dibalik kemunduran sebuah  proyek atau  yang sedang mengalami masalah. Manajemen puncak harus benar-benar berada dibelakang sebuah proyek dan begitupun bila akhirnya proyek tersebut menjadi sukses.

Ada perbedaan antara proyek sistem dengan gedung perkantoran. Ketika sebuah gedung baru dikerjakan separohnya, maka sudah ada sesuatu yang bisa dilihat. Sementara jika Proyek PL masih  setengah jadi, hanya  sedikit sekali (bahkan tidak ada sama sekali) yang bisa dilihat. Manajer perlu mengetahui apa yang dapat mereka harapkan dan kapan hal tersebut bisa terjadi. Mereka tidak bisa begitu saja berasumsi bahwa proyek yang telah berjalan 50% berarti  juga telah menghabiskan biaya  50%.

Seorang manajer seringkali  tidak memahami desain sebuah sistem, sehingga mereka jarang memberikan nasihat teknis. Manajer tersebut sebaiknya membawa auditor obyektif  agar manajemen bisa tahu bahwa mereka sedang tidak tertipu atau proyek tidak sedang mengalami mismanajemen. Bila mereka tidak memiliki kemampuan menilai situasi, solusinya cukup sederhana yaitu dengan memiliki technical audit yang bisa mensyahkan tindakan tim pengembangan dan memberikan informasi yang diperlukan untuk kelanjutan proyek.

Development Methodology

Banyak sistem yang dibangun dengan sedikit memikirkan proses. Segera setelah informasi yang diperoleh cukup memadai, pekerjaan coding langsung dimulai. Lambatnya perhatian pada proses sebenarnya bisa membunuh sistem itu sendiri. Kesalahan terbesar biasanya disebabkan adanya kebutuhan user yang diabaikan. Akibatnya sejumlah besar kode perlu ditulis ulang, karena tidak ditemukan dalam user requirement. Dampak lanjutan dari kesalahan tersebut, meskipun pada akhirnya proyek bisa selesai, namun sistem menjadi tidak efisien dengan testing yang tidak mencukupi pula. Dengan kata lain, tanpa memikirkan proses secara baik, sebuah proyek hanya memiliki sedikit kesempatan bisa diselesaikan dengan baik. Kalaupun bisa sukses, mungkin hanya menuliskan ulang bagian-bagian substansial dengan biaya yang membengkak.

Ini mungkin mengejutkan bila ada pendapat yang mengatakan bahwa metodologi tidak perlu diseleksi, tetapi kenyataannya hal tersebut bisa benar adanya. Apa yang terjadi bila ada beberapa metodologi? Tidak ada kajian jelas yang menggambarkan suatu metodologi lebih baik dari yang lain. Yang paling penting bahwa  proyek dikelola dengan cara-cara yang konsisten, fokus serta sejak awal telah berpikir lewat kerangka proses secara hati-hati.  

Technical Leadership

Bukan hanya bangunan saja yang membutuhkan arsitek, namun sistem informasi juga memerlukan pimpinan teknik. Agar sukses, arsitek ataupun pimpinan teknik harus berada dalam satu kendali arsitektur proyek yang sama, yang disebut model data atau desain aplikasi. Kendali level ini harus dikenali dan dimengerti oleh setiap orang yang terlibat dalam proyek. Sebaliknya, bila setiap bagian sistem dikonstruksi secara berbeda  maka potongan-potongan tersebut tidak akan cocok bila digabungkan di kemudian hari. 

Faktor-Faktor Yang saling Mempengaruhi Kesuksesan Proyek Perangkat Lunak

Interdependent Factors 

Dalam setiap proyek sistem perangkat lunak, terdapat  empat faktor yang saling berpengaruh satu sama lain, yaitu :           

§         Harga (Cost)

§         Kualitas (Quality)

§         Kecepatan (Speed)

§         Resiko (Risk).

Namun tidak mungkin mendapatkan hasil terbaik keempat faktor tersebut secara bersamaan. Terutama, tidak  akan bisa membangun sistem dengan biaya murah, berkualitas tinggi, diselesaikan secara cepat dengan sedikit atau bahkan tanpa resiko kegagalan sama sekali. Kebanyakan hanya tiga faktor pertama saja yang mungkin bisa direalisasikan,  yaitu membangun sistem berkualitas tinggi secara cepat, biaya yang relatif murah dengan jalan memotong bagian-bagian tertentu dan hanya melakukan sedikit atau bahkan tanpa pengujian (testing) sama sekali. Bagaimanapun juga, resiko kegagalan sistem tersebut akan meningkat secara dramatis.  

 Dalam setiap proyek, dari keempat faktor tersebut hanya dua saja yang mungkin berhasil, sedang dua sisanya harus diatur. Dari keempat faktor tersebut, dua yang paling penting adalah resiko dan kualitas. Sistem yang dibuat harus mampu bekerja dan memenuhi kebutuhan user.  Hal ini menyisakan kecepatan (waktu) dan biaya (uang) sehingga harus diatur menyesuaikan. Bila proyek menuntut waktu pengembangan yang cepat atau biaya rendah, maka kualitas dan resiko akan digeser menyesuaikan. Jika ada yang mengatakan bahwa dengan menggunakan produk X dan metodologi Y maka  sistem dapat dibangun cepat  dengan biaya murah, rasanya hal tersebut kurang realistis. Jika dipaksakan pada resiko rendah dan berkualitas tinggi, harus bisa menerima kenyataan bahwa waktu dan biaya harus diatur agar dapat mencapai maksud tersebut. 

Migrasi Data Dan Implementasi 

Dua faktor tambahan yang juga menentukan sukses atau gagalnya proyek adalah migrasi data dan implementasi proyek itu sendiri. Namun kenyataanya kedua faktor tersebut sering dilupakan. Migrasi data seharusnya direncanakan lebih awal pada setiap proyek. Ironisnya, migrasi data seringkali dianggap sebagai proyek terpisah. 

Meskipun telah berkeahlian baik, didokumentsikan dengan baik dan desain telah dibuat dengan teliti, sebuah sistem masih berpotensi gagal 10-20% (dari waktu), dikarenakan implentasi yang tidak bisa ditangani secara baik. Hal ini dapat disebabkan pelatihan user yang kurang memadai, lemahnya transisi dari sistem lama ke yang baru dan kurangnya dukungan user ke sistem baru.

Faktor-Faktor Penyebab Kegagalan Proyek Perangkat Lunak

Hampir semua proyek perangkat lunak (PL) dapat dikatakan mengalami kegagalan, walaupun hanya di bagian tertentu saja. Hal ini dikarenakan, hanya sedikit saja proyek yang dapat memenuhi semua target yang ditetapkan baik dari sisi harga, jadwal waktu penyelesaian, kualitas maupun kebutuhan yang diinginkan pengguna (user).        

Hanya saja yang masih menyisakan pertanyaan, mengapa kebanyakan  proyek yang gagal tidak pernah dikaji lebih lanjut, bahkan oleh lembaga yang mengalaminya sendiri ? Seandainya hal tersebut dilakukan mungkin akan dianggap sebagai suatu petualangan yang tidak akan membuahkan hasil (pemborosan), sehingga sedikit yang mau menginvestasikan waktu dan uangnya untuk mengumpulkan data dan menganalisanya. Bahkan data yang telah berhasil dikumpulkannya mungkin juga hanya berhasil disusun saja, kemudian disembunyikan untuk melindungi karir dan reputasi lembaga tersebut. Walhasil pemilik informasi tentang kegagalan-kegagalan proyek sering kali berat untuk mempublikasikannya walau untuk tujuan tertentu (yang baik).       

Sekali lagi, yang dimaksud dengan kegagalan disini adalah proyek perangkat lunak yang mengalami pembengkakan harga, penyelesaiannya molor atau kualitasnya bermasalah (challenged project) maupun yang mengalami pembatalan secara tiba-tiba (failed project).  Dan uraian berikut ini akan menjelaskan beberapa penyebab kegagalan yang sering terjadi dalam pengembangan proyek perangkat lunak. 

 1.  Poor User Input

 Masukan penting yang diperlukan untuk membangun perangkat lunak (PL) adalah bagaimana sistem yang dibuat tersebut akan dipakai di lapangan. Sedangkan yang berkompeten memberikan masukan dalam hal ini adalah klien (user) itu sendiri. Hanya saja yang sering terjadi , bahwa user kurang terbuka dalam menyatakan kebutuhannya, padahal hal itu sangat berdampak pada pekerjaan software developer. Akibatnya, pihak developer harus bekerja keras untuk memahami apa saja yang menjadi bisnis user, sehingga bisa memprediksi fasilitas apa saja yang diperlukan. Hal tersebut sering berkelanjutan hingga proses development selesai. 

  2.  Stakeholder Conflichts

 Stakeholder bekerja di bawah ilusi bahwa semua orang harus mendapatkan apa yang mereka inginkan. Akibatnya sejumlah alternatif yang berbeda dipersiapkan untuk mengakomodasi semua permintaan yang mungkin timbul. Perbedaan tersebut selanjutnya diekspos oleh developer dan mengakibatkan sistem menjadi ambigu. Konflik dalam stakeholder ini bisa menjadi biang utama kegagalan sebuah proyek, karena pihak developer tidak dapat memahami apa yang sesungguhnya diinginkan oleh stakeholder.  

3.  Vague Requirement

Perlu bekerja keras untuk mempelajari apa yang akan terjadi ketika sebuah proyek mulai dikerjakan pada saat kebutuhan yang diinginkan belum jelas. Bisa jadi untuk setiap step yang diambil kemudian perlu mundur tiga langkah ke belakang. Biaya proyek dan kualitas hasil yang berubah cepat bisa lepas dari kontrol, sehingga perusahaan bisa dipersalahkan bahkan bisa kehilangan kontrak untuk menyelesaikan proyek tersebut.Seperti yang sering terjadi pada sejumlah proyek gagal, bahwa lingkup permasalahan yang tidak cukup sempit tidak bisa memberi peluang yang masuk akal untuk sukses. Oleh karenanya perlu memastikan kebutuhan yang diinginkan user sebelum pekerjaan tersebut dimulai. Kendati demikian, kenyataannya perkembangan kebutuhan masih saja terjadi. Permasalahan ini bisa diatasi bila arsitektur dan prosesnya dibuat mampu mengakomodasi perubahan atau setidaknya dibuat ketentuan jelas bagaimana dan kapan requirement bisa ditambahkan, dilepas dan diimplementasikan, termasuk siapa yang akan menanggung biaya perubahan tersebut. 

4.  Poor Cost and Schedule Estimation  

Sebenarnya tidak fair menuduh setiap proyek PL pasti mengalami kegagalan, jika tidak mengaitkan antara biaya yang dikeluarkan dengan tujuan yang diinginkan. Sama seperti yang lain, setiap proyek PL juga memiliki jadwal dan biaya minimal yang dapat dicapai. Permasalahan bisa muncul kapan saja manakala orang  yang membuat jadwal tidak mendengarkan masukan orang yang biasa mengerjakannya. Misalnya untuk menyelesaikan sebuah program biasanya diperlukan 5 orang selama setahun, jelas berbeda seandainya hanya dikerjakan 4 orang selama 8 bulan, baik dilihat dari sisi desain maupun quality-check-nya.   

  5.  Skills That Do Not Match The Job

Pengerjaan proyek dengan teknologi tinggi memerlukan seorang manajer dengan kemampuan teknik yang hebat. Penanggung jawab proyek harus bisa menempatkan orang yang memahami dampak dari resiko teknik yang diambil. Namun demikian, seorang teknolog yang baik tidak perlu diseimbangkan dengan manager yang baik, karena kemampuan manajemen dan pemrograman tidak bisa dipertukarkan.Pada proyek yang lebih besar membutuhkan orang-orang yang cakap dalam planning, oversight, organization dan communication skill; sementara seorang teknolog yang brilian tidak perlu memiliki keahlian tersebut.Sebuah team yang beranggotakan orang-orang dengan gaji lebih besar namun memiliki kemampuan spesialisasi yang baik, akan lebih pantas dipilih daripada sebuah kelompok yang terdiri dari orang-orang dengan gaji rendah yang masih memerlukan berminggu-minggu bahkan berbulan-bulan untuk mempelajari sebuah proses atau teknologi baru sebelum mereka mulai mengerjakannya. 

6.  Hidden Cost of  Going “Lean and Mean”

Sejumlah kegagalan akan dipandang sebagai hasil langsung dari kinerja yang buruk, meskipun sesungguhnya kinerja yang buruk tidak menunjuk pada faktor yang signifikan dalam kegagalan pada kebanyakan proyek. Kegagalan sebuah proyek tidak bisa terlepas dari rencana tujuan yang ingin dicapai.  Hal lain yang juga pantas dicermati adanya perbedaan kecenderungan yang terjadi dalam sebuah organisasi. Pada level yang lebih rendah, seorang developer akan sibuk menghitung pengeluaran mereka yang mahal, hasil kerja pegawai, update software dan pekerjaan-pekerjaan lainnya, sedangkan pada tingkatan yang lebih tinggi hal tersebut akan dikerjakan oleh seorang spesialis yang memadai. Kebanyakan software developer akan menghabiskan setengah dari jam kerja mereka untuk berlama-lama dalam mengerjakan tugas yang diberikan dengan tanpa melakukan apapun terhadap pekerjaan tersebut. Orang-orang demikian ini sangat tidak berkemampuan dan menjadi isu produktifitas yang sangat serius. 

7.  Failure to Plan

Banyak orang bekerja keras, tapi tak seorangpun yang memiliki rencana, karena tidak ada yang merasa perlu membuat rencana. Seorang manajer proyek sering tidak membuat rencana, karena banyak rencana yang diserahkan bersamaan dengan berlalunya waktu.  Mereka mengira waktunya akan habis untuk melakukan hal-hal seperti planning, design, requirement dan inspection.   Kebanyakan dari mereka berpendapat bahwa hal-hal tersebut bisa dilakukan bersamaan dengan pekerjaan sesungguhnya, seperti pada saat coding dan testing. Pandangan ini umumnya datang dari kalangan programmer yang mengisukan bahwa hal tersebut dapat dilakukan ketika perangkat lunak diimplementasikan, padahal jelas ada perbedaan antara speed dan progress. Kita perlu memberi penghargaan pada orang-orang yang tidak menganut pandangan itu sehingga terlepas dari misi bunuh diri tersebut. 

 8.  Communication Breakdown

Sejumlah problema yang timbul pada proyek berskala besar biasanya jika orang yang mengerjakannya berasal dari bagian yang berbeda. Dalam banyak kasus proyek yang bermasalah, tidak ada seorang pun yang memiliki pandangan yang menyeluruh pada proyek tersebut, khususnya bila proyeknya berskala besar. Untuk itu perlu kiranya menginvestasikan waktu tambahan secara periodik agar semua orang di setiap posisi bersedia mempelajari gambaran besar proyek tersebut. Hal ini sejalan dengan sementara orang yang berpendapat bahwa seorang yang mengerjakan kepingan-kepingan kecil sebuah puzzle perlu mengetahui bagaimana sebuah keping bisa masuk ke dalam arsitektur gambar keseluruhan.   

9.  Poor Architecture

 Desain perangkat lunak sebaiknya dapat dikonfigurasi ulang untuk mendukung sebuah fungsi baru. Sebuah arsitektur PL seharusnya bisa mengikuti organisasi dan misi yang berubah, setidaknya harus memperhitungkan keterbatasan jangka panjang, tingkat kesulitan dan harganya. Arsitektur PL harus dipandang seperti bangunan rumah, dimana penambahan pipa dan kabel  harus bisa dilakukan untuk fasilitas yang belum terpikirkan sebelumnya. Begitupun ketika sebuah PL mengalami perubahan kebutuhan atau bisnis yang tidak diantisipasi sebelumnya, harus dapat ditambah atau dimodifikasi tanpa harus membuat PL yang baru. 

10    Late Failure Warning Signals

Lamanya waktu penyelesaian dan besarnya biaya pembuatan PL sangat dipengaruhi oleh  sinyalemen orang yang mana kita takut mengatakan “tidak” kepadanya. Kedengarannya hal ini tidak baik secara politik dikarenakan  mengatakan atau menunjukkan perkiraan yang jauh dari yang dapat dijalankan. Memang kenyataannya tak seorangpun bisa mengetahui bencana yang mendekat karena sering kali tak terlihat gejala awalnya. Dalam dunia nyata, sama seperti orang yang levelnya lebih rendah dapat meyakinkan manajer level atasnya bahwa proyek tersebut sesungguhnya tidak dapat dikerjakan sedemikian rupa hingga jatuh kepadanya.  

Mengapa Proyek Perangkat Lunak Sering Gagal ?

Proyek perangkat lunak sering tidak berhasil. Menurut sebuah penelitian, tingkat kegagalan proyek perangkat lunak berskala besar bisa mencapai 50% hingga 80 %. Data tersebut bisa saja belum menggambarkan realitas sesungguhnya, mengingat sifat alami manusia yang cenderung suka menyembunyikan kabar buruk, sehingga kondisi  riilnya bisa lebih besar dari angka itu. 

 Standish Report Version           

Menurut  Standish Report (USA), outcome sebuah software engineering project dapat dikelompokkan dalam 3 katagori :

1. Successful, dimana proyek tersebut bisa selesai tepat waktu dengan biaya yang tidak berubah dan menghasilkan feature & function seperti yang diharapkan.
2. Challanged, dimana proyek tersebut bisa diselesaikan  dan mampu beroperasi baik, namun waktu penyelesaiannya molor, biaya membengkak dengan feature & function yang lebih sedikit dari yang direncanakan semula.
3. Failed, dimana proyek dihentikan ketika masih dalam siklus pengembangan dengan alasan tidak lengkapnya daftar kebutuhan (requirement) yang diinginkan. Tentu saja produk perangkat lunaknya tidak pernah diimplementasikan dan dibongkar dari instalasi.   

Sebagai gambaran betapa masih tingginya tingkat kegagalan proyek perangkat lunak di negara yang telah maju sekalipun, tabel berikut menunjukkan perkembangan tingkat keberhasilan proyek pengembangan perangkat lunak (software development project) di Amerika Serikat dari tahun ke tahun :

Dampak kegagalan seperti yang dilaporkan Standish Report tersebut berakibat pada pemborosan SDM dan peralatan, hilangnya dana klien, kerugian instalasi, bahkan hilangnya sebuah kehidupan. Dan ketika diproses di lembaga hukum, aduannya banyak dimentahkan oleh pihak pengadilan. Padahal biaya peradilannya sendiri seringkali lebih besar dari pada coding cost yang dipermasalahkan itu. Dan sekalipun telah lebih dari 12 tahun berselang, seperti dalam laporan terbaru Standish Report (2006), bahwa proyek perangkat lunak yang dibuat mulai 2006 yang berkatagori sukses baru beranjak ke level 35% (dari 16,2 % di tahun 1994). Ini berarti baru 35% dari proyek perangkat lunak yang bisa selesai tepat waktu, tepat biaya dan memenuhi kebutuhan user.  Lebih lanjut dilaporkan bahwa proyek yang sama sekali gagal  turun menjadi 19% (dari 31,1% ditahun 1994), sedangkan proyek yang termasuk dalam kelompok challenged turun menjadi 46% (dari kisaran 52,7% di tahun 1994). 

OXPORD University Version 

Sebuah kajian yang lain dilakukan oleh laboratorium komputer OXPORD University, yang menyebutkan bahwa ketidakberhasilan sebuah proyek perangkat lunak banyak disebabkan karena :1.    Kegagalan mengkomunikasikan permintaan klien dengan anggota team desain inti.2.    Kurangnya metode yang dapat menjamin requirement statement yang konsisten, akurat dan lengkap. 3.    Ketidakmampuan mengatasi perubahan (evolusi) permintaan klien (user).Penelitian tersebut juga berhasil menyimpulkan bahwa biang kegagalan sebuah proyek perangkat lunak yang paling umum adalah ketidakberhasilan dalam mendefinisikan permintaan klien secara akurat. Dan kesalahan yang sering terjadi selama ini bukan karena suatu faktor yang misterius, melainkan  kesalahan yang baru diketahui di kemudian hari setelah proses pengembangan perangkat lunak telah berubah cukup jauh.  

Software Project Suscces

Perlu diketahui bahwa Standish Group dibawah pimpinan Jim Johnson telah mengamati tingkat keberhasilan proyek perangkat lunak secara konsisten sejak tahun 1994, dan mengeluarkan laporannya setiap 2 tahun sekali (kecuali di tahun 2004). Johnson menunjuk 3 faktor yang bisa memperbaiki kualitas produk perangkat lunak yaitu manajemen proyek yang lebih baik (better project management), pengembangan berulang (iterative development) dan kemunculan prasarana Web (the emerging Web infrastructure).Perbaikan manajemen proyek yang dimaksud adalah dalam pengertian keahlian maupun segi teknik. Seorang manajer harus memiliki pemahaman yang lebih baik terhadap dinamika proyek. Harus bisa mempermudah orang lain untuk mendapatkan apa yang mereka inginkan merupakan bagian proses pembelajaran untuk iterative development yang dapat membuat orang lain dapat menyatakan secara jelas apa yang mereka harapkan dari hasil proyek secara lebih baik. Dan pada akhirnya kehadiran Web akan memainkan peran yang sangat penting, dimana suatu ide yang diperoleh bisa dipublikasikan secara cepat dan orang lain dapat mempelajarinya, menganalisanya dan memberikan umpan balik agar menjadi informasi yang lebih dinamis.  (Diolah dari berbagai sumber ).

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!