Saturday, October 2, 2010

Enterprise Resource Planning

Saat kuliah s2 dulu, aku hanya mendapatkan kuliah Perencanaan Strategis Sumber Daya Perusahaan. adanya sedikit perbedaan dengan Enterprise Resource Planning. terutama aku tidak ingin mengecewakan dosen pengampu sebelumnya.

Enterprise Resources Planning (ERP) adalah aplikasi perangkat lunak komputer yang terintegrasi dan menyeluruh. Secara arsitektural sistem, ERP dikembangkan berdasarkan modul-modul fungsional yang meliputi seluruh aspek sumber daya di dalam sebuah perusahaan/organisasi.

untuk pendahuluan ERP dapat dibaca selengkapnya pada

02_Definisi_ERP


Read More..

Wednesday, September 29, 2010

Open Source

Open Source adalah sebuah sistem baru dalam mendistribusikan software kepada pengguna dengan memberikan program dan source code secara gratis. Selain itu pengguna dapat membaca kode sumber aplikasi, mempelajari, menggunakan, melakukan modifikasi, dan juga berhak mendistribusikan kembali dengan lisensi yang sama untuk membuat software sesuai dengan kebutuhan pengguna. Adanya lisensi software untuk Open Source yang dinamakan GPL (GNU Public License) digunakan untuk mendistribusikan software Open Source.

Pola Open Source lahir karena kebebasan berkarya, tanpa intervensi berpikir dan mengungkapkan apa yang diinginkan dengan menggunakan pengetahuan dan produk yang cocok. Kebebasan menjadi pertimbangan utama ketika dilepas ke publik. Komunitas yang lain mendapat kebebasan untuk belajar, mengutak-ngatik, merevisi ulang, membenarkan ataupun bahkan menyalahkan, tetapi kebebasan ini juga datang bersama dengan tanggung jawab, bukan bebas tanpa tanggung jawab.

Untuk materi pendahuluan OS, dapat dilihat pada

02-OS_Pendahuluan_TOSS

03-OS_License_TOSS

04-OS_Linux

05-OS-E_Learning

Read More..

Mata Kuliah Pemrograman Terstruktur

ini adalah pengalaman pertamaku mengajar mata kuliah yang berhubungan dengan pemrograman. aku harap materi yang aku upload disini dapat dimanfaatkan dengan baik, terutama dari mahasiswa yang aku bimbing.
Pemrograman Terstruktur adalah tindakan mengorganisasi dan membuat kode-kode program supaya mudah dimengerti, dites dan dimodifikasi. Prinsip utama pemrograman terstruktur adalah jika suatu proses telah sampai pada suatu titik tertentu, maka proses selanjutnya tidak boleh kembali lagi ke baris sebelumnya, kecuali untuk proses berulang (Loop).
Setiap teknik dikembangkan untuk tujuan tertentu. Teknik pemrograman dalam pemrograman terstruktur ini mempunyai tujuan: meningkatkan kehandalan program supaya program mudah dibaca dan ditelusuri apabila ada kesalahan, menyederhanakan kerumitan program, menyederhanakan pemeliharaan program, meningkatkan produktifitas pemrogram.
untuk materi pendahuluan Pemrograman Terstruktur dapat dibaca selengkapnya pada
02_Pendahuluan_PT
03_Pendahuluan_JAVA
04_Pemrograman_Dasar_Java
05_Rekursi_Overloading_Konversi
06_Percabangan
07_Perulangan
08_Array
09_Prosedur
10_Fungsi
11_Class_Library
Read More..

Wednesday, June 30, 2010

anakku adalah guruku

Ini adalah pengalaman pertama aku menjadi seorang ibu. Pada bulan November’08 aku bersama mantan kekasihku untuk memutuskan memulai bersama, kemudian satu bulan kemudian datang hadiah terbesar dalam hidup kami, buah cinta kami. Aku benar-benar sangat kaget dan bersyukur, karena bisa dikatakan tamu bulananku tidak lancar, bisa 2-3 bulan sekali. Tetapi syukur alhamdulilah DIA memberikan kado istimewa yang begitu cepat.

Keesokan harinya aku mencoba tes kehamilan tersebut, dan ternyata hasilnya positif. Tidak puas dengan hasil tes kehamilan, kita pergi ke dokter kandungan dan dokter pun membenarkan hasil dari tes kehamilan tersebut. Mulai dari sinilah penantian aku untuk menjadi seorang ibu dimulai.Saat awal kehamilan, aku masih dalam menyelesaikan tugas akhir kuliah. Saat itu aku memerlukan untuk membawa laptop setiap kali aku ke kampus untuk menunjukkan software yang telah aku kerjakan kepada dosen pembimbing. Awalnya aku tidak merasakan beban tas yang aku bawa, tetapi dengan berjalannya waktu, perutku terasa kram. Aku baru tau ternyata dalam kondisi hamil, angkat beban yang terlalu berat bisa mengakibatkan otot menjadi tegang dan dapat membahayakan perut [1]. Ibu hamil harus menghindari mengangkat beban-beban berat, termasuk menggendong anak atau mengangkut ember berisi air, karena dapat memicu kontraksi rahim. Bila terjadi dalam jangka waktu cukup lama dapat mengakibatkan keguguran atau kelahiran prematur. Meski begitu, mengangkat barang dalam batas-batas normal tidak masalah. Sehingga ibu harus bisa menilai sendiri, apakah yang diangkatnya akan membebani perutnya atau tidak. [2]. Mengangkat beban berlebihan.

Keinginan aku saat masih kuliah, dapat menyelesaikan kuliah dan mengikuti yudisium sebalum bayi ini lahir. Karena terlalu sibuk dengan pekerjaan, aku terkadang lupa makan. Untungnya bayi ini selalu mengingatkanku untuk selalu mengkonsumsi makanan ringan setidaknya 3 jam sekali [3]. Waktu itu yang sering aku pilih adalah apel, karena terasa segar dan tidak terlalu mengenyangkan. Makan.

Tentunya mengkonsumsi air putih tidak kalah pentingnya karena ibu hamil memerlukan banyak cairan agar kinerja tubuhnya bisa terus beraktifitas untuk kelangsungan hidup dua nyawa. Dengan meminum air putih minimal delapan gelas per hari dapat membantu mencegah infeksi urin atau Urinary Tract Infections (UTIs) yang dapat menyebabkan dehidrasi. Air juga dibutuhkan untuk membawa nutrisi dari darah ke janin. Tak heran bila kecukupan minum juga mampu menghindarkan ibu dari kemungkinan lahir prematur di trimester ketiga kehamilan. Selain itu air dapat membantu mencegah terjadi hipertensi serta morning sickness [4] Minum air putih.

Memasuki bulan kedua masa kehamilan, kondisi rumahku seperti kapal pecah. Hal ini dikarenakan rumahku sedang dalam masa renovasi. Saat itu aku merasa benar-benar tidak tahan dengan aroma bahan bangunan, suara bising dari mesin gergaji, bor, dsb. Untungnya di alam rahim suara bising tidak terlalu berpengaruh kuat, hanya saja akan lebih baik bila janin dirangsang dengan suara musik yang menenangkan sang ibu dan janin karena dapat merangsang kestabilan emosi janin serta meningkatkan kecerdasan janin [5]. Suara bising

Gambar 1. My Baby saat usia 6 Minggu

Yang tetap membuat aku semangat dalam menjalani masa kehamilan adalah perhatian dari orang-orang terdekatku, salah satunya dari ayahku. Beliau termasuk perokok kelas ringan. Tetapi aku selalu merasa mual apabila mencium asap rokok. Syukur alhamdulilah, ayah benar-benar pengertian. Setiap kali ayah ingin merokok, beliau lakukan di luar rumah atau setidaknya menjauhi aku. Karena dalam publikasi Journal of Epidemiology and Community Health mengungkapkan ibu hamil yang menghirup udara kotor akan menyebabkan anaknya berisiko kanker, leukemia (kanker darah) Polusi udara yang dihirup oleh sang ibu, akan membawa karsinogen (penyebab kanker) masuk ke janin melalui plasenta (ari-ari). [6]. Tidak hanya itu asap rokok juga dapat mengakibatkan:

  • Kehamilan di luar rahim
  • Abortus (keguguran) spontan
  • Plasenta menutupi mulut rahim (plasenta previa)
  • Plasenta lepas (abrupsia plasenta)
  • Ketuban pecah dini
  • Infeksi kantong cairan ketuban (chorioamnionitis)
  • Kelahiran prematur
  • Bayi lahir dengan berat badan rendah
  • Janin meninggal dalam rahim [7]. Asap rokok

Selain asap rokok, polusi udara juga berbahay bagi ibu hamil. ”Jika ibu hamil menderita penyakit terkait polusi udara, itu mempengaruhi suplai makanan pada bayi,” kata dr Rinawati Rohsiswatmo dari Divisi Neonatal Departemen Kesehatan Anak Fakultas Kedokteran Universitas Indonesia Rumah Sakit Cipto Mangunkusumo, Jakarta. Para peneliti dari University of Medicine and Dentistry di New Jersey merekam data Badan Perlindungan Lingkungan AS tentang pengaruh polusi udara terhadap ibu hamil. Hasil studi itu menunjukkan, dibandingkan dengan ibu yang memiliki bayi berbobot tubuh lahir normal, para ibu yang melahirkan bayi dengan berat badan lahir rendah dan sangat rendah ternyata berusia lebih muda, tingkat pendidikan rendah, perokok, miskin, dan orang tua tunggal [8]. Kabar dari American Journal of Epidemiology, menunjukkan jika si ibu menghirup polusi udara dari asap kendaraan bermotor yang mengandung karbon monoksida atau partikel sejenis, maka kemungkinan 20 hingga 25 persen akan mengalami kelahiran prematur sebelum usia kandungan mencapai usia 37 minggu. “Fakta ini menunjukkan betapa berbahayanya polusi udara bagi keselamatan ibu hamil,” ujar Dr. Beate Ritz, dari unit Kesehatan masyarakat Univeristy Of California, Los Angeles. [9]. Polusi udara.

Salah satu sikap tubuh yang harus Anda perhatikan sewaktu hamil adalah jangan terlalu lama dalam posisi duduk maupun berdiri. Memang, gangguan yang muncul bisa dikatakan bukan masalah serius. Tapi, toh bisa menimbulkan rasa tidak nyaman. Beberapa tips saat duduk maupun berdiri dapat dilihat di internet, salah satunya [10]. Beberapa gangguan yang sering dikeluhkan akibat kelamaan duduk atau berdiri, yaitu:

  • Kram kaki.
  • Pegal dan lelah.
  • Nyeri pinggang bawah.
  • Pembengkakan pada tungkai dan pergelangan kaki.
  • Varises (pelebaran pembuluh darah).
  • Kontraksi dini

Gambar 2. My Baby saat usia 10 Minggu

Semua orang tau dalam masa kehamilan konsumsi ikan sangat diperlukan bagi janin untuk meningkatkan kecerdasan otak [11]. Tetapi berhati-hatilah dalam memilih ikan, karena ikan yang tidak segar justru membuat janin teracuni dengan makanan yang kita makan. Waktu itu aku membeli ikan yang sudah diberi bumbu, sehingga aku tidak dapat mengetahui kesegaran ikan yang aku beli tersebut. Setelah aku makan ikan tersebut, bayi ini memberi respon dengan memuntahkan makanan yang aku makan. Untungnya aku bisa mengeluarkan makanan yang kurang sehat itu, dan tentu saja aku mengganti asupan makanan yang telah dikeluarkannya. Sejak saat itu aku selalu membeli ikan yang tidak diberi bumbu, sehingga aku bisa melihat kesegaran ikan yang akan aku beli. Kesegaran ikan.

Sekarang aku ingin menceritakan pengalamanku dengan makanan yang dikenal praktis, cepat, lezat dan juga murah. Yang aku maksud adalah mie. Setiap kali aku makan mie, bayi ini selalu menolak dengan mengeluarkan makanan tersebut. Meski resiko kesehatan akibat additive tak langsung kelihatan, namun menurut Arlene Eisenberg, dalam buku What to Eat When You're Expecting, ibu hamil sebaiknya menghindari makanan yang banyak mengandung additive. Bagi balita, bahan-bahan yang sebenarnya tak dibutuhkan tubuh ini juga bisa memperlambat kerja organ-organ pencernaan. Selain itu juga kandungan utama dari mie adalah karbohidrat. Lalu ada protein tepung (gluten), dan lemak, baik yang dari mienya sendiri maupun minyak sayur dalam sachet. Jika dilihat komposisi gizinya, mie memang tinggi kalori, namun miskin zat-zat gizi penting lain seperti vitamin, mineral dan serat [12]. Mie.

Gambar 3. My Baby saat usia 22 Minggu

Pada saat hamil, aku kurang menyukai teh. Apalagi kopi, mencium aromanya saja sudah membuatku merasa mual. Hal ini disebabkan karena kopi dan teh mengandung kafein yang memiliki efek merangsang syaraf serta memacu kerja jantung dan otot. Bila dikonsumsi secara berlebih dengan kadar kekentalan tinggi, janin bisa terkena gangguan epilepsi [13]. Selain itu kopi dapat mengakibatkan keguguran. Ingat juga kafein tidak hanya terdapat di dalam kopi tapi juga di dalam teh, dan beberapa softdrinks yang mengandung kafein [14]. Kopi, Teh dan softdrink.

Gambar 4. My Baby saat usia 30 Minggu

Memakan es krim tentu sangat menyenangkan bagi sebagian besar orang. Tetapi aku sempat bingung wanita hamil kurang diperkenankan mengkonsumsi makanan yang manis karena dapat menyebabkan ukuran si bayi oversize. Akhirnya aku mendapat beberapa artikel mengenai es krim. Kandungan es krim memang dapat membuat bayi oversize jika dikonsumsi berlebihan [15]. Tetapi es krim dapat membantu wanita untuk mendapatkan momongan, menurut laporan dan data yang diambil dari Nurses Health Study. Wanita yang hanya mengkonsumsi sekitar dua atau lebih porsi produk susu olahan rendah lemak memiliki resiko kurang subur atau kurang memiliki kesempatan untuk hamil sekitar 85 persen. Sementara wanita yang rajin mengkonsumsi produk kaya lemak seperti es krim kaya susu hanya memiliki resiko 27 persen yang mengalami kegagalan kehamilan, seperti dilansir dari Associated Press pada tanggal 28 Februari 2007. Dr Jorge Chavarro, pemimpin studi menasehati kaum wanita yang ingin memiliki momongan untuk kembali memikirkan diet rendah susu yang mereka jalani. "Dalam artian kita tak menyarankan untuk makan es krim tiga kali sehari, namun akan lebih baik untuk memulai diet sehat dengan mengganti panganan dari olahan rendah lemak dan menggantinya dengan produk susu olahan kaya lemak sehari sekali," jelas Doktor dari Harvard yang yakin bahwa pola diet seimbang akan memberi efek yang baik pada alat reproduksi wanita. Hal senada juga dikatakan Dr Richard Fleming, dari Glasgow Centre for Human Reproduction, yang menyebutkan wanita yang melakukan diet rendah lemak harus berhati-hati dengan kemandulan. Dalam hal ini kegemukan juga memiliki andil seorang wanita untuk sulit mendapatkan kehamilan, meski dia juga tidak menyarakan untuk mengubah diet rendah lemak mereka. Masalah kegemukan ini juga didukung Dr. William Gibbons, yang memiliki klinik kesuburan di Baton Rouge, La., dan juga Presiden Society for Assisted Reproductive Technology, menyatakan berat badan yang terlalu kurus dan terlalu gemuk juga memiliki andil besar terhadap kesehatan reproduksi wanita. "Bukan berarti mengkonsumsi produk tinggi lemak itu melindungi kita, namun melakukan diet rendah lemak dan 'mengharamkan' produk kaya susu bukan sesuatu yang baik bagi kesehatan alat reproduksi kita," papar Dr. Zev Rosenwaks, direktur Weill Cornell University and New York Presbyterian yang melayani masalah kesuburan. Rosenwaks menekankan setiap wanita untuk menjalani diet sehat sesuai kemampuan dan porsi tubuh mereka. Jadi bagi mereka yang ingin hamil, tak ada salahnya mulai rajin konsumsi produk olahan susu, termasuk es krim [16]. Selama konsumsi es krim dalam batas normal yaitu 2 sampai 3 cangkir tiap minggu maka sebenarnya hal tersebut tidak perlu di khawatirkan. Bahkan es krim dapat menjadi teman bagi ibu hamil di awal-awal masa kehamilannya. Dimana es krim dianggap mampu menghilangkan rasa mual (morning sickness), bahkan dapat sebagai pengganti nasi yang tepat karena banyak mengandung lemak sebagai sumber energi yang tinggi [15]. Hubungan es krim dan kesuburan.

KESIMPULAN

  1. Pada saat hamil kegiatan yang dilakukan ibu jangan berlebihan, baik dalam hal mengangkat beban yang berat, duduk maupun berdiri berlebihan. Apabila aktifitas ini dilakukan dalam jangka waktu yang lama, maka ibu dapat mengalami ketegangan otot dan kemungkinan terburuk dapat mengakibatkan keguguran. Naudzubillah.
  2. Saat hamil bukan saat yang tepat untuk melakukan diet makanan karena ibu hamil memerlukan tambahan 300 kalori dari saat sebelum hamil. Usahakan untuk selalu makan (makanan ringan) setidaknya 3 jam sekali. Dan jangan lupa untuk mengkonsumsi air putih untuk keberlangsungan dua nyawa Asap rokok dapat mengakibatkan ibu hamil perokok pasif dan/atau janinnya: kehamilan di luar rahim, abortus (keguguran) spontan, plasenta menutupi mulut rahim (plasenta previa), plasenta lepas (abrupsia plasenta), ketuban pecah dini, infeksi kantong cairan ketuban (chorioamnionitis), kelahiran prematur, bayi lahir dengan berat badan rendah, janin meninggal dalam rahim.
  3. Kesegaran ikan sangat diutamakan agar janin tidak teracuni dengan makanan kadaluarsa. Hindari memilih ikan yang sudah berbumbu karena kita tidak dapat melihat kesegaran ikan.
  4. Untuk masalah makanan, sebaiknya ibu hamil tidak mengkonsumsi berlebihan pada makanan seperti: mie, coklat, kopi, teh, softdrink, es krim.
  • Hal ini disebabkan karena mie mengandung zat additive.
  • Kopi, teh dan softdrink bila dikonsumsi secara berlebih dengan kadar kekentalan tinggi, janin bisa terkena gangguan epilepsi. Selain itu kopi dapat mengakibatkan keguguran.
  • Begitu pula dengan mengkonsumsi es krim yang dianggap mampu menghilangkan rasa mual (morning sickness), bahkan dapat membantu wanita untuk mendapatkan momongan. Tetapi apabila dikonsumsi berlebih, ibu hamil dapat memiliki janin berukuran oversize atau bahkan membuat wanita obesitas yang nantinya juga akan menghalangi kehamilan.

DAFTAR PUSTAKA

  1. http://parentsindonesia.com/content/view/43/29/.
  2. http://muhammadpasha.multiply.com/journal/item/17/yang_gak_boleh_dilakukan_ibu_hamil.
  3. http://www.momsmiracle.com/content/view/104/85/
  4. http://www.dechacare.com/Manfaat-Air-Putih-Bagi-Ibu-Hamil-I486.html
  5. http://mdopost.com/news/index.php?option=com_content&task=view&id=16931&Itemid=9
  6. http://www.ayahbunda.co.id/Artikel/Gizi+dan+Kesehatan/repotnya.berkelit.dari.asap.rokok.saat.hamil/001/001/59/10/-/4
  7. http://ridwanamiruddin.wordpress.com/2007/05/05/status-gizi-ibu-hamil-rokok-dan-efeknya/
  8. http://sains.kompas.com/read/xml/2009/04/12/08304313/polusi.udara.ganggu.perkembangan.janin
  9. http://www.zonawanita.com/index.php/motherachild/pregnancy/35-polusi-udara-membahayakan-ibu-hamil
  10. http://tentang-kehamilan.blogspot.com/2008/12/kelamaan-duduk-atau-berdiri.html
  11. http://www.bayisehat.com/nutrition-for-moms-mainmenu-38/363-konsumsi-ikan-saat-hamil.html
  12. http://lifestyle.id.finroll.com/kesehatan/5-kesehatan/27005-balita-dan-wanita-hamil-jauhi-mie-instant.html
  13. http://muhammadpasha.multiply.com/journal/item/17/yang_gak_boleh_dilakukan_ibu_hamil
  14. http://www.ibujempol.com/gizi-ibu-hamil/
  15. http://www.mesineskrim.com/es-krim-dan-ibu-hamil.html
  16. http://www.kapanlagi.com/a/ingin-hamil-makan-es-krim-yuk.html

sebagai catatan: referensi yang aku ambil pada bulan januari'09 - agustus'09 Read More..

Tuesday, January 8, 2008

ISO 9126

Setelah beberapa tahun, beberapa daftar karakteristik Kualitas perangkat lunak ditampilkan, seperti James McCall dan Barry Boehm. Mengetahui kesulitan pada definisi kualitas perangkat lunak yang baik dengan cara, misalnya menjadikan kesenangan kepada kesalahan perangkat lunak yang dapat ditolerir dan diperbaiki. Untuk beberapa ‘ketahanan’(robustness) yang berarti toleransi kesalahan input pada perangkat lunak, dengan kemampuan untuk merubah kode program tanpa menampilkan kesalahan. Standard ISO 9126 pertama kali diperkenalkan pada tahun 1991 melalui pertanyaan tentang definisi Kualitas perangkat lunak. Dokumen halaman-13 yang asli didesain sebagai fondasi lebih jauh, lebih detail, dan memiliki standard yang dapat diolah. Dokumen standard ISO 9126 sangat panjang. Hal ini dikarenakan orang memiliki motivasi berbeda yang memungkinkan untuk tertarik pada kualitas perangkat lunak :
  • Acquirer adalah orang yang memperoleh perangkat lunak dari supplier eksternal.
  • Developer adalah orang yang membangun produk perangkat lunak.
  • Evaluator independent adalah orang yang menetapkan kualitas produk perangkat lunak – tidak untuk dirinya sendiri tetapi untuk komunitas user – misalnya melalui jenis tool tertentu dari sebuah perangkat lunak sebagai bagian dari aktifitas profesional.
ISO 9126 telah membagi dokumen menjadi tiga bagian kebutuhan. Disamping ukuran bagian dokumentasi, ISO 9126 tidak hanya mendefinisikan atribut kualitas perangkat lunak. Standard ISO 14598 memisahkan prosedur yang seharusnya dibawa saat menaksir derajat produk perangkat lunak untuk menyesuaikan diri pada karakteristik kualitas ISO 9126 yang dipilih. Hal ini mungkin saja tidak diperlukan, tetapi disetujuinya ISO 14598 dapat digunakan untuk menyelesaikan penilaian dalam membedakan bagian karakteristik kualitas pada ISO 9126 yang dibutuhkan.
Perbedaan antara atribut kualitas internal dan eksternal telah dicatat, ISO 9126 juga memperkenalkan tipe kualitas – quality in use – dimana mengikuti elemen yang telah diketahui :
  • Effectiveness merupakan kemampuan untuk mencapai tujuan user melalui akurasi dan kelengkapan.
  • Productivity merupakan upaya menghindari kelebihan penggunaan sumber daya, seperti biaya staff dalam mencapai tujuan user.
  • Safety merupakan upaya menghindari kejahatan level resiko untuk orang dan entitas lain seperti business, perangkat lunak, property dan lingkungan
  • Satisfaction merupakan kepuasan user dalam menggunakan perangkat lunak.
User pada konteks ini adalah orang yang tidak hanya bekerja secara nyata pada sistem perangkat lunak yang akan dibuat, tetapi juga orang yang akan merawat dan meningkatkan perangkat lunak. Ide kualitas dalam penggunaan underlines adalah Bagaimana mempersiapkan kualitas perangkat lunak sebagai atribut yang tidak hanya berlaku pada perangkat lunak tetapi juga pada konteks penggunaan. Mengambil skenario IOE sebagai contoh, misalnya variasi prosedur invoicing yang akan dipertimbangkan, tergantung pada tipe produk yang akan disajikan. Hal ini mungkin saja terdapat perbedaan input yang dibutuhkan pada situasi yang berbeda untuk perhitungan jumlah klien. Katakan invoices 95% yang digunakan dimiliki tipe produk A dan sisanya 5% ke produk B. Jika perangkat lunak ditulis secara khusus untuk aplikasi ini, maka di samping pengujian yang baik, beberapa kesalahan yang mungkin akan ditemukan, terdapat pada cara sistem operasional. Selagi dilaporkan dan diperbaiki, perangkat lunak mungkin saja dapat menjadi lebih ‘dewasa’ sehingga kesalahan perangkat lunak menjadi jarang. Hal ini terjadi jika ada kecepatan menukar antara produk B lebih mudah mengeluarkan faktur daripada peningkatan jumlah transaksi produk B. Oleh karena itu, perubahan penggunaan perangkat lunak harus melibatkan perubahan kebutuhan perangkat lunak, apa yang dapat diterima ke satu user mungkin tidak diterima oleh user lain.
ISO 9126 mengidentifikasi enam karakteristik kualitas perangkat lunak utama yaitu:
  • Functionality: kemampuan menutupi fungsi produk perangkat lunak yang menyediakan kepuasan kebutuhan user.
  • Reliability: kemampuan perangkat lunak untuk perawatan dengan level performansi.
  • Usability: kemampuan yang berhubungan dengan penggunaan perangkat lunak.
  • Efficiency: kemampuan yang berhubungan dengan sumber daya fisik yang digunakan ketika perangkat lunak dijalankan.
  • Maintainanility: kemampuan yang dibutuhkan untuk membuat perubahan perangkat lunak
  • Portability: kemampuan yang berhubungan dengan kemampuan perangkat lunak yang dikirim ke lingkungan berbeda.
ISO 9126 menyarankan sub-karakteristik untuk setiap karakteristik utama

‘Functionality compliance’ mengacu pada bagian perangkat lunak untuk mengaplikasikan standard atau kebutuhan legal. Umumnya hal ini digunakan untuk kebutuhan auditing. Sejak daftar asli 1999, sub-karakteristik yang disebut dengan ‘compliance’ telah ditambahkan pada ke-enam karakteristik ISO eksternal. Pada setiap kasus, hal ini mengacu pada standard spesifik manapun yang dapat menerapkan atribut kualitas tertentu.
‘Interoperability’ merupakan gambaran yang bagus pada usaha ISO 9126 untuk mengklarifikasi terminologi ‘interopability’ yang mengacu pada kemampuan perangkat lunak untuk berinteraksi dengan sistem lain. Kerangka ISO 9126 telah dipilih pada kata ini daripada ‘comparability’ karena nantinya akan mengakibatkan kebingungan dengan karakteristik yang dituju oleh ISO 9126 sebagai ‘replacability’

‘Maturity’ mengacu pada frekuensi kesalahan produk perangkat lunak yang memberikan dampak pada perangkat lunak yang digunakan sehingga kesalahan menjadi tidak nampak dan mudah dihilangkan. Hal ini menarik untuk ketahui bahwa ‘recoverability’ telah menjadi hal yang berbeda dari ‘security’ yang menggambarkan kontrol akses pada sistem.


Catatan bagaimana ‘learnability’ dibedakan dari ‘operability’. Tool perangkat lunak dapat dengan mudah dipelajari tetapi menghabiskan waktu untuk menggunakannya dikarenakan oleh cara penggunaannya membutuhkan jumlah menu besar. Hal ini dapat diaplikasikan untuk paket yang singkat, tetapi tidak ada sistem yang menggunakannya untuk sepanjang waktu setiap hari. Pada kasus ini ‘learnability’ telah disatukan pada biaya ‘operability’.
‘Attractiveness’ adalah tambahan terbaru pada sub-karakteristik usability dan sangat penting dimana user tidak dipaksa untuk menggunakan produk perangkat lunak tertentu, Misalnya, kasus game dan produk entertainment lain.

‘Analysability’ merupakan kemudahan untuk menentukan penyebab kesalahan. ‘Changebility’ merupakan kualitas lain dari ‘flexibility’ yang kemungkinan nantinya disebut sebagai ‘changebility’ yang memiliki arti tambahan yang sederhana dalam perbendaharan kata bahasa English – hal ini mungkin saja menandakan pemasok perangkat lunak yang selalu berubah.
Di sisi lain pengertian ‘Stability’, adalah tidak berarti perangkat lunak itu tidak pernah berubah. Hal ini berarti juga terdapat resiko yang kecil pada modifikasi perangkat lunak yang memiliki dampak tidak diduga.

‘Portability compliance’ berhubungan erat dengan standard kemampuan yang digunakan pada platform manapun (portability). Standard bahasa pemrograman umum pada kasus ini digunakan pada lingkungan hardware/software. ‘Replacebility’ mengarah ke faktor yang memberikan ‘upward compatibility’ antara komponen software lama dan yang baru. Sedangkan ‘downwards compatibility' tidak dijelaskan pada pengertian definisi.
‘Co-existence’ mengarah pada kemampuan software untuk berbagi sumber daya dengan komponen software lain, tetapi tidak seperti ‘interopability’, dimana tidak ada data yang digunakan.
ISO 9126 menyediakan petunjuk untuk menggunakan kualitas karakteristik. Variasi dalam membedakan karakteristik kualitas tergantung pada tipe produk yang ditekankan.
Terdapat 5 langkah yang dikembangkan untuk kebutuhan produk software yaitu :

  1. Menilai pentingnya masing-masing karakteristik kualitas aplikasi. Reliability akan berfokus pada sistem kerentanan keamanan (safety-critical) selama efisiensi itu merupakan keutamaan untuk sistem real time.
  2. Memilih pengukuran kualitas eksternal menggunakan kerangka ISO 9126 yang berhubungan dengan prioritas utama kualitas. Realiability berarti memiliki waktu antara kesalahan yang akan menjadi keutamaan pengukuran, Dimana efisiensi dan lebih utamanya pada ‘time behaviour’, -respon waktu yang digunakan untuk pengukuran.
  3. Pemetaan pengukuran pada tingkat kepuasan user. Untuk waktu respon, misalnya pemetaannya dapat dilihat pada Tabel 1.

Tabel 1. Pemetaan Pengukuran untuk Kepuasan User



4. Identifikasi yang berhubungan dengan pengukuran internal dan produk yang dihasilkan. Hal ini akan menjadi sesuatu yang penting saat software dikembangkan daripada mengevaluasi software yang dihasilkan. Untuk software baru, umumnya kualitas akhir produk akan membutuhkan penilaian selama pengembangan. Misalnya, pada kualitas eksternal dalam pertanyaan time behaviour, pada langkah desain software , perkiraan waktu eksekusi untuk sebuah proses dapat dihasilkan melalui pengujian kode software dan menghitung waktu untuk setiap perintah pada eksekusi proses secara umum. Menurut buku ini pemetaan antara karakteristik kualitas internal dan eksternal serta pengukuran disarankan sesuai standard ISO 9126 yang setidaknya meyakinkan elemen sebuah pendekatan.. Technical report merupakan bagian dari keseluruhan standart. Standart ISO 9126, digunakan untuk pemetaan pengukuran internal dan eksternal serta validasi pengukuran yang memiliki hubungan erat diantara dua kondisi yang semestinya dilakukan. Hal ini mencerminkan masalah sebenarnya pada pengembangan software terutama pengujian struktur kode dan prediksi kualitas eksternal secara akurat seperti reliability.
Menurut ISO 9126, pengukuran dapat bertindak sebagai indikator akhir kualitas software yang dilakukan pada pengembangan life cycle yang berbeda. Untuk langkah awal dalam penentuan kualitas produk dapat bersifat kualitatif. Penentuan tersebut berdasarkan ceklist , dimana pemenuhan kriteria definisi awal dibantu oleh penilaian ekspert (expert judgement). Sebagai produk yang berhubungan dengan penyelesaian, sasaran, kuantitatif, maka peningkatan pengukuran akan dilakukan kemudian.


5. Penilaian keseluruhan kualitas produk. Apakah penilaian tersebut memungkinkan untuk memperoleh nilai yang menghasilkan keputusan kualitas produk software? Hal ini merupakan perdebatan utama. Dapat dilihat bahwa kualitas yang didiskusikan dapat berbeda antara satu dengan yang lainnya. Pada beberapa kasus penilaian, dapat dihadirkan hasil kualitas produk. Misalnya karakteristik efisiensi time behaviour dan pemanfaatan sumber daya dapat ditingkatkan dengan cara memaksimalkan karakteristik sistem operasi dan hardware untuk menghasilkan software. Bagaimanapun juga penilaian dapat mempengaruhi biaya portability. Faktor ketakutan lain adalah menggabungkan penilaian karakteristik jaminan yang berbeda , pada prakteknya, bisa sangat berbeda dan dapat diukur dengan cara yang berbeda, dimana membuat perbandingan dan penggabungan yang bisa sangat bermasalah.


Pengukuran telah dicatat pada penilaian kualitas yang dapat dilaksanakan untuk beberapa alasan yang berbeda : untuk menilai pengembangan software, acquisition atau penilaian independent.
Selama pengembangan produk software, penilaian diarahkan kepada kebutuhan yang utama dari keinginan developer terhadap kualitas. Tujuannya digunakan untuk identifikasi kemungkinan kelemahan sejak awal dan kebutuhan pada kasus yang menghasilkan pembobotan kualitas secara keseluruhan
Pada situasi ini dimana user yang berpotensi adalah menilai sejumlah perbedaan produk software untuk memilih yang terbaik sesuai keinginan mereka, hasilnya akan mengarah ke produk A yang lebih memuaskan daripada produk B atau C. Di sini terdapat beberapa ide mengenai hasil kepuasan relatif dan pertimbangan dalam berusaha untuk membuat suatu model kepuasan user. Satu pendekatan mengenali beberapa level kualitas menjadi sebuah kewajiban. Jika sebuah produk gagal meraih kewajiban level rating maka produk tersebut harus ditolak, tanpa melihat seberapa bagus kemungkinan di masa yang akan datang. Karakteristik kepuasan user mungkin saja diinginkan tetapi tidak dibutuhkan. Untuk rating kepuasan user dapat dibagi menjadi beberapa range, misalnya 0-5. Rating kepuasan user berdasarkan pada pengukuran yang obyektif untuk beberapa fungsi dan berhubungan dengan perbedaan nilai pengukuran ke level kepuasan user yang berbeda– lihat tabel 2.

Tabel 2. Pemetaan Respon Waktu terhadap Kepuasan User
Sebagai tambahan pada rating kepuasan, rating pada range 1-5 dapat digunakan sebagai patokan untuk kepentingan setiap karakteristik kualitas, dll. Skor yang menggambarkan tentang kurang lebihnya kualitas dapat dilakukan dengan cara mengkalikan setiap rating dengan pembobotan yang diperoleh melalui perkalian antara (importance rating) keutamaan rating dan nilai kualitas (quality score). Skor pembobotan ini dapat dijumlahkan untuk mendapatkan skor keseluruhan produk. Skor untuk produk yang berbeda dapat dipesan untuk mendapatkan pilihan skala awal. Misalnya kualitas dua produk kemungkinan dibandingkan dalam hal usability, efisiensi dan maintainaibility. Keutamaan setiap kualitas kemungkinan masing-masing bernilai 3, 4 dan 2, dengan nilai maksimum 5. Pengujian kualitas dapat menghasilkan situasi seperti pada tabel 3.
Situasi akhir , dimana penilaian kualitas dapat bertindak sebagai tim penilai yang bekerja atas nama komunitas user secara keseluruhan. Misalnya praktisi mungkin dapat menilai tool software yang mensupport kinerja anggotanya. Tidak seperti pemilihan oleh individual user / purchaser, percobaan dibuat untuk menghasilkan penilaian software yang obyektif, pada lingkungan user secara independent. Hal ini jelas bahwa hasil pengukuran akan memiliki banyak pertimbangan tergantung pada pembobotan yang diberikan pada setiap karakteristik software, dan perbedaan user akan memiliki kebutuhan nilai yang berbeda.
Read More..

Menempatkan Kualitas Perangkat Lunak pada Perencanaan Proyek

Kualitas akan berfokus pada semua langkah perencanaan dan pelaksanaan proyek, dapat dilihat pada gambar 1

Gambar 1. Penempatan Kualitas Perangkat Lunak

  • Langkah 1: identifikasi ruang lingkup dan sasaran proyek. Beberapa sasaran berhubungan dengan kualitas aplikasi yang akan dikerjakan.
  • Langkah 2: identifikasi infrastruktur proyek. Dengan langkah ini maka memerlukan identifikasi standard instalasi dan prosedur. Beberapa diantaranya akan berbicara tentang kualitas
  • Langkah 3: analisis karakteristik proyek. Pada analisis karakteristik proyek berdasarkan kualitas, aplikasi akan diimplementasikan untuk melihat kebutuhan khusus kualitas. Misalnya pada keamanan kritis (keamanan data) yang ekstrim dari keseluruhan tambahan batas aktifitas yang bisa digunakan sebagai pengembangan versi ke n dimana tim pengembang pada software versi sebelumnya akan sama berjalan secara paralel dengan output yang akan di cross cek untuk bahan perdebatan.
  • Langkah 4: identifikasi produk dan aktifitas proyek. Poin ini sangat penting dimana masukan, keluaran dan kebutuhan proses di identifikasi untuk setiap proyek. Kebutuhan alami digambarkan lebih jelas pada bab ini.
  • Langkah 5: tinjau ulang dan publikasi perencanaan. Pada langkah ini keseluruhan aspek kualitas perencanaan proyek akan di tinjau ulang.

Keutamaan Kualitas perangkat lunak

Kita berharap kualitas menjadi fokus pada semua prosedur barang dan jasa. Bagaimanapun juga, karakteristik khusus perangkat lunak menjadi hal yang tak mudah dimengerti (intangibility) dan kompleksitas, membuat permintaan khusus

  • Meningkatkan perangkat lunak secara kritis. End user umumnya tertarik tentang kualitas umum perangkat lunak, terutama yang dapat diandalkan. Hal ini akan menyebabkan peningkatkan ketergantungan suatu organisasi pada sistem komputer dan perangkat lunak sehingga lebih berguna untuk area keamanan kritis (pengamanan data), misalnya pengontrolan pesawat terbang (aircraft)
  • Hal yang tidak dimengerti (intangibility) oleh perangkat lunak membuat kesulitan untuk mengetahui pekerjaan tertentu dalam memuaskan customer di proyek. Hasil pekerjaan ini menjadi sesuatu yang dapat dimengerti (tangible) dengan menuntut developer menghasilkan ‘deliverables’ yang dapat diuji untuk kualitas
  • Penjumlahan kesalahan selama pengembangan perangkat lunak. Sebagai pengembangan sistem komputer , jumlah langkah output dibuat dari satu langkah input ke langkah selanjutnya, kesalahan pada deliverables awal akan ditambahkan pada langkah berikutnya, yang mengarahkan ke penjumlahan efek merugikan. Umumnya pada proyek berikutnya dimana kesalahan ditemukan menjadi lebih mahal untuk diperbaiki. Sebagai tambahan, karena jumlah kesalahan sistem tidak diketahui, fase debugging proyek menjadi sulit sekali untuk dikontrol.Untuk alasan inilah manajemen kualitas merupakan bagian utama keseluruhan manajemen proyek.

Mendefinisikan Kualitas Perangkat Lunak

Kualitas merupakan kata yang meragukan dan dibutuhkan untuk definisi yang secara hati-hati untuk dimaknai. Untuk sistem perangkat lunak apapun, seharusnya ada tiga spesifikasi yaitu ;

  • Spesifikasi fungsional
    Spesifikasi ini menggambarkan apa yang dikerjakan sistem – hal ini merupakan fokus utama metodologi seperti Unified Software Development Process
  • Spesifikasi kualitas (atau atribut)
    Spesifikasi ini memfokuskan pada , bagaimana fungsi beroperasi.
  • Spesifikasi sumber daya
    Spesifikasi ini berfokus pada seberapa banyak yang harus dihabiskan oleh sistem

Beberapa kualitas dapat diidentifikasi untuk menghasilkan perangkat lunak yang mencerminkan pandangan eksternal perangkat lunak yang akan diliki user, sebagaimana pada kasus usability. Kualitas eksternal akan dipetakan ke faktor internal dimana developer akan bersikap waspada. Hal ini bisa diperdebatkan, misalnya kode yang tersusun dengan baik (well-constructed code) umumnya memiliki kesalahan lebih sedikit dan peningkatan kemampuan untuk digunakan.
Mendefinisikan kualitas tidak cukup hanya dengan jika kita melakukan keputusan yang sesuai dengan kebutuhan sistem sehingga kita perlu melakukan pengukuran kualitas. Untuk setiap karakteristik kualitas, satu atau lebih pengukuran yang ditemukan akan menghasilkan nilai derajat kualitas.
Pengukuran yang baik harus dapat menghubungkan jumlah unit sampai keadaan yang maksimal. Jumlah maksimum kesalahan pada program, misalnya kesalahan yang berhubungan dengan ukuran program sehingga pengukuran kesalahan per seribu baris kode (fault per thousand line of code) akan lebih membantu daripada jumlah kesalahan (total fault) pada program sebagai jaminan kualitas program.
Mencoba untuk menemukan pengukuran untuk kualitas tertentu membantu mengklarifikasi apakah kualitas itu. Yang dipertanyakan adalah, dampak terhadap ‘Bagaimana kita mengetahui kapan hal ini akan berhasil?’ menjawab tentang sasaran kualitas akan dijelaskan lebih lanjut.
Kemungkinan pengukuran kualitas dapat dilakukan secara langsung atau indirect dimana sesuatu yang diukur bukan kualitasnya sendiri tetapi indikator kualitas yang dihadirkan. Misalnya jumlah permintaan oleh user diterima dengan bantuan pengoperasian aplikasi perangkat lunak tertentu dapat menjadi pengukuran usability secara indirect. Dengan identifikasi manajemen pengukuran pengaturan program bagi tim anggota proyek sangat penting untuk meningkatkan kualitas pengukuran itu sendiri. Misalnya jumlah kesalahan yang ditemukan di baris program tidak bisa dihitung, pada dasarnya hal itu memerlukan proses pemeriksaan yang lebih teliti, sehingga kesalahan lebih mudah ditemukan. Meningkatkan pengukuran ini bisa saja dilakukan, tentu saja, dengan mengetahui kesalahan yang ada melalui langkah pemeriksaan daripada menghilangkan kesalahan dari awal – dimana hal ini bukan faktor utama.
Kebutuhan utama untuk spesifikasi karakteristik kualitas adalah

  • Definisi / deskripsi: definisi karakteristik Kualitas.
  • Skala: unit pengukuran.
  • Uji: uji praktis yang dilakukan dimana dihasilkan atribut Kualitas
  • Penerimaan secara sederhana : nilai terburuk yang mungkin saja diterima jika karakteristik lain dibandingkan dengan kualitas, dan saat produk belum diterima.
  • Batas target: batas nilai dimana perencanaan pengukuran nilai Kualitas seharusnya diperbaiki.
  • Sekarang: hasil yang diharapkan sekarang

Oleh karena itu ada pengukuran yang dapat diaplikasikan lebih dari satu ke karakteristik kualitas. Saat melakukan daftar (drafting) spesifikasi kualitas karakteristik kualitas mungkin saja akan terbagi dalam beberapa sub-karakteristik. Misalnya sub-karakteristik dari ‘usability’ mungkin saja dapat dijelaskan (communicativeness). Satu aspek yang mungkin saja menjadi pemahaman struktur menu, adalah begitu mudahnya menemukan perintah untuk menyelesaikan beberapa fungsi. Aspek lain dari penjelasan tersebut adalah bagaimana mengatakan keberadaan pesan kesalahan yang muncul, melalui halaman “help”

Read More..

KUALITAS PERANGKAT LUNAK

Ketika kualitas pada umumnya disetujui menjadi ‘barang bagus’, apa yang dimaksud orang pada kata ‘kualitas’ pada sebuah sistem dapat menjadi hal yang meragukan. Oleh karena itu dibutuhkan definisi yang lebih tepat untuk kualitas pada sistem. Bagaimanapun juga, hal ini tidak cukup - kita membutuhkan keputusan secara obyektif dimana sistem menemui kebutuhan kualitas dan pengukuran. Hal ini akan menjadi fokus seseorang seperti Brigette pada Britghtmouth College pada proses pemilihan paket.

Untuk seseorang-seperti Amanda pada IOE-pengembang software, pengukuran kualitas tidak hanya berfokus pada hasil akhir, tetapi juga pada proses. Amanda mungkin ingin menilai kualitas sistem akhir selama dalam proses pengembangan, dan juga meyakinkan pengembangan metode yang digunakan untuk menghasilkan kualitas. Hal ini akan mengarah ke penekanan yang berbeda-daripada berfokus pada kualitas sistem akhir, customer yang berpotensi (customer yang memiliki keinginan untuk membeli software) mungkin akan mencoba untuk melakukan cek ke supplier dalam penggunaan metode terbaik.

Dapat dibaca pada kualitassoftware.pdf
Untuk contoh implementasi bisa dibaca pada 785.pdf
Read More..

Saturday, November 24, 2007

Manajemen Resiko

E-Government, yang di implementasikan dalam Sistem Informasi Manajemen Daerah (SIMDA), adalah salah satu upaya dalam rangka memenuhi kebutuhan informasi secara cepat, tepat, lengkap, akurat dan terpadu untuk menunjang proses administrasi pemerintahan, pelayanan masyarakat, dan memfasilitasi partisipasi dan dialog publik di dalam perumusan kebijakan [1].
Menyusun proposal SIMDA adalah bagian pekerjaan yang penting dan juga kritis bagi pemerintah. Dalam jangka waktu yang relatif singkat, mereka harus me-review banyak hal dan mengambil berbagai keputusan beresiko untuk menentukan besarnya pengeluaran yang dibutuhkan [2]. Untuk itu dibutuhkan suatu manajemen dalam melakukan analisa resiko yang biasa dikenal sebagai manajemen resiko.
Manajemen resiko adalah suatu proses mengidentifikasi, mengukur risiko, serta membentuk strategi untuk mengelolanya melalui sumber daya yang tersedia. Strategi yang dapat digunakan antara lain mentransfer risiko pada pihak lain, menghindari risiko, mengurangi efek buruk dari risiko dan menerima sebagian maupun seluruh konsekuensi dari risiko tertentu [3].

I. Identifikasi Risiko
Proses ini meliputi identifikasi risiko yang mungkin terjadi dalam suatu aktivitas usaha. Identifikasi risiko secara akurat dan komplet sangatlah vital dalam manajemen risiko. Salah satu aspek penting dalam identifikasi risiko adalah mendaftar risiko yang mungkin terjadi sebanyak mungkin.

II. Daftar Resiko
2.1 Resiko estimasi
a. Kesalahan perkiraan LOC
Resiko ini terjadi jika perkiraan LOC pada kenyataan yang ada jauh melebihi LOC perkiraan pada perhitungan COCOMO, yang mengakibatkan berubahnya jadwal pengerjaan dan biaya operasional.

Solusi :
-Melakukan re-scheduling dan melaporkannya kepada badan pengawas pemerintah, dan melakukan penyesuaian jadwal dan biaya.
-Merekrut staff tambahan untuk membantu penyelesaian SIMDA agar sesuai jadwal.

b. Kesalahan perancangan skala database
Resiko ini terjadi karena skala database yang telah dirancang ternyata tidak sesuai pada proses pengembangan software tersebut. Yang dapat berakibat berubahnya waktu penyelesaian pekerjaan.
Solusi :
-Memberitahu seluruh staff yang bersangkutan untuk melakukan meeting sehubungan dengan perancangan ulang skala database.
-Memberitahu teamwork apabila terjadi perubahan waktu penyelesaian pekerjaan.
-Merekrut staff tambahan untuk membantu penyelesaian pekerjaan agar sesuai jadwal.

2.2 Resiko pengaruh organisasi
a. Dokumentasi untuk pemerintah dianggap kurang baik oleh masyarakat
Resiko ini terjadi apabila dokumentasi yang diberikan kepada masyarakat tidak seperti yang diharapkan. Sehingga masyarakat tidak puas dan kemungkinan adanya ketidakpercayaan masyarakat.
Solusi :
-Untuk pencegahannya sejak awal kita harus sudah melakukan riset bagaimana membuat dokumentasi yang baik, dan juga kita perlu untuk menanyakan kepada dinas-dinas yang terkait mengenai dokumentasi seperti apa yang diharapkan oleh masyarakat.
-Jika resiko tersebut sudah terjadi, kita dapat meminta kepada masyarakat untuk memberikan respon maupun review atas dokumentasi tersebut, dan berusaha memperbaikinya.

2.3 Resiko yang berhubungan dengan masyarakat
a. Masyarakat belum/tidak bisa memastikan apa yang dibutuhkannya.
Resiko ini dikarenakan oleh masyarakat yang tidak tahu pasti apa yang dibutuhkannya, mungkin akibat masyarakat belum mempersiapkan diri terhadap perkembangan teknologi yang terbaru.
Solusi :
-Menggali informasi tentang keadaan masyarakat, apa yang dibutuhkan. Sehingga kita bisa membantu memberikan saran tentang apa yang mereka butuhkan.
-Meminta kepada masyarakat untuk mempersiapkan kebutuhannya terlebih dahulu, atau meminta kepada dinas-dinas yang terkait untuk meminta kritik, saran dan masukan terhadap sistem yang akan dibangun.

b. Dinas-dinas kurang berkomunikasi dengan developer untuk saling memberi informasi.
Dinas-dinas kurang berkomunikasi dengan developer untuk memberitahu apa yang masyarakat butuhkan dan apakah progress yang telah dilakukan telah sesuai dengan keinginan masyarakat.
Solusi :
-Mengadakan jejak pendapat melalui beberapa wakil rakyat
-Membuat report dan simulasi yang sesingkat dan sedetil mungkin supaya masyarakat dapat melakukan koreksi.

c. Masyarakat tidak mengerti proses pengembangan software.
Akibat masyarakat tidak mengerti proses pengembangan software, maka persepsi masyarakat tentang jadwal produksi, besar project, sulit tidaknya suatu project kemungkinan salah.
Solusi :
-Memberikan gambaran global tentang proses pengembangan software, dan memberikan keterangan sesederhana dan sedetil mungkin.

2.4 Resiko proses
a. Tidak semua staff bersedia untuk mengikuti proses yang telah ditentukan.
Resiko kemungkinan staff tidak mampu untuk mengikuti prosedur yang telah ditentukan, baik karena alasan skill, waktu, dan lain-lain.
Solusi :
-Menyusun ulang pembagian tugas dari masing-masing staff.
-Mengganti staff tersebut dengan yang lebih mampu

b. Kesulitan pengaturan jadwal untuk melakukan review teknis.
Para staff memiliki jadwal yang berbeda-beda sehingga mereka tidak dapat melakukan koordinasi dengan baik.
Solusi :
-Project Manager harus mengatur jadwal yang tepat untuk masing-masing staff.
-Masing-masing staf sejak awal harus berkomitmen untuk meluangkan waktunya.

c. Metode testing yang ada kurang sesuai.
Metode Pengetesan yang dilakukan ternyata tidak dapat diterapkan pada software tersebut.
Solusi :
-Mencari metode testing yang lebih baik, dengan cara merapatkannya dengan staff, mencari metode testing yang lebih efektif.

2.5 Resiko teknologi
a. Tidak semua staff menguasai/telah mengenal tools yang akan digunakan.
Para staff memiliki kemampuan yang berbeda-beda sehingga tools yang mereka kuasai juga tidak sama.
Solusi :
-Memilih staff yang telah mengenal tools tersebut.
-Mengadakan training singkat untuk staff yang belum menguasainya.

b. Project membutuhkan inovasi oleh developer.
Solusi :
-Mengumpulkan bahan-bahan yang diperlukan dan melakukan riset untuk persiapan project tersebut.

2.6 Resiko peralatan pengembangan
a. Software project/proses manajemen tidak tersedia.
Solusi :
-Mencari software tersebut terlebih dahulu.
-Tidak tersedianya software development untuk yang dibutuhkan.
-Mencari alternatif software yang dapat menggantikannya.

b. Tidak tersedianya referensi yang cukup untuk peralatan yang digunakan.
Solusi :
-Mencari referensi dari buku, internet, majalah, dan sebagainya.

c. Staf belum terlatih untuk menggunakan tools yang ada.
Solusi :
-Mengadakan training singkat mengenai tools tersebut.
-Memberikan buku panduan yang harus dipelajari sendiri oleh staff tersebut.

2.7 Resiko yang berhubungan dengan jumlah staf dan pengalaman.
a. Tidak tersedianya kombinasi staff dengan kemampuan yang tepat.
Solusi :
-Menyusun ulang pembagian tugas antar staf.
-Merekrut staf baru yang memiliki kemampuan seperti yang dibutuhkan.

b. Jumlah staff tidak memadai.
Solusi :
-Merekrut staf baru.
-Mengefektifkan kerja para staf.
-Menambah jumlah jam kerja setiap staf.

c. Staf mengundurkan diri.
Solusi :
-Merekrut staff baru.
-Mengefektifkan kerja para staf.
-Menambah jumlah jam kerja setiap staf.

2.8 Resiko komponen dan pengendali.
a. Performa sistem tidak seperti yang diharapkan.
Solusi :
-Melakukan kompilasi ulang dengan mengoptimalkan dan memperbaiki software.

b. Harga hardware dan software di luar perkiraan.
Solusi :
-Melakukan pencegahan dengan menyediakan dana cadangan dalam estimasi.

c. Software tidak bisa dikoreksi/diubah.
Solusi :
-Melakukan kompilasi software dari awal dengan terlebih dahulu memperbaikinya.

d. Project di luar jadwal yang ditentukan.
Solusi :
-Melakukan pencegahan dengan menambahkan waktu pada estimasi.

III. Analisa Risiko
Setelah melakukan identifikasi risiko, maka tahap berikutnya adalah pengukuran risiko dengan cara melihat potensial terjadinya seberapa besar severity (kerusakan) dan probabilitas terjadinya risiko tersebut. Penentuan probabilitas terjadinya suatu event sangatlah subyektif dan lebih berdasarkan nalar dan pengalaman. Beberapa risiko memang mudah untuk diukur, namun sangatlah sulit untuk memastikan probabilitas suatu kejadian yang sangat jarang terjadi. Sehingga, pada tahap ini sangatlah penting untuk menentukan dugaan yang terbaik supaya nantinya kita dapat memprioritaskan dengan baik dalam implementasi perencanaan manajemen risiko.
Kesulitan dalam pengukuran risiko adalah menentukan kemungkinan terjadi suatu risiko karena informasi statistik tidak selalu tersedia untuk beberapa risiko tertentu. Selain itu, mengevaluasi dampak severity (kerusakan) seringkali cukup sulit untuk asset immateriil.

Tujuan dari Analisis Risiko
Tujuan utama tentang melakukan Analisis Risiko adalah untuk mengukur dampak dari ancaman-ancaman yang berpotensi untuk berdampak terhadap sistem, serta untuk menafsir kebutuhan atau nilai terhadap kemampuan organisasi yang hilang akibat ancaman-ancaman tersebut.
Kedua hasil utama dari suatu analisis resiko adalah identifikasi dari resiko-resiko dan pertimbangan kerugian / keuntungan dari pengantisipasian ancaman-ancaman tersebut - merupakan hal yang sangat penting pada saat pembuatan suatu strategi peringanan resiko.
Selain itu, juga mempengaruhi proses pengambilan keputusan yang bersangkutan dengan konfigurasi perangkat keras dan desain sistem perangkat lunak. Dan juga dapat mempengaruhi keputusan-keputusan konstruksi dan perencanaan.

Bahaya yg Beresiko Tinggi
Didasarkan pada dua penilaian ancaman yaitu:
- Probabilitas atau kemungkinan terjadinya peristiwa dan
- Dampak, kerugian atau kerusakan yang ditimbulkan
Hasil penelitian kemudian di plot ke dalam matriks pemilihan resiko

Probabilitas Kejadian
Skala Probabilitas:
5 Sangat Pasti (hampir dipastikan 100% terjadi tahun depan, atau terjadi setiap tahun).
4 Hampir Pasti (75 –100% terjadi tahun depan, atau sekali dalam 5 tahun mendatang)
3 Mungkin (50 -75 % terjadi tahun depan, atau sekali dalam 10 tahun)
2 Kemungkinan Kecil (20-50 % terjadi tahun depan atau sekali dalam 25 tahun)
1 Tidak Pasti (1 –20 % terjadi tahun depan atau sekali dalam lebih dari 50 tahun)

Dampak Kejadian
Dampak Kerugian yang ditimbulkan:

5 Sangat Parah (hampir dipastikan SIMDA tidak dapat dilaksanakan 100%)
4 Parah (SIMDA dapat terlaksana 50-75%)
3 Cukup Parah (SIMDA dapat terlaksana 10-50 %)
2 Ringan (SIMDA dapat terlaksana kurang 10%)
1 Tidak Parah (dampak terkecil)

Penilaian Bahaya


P= Probabilitas (skala 1-5)
D= Dampak (skala 1-5)
MATRIKS RESIKO



Dari gambar matriks resiko, bisa dibuat prioritas dari kemungkinan resiko yang telah dibuat dimana:
  1. Prioritas utama, yaitu resiko estimasi
  2. Prioritas menengah, yaitu resiko yang berhubungan dengan masyarakat (eksternal) dan resiko peralatan pengembangan
  3. Prioritas kecil , yaitu resiko pengaruh organisasi (internal), resiko proses, resiko teknologi, resiko yang berhubungan dengan jumlah staf dan pengalaman dan resiko komponen dan pengendali.

Bisa dibaca pada artikel manajemenresikonia_811.pdf
Sumber:
waspada-pmk.pdf
proses_manajemen_risiko.pdf
perancangan_software_sistem_informasi_akademik_ftui.pdf
manajemen-bencana-materi-2-penentuan-resiko.pdf
introduction.pdf
121p-01-final10-security_management_practice.pdf
project_mgtproposal_tender.pdf

Read More..

Saturday, October 20, 2007

Sistem Informasi Daerah

Tulisan ini bisa didapatkan pada estimasnia-811.pdf
Perhitungan COCOMO bisa digunakan untuk mengetahui jenis proyek, menghitung Person Month (perbandingan antara waktu dan tenaga yang dibutuhkan), Durasi (waktu yang dibutuhkan untuk menyelesaikan proyek), tim size (tenaga yang dibutuhkan). Metode Function Point pertama kali diusulkan oleh Albrecht dan Gaffney. Pada metode ini, ukuran proyek dapat dihitung oleh tiga komponen yaitu ukuran proses informasi (Unadjusted Function Points-UFP), faktor penyesuaian kompleksitas dan Function Points. Komponen tersebut dianalisa sebagai berikut:

Unadjusted Function Points - UFP
Fitur ini disebut juga sebagai ukuran proses informasi. Ukuran ditentukan oleh identifikasi komponen eksternal sistem atau logical input, output, pemeriksaan (inquiry), external interface ke sistem lain dan logical internal file. Komponen ini memiliki kategori "mudah", "menengah" atau "komplek" tergantung pada karakteristik yang dimiliki. Lalu jumlah dari semua komponen disebut Unadjusted Function Points (UFP). Kategori yang dimiliki digambarkan pada tabel 1 dibawah [Symons,88]. Dengan catatan jumlah keseluruhan didapatkan dengan mengalikan kategori yang dipilih (mudah, menengah atau komplek).


Sesuai dengan kategori yang dimiliki SIMDA, maka perhitungan UFP adalah:
  • Eksternal input mudah 3 x3 = 9
  • Eksternal output mudah 4 x4 = 16
  • User menengah 4 x4 = 16
  • File komplek 15 x15 = 225
  • Eksternal interface menengah 7 x7 = 49
sehingga bisa didapatkan UFP = 9+16+16+225+49
UFP = 315

Perhitungan Kompleksitas Teknis
Perhitungan ini dihasilkan dari perhitungan technical complexity factor (TCF). TCF dihitung dengan melakukan penilaian 14 pertanyaan yang ditunjukkan pada table 2 [Pressman,87] dari 0 sampai 5 dimana



Sesuai dengan kategori yang dimiliki SIMDA, maka perhitungan TCF adalah:
  1. Backup dan recovery dapat dipercaya 5
  2. Komunikasi data 4
  3. Fungsi distribusi 4
  4. Performansi 4
  5. Lingkungan operasional 4
  6. Data entry on-line 5
  7. Layar interaktir untuk input 3
  8. Online update 4
  9. Kompleksitas interface 3
  10. Bisa digunakan kembali (reusability) 3
  11. Kompleksitas proses 3
  12. Kemudahan dalam install 3
  13. Memiliki banyak site 3
  14. Mudah digunakan 4
sehingga bisa didapatkan TCF = 5+4+4+4+4+5+3+4+3+3+3+3+3+4

TCF = 52

Perhitungan Function Point
Sesuai dengan SIMDA, maka perhitungan Function point dihitung dengan menggunakan rumus:



Sehingga didapatkan FP = 315 x (0.65 + 0.01 * 52)
FP = 368,55

Konversi FP-ke-NCSS
Setelah function point dihitung, sesuai dengan table 3 digunakan untuk konversi ke NCSS yang diusulkan oleh Albrecht dan Gaffney [83].



Karena SIMDA menggunakan bahasa C, maka didapatkan perhitungan konversi dimana konversi NCSS = FP * NCSS
konversi NCSS = 368,55 * 70
konversi NCSS = 25798,5

Menurut ide dasar COCOMO, proyek dibagi menjadi dua kategori yaitu poyek kecil dan proyek besar, dimana masing-masing proyek tersebut memiliki ciri-ciri sebagai berikut:

Proyek Kecil
  • Tim memiliki anggota sedikit (2-3 orang)
  • Mudah dimodelkan
  • Memiliki penyelesaian tidak terlalu rumit
  • Perhitungan EFFORT = a * SIZE + b

Proyek Besar

  • Semakin banyak tim yang dimiliki, semakin komplek proyek yang akan dikerjakan
  • Perhitungan EFFORT = a * SIZE b

Dimana a dan b adalah faktor penskalaan

Selain itu COCOMO memiliki kriteria tipe proyek, yaitu organik, semi detached dan embedded dimana masing-masing kriteria memiliki ciri-ciri sebagai berikut:

Organik

  • Merupakan proyek rutinitas
  • Proyek yang dikerjakan mudah dipelajari
  • Tim work bekerja scara efisien
  • Proyek yang dikerjakan memiliki sedikit hambatan
  • Umumnya sistem kecil

Semi-Detached

  • Pada pertengahan antara organic dan embedded
  • Memiliki sistem yang kompleks, tetapi proyek bukanlah sesuatu yang baru
  • Tim bisa terdiri dari tenaga yang berpengalaman dan belum berpengalaman

Embedded

  • Memiliki tingkat kesulitan lebih bila dibandingkan organik dan semi detached
  • Proyek yang dikerjakan cukup besar (software untuk kontrol nuklir, atau pesawat luar angkasa)
  • Tim sebagian besar terdiri dari tenaga yang berpengalaman
  • Proyek yang dikerjakan merupakan sesuatu yang baru
  • Biasanya memiliki hambatan yang cukup besar

Berdasarkan kriteria kategori proyek COCOMO, SIMDA merupakan proyek besar, sehingga memiliki Perhitungan EFFORT = a * SIZE b. Selain itu SIMDA merupakan tipe proyek Semi detached sehingga sesuai dengan table 4, SIMDA memiliki nilai a dan b masing-masing yaitu a = 3.0 dan b = 1.12.



Perhitungan Unadjusted function Point – UFP digunakan untuk mengetahui SIZE yang dimiliki SIMDA. Sehigga bisa diketahui SIZE yang dimiliki SIMDA adalah 315.Untuk mengetahui berapa banyak usaha (Effort) untuk menyelesaikan SIMDA, maka digunakan rumus



EAF adalah Effort Adjustment Factor sesuai dengan table 5




Berdasarkan table 5, EAF yang dimiliki SIMDA, memiliki detail:
  • Required software reliability high 1.15
  • Database size high 1.08
  • Main storage high 1.06
  • Programmer capability low 1.17
  • Programming language experience low 1.07
  • Use of software tools low 1.10
  • Required development schedule low 1.08

Sehingga bisa ditentukan Person Month (PM), yaitu:
PM = EAF * a * SIZE b
PM = (1.15 * 1.08 * 1.06 * 1.17 * 1.07 * 1.10 * 1.08) * 3.0 * (315) 1.12
PM = 1,958 * 3.0 * 628,214
PM = 3690,138
3690 PM yang dibutuhkan untuk menyelesaikan proyek SIMDA

Berdasarkan table 6, bisa ditentukan waktu yang dibutuhkan untuk menyelesaikan SIMDA



Duration = 2.5 * Effort 0.35
Duration = 2.5 * (3690) 0.35
Duration = 44,300
Waktu yang dibutuhkan sebanyak 44 bulan

Orang yang dibutuhkan untuk menyelesaikan proyek SIMDA
3690,138 / 44,300 = 83,298

Sehingga untuk menyelesaikan proyek SIMDA dibutuhkan 83 orang

Perhitungan COCOMO disini berdasarkan proposal Sistem Informasi Daerah (SIMDA), bisa didapatkan pada
simda_proposal.pdf
tgsproposalnia-811.ppt

Sumber perhitungan COCOMO bisa didapatkan pada
tutorial-oct25.pdf
Read More..

Sunday, September 30, 2007

Perbandingan Microsoft Word (Windows) dan OpenOffice (Linux)

Perbandingan Windows dan Linux (dua sistem operasi komputer) telah menjadi topik sebagai bahan diskusi diantara para pengguna. Windows merupakan sistem operasi yang banyak dikenal orang dan merupakan software legal (memiliki license), sedangkan Linux merupakan sistem operasi yang bisa didapatkan secara bebas (tanpa license). Dua sistem operasi ini bersaing untuk penggunaan personal computer market sebagai server market, dan digunakan pada kantor pemerintahan, sekolah, kantor, rumah, intranet dan internet servers [1].

Standard Linux Solution vs. Microsoft Solution [2]
Perbedaan antara Windows dan Linux dari keuntungan yang bisa didapat pada:
Hardware dan infrastruktur yang telah digunakan sampai saat iniPembelian hardware dan infrastruktur baru



Bila dilihat dari table, didapatkan kesimpulan bahwa Microsoft memiliki keuntungan lebih banyak daripada Linux Standard. Dimana Microsoft mendapatkan keuntungan sebesar 36% sedangkan Linux sebesar 26%
Perbedaan antara Windows dan Linux dari keuntungan yang bisa didapat pada perbendiangan harga produk.


Bisa disimpulkan bahwa apabila kita menginginkan produk OpenOffice dari Linux, maka kita bisa mendapatkannya secara gratis. Sedangkan bila kita menginginkan produk Microsoft Office Standard, maka kita perlu mengeluarkan biaya sebesar $399,00.

Daftar Hardware, Software dan Biaya Operasional
Pada daftar hardware antara Windows dan Linux (standard), tidak ada perbedaan biaya. Sedangkan untuk software, Windows membutuhkan biaya yang lebih besar bila dibandingkan dengan Linux (standard).
Pada biaya operasional, Linux (standard), beberapa bagian diperlukan biaya yang lebih tinggi bila dibandingkan dengan Windows. Diantaranya: Gaji staff, biaya konsultan.


Penggunaan Microsoft Word dan OpenOffice.org Writer memiliki perbedaan, diantaranya [3]:


Kesimpulan [4]:
Hampir sebagian software Linux bisa konsumen dapatkan secara bebas di internet. Hal ini dilakukan karena kemampuan daya beli konsumen masih kurang. Bisa dilihat bahwa bila konsumen menginginkan software Windows, maka konsumen diharuskan membayar software yang dibutuhkan tersebut. Tetapi di sisi lain, konsumen lebih familiar menggunakan Windows daripada Linux. Alasan inilah mengapa Windows masih dapat mempertahankan pangsa pasar yang dimiliki.
Sumber:
Read More..

Sunday, September 9, 2007

Software Proyek Manajemen Organizing

Aktifitas dalam software proyek manajemen meliputi beberapa proses, diantaranya organizing yang bertujuan agar perusahaan dapat mengatur suatu kegiatan yang berada pada sebuah kelompok
Project FileAmigo 7 merupakan salah satu software digunakan untuk organizing pada manajemen proyek, yang bisa di-download pada situs www.fileamigo.com/Home.htm
atau bisa dibaca User Guide menggunakan software FileAmigo 7
Dengan project FileAmigo 7 kita dapat memilih jenis file yang kita inginkan
Keuntungan yang bisa didapatkan menggunakan FileAmigo 7 adalah telah tersedianya beberapa template sesuai dengan kebutuhan pengguna. Selain itu pengguna dapat melakukan customize terhadap template yang dibutuhkan. FileAmigo 7 mirip dengan Microsoft Access, hanya saja dikemas sedimkian rupa sehingga pengguna yang belum familiar dengan Microsoft Access dapat menjalankan FileAmigo dengan mudah
hanya saja Software FileAmigo 7 tidak dijual bebas, dengan kata lain, pengguna hanya bisa mendapatkan software berupa trial selama 30 hari
Hasil report menggunakan FileAmigo 7 bisa di download pada
Read More..