Hello world!

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

Upgrade FC 6 ke FC 7

Hari ini gue upgrade server yang ada di gedung CYBER, upgrade saya lakukan dengan menggunakan yum, karena tools ini sangat mudah banget di gunakan baik untuk sekedar installasi maupun untuk proses upgrade. Linux yang saya upgrade sebelumnya menggunakan Linux FC 6 dan saya upgrade menjadi FC 7, karena mau upgrade langsung ke FC 8 takut banyak dependecy nya. Untuk menjalankan proses upgrade langkahnya adalah sebagai berikut :

• yum clean all
• rpm -Uvh
  • http://kambing.ui.edu/fedora/releases/7/Fedora/i386/os/ \  Fedora/fedora-release-7-3.noarch.rpm
  • http://kambing.ui.edu/fedora/releases/7/Fedora/i386/os/                           \

  Fedora/fedora-release-notes-7.0.0-1.noarch.rpm

• yum -y update

Gitu aja sih perintahnya sederhana kan…, selamat mencoba

Email Yang Terlambat, jadi nya gue keburu printer

Kemarin malem gue beli printer canon iP1880 karena printer gue yang lama untuk tinta warnanya nggak bisa di pakai, padahal aku udah beliin catride baru.
Karena gue butuh cepat, maka gue cari printer di ratu plaza walaupun harganya agak lebih tinggi bila di bandingkan dengan di mangga 2, tapi apa boleh buat la wong namanya aja butuh mendadak dan sangat terpaksa sekali.

Setelah gue pulang dari ratu plaza gue langsung coba printer untuk connect ke laptop dan langsung print foto gue, hasilnya nggak begitu mengecewakan.

Setelah instalasi driver printer dan uji coba selesai maka gue memutuskan untuk print Tesis, tapi sebelum nya gue sempatkan buka email dulu.

Nah disini aku sedikit kecewa, ada email dari dosen gue yang memberitahukan bahwa file gambar tidak boleh berwarna, jadi intinya tesisku nggak usah ada warna di bagian gambarnya. Lah setelah baca email ini, aku jadi berpikir “wah sedikit percuma donk aku tadi buru-buru beli print baru, padahal print ku yang lama kalo buat hitam putih aja masih sangat Ok”

Ya inilah… nasib, Email Yang Terlambat, jadi nya gue keburu printer

Tapi gpp, siapa tahu nanti ada faedahnya… dengan beli printer baru.

Ah… Bulan Depan Gaji Kan Naik…

Tidak terasa bulan januari sudah memasuki tanggal 16, yang berarti setengah bulan lagi gue nerima gaji dan tentunya gaji akan naik “berharap banget…”. Setelah beberapa hari ini gue mendengar berita bahwa kedelai naik dan para pembuat tempe kesulitan mendapat bahan baku nya di tambah dengan banyaknya pengusaha kecil khususnya di bidang produksi tempe yang banyak gulung tikar, gue mulai berpikir “gue tidak boleh berfoya foya lagi seperti dulu, yang seperti masih anak kecil, ingat…!!! umur gue udah 25 tahun”

Dengan menungkatnya harga kebutuhan hidup gue di jakarta tentunya hal ini akan dapat mengurangi angka tabungan gue yang harus gue setor tiap bulan, gue sekarang nggak boleh ngandalain gaji kantor dan berpedoman “Ah… Bulan Depan Gajik Kan Naik…”, untuk menjaga kestabilan keungan, gue harus pandai-pandai mengatur pemasukan dan pengeluaran.

Salah satu yang terpikir buat gue sekarang adalah bagimana car menginvestasikan uang yang saya miliki selain hanya di taruh di bank saja.

Ada ide..???, gimana kalo bisnis webhosting or voucher yang berbasis web ?

Control Panel Gratisan …?

Hari ini gue nyari beberapa control panel untuk mengelola hosting server, namun setelah beberapa cari di google nemunya cuma yang berifat komersial sedangakan yang free masih dikit banget, salah satunya ISPconfig. Hari ini gue rencananya mau install di mesin linux gue, Fedora 7.

Sekilas melihat manual nya sih gampang, tapi ada beberapa forum yang mengatakan bahwa installasi ISPconfig di fedora gampang-gampang susah, karena mereka setelah melakukan installasi ISPconfig ada beberapa problem yang muncul sehingga Linux Box mereka tidak bisa berjalan dengan baik.

Oke…, aku sekarang mau coba dulu, entar kalo nggak ada masalah aku buatin tutorial nya untuk installasi.

Mau rasakan browsing dengan adrenalin memuncak ?

Hari ini gue bener-bener mempunyai pengalaman baru untuk bisa merasakan browsing dengan adrenalin yang semakin meningkat, nyawa rasanya hampir copot. Hal ini gue alami ketika dari blok M, mau kekantor.

Berhubung nunggu kendaraan ke arah kantor terlalu lama gue akhirnya nekad juga untuk naik kendaraan yang sangat super cepat, siapa lagi kalo nggak si imut “bajaj”.

Gue terpaksa browsing sambil naik bajaj karena ada email penting yang harus gue baca, di sela sela nekan tombol enter, saat itu juga bajaj mengirim secara mendadak.

Wah pokonya seru deh…, tapi hati hati dengan hardisk laptop…, bisa bisa rusak kena guncangan bajaj he he he

Jakarta Mendung!

Hari ini gue bangun agak telat, dan hal ini tentunya berimbas pada jam masuk kasntorku yang telat juga. Suasana emang menduku sekali saat ini karena mendung dan dingin jadi enak banget emang buat tidur.

Ah udah…, gue mandi dulu aja deh dan langsung berangkat ke kantor

KENDALIKAN EMOSI ANDA

Emosi Anda adalah energi besar. Kekuatannya tak pernah bisa Anda bayangkan.
Kejadian di Virginia Tech adalah emosi. Orang berantem di televisi adalah
emosi. Bahagianya Tamara Blezinski ketemu Rasha adalah emosi. Emosi adalah
energi yang bisa positif dan bisa negatif. Anda, tentu saja ingin emosi Anda
selalu positif. Bagaimana me-manage-nya? Ada caranya.

Berikut ini adalah ringkasan dari buku “I Create Reality – Beyond
Visualization: How You Can Use Holographic Creation to Manifest Your
Desires!” karangan Christopher Westra yang dikenal dengan HoloCreation
Techniques-nya.

*1. Bertanggungjawablah atas Emosi Anda*

Mungkin, saat ini Anda belum terlalu mempercayainya. Namun demikian tetaplah
katakan ini pada diri Anda, saat Anda marah, sedih, kecewa, putus asa, atau
bahkan berbahagia:

*”Sayalah yang menciptakan realitas Saya, dan sekarang Saya sedang
menciptakan emosi ini.”*

Biasanya, Anda tidak pernah melakukan langkah pertama ini. Mengapa? Karena
Anda lebih percaya bahwa keadaan atau situasai di luar Andalah yang
menyebabkan emosi Anda.

*2. Beri Nama untuk Emosi Anda*

Memberi nama pada emosi akan memperjelas pemahaman Anda tentang emosi itu.
Ini juga akan meningkatkan kesadaran Anda tentang emosi itu. Tidak cukup,
jika Anda menyebut emosi itu hanya dengan “sedih”, “marah”, “jelek”, “bagus”
dan sebagainya.

*”Aku lagi biru”
“Gue emang lagi ngehek”
“Saya sedang hitam”
“Aku lagi kena emosi nomor dua belas”
“Saya sedang mengalami kram otak”
“Aku kayaknya lagi kena racun cinta” *

Semakin spesifik Anda menamainya, semakin jelas, lengkap, dan spesifik
inventory emosi Anda. Hafalkan untuk identifikasi di masa depan.

*3. Biarkan Berlalu Penyebabnya*

Lupakan, apapun yang di luar diri Anda yang Anda anggap menjadi penyebab
emosi Anda, tapi pertahankanlah emosinya. Ingat, Anda tetap harus
mengontrolnya. Apa yang Anda lakukan, adalah memisahkan “penyebab emosi”
dari emosi itu sendiri. Kini, emosi Anda menjadi lebih obyektif sifatnya.
Benda obyektif yang sudah punya nama.

*4. Hargai Emosi Anda*

Hargai emosi Anda. Sebab dengan itu, Anda ternyata masih manusia. Menghargai
emosi tidak berarti menghakiminya dengan “baik” atau “buruk”. Hargai
keberadaannya sebagai pelengkap kemanusiaan. Hargai keberadaannya dan bukan
sifat atau pengaruhnya. Ini adalah langkah penting dalam rangka menuju ke
poin berikut ini.

*5. Rasakan Emosi Anda*

Kini, Anda rasakan lagi emosi Anda dengan cara yang berbeda. Tanpa
penghakiman dan sikap bertahan, rasakan saja. Bila perlu, rasakan di mana
letaknya. Di kepala Anda, di dada Anda, di telinga Anda, di wajah Anda, di
mana saja di bagian tubuh Anda. Anda kini mengobservasi emosi Anda dengan
obyektif. Ingat, tanpa penghakiman dan sikap bertahan.

*6. Dapatkan Penjelasan*

Anda telah dilingkupi oleh semangat untuk belajar dan tumbuh. Mulailah
mencari alasan yang menciptakan emosi Anda. Waspadai yang satu ini: Jangan
kembali ke “penyebab eksternal” sebab Anda sedang ber-internalisasi.
Penyebab emosi Anda adalah Anda sendiri, bukan sesuatu yang di luar Anda.
Bertanyalah,

*”Apa yang perlu Saya pelajari dari emosi ini?”
“Keyakinan melenceng apa di dalam diri Saya, yang menciptakan emosi ini?”*

*7. Identifikasi*

Berilah waktu untuk jawabannya. Your answer will come. Di dasar setiap emosi
negatif, selalu ada keyakinan yang tidak tepat.

*Apakah Anda merasa “harus” membuat semua orang senang?
Apakah Anda merasa tidak akan bisa disukai jika “tidak sempurna”?
Apakah Anda bahwa semua orang “harus” mengikuti Anda?
Apakah Anda merasa diri Anda “tidak bernilai”?*

*8. Tukar Keyakinan Anda*

Pilihlah keyakinan yang lebih baik untuk menggantikan keyakinan negatif
Anda. Katakan dengan eksplisit,

*”Sekarang Saya memilih untuk menolak keyakinan ini, dan menggantinya dengan
keyakinan ini.”*

Pada empat langkah terakhir, Anda akan merasakan sesuatu yang luar biasa.
Emosi negatif Anda pergi, dan sepenuhnya digantikan dengan sesuatu yang
lain. Mengapa ini bisa terjadi? Kuncinya, ada pada kejelasan dan naiknya
kesadaran.

Pernah mendengar “control illusion”? Dengan mengikuti amarah, Anda merasa
mengendalikan sesuatu, padahal Anda yang sebenarnya berada di bawah kendali
emosi. Upaya Anda untuk mengendalikan emosi, tanpa Anda sadari adalah
sebentuk penolakan. Dan jika Anda melakukannya dengan memaksa diri, maka
Anda bisa menderita selama beberapa jam. Ketahuilah, itu menggerogoti Anda.

Dengan langkah yang tepat dalam membiarkan diri merasakan emosi, Anda akan
bisa merasakan emosi sesuai kegunaannya. Untuk belajar, untuk tumbuh, untuk
dewasa, untuk tidak menjadi destruktif, untuk menjadi lebih berbahagia.

Lakukanlah sesegera mungkin, dan dapatkan manfaat ajaibnya dalam dua minggu
ke depan.

Pemodelan Dalam Rekayasa Perangkat Lunak

Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang dilakukan di tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih memungkinkan tanpa melakukan suatu pemodelan. Hal itu tidak dapat lagi dilakukan dalam suatu industri perangkat lunak. Pemodelan delam perangkat lunak merupakan suatu yang harus dikerjakan di bagian awal dari rekayasa, dan pemodelan ini akan mempengaruhi perkerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut.

Proses

Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang berbeda untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan.Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas ini.

Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak. Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara. Pembuatan perangkat lunak untuk suata perubahan adalah penting. Proses perangkat lunak komplek dan melibatkan banyak aktivitas.

Seperti produk, proses juga memiliki atribut dan karakteristik seperti :

• Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti.
• Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas
• Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE
• Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak
• Reliability, apakah proses didesain sedikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk.
• Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga
• Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan
• Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi.

Model

Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Contohnya, jika pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. Ini akan memperlambat proses.Model proses perangkat lunak masih menjadi object penelitian, tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain:

• Pendekatan Waterfall

Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam proses yang terpisah, seperti spesifikasi kebutuhan, implementasi desain perangkat lunak, uji coba dst. Setelah setiap langkah didefinisikan, langkah tersebut di sign off dan pengembangan dilanjutkan pada langkah berikutnya.

• Pengembangan secara evolusioner

Pendekatan ini interleaves aktivitas spesifikasi, pengembangan dan validasi. Sistem awal dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang memenuhi kebutuhan kastamer. Kemudian sistem disampaikan. Sistem itu mungkin diimplementasikan kembali dengan pendekatan yang lebih terstruktur untuk menghasilkan sistem yang kuat dan maintable.

• Transformasi formal

Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu program. Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat yakin program yang dikembangkan sesuai dengan spesifikasi.

• Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan kembali.

Teknik ini menganggap bagian-bagian dari sistem sudah ada. Proses pengembangan sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap bagian. Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner, saat ini banyak digunakan dalam pengembangan sistem. Beberapa sistem sudah dibuat dengan menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian.Metode penggunaan kembali (reuse) umum di jepang. Metode ini sekiranya akan diakui oleh Eropa dan Amerika Utara. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars. Bagaimanapun juga reuse masih suatu penelitian, terlalu cepat untuk berkomentar tentang keefektifannya.

Waterfall

Model ini telah diperoleh dari proses engineering lainnya. Model ini menawarkan cara pembuatan perangkat lunak secara lebih nyata.Langkah-langkah yang penting dalam model ini adalah

• Penentuan dan analisis spesifikasi

Jasa, kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Kemudian semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.

• Desain sistem dan perangkat lunak

Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat dijalankan.

• Implementasi dan ujicoba unit

Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi.

• Integrasi dan ujicoba sistem

Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah ujicoba, sistem disampaikan ke kastamer

• Operasi dan pemeliharaan

Normalnya, ini adalah phase yang terpanjang. Sistem dipasang dan digunakan. Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan. Gambar 1. Pemodelan WaterfallDalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari aktivitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.

Sayangnya, model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan atau diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang nyata/jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan kastamer. Namun demikian model waterfall mencerminkan kepraktisan engineering. Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.

Pengembangan Evolusioner

Model ini berdasarkan pada ide pengembangan pada implementasi awal yang akan menghasilkan komentar pemakai sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang mencukupi dapat dikembangan. Selain memiliki aktivitas-aktivitas yang terpisah model ini memberikan feedback dengan cepat dan serentakTerdapat 2 tipe pada model ini

1. Pemprograman evolusioner

Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer. Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer.

2. Pemodelan

Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhan-kebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk sistem. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang kurang dimengerti. Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun, pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial intelligence) yang berusaha untuk menyamai kemampuan manusia.Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka.

Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer. Namun, dari segi teknik dan manajemen, model ini memiliki masalah mendasar yaitu:

• Proses tidak visibel.

Manager-manager membutuhkan “deliverables” yang teratur untuk mengukur kemajuan. Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem.

• Sistem-sistem biasanya kurang terstruktur

Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat lunak. Evolusi perangkat lunak terlihat sulit dan mahal.

• Ketrampilan khusus jarang dimiliki

Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang mungkin dapat digunakan secara efektif dalam model pengembangan ini. Kebanyakan sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil yang memiliki ketrampilan yang tinggi dan motivasi yang kuat. Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem. Contoh ini digunakan untuk mengerti dan mevalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas. ( seperti model waterfall ).Karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. Pengembangan evolusioner lebih tepat untuk

Pengembangan sistem yang relatif kecil.

Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika pemodelan digunakan, tidak terlalu mahal.

Pengembangan sistem yang memiliki masa hidup yang relatif singkat.

Disini, sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu. Contohnya, sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk baru.

Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan untuk menyatakan spesifikasi secara rinci. Contohnya, sistem AI dan interfaces pemakai.

Spiral Boehm

Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi, tidak mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua model umum seperti yang telah kita bicarakan sebelumnya. Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Pendekatan alternatif diusulkan oleh Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum.Model Boehm bebrbentuk spiral. Setiap loop mewakili sebuah tahap dari proses perangkat lunak.

Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan bagaimana membentuk proyek kedalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan selama pembuatan proyek.

Setiap loop dibagi dalam 4 sektor

1. Pembuatan tujuan

Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan. Rencan rinci manajemen juga ditulis lengkap. Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada.

2. Perkiraan dan pengurangan resiko

Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian diambil langkah-langkah untuk mengurangi resiko. contohnya, jika ada resiko bahwa persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat dikembangkan.

3. Pengembangan dan validasi

Setelah evaluasi resiko, sebuah model pengembangan untuk sistem dipilih. Misalnya, jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan model contoh (prototipe)

Jika resiko keselamatan yang diutamakan, model pengembangan yang sesuai adalah transformasi formal dan seterusnya. Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem.

4. Perencanaan

Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya. Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sisten perangkat lunak. Model spiral encompasses model lainnya. Pemodelan digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Kemudian dapat diikuti oleh model konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan bagian-bagian sistem yang memiliki persyaratan keselamatan yang tinggi dan pendekatan reuse digunakan untuk pengimplementasian bagian-bagian lain dari sistem data manajemen.Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.

Manajemen Resiko

Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada. Resiko adalah konsep yang sulit didefinisikan secara tepat. Secara informal resiko adalah sesuatu yang sederhana yang dapat menyebabkan kesalahan. Contohnya, jika bertujuan menggunakan pemprograman bahasa baru (new programming language), resiko yang mungkin adalah alat pengumpul yang digunakan tidak reliabel dan tidak menghasilkan code objek yang efesien.Resiko adalah sebagai hasil ketidakcukupan informasi. Resiko tersebut dapat dipecahkan dengan pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Dalam contoh diatas, resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Jika sistem ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah.

Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance, kegunaan, dan seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaik-baiknya kemudian diperhitungkan. Setiap alternatif diperhitungan bertentangan dengan tujuan. Ini biasanya menghasilkan identifikasi sumber resiko proyek. Langkah selanjutnya adalah mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail, pembuatan model/contoh, simulasi dan seterusnya. Untuk menggunakan model spiral, Boehm menyarankan sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Bentuk ini mungkin dilengkapi pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk.

Daftar Pustaka

1. Roger S. Pressman, “Software Engineering, a Practitioner’s Approach” Fourth Edition, McGraw Hill, 1997.
2. Barbee Teasley Mynatt, “Software Engineering with Student Project Guidance”, Prentice Hall Int. 1990.
3. Roger S. Pressman, “Software Engineering, A Beginner’s Guide”, McGraw Hill, 1998.

Oleh :
Arief Hamdani : hamdani@risti.telkom.co.id
Fera fbj15@bdg.centrin.net.id

Mapping Ethernet Yang Trouble

Kemarin aku disibukkan dengan masalah komputer proxy yang disebabkan listrik PLN kantor yang padam kemarin malam.
Listrik PLN tersebut menjadi masalah serius bagi aku karena upgrade kernel untuk linux aku set setiap malam. Kemungkinan besar sewaktu listrik PLN padam, upgrade yang terjadi di komputer proxy belum 100% selesai.
Hal aneh terjadi ketika aku boot komputer dengan kernel baru tersebut, mapping untuk Eth nya kacau. Sebagai catatan ada tiga Eth di komputer proxyku dan setiap Eth ada IP alias, jadi secara rinci dapat digambarkan sebagai berikut :

• Eth0
• Eth0:0
• Eth0:1
• Eth0:2
• Eth1
• Eth1:0
• Eth1:1
• Eth2
• Eth2:0
• Eth2:1
• Eth2:2

Nah ketika Boot menggunakan kernel dari hasil upgrade otomatis kemarin,  hasil ping dari komputer proxy nihil sama sekali. Setelah beberapa saat otak – atik di sisi level software en nggak nemu solusi, akhirnya gue nekad mencoba menukar kabel UTP yang mencolok di masing – masing Eth.

• Kabel yang mencolok di Eth0 aku ganti ke Eth2
• Kabel yang mencolok di Eth1 aku ganti ke Eth0
• Kabel yang mencolok di Eth2 aku ganti ke Eth1

Lah… nggak disangka…,  ternyata komputer proxy berhasil melakukan ping, dalam hati… cuma bisa bingung en sampai saat ini belum tahu jawabannya he… he… he…

Kok bisa ya mapping device eth nya kacau balau he he he.