Pagaralam

Rapid Aplication Development (RAD) adalah sebuah proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier dimana perkembangan cepat dicapai dengan menggunakan pendekatan konstruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari).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.
2.2   Sejarah RAD
 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.

2.3   Unsur-unsur model RAD
Rapid Aplication Development memiliki banyak unsurunsur yang membuat sebuah metodologi yang unik termasuk prototyping, iterative development, time boxing, team members, management approach, dan RAD tools.

a. Prototyping
Sebuah aspek kunci dari RAD adalah pembangunan prototipe untuk tujuan membangkitkan kembali desain untuk kebutuhan pengguna. Tujuannya adalah untuk membangun sebuah fitur ringan yang hasil akhirnya dalam jumlah pendek dengan waktu yang memugkinkan. Prototipe awal berfungsi sebagai bukti konsep untuk klien, tetapi lebih penting berfungsi sebagai titik berbicara dan alat untuk kebutuhan pemurnian. Mengembangkan prototipe cepat dicapai dengan Computer Aided Engineering CASE tools Software yang berfokus pada menangkap persyaratan, mengkonversi mereka ke model data, mengubah model data ke database, dan menghasilkan kode semua dalam satu alat. CASE tools populer di 80an dan awal 90an, tetapi sebagai teknologi telah berubah (dan COBOL telah menjadi usang) beberapa alat mengambil keuntungan penuh dari potensi penuh dari teknologi KASUS alat. Perusahaan rasional adalah yang paling terkenal meskipun prototipe potensi pembangkitnya terbatas. Pada Otomatis Arsitektur produk cetak biru kami 3 berfokus pada peningkatan tingkat aplikasi enterprise web yang berfungsi sebagai prototipe karena kecepatan yang mereka dapat diciptakan (dalam menit).

b. Iterative Development
Iterative Development berarti menciptakan versi yang lebih fungsional dari sebuah sistem dalam siklus pembangunan pendek. Setiap versi ditinjau dengan klien untuk menghasilkan persyaratan untuk membuat versi berikutnya. Proses ini diulang sampai semua fungsionalitas telah dikembangkan. Panjang ideal iterasi adalah antara satu hari (yang lebih dekat dengan Metodologi Agile) dan tiga minggu. Setiap siklus pengembangan memberikan pengguna kesempatan untuk memberikan umpan balik, memperbaiki persyaratan, dan kemajuan melihat (dalam pertemuan sesi fokus grup). Hal ini akhirnya pembangunan berulang yang memecahkan masalah yang melekat dalam metodologi fleksibel dibuat pada 1970an.

c. Time boxing
Time boxing adalah proses menunda fitur untuk versi aplikasi di masa mendatang untuk melengkapi versi saat ini sebagai ketepatan waktu.Ketepatan waktu merupakan aspek penting dari RAD, karena tanpa itu ruang lingkup dapat mengancam untuk memperpanjang iterasi pembangunan, sehingga membatasi umpan balik dari klien, meminimalkan manfaat dari pembangunan berulang, dan berpotensi mengembalikan proses kembali ke pendekatan metodologi air terjun.
d. Team Member
Metodologi RAD merekomendasikan penggunaan tim kecil yang terdiri dari anggota yang berpengalaman, serbaguna, dan motivasi yang mampu melakukan peran ganda. Sebagai klien memainkan peran penting dalam proses pembangunan, sumber daya klien khusus harus tersedia selama awal Joint Application Development (JAD) sesi serta Focus Group Sessions dilakukan pada akhir siklus pengembangan. Pengembangan tim (juga dikenal sebagai SWAT atau Skilled Workers with Advance 4 Tools) idealnya harus memiliki pengalaman di Rapid Application Development dan harus memiliki pengalaman dengan Computer Aided Software Engineering.
Pendekatan manajemen Aktif dan manajemen yang terlibat sangat penting untuk mengurangi risiko siklus pengembangan diperpanjang, kesalahpahaman klien, dan melebihi tenggat waktu. Di atas manajemen semua harus kuat dan konsisten dalam keinginan mereka untuk menggunakan metodologi Rapid Application Development. Selain menegakkan waktu yang ketat, manajemen harus fokus pada pemilihan anggota tim, motivasi tim, dan pada kliring hambatan birokrasi atau politik.
e. RAD Tools
Salah satu tujuan utama dari metodologi Rapid Application Development yang dikembangkan oleh James Martin pada tahun 1980an adalah untuk memanfaatkan teknologi terbaru yang tersedia untuk mempercepat pembangunan. Jelas teknologi tahun 1980 sudah kuno, tetapi fokus RAD tentang alat terbaru adalah sama pentingnya hari ini seperti ketika metodologi awalnya diciptakan.

2.4    Penerapan Model RAD
Model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang dicapai dengan menerapkan :
Component based construction ( pemrograman berbasis komponen bukan prosedural).
Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada.
Pembangkitan kode program otomatis/semi otomatis.
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.

2.5     Fase-Fase Model RAD
Bussiness Modeling
Aliran informasi di antara fungsi-fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan-pertanyaan berikut : Informasi apa yang mengendalikan proses bisnis? Informasi apa yang dimunculkan? Siapa yang memunculkannya? Ke mana informasi itu pergi? Siapa yang memprosesnya?
Data Modeling
Aliran informasi yang didefinisikan sebagai bagian dari fase bussiness modeling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik masing-masing objek didefinisikan dan hubungan antara objek-objek tersebut didefinisikan.
Prosess Modeling
Objek data yang telah didefinisikan di dalam fase data modeling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus atau mendapatkan kembali sebuah objek data.
Aplication Generation
   RAD mengasumsikan pemakaian teknik generasi keempat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman general yang konvensional, RAD lebih banyak memproses kerja untuk mamakai lagi komponen program yang ada atau menciptakan komponoen yang bisa dipakai lagi. Pada semua kasus, alat-alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.
Testing and Turnover
Karena proses RAD menekankan pada pemakaian kembali , banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi komponen baru harus diuji dan semua interface harus dilatih secara penuh.
. 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. Workshop desain ini dapat dilakukan selama beberapa hari tergantung dari ukuran aplikasi yang akan dikembangkan. Selama workshop desain 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).

Berikut ini Contoh dari pembuatan system menggunakan Rapid Application Develoopment Methodology :
Pembuatan website mcommerce (mobile commerce) untuk mempermudah proses penyewaan kendaraan mobil pada suatu badan usaha. Pengembangan sistem mcommerce ini
menggunakan metode Rapid Application Development (RAD), dengan demikian siklus pembangunan perangkat lunak menjadi lebih pendek atau singkat. Penerapan sistem mcommerce ini menggunakan arsitektur yang berbasis Wireless Application Protocol (WAP) sehingga website dapat diakses dari telepon seluler (ponsel) melalui browser.

Gambar 4 Halaman Utama Sistem Penyewaan Mobil Menggunakan RAD

2.6    Perbandingan RAD dengan Metode Lain
2.6.1 Perbandingan Dengan Metode Tradisional
Sebagai gambaran umum, pengembangan aplikasi berarti mengembangkan aplikasi pemrograman yang bervariasi dari pemrograman umum dalam arti bahwa ia memiliki tingkat yang lebih tinggi dari kewajiban, termasuk untuk kebutuhan menangkap dan pengujian. Pada 1970an, Rapid Application Development muncul sebagai respon mengerikan untuk proses nontangkas, seperti model Waterfall. Pengembang perangkat lunak menghadapi masalah waktu dengan metodologi sebelumnya sebagai aplikasi begitu lama untuk membangun bahwa.spesifikasi persyaratan diubah oleh sistem waktu itu selesai. Dengan demikian, metodologi tersebut sering mengakibatkan sistem tidak dapat digunakan.
Metodologi RAD adalah dalam jangkauan hampir semua orang sebagai generator kode, alatalat visual seperti VB, Visual C + + dan CASE tool seperti Rational Rose didasarkan pada teknik RAD saja. Jika Anda merancang aplikasi dengan Rational Rose, kode dapat secara otomatis dihasilkan dalam bahasa seperti C + +, VC + + atau VB. Sebagai contoh sederhana, jika Anda telah menggunakan alat alat seperti MS FrontPage maka itu kembali alat RAD. Berikut ini gambar perbandingan antara metode RAD dengan metode Trdisional. perbedaan dari metode tradisonal dengan metode RAD. Untuk tahap tradisonal mengacu pada urutan tahaptahap SDLC. Pada RAD Tahap pertama langsung membuat analisis dan design, lalu langsung ketahap siklus prototyping yaitu membangun, memperhalus dan mendemonstrasikannya. Itu akan mempercepat proses dalam pembuatan suatu project. RAD memang lebih cepat dari Waterfall. Jika kebutuhan dan batasan project sudah diketahui dengan baik. Juga jika proyek memungkinkan untuk dimodularisasi.


2.6.2 Metodelogi RAD mengunakan Prototyping dan Throwaway Prototyping
Karena Keunggulan metode ini menggabungkan teknik SDLC, Prototyping, teknik joint application development (JAD) dan computer aided software engineering (CASE Tools) yang bertujuan untuk membuat system dalam waktu singkat ( kurang dari 6 bulan ). Pada gambar 2 diatas Metodologi prototyping melakukan analisis, desain dan implementasi secara bersamaan untuk menghadirkan sebuah sistem dengan skala kecil dalam fungsi minimal kemudian di review oleh user untuk dilakukan proses development secara berulang hingga menghasilkan sebuah system.
metode Throwaway Prototyping, pada metodologi ini Analisa dilakukan lebih mendalam, prototype dibuat dan ditest, pengalaman yang diperoleh dari latihan ini digunakan untuk membuat produk finalnya, tetapi prototypenya sendiri dibuang.

2.7  Kelebihan Penggunaan Model RAD
Dimungkinkan dalam proses pembuatan membutuhkan waktu yang sangat singkat (60-90 hari)
Menghemat biaya, karena penekannya adalah penggunaan komponen-komponen yang sudah ada
RAD menggunakan kembali komponen-komponen yang sudah ada, maka beberapa komponen program sudah diuji sehingga kita dapat melakukan penghematan waktu dalam uji coba





2.8 Kekurangan Penggunaan Model RAD

Seperti semua proses model yang lain, pendekatan RAD memiliki kekurangan-kekurangan sebagi berikut:
Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.
RAD menuntut pengembangan dan pelanggan yang memiliki komitmen di dalam aktifitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal. RAD menekankan perkembangan komponen program yang bisa dipakai kembali. Reusable menjadi batu pertama teknologi objek dan ditemui di dalam proses rakitan komponen
Tidak semua aplikasi sesuai untuk RAD. Bila sistem tidak dapat dimodulkan dengan teratur, pembangunan komponen penting pada RAD akan menjadi sangat problematis.
RAD menjadi tidak sesuai jika risiko teknisnya tingggi. Hal ini terjadi bila sebuah aplikasi baru memforsir teknologi baru atau bila perangkat lunak baru membutuhkan tingkat interoperabilitas yang tinggi dengan program komputer yang ada

Sejarah Model Waterfall

1.      Sejarah Model Waterfall
            Nama model ini sebenarnya adalah “Linear Sequential Model”. Model ini sering disebut dengan “classic life cycle” atau model waterfall. Model ini pertama kali yang diperkenalkan oleh Winston Royce sekitar tahun 1970 sehingga sering dianggap kuno, tetapi merupakan model yang paling banyak dipakai didalam Software Engineering (SE). Model ini melakukan pendekatan secara sistematis dan berurutan. Disebut dengan waterfall karena tahap demi tahap yang dilalui harus menunggu selesainya tahap sebelumnya dan berjalan berurutan.
2.      Pengertian Waterfall
Waterfall atau AIR terjun adalah model yang dikembangkan untuk pengembangan perangkat lunak, membuat perangkat lunak. model berkembang secara sistematis dari satu tahap ke tahap lain dalam mode seperti air terjun.
Model ini mengusulkan sebuah pendekatan kepada pengembangan software yang sistematikdan sekuensial yang mulai dari tingkat kemajuan sistem pada seluruh analisis, desain, kode, pengujian dan pemeliharaan. Model ini melingkupi aktivitas-aktivitas sebgai berikut : rekayasa dan pemodelan sistem informasi, analisis kebutuhan, desain, koding, mengujian dan pemeliharaan.
Model pengembangan ini bersifat linear dari tahap awal pengembangan system yaitu tahap perencanaan sampai tahap akhir pengembangan system yaitu tahap pemeliharaan. Tahapan berikutnya tidak akan dilaksanakan sebelum tahapan sebelumnya selesai dilaksanakan dan tidak bisa kembali atau mengulang ke tahap sebelumnya.











1.      Tahapan Atau Fase Model Waterfall
Ini adalah gambar tahapan atau fase yang paling umum tentang model waterfall



        Akan tetapi Roger S. Pressman memecah model ini menjadi 6 tahapan meskipun secara garis besar sama dengan tahapan-tahapan model waterfall pada umumnya. Berikut adalah Gambar dan penjelasan dari tahap-tahap yang dilakukan di dalam model ini menurut Pressman:



System / Information Engineering and Modeling. Permodelan ini diawali dengan mencari kebutuhan dari keseluruhan sistem yang akan diaplikasikan ke dalam bentuk software. Hal ini sangat penting, mengingat software harus dapat berinteraksi dengan elemen-elemen yang lain seperti hardware, database, dsb. Tahap ini sering disebut dengan Project Definition.
Software Requirements Analysis. Proses pencarian kebutuhan diintensifkan dan difokuskan pada software. Untuk mengetahui sifat dari program yang akan dibuat, maka para software engineer harus mengerti tentang domain informasi dari software, misalnya fungsi yang dibutuhkan, user interface, dsb. Dari 2 aktivitas tersebut (pencarian kebutuhan sistem dan software) harus didokumentasikan dan ditunjukkan kepada pelanggan.
Design. Proses ini digunakan untuk mengubah kebutuhan-kebutuhan diatas menjadi representasi ke dalam bentuk “blueprint” software sebelum coding dimulai. Desain harus dapat mengimplementasikan kebutuhan yang telah disebutkan pada tahap sebelumnya. Seperti 2 aktivitas sebelumnya, maka proses ini juga harus didokumentasikan sebagai konfigurasi dari software.
Coding. Untuk dapat dimengerti oleh mesin, dalam hal ini adalah komputer, maka desain tadi harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin, yaitu ke dalam bahasa pemrograman melalui proses coding. Tahap ini merupakan implementasi dari tahap design yang secara teknis nantinya dikerjakan oleh programmer.
Testing / Verification. Sesuatu yang dibuat haruslah diujicobakan. Demikian juga dengan software. Semua fungsi-fungsi software harus diujicobakan, agar software bebas dari error, dan hasilnya harus benar-benar sesuai dengan kebutuhan yang sudah didefinisikan sebelumnya.
Maintenance. Pemeliharaan suatu software diperlukan, termasuk di dalamnya adalah pengembangan, karena software yang dibuat tidak selamanya hanya seperti itu. Ketika dijalankan mungkin saja masih ada errors kecil yang tidak ditemukan sebelumnya, atau ada penambahan fitur-fitur yang belum ada pada software tersebut. Pengembangan diperlukan ketika adanya perubahan dari eksternal perusahaan seperti ketika ada pergantian sistem operasi, atau perangkat lainnya.
B.      Karakteristik
Dalam model ini terdapat beberapa sifat-sifat yang menojol dan cenderung menjadi permasalahan pada model waterfall.
Ketika problem muncul, maka proses berhenti karena tidak dapat menuju ke tahapan selanjutnya. Apabila terdapat kemungkinan problem tersebut muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi tahapan sebelumnya agar problem ini tidak muncul.
Karena pendekatannya secara sequential, maka setiap tahap harus menunggu hasil dari tahap sebelumnya. Hal itu tentu membuang waktu yang cukup lama, artinya bagian lain tidak dapat mengerjakan hal lain selain hanya menunggu hasil dari tahap sebelumnya.

C. Mengapa Model Ini Sangat Populer?
        Selain karena pengaplikasian menggunakan model ini mudah, kelebihan dari model ini adalah ketika semua kebutuhan sistem dapat didefinisikan secara utuh, eksplisit, dan benar di awal project, maka SE dapat berjalan dengan baik dan tanpa masalah. Meskipun seringkali kebutuhan sistem tidak dapat didefinisikan seeksplisit yang diinginkan, tetapi paling tidak, problem pada kebutuhan sistem di awal project lebih ekonomis dalam hal uang (lebih murah), usaha, dan waktu yang terbuang lebih sedikit jika dibandingkan problem yang muncul pada tahap-tahap selanjutnya.
            Meskipun demikian, karena model ini melakukan pendekatan secara urut / sequential, maka ketika suatu tahap terhambat, tahap selanjutnya tidak dapat dikerjakan dengan baik dan itu menjadi salah satu kekurangan dari model ini. Selain itu, ada beberapa kekurangan pengaplikasian model ini, antara lain adalah sebagai berikut:
Ketika problem muncul, maka proses berhenti, karena tidak dapat menuju ke tahapan selanjutnya. Bahkan jika kemungkinan problem tersebut muncul akibat kesalahan dari tahapan sebelumnya, maka proses harus membenahi tahapan sebelumnya agar problem ini tidak muncul. Hal-hal seperti ini yang dapat membuang waktu pengerjaan SE.
Karena pendekatannya secara sequential, maka setiap tahap harus menunggu hasil dari tahap sebelumnya. Hal itu tentu membuang waktu yang cukup lama, artinya bagian lain tidak dapat mengerjakan hal lain selain hanya menunggu hasil dari tahap sebelumnya. Oleh karena itu, seringkali model ini berlangsung lama pengerjaannya.
Pada setiap tahap proses tentunya dipekerjakan sesuai spesialisasinya masing-masing. Oleh karena itu, ketika tahap tersebut sudah tidak dikerjakan, maka sumber dayanya juga tidak terpakai lagi. Oleh karena itu, seringkali pada model proses ini dibutuhkan seseorang yang “multi-skilled”, sehingga minimal dapat membantu pengerjaan untuk tahapan berikutnya.
d.  Kapan Model Waterfall Di Gunakan?????             Salah satu model tradisional dan mudah yang tahapannya mengalir satu arah seperti air terjun adalah Waterfall Model atau Linear Sequential Model. Pertanyaannya, kapan sebaiknya model tersebut digunakan?


Teori-teori lama menyimpulkan ada beberapa hal, yaitu:
Ketika semua persyaratan sudah dipahami dengan baik di awal pengembangan.
Definisi produk stabil dan tidak ada perubahan saat pengembangan untuk alasan apapun seperti perubahan eksternal, perubahan tujuan, perubahan anggaran atau perubahan teknologi. Untuk itu, teknologi yang digunakan pun harus sudah dipahami dengan baik.
Menghasilkan produk baru, atau versi baru dari produk yang sudah ada. Sebenarnya, jika menghasilkan versi baru maka sudah masuk incremental development, yang setiap tahapnya sama dengan Waterfall kemudian diulang-ulang.
Porting produk yang sudah ada ke dalam platform baru.
Dengan demikian, Waterfall dianggap pendekatan yang lebih cocok digunakan untuk proyek  pembuatan sistem baru. Tetapi salah satu kelemahan paling dasar adalah menyamakan pengembangan perangkat keras dengan perangkat lunak dengan meniadakan perubahan saat pengembangan. Padahal, galat diketahui saat perangkat lunak dijalankan, dan perubahan-perubahan akan sering terjadi.
3. Tahap Pengembangan Waterfall
Tahap – tahap pengembangan waterfall model adalah
   Analisis dan definisi persyaratan        Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user.
Perancangan sistem dan perangkat lunak Kegiatan ini menentukan arsitektur sistem secara keseluruhan
Implementasi dan pengujian unit Perancangan perangkat lunak direalisasikan sebagai serangkaian program
Integrasi dan pengujian sistem Unit program diintegrasikan atau diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sitem telah terpenuhi
Operasi dan pemeliharaan Merupakan fase siklus yang paling lama. Sistem diinstall dan dipakai. Perbaikan mencakup koreksi dari berbagai error, perbaikan dan implementasi unit sistem dan pelayanan sistem.




4.      Kelebihan dari Model Waterfall
Merupakan model pengembangan paling handal dan paling lama digunakan.
Cocok untuk system software berskala besar.
Cocok untuk system software yang bersifat generic.
Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol

5.      Kelemahan Waterfall
Waktu pengembangan lama. hal ini dikarenakan input tahap berikutnya adalah output dari tahap sebelumnya. Jika satu tahap waktunya molor, maka waktu keseluruhan pengembangan juga ikut molor.
Biaya juga mahal, hal ini juga dikarenakan waktu pengembangan yang lama
Terkadang perangkat lunak yang dihasilkan tidak akan digunakan karena sudah tidak sesuai dengan requirement bisnis customer. hal ini juga dikarenakan waktu pengembangan yang lama. selain itu dikarenakan waterfall merupakan aliran yang linear, sehingga jika requirement berubah proses tidak dapat diulang lagi.
Karena tahap-tahapan pada waterfall tidak dapat berulang, maka model ini tidak cocok untuk pemodelan pengembangan sebuah proyek yang memiliki kompleksitas tinggi.
Meskipun waterfall memiliki banyak kelemahan yang dinilai cukup fatal, namun model ini merupakan dasar bagi model-model lain yang dikembangkan setelahnya.

Kesimpulan
Perkembangan dunia industri teknologi di dunia semakin pesat, hal ini menjadikan persaingan setiap perusahaan semakin kuat pula. Jika di hubungkan dengan pemodelan analisis perangkat lunak terletak pada jenis pemodelannya, karena pada dasarnya pemodelan analisis bermacam-macam. Hal inilah yang di manfaatkan oleh perusahaan perangkat lunak atau pembuatan software.                                                                                                 

Inceremental Model

Inceremental Model

Incremental model adalah model pengembangan sistem pada software engineering berdasarkan requirement software yang dipecah menjadi beberapa fungsi atau bagian sehingga model pengembangannya secara bertahap. dilain pihak ada mengartikan model incremental sebagai  perbaikan dari model waterfall dan sebagai standar pendekatan topdown. Layaknya Model Waterfall, model ini pun juga memiliki tahapan tahapan untuk perancangan perangkat lunaknya, yaitu:
Requirement , Requirment adalah proses tahapan awal yang dilakukan pada incremental model adalah penentuan kebutuhan atau analisis kebutuhan.
Specification, Specification adalah proses spesifikasi dimana menggunakan analisis kebutuhan sebagai acuannya.
Architecture Design, adalah tahap selanjutnya, perancangan software yang terbuka agar dapat diterapkan sistem pembangunan per-bagian pada tahapan selanjutnya.
Code setelah melakukan proses desain selanjutnya ada pengkodean.
Test merupakan tahap pengujian dalam model ini.
        Tahapan-tahapan dilakukan secara berurutan. Setiap bagian yang sudah selesai dilakukan testing, dikirim ke pemakai untuk langsung dapat digunakan. Pada incremental model, tiga tahapan awal harus diselesaikan terlebih dahulu sebelum sebelum tahap membangun tiap increment. Untuk mengantisipasi kondisi yang terjadi pada incremental model, diperkenalkan model More Risky Incremental Model. Model ini menerapkan sistem kerja yang paralel. Setelah daftar kebutuhan didapatkan dari pemakai, tim spesifikasi membuat spesifikasi untuk modul pertama. Setelah spesifikasi pertama selesai, tim desain menindak lanjuti. Tim spesifikasi sebelumnya juga langsung membuat spesifikasi untuk model kedua, dan seterusnya. Jadi, tidak harus menunggu modul pertama selesai hingga dikirim ke user.

Kelebihan Dari Mode Incremental:
Merupakan model dengan manajemen yang sederhana
Pengguna tidak perlu menunggu sampai seluruh sistem dikirim untuk mengambil keuntungan dari sistem tersebut. Increment yang pertama sudah memenuhi persyaratan mereka yang paling kritis, sehingga perangkat lunak dapat segera digunakan.
Resiko untuk kegagalan proyek secara keseluruhan lebih rendah. Walaupun masalah masih dapat ditemukan pada beberapa increment. Karena layanan dengan prioritas tertinggi diserahkan pertama dan increment berikutnya diintegrasikan dengannya, sangatlah penting bahwa layanan sistem yang paling penting mengalami pengujian yang ketat. Ini berarti bahwa pengguna akan memiliki kemungkinan kecil untuk memenuhi kegagalan perangkat lunak pada increment sistem yang paling bawah.
Nilai penggunaan dapat ditentukan pada setiap increment sehingga fungsionalitas sistem disediakan lebih awal.
Memiliki risiko lebih rendah terhadap keseluruhan pengembagan sistem,
Prioritas tertinggi pada pelayanan sistem adalah yang paling diuji

Kelemahannya  :
kemungkinan tiap bagian tidak dapat diintegrasikan
Dapat menjadi build and Fix Model, karena kemampuannya untuk selalu mendapat perubahan selama proses rekayasa berlangsung
Harus Open Architecture
Mungkin terjadi kesulitan untuk memetakan kebutuhan pengguna ke dalam rencana spesifikasi masing-masing hasil increment.

MODEL SPIRAL REKAYASA PERANGKAT LUNAK

MODEL SPIRAL
REKAYASA PERANGKAT LUNAK

Pengertian model spiral
Model Spiral (spiral model) adalah salah satu bentuk dari Metode Pengembangan Perangkat Lunak atau yang disebut SDLC (Software Development Life Cycle), yang sangat populer digunakan dalam bidang teknologi informasi. Model Spiral adalah gabungan dari Model Prototyping dan Model Waterfall dengan penekanan yang tinggi pada analisis risiko tiap tahapannya. Bentuk ini bersifat iteratif atau berulang dengan mengontrol aspek yang teratur dari sekuensial linier. Fungsi Model Spiral ini adalah untuk melakukan perubahan, penambahan dan pengembangan suatu software dengan deretan pertambahan menjadi lebih baik secara cepat dan tepat berdasarkan keinginan dan kebutuhan penggunanya.

Model ini ditemukan, yaitu pada sekitar tahun 1988 oleh Barry Boehm pada artikel A Spiral Model of Software Development and Enhancement. Spiral model adalah salah satu bentuk evolusi yang menggunakan metode iterasi natural yang dimiliki oleh model prototyping dan di gabungkan dengana speksistimatis yang dikembangkan dengan model waterfall. Tahap desain umumnya di gunakan pada model Waterfall, sedangkan tahap prototyping adalah suatu model dimana software dibuat prototype (incomplete model), “blue-print”-nya, atau contohnya dan ditunjukkan ke user / customer untuk mendapatkan feedback-nya. Jika prototype-nya sudah sesuai dengan keinginan user / customer, maka proses SE di lanjutkan dengan membuat produk sesungguhnya dengan menambah dan memperbaiki kekurangandari prototype tadi.
Model ini juga mengkombinasikan top-down design dengan bottom-up design, dimana top-down design menetapkan sistem global terlebih dahulu, baru di teruskan dengan detail sistemnya, sedangkan bottom-up design berlaku sebaliknya. Top-down design biasanya di aplikasikan pada model waterfall dengan sequential-nya, sedangkan bottom-up design biasanya di aplikasikan pada model prototyping dengan feedback yang diperoleh. Dari 2 kombinasi tersebut, yaitu kombinasi antara desain dan prototyping, serta top-down dan bottom-up, yang juga di aplikasikan pada model waterfall dan prototype, maka spiral model ini dapat dikatakan sebagai model proses hasil kombinasi dari kedua model tersebut. Oleh karena itu, model ini biasanya dipakai untuk pembuatan software dengan skala besar dan kompleks.
Sejarah model spiral
Tahun 1986, model ini dikenalkan pertama kali oleh Barry Boehm pada makalahnya yang berjudul “A Spiral Model of Software Development and Enhancement”.  Makalah tersebut menjelaskan tentang sebuah diagram yang dihasilkan dari berbagai publikasi yang mendiskusikan tentang Model Spiral ini. Model ini merupakan model yang sudah lama, tetapi sangat berguna untuk melakukan pembangunan proyek-proyek besar.
Pada makalah awal yang dibuatnya, Barry Boehm menganggap bahwa Model Spiral adalah suatu model proses yang berhubungan dengan inkrementasi, Model Waterfall dan Model Prototyping.
Namun dalam publikasi selanjutnya, Boehm menjelaskan bahwa Model Spiral sebagai model proses generator yang mana pilihan berdasarkan risiko proyek untuk menghasilkan suatu model proses yang tepat untuk proyek tersebut. Dengan demikian, inkrementasi, Model Waterfall dan Model Prototyping adalah kasus khusus dengan pola risiko proyek tertentu dari Model Spiral.
Tahap-tahap Spiral Model
Dalam Model Spiral terdapat lima tahap untuk merealisasikan penggunaannya sebagai berikut :

1. Tahap Liason
Tahap ini berhubungan dengan komunikasi antara orang yang akan mengembangkan software (system analyst) dengan pelanggan. Tujuannya adalah agar dapat memuaskan pelanggan dengan memperbaiki dan mengembangkan software sesuai dengan kebutuhan, kepentingan dan keinginannya.

2. Tahap Planning
Tahap perencanaan meliputi estimasi biaya yang digunakan, batas waktu, pengaturan jadwal, identifikasi lingkungan kerja, sumber-sumber infomasi untuk melakukan iterasi. Hasilnya adalah dokumen spesifikasi kebutuhan sistem dan bisnis.

3. Tahap Analisis Risiko
Tahap ini berfungsi untuk mengidentifikasi risiko yang berpotensial untuk terjadi dan menghasilkan suatu solusi alternatif secara teknis dan manajemen saat strategi mitigasi risiko direncanakan dan diselesaikan.

4. Tahap Rekayasa (engineering)
Pada tahap ini, yang dilakukan adalah sebagai berikut :
Menguji, coding dan mengembangkan software
Menginstal software
Membuat prototipe
Mendesain dokumen
Meringkas suatu pengujian software
Membuat laporan atas kekurangan dari software agar segera diperbaiki

5. Tahap Evaluasi
Peran pelanggan sangat diperlukan pada tahap ini. Mereka dapat memberikan masukan dan tanggapan, mengevaluasi produk kerja dan memastikan bahwa produk yang dibutuhkan sesuai dengan semua ketentuan. Jika terdapat perubahan, semua tahapan akan diperbaiki sesuai dengan kepuasan pelanggan. Namun, mengidentifkasi dan memantau risiko yang terjadi juga diperlukan, seperti cost overrun.
Sektor-sektor pada Spiral Model

Mengidentifikasi tujuan, alternatif, dan kendala setiap tahap secara spesifik 2.
Mengevaluasi alternatif, menilai resiko dan pengurangannya, aktifitas ditempatkan untuk mengurangi resiko kunci3.
Pengembangan dan validasi
Proyek ditinjau ulang dan tahap spiral berikutnya direncanakan
Penggunaan Spiral Model
Model Spiral tepat digunakan dalam hal sebagai berikut :
Ketika memiliki sebuah proyek dengan risiko sedang hingga tinggi
Komitmen proyek jangka panjang karena potensi perubahan pada prioritas ekonomi dalam perubahan waktu
Lini produk baru yang harus dirilis secara bertahap untuk mendapatkan feedback pelanggan dengan cukup
Ketika penciptaan prototipe berlaku
Perubahan signifikan yang diharapkan dalam produk selama siklus pengembangan
Persyaratan yang kompleks dan memerlukan suatu evaluasi
kelebihan dan Kekurangan Spiral Model

Kelebihan dalam menggunakan Model Spiral, yaitu :
Perubahan-perubahan yang terjadi dapat diselesaikan secara sistematis
Estimasi biaya menjadi mudah karena pembuatan prototipe telah selesai dalam fragmen yang kecil
Manajemen dan analisis risiko yang lebih baik
Pembangunan yang cepat dan mudah secara sistematis
Manajemen waktu yang lebih baik
Mudah dalam melakukan perubahan kebutuhan dan dokumentasi jika perubahan terjadi di tengah-tengah perubahan
Produksi software terjadi lebih cepat
Kekurangan dalam menggunakan Model Spiral, yaitu :
Tidak cocok ketika digunakan dalam proyek-proyek kecil
Tidak terlalu berguna dalam proyek-proyek kecil
Sulit dalam mengikuti strategi proyek kecil
Kurang efisien dalam penerapan model spiral karena waktu yang digunakan
Membutuhkan sumber pengalaman sebagai proses sehingga sangat kompleks
Dalam melakukan proyek kecil, estimasi biaya akan sangat tinggi
Risiko dalam tahap planning, jika terjadi perbedaan dalam jadwal pengembangan atau dalam anggaran belanja.

COMPONENT ASSEMBLY MODEL ( CAM )

COMPONENT ASSEMBLY MODEL ( CAM )


A.Pengertian CAM

Component Assembly Model (CAM) adalah suatu model Metodologi Penelitian RPL yang merupakan gabungan dari berbagai model lain karena terdapat beberapa kesamaan dari Model RPL Prototype, Spiral Boehm dan RAD.

Sifat karakteristik dari CAM yaitu yang seperti saya sebutkan tadi Model Spiral Boehm dan sangat erat keterikatannya dengan model RAD (Rapid Application Development), model karena model CAM ini menggunakan peralatan-peralatan dan GUI (Graphic User Interface) untuk membangun software.

Dengan kata lain pembuatan aplikasinya dibuat dari paket perangkat lunak yang berisi serangkaian komponen yang telah ada sebelumnya. Namun, waktu yang dibutuhkan dapat disesuaikan atau lebih efektif daripada harus mengerjakan program dari awal.

Seperti yang sudah saya sebutkan tadi CAM ini mirip dengan prototype model karena dalam pengembangannya di haruskan membuat prototype sesuai dengan kebutuhan customer agar lebih pasti perancangannya dan sesuai keinginan, dengan langkah ini artinya dapat menghemat dari segi efesiensi waktu dalam pengerjaanya.

 PEMBAHASAN


A.Tahapan-tahapan CAM yaitu sebagai berikut :

Tahap identifikasi calon-calon komponen (Kelas Objek)
Tahap melihat komponen-komponen dalam pustaka
Tahap mengekstrak komponen
Tahap membangun komponen
Tahap menyimpan komponen baru pada pustaka
Tahap mengkonstruksi iterasi ke-N dari sistem.

Kelebihan CAM adalah tinggal mencaplok atau menggunakan program atau komponen yang sudah ada dan menyusunnya menjadi sebuah program yang lebih kompleks dan berkembang sesuai dengan kebutuhan user/pengguna sehingga dapat mengefisienkan penggunaan waktu dan tenaga.  Selain itu, model ini juga menyediakan kemampuan untuk memvisualisasikan hasil rakitan dengan kesanggupan untuk mengukur, menganalisa, merancang dan merancang ulang program.

Kekurangan CAM adalah seringnya program atau komponen-komponen terdahulu tidak kompatibel atau sejalan dengan model perakitan komponen ini sehingga untuk perusahaan berskala kecil akan kesulitan menemukan komponen yang sesuai untuk dirakit.


KESIMPULAN

Jadi Kesimpulan-nya bahwa CAM sangat sesuai digunakan oleh perusahaan besar yang sudah berpengalaman mengembangkan software, mereka dapat memanfaatkan software-software yang telah umum dikembangkan sebelumnya menjadi bentuk baru dari software yang ingin dikomersilkan dan para pengembang hanya perlu mengetahui kebutuhan pelanggan, mencari komponen yang berguna yang berguna untuk menjawab kebutuhan pelanggan dan akhirnya menempatkan mereka bersama-sama untuk membangun sebuah program baru yang bermanfaat.

APA ITU 4GT Dan kesimpulanya

APA ITU 4GT (FOURTH GENERATION TRCHNIQUES)

FOURTH GENERATION TRCHNIQUES/ 4GT  adalah seperanagkat peralatan software yang fungsinya sebagai perangkat pembantu untuk memudahkan seorang pengembang  software untuk mengaplikasikan karakteristik software tersebut, dari situ akan menghasilkan soucrce code dan object code yang secara otomatis sesuai dengang persyaratan khususnya yang dibuat oleh pengembang sofware tersebut.

TOOL 4GT adalah bahasa non prosedur antara lain:

1.DataBase Query

2.Pembentukan laporan ( Report Generation )

3.Manipulasi data

4.Definisi dan interaksi layar (screen)

5.Pembentukan object dan source ( Object and source generation )

6.Kemampuan grafik yang tinggi, dan

7.Kemampuan spreadsheet

Kelebihan

Pengurangan waktu dan peningkatan produktivitas secara besar

Tool yang menggunakan metode pengembangan perangkat lunak 4GL bisa meng-generate sistem dari output yang dihasilkan oleh CASE tools

Kekurangan

Penggunaan perangkat bantu (tools) dibandingkan dengan bahasa pemrograman, dan juga kode sumber yang dihasilkannya tidak efisien.

Penggunaan 4GT tanpa perencanaan matang (untuk proyek besar) akan menyebabkan kesulitan yang sama (kualitas dan pemeliharaan yang jelek, ketidakpuasan pelanggan) seperti dengan metode konvensional.

KESIMPULAN

Fourth Generation Techniques (4GT) mencakup seperangkat peralatan perangkat lunak yang berfungsi sebagai perangkat bantu yang memudahkan seorang pengembang software mengaplikasi beberapa karakteristik software pada tingkat yang tinggi, yang akan menghasilkan source code dan object code secara otomatis sesuai dengan spesifikasi (persyaratan khusus) yang dibuat oleh sang pengembang perangkat lunak itu sediri

Pengertian Dan Kesimpulan Prototyping Model

Pengertian Dan Kesimpulan Protyping Model


Prototyping perangkat lunak (software prototyping) atau siklus hidup menggunakan protoyping (life cycle using prototyping) adalah salah satu metode siklus hidup sistem yang didasarkan pada konsep model bekerja (working model). Tujuannya adalah mengembangkan model menjadi sistem final. Artinya sistem akan dikembangkan lebih cepat daripada metode tradisional dan biayanya menjadi lebih rendah Ada banyak cara untuk memprotaoyping, begitu pula dengan penggunaannya. Ciri khas dari metodologi adalah pengembang sistem (system developer), klien, dan pengguna dapat melihat dan melakukan eksperimen dengan bagian dari sistem komputer dari sejak awal proses pengembangan.


Dengan prototype yang terbuka, model sebuah sistem (atau bagiannya) dikembangkan secara cepat dan dipoles dalam diskusi yang berkali-kali dengan klien .Model tersebut menunjukkan kepada klien apa yang akan dilakukan oleh sistem, namun tidak didukung oleh rancangan desain struktur yang mendetil.] Pada saat perancang dan klien melakukan percobaan dengan berbagai ide pada suatu model dan setuju dengan desain final rancangan yang sesungguhnya dibuat tepat seperti model dengan kualitas yang lebih bagus. Protoyping membantu dalam menemukan kebutuhan di tahap awal pengembangan, terutama jika klien tidak yakin dimana masalah berasal. Selain itu protoyping juga berguna sebagai alat untuk mendesain dan memperbaiki user interface bagaimana sistem akan terlihat oleh orang-orang yang menggunakannya.


Salah satu hal terpenting mengenai metodologi ini, cepat atau lambat akan disingkirkan dan hanya digunakan untuk tujuan dokumentasi. Kelemahannya adalah metode ini tidak memiliki analisis dan rancangan yang mendalam yang merupakan hal penting bagi sistem yang sudah kokoh, terpercaya dan bisa dikelola. Jika seorang pengembang memutuskan untuk membangun jenis prototipe ini, penting untuk memutuskan kapan dan bagaimana ia akan disingkirkan dan selanjutnya menjamin bahwa hal tersebut telah diselesaikan tepat pada waktunya.


sejarah prototyping

Pada tahun 1960-an: Teknik-teknik prototyping pertama cepat menjadi diakses pada tahun delapan puluhan kemudian dan mereka digunakan untuk produksi komponen prototipe dan model. Sejarah prototipe cepat dapat ditelusuri sampai akhir tahun enam puluhan, ketika seorang profesor teknik, Herbert Voelcker, mempertanyakan dirinyasendiri tentang kemungkinan melakukan hal-hal menarik dengan alat komputer dikontroldan otomatis mesin. Alat-alat mesin baru saja mulai muncul di lantai pabrik itu. Voelcker berusaha mencari jalan di mana alat-alat mesin otomatis dapat diprogram denganmenggunakan output dari program desain komputer.Kemudian 1970: Voelcker mengembangkan alat dasar matematika yang dengan jelas menggambarkan tiga aspek dimensi dan menghasilkan teori-teori awal teori algoritma dan matematika untuk pemodelan solid. Teori-teori ini membentuk dasar program komputer modern yang digunakan untuk merancang hampir segala hal mekanis,mulai dari mobil mainan terkecil ke gedung pencakar langit tertinggi.


Teori Volecker berubah metode perancangan pada tahun tujuh puluhan, namun, metode lama untuk merancang masih sangat banyak digunakan. Metode lama terlibat baik alat masinis ataumesin dikendalikan oleh komputer. Para cowok logam dipotong dan bagian yangdibutuhkan tetap sesuai kebutuhan. Namun, pada tahun 1987, Carl Deckard, bentuk peneliti dari University of Texas,datang dengan ide yang revolusioner yang baik.


Dia memelopori manufaktur yang berbasis lapisan, dimana ia memikirkan membangun lapisan model dengan lapisan. Diadicetak model 3D dengan menggunakan sinar laser untuk bedak sekering logam dalam prototipe solid, single layer pada suatu waktu. Deckard mengembangkan ide ini menjadisebuah teknik yang disebut "Selective Laser Sintering".










Kesimpulan


Metode prototyping melakukan bentuk antsipatif terhadap kesalahpahaman idea atau spesifikasi kebutuhan user dari percakapan yang dilakukan dari metode lainnya. Sehingga dari hasil paparan teori diatas jelas bahwa metode prototyping memilki kelebihan dalam hal komunikasi antara user dan analis untuk menemukan spesifikasi yang sesuai dan ideal. Metode prototyping melakukan design secara cepat (quick design) untuk menyelesaikan sebuah perangkat lunak.


Dalam pembuatan sebuah perangkat lunak metode ini melibatkan secara lebih aktif kepada user untuk mengutarakan spesifikasi personalnya kepada analis. Sehingga analis akan dapat sedikitnya memahami dengan betul apa yang menjadi keinginan dari user atau client yang bersangkutan.

Rekayasa perangkat lunak

Apakah Perangkat Lunak Itu ?

Perangkat Lunak adalah definisi dan organisasi dari sekumpulan task dan fungsi yang dienkapsulasi dalam bentuk yang dapat dieksekusi oleh komputer.
Beberapa tipe Perangkat Lunak :

• Commercial-Off-the-Shelf (COTS)
• Government-Off-the-Shelf (GOTS)
• Legacy: ditulils dalam bahasa pemrograman ‘sebelumnya’
• Cobol, PL/1 (Y2k/SNET), Fortran, etc
• C and C++!
• Customized New Software
• Client vs Server Software
• Database Management System / Applications

Rekayasa : Aplikasi keilmuan untuk penyelesaian permasalahan praktis.
Rekayasa Perangkat Lunak : Aplikasi ilmu komputer untuk membangun sistem perangkat lunak praktis.
Pemrograman :

• Individu menulis keseluruhan program
• Satu orang, satu komputer
• Well-defined Problem
• Programming-in-the-Small

Rekayasa Perangkat Lunak :

• Individu menulis komponen program
• Tim membangun keseluruhan program
• Programming-in-the-Large

Aplikasi dari merekayasa Perangkat Lunak.
Wilayah Computer Science Engineering yang berhubungan dengan sistem Perangkat Lunak.

• Besar dan kompleks
• Dibangun oleh tim
• Terdapat beberapa versi
• Berakhir beberapa tahun
• Undergo changes

Definisi :

• Aplikasi yang menggunakan pendekatan sistematis, disiplin, terukur untuk mengembangkan, mengoperasikan, dan memelihara Perangkat Lunak (IEEE 1990)
• Pembangunan oleh banyak orang (multi-person) dari Perangkat Lunak multi-version (Parnas 1978)

Mengapa Rekayasa Perangkat Lunak ?

Kompleksitas program melebihi programmer individu atau sendiri.
Rekayasa Perangkat Lunak ditarget untuk :

• Membangun aplikasi Perangkat Lunak besar
• Mendefinisikan permasalahan dengan jelas dan komplit
• Perangkat dan teknik untuk mendukung proses
• Team-Oriented experienced

Rekayasa Perangkat Lunak  harus berkembang menjadi Engineering discipline.
Rekayasa Perangkat Lunak harus memajukan dan mendukung konstruksi multi-person dari Perangkat Lunak multi-version.

Sejarah RPL

“Early Days”

• Tahun 1950 programmer menulis program
• Awal 1960 – Pembangunan project software skala sangat besar oleh “Expert”
• Pertengahan akhir 1960 – Muncul aplikasi software komersial skala besar (sistem besar melibatkan tim dan muncul istilah “Software Engineering”)

Disiplin RPL

• Individu tidak dapat melihat “Big Picture”
• Meningkatnya waktu komunikasi
• Perubahan personal berakibat pada produktifitas

RPL : Manajemen, organisasi, perangkat, teori, metodologi, teknik, dll.

Pengaruh RPL

Harga software terus meningkat, membutuhkan produksi software yang lebih efisien

• Software acquisition vs outsourcing
• Software reuse vs build-from-scratch

Kompleksitas Perangkat Lunak Besar berubah dalam bentuk perspektif pengembangan : Konsep – Desain – Pengembangan – Integrasi – Distribusi – Dokumentasi – Pemeliharaan – Evolusi – Perluasan.

Pertumbuhan RPL / Computer Science :

• 350.000 pekerjaan teknologi informasi terbuka
• 100.000 pekerjaan baru setiap tahun selama 10 tahun

A. Analisa dan spesifikasi kebutuhan :

• Permasalahan apa yang dipecahkan ?
• Apa yang dibutuhkan / diinginkan pelanggan ?
• Interaksi antara SE dan pelanggan ?
• Identifikasi dan dokumentasi kebutuhan sistem
• Membangkitkan user manual dan tes plan

B. Desain dan spesifikasi

• Bagaimana permasalahan dipecahkan
• Desain High-Level
• Menentukan komponen / modul
• Transisi ke desain secara detil
• Fungsional detil dari komponen / modul

C. Coding dan Testing Modul

• Menulis kode sesuai spesifikasi desain komponen / modul
• Memisahkan testing modul individu
• Simulasi prilaku sistem dengan driver dan stub

D. Integrasi dan System Maintenance

• Integrasi komponen / modul ke dalam sub sistem
• Integrasi sub sistem ke dalam program akhir

E. Delivery dan Maintenance

• Memberikan sistem ke Konsumen / Market
• Memperbaiki buk dan version release sepanjang waktu

Sejarah Perangkat Lunak

>> Abstract Data Types (ADTs) – 1970-an
>> Object-Oriented Paradigm – 1980-an
>> Component-Based D&D – 1990-an
>> Web-Based / Distributed Computing – 2000-an

Abstract Data Types (ADTs) – 1970-an

Diusulkan oleh B. Liskov (MIT)  tahun 1975
ADTs mempromosikan pengembangan aplikasi dari pandangan informasi dan penggunaannya.
Proses desain ADT :

• Identifikasi “jenis” atau “tipe” informasi
• Membungkus informasi dan menyediakan public interface dari metode
• Menyembunyikan informasi dan kode metode dalam private implementation

ADT berhubungan dengan User-Defined Data Types
Analogi dengan Integer Data Type dan +,-,*, dll

Object-Oriented Paradigm – 1980-an

Object-Oriented Decomposition :

• Dekomposisi permasalahan ke dalam agen yang membentuk operasi
• Penekanan agen yang menyebabkan aksi

Agen terdiri dari 12 bagian :

• Hidden Implementation: data dan operasi hanya tersedia pada agen
• Public Interface: operasi tersedia untuk client dari agen

Agen hanya dapat dimodifikasi dengan operasi yang ditentukan dengan Hidden Implementation atau Public Interface

Konsep Object-Oriented

Class

• Tipe agen
• Menggambarkan perilaku

Object

• Instance dari class
• Mempresentasikan data aktual yang dimanipulasi oleh agen
• Memelihara state dari object

Method

• Operasi yang didefinisikan dalam class
• Operasi terhadap SEMUA instance dari class

Message

• Mengindikasi bahwa method dari object dikerjakan

Modul vs ADT/Class

Modul

• Menggambarkan baik state dan perilaku
• Modul Employee terdiri dari Instance Variable, Operasi, dan Program Variable
• Single instance di-share oleh semua user

Class

• Menggambarkan hanya perilaku
• Class Employee mengabaikan Program Variable
• Multiple Independent Instance membagi deklarasi class yang sama tetapi membedakan state

Kunci perbedaan: sifat dinamis class memungkinkan instance dibuat sesuai kebutuhan

Konsep Lanjutan Object-Oriented

Inheritance

• Menggunakan Class bersama-sama dengan Generalisasi dan Spesialisasi
• Memperlakukan instance dari class yang berbeda dalam bentuk seragam

Polymorphism / Dynamic Binding

• Pemilihan Run-Time dari Method dijalankan berdasarkan tipe pemanggilan instance
• Message dilewatkan dalam tipe yang dependent

Generic: A Type Parameterizable Class

• Stack mempunyai parameter untuk tipe elemen
• Pembuatan Program Variable mengikat data dan Method stack ke tipe khusus dari elemen

Stack(Real), Stack(Int), Stack(Employee)

Keuntungan Object-Oriented

Mendukung komponen software yang reusable

• Pembuatan dan testing dalam isolasi
• Integrasi dari komponen yang bekerja
• Desainer / developer melihat permasalahan pada level abtraksi lebih tinggi

Mengontrol konsistensi informasi

• Public Interface membatasi akses ke data
• Private Implementation tidak tersedia

Mempromosikan / Memfasilitasi Evolusi / Reuse software

• Inheritance ke desain lebih lanjut / Class Library
• Multiple instance dari class yang sama

Component-Based D&D – 1990-an

ADT sebagai unit abstraksi / konseptualisasi
Class adala Object-Oriented yang ekuivalen dengan ADT
Tetapi, dalam 10 tahun

• Kekuatan komputasi meledak
• Kompleksitas aplikasi meningkat
• Class adalah bagian dari hirarki inheritance
• Hirarki inheritance bagian dari Aplikasi Class Library

Dalam 10 tahun

• Muncul Java (dan sekarang .NET)
• Muncul Java Beans
• Component-Based Development Tools

Apakah Komponen itu ?

Bagaimana aplikasi dikonsepkan ?

• Inheritance Hierarchies Partition Domain
• Package sebagai kumpulan atau class yang berhubungan
• Kumpulan class, Package, hirarki inheritance membentuk Application Class Library

Bagaimana Class Library dimanfaatkan ?

• Menggunakan Class individu
• Menggunakan Package atau subset dari Package
• Menggunakan porsi utama dari hirarki inheritance
• Tool menggunakan beberapa Package dan/atau hirarki terpilih
• Tool yang menjangkau Application Class merupakan software yang didesain dengan jelek

Konsep Komponen

Komponen terdiri dari satu atau lebih Class (atau komponen lain) dan diperuntukkan untuk mendukung Pembentukan unit fungsionalitas
Peruntukan class dalam multiple component mempertahankan semantic  yang sama dalam semua keadaan
Contoh komponen

• Graphical User Interface Widget
• Major “Reused” Functionality (Algoritma untuk Searching/Sorting, Database Connection/Querying)
• Aplikasi khusus (Komponen Cost Accounting, Komponen Computational Fluid Dynamics)

Contoh Komponen

Two Sample Components:

• Komponen Tanggal (selalu tanggal valid)
• Komponen Alamat (konsistensi dalam presentasi)

Web-Based / Distributed Computing – 2000-an

Komputasi / aplikasi terdistribusi adalah :

• Sistem dari sistem
• Interoperasi dari aplikasi baru dan yang sudah ada
• Pewarisan, database, COTS, New Client dll
• Network Centric Environment
• Multi-Tier Solutions

Aplikasi komputasi terdistribusi harus :

• Mengatur, mengontrol, mengakses dan memodifikasi data
• Memungkinkan manusia berinteraksi dengan data
• Menyediakan High-Availability dan Performansi
• dapat berkembang sepanjang waktu

Apakah Aplikasi Terdistribusi

Realitas saat ini :

Alasan : Artifact – kumpulan  (DB, Legacy, COTS, GOTS, Each w/ API)

Alasan : User

• Baru dan sudah ada
• Memanfaatkan Artifact API

Aplikasi Terdistribusi

• Artifacts + User

Isu yang terjadi ?

• Bagaimana mereka berinteraksi ?
• Heterogenitas
• Masalah keamanan
• Model program  yang berbeda
• dll,

CASE

CASE (Computer-Aided Software Engineering) adalah berbagai macam program yang digunakan untuk mendukung semua kegiatan Perangkat Lunak seperti analisa persyaratan, permodelan sistem, debugging, dan pengujian

CASE bisa terdiri dari

• Editor untuk notasi yang digunakan
• Modul analisis untuk memeriksa model sistem dan membuat dokumentasinya

CASE bisa mencakup generator kode, CASE yang hanya terdiri dari editor dinamakan Lower-Case

Atribut-atribut Perangkat Lunak

Perangkat Lunak harus :

• Memberikan fungsionalitas dan kinerja yang dibutuhkan user
• Dapat dipelihara: Perangkat Lunak dapat diubah sesuai perubahan kebutuhan user
• Dapat diandalkan: Perangkat Lunak harus memiliki keandalan, keamanan dan keselamatan. Perangkat Lunak yang baik tidak menyebabkan kerusakan fisik atau ekonomi bila terjadi kegagalan sistem
• Dapat digunakan: Perangkat Lunak harus memiliki user interface yang baik dan dokumentasi yang mencukupi

Macam-macam Perangkat Lunak

Perangkat Lunak Berdasarkan Pemakai

• Generik: Perangkat Lunak yang bisa digunakan secara umum
• Spesifik: Perangkat Lunak yang dibuat berdasarkan pesanan

Perangkat Lunak Berdasarkan Fungsional

• Interfacing
• Operating System
• Perangkat Lunak Aplikasi
• CASE Tools

Perangkat Lunak Berdasarkan Pemakai

Generik: Perangkat Lunak yang bisa digunakan secara umum. Sebagai Contoh:

• Operating System seperti Microsoft Windows
• Word Processing seperti Microsoft Word, WordPad
• Spreadsheet seperti Microsoft Excell
• Beberapa aplikasi khusus bisa dibuat menjadi generik dengan membuatnya general dan mudah digunakan siapa saja seperti aplikasi akuntansi, aplikasi sekolah, dll.

Spesifik: Perangkat Lunak yang dibuat berdasarkan pesanan. Bnayak Software House yang menghasilkan Perangkat Lunak ini berdasarkan proyek/pesanan tertentu. Sebagai contoh aplikasi Rumah Sakit, aplikasi Pendidikan, aplikasi Kesehatan, dll.

Perangkat Lunak Berdasarkan Fungsional

INTERFACING: Perangkat Lunak ini menghubungkan suatu perangkat keras tertentu, seperti Hardware driver, interfaces dengan perangkat keras lain. Contoh:

• Driver untuk kamera, handphone atau perangkat keras lainnya.
• Program interface seperti sensor suhu dengan LM555, PPI 8255, Komunikasi Serial RS232

OPERATING SYSTEM: Perangkat lunak yang menjalankan sistem komputer dan merupakan interface dari sistem komputer dan program aplikasi yang berjalan di atasnya.

Beberapa OS yang dikenal secara luas:

• Windows
• Linux dan variansnya, seperti Redhat, Suse, Mandrake, Debian
  dll.
• Unix
• FreeBSD
• Machintos (Apple)

PROGRAM APLIKASI, program ini digunakan untuk keperluan tertentu, yang tujuan membantu pekerjaan manusia menjadi lebih mudah. Progranm ini yang banyak dibahas dalam pembuatan perangkat lunak.

Program Aplikasi ini tergantung pada kebutuhan dari program itu sendiri, seperti

• Program Office
• Program Graphics Design
• Program Multimedia
• Dan Lain-lain

Advertisements