Sabtu, 03 Desember 2011

MOdEM baru ^^_^^

Alhamdulillah, modem baru. akhirnya terpenuhi juga kebutuhan yang satu ini. cuma emang pilih yang murah soalnya klo miliha yang mahal takut keenakan browsing ga jelas dan akhirnya nggak terpenuhi maksud dan tujuan punya modem. maksudnya sih biar bisa sering-sering ngeblog dengan tulisan2 yang bermutu. dan juga skripsinya jangan dilupakan. barakallah, semoga bermanfaat dan barokah :D

Kamis, 01 Desember 2011

Mengenang Kenangan Radio

Sebenarnya kejadian itu sudah beberapa lam. tapi entah mengapa tadi tiba-tiba teringat lagi. ceritanya saat itu malam yang begitu mnyebalkan. aku bener2 merasa menjadi orang perantauan yang tak berteman. entah kenapa ingin dengerin radio, berita-berita atau apalah. tak sengaja aku dengar sebuah radio siaran malam yang membaca sebuah memoar tentang seseorang. lha aku juga denger baru aja dan ku dengar
untuk seseorang yang sudah kuanggap seperti kakakku (kira2 begitu).,,,,,,,
dia bercerita panjang lebar mengenai kakaknya itu, dan saat itu jujur aku geer. dan berharap itu untukku. tapi aku tahu kemungkinannya nggak terlalu banyak. 10% lah. akhirnya aku hanya bisa menikmatinya dan terselip dihatiku "Allah, aku tak tahu itu untuk siapa, tapi bolehkah aku berharap untuk bisa menikmatinya dan berandai bahwa itu untukku, sekejap saja". subhanallah ketika di akhir atensi
terima kasih untuk kak Reny,,,,
 jujur aku ga tahu apa benar ini untuk reny aku. tapi aku bersyukur Alah begitu baik mengatakan aku tak sendirian dan ada orang yang begitu menyayangiku. walaupun sampai saat ini aku tak tahu apakah itu benar untukku atau bukan. tapi aku tetap bersyukur Allah begitu baik. ^_^

Rabu, 30 November 2011

Lembur-Lembur Kerja-Kerja

alhamdulillah, rejeki itu pasti akan datang pada waktunya. dan sekarang cukup banyak kerjaan. alhamdulillah yak! kemarin malam sampai nggak tidur 31 jam full gara2 kerja dan ngerjain skripsi. keren tenan! habis itu pagi tadi terkurung deket kamar mandi alias diare. kayaknya masuk angin berat. hidung mampet, kepala berat. tapi udah kelar sih sekarang. alhamdulillah. baru baik tapi ada kerjaan yang deadlinenya besok. hohohoh gimana neh? bismillah ^_^

Senin, 28 November 2011

Menyegarkan Kembali Pemahaman tentang Requirement Engineering


Requirements engineering adalah fase terdepan dari proses rekayasa perangkat lunak (software engineering), dimana software requirements (kebutuhan) dari user (pengguna) dan customer (pelanggan) dikumpulkan, dipahami dan ditetapkan. Para pakar software engineering sepakat bahwa requirements engineering adalah suatu pekerjaan yang sangat penting. Fakta membuktikan bahwa kebanyakan kegagalan pengembangan software disebabkan karena adaya ketidakkonsistenan (inconsistent), ketidaklengkapan (incomplete), maupun ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan).
Banyak definisi yang diungkapkan oleh para peneliti tentang requirements engineering. Satu definisi yang cukup jelas dan diterima secara umum adalah yang diuraikan oleh Pamela Zave [Zave-97]:
    Requirements engineering adalah cabang dari software engineering yang mengurusi masalah yang berhubungan dengan: tujuan (dunia nyata), fungsi, dan batasan-batasan pada sistem software. Termasuk hubungan faktor-faktor tersebut dalam menetapkan spesifikasi yang tepat dari suatu software, proses evolusinya baik berhubungan dengan masalah waktu maupun dengan software lain (dalam satu famili).
Studi di The Standish Group mencatat bahwa prosentase akumulatif kegagalan sebuah project pengembangan software sebagian besar disebabkan oleh masalah requirements dan spesifikasinya [Standish-94].
Untuk merangkum masalah yang ingin dipecahkan dalam cabang ilmu requirements engineering, kebanyakan pakar mengamini ungkapan Ed Yourdon dalam foreword yang ditulisnya untuk buku Managing Software Requirements – A Unified Approach karya Dean Leffingwell [Leffingwell-00]. Ed Yourdon menggunakan istilah “the rock problem (masalah batu) sebagai diskusi dasar masalah yang selalu muncul dalam proses pengerjaan proyek software.
Customer (pelanggan) yang datang kepada kita untuk mengerjakan sebuah proyek pengembangan software, adalah ibarat seseorang yang mengatakan kepada kita, “Tolong buatkan saya batu”. Ketika kita memberikan kepadanya sebuah batu, dia akan melihatnya sebentar dan mengatakan kepada kita, “Ya terima kasih, tapi sebenarnya yang saya inginkan adalah sebuah batu kecil berwarna biru”. Dan ketika kita bawakan untuknya batu kecil berwarna biru, dia mengatakan bahwa yang diinginkan adalah yang “bentuknya bulat”. Demikian seterusnya proses iterasi (iteration) terjadi berulangkali sampai akhirnya kita dapatkan yang sebenarnya diinginkan customer kita adalah “batu pualam kecil berwarna biru”. Meskipun mungkin sebenarnya bukan “tepat yang diinginkan”, tapi paling tidak “paling dekat” dengan yang diinginkan customer. Dan mungkin saja terjadi, customer kita mengubah pikiran tentang requirements pada saat proses interaksi dengan pengembang terjadi (dari iterasi pertama yang sekedar batu, sampai iterasi terakhir yang menghasilkan batu pualam kecil berwarna biru).
Frustasi terjadi baik di pihak pengembang maupun customer. Pengembang frustasi karena merasakan perbedaan signifikan antara requirements pertama yang dijelaskan customer dengan yang sebenarnya diinginkan customer, belum lagi waktu dan biaya besar sudah dikeluarkan pengembang dalam tiap iterasi. Di lain pihak, customer juga frustasi karena merasa sudah menjelaskan dengan baik dan pengembang tidak bisa memahami yang diinginkan, sehingga memerlukan waktu yang sangat lama.
Fenomena senada dengan masalah batu diatas sering juga disebut dengan “Yes, But Syndrome” (That is what I meant, but not exactly what I meant) dan “Undiscovered Ruins Syndrome” (Now that I see it, I have another requirement to add) [Romi-02].
Dari ilustrasi diatas, muncul keinginan untuk menerapkan pendekatan engineering (engineering approach) untuk memecahkan masalah tersebut, yang akhirnya membawa arus deras kemunculan cabang ilmu requirements engineering.
Hasil dari fase requirements engineering terdokumentasi dalam requirements specification. Requirements specification berisi kesepakatan bersama tentang permasalahan yang ingin dipecahkan antara pengembang dan customer, dan merupakan titik start menuju proses berikutnya yaitu software design. Sistemisasi proses negosiasi pengembang dan customer dalam requirements engineering dibagi dalam 3 proses besar yaitu: elicitation, specification, validation and verification. Formula ini kemudian juga dikenal dengan nama The Three Dimensions of Requirements Engineering. Proses requirements engineering ini dilakukan secara iterasi dengan mengakomodasi adanya feedback dari customer (user).
prosesre.jpg

Requirements Elicitation
Adalah proses mengumpulkan dan memahami requirements dari user. Kadang masalah yang muncul berakar dari gap masalah knowledge domain (perbedaan disiplin ilmu yang dimiliki). Customer adalah expert pada domain yang softwarenya ingin dikembangkan (domain specialist), dilain pihak sang pengembang (requirements analyst) adakalanya sama sekali buta terhadap knowledge domain tersebut, meskipun tentu memahami dengan benar bagaimana sebuah software harus dikembangkan. Gap knowledge domain tersebut yang diharapkan bisa diatasi dengan adanya interaksi terus menerus dan berulang (iterasi) antara pengembang dan customer. Proses interaksi tersebut kemudian dimodelkan menjadi beberapa teknik dan metodologi diantaranya adalah interviewing, brainstorming, prototyping, use case, dsb.
Requirements Specification
Setelah masalah berhasil dipahami, pengembang mendeskripsikannya dalam bentuk dokumen spesifikasi dokumen. Spesifikasi ini berisi tentang fitur dan fungsi yang diinginkan oleh customer, dan sama sekali tidak membahas bagaimana metode pengembangannya. IEEE mengeluarkan standard untuk dokumen spesifikasi requirements yang terkenal dengan nama IEEE Recommended Practice for Software Requirements Specifications [IEEE-830]. Dokumen spesifikasi requirements bisa berisi functional requirements, performance requirements, external interface requirements, design constraints, maupun quality requirements.
Requirements Validation and Verification
Setelah spesifikasi requirements berhasil dibuat, perlu dilakukan dua usaha: Validation (validasi), yaitu proses untuk memastikan bahwa requirements yang benar sudah ditulis. Verification (verifikasi), yaitu proses untuk memastikan bahwa requirements sudah ditulis dengan benar. Proses validasi dan verifikasi ini melibatkan customer (user) sebagai pihak yang menilai dan memberi feedback berhubungan dengan requirements.
REFERENSI[Leffingwell-00] Dean Leffingwell and Don Widrig, Managing Software Requirements: A Unified Approach, Addison Wesley, 2000.
[Romi-02] Romi Satria Wahono and Jingde Cheng, Extensible Requirements Patterns of Web Application, IEEE International Symposium on Cyber Worlds (CW 2002), Japan, 2002.
[Romi-03] Romi Satria Wahono, Analyzing Requirements Engineering Problems, IECI Japan Workshop 2003 (IJW-2003), Japan, 2003.
[Standish-94] The Standish Group, Charting the Seas of Information Technology Chaos, The Standish Group International, 1994.
[Zave-97] Pamela Zave, Classification of Research Efforts in Requirements Engineering, ACM Computing Surveys, 29(4), pp. 315-321, 1997.
ttd-small.jpg

Berdampak pada Kesehatan

subhanallah sejak kemarin rasanya sibuk banget. jam terbangnya malam terus. dan sekarang rasanya berdampak pada kesehatan juga. sebenarnya aku nggak banget untuk keluar malam tapi mau tidak mau sebagai tuntutan pekerjaan harus pulang malam. tapi alhamdulillah sudah terkumpul uang sebanyak 200rb-an dan masih ada tambahan uang beasiswa 1000rban. paling tidak klo bisa mengumpulkan uang 3000rban. sekolah kedua adekku nita dan yeye masih lebih aman nasibnya. bismillah semoga bisa dapat 3000rban.