Cerita Motivasi


Nilai Kehidupan

http://iphincow.files.wordpress.com/2012/06/nilai-kehidupan.jpg

Alkisah, ada seorang pemuda yang hidup sebatang kara. Pendidikan rendah, hidup dari bekerja sebagai buruh tani milik tuan tanah yang kaya raya. Walapun hidupnya sederhana tetapi sesungguhnya dia bisa melewati kesehariannya dengan baik.
Pada suatu ketika, si pemuda merasa jenuh dengan kehidupannya. Dia tidak mengerti, untuk apa sebenarnya hidup di dunia ini. Setiap hari bekerja di ladang orang demi sesuap nasi. Hanya sekadar melewati hari untuk menunggu kapan akan mati. Pemuda itu merasa hampa, putus asa, dan tidak memiliki arti.
“Daripada tidak tahu hidup untuk apa dan hanya menunggu mati, lebih baik aku mengakhiri saja kehidupan ini,” katanya dalam hati. Disiapkannya seutas tali dan dia berniat menggantung diri di sebatang pohon.
Pohon yang dituju, saat melihat gelagat seperti itu, tiba-tiba menyela lembut. “Anak muda yang tampan dan baik hati, tolong jangan menggantung diri di dahanku yang telah berumur ini. Sayang, bila dia patah. Padahal setiap pagi ada banyak burung yang hinggap di situ, bernyanyi riang untuk menghibur siapapun yang berada di sekitar sini.”
Dengan bersungut-sungut, si pemuda pergi melanjutkan memilih pohon yang lain, tidak jauh dari situ. Saat bersiap-siap, kembali terdengar suara lirih si pohon, “Hai anak muda. Kamu lihat di atas sini, ada sarang tawon yang sedang dikerjakan oleh begitu banyak lebah dengan tekun dan rajin. Jika kamu mau bunuh diri, silakan pindah ke tempat lain. Kasihanilah lebah dan manusia yang telah bekerja keras tetapi tidak dapat menikmati hasilnya.”
Sekali lagi, tanpa menjawab sepatah kata pun, si pemuda berjalan mencari pohon yang lain. Kata yang didengarpun tidak jauh berbeda, “Anak muda, karena rindangnya daunku, banyak dimanfaatkan oleh manusia dan hewan untuk sekadar beristirahat atau berteduh di bawah dedaunanku. Tolong jangan mati di sini.”
Setelah pohon yang ketiga kalinya, si pemuda termenung dan berpikir, “Bahkan sebatang pohonpun begitu menghargai kehidupan ini. Mereka menyayangi dirinya sendiri agar tidak patah, tidak terusik, dan tetap rindang untuk bisa melindungi alam dan bermanfaat bagi makhluk lain”.
Segera timbul kesadaran baru. “Aku manusia; masih muda, kuat, dan sehat. Tidak pantas aku melenyapkan kehidupanku sendiri. Mulai sekarang, aku harus punya cita-cita dan akan bekerja dengan baik untuk bisa pula bermanfaat bagi makhluk lain”.
Si pemuda pun pulang ke rumahnya dengan penuh semangat dan perasaan lega.
Kalau kita mengisi kehidupan ini dengan menggerutu, mengeluh, dan pesimis, tentu kita menjalani hidup ini (dengan) terasa terbeban dan saat tidak mampu lagi menahan akan memungkinkan kita mengambil jalan pintas yaitu bunuh diri.
Sebaliknya, kalau kita mampu menyadari sebenarnya kehidupan ini begitu indah dan menggairahkan, tentu kita akan menghargai kehidupan ini. Kita akan mengisi kehidupan kita, setiap hari penuh dengan optimisme, penuh harapan dan cita-cita yang diperjuangkan, serta mampu bergaul dengan manusia-manusia lainnya.
=========================================================================

Arti Kesetiaan


Kisah nyata yang bagus sekali untuk contoh kita semua yang saya dapat dari millis sebelah (kisah ini pernah ditayangkan di MetroTV). Semoga kita dapat mengambil pelajaran.
Ini cerita nyata, beliau adalah Bp. Eko Pratomo Suyatno, Direktur Fortis Asset Management yg sangat terkenal di kalangan Pasar Modal dan Investment, beliau juga sangat sukses dlm memajukan industri Reksadana di Indonesia. Apa yg diutarakan beliau adalah sangat benar sekali. Silakan baca dan dihayati.
————————————————————————————————–
Dilihat dari usianya beliau sudah tidak muda lagi, usia yg sudah senja bahkan sudah mendekati malam, Pak Suyatno 58 tahun kesehariannya diisi dengan merawat istrinya yang sakit istrinya juga sudah tua.Mereka menikah sudah lebih 32 tahun. Mereka dikarunia 4 orang anak.
Disinilah awal cobaan menerpa, setelah istrinya melahirkan anak keempat tiba-tiba kakinya lumpuh dan tidak bisa digerakkan. Itu terjadi selama 2 tahun. Menginjak tahun ke tiga, seluruh tubuhnya menjadi lemah bahkan terasa tidak bertulang, lidahnyapun sudah tidak bisa digerakkan lagi.
Setiap hari pak suyatno memandikan, membersihkan kotoran, menyuapi, dan mengangkat istrinya keatas tempat tidur. Sebelum berangkat kerja, dia letakkan istrinya didepan TV supaya istrinya tidak merasa kesepian. Walau istrinya tidak dapat bicara tapi dia selalu melihat istrinya tersenyum.
Untunglah tempat usaha pak suyatno tidak begitu jauh dari rumahnya sehingga siang hari dia pulang untuk menyuapi istrinya makan siang. Sorenya dia pulang memandikan istrinya, mengganti pakaian dan selepas waktu maghrib dia temani istrinya nonton televisi sambil menceritakan apa2 saja yg dia alami seharian. Walaupun istrinya hanya bisa memandang tapi tidak bisa menanggapi, Pak Suyatno sudah cukup senang, bahkan dia selalu menggoda istrinya setiap berangkat tidur.
Rutinitas ini dilakukan Pak Suyatno lebih kurang 25 tahun, dengan sabar dia merawat istrinya bahkan sambil membesarkan ke 4 buah hati mereka, sekarang anak2 mereka sudah dewasa, tinggal si bungsu yg masih kuliah.
Pada suatu hari, ke empat anak suyatno berkumpul dirumah orang tua mereka sambil menjenguk ibunya. Karena setelah anak mereka menikah, sudah tinggal dengan keluarga masing-masing dan Pak Suyatno memutuskan ibu mereka dia yang merawat, yang dia inginkan hanya satu semua anaknya berhasil.
Dengan kalimat yang cukup hati-hati anak yg sulung berkata “Pak kami ingin sekali merawat ibu, semenjak kami kecil melihat bapak merawat ibu, tidak ada sedikitpun keluhan keluar dari bibir bapak, bahkan bapak tidak ijinkan kami menjaga ibu”.
Dengan air mata berlinang anak itu melanjutkan kata-kata: “sudah yang keempat kalinya kami mengijinkan bapak menikah lagi, kami rasa ibupun akan mengijinkannya, kapan bapak menikmati masa tua bapak, dengan berkorban seperti ini kami sudah tidak tega melihat bapak. Kami janji kami akan merawat ibu sebaik-baik secara bergantian”.
Pak Suyatno menjawab hal yg sama sekali tidak diduga anak-anaknya: “Anak-anakku… Jikalau perkawinan & hidup di dunia ini hanya untuk nafsu, mungkin bapak akan menikah.. tapi ketahuilah dengan adanya ibu kalian disampingku itu sudah lebih dari cukup, dia telah melahirkan kalian. Sejenak kerongkongannya tersekat, kalian yg selalu kurindukan hadir didunia ini dengan penuh cinta yg tidak satupun dapat dihargai dengan apapun.”
“Coba kalian tanya ibumu apakah dia menginginkan keadaannya seperti ini? Kalian menginginkan bapak bahagia, apakah bathin bapak bisa bahagia meninggalkan ibumu dengan keadaanya sekarang, kalian menginginkan bapak yang masih diberi Tuhan kesehatan dirawat oleh orang lain? Bagaimana dengan ibumu yg masih sakit.”
Sejenak meledaklah tangis anak-anak pak suyatno. Merekapun melihat butiran-butiran kecil jatuh dipelupuk mata ibu Suyatno. Dengan pilu ditatapnya mata suami yg sangat dicintainya itu.
Sampailah akhirnya Pak Suyatno diundang oleh salah satu stasiun TV swasta untuk menjadi nara sumber dan merekapun mengajukan pertanyaan kepada Suyatno, kenapa mampu bertahan selama 25 tahun merawat Istrinya yang sudah tidak bisa apa-apa.
Disaat itulah meledak tangis beliau dengan tamu yang hadir di studio, kebanyakan kaum perempuanpun tidak sanggup menahan haru. Disitulah Pak Suyatno bercerita..” Jika manusia didunia ini mengagungkan sebuah cinta dalam perkawinannya, tetapi tidak mau memberi (memberi waktu, tenaga, pikiran, perhatian) itu adalah kesia-siaan”.
“Saya memilih istri saya menjadi pendamping hidup saya, dan sewaktu dia sehat diapun dengan sabar merawat saya, mencintai saya dengan hati dan bathinnya bukan dengan mata, dan dia memberi saya 4 orang anak yg lucu-lucu. Sekarang dia sakit karena berkorban untuk cinta kita bersama. Dan itu merupakan ujian bagi saya, apakah saya dapat memegang komitmen untuk mencintainya apa adanya. Sehatpun belum tentu saya mencari penggantinya apalagi dia sakit…”
Hidup adalah Perjuangan tanpa henti-henti, tidak usah kau tangisi hari kemarin.
========================================================================




  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Motivasi

Pada suatu malam, seorang buta berpamitan pulang dari rumah sahabatnya. Sang sahabat membekalinya dengan sebuah lentera pelita.
Orang buta itu terbahak berkata: “Buat apa saya bawa pelita? Kan sama saja buat saya! Saya bisa pulang kok.”
Dengan lembut sahabatnya menjawab, “Ini agar orang lain bisa melihat kamu, biar mereka tidak menabrakmu.”
Akhirnya orang buta itu setuju untuk membawa pelita tersebut. Tak berapa lama, dalam perjalanan, seorang pejalan menabrak si buta.
Dalam kagetnya, ia mengomel, “Hei, kamu kan punya mata! Beri jalan buat orang buta dong!”
Tanpa berbalas sapa, mereka pun saling berlalu.
Lebih lanjut, seorang pejalan lainnya menabrak si buta.
Kali ini si buta bertambah marah, “Apa kamu buta? Tidak bisa lihat ya? Aku bawa pelita ini supaya kamu bisa lihat!”
Pejalan itu menukas, “Kamu yang buta! Apa kamu tidak lihat, pelitamu sudah padam!”
Si buta tertegun..
Menyadari situasi itu, penabraknya meminta maaf, “Oh, maaf, sayalah yang ‘buta’, saya tidak melihat bahwa Anda adalah orang buta.”
Si buta tersipu menjawab, “Tidak apa-apa, maafkan saya juga atas kata-kata kasar saya.”
Dengan tulus, si penabrak membantu menyalakan kembali pelita yang dibawa si buta. Mereka pun melanjutkan perjalanan masing-masing.
Dalam perjalanan selanjutnya, ada lagi pejalan yang menabrak orang buta kita.
Kali ini, si buta lebih berhati-hati, dia bertanya dengan santun, “Maaf, apakah pelita saya padam?”
Penabraknya menjawab, “Lho, saya justru mau menanyakan hal yang sama.”
Senyap sejenak.
secara berbarengan mereka bertanya, “Apakah Anda orang buta?”
Secara serempak pun mereka menjawab, “Iya.,” sembari meledak dalam tawa.
Mereka pun berupaya saling membantu menemukan kembali pelita mereka yang berjatuhan sehabis bertabrakan.
Pada waktu itu juga, seseorang lewat. Dalam keremangan malam, nyaris saja ia menubruk kedua orang yang sedang mencari-cari pelita tersebut. Ia pun berlalu, tanpa mengetahui bahwa mereka adalah orang buta.
Timbul pikiran dalam benak orang ini, “Rasanya saya perlu membawa pelita juga, jadi saya bisa melihat jalan dengan lebih baik, orang lain juga bisa ikut melihat jalan mereka.”
Pelita melambangkan terang kebijaksanaan. Membawa pelita berarti menjalankan kebijaksanaan dalam hidup. Pelita, sama halnya dengan kebijaksanaan, melindungi kita dan pihak lain dari berbagai aral rintangan (tabrakan!).
Si buta pertama mewakili mereka yang terselubungi kegelapan batin, keangkuhan, kebebalan, ego, dan kemarahan. Selalu menunjuk ke arah orang lain, tidak sadar bahwa lebih banyak jarinya yang menunjuk ke arah dirinya sendiri. Dalam perjalanan “pulang”, ia belajar menjadi bijak melalui peristiwa demi peristiwa yang dialaminya. Ia menjadi lebih rendah hati karena menyadari kebutaannya dan dengan adanya belas kasih dari pihak lain. Ia juga belajar menjadi pemaaf.
Penabrak pertama mewakili orang-orang pada umumnya, yang kurang kesadaran, yang kurang peduli. Kadang, mereka memilih untuk “membuta” walaupun mereka bisa melihat.
Penabrak kedua mewakili mereka yang seolah bertentangan dengan kita, yang sebetulnya menunjukkan kekeliruan kita, sengaja atau tidak sengaja. Mereka bisa menjadi guru-guru terbaik kita. Tak seorang pun yang mau jadi buta, sudah selayaknya kita saling memaklumi dan saling membantu.
Orang buta kedua mewakili mereka yang sama-sama gelap batin dengan kita. Betapa sulitnya menyalakan pelita kalau kita bahkan tidak bisa melihat pelitanya. Orang buta sulit menuntun orang buta lainnya. Itulah pentingnya untuk terus belajar agar kita menjadi makin melek, semakin bijaksana.
Orang terakhir yang lewat mewakili mereka yang cukup sadar akan pentingnya memiliki pelita kebijaksanaan.
Sudahkah kita sulut pelita dalam diri kita masing-masing? Jika sudah, apakah nyalanya masih terang, atau bahkan nyaris padam? JADILAH PELITA, bagi diri kita sendiri dan sekitar kita.
Sebuah pepatah berusia 25 abad mengatakan: Sejuta pelita dapat dinyalakan dari sebuah pelita, dan nyala pelita pertama tidak akan meredup. Pelita kebijaksanaan pun, tak kan pernah habis terbagi.
Bila mata tanpa penghalang, hasilnya adalah penglihatan. Jika telinga tanpa penghalang, hasilnya adalah pendengaran. Hidung yang tanpa penghalang membuahkan penciuman. Fikiran yang tanpa penghalang hasilnya adalah kebijaksanaan.

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Cerita Lucu

Cerita lucu 1 - kena tilang

Seorang pegawai terlambat pergi ke kantor, ia tergesa-gesa dengan motornya. Sialnya ditengah jalan terjadi razia dadakan oleh polisi. Prriiittt.., motornya dihentikan oleh polisi. "Mana surat-suratnya!", kata polisi. Sialnya ternyata si pengendara motor itu nggak bawa SIM. "Kamu saya tilang!", seru polisi. "wah, jangan pak, damai saja ya pak..", kata si pengendara sambil memberi uang 20 ribuan. "Ya sudah, kamu pulang lagi, ambil dulu surat kelengkapan yang kurang!". Si pengendara akhirnya pulang untuk mengambil SIM dan kembali berangkat ke kantor untuk bekerja. Priiitttt.., si pengendara diberhentikan polisi lagi. "Ada apa lagi sih pak?", kata si pengendara. "Anda tidak pakai helm!", kata polisi. Sial banget, gara-gara pulang mengambil SIM malah kelupaan helm, akhirnya si pengendara pulang mengambil helmnya setelah terkuras 20 ribu lagi. Di tengah jalan saat kembali ke kantor, priiittttt!, "Nih.. surat-surat lengkap, helm udah bawa, serakah amat, ada apa lagi sih pak?", kata pengendara. "Surat lengkap, helm sudah dipakai.. sekarang motornya mana!!???", seru polisi.


Cerita lucu 2 - sok tahu

Suatu hari Udin mau mengetes seorang dukun yg terkenal pinter di desanya
Udin (U): Kalo anda emang pinter, coba tebak, burung di tangan gue masih idup apa sudah mati???
Dukun (D): halllahhh.... kamu masih bocah sudah mau ngejebak saya, saya tahu kalau saya bilang hidup, kamu akan meremas burung itu sampai mati, kalau saya bilang mati, kamu akan melepaskan burung itu agar terbang
U: Hahahaha.... ternyata desas-desus kalau anda orang paling pintar di desa ini salah besar
D: lha!!!! knapa??? bukankah jawaban saya masuk akal???
U: jawaban anda masuk akal, tetapi anda tetap salah karena ditangan saya bukan burung, tapi hamster

Cerita lucu 3 - Antara Topeng Istri dan Sekretaris

Ketika diadakan Pesta Topeng (Halloween Party) seorang istri Konglomerat marahmarah
sama sekretaris suaminya. Berceritalah Tuan Billy ,sang Konglomerat, kepada
temennya Tuan Bagus.
Tuan Bagus: "Jadi kenapa istri anda marah-marah?"
Tuan Billy: "Iya masalahnya sih sepele, katanya."
Tuan Bagus: "Apakah istri bapak,pencemburu,dan cemburu kepada sekretaris anda
waktu Pesta itu, tanyanya?"
Tuan Billy: "Bukan itu masalahnya.Istriku marah-marah kepada sekretarisku karena
sekretarisku mau meminjam Topeng istriku."
Tuan Bagus: "Mosok begitu saja marah?"
Tuan Billy: "Iya, sebab malam itu sebenarnya istriku sedang tidak memakai
topeng...."

Cerita lucu 4 - Berita kehilangan anak

Berita Kehilangan!
Telah hilang seorang anak, dengan ciri-ciri sebagai berikut:
Nama : Satriyo
Alamat : Yogyakarta
Usia : 7 tahun
Hilang hari minggu jam 13.00 WIB, memakai baju partai, celana pendek, kulit putih,
rambut cepak dan pakai sendal kegedean. Bagi yang menemukan ciri-ciri diatas harap
menghubungi ibunya karena sendalnya mau dipakai...




  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

ASI BARU


  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

Materi Konsep dan Prinsip Desain

DESAIN PERANGKAT LUNAK DAN REKAYASA PERANGKAT LUNAK

Desain perangkat lunak berada pada inti dari proses rekayasa perangkat desain dan diaplikasikan tanpa memperhatikan model proses rekayasa untuk digunakan. Begitu persyaratan lunak menjadi yang pertama dari tiga aktifitas teknik – desain, pembuatan kode, dan pengujian – yang diperlukan untuk membangun dan menguji perangkat lunak yang masing-masing menghasilkan perangkat lunak komputer yang tervalidasi.
Masing-masing elemen model analisis memberikan informasi yang diperlukan untuk menciptakan suatu model. Persyaratan perangkat lunak, yang dimanifestasikan oleh data, fungsional, dan model-model perilaku, mengisi langkah desain. Dengan menggunakan satu dari sejumlah metode desain, langkah desain data, desain arsitektur, desain interface, serta desain prosedural.
Desain data mentransformasikan menentukan model domain informasi yang dibuat selama analisis ke dalam struktur data yang akan diperlukan untuk mengimplementasi perangkat lunak.
Desain arsitektur menentukan hubungan diantara elemen-elemen struktur utama dari program.
Desain interface menggambarkan bagaimana perangkat lunak berkomunikasi dalam dirinya sendiri, dengan sistem berinteroperasi dengannya, dan dengan manusia yang menggunakannya.
Desain prosedural mentransformasikan elemen-elemen dari arsitektur program ke dalam suatu deskripsi prosedural dari komponen-komponen perangkat lunak. Informasi yang diperoleh dari PSPEC, CSPEC, dan STD berfungsi sebagai dasar bagi desain prosedural. Selama desain, kita membuat keputusan yang akan mempengaruhi kesuksesan perangkat lunak, dan yang penting, kemudian dimana perangkat lunak dapat dipelihara. 
Desaign Perangkat Lunak
Desain suatu perangkat lunak merupakan proses beberapa tahap yang difokuskan pada 4 atribut yang berbeda dari sebuah program yaitu: Struktur Data, Arsitektur software, Tampilan antarmuka, Algoritma (prosedur). Desain ini didokumentasikan dan menjadi bagian dari konfigurasi perangkat lunak
· Desain Antar Muka
Desain antarmuka harus dibuat yang menarik, interaktif, mudah dipelajari, mudah digunakan dan mudah dipahami. Beberapa faktor yang perlu diperhatikan dalam desain antarmuka, yaitu :
a. Ruang gerak mata
b. Sarana komunikasi
c. Mudah digunakan
d. Ergonomic (kenyamana & keamanan), yang meliputi : Penentuan ukuran, jenis, warn & format font, Pemilihan warna, Menyajikan objek yang tipis / kecil dengan pilihan warna, Ruang gerak mata
e. Cognitive Psychology, yang meliputi : Jumlah warna, Simbol standart & tata letak, Penggunaan kata yang tidak berkonotasi ganda. Mis. Masukkan nama anda, bisa dispesifikasikan menjadi masukkan nama user dll
f. Aneka ragam dialog, yang meliputi : Model menu datar, check box dll

· Permasalahan yang ada pada desain perangkat lunak :
a. Waktu respon sistem, diukur mulai saat user melakukan beberapa aksi kontrol sampai dengan perangkat lunak merespon dengan menampilkan output / aksi yang diperlukan.
b. Fasilitas help untuk pemakai. Ada 2 jenis fasilitas help yaitu :
§ Help integrated, fasilitas help yang dimasukkan ke dalam perangkat lunak, yang memungkinkan user untuk memilih topik yang sesuai dengan kegiatan yang dilakukan.
§ Help Add-On, fasilitas help yang ditambahkan setelah aplikasi perangkat lunak selesai dikembangkan yang dapat berupa manual user-line dengan kemampuan query yang terbatas.


Beberapa hal yang perlu dipertimbangkan dalam membuat desain help :
· Apakah help dapat diperoleh untuk semua fungsi sistem dan keseluruhan waktu selama interaksi sistem ?
· Bagaimana user mengakses help? Pilihan meliputi : menu help, kunci fungsi khusu, perintah help
· Bagaimana help diprepresentasikan? Pilihan meliputi : sebuah jendela terpisah, refensi untuk dokumen yang tercetak serta satu atau dua baris usulan yang dibuat pada suatu lokasi layer yang tetap
· Bagaimana pemakai kembali ke interaksi normal?pilihan mencakup tombol return yang ditampilkan pada layer dan kunci fungsi atau urutan control
· Bagaimana informasi help distruktur? Pilihan mencakup struktur “datar” di mana semua informasi diakses melalui suatu kata kunci, hirarki informasi bertingkat, kegunaan hiperteks.

c. Penanganan informasi kesalahan
Sering kali pesan kesalahan tidak memberikan indikasi nyata mengenai apa yang salah atau dimana dapat memperoleh informasi tambahan. Karakteristik peringatan kesalahan adalah :
· Pesan harus menggambarkan masalah dalam istilah yang dapat dipahami oleh pemakai
· Pesan harus memberikan nasihat instruktif untuk membetulkan kesalahan
· Pesan harus mengindikasikan konsekuensi negatif dari kesalahan, cont. File data yang secara potensial dikorup) sehingga pemakai dapat mengecek untuk memastikan bahwa hal tersebut tidak terjadi (atau membetulkan bila memang terjadi)
· Pesan harus disertai oleh sebuah isyarat visual atau bunyi untuk mengiringi tampilan pesan
· Pesan tersebut harus tidak ”menghakimi” yaitu penyusunan kata tidak boleh menyalahkan pemakai.

d. Pelabelan perintah
Perintah yang diketik merupakan mode yang umum dari interaksi antara pemakai dan perangkat lunak sistem dan biasa dipakai untuk aplikasi setiap tipe. Dalam banyak keadaan, user dapat memilih fungsi-fungsi yang disediakan. Beberapa hal yang perlu diperhatikan dalam mendesain perintah :
· Apakah setiap pilihan menu memiliki perintah yang sesuai?Bagaimana pentuk yang akan diambil oleh perintah? Pilihan meliputi : urutan kontrol (mis. ^P), tombol fungsi, kata yang diketikkan 


Desaign Rekayasa perangkat Lunak
Desain prosedural terjadi setelah data, desain arsitektur, dan interface, dibangun.Dalam dunia yang ideal, spesifikasi prosedural diperlukan untuk menetapkan detail algoritma yang akan dinyatakan dalam suatu bahasa ibu seperti bahasa inggris. Akan tetapi, semua anggota organisasi pengembangan perangkat lunak menggunakan bahasa ibu (paling tidak secara teori), orang di luar domain perangkat lunak dapat lebih memahami spesifikasi tersebut dan tidak ada pelajaran baru yang Sayangnya ada satu masalah kecil, desain prosedural harus menentukan detail desain prosedural tanpa ada ambiguitas, dan tidak ada ambiguitas. Di dalam bahasa ibu bukan merupakan hal hal wajar. Dengan menggunakan suatu bahasa ibu, kita dapat menuliskan serangkaian langkah prosedural dalam begitu banyak cara yang berbeda. Kita kerap kali bersandar pada konteks untuk mendapatkan fakta penting. Kita sering menulis seolah-olah ada dialog dengan pembaca (sebenarnya tidak). Karena alasan tersebut dan hal lainnya, harus digunakan mode yang lebih terbatas untuk mempresentasikan detail prosedural.
PEMROGRAMAN TERSTUKTUR REKAYASA PERANGKAT LUNAK
Definisi – definisi mendasar dari pemrograman yang terstruktur adalah sebagai berikut :
  • Teori pemrograman terstruktur memperlakukan pengkorversian diagram alir besar dan kompleks ke dalam bentuk standar sedemikian rupa sehingga mereka dapat dipresentasikan dengan iterasi dan nesting (pengumpulan) sejumlah kecil struktur logika kontrol dasar dan standar (H.D. Mills, Chief Programmer Teams:Principle and Procedures).
  • Pemrograman terstruktur adalah cara pengorganisasian dan pengkodean program-program yang kompleks dan membuat program tersebut lebih mudah dipahami dan dimodifikasi (J.R.Donaldson,Struktured programming
  • Konsep dasar [dari pemrograman terstuktur] adalah suatu pembuktian kebenaran, (R.A.Karp)
  • Pemrograman terstuktur bukanlah obat mujarab-ia benar-benar terdiri dari suatu atribut yang biasanya tidak inherent (menjadi sifat) dalam pemrograman atau sebarang jenis yang lain (D.Butterworrth)
Prof E.W Dykstra pada tahun 1960 dalam papernya mengusulkan bahwa pernyataan Go To,seharusnya tidak dipergunakan didalam program terstuktur. Oleh karena itu sering disebut pemrograman terstruktur sebagai pemrograman tanpa GOTO (GOTO less programming).
Definisi yang lain oleh H.D. Mills adalah pemrograman terstuktur tidak harus dicirikan secara panjang lebar dengan absennya go to,melainkan timbulnya terstruktur.
Sedangkan definisi yang lebih akurat lagi dinyatakan oleh N. Wirth bahwa pemrograman terstuktur adalah formulasi program secara hierarkis,struktur berkelompok dari pernyataan-pernyataan dan objek-objek komputasi. Pernyataan Wirth sendiri bukanlah mendefininisikan perangkat atau konstruksi kontrol logika yang dapat digunakan, atau tidak membatasi teknik formulasi terstuktur yang tersedia untuk desain program.
Prinsip utama dari pemrograman yang terstuktur adalah bahwa jika urutan suatu proses telah sampai pada suatu baris sintaks tertentu, maka proses selanjutnya tidak boleh melompat mundur kebaris sebelumnya, kecuali untuk proses dengan struktur kontrol repetition/looping. Modifikasi akan sulit dilakukan terhadap suatu program, jika kode programnnya yang dibuat tidak terstruktur dengan baik. Biasanya para pemrogram (programmer) akan merasa sangat perlu untuk memahami metodologi perancangan program yang terstruktur, jika mereka sedang membuat program yang besar dan komplek.
Pemrograman terstruktur dipandang oleh banyak pemrogram sebagai sinonim untuk pemrogramman modular atau top-down. Sebenarnya pemrograman modular adalah suatu sub kelas dari metodologi perancangan dalam suatu kelas umum dari metodologi penyederhanaan persoalan yang diketahui sebagai pemrograman terstruktur.
Pemrograman terstuktur dapat divisualisasikan sebagai aplikasi dan metode penyederhananaan persoalan dasar untuk menyusun terstruktur persoalan hierarki yang bisa dikelola.Untuk memperolah suatu pengetahuan yang lebih besar dari perbedaan antara sub kelas berbagai metodologi yang terkandung dalam pemrograman terstruktur, pertama kita harus memandang tujuan dari proses kemurnian. Kita diberikan suatu persoalan, biasanya kita menspesifikasi kedalam bahasa kita, dan mensyaratkan untuk menunjukan suatu penyelesaian persoalan tersebut ke dalam suatu bahasa pemrograman tingkat tinggi.
Bila persoalan tidak lebih dari”menghitung jumlah dari A dan B”, persoalan ini akan langsung diterjemahkan kedalam RESULT = A+B. Jika persoalan besar atau rumit, maka sistem yang didefinisikan untuk menyelesaikan persoalan tersebut haruslah disederhanakan menjadi sub sistem dimana setelah sejumlah penyederhanaan, secara hierarkis menjadi modul-modul. Setelah penyederhanaan tambahan, hasilnya merupakan suatu program yang terstruktur. Masing-masing sub kelas metodologi dapat digambarkan dengan:
  • Jangkauan proses keaslian yang padanya metodologi menjadi efektif.
  • Pendekatannya ke proses keaslian.
  • Aplikasi yang berguna
CIRI-CIRI PROGRAM TERSTUKTUR
Program yang baik/terstuktur mempunyai ciri-ciri sebagai berikut :
    Dapat dijalankan dengan baik dan benar (sesuai dengan keinginan pemrogram).
  • Dapat dijalankan secara efisien dan efektif dengan tidak banyak menggunakan sintaks yang tidak perlu (menghasilkan output yamg tepat dan benar dalam waktu yang singkat).
  • Mudah dibaca dan dipahami oleh orang lain maksud dan tujuan objek yang akan ditampilkan (memiliki logika perhitungan yang tepat dalam memecahkan masalah, dan ditulis dalam bahasa yang standar yaitu bahasa Indonesia/Inggris terstuktur,sehingga tidak menimbulkan arti ganda).
  • Mudah diperbaiki, jika terjadi kesalahan (semua operasi yang dilakukan harus terdefinisi dengan jelas dan berakhir setelah sejumlah langkah dilakukan).
    Biaya pengujian yang dibutuhkan rendah
    Memiliki dokumentasi yang baik
  • Biaya perawatan dan dokumentasi yang dibuthkan rendah
  • Program hanya terdiri dari tiga struktur kontrol, yaitu stuktur urut,stuktur seleksi, dan struktur repetisi/iterasi
LANGKAH-LANGKAH PENGEMBANGAN PROGRAM
Suatu program yang baik membutuhkan suatu standar, sehingga akan memudahkan pemrogram untuk merancang, dan merawat program. Sehingga perlu dipahami beberapa langkah yang harus dilakukan dalam merancang suatu program yang terstruktur. Langkah –langkah tersebut adalah sebagai berikut:
1. Definisikan Masalah
Pemahaman permasalahan merupakan suatu hal yang sangat penting bagi sipemrogram. Sipemrogram perlu memahami permasalahan yang dihadapi dan yang akan diselesaikan oleh pemesan program, agar hasil pendefinisian masalah tidak menyimpang dari masalah yang sedang dihadapi.
Setelah menyamakan persepsi tentang suatu masalah yang dihadapi dan akan diselesaikan, maka pemrogram dapat mengidentifikasi permasalahan tersebut secara rinci, dan menentukan ruang lingkup permasalahan yang akan diselesaikan terlebih dahulu, dan kemungkinan kendala-kendala yang akan dihadapi, lalu berapa lama proses penyelesaian masalah tersebut. Pemrograman harus membuat langkah-langkah penyelesaian masalah berdasarkan ruang lingkup permasalahan yang ditentukan, sehingga pekerjaan pembuatan program terarah dan terjadwal dengan baik.
Masalah yang perlu didefinisikan adalah komponen input dari suatu program yang akan dirancang tersebut apa saja yang akan terjadi didalam menyelesaikan program tersebut dan menampilkan hasilnya, yang terakhir adalah komponen output yang diinginkan seperti apa, dan formatnya bagaimana.
2. Merancang Outline Pemecahan Masalah
Dalam merancang outline pemecahan masalah pemrogram perlu membuat rincian proses secara rinci (meliputi proses apa saja yang terjadi pada menu utama, lalu masing-masing sub menu dalam menu utama tesebut akan mengerjakan berapa proses,setiap proses yang terjadi berinteraksi dengan file apa saja, dan berapa file yang terlibat dalam proses tersebut).
Setelah rincian proses dan file yang berinteraksi diketahui, pemrogram menentukan berapa bentuk stuktur kontrol yang terlibat dalam satu proses,dan jenis stukturnya apa saja dan berapa banyak, misalkan baris 1-10 menggunakan struktur urut atau seleksi, dan baris 11-20 menggunakan struktur repetisi repeat-until atau for-do, dst.
Judul dari setiap proses (modul) apa saja, dan deklarasikan seluruh variable yang akan digunakan dalam setiap proses (modul), baik variable lokal maupun variable global. Setelah itu tentukan deskripsi dari proses (modul) tersebut. Setelah outline selesai, maka transformasikan outline tersebut kedalam algoritma, dengan menggunakan pseudecode yang dapat ditulis dengan struktur Indonesia (bahasa Indonesia terstuktur) atau struktur Inggris (bahasa Inggris tersrtuktur).
Desain algoritma yang dibuat haruslah sama dengan langkah-langkah penyelesaian masalah yang ditentukan, karena algoritma dibuat untuk menyelesaikan masalah yang dihadapi oleh pemrogram.
Algoritma yang telah dibuat tersebut perlu dilakukan pengujian agar output yang dihasilkan nantinya dapat sesuai dengan keinginan sipemrogram. Disamping pengujian juga perlu dibuat format input / output yang jelas, serta komentar untuk setiap baris yang dapat membantu pemrogram dalam mengingat tujuan dari perintah tersebut.Pengujian algoritma tersebut dapat dilakukan dengan menggunakan diagram overview dan diagram rinci HIPO (HIRARKI Plus Input dan Output).
3. Pengkodean Program
Algoritma yang telah selesai dilakukan pengujian,dapat langsung ditransformasikan kedalam salah satu bahasa pemrograman yang diinginkan atau yang dikuasai oleh sipemrogram. Bahasa pemrograman yang baik harusalah dapat dipakai pada berbagai jenis komputer yang berbeda-beda dan berbaai jenis sistem informasi, hal ini dikenal dengan portabilitas. Pemrogram juga haruslah menentukan batas waktu minimum dalam penulisan suatu modul program, dari awal hingga siap dioperasikan.
Tujuan pengkodean adalah terjadinya efisiensi terhadap memori yang akan digunakan, efisiensi perintah dalam setiap modul program,serta efisiesi terhadap penggunaan fasilitas input dan output yang akan berpengaruh langsung terhadap porseor ataupun terhadap pengguna.
4. Eksekusi Program
Pekerjaan komputer (prosesor) pada dasarnya hanya dua yaitu fetch (membaca instruksi/ program dari memori), lalu execute (mengeksekusi instruksi/program tesebut) dan menampilkan hasilnya ke media output seperti printer, monitor dll.Untuk memperoleh eksekusi program dengan kecepatan maksimum, maka perlu diperhatikan beberapa faktor, seperti jenis bahasa pemrograman yang dipilih apakah sanggup mengangkat data yang akan diproses, dan spesifikasi perangkat keras yang digunakan.
5. Dokumentasi Dan Pemeliharaan Program
Penulisan program yang kompleks harus selalu didokumentasikan setiap kurun waktu tertentu, jadwal dokumentasi juga perlu dibuat demi menjaga keamanan terhadap program dan data dari orang-orang yang tidak bertanggung jawab.
Pemeliharaan program berfungsi untuk menjabarkan aktivitas dari hasil analisis terhadap sistem dan dilakukan setelah program diimplementasikan dan telah digunakan beberapa saat oleh pemakai. Pemeliharaan mencangkup:
  1. Format tampilan yang disesuaikan dengan keinginan pengguna
  2. Fungsi-fungsi yang tidak sesuai dengan keinginan pengguna
  3. Adaptasi dengan spesifikasi prosesor yang baru dan ssistem operasi yang baru.
  4. Dan lain-lain.
KOMPONEN PEMROGRAMAN TERSTUKTUR
Pemrograman terstuktur memiliki tiga komponen utama yaitu :.
1. Pemrograman Top-Down
Teknik Top-Down didefinisikan sebagai suatu masalah yang kompleks dibagi-bagi kedalam beberapa kelompok masalah yang lebih kecil. Dari kelompok masalah yang kecil tersebut dianalisis. Apabila dimungkinkan, maka masalah tersebut akan dipilah-pilah lagi menjadi sub bagian yang lebih kecil, dan setelah itu mulai disusun langkah-langkah untuk menyelesaikan secara detail.
Bila ada masalah yang kompleks, maka pemecahan masalah dilakukan dengan menggabungkan prosedur-prosedur yang ada menjadi satu kesatuan program guna menyelesaikan masalah tersebut, teknik ini dikenal dengan Teknik Bottom-Up yang sudah mulai ditinggalkan pemrogram karena kurang efektif.
2. Pemrograman Modular
Pada teknik top-down masalah yang besar dan kompleks dibagi-bagi kedalam kelompok masalah yang lebih kecil. Kelompok masalah yamg lebih kecil tersebut dinamakan modul. Satu modul akan mewakili satu rincian proses detail yang sudah mewakili media penyimpanan dan struktur data yang jelas.
Teknik pemrograman terstruktur yang digunakan untuk mengimplemetasikan langkah-langkah pemecahan masalah pada kelompok masalah yang kecil tersebut dinamakan teknik pemrograman modular.
Modul program didefinisikan sebagai sekumpulan instruksi yang memiliki operasi-operasi dan data yang didefinisikan; memiliki stuktur internal yang tidak tergantung pada subprogram yang lain, dan merupakan satu kesatuan yang utuh yang akan dieksekusi secara berulang-ulang.
3. Teorema Struktur / Struktur Kontrol
Perancangan program terstruktur tidak dipengaruhi oleh kelebihan dan keunggulan salah satu bahasa pemrograman yang sedang populer pada saat itu, namun lebih dipengaruhi oleh tiga teorema struktur / struktur kontrol yang akan digunakan. Karena pada dasarnya algoritma dari program yang telah terstuktur akan dapat ditransformasikan kedalam bahasa pemrograman dan jenis sistem informasi apa saja. Terdapat tiga teorema struktur yaitu:
  1. Struktur Urut
  2. Struktur Seleksi
  3. Struktur Repetisi/pengulangan.
============================================================================
PROSES DESAIN
Desain perangkat lunak adalah suatu proses interaktif yang melaluinya persyaratan diterjemahkan ke dalam suatu ‘cetak biru’ untuk membangun perangkat lunak. Pada dasarnya cetak biru menggambarkan suatu pandangan menyeluruh perangkat lunak, yaitu bahwa desain dapat dihadirkan pada tingkat abstraksi yang tinggi – tingkat yang dapat secara langsung ditelusuri sampai data spesifik, fungsional, dan persyaratan behavioral. Pada saat iterasi desain berjalan, penyaringan berikutnya membawa kepada representasi desain pada tingkat abstraksi yang jauh lebih rendah. Hal itu tetap dapat ditelusuri pada persyaratan, tetapi koneksi menjadi lebih halus.

1. Desain dan Kualitas Perangkat Lunak
2. Evolusi Desain Perangkat Lunak

Software design dibagi dalam 2 tahap :
1.Preliminary Design, Pada tahap ini difokuskan dengan transformasi dari keperluan/kebutuhan ke dalam data dan arsitektur software
2.Detail Design, Difokuskan pada penghalusan representasi arsitektur yang berisi struktur data detail dan algoritma untuk software.

Agar dihasilkan desain dengan kriteria yang baik, maka suatu desain haruslah :
1.Memperlihatkan organisasi hirarki yang mengontrol elemen-elemen software
2.Berkenaan dengan modul. Software secara logika terbagi dalam elemen-elemen yang membentuk fungsi dan sub fungsi
3.Berisi representasi yang berbeda dan terpisah dari data dan prosedur
4.Membentuk modul (contoh subroutine dan procedure) yang memperlihatkan karakteristik fungsi yang tidak saling bergantung
5.Diturun



PROSES PERANGKAT LUNAK

 Serangkaian kegiatan dan hasil yang berhubungan dengannya, yang menuju pada dihasilkannya produk perangkat lunak.
 Kegiatan-kegiatan mendasar yg umum bagi semua proses Perangkat Lunak :
1. Spesifikikasi Perangkat Lunak à Fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan.
2. Pengembangan (Perancangan dan Implementasi) Perangkat Lunak à Perangkat lunak yang memenuhi spesifikasi harus di produksi
3. Validasi Perangkat Lunak à Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak bekerja sesuai dengan apa yang diinginkan oleh pelanggan.
4. Evolusi Perangkat Lunak à Perangkat lunak harus berkembang untuk memenuhi kebutuhan pelanggan.
 =========================================================================

KONSEP DESAIN
  1. Abstraksi
Abstraksi memungkinkan desainer menentukan prosedur dan data, dan masih menekan detail tingkat rendah.
Terdapat 3 macam bentuk abstraksi, yaitu :
a. Abstraksi prosedural.
Merupakan urutan instruksi yang diberi nama yang mempunyai fungsi tertentu dan terbatas.
b. Abstraksi data.
Kumpulan data yang bernama yang menggambarkan obyek data.
c. Abstraksi kontrol.
Mengimplikasikan suatu mekanisme kontrol program tanpa menentukan detail-detail internal
  1. Penyaringan
Penyaringan stepwise (dengan serangkaian langkah) adalah strategi desain top-down yang diusulkan oleh Wiklaus Wirth. Kajian dari konsep tersebut adalah
“Pada setiap langkah (penyaringan), satu atau beberapa instruksi dari program yang diberikan didekomposisi ke dalam instruksi-instruksi yang lebih detail. Dekomposisi berurutan atau penyaringan spesifikasi berhenti bila semua instruksi diekspresikan dalam bentuk bahasa pemrograman atau komputer yang mendasar. Jika tugas-tugas disaring, maka data harus disaring juga, didekomposisi atau distruktur, dan adalah wajar untuk menyaring program dan spesifikasi data secara paralel” . Abstraksi dan penyaringan adalah konsep kompementer. Kedua konsep tersebut membantu desainer dalam menciptakan suatu model desain lengkap jika desain berkembang.
  1. Modularitas
Modularitas merupakan atribut tunggal dari perangkat lunak yang memungkinkan sebuah program untuk dikelola secara intelektual.
Meyer menyebutkan 5 kriteria yang memungkinkan kita untuk mengevaluasi suatu metode desain dengan merujuk pada kemampuannya untuk menentukan sistem modular yang efektif.
a. Dekomposisi modular.
b. Komposabilitas modular.
c. Kemampuan pemahaman modular.
d. Kontinuitas modular.
e. Proteksi modular.
  1. Arsitektur Perangkat Lunak
Arsitektur perangkat lunak mencakup “struktur keseluruhan perangkat lunak dan cara dimana struktur memberikan integrasi konseptual bagi suatu sistem”. Shaw dan Garlan menjelaskan sekumpulan properti yang seharusnya ditetapkan sebagai bagian dari desain arsitektural :
a. Properti struktural.
Menentukan komponen suatu sistem dan cara dimana komponen-komponen tersebut dikemas dan berinteraksi satu dengan yang lain.
b. Properti ekstra-fungsional.
Menekankan pada bagaimana arsitektur desain memenuhi persyaratan kinerja, kapasitas, reliabilitas, keamanan, adaptibilitas, dan karakteristik sistem yang lain.
c. Keluarga dari sistem yang berhubungan.
Desain harus memiliki kemampuan untuk memakai lagi blok bangunan arsitektural tersebut.
  1. Hirarki Kontrol
Hirarki kontrol, disebut juga struktur program merepresentasikan organisasi komponen program serta mengimplikasikan suatu hirarki kontrol. Hirarki kontrol tidak mengimplikasikan aspek prosedural dari perangkat lunak, seperti urutan proses, kejadian/urutan dari keputusan, atau pengulangan operasi.
  1. Partisi Struktural
Struktur progam harus dipartisi baik secara horizontal maupun vertikal.
Partisi horizontal menentukan cabang-cabang terpisah dari hirarki modular untuk setiap fungsi program mayor. Keuntungannya :
a. menghasilkan perangkat lunak yang lebih mudah diuji.
b. Membawa kepada perangkat lunak yang lebih mudah dipelihara.
c. Menghasilkan penyebaran efek samping yang lebih sedikit.
d. Menghasilkan suatu perangkat lunak yang lebih mudah untuk diperluas.
Partisi vertikal menyatakan bahwa kontrol dan kerja harus didistribusikan secara top-down dalam arsitektur program.
  1. Struktur Data
Struktur data adalah representasi dari hubungan logis antara elemen-elemen data individual.
  1. Prosedur Perangkat Lunak
Prosedur perangkat lunak berfokus pada detail-detail pemrosesan dari masing-masing modul secara individual. Prosedur harus memberikan spesifikasi yang teliti terhadap pemrosesan, mencakup urutan event, poin-poin keputusan nyata, operasi repetitif, dan organisasi struktur data.
  1. Penyembunyian Informasi
Prinsip penyembunyian informasi menyatakan bahwa bahwa modul ditandai dengan keputusan desain tersembunyi dari semua desain lain.
========================================================================

DESAIGN MODULAR AFEKTIF
1. Independensi fungsional
Merupakan hasil pertumbuhan langsung dari modularitas dan konsep abstraksi dan penyembunyian informasi.
Independensi fungsional dicapai dengan mengembangkan modul dengan fungsi “single-minded” dan suatu “aversi” ke interaksi eksesif dengan modul yang lain.
2. Kohesi
Kohesi adalah suatu ekstensi natural dari konsep penyembunyian informasi. Modul kohesi melakukan suatu tugas tunggal pada suatu prosedur perangkat lunak yang memerlukan sedikit interaksi dengan prosedur yang sedang dilakukan di bagian lain dari suatu program.
3. Perangkaian
Perangkaian adalah pengukuran interkoneksi diantara modul-modul pada sebuah struktur progam. Perangkaian tergantung pada kompleksitas interface diantara modul-modul, titik dimana entri atau referensi dibuat untuk sebuah modul dan data yang dilewatkan pada interface tersebut.

Desain Modular Efektif

Informasi yang disimpan: Modul-modul seharusnya dispesifikasi dan didesain sehingga detail internal dari modul darus dapat terlihat atau dapat diakses terhadap modul lainnya.

Keuntungan utama: mengurangi pengaruh perubahan pada testing(pengujian) dan maintenance(perawatan).

Independen fungsional: Mendesain modul-modul berdasarkan fitur fungsional independen.

Keuntungan utama: modularity efektif

Cohesion: sebuah ekstensi alami dari konsep informasi yang disimpan sebuah modul dapat menampilkan sejumlah tusk

Sebuah modul cohesive menampilkan sebuha task tunggal dalam sebuah prosedur dengan interaksi kecil dengan lainnya.

Goal: untuk mencapai cohesion yang tinggi untuk modul-modul pada sebuah sistem.

Tipe-tipe yang berbeda dari cohesion:
- coincidentally cohesive: sekumpulan task yang berhubungan satu sama lain secara bebas.
- logically cohesive: koneksi logical antara elemen-elemen pemrosesan
- communication cohesion: data di-share antar elemen-elemen pemrosesan - procedural cohesion: pemesanan antara elemen-elemen pemrosesan

Desain Modular Efektif

Coupling: (Gambar 13.8)
Suatu ukuran interkoneksi antar modul-modul dalam sebuah struktur program.
Coupling tergantung pada kompleksitas interface antar modul.

Goal: mencoba untuk coupling terendah yang mungkin antar modul.

Coupling yang baik à mengurangi atau mencegah pengaruh perubahan dan efek ripple.
à mengurangi biaya pada perubahan program, testing,
maintenance

Tipe-tipe coupling:

- data coupling: parameter passing atau interaksi data

- control coupling: share logical kontrol yang berhubungan (untuk sebuah data kontrol)

- common coupling: sharing data umum

- content coupling: modul, penggunaan data atau pengontrolan
informasi di-maintain modul lain. 

Desain modular afektif 

G. Modularitas Konsep modularitas dalam perangkat lunak komputer telah didukung selama hampir empat dekade. Arsitektur perangkat lunak memasukkan modularitas, dimana perangkat lunak dibagi ke dalam komponen-komponen bernama dan dapat dipanggil terpisah. Lima kriteria yang memungkinkan kita mengevaluasi suatu metode desain dengan merujuk pada kemampuannya untuk menentukan sistem modular yang efektif. Dekomposibilitas modular. Bila metode desain memberikan suatu mekanisme sistematis untuk melakukan dekomposisi terhadap masalah menjadi submasalah-submasalah, maka metode desain akan mengurangi kompleksitas keseluruhan masalah, sehingga dapat mencapai solusi modular efektif. Komposabilitas modular, bila suatu metode desain memungkinkan komponen-komponen desain (reusable) yang ada untuk dipasang ke dalam sebuah sistem baru, maka metode desain akan menghasilkan suatu solusi modular yang tidak berulang. Kemampuan pemahaman modular, jika sebuah modul dapat dipahami sebagai unit yang berdiri sendiri (tanpa referensi dari modul lain), maka modul akan lebih mudah dibangun dan diubah. Kontinuitas modular, Bila perubahan kecil pada persyaratan sistem menyebabkan perubahan kecil pada modul individual dan bukan perubahan sistem secara luas, maka pengaruh dari efek samping yang disebabkan oleh kesalahan oleh perubahan dapat diminimalkan. Proteksi modular, Bila terjadi kondisi yang menyimpang pada modul tersebut, pengaruh dari efek samping yang disebabkan oleh kesalahan akan diminimalkan. Akhirnya penting untuk dicatat bahwa suatu sistem dapat di desain secara modular, bahkan juga bila implementasinya harus “monolistik”. Ada situasi (misalnya perangkat lunak real time, perangkat lunak embedded) di mana kecepatan dan subrutin, prosedur) tidak dapat diterima. Dalam situasi seperti itu, perangkat lunak dapat dan harus dirancang dengan modularitas sebagai sebuah filosofi yang diprogram tidak kelihatan modular pada saat pertamanya, filosofi harus dijaga, dan program tersebut akan memberikan manfaat sistem modular. 
=========================================================================

HEURISTIK DESAIN BAGI MODULARITAS YANG EFEKTIF
1. Evaluasi “iterasi pertama” dari struktur program untuk mengurangi perangkaian dan meningkatkan kohesi.
2. Usahakan meminimalkan struktur dengan fan-out yang tinggi; usahakan untuk melakukan fan-in pada saat kedalaman (depth) bertambah.
3. Jagalah supaya lingkup efek dari suatu model ada dalam lingkup control.
4. Evaluasi interface modul untuk mengurangi kompleksitas dan redundansi.
5.Tetapkan modul-modul yang fungsinya dapat diprediksi, tetapi hindari modul yang terlalu restriktif.
6.Usahakan modul-modul “entri kontrol" dengan menghindari “hubungan patalogis”
7.Kemaslah software berdasarkan batasan desain dan persyaratan probabilitas.
=========================================================================

MODEL DESAIN
Prinsip dan konsep desain disini dimaksudkan membangun sebuah fondasi untuk pembuatan model desain yang mencakup representasi data, arsitektur, interface, dan prosedural. Seperti model analisis sebelumnya. Pada model desain, masing-masing representasi desain diikatkan dengan yang lainnya, dan semua dapat ditelusuri balik ke persyaratan perangkat lunak.
Banyak pemrogram terus menerus mendesain secara implisit, dengan melakukan desain prosedural pada saat dikodekan. Hal itu sama dengan mengambil desain piramid dan mendirikannya pada titiknya, hasil desain yang sangat tidak stabil. Perubahan yang paling kecil dapat menyebabkan piaramid tersebut (dan program) tumbang.

Model Proses Perangkat Lunak

A. Model air terjun (waterfall) à Biasa juga disebut siklus hidup perangkat lunak. Mengambil kegiatan dasar seperti spesifikasi, pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian dan seterusnya.
1. Analisis dan Definisi Persyaratan à Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user sistem.

2. Perancangan sistem dan Perangkat Lunak à Proses perancangan sistem membagi persyaratan dalam sistem perangkat keras atau perangkat lunak. Menentukan arsitektur sistem secara keseluruhan.

3. Implementasi dan pengujian unit à Perancangan perangkat lunak direalisasikan sebagai serangkaian program atau unit program. Pengujian unit melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasinya.
4. Integrasi dan Pengujian Sistem à Unit program atau program individual diintegrasikan dan diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem telah dipenuhi. Setelah pengujian sistem, PL dikirim ke User.

5. Operasi dan Pemeliharaan à Biasanya merupakan fase siklus yg paling lama (walaupun tidak seharusnya). Sistem diinstall dan di pakai.
Pemeliharaan mencakup koreksi dan berbagai error yg tdk ditemukan pada tahap2 sebelumnya, perbaikan atas implementasi unit sistem dan pengembangan pelayanan sistem.

=========================================================================

DOKUMENTASI DESAIN
Outline spesifikasi desain :
I. Ruang Lingkup
A. Sasaran Sistem
B. Persyaratan utama software
C. Batasan-batasan dan pembatasan desain

II. Desain Data
A. Obyek data dan struktur data resultan
B. Struktur file dan database
1. Struktur file eksternal
a.struktur logis
b.deskripsi record logis
c.metode akses
2. data global
3. file dan referensi lintas data

III. Desain Arsitektural
A. Kajian data dan aliran control
B. Struktur program yang diperoleh

IV. Desain Interface
A. Spesifikasi interface manusia-mesin
B. Aturan desain interface manusia-mesin
C. Desain interface eksternal
1. Interface untuk data eksternal
2. Interface untuk sistem atau peralatan eksternal

V. Desain Prosedural
Untuk masing-masing modul :
A. Naratif pemrosesan
B. Deskripsi Interface
C. Deskripsi bahasa (atau lainnya) desain
D. Modul-modul yang digunakan
E. Struktur data internal
F. Keterangan/larangan/pembatasan

VI. Persyaratan Lintas-Referensi

VII. Ketetentuan pengujian
1. Panduan pengujian
2. Strategi integrasi
3. Pertimbangan Khusus

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS

USE CASE

                                                       
           Sebuah use case adalah metodologi yang digunakan dalam analisis sistem untuk mengidentifikasi, memperjelas, dan mengatur persyaratan sistem. Kasus penggunaan terdiri dari satu set urutan yang mungkin dari interaksi antara sistem dan pengguna dalam lingkungan tertentu dan terkait dengan tujuan tertentu. Ini terdiri dari sekelompok elemen (misalnya, kelas dan interface) yang dapat digunakan bersama-sama dengan cara yang akan memiliki efek lebih besar daripada jumlah elemen yang terpisah digabungkan. Kasus penggunaan harus berisi kegiatan semua sistem yang memiliki signifikansi bagi pengguna. Sebuah use case dapat dianggap sebagai kumpulan skenario yang mungkin terkait dengan tujuan tertentu, memang, kasus penggunaan dan tujuan kadang-kadang dianggap sinonim.
Sebuah use case (atau set use case) memiliki karakteristik ini:
  • Mengatur kebutuhan fungsional
  • Model tujuan sistem / aktor (user) interaksi
  • Catatan jalan (disebut skenario) dari peristiwa pemicu untuk tujuan
  • Menjelaskan salah satu aliran utama peristiwa (juga disebut kursus dasar tindakan), dan mungkin yang lain, yang disebut arus yang luar biasa dari peristiwa (juga disebut kursus alternatif tindakan)
  • Apakah multi-level, sehingga satu use case dapat menggunakan fungsi satu lagi.
Gunakan kasus dapat digunakan selama beberapa tahap pengembangan perangkat lunak, seperti perencanaan kebutuhan sistem, memvalidasi desain, pengujian perangkat lunak, dan membuat garis besar untuk bantuan online dan manual pengguna.

Memulai dengan metodologi menggunakan kasus
Untuk menjelajahi bagaimana use case digunakan di perusahaan, berikut adalah beberapa sumber daya tambahan untuk belajar tentang metodologi use case:
Pro dan kontra dari diagram use case: Menempatkan terlalu banyak ke dalam diagram use case sering dapat membuat teknik lain yang berguna kasus penggunaan hampir tidak berguna. Kevlin Henney merekomendasikan pendekatan yang lebih seimbang dan terkendali agar tidak kehilangan pembaca dalam berbagai gelembung dan teks mikroskopis.
Dari diagram use case untuk diagram konteks : Ada godaan untuk mempertimbangkan menggunakan diagram kasus sebagai diagram konteks karena mereka melakukan konteks pertunjukan. Tapi memiliki satu diagram untuk kedua akan menghasilkan awan terbaca gelembung.
Lima perangkap kasus gunakan untuk menghindari: Mempekerjakan kasus penggunaan selama analisis persyaratan perangkat lunak membantu Anda meningkatkan kesempatan Anda untuk mengembangkan perangkat lunak yang benar-benar memenuhi kebutuhan mereka. Tapi ada perangkap Anda harus menghindari, kata pakar Karl E. Wiegers.

 =================================================

Deskripsi singkat tentang USE CASE
  •    Perilaku sistem adalah bagaimana sistem beraksi dan bereaksi. Perilaku ini merupakan aktifitas sistem yang bisa dilihat dari luar dan bisa diuji.
  • Perilaku sistem ini dicapture di dalam USE CASE. USE CASE sendiri mendeskripsikan sistem, lingkungan sistem, serta hubungan antara sistem dengan lingkungannya.
              Defenisi Use Case
  • Deskripsi dari sekumpulan aksi sekuensial yang ditampilkan sistem yang menghasilkan yang tampak dari nilai ke actor khusus. Use Case digunakan untuk menyusun behavioral things dalam sebuah model. Use case direalisasikan dengan sebuah collaboration. Secara gambar, sebuah use case digambarkan dengan sebuah ellips dengan garis penuh, biasanya termasuk hanya namanya.
  •  Representasi atau model yang digunakan dalam Rekayasa Perangkat Lunak untuk menggambarkanfungsional requirement suatu sistem.
  • Sekelompok skenario pengguna yang menggambarkan alur penggunaan sistem.
  • Setiap skenario digambarkan dari sudut pandang “aktor”, seseorang atau piranti yang berinteraksi dengan perangkat lunak dalam berbagai cara.
  •  Suatu Use Case adalah suatu sekuensial aksi yang dilakukan oleh sistem, yang akan secara bersama-sama, memproduksi hasil yang dibutuhkan oleh pengguna sistem. Use Case mendefinisikan alur proses sepanjang sistem berbasis pada kegunaan sebagaimana yang biasa dilakukan (secara manual).
Kegunaan Use Case adalah untuk menspesifikasikan konteks sistem, menggambarkan kebutuhan sistem, memvalidasikan arsitektur sistem, menjalankan implementasi dan meng-generate test case.

Include
Keterhubungan secara include antar use case menunjukkan bahwa use case asal secara eksplisit memasukkan perilaku dari use case lain yang ditunjuk oleh use case tersebut. Included use case tidak pernah berdiri sendiri, tetapi hanya merupakan bagian dari beberapa use case yang lebih besar yang diikutinya. Keterhubungan use case secara include pada dasarnya merupakan sebuah contoh dari pendelegasian - sekumpulan dari tanggung jawab sebuah sistem diambil dan ditangkap di dalam satu tempat (included use case) - kemudian bagian lainnya dari sistem (use case yang lain) memasukkan kumpulan tanggung jawab yang baru setiap saat mereka memerlukan fungsi-fungsi use case tersebut.

Extend
Keterhubungan use case secara extend menunjukkan bahwa use case yang ditunjuk merupakan perluasan perilaku dari use case asal. Use case asal dapat berdiri sendiri, tetapi untuk kondisi tertentu perilaku use case tersebut dapat diperluas oleh perilaku dari use case lain. Hubungan perluasan digunakan untuk memodelkan bagian dari use case yang dapat dilihat oleh user sebagai perilaku yang dapat dipilih dari sistem. Hubungan perluasan juga dapat digunakan untuk memodelkan sub aliran yang terpisah-pisah yang hanya dapat dijalankan dalam kondisi tertentu. Pada akhirnya, hubungan perluasan use case untuk memodelkan beberapa aliran yang dapat dimasukkan dalam titik tertentu.
  • Manfaat Model Use Case
Digunakan untuk berkomunikasi dengan end user dan domain expert
o    Menyediakan buy-in pada tahap awal pengembangan sistem.
o    Memastikan pemahaman yang tepat tentang requirement / kebutuhan sistem.
·         Digunakan untuk mengidentifikasi
o    Siapa yang berinteraksi dengan sistem dan apa yang harus dilakukan sistem.
o    Interface yang harus dimiliki sistem.
·         Digunakan untuk ferifikasi
o    Semua requirement yang telah dicapture.
o    Tim pengembang memahami requirement.

Macam-macam Use Case
  •   Narative Form
  • Bentuk teks bebas dalam format paragraph.
       Scenerio Form
Penjelasan penulisan use case dari sudut pandang actor.
  •  Conversation Form
Dialog antara actor dan sistem yang menunjukkan interaksi antar keduanya.

Format Penulisan Use Case
Tiap Use Case memiliki:
·         Precoditions, yang harus dipertemukan agar use cases dapat bekerja dengan sukses.
·         Postconditions, mendefinisikan kondisi-kondisi dimana use cases berakhir.
·         Postconditions mengidentifikasi hasil yang dapat diobservasi dan status akhir dari sistem setelah use case telah komplit.
·         Flow of events, yang mendefinisikan aksi pengguna dan respon sistem terhadap aksi yang dilakukan. Flow of events merupakan kompresi dari skenario normal, yang mendefinisikan tingkah laku umum dari sistem untuk use case, dan cabang-cabang alternatif, dimana bagian lain yang telah tersedia dapat digunakan oleh use case.
Use Case dan Test Cases akan bekerja dengan baik dalam dua cara, yaitu:
·         Jika use case dari sistem komplit, akurat dan jelas, maka pembuatan test cases dapat dilakukan secara langsung.
·         Jika use case tidak dalam kondisi yang baik, maka pembuata test cases akan membantu dalam melakukan debug terhadap test cases.
Modul Use Case
Mulai dengan kondisi atau kejadian normal biasa:
·         Acuhkan pengecualian, alternatif, dll.
·         Use case harus dinamai dan perspektif pengguna sebagai kata kerja aktif.
·         Menunjukkan deskripsi tujuan dari use case dan defenisi fungsionalitas tingkat
tinggi.



TAMBAHAN MENGENAI USE CASE DIAGRAM

USE CASE DIAGRAM
•Menggambarkan fungsionalitas yang diharapkan dari sebuah sistem.
Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”.
•Menggambarkan kebutuhan system dari sudut pandang user
•Mengfokuskan pada proses komputerisasi (automated processes)
•Menggambarkan hubungan antara use case dan actor
•Use case menggambarkan proses system (kebutuhan system dari sudut pandang user)
•Secara umum use case adalah:
   –Pola perilaku system
   –Urutan transaksi yang berhubungan yang dilakukan oleh satu actor
•Use case diagram terdiri dari
   –Use case
   –Actors
   –Relationship
   –System boundary boxes (optional)
   –Packages (optional)

USE CASE
• Use case dibuat berdasar keperluan actor, merupakan “apa” yang dikerjakan system, bukan “bagaimana”   system mengerjakannya
• Use case diberi nama yang menyatakan apa hal yang dicapai dari hasil interaksinya dengan actor.
• Use case dinotasikan dengan gambar (horizontal ellipse)
• Use case biasanya menggunakan kata kerja
• Nama use case boleh terdiri dari beberapa kata dan tidak boleh ada 2 use case yang memiliki nama yang sama

ACTOR
• Actor menggambarkan orang, system atau external entitas / stakeholder yang menyediakan atau menerima informasi dari system
• Actor menggambarkan sebuah tugas/peran dan bukannya posisi sebuah jabatan
• Actor memberi input atau menerima informasi dari system
• Actor biasanya menggunakan Kata benda
• Tidak boleh ada komunikasi langsung antar actor
• Indikasi <<system>> untuk sebuah actor yang merupakan sebuah system
• Adanya actor bernama “Time” yang mengindikasikan scheduled events (suatu kejadian yang terjadi secara periodik/bulanan)
• Letakkan actor utama anda pada pojok kiri atas dari diagram

ASSOCIATION

• Associations bukan menggambarkan aliran data/informasi
• Associations digunakan untuk menggambarkan bagaimana actor terlibat dalam use case
• Ada 4 jenis relasi yang bisa timbul pada use case diagram
   1. Association antara actor dan use case
   2. Association antara use case
   3. Generalization/Inheritance antara use case
   4. Generalization/Inheritance antara actors


ASSOCIATION ANTARA ACTOR DAN USE CASE

• Ujung panah pada association antara actor dan use case mengindikasikan siapa/apa yang meminta interaksi dan bukannya mengindikasikan aliran data
• Sebaiknya gunakan Garis tanpa panah untuk association antara actor dan use case
• association antara actor dan use case yang menggunakan panah terbuka untuk mengindikasikan bila actor berinteraksi secara pasif dengan system anda
 
ASSOCIATION ANTARA USE CASE (LANJUT)
• <<extend>> perluasan dari use case lain jika kondisi atau syarat terpenuhi
– Kurangi penggunaan association Extend ini, terlalu banyak pemakaian association ini membuat diagram sulit dipahami.
– Tanda panah terbuka harus terarah ke parent/base use case
– Gambarkan association extend secara vertical
                                                                        
GENERALIZATION/INHERITANCE ANTARA ACTOR
• Gambarkan generalization/inheritance antara actors secara vertical dengan inheriting actor dibawah base/parent use case



USE CASE SYSTEM BOUNDARY BOXES

• Digambarkan dengan kotak disekitar use case, untuk menggambarkan jangkauan system anda (scope of of your system).
• Biasanya digunakan apabila memberikan beberapa alternative system yang dapat dijadikan pilihan
• System boundary boxes dalam penggunaannya optional


Contoh Kasus Usecase

CONTOH KASUS USE CASE PADA GALLERY VCD
VCD House adalah sebuah gallery yang bergerak di bidang retail dan menjual produk-produk hiburan seperti VCD,DVD,CD playstation, accessories dan lain-lain. VCD house saat ini mempunyai beberapa cabang yang tersebar diberbagai mal di Jakarta dan bekasi.
Pada setiap cabang, VCD house menemparkan 2 orang petugas untuk menjaga tokonya. Biasanya kedua orang ini bertugas secara bergiliran dengan system shift. Untuk mengendalikan keseluruhan cabangnya, pemilik VCD House mempekerjakan 2 or ang bagian keuangan, 3 orang bagian pengontrolan stok dan 3 orang supervisor.
Proses penjualan dimulai saat seorang pelanggan menanyakan tentang suatu produk kepada petugas toko. Oleh petugas toko, permintaan tersebut akan ditulis dalam bentuk bon. Selanjutnya atas dasar bon tersebut, petugas toko akan mengecek dan mengambil barang yang dipesan. Bilamana barang tidak ada atau jumlah permintaan tidak sesuai, petugas akan bertanya kepada pelanggan apakah transaksi akan tetap dilakukan. Bila transaksi tetap dilakukan dengan cara mengambil barang jenis lain atau mengubah jumlah barang yang dipesan, maka petugas akan melaporkan perhitungan pembayaran. Saat pembayaran dilakukan petugas akan menanyakan kembali kategori pembayaran yang akan dilakukan oleh pelanggan. Pembayaran bisa dilakukan secara tunai(cash) , dengan kartu kredit atau dengan kartu debit. Jika pembayaran dilakukan secaraa tunai, transaksi akan langsung dicatat pada buku penjualan. Namun bila dilakukan dengan kartu kredit atau kartu debit, akan dilakukan otorisasi terlebih dahulu dengan mesin otorisasi yang telah disediakan oleh bank. Setelah semua prose situ selesai, barula proses penjualan itu dicatat di buku penjualan

  • Digg
  • Del.icio.us
  • StumbleUpon
  • Reddit
  • RSS