Tugas RPL

Model Waterfall

Sejarah Model Waterfall

            Model Waterfall ini awalnya ditemukan oleh Winston W. Royce pada tahun 1970 . Dia menulis sebuah artikel ilmiah yang berisi pandangan pribadinya pada pengembangan perangkat lunak . Pada paruh pertama dari artikel, ia membahas sebuah proses yang dia sebut ” megah ” . Dia bahkan menggambar sosok model , dan lain yang menunjukkan mengapa hal itu tidak bekerja ( karena persyaratan selalu berubah ) . Model ini adalah air terjun . Dia menggunakannya sebagai contoh dari proses yang sama sekali tidak bekerja. Di paruh kedua artikel ia menggambarkan proses berulang-ulang bahwa ia dianggap jauh lebih baik .
Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan urut mulai dari level kebutuhan sistem lalu menuju ke tahap analisis, desain, coding, testing / verification, dan maintenance. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan. Sebagai contoh tahap desain harus menunggu selesainya tahap sebelumnya yaitu tahap requirement.

Pengertian Waterfall

            Waterfall atau sering juga disebut air terjun adalah sebuah metode dalam pengembangan sistem yang dilakukan untuk membuat pembaruan sistem yang berjalan.

            Menurut Buku Rosa Metode pengembangan sistem merupakan proses mengembangkan atau mengubah suatu sistem perangkat lunak dengan menggunakan metode-metode atau model-model yang digunakan orang untuk mengembangkan sitem-sistem perangkat lunak sebelumnya dengan memiliki alur hidup perangkat lunak secara sekuensial atau terurut dimulai dari analisis, desain, pengodean, pengujian, dan tahap pendukung (support).
            Dan untuk gambarannya dapat di ilustrasikan seperti gambar berikut ini :

            DesainPengodeanPengujianAnalisisSistem/Rekayasa Informasi

Penjelasan Alur Metode Waterfall

Analisis

            Analisis atau analisa ini merupakan tahap awal yang dilakukan oleh peneliti dalam mengembangkan sistem. Dalam analisis ini harus mendapatkan beberapa hal yang dianggap menunjang penelitian yang dilakukan, seperti : mencari permasalahan yang ada, mengumpulkan data (data fisik, non fisik), wawancara dan lain-lain. Dalam tahap awal ini penulis dituntut untuk benar-benar melakukan penelitian yang terarah seperti contohnya untuk penelitian Teknik Informatika.

            Untuk menentukan pokok permasalahan peneliti harus memilih terlebih dahulu permasalahan globalnya (misal : Jaringan), kemudian membagi lagi menjadi beberapa sub kecil (misal : pengiriman paket data), dan membagi kembali hingga tertuju pada titik fokus (misal : enkripsi data). 

Desain

            Desain yang dimaksud bukan hanya tampilan atau interfacenya saja, tetapi yang dimaksud desain dalam metode ini adalah desain sistem yang meliputi : alur kerja sistem, cara pengoprasian sistem, hasil keluaran (output) dengan menggunakan metode-metode seperti UML (Unified Modeling Language) tampilan sistem dan lain-lain yang telah disesuaikan dengan analisis kebutuhan pada tahap awal untuk menyelesaikan permasalahan tersebut

            Sehingga programmer atau pihak yang terlibat dalam pembuatan kode programs akan dipermudah karena sudah terarah seperti apa sistem ini akan berjalan dan seperti apa alur yang ada didalam sistem maupun diluar sistem. Contoh desain sistem salah satunya adalah seperti Artikel saya yang berikut ini : Pengertian dan Contoh Class Diagram dengan Edraw max

Pengodean

            Bagian pengodean merupakan bagian para programmer untuk memasukan script kode pemrograman kedalam sebuah software programming untuk menghasilkan aplikasi yang telah di desain, software programming yang dapat digunakan harus disesuaikan dengan desain sistem yang dibuat (misal : untuk ponsel, Desktop, Website, anginer dan lain-lain). Untuk software programming dapat menggunakan Borland C++, Dev C++, Delphi, Visual Basic, NetBeans dan lain-lain. 

Pengujian dan tahap pendukung(Support)

            Tahap ini adalah tahap pengujian dan tahap pendukung yang artinya sistem yang telah dibuat dari hasil analisis masalah yang telah melalui tahap-tahap desain, pengodean barulah masuk kedalam pengujian sistem, sehingga akan dapat diketahui seperti apa hasil kinerja sistem yang baru ini dibandingkan dengan sistem yang lama, kemudian dapat diketahui pula apakan dalam sistem yang baru ini masih ada kelemahan yang kemudian akan dikembangkan oleh peneliti berikutnya. 

Kelebihan Metode Waterfall

Kelebihan menggunakan metode air terjun (waterfall) adalah metode ini memungkinkan untuk departementalisasi dan kontrol. proses pengembangan model fase one by one, sehingga meminimalis kesalahan yang mungkin akan terjadi. Pengembangan bergerak dari konsep, yaitu melalui desain, implementasi, pengujian, instalasi, penyelesaian masalah, dan berakhir di operasi dan pemeliharaan.

Kekurangan Metode Waterfall

            Kekurangan menggunakan metode waterfall adalah metode ini tidak memungkinkan untuk banyak revisi jika terjadi kesalahan dalam prosesnya. Karena setelah aplikasi ini dalam tahap pengujian, sulit untuk kembali lagi dan mengubah sesuatu yang tidak terdokumentasi dengan baik dalam tahap konsep sebelumnya.

Referensi
http://tarmo.fi/blog/2005/09/dont-draw-diagrams-of-wrong-practices-or-why-people-still-believe-in-the-waterfall-model/

http://dikaseba.blogspot.co.id/2017/02/waterfall.html/

http://www.pengetahuandanteknologi.com/2016/09/metode-waterfall-definisi-tahapan.html

Model Prototipe

Secara umum tujuan pengembangan sistem informasi adalah untuk memberikan kemudahan dalam penyimpanan informasi, mengurangi biaya dan menghemat waktu, meningkatkan pengendalian, mendorong pertumbuhan, meningkatkan produktifitas serta profitabilitas organisasi. Dalam beberapa tahun terakhir ini peningkatan produktifitas organisasi ini dibantu dengan berkembangnya teknologi komputer baik hardware maupun softwarenya. Tetapi tidak semua kebutuhan sistem informasi dengan komputer itu dapat memenuhi kebutuhan dan menyelesaikan masalah yang dihadapi organisasi. Keterbatasan sumber daya dan anggaran pemeliharaan memaksa para pengembang sistem informasi untuk menemukan jalan untuk mengoptimalkan kinerja sumber daya yang telah ada.

Karakteristik dari suatu sistem informasi manajemen yang lengkap tergantung dari masalah yang dihadapi, proses pengembangannya dan tenaga kerja yang akan dikembangkannya. Seiring dengan perkembangan permasalahan karena berubahnya lingkungan yang berdampak kepada perusahaan maka yang menjadi parameter proses pengembangan sistem informasi yaitu masalah yang dihadapi, sumber daya yang tersedia dan perubahan, sehingga hasil pengembangan sistem informasi manajemen baik yang diharapkan oleh perorangan maupun oleh organisasi turut berubah.

Perubahan tersebut pada akhirnya menimbulkan ketidakpastian dan menambah kompleks/rumit masalah yang dihadapi oleh para analis sistem informasi. Metode tradisional seperti SDLC dianggap tidak lagi mampu memenuhi tantangan perubahan dan kompleksnya masalah yang dihadapi tersebut. Sekitar awal tahun delapan puluhan, para profesional dibidang sistem informasi memperkenalkan satu metode pengembangan sistem informasi baru, yang dikenal dengan nama metode prototyping.

Metode prototyping sebagai suatu paradigma baru dalam pengembangan sistem informasi manajemen, tidak hanya sekedar suatu efolusi dari metode pengembangan sistem informasi yang sudah ada, tetapi sekaligus merupakan refolusi dalam pengembangan sistem informasi manajemen. Metode ini dikjatakan refolusi karena merubah proses pengembangan sistem informasi yang lama (SDLC).

Menurut literatur, yang dimaksud dengan prototipe (prototype) adalah ”model pertama”, yang sering digunakan oleh perusahaan industri yang memproduksi barang secara masa. Tetapi dalam kaitannya dengan sistem informasi definisi kedua dari Webster yang menyebutkan bahwa ”prototype is an individual that exhibits the essential peatures of later type”, yang bila diaplikasikan dalam pengembangan sistem informasi manajemen dapat berarti bahwa Prototipe tersebut adalah sistem informasi yang menggambarkan hal-hal penting dari sistem informasi yang akan datang. Prototipe sistem informasi bukanlah merupakan sesuatu yang lengkap, tetapi sesuatu yang harus dimodifikasi kembali, dikembangkan, ditambahkan atau digabungkan dengan sistem informasi yang lain bila perlu.

Dalam beberapa hal pengembangan software berbeda dengan produk-produk manufaktur, setiap tahap atau fase pengembangan sistem informasi merupakan bagian yang tidak terpisahkan dari seluruh proses yang harus dilakukan. Proses ini umumnya hanya untuk satu produk dan karakteristik dari produk tersebut tidak dapat ditentukan secara pasti seperti produk manufaktur, sehingga penggunaan ”model pertama” bagi pengembangan software tidaklah tepat. Istilah prototyping dalam hubungannya dengan pengembangan software sistem informasi manajemen lebih merupakan suatu proses bukan prototipe sebagai suatu produk.

Tahapan-Tahapan Prototyping dan Kelebihannya

Tahapan-tahapan dalam Prototyping adalah sebagai berikut:

1.      Pengumpulan kebutuhan
Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.

2.      Membangun prototyping
Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output).

3.      Evaluasi protoptyping
Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. Jika sudah sesuai maka langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulang langkah 1, 2 , dan 3.

4.      Mengkodekan sistem
Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai.

5.      Menguji sistem
Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain.

6.      Evaluasi Sistem
Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan. Jika ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5.

7.      Menggunakan sistem
Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.

Model pengembangan ini (Prototyping Model) memiliki beberapa kelebihan, diantaranya :

§  Adanya komunikasi yang baik antara pengembang dan pelanggan

§  Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan

§  Pelanggan berperan aktif dalam pengembangan system

§  Lebih menghemat waktu dalam pengembangan system

§  Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya

§  membuat klien mendapat gambaran awal dari prototype

Membantu mendapatkan kebutuhan detil lebih baik

Implementasi Prototyping Model

     Metode prototyping sebagai suatu paradigma baru dalam pengembangan sistem informasi manajemen, tidak hanya sekedar suatu efolusi dari metode pengembangan sistem informasi yang sudah ada, tetapi sekaligus merupakan refolusi dalam pengembangan sistem informasi manajemen. Metode ini dikjatakan refolusi karena merubah proses pengembangan sistem informasi yang lama (SDLC).

     Menurut literatur, yang dimaksud dengan prototipe (prototype) adalah ”model pertama”, yang sering digunakan oleh perusahaan industri yang memproduksi barang secara masa. Tetapi dalam kaitannya dengan sistem informasi definisi kedua dari Webster yang menyebutkan bahwa ”prototype is an individual that exhibits the essential peatures of later type”, yang bila diaplikasikan dalam pengembangan sistem informasi manajemen dapat berarti bahwa Prototipe tersebut adalah sistem informasi yang menggambarkan hal-hal penting dari sistem informasi yang akan datang. Prototipe sistem informasi bukanlah merupakan sesuatu yang lengkap, tetapi sesuatu yang harus dimodifikasi kembali, dikembangkan, ditambahkan atau digabungkan dengan sistem informasi yang lain bila perlu.

     Dalam beberapa hal pengembangan software berbeda dengan produk-produk manufaktur, setiap tahap atau fase pengembangan sistem informasi merupakan bagian yang tidak terpisahkan dari seluruh proses yang harus dilakukan. Proses ini umumnya hanya untuk satu produk dan karakteristik dari produk tersebut tidak dapat ditentukan secara pasti seperti produk manufaktur, sehingga penggunaan ”model pertama” bagi pengembangan software tidaklah tepat. Istilah prototyping dalam hubungannya dengan pengembangan software sistem informasi manajemen lebih merupakan suatu proses bukan prototipe sebagai suatu produk.

     Sebagai contoh, pembuat mobil dapat mengembangkan sebuah purwarupa yang dapat digunakan dalam lintasan pengujuan khusus dan kemudian ditampilkan dalam showroom. Informasi yang diperoleh dari perlakuan seperti itu dapat digunakan untuk meningkatkan desain sebelum implementasi/produksi dilakukan secara massal.

Karakteristik metode prototyping
Ada empat langkah yang menjadi karakteristik metode prototyping yaitu :

1.      Pemilahan Fungsi
Mengacu pada pemilahan fungsi yang harus ditampilkan oelh prototyping. Pemilahan harus selalu dilakukan berdasarkan pada tugas-tugas yang relevan yang sesuai dengan contoh kasus yang akan dipergakan.

2.      Penyusunan Sistem Informasi

3.      Evaluasi

4.      Penggunaan Selanjutnya

Referensi

http://zacha.blog.ugm.ac.id/2011/03/09/prototyping-model/

http://rizalloa.ilearning.me/?p=132

Model Spiral

Pada artikel kali ini saya akan melanjutkan postingan tentang salah satu metode pengembangan perangkat lunak yaitu metode PRL SPIRAL. Model ini mengadaptasi dua model perangkat lunak yang ada yaitu model prototyping dengan pengulangannya dan model waterfall dengan pengendalian dan sistematikanya.  Model ini dikenal dengan sebutan Spiral Boehm. Pengembang dalam model ini memadupadankan beberapa model umum tersebut untuk menghasilkan produk khusus atau untuk menjawab persoalan-persoalan tertentu selama proses pengerjaan proyek.

Gambar 1. Model Spiral Boehm

Model spiral (spiral model) adalah model proses software yang evolusioner yang merangkai sifat iteratif dari prototipe dengan cara kontrol dan aspek sistematis dari model sekuensial linier. Model ini berpotensi untuk pengembangan versi pertambahan software secara cepat. Di dalam model spiral, software dikembangkan di dalam suatu deretan pertambahan. Selama awal iterasi, rilis inkremental bisa merupakan sebuah model atau prototipe kertas. Selama iterasi berikutnya, sedikit demi sedikit dihasilkan versi sistem rekayasa yang lebih lengkap.

Model spiral dibagi menjadi sejumlah aktifitas kerangka kerja, disebut juga wilayah tugas, di antara tiga sampai enam wilayah tugas. Tahap-tahap model tersebut dapat dijelaskan secara ringkas sebagai berikut.

1. Tahap Liason: pada tahap ini membangun komunikasi yang efektif di antara pengembangan dan pelanggan.

2. Tahap Planning (perencanaan): pada tahap ini ditentukan sumber-sumber informasi, batas waktu dan informasi-informasi yang dapat menjelaskan proyek.

3. Tahap Analisis Resiko: mendefinisikan resiko, menentukan apa saja yang menjadi resiko baik teknis maupun manajemen.

4. Tahap Rekayasa (engineering): pembuatan prototipe atau pembangunan satu atau lebih representasi dari aplikasi tersebut

5.Tahap Konstruksi dan Pelepasan (release): pada tahap ini dilakukan pembangunan perangkat lunak yang dimaksud, diuji, diinstal dan diberikan sokongan-sokongan tambahan untuk keberhasilan proyek.

6. Tahap Evaluasi: Pelanggan/pemakai/pengguna biasanya memberikan masukan berdasarkan hasil yang didapat dari tahap engineering dan instalasi.

Dalam pengembangan sistem informasi berbasis web, model ini digunakan untuk menyelesaikan sistem secara global terlebih dahulu, kemudian untuk feature dari sistem akan dikembangkan kemudian. Dengan ini mempercepat dalam pengimplementasian project dan hal ini cocok digunakan dalam sistem informasi Web.

Kelebihan
1. Sangat mempertimbangkan resiko kemungkinan munculnya kesalahan sehingga sangat dapat diandalkan untuk pengembangan perangkat lunak skala besar.
2. Pendekatan model ini dilakukan melalui tahapan-tahapan yang sangat baik dengan menggabungkan model waterfall ditambah dengan pengulangan-pengulangan sehingga lebih realistis untuk mencerminkan keadaan sebenarnya.
3. Baik pengembang maupun pemakai dapat cepat mengetahui letak kekurangan dan kesalahan dari sistem karena proses-prosesnya dapat diamati dengan baik.

Kekurangan

1.Waktu yang dibutuhkan untuk mengembangkan perangkat lunak cukup panjang demikian juga biaya yang besar.

2. Sangat tergantung kepada tenaga ahli yang dapat memperkirakan resiko.

3. Terdapat pula kesulitan untuk mengontrol proses. Sampai saat ini, karena masih relatif baru, belum ada bukti apakah metode ini cukup handal untuk diterapkan.

4. Meyakinkan konsumen (khusunya dalam situasi kontrak) bahwa pendekatan evolusioner bisa dikontrol.

Model Boehm sangat cocok diterapkan untuk pengembangan sistem dan perangkat lunak skala besar di mana pengembang dan pemakai dapat lebih mudah memahami kondisi pada setiap tahapan dan bereaksi terhadap kemungkinan terjadinya kesalahan. Selain itu, diharapkan juga waktu dan dana yang tersedia cukup memadai.

Referensi

http://imanaanggreani.blogspot.co.id/2014/06/metode-pengembangan-perangkat-lunak.html

Rapid Application Development (RAD)

Rapid application development  (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan. Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final.

 Sejarah

Rapid Application Development ( RAD ) adalah istilah awalnya digunakan untuk menggambarkan proses pengembangan perangkat lunak pertama kali dikembangkan dan berhasil digunakan selama pertengahan 1970-an oleh Sistem Pusat Pengembangan New York Telephone Co di bawah arahan Dan Gielan. Setelah serangkaian implementasi sangat berhasil dari proses ini, Gielan kuliah secara ekstensif di berbagai forum pada metodologi , praktek, dan manfaat dari proses ini.

RAD melibatkan pengembangan dan pembangunan prototipe iteratif . Pada tahun 1990 , dalam buku RAD, Rapid Application Development, James Martin didokumentasikan penafsirannya tentang metodologi. Baru-baru ini, istilah dan singkatan yang telah datang untuk digunakan dalam lebih luas, pengertian umum yang mencakup berbagai metode yang bertujuan untuk mempercepat pengembangan aplikasi, seperti penggunaan kerangka perangkat lunak dari berbagai jenis, seperti kerangka kerja aplikasi web.

Pengembangan aplikasi yang cepat merupakan respon terhadap proses yang dikembangkan pada 1970-an dan 1980-an, seperti Structured Sistem Metode Analisis dan Desain dan model Waterfall lainnya. Satu masalah dengan metodologi sebelumnya adalah bahwa aplikasi begitu lama untuk membangun bahwa persyaratan telah berubah sebelum sistem itu selesai, sehingga sistem tidak memadai atau bahkan tidak dapat digunakan. Masalah lain adalah asumsi bahwa persyaratan metodis tahap analisis saja akan mengidentifikasi semua persyaratan penting. Membuktikan fakta bahwa ini adalah jarang terjadi, bahkan untuk proyek-proyek dengan profesional yang sangat berpengalaman di semua tingkatan.

Dimulai dengan ide-ide dari Brian Gallagher, Alex Balchin, Barry Boehm dan Scott Shultz, James Martin mengembangkan pendekatan pengembangan aplikasi yang cepat selama tahun 1980 di IBM dan akhirnya diresmikan itu dengan menerbitkan sebuah buku pada tahun 1991, Rapid Application Development.

Kelebihan dan Kekurangan

 Kelebihan dari RAD :

1.    Membeli sistem yang baru memungkinkan untuk lebih menghemat biaya ketimbang mengembangkan sendiri.

2.    Proses pengiriman menjadi lebih mudah, hal ini dikarenakan proses pembuatan lebih banyak menggunakan potongan-potongan script.

3.    Mudah untuk diamati karena menggunakan model prototype, sehingga user lebih mengerti akan sistem yang dikembangkan.

4.    Lebih fleksibel karena pengembang dapat melakukan proses desain ulang pada saat yang bersamaan.

5.    Bisa mengurangi penulisan kode yang kompleks karena menggunakan wizard.

6.    Keterlibatan user semakin meningkat karena merupakan bagian dari tim secara keseluruhan.

7.    Mampu meminimalkan kesalahan-kesalahan dengan menggunakan alat-alat bantuan (CASE tools).

8.    Mempercepat waktu pengembangan sistem secara keseluruhan karena cenderung mengabaikan kualitas.

9.    Tampilan yang lebih standar dan nyaman dengan bantuan software-software pendukung.

  Kelemahan dari RAD :

1.    Dengan melakukan pembelian belum tentu bisa menghemat biaya dibandingkan dengan mengembangkan sendiri.

2.    Membutuhkan biaya tersendiri untuk membeli peralatan-peralatan penunjang seperti misalnya software dan hardware.

3.    Kesulitan melakukan pengukuran mengenai kemajuan proses.

4.    Kurang efisien karena apabila melakukan pengkodean dengan menggunakan tangan bisa lebih efisien.

5.    Ketelitian menjadi berkurang karena tidak menggunakan metode yang formal dalam melakukan pengkodean.

6.    Lebih banyak terjadi kesalahan apabila hanya mengutamakan kecepatan dibandingkan dengan biaya dan kualitas.

7.    Fasilitas-fasilitas banyak yang dikurangi karena terbatasnya waktu yang tersedia.

8.    Sistem sulit diaplikasikan di tempat yang lain.

9.    Fasilitas yang tidak perlu terkadang harus disertakan, karena menggunakan komponen yang sudah jadi, sehingga hal ini membuat biaya semakin meningkat.

Contoh Penerapan dalam Kehidupan

Model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang dicapai dengan menerapkan :

1.     Component based construction (pemrograman berbasis komponen bukan prosedural).

2.     Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada.

3.     Pembangkitan kode program otomatis/semi otomatis.

4.     Multiple team (banyak tim), tiap tim menyelesaikan satu tugas yang selevel tapi tidak sama. Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun.

Jika keutuhan yang diinginkan pada tahap analisis kebutuhan telah lengkap dan jelas, maka waktu yang dibutuhkan untuk menyelesaikan secara lengkap perangkat lunak yang dibuat adalah berkisar 60 sampai 90 hari. Model RAD hampir sama dengan model waterfall, bedanya siklus pengembangan yang ditempuh model ini sangat pendek dengan penerapan teknik yang cepat.

Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan beberapa tim dalam waktu yang hampir bersamaan dalam waktu yang sudah ditentukan. Model ini melibatkan banyak tim, dan setiap tim mengerjakan tugas yang selevel, namun berbeda. Sesuai dengan pembagian modul sistem.

ALASAN MEMILIH METODE RAD

Di dalam memilih metode RAD harus memperhatikan alasan-alasan berikut ini:

1. Alasan yang Buruk

§  Apabila menggunakan RAD hanya untuk menghemat biaya pengembangan suatu sistem. Hal ini disebabkan karena dengan menggunakan metode RAD membutuhkan suatu tim yang mengerti betul
mengenai manajemen biaya. Sebab bila tidak, maka biaya yang dikeluarkan akan menjadi lebih besar.

§  Apabila menggunakan RAD hanya untuk menghemat waktu pengembangan suatu sistem. Hal ini disebabkan karena dengan menggunakan metode RAD membutuhkan suatu tim yang mengerti betul mengenai manajemen waktu. Sebab bila tidak maka waktu yang dibutuhkan akan menjadi lebih lama.

2. Alasan yang Baik

§  Apabila menggunakan RAD untuk mendapatkan suatu desain yang dapat diterima oleh konsumen dan dapat dikembangkan dengan mudah.

§  Apabila menggunakan RAD untuk memberikan batasan-batasan pada suatu system supaya tidak mengalami perubahan.

§  Apabila menggunakan RAD untuk menghemat waktu, dan kalau memungkinkan bisa menghemat biaya serta menghasilkan produk yang berkualitas.

Referensi

http://fannynurrizky06.blogspot.co.id/2013/11/rapid-application-development-rad.html

http://rizalloa.ilearning.me/?p=133

MODEL RUP (Rational Unified Process)

           

RUP (Rational Unified Process) merupakan suatu Software engineering process hasil kerja awal dari “Three Amigos” –Ivar Jacobson, Grady Booch, dan James Rumbaugh- yang bertujuan untuk memastikan kualitas yang terbaik pada suatu produksi software dengan memperkirakan jadwal dan biaya yang harus dikeluarkan. RUP merupakan process product dari Rational® Software dengan konsep utamanya adalah tentang model, workflow dan workers, serta tentang phase dan iterasi.

Aktifitas yang dilakukan oleh Rational Unified Process adalah membuat dan memelihara  model. RUP juga meliputi pembahasan dari implementasi UML (Unified Modelling Language)  secara luas dan memfokuskan dirinya pada software yang memiliki metodologi berorientasi objek. Sehingga dapat kita bedakan dengan UML bahwa RUP merupakan sebuah proses yang dilakukan dalam rekayasa perangkat lunak sedangkan UML adalah bahasa standar yang digunakan untuk memvisualisasikan, mendeskripsikan, membangun, dan mendokumentasikan perangkat yang akan digunakan dalam membangun sebuah perangkat lunak. RUP dibutuhkan sebagai pedoman untuk menggunakan UML secara efektif. Sedangkan UML berfungsi sebagai standardisasi notasi yang berorientasi objek untuk mengkomunikasikan kebutuhan/requirement, architectures, dan desain secara jelas dengan user. Oleh karena itu, hubungan antara RUP dan UML sangatlah dekat.

Aktifitas yang dilakukan dalam Software development merupakan sebuah pekerjaan team. Karena perubahan teknologi yang cepat sehingga memerlukan spesialisasi tertentu dalam pelaksanaannya.  Produktivitas team ini dapat ditingkatkan dengan menggunakan RUP dalam mendukung pembangunan sebuah software. Mengapa? Karena setiap anggota team akan dibekali oleh pengetahuan dasar yang sama mengenai guidelines dan template dalam aktifitas software development, sehingga saat membangun sebuah sistem akan dijamin bahwa setiap anggota team akan menggunakan bahasa yang sama untuk merepresentasikan requirement yang diminta user. Jika telah ada standar yang digunakan dalam proses pembangunan sebuah software, diharapkan dapat mengoptimalkan hasil yang diperoleh. 

Namun dengan metode ini dirasakan kurang efektif karena membutuhkan lebih banyak cost sampai menghasilkan sistem yang baik. Hal ini dapat terjadi karena modul yang ada dalam sistem tidak dibagi-bagi terlebih dahulu dalam pengujian software.  Masalah ini dapat diatasi dengan menggunakan metode iteration incremental yang membagi modul-modul sehingga kesalahan dapat diatasi sejak dini. Metode ini yang digunakan dalam RUP.

Keuntungan yang didapat dengan menggunakan pendekatan iterasi diantaranya adalah : mengurangi resiko lebih awal, perubahan yang dilakukan lebih mudah diatur, higher level of reuse, project team memiliki waktu lama untuk memahami sistem yang akan dibangun, dan menghasilkan kualitas yang lebih baik di segala aspek.

RUP menawarkan berbagai kemudahan dalam membangun sebuah sotfware, ada yang disebut Six Best Practices yang terdiri dari :

·          Develop Iteratively

·          Manage Requirement

·          Use Component-based Architecture

·          Model Visually

·          Verify Quality

·          Control Changes to software

       Semua proses yang dilakukan oleh RUP akan memberikan keuntungan pada tahapan membangun sebuah software. Yang akan kita bahas di bagian lain dari makalah ini.

Saat melakukan perancangan sebuah perangkat lunak, tentunya setiap tahapan akan mendapatkan masalah. Biasanya gejala/symptom yang menunjukkan ada masalah dalam proses perancangan software seperti berikut :

·          Ketidak akuratan dalam memahami kebutuhan end-user.

·          Ketidakmampuan untuk menyetujui perubahan kebutuhan yang diajukan.

·          Modul-modul yang dibutuhkan tidak dapat dihubungkan.

·          Software yang sulit untuk dibangun atau diperluas.

·          Terlambat menemukan kerusakan project yang serius.

·          Kualitas software yang buruk.

·          Kemampuan software yang tidak dapat diterima.

               Team members yang bekerja sendiri-sendiri sulit untuk mengetahui perubahan yang telah dilakukan karena ada perbedaan dalam membangun software tersebut.

·          Ada ketidakpercayaan dalam membangun dan me-release proses.

Usaha untuk menghilangkan symptom ini tidak akan menyelesaikan masalah yang dihadapi software developer karena gejala ini dapat terjadi oleh adanya penyebab utama masalah yang timbul saat membangun sebuah sistem, yaitu :

·          Requirement management yang tidak mencukupi

·          Komunikasi yang ambigu dan tidak tepat

·          Arsitektur yang rapuh

·          Kompleksitas yang sangat besar

·          Tidak terdeteksinya ketidakkonsistenan antara requirement,desain, dan implementasi

·          Pengetesan yang tidak mencukupi

·          Penilaian status project yang subjektif

·          Keterlambatan pengurangan resiko yang disebabkan waterfall development

·          Perkembangan yang tidak terkontrol

·          Otomatisasi yang kurang

Penerapan Tahapan Metodologi Pengembagan Perangkat Lunak dengan Menggunakan RUP (Contoh Kasus)

Metodologi Rational Unified Process (RUP). Metode RUP merupakan metode pengembangan kegiatan yang berorientasi pada proses. Dalam metode ini, terdapat empat tahap pengembangan perangkat lunak yaitu:

Inception :

Pada tahap ini pengembang mendefinisikan batasan kegiatan, melakukan analisis kebutuhan user, dan melakukan       perancangan awal perangkat lunak (perancangan arsitektural dan use case). Pada akhir fase ini, prototipe perangkat lunak versi Alpha harus sudah dirilis

Elaboration :

Pada tahap ini dilakukan perancangan perangkat lunak mulai dari menspesifikasikan fitur perangkat lunak hingga perilisan prototipe versi Betha dari perangkat lunak.

Construction :

Pengimplementasian rancangan perangkat lunak yang telah dibuat dilakukan pada tahap ini. Pada akhir tahap ini, perangkat lunak versi akhir yang sudah disetujui administrator dirilis beserta  dokumentasi perangkat lunak.

Transition :

Instalasi , deployment dan sosialisasi perangkat lunak dilakukan pada tahap ini.

Referensi

http://aih25.blogspot.co.id/2013/03/rup-rational-unified-process.html

http://cccoffe.blogspot.co.id/2014/09/rdp-rational-unified-process.html

MODEL Extreme Programming

Extreme Programming (XP) merupakan suatu pendekatan yang paling banyak digunakan untuk pengembangan perangkat lunak cepat. Alasan menggunakan metode  Extreme Programming (XP) karena sifat dari aplikasi yang di kembangkan dengan cepat melalui tahapan-tahapan yang ada meliputi : Planning/Perencanaan, Design/Perancangan, Coding/Pengkodean dan Testing/Pengujian. (Pressman, 2012:88). Adapun  tahapan padaExtreme Programming dapat di jelaskan sebagai berikut:

Sejarah XP

Proyek pengembangan perangkat lunak yang dianggap sebagai yang pertama kali menerapkan extreme programming  adalah C3 (Chrysler Comprehensive Compensation) Project dari Chrysler. Proyek ini adalah proyek penggajian 10.000 karyawan Chrysler, terdiri dari kira-kira 2000 class dan 30.000 method. Proyek yang dimulai pertengahan dekade 90-an ini terancam gagal karena rumitnya sistem yang dibangun dan kegagalan pada saat testing. Chrysler kemudian menyewa Kent Beck, seorang pakar software engineering yang di kemudian hari dikenal sebagai pencetus awal dari XP, untuk menyelamatkan proyek tersebut. Beck bersama rekannya Ron Jeffries dengan kewenangan yang diberikan oleh Chrysler melakukan berbagai perubahan di C3 Project untuk membuatnya lebih efisien, adaptif, dan fleksibel. Hal yang paling penting bagi mereka adalah harus mampu memenuhi permintaan utama dari Chrysler, untuk melakukan launching perangkat lunak tersebut dalam waktu tidak lebih dari dua tahun sejak saat Beck dikontrak.

Beck dan Jeffries pada akhirnya berhasil menyelesaikan target Chrysler dengan menerapkan berbagai metode dalam proses pengembangan perangkat lunak tersebut. Kumpulan metode inilah yang kemudian dikenal sebagai model atau pendekatan XP dalam pengembangan perangkat lunak. Begitu sederhananya metode-metode tersebut sehingga bagi orang yang belum menerapkan, XP terlihat sebagai kumpulan ide lama yang terlalu sederhana dan tidak akan memberikan efek apapun pada sebuah proyek pengembangan perangkat lunak.

Kent Beck sendiri mengakui dan menegaskan bahwa XP tidak selalu cocok untuk setiap proyek pengembangan perangkat lunak. Kelebihan XP adalah sesuai untuk digunakan pada proyek yang memiliki dynamic requirements. Proyek semacam ini memerlukan adaptasi cepat dalam mengatasi perubahan-perubahan yang terjadi selama proses pengembangan perangkat lunak. XP juga cocok untuk proyek dengan jumlah anggota tim tidak terlalu banyak (sekitar 10-20 orang) dan berada pada lokasi yang sama.

 1)Planning/Perencanaan

Pada tahap perencanaan ini dimulai dari pengumpulan kebutuhan yang membantu tim teknikal untuk memahami konteks bisnis dari sebuah aplikasi. Selain itu pada tahap ini juga mendefinisikan output yang akan dihasilkan, fitur yang dimiliki oleh aplikasi dan fungsi dari aplikasi yang dikembangkan.

2)Design/Perancangan

Metode ini menekankan desain aplikasi yang sederhana, untuk mendesain aplikasi dapat menggunakanClass-Responsibility-Collaborator (CRC) cards yang mengidentifikasi dan mengatur class pada object-oriented.

3)Coding/Pengkodean

Konsep utama dari tahapan pengkodean pada extreme programming adalah pair programming, melibatkan lebih dari satu orang untuk menyusun kode.

4)Coding/Pengujian

Pada tahapan ini lebih fokus pada pengujian fitur dan fungsionalitas dari aplikasi.

Referensi

http://ganiamanda.blog.widyatama.ac.id/2016/02/13/extreme-programming-xp-model/

http://catatandestra.blogspot.co.id/2014/11/metode-pengembangan-extreme-programming.html