Assalam'mualaikum Wr.Wb

 Puji syukur kehadirat Allah SWT yang karena anugerah dari-Nya kami dapat menyelesaikan tuga tentang "membuat use case dengan mengunakan miscrosoft visio" ini. Sholawat dan salam semoga senantiasa tercurahkan kepada junjungan besar kita, yaitu Nabi Muhammad SAW yang telah menunjukkan kepada kita jalan yang lurus berupa ajaran agama Islam yang sempurna dan menjadi anugerah serta rahmat bagi seluruh alam semesta.

1.DFD menggunakan microsoft visio 2007

Diagram Use Case menggunakan Aplikasi Microsoft Visio

Assalam'mualaikum

berikut ini adalah contoh study kasus membuat Use Case

Membuat Use Case dengan studi kasus :

1.  Sistem Informasi Koperasi
2.  Sistem Informasi Akademik
3.  Sistem Informasi POS (Point Of Sales)

Berikut ini Diagram Use Case menggunakan Aplikasi Microsoft Visio :

1.  Sistem Informasi Koperasi

                                                      1.Sistem Informasi Koperasi

2.Sistem Informasi Akademik

3.Sistem Informasi POS (Point Of Sales)

Extreme Programming

Extreme Programming

Extreme Programming (berikutnya akan disingkat sebagai XP) adalah sebuah pendekatan atau model pengembangan perangkat lunak yang mencoba menyederhanakan berbagai tahapan dalam proses pengembangan tersebut sehingga menjadi lebih adaptif dan fleksibel. XP bukan hanya berfokus pada coding tetapi meliputi seluruh area pengembangan perangkat lunak.
XP mengambil pendekatan ‘ekstrim’ dalam iterative development.

Sejarah XP

Extreme Programming diciptakan oleh Kent Beck selama Ia bekerja di proyek Chrysler Comprehensive Compensation (C3). Beck menjadi pemimpin proyek C3 pada bulan Maret 1996 dengan mulai memperbaiki metodologi pengembangan yang digunakan dalam proyek penggajian 10.000 karyawan Chrysler, yang terdiri dari kira-kira 2000 class dan 30.000 method.  Beck juga menulis sebuah buku tentang metodologi <i>Extreme Programming Explained</i> yang diterbitkan (bulan Oktober 1999. Kemudian Chrysler membatalkan proyek C3 pada bulan Februari 2000, setelah 7 tahun, ketika perusahaan ini diakuisisi oleh Daimler-Benz.

Aspek Dasar XP

Aspek dasar XP terdiri dari berbagai teknik atau metode yang diterapkan Beck dan Jeffries pada C3 Project. Teknik-teknik tersebut antara lain:

• Whole Team
  Seluruh kontributor dalam proyek yang menggunakan pendekatan XP duduk bersama sebagai suatu tim. Tim ini terdiri beberapa peran, antara lain programmer, penguji,orang yang mengerti bisnis, analis, manajer, dan lain-lain. Setiap peran yang ada tidak mutlak menjadi peran dari satu orang saja. Tim terbaik dalam XP tidak harus memiliki pakar, hanya kontributor umum dengan keterampilan khusus saja. Semua orang di tim XP memberikan kontribusi dengan cara apapun yang mereka dapat lakukan.

• Planning game
  Perencanaan dalam XP mengemukakan dua pertanyaan kunci dalam pengembangan perangkat lunak, yaitu  memprediksi apa yang akan dicapai pada waktu tertentu, dan menentukan apa yang harus dilakukan setelah itu. Ada dua langkah kunci dalam perencanaan XP, yang menangani dua pertanyaan tersebut:
  Release Planning yaitu praktek dimana Customer mengutarakan fitur yang diinginkannya ke programer, dan programer memperkirakan tingkat kesulitannya. Dengan estimasi biaya di tangan, dan dengan pengetahuan tentang pentingnya fitur yang diinginkan, Pelanggan meletakkan satu rencana untuk proyek tersebut. Rencana rilis awal yang selalu tepat: baik prioritas maupun perkiraan yang benar-benar solid, dan sampai tim mulai bekerja, kita tidak akan tahu seberapa cepat mereka akan pergi. Bahkan rencana rilis pertama cukup akurat untuk pengambilan keputusan, namun, dan tim XP melakukan revisi terhadap rencana rilis secara teratur.
  Iteration Planning adalah praktek di mana tim diberikan petunjuk atau arahan setiap beberapa minggu sekali. Tim XP membangun perangkat lunak dalam “iterasi” dua minggu, memberikan menjalankan perangkat lunak yang berguna pada setiap akhir iterasi. Selama Iteration Planning, Customer mengutarakan fitur yang diinginkan selama dua minggu ke depan. Para programer memecahnya ke dalam pekerjaan yang lebih kecil, dan memperkirakan biaya yang diperlukan.

• Customer Tests
  Sebagai bagian dari presentasi masing-masing fitur yang diinginkan, Customer XP mendefinisikan satu atau lebih  tes penerimaan otomatis untuk menunjukkan bahwa fitur tersebut bekerja dengan baik. Tim membangun tes ini dan menggunakannya untuk membuktikan pada kepada Customer bahwa fitur ini telah diimplementasikan dengan benar. Tes secara otomatis ini penting karena dalam XP hanya diberikan waktu yang singkat sehingga tes manual tidak akan digunakan karena memakan waktu yang lama.

• Small Release
  Pada setiap Iterasi, tim mengerjakan sebuah unit atau bagian dari perangkat lunak, melakukan tes terhadap unit perangkat lunak yang dibangun, kemudian di akhir iterasi perangkat lunak yang dibangun diberikan kepada Customer. Oleh customer, perangkat lunak ini bisa dijadikan bahan evaluasi maupun langsung dirilis kepada end user. Bisa juga tim XP langsung merilis ke end user secara rutin.

• Simple Design
  Tim XP membangun perangkat lunak dengan desain yang sederhana. Dimulai dengan desain yang sederhana, kemudian melalui pengujian program dan perbaikan desain. Desain yang dibuat harus benar-benar cocok untuk fungsi saat ini dari sistem sehingga tidak ada yang sia-sia dan perangkat lunak siap dikembangkan lagi selanjutnya. Namun, pembuatan desain dalam XP tidak dilakukan hanya sekali. Tahapan desain dalam Extreme Programming yang menghasilkan desain yang bagus dianggap sangat penting, sehingga selama proses development banyak difokuskan ke tahapan desain.

•  Pair Programming
  Semua perangkat lunak yang dibangun dengan pendekatan XP dibangun oleh dua orang programmer. Keduanya duduk berdampingan di satu komputer yang sama. Seorang programmer akan membuat code dan programmer yang lainnya akan mengoreksinya. Praktik seperti ini mungkin kelihatan tidak efisien. Namun dari segi hasil dari pair programming, desain akan lebih baik, pengujian lebih baik, dan code yang dihasilkan pun akan lebih baik.

• Test-Driven Development
  XP begitu terobsesi dengan umpan balik, dan dalam pengembangan perangkat lunak, umpan balik yang baik mensyaratkan pengujian yang baik pula. Test-Driven Development bergantung pada pengulangan siklus development yang sangat pendek. Pertama tim XP akan menuliskan automated test case yang mendefinisikan perbaikan yang diinginkan atau fungsi baru. Kemudian dari test case tersebut dihasilkan jumlah minimal code yang harus dituliskan untuk lulus tes tersebut. Setelah itu melakukan refactoring code baru agar memenuhi standar baru.

• Design Improvement
  XP berfokus pada memberikan nilai bisnis dalam setiap perulangan. Agar dapat mencapai tujuan tersebut selama proyek berlangsung, perangkat lunak harus dirancang dengan baik. XP menggunakan proses perbaikan desain secara terus menerus dengan Refactoring. Proses refactoring berfokus pada penghapusan duplikasi dari code yang telah dibuat. Disamping itu, proses refactoring didukung dengan pengujian yang komprehensif utnuk memastikan bahwa desain yang dibuat berkembang dan tiidak ada yang rusak.

• Continuous Integration
  Beberapa kali dalam sehari, tim XP akan menggabungkan seluruh salinan pekerjaan tim menjadi satu dalam jaringan utama. Sehingga tim XP harus menjaga tim agar terintegrasi setiap saat.

• Collective Code Ownership
  Pada proyek XP, setiap pasang programmer dapat meningkatkan code apapun setiap saat. Semua code yang ada dimiliki secara kolektif oleh tim. Manfaatnya setiap code akan mendapat perhatian dari banyak orang, sehingga dapat meningkatkan kualitas code dan mengurangi cacat. Selain itu dapat mengurangi duplikasi code yang sama walaupun dibuat oleh pasangan programmer yang berbeda.

• Coding Standard
  Setiap anggota tim XP harus mengikuti standar coding yang umum, sehingga semua code dalam sistem seolah-olah tampak dibuat oleh satu orang yang sangat kompeten. Selain itu hal ini sangat mendukung Collective Code Ownership.

• Metaphor
  Tim XP akan membuat suatu deskripsi umum bagaimana program yang mereka kembangkan bekerja dengan benar.

• Sustainable Pace
  Tim XP akan bekerjasama dalam jangka waktu lama. Mereka bekerja keras dengan kecepatan tertentu tanpa batas waktu. Tim XP akan bekerja lembur pada hari efektif dan memaksimalkan produktivitas setiap minggunya.  Hal ini perlu diperhatikan dengan baik, karena akan mengurangi produktivitas atau sebaliknya menghasilkan perangkat lunak yang berkualitas.

Referensi:

• http://www.znu.ac.ir/members/afsharchim/T&M/xp.htm
• Wikipedia
• IlmuKomputer.com

RUP (Rational Unified Process)

Menelusuk Pengertian RUP (Rational Unified Process)

1 Votes

Pengertian RUP

Apa sebetulnya RUP itu? Berdasarkan buku Agility and Discipline Made Easy: Practices from OpenUP and RUP, RUP merupakan framework proses yang banyak diadopsi dan digunakan oleh puluhan ribu proyek mulai dari tim dengan dua anggota hingga tim dengan ratusan anggota, pada berbagai industri di seluruh dunia. RUP bercabang, salah atunya adalah EPF (Eclipse Process Framework) dengan sebuah volume tambahan konten proses yang besar, memungkinkan tim pengembangan untuk mengukur proses mereka untuk melakukan hal berikut:

• Melakukan distribusi atau pengembangan skala besar yang membutuhkan lebih banyak serangkaian aturan, seperti persyaratan traceability, model analisis, model-driven architecture (MDA), atau pengujian beban dan kinerja secara komprehensif.
• Mengembangkan sistem yang menggunakan alat IBM, memberikan panduan khusus tentang teknologi yang relevan seperti J2EE dan .NET, dan menggunakan IBM beserta turunan-turunan atau keluarganya.
• Mengembangkan sistem yang mengikuti standar industri seperti ISO 9001, SEI CMMI, atau SOX.
• Mengatur proses berorientasi projek menjadi proses enterprise, seperti program dan portofolio manajemen; rekayasa sistem; penggunaan ulang enterprise; pemodelan bisnis dan simulasi; atau SOA berskala enterprise.

Dalam buku Software Engineering for Small Project disebutkan bahwa salah satu keuntungan nyata penggunaan RUP adalah fleksibel.

Pada bukunya Gary menyebutkan pendekatan RUP adalah dengan memikirkan artefak (requirements, tests, code, dan seterusnya) yang dibutuhkan oleh projekt, lalu mempertimbangkan apa aktivitas untuk melakukan pembuatan artefak tersebut. Sebuah kunci utama yang perlu dingat adalah, bahwa tujuannya adalah untuk membangun software, bukan membuat artefak.

Berikut adalah artefak dasar yang kita percaya setiap tim membutuhkannya:

• Sebuah Visi. Hal ini membantu tim proyek memahami untuk membangun apa dan kemudian membantu mereka tahu kapan mereka selesai membangun itu.
• Sebuah Daftar Risiko. Apa resiko yang sebenarnya Anda hadapi dan bagaimana Anda akan menanggulanginya? Ketika Anda berpikir tentang risiko, pertimbangkan elemen ini proyek Anda: orang, proses, dan alat-alat.
• Masalah Pengembangan. Ini menjelaskan bagaimana Anda akan beradaptasi RUP dengan kebutuhan Anda. Salah satu bagian penting dari kasus pembangunan adalah bahwa ia menjelaskan tanggung jawab masing-masing peran yang berbeda pada proyek.
• Use Case. Ini mendefinisikan serangkaian interaksi antara sistem dan aktor (biasanya seorang pengguna) yang menghasilkan hasil yang dapat diamati dari nilai.
• Seperangkat Tes yang Baik. Jika Anda menggunakan RUP, maka Anda dapat mulai menghasilkan tes segera setelah Anda menyelesaikan use case pertama Anda.
• Sebuah Arsitektur. Ini mungkin sangat informal. Beberapa kelompok merilis versi pertama mereka tanpa arsitektur formal, maka (dengan asumsi sukses) ketika mereka sedang merencanakan versi kedua, mereka mulai dengan mendokumentasikan arsitektur sejauh ini dan bagaimana mengembangkannya.
• Sebuah Rencana Proyek. Perencanaan ini harus menguraikan iterasi dan jadwal. Desainlah iterasi agar Anda mengatasi item risiko utama selama fase Elaborasi (salah satu dari empat fase RUP). Ini akan membantu Anda mengurangi kemungkinan kejutan teknis atau pekerjaan ulang yang tak terduga di akhir proyek
• Sebuah Glosarium. Glosarium harus berisi definisi untuk menjaga bahasa tim Anda konsisten, proyek yang luas. Jika tim, termasuk pelanggan Anda dan semua pemangku kepentingan, yang akrab dengan domain dan semua hal yang mungkin Anda gunakan saat bekerja pada proyek, Anda mungkin tidak perlu menulis glosarium.

Diagram Iterasi RUP

Berbeda halnya pada buku The Rational Unified Process: An Introduction (2nd Edition),  Rational Unified Process adalah proses rekayasa perangkat lunak. RUP menyediakan pendekatan disiplin untuk menetapkan tugas dan tanggung jawab dalam pengembangan organisasi. Tujuannya adalah untuk memastikan produksi perangkat lunak berkualitas tinggi yang memenuhi kebutuhan pengguna akhir pada jadwal dan anggaran yang dapat diprediksi.

Rational Unified Process adalah sebuah proses poduk. Hal ini dikembangkan dan dikelola oleh Rational Software dan terintegrasi dengan seperangkat  alat pengembangan perangkat lunak. Perangkat ini tersedia pada CD-ROM Software Rational atau melalui internet. Rational Unified Process juga sebuah framework proses yang dapat disesuaikan dan dikembangkan sesuai dengan kebutuhan adopsi organisasi.

RUP Online

Phase RUP

RUP menguraikan empat fase (Inception, Elaboration, Construction dan Transition) yang mana sebuah projek melaluinya. Fase Inception adalah tentang menciptakan visi, mengembangkan kasus bisnis, dan prototipe software atau solusi parsial agar orang mengusahakannya mendapat dukungan dan pendanaan. Fase Elaboration berakhir dengan eksekusi arsitektur di mana keputusan arsitektur utama telah dibuat dan risiko telah dikurangi. Eksekusi arsitekur software menunjukkan sebuah implementasi dari kunci keputusan arsitektur. Fase Constrction adalah tentang mengisi fungsi yang diidentifikasi dalam arsitektur, dan fase Transition berfokus pada penyampaian software untuk para penggunanya.

RUP Hump Chart

Tahapan dibagi menjadi iterasi. Iterasi adalah “time-boxed” dan memiliki tujuan tertentu. Iterasi disimpan sesingkat mungkin, tapi cukup lama bagi Anda untuk menerapkan kelengkapan use case atau skenario use case yang memberikan nilai nyata bagi pengguna. Pada akhir setiap iterasi, Anda memegang penilaian di mana Anda menyesuaikan rencana untuk iterasi mendatang, berdasarkan hasil dari iterasi saat ini. Selama penilaian, tim Anda juga mencerminkan tentang manfaat proses dan penyesuaian seperlunya. RUP adalah tentang menciptakan visi dari apa yang Anda inginkan, menciptakan kerangka kerja untuk mencapai visi tersebut, dan menilai di poin yang diberikan apakah Anda mencapai sesuai dengan yang direncanakan.

Kesimpulan

RUP merupakan proses bahkan framework proses pada pengembangan perangkat lunak, dan siklus hidup pengembangan software (SDLC) dilakukan secara iterasi dengan menggunakn empat fase (Inception, Elaboration, Construction dan Transition). RUP sangat fleksibel, tetapi anda harus memenuhi kriteria-kitera tertentu sebagaimana dijelaskan di atas untuk dapat mengadopsi RUP di perusahaan anda sehingga mampu mencapai visi yang direncakan pada awal fase.

Referensi

Kruchten, P. (2000). The Rational Unified Process: An Introduction (2nd Edition). Vancouver: Addison-Wesley Professional. MacIsaac, B., & Kroll, P. (2006). Agility and Discipline Made Easy: Practices from OpenUP and RUP. Addison Wesley Professional. Madhur, J., Lowe, C., Augustine, L., & Pollice , G. (2003). Software Development for Small Teams: A RUP-Centric Approach. Boston: Addison-Wesley Professional.

RAD (Rapid Application Development)

Rekayasa Perangkat Lunak (Rapid Application Development (RAD))

Rapid Application Development (RAD) adalah strategi siklus hidup yang ditujukan untuk menyediakan pengembangan yang jauh lebih cepat dan mendapatkan hasil dengan kualitas yang lebih baik dibandingkan dengan hasil yang dicapai melalui siklus tradisional (McLeod, 2002). RAD merupakan gabungan dari bermacam-macam teknik terstruktur dengan teknik prototyping dan teknik pengembangan joint application untuk mempercepat pengembangan sistem/aplikasi (Bentley, 2004). Dari definisi-definisi konsep RAD ini, dapat dilihat bahwa pengembangan aplikasi dengan menggunakan metode RAD ini dapat dilakukan dalam waktu yang relatif lebih cepat.

Pemaparan konsep yang lebih spesifik lagi dijelaskan oleh Pressman (2005) dalam bukunya, “Software Engineering: A Practition’s Approach”. Ia mengatakan bahwa RAD adalah proses model perangkat lunak inkremental yang menekankan siklus pengembangan yang singkat. Model RAD adalah sebuah adaptasi “kecepatan tinggi” dari model waterfall, di mana perkembangan pesat dicapai dengan menggunakan pendekatan konstruksi berbasis komponen. Jika tiap-tiap kebutuhan dan batasan ruang lingkup projek telah diketahui dengan baik, proses RAD memungkinkan tim pengembang untuk menciptakan sebuah “sistem yang berfungsi penuh” dalam jangka waktu yang sangat singkat. Dari penjelasan Pressman (2012) ini, satu perhatian khusus mengenai metodologi RAD dapat diketahui, yakni implementasi metode RAD akan berjalan maksimal jika pengembang aplikasi telah merumuskan kebutuhan dan ruang lingkup pengembangan aplikasi dengan baik.

Sedangkan menurut Kendall (2010), RAD adalah suatu pendekatan berorientasi objek terhadap pengembangan sistem yang mencakup suatu metode pengembangan serta perangkat-perangkat lunak. RAD bertujuan mempersingkat waktu yang biasanya diperlukan dalam siklus hidup pengembangan sistem tradisional antara perancangan dan penerapan suatu sistem informasi. Pada akhirnya, RAD sama-sama berusaha memenuhi syarat-syarat bisnis yang berubah secara cepat.

Siklus RAD

(Sumber: Kendall, 2010)

Fase dan Tahapan Pengembangan Aplikasi

Menurut Kendall (2010), terdapat tiga fase dalam RAD yang melibatkan penganalisis dan pengguna dalam tahap penilaian, perancangan, dan penerapan. Adapun ketiga fase tersebut adalah requirements planning (perencanaan syarat-syarat), RAD design workshop (workshop desain RAD), dan implementation (implementasi). Sesuai dengan metodologi RAD menurut Kendall (2010), berikut ini adalah tahap-tahap pengembangan aplikasi dari tiap-tiap fase pengembangan aplikasi.

1)      Requirements Planning (Perencanaan Syarat-Syarat)

Dalam fase ini, pengguna dan penganalisis bertemu untuk mengidentifikasikan tujuan-tujuan aplikasi atau sistem serta untuk megidentifikasikan syarat-syarat informasi yang ditimbulkan dari tujuan-tujuan tersebut. Orientasi dalam fase ini adalah menyelesaikan masalah-masalah perusahaan. Meskipun teknologi informasi dan sistem bisa mengarahkan sebagian dari sistem yang diajukan, fokusnya akan selalu tetap pada upaya pencapaian tujuan-tujuan perusahaan (Kendall, 2010).

2)      RAD Design Workshop (Workshop Desain RAD)

Fase ini adalah fase untuk merancang dan memperbaiki yang bisa digambarkan sebagai workshop. Penganalisis dan dan pemrogram dapat bekerja membangun dan menunjukkan representasi visual desain dan pola kerja kepada pengguna. Workshopdesain ini dapat dilakukan selama beberapa hari tergantung dari ukuran aplikasi yang akan dikembangkan. Selama workshopdesain RAD, pengguna merespon prototipe yang ada dan penganalisis memperbaiki modul-modul yang dirancang berdasarkan respon pengguna. Apabila sorang pengembangnya merupakan pengembang atau pengguna yang berpengalaman, Kendall menilai bahwa usaha kreatif ini dapat mendorong pengembangan sampai pada tingkat terakselerasi (Kendall, 2010).

3)      Implementation (Implementasi)

Pada fase implementasi ini, penganalisis bekerja dengan para pengguna secara intens selama workshop dan merancang aspek-aspek bisnis dan nonteknis perusahaan. Segera setelah aspek-aspek ini disetujui dan sistem-sistem dibangun dan disaring, sistem-sistem baru atau bagian dari sistem diujicoba dan kemudian diperkenalkan kepada organisasi (Kendall, 2010).

Kelebihan dan Kekurangan RAD

Metode pengembangan sistem RAD relatif lebih sesuai dengan rencana pengembangan aplikasi yang tidak memiliki ruang lingkup yang besar dan akan dikembangkan oleh tim yang kecil. Namun, RAD pun memiliki kelebihan dan kekurangannya sebagai sebuah metodoligi pengembangan aplikasi. Berikut ini adalah kelebihan metodologi RAD menurut Marakas (2006):

1. Penghematan waktu dalam keseluruhan fase projek dapat dicapai.
2. RAD mengurangi seluruh kebutuhan yang berkaitan dengan biaya projek dan sumberdaya manusia.
3. RAD sangat membantu pengembangan aplikasi yang berfokus pada waktu penyelesaian projek.
4. Perubahan desain sistem dapat lebih berpengaruh dengan cepat dibandingkan dengan pendekatan SDLC tradisional.
5. Sudut pandang user disajikan dalam sistem akhir baik melalui fungsi-fungsi sistem atau antarmuka pengguna.
6. RAD menciptakan rasa kepemilikan yang kuat di antara seluruh pemangku kebijakan projek.

Sedangkan, mengacu pada pendapat Kendall (2010), maka dapat diketahui bahwa kekurangan penerapan metode RAD adalah sebagai berikut:

1. Dengan metode RAD, penganalisis berusaha mepercepat projek dengan terburu-buru.
2. Kelemahan yang berkaitan dengan waktu dan perhatian terhadap detail. Aplikasi dapat diselesaikan secara lebih cepat, tetapi tidak mampu mengarahkan penekanan terhadap permasalahan-permasalahan perusahaan yang seharusnya diarahkan.
3. RAD menyulitkan programmer yang tidak berpengalaman menggunakan prangkat ini di mana programmer dan analystdituntut untuk menguasai kemampuan-kemampuan baru sementara pada saat yang sama mereka harus bekerja mengembangkan sistem.

Referensi:

1.      Mc.,Leod, R. Jr. 2002. System Development: A Project Management Approach. New York: Leigh Publishing LLC.

2.      Whitten, J.L. & Bentley, L.D. 2004. System Analysis & Design Methods: Sixth Edition. New York: Mc.Graw-Hill.

3.      Pressman, R.S. 2012. Rekayasa Perangkat Lunak: Pendekatan Praktisi. Yogyakarta: Penerbit Andi.

4.      Marakas, G.M. 2006. System Analysis Design: an Active Approach. New York: Mc.Graw-Hill.

5.      Kendall, J.E. & Kendall, K.E. 2010. Analisis dan Perancangan Sistem. Jakarta: Indeks.