MODEL MODEL SDLC

Dalam System Development life cycle Models, terdapat 12 model yang dijadikan acuan dalam rekayasa perangkat lunak, yaitu

1.Waterfall Models
2. V-Shaped Models
3. Prototype Models
4. RAD Models
5. incremental Models
6. Spiral Models
7. Agile Models
8. Extreme Programming Models
9. Opportunistic Softwere System Development Model (OSSDM) Models
10. Rational Unified Process (RUP) Models
11. Component-based development Models
12. Evolutionary development Models

1. Model Waterfall

Model SDLC air terjun (waterfall) sering juga disebut model sekuensial linier (sequential linear) atau alur hidup klasik (classic life cycle). Model air terjun menyediakan pendekatan alur hidup perangkat lunak secara sekuensial atau terurut dimulai dan analisis, desain, pengodean, pengujian, dan tahap pendukung (support). Berikut adalah gambar model air terjun:

-   Analisis kebutuhan perangkat lunak

proses pengumpulan kebutuhan dilakukan secara intensif untuk mespesifikasikan kebutuhan perangkat lunak agar dapat dipahami perangkat lunak seperti apa yang dibutuhkan oleh user. Spesifikasi - Desain

desain perangkat lunak adalah proses multi langkah yang fokus pada desain pembuatan program perangkat lunak termasuk struktur data, arsitektur perangkat lunak, representasi antarmuka, dan prosedur pengodean.

-   Pembuatan kode program

desain harus ditranslasikan ke dalam program perangkat lunak. Hasil dan tahap ini adalah program komputer sesuai dengan desain yang telah dibuat pada tahap desain.

-   Pengujian

pengujian fokus pada perangkat lunak secara dan segi lojik dan fungsional dan memastikan bahwa semua bagian sudah diuji.

Kelebihan Metode Waterfall

• Kualitas dari sistem yang dihasilkan akan baik. Ini dikarenakan oleh pelaksanaannya secara bertahap. Sehingga tidak terfokus pada tahapan tertentu.
• Document pengembangan system sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.
• Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno, daripada menggunakan pendekatan asal-asalan.

Kelemahan waterfall

• Diperlukan majemen yang baik, karena proses pengembangan tidak dapat dilakukan secara berulang sebelum terjadinya suatu produk.
• Kesalahan kecil akan menjadi masalah besar jika tidak diketahui sejak awal pengembangan yang berakibat pada tahapan selanjutnya.
• Pelanggan sulit menyatakan kebutuhan secara eksplisit sehingga tidak dapat mengakomodasi ketidak pastian pada saat awal pengembangan.
• Pelanggan harus sabar, karena pembuatan perangkat lunak akan dimulai ketika tahap desain sudah selesai.

II. Model Prototipe

Model prorotipe (prototyping model) dimulai dan mengumpulkan kebutuhan pelanggan terhadap perangkat lunak yang akan dibuat. Lalu dibuatlah program protipe agar pelanggan lebih terbayang dengan apa yang sebenarnya diinginkan. Program prototipe biasanya merupakan program yang belum jadi. Program ini biasanya menyediakan tampilan dengan simulasi alur perangkat lunak sehingga tampak seperti perangkat lunak yang sudah jadi. Program prototipe ini dievaluasi oleh pelanggan atau user sampai ditemukan spesifikasi yang sesuai dengan keinginan pelanggan atau user.

Berikut adalah gambar dan model prototipe:

Mock-up adalah sesuatu yang digunakan sebagai model desain yang digunakan untuk mengajar, demonstrasi, evaluasi desain, promosi, atau keperluan lain. Sebuah mock-up disebut sebagai prototipe perangkat lunak jika menyediakan atau mampu mendemonstrasikan sebagian besar fungsi sistem perangkat lunak dan memungkinkan pengujian desain sistem perangkat lunak. Iterasi terjadi pada pembuatan prototipe sampai sesuai dengan keinginan pelanggan (customer) atau user.

Kelebihan:

·      Menghemat waktu untuk pengembangan.

·      Adanya komunikasi yang terjalin baik antara Pengembang dan Customer.

·      Pengembang dapat bekerja dengan lebih baik dalam menentukan kebutuhan pelanggan.

·      Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.

·      User dapat berpartisipasi aktif dalam pengembangan sistem.

·      Untuk digunakan secara Standalone (Berdiri Sendiri).

·      Digunakan untuk memperluas SDLC (System Development Life Cycle).

Kelemahan:

·      Pada Model Prototype tentu saja banyak kebutuhan yang tidak ditampilkan seluruhnya karena data yang dikumpulkan hanya sebagian.

·      Prototype yang telah disetujui oleh Client harus dikembangkan oleh developer tanpa ada data tambahan dari client dan software dari prototype harus memiliki fungsi yang lengkap.

·      Banyak ketidaksesuaian pada bentuk Prototype.

·      Proses analisis dan perancangan terlalu singkat.

III. Model Rapid Appliçation Development (RAD)

Rapid Application Development (RAD) adalah model proses pengembangan perangkat lunak yang bersifat inkremental terutama untuk waktu pengerjaan yang pendek. Model RAD adalah adaptasi dan model air terjun versi kecepatan tinggi dengan menggunakan model air terjun untuk pengembangan setiap komponen perangkat lunak.

komponen masing-masing tim pengerjaan dapat dilakukan secara paralel. Berikut adalah gambar dan model RAD:

1. Pemodelan bisnis

pemodelan yang dilakukan untuk memodelkan fungsi bisnis untuk mengetahui informasi apa yang terkait proses bisnis, informasi apa saja yang harus dibuat, siapa yang harus membuat informasi itu, bagaimana alur informasi itu, proses apa saja yang terkait informasi itu.

2. Pemodelan data

memodelkan data apa saja yang dibutuhkan berdasarkan pemodelan bisnis dan mendefinisikan atribut-atributnya beserta relasinya dengan data-data yang lain.

3. Pemodelan proses

mengimplementasikan fungsi bisnis yang sudah didefinisikan terkait dengan pendefinisian data.

4. Pembuatan aplikasi

mengimplementasikan pemodelan proses dan data menjadi program. Model RAD sangat menganjurkan pemakaian komponen yang sudah ada jika dimungkinkan.

5. Pengujian dan pergantian

menguji komponen-komponen yang dibuat. Jika sudah teruji maka tim pengembang komponen dapat beranjak untuk mengembangkan komponen berikutnya.

Kelebihan:

·      Lebih efektif dari pendekatan waterfall/sequential linear dalam menghasilkan sistem yang dapat memenuhi kebutuhan langsung dari pelanggan.

·      Cocok untuk proyek yang memerlukan waktu yang singkat.

·      Pengerjaan proyek dilakukan secara team dengan tugas yang berbeda sehingga tidak ada team proyek yang menganggur selama proses pembuatan proyek.

(-) Kelemahan:

·      RAD tidak cocok digunakan untuk sistem yang mempunyai resiko teknik yang lebih tinggi.

·      Memerlukan anggota yang lebih banyak untuk menyelesaikan sebuah proyek berskala besar.

·      Pengembang dan Customer harus mempunyai komitmen yang kuat untuk menyelesaikan sebuah software.

·      Jika sistem tidak dibangun dengan benar, maka RAD akan bermasalah.

·      Jika ada perubahan ditengah-tengah pengerjaan maka harus membuat kontrak baru antara Pengembang dan Customer.

4. Pengertian Incremental 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:

1. Requirement , Requirment adalah proses tahapan awal yang dilakukan pada incremental model adalah penentuan kebutuhan atau analisis kebutuhan.
2. Specification, Specification adalah proses spesifikasi dimana menggunakan analisis kebutuhan sebagai acuannya.
3. Architecture Design, adalah tahap selanjutnya, perancangan software yang terbuka agar dapat diterapkan sistem pembangunan per-bagian pada tahapan selanjutnya.
4. Code setelah melakukan proses desain selanjutnya ada pengkodean.
5. Test merupakan tahap pengujian dalam model ini.

Beberapa Kelebihan Dari Mode Incremental atara lain :

1. Merupakan model dengan manajemen yang sederhana
2. Pengguna tidak perlu menunggu sampai seluruh sistem dikirim untuk mengambil keuntungan dari sistem tersebut
3. Resiko untuk kegagalan proyek secara keseluruhan lebih rendah. Walaupun masalah masih dapat ditemukan pada beberapa increment.
4. Nilai penggunaan dapat ditentukan pada setiap increment sehingga fungsionalitas sistem disediakan lebih awal.
5. Memiliki risiko lebih rendah terhadap keseluruhan pengembagan sistem,
6. Prioritas tertinggi pada pelayanan sistem adalah yang paling diuji

Kelemahannya adalah :

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

 Model Spiral

Model spiral (spiral model) memasangkan iteratif pada model prototipe dengan kotrol dan aspek sistematik yang diambil dan model air terjun. Model spiral menyediakan pengembangan dengan cara cepat dengan perangkat lunak yang memiliki versi yang terus bertambah fungsinya (increment).

Model spiral dibagi menjadi beberapa kerangka aktifitas atau disebut juga wilayah kerja (task region). Banyaknya wilayah kerja biasanya diantara tiga sampai enam wilayah sebagai berikut:

1. Komunikasi dengan pelanggan (customer communication) aktifitas ini diperlukan untuk membangun komunikasi yang efekiif antara pengembang (developer) dan pelanggan (customer).

2. Perencanaan (planning) aktifitas ini diperlukan untuk mendefinisikan sumber daya, waktu, dan informasi yang terkait dengan proyek.

3. Analisis risiko (risk analysis) aktifitas ini diperlukan untuk memperkirakan risiko dan segi teknis maupun manajemen.

4. Rekayasa (engineering) aktifitas ini diperlukan untuk membangun satu atau lebih representasi dan aplikasi perangkat lunak (dapat juga berupa prototipe).

5. Konstruksi dan peluncuran (construction and release) aktifitas ini dibutuhkan untuk mengonstruksi, menguji, melakukan instalasi, dan menyediakan dukungan terhadap user (misalnya dan segi dokumentasi dan pelatihan).

6. Evaluasi pelanggan (customer evaluation) aktifitas ini dibutuhkan untuk mendapatkan umpan balik berdasarkan evaluasi representasi perangkat lunak yang dihasilkan dan proses rekayasa dan diimplementasikan pada tahap instalasi.

Berikut adalah gambar model spiral:

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

V-Model

Model ini merupakan perluasan dari model waterfall. Disebut sebagai perluasan karena tahap-tahapnya mirip dengan yang terdapat dalam model waterfall. Jika dalam model waterfall proses dijalankan secara linear, maka dalam model V proses dilakukan bercabang. Dalam model V ini digambarkan hubungan antara tahap pengembangan software dengan tahap pengujiannya.

lustrasi berikut menggambarkan berbagai tahap dalam V-Model SDLC.

Ada beberapa tahapan verifikasi di V-Model, yaitu :

Business Requirement Analysis

Fase ini melibatkan komunikasi rinci dengan pelanggan untuk memahami harapan dan kebutuhan yang tepat,  Ini merupakan kegiatan yang sangat penting dan perlu dikelola dengan baik,

System Design

Desain sistem akan memiliki pemahaman dan merinci hardware lengkap dan setup komunikasi untuk produk dalam pengembangan.

Architectural Design

spesifikasi arsitektur dipahami dan dirancang dalam fase ini. Biasanya lebih dari satu pendekatan teknis diusulkan dan berdasarkan kelayakan teknis dan finansial keputusan akhir diambil. Module Design

Pada fase ini, desain internal rinci untuk semua modul sistem yang ditentukan, disebut "Desain Tingkat Rendah".

Coding Phase

Bahasa pemrograman yang paling cocok ditentukan berdasarkan sistem dan persyaratan arsitektur. pengkodean dilakukan berdasarkan pedoman coding dan standar.

Kelebihan dari V-Model SDLC

• Ini adalah model yang sangat-disiplin dan Tahapan selesai satu per satu.
• Bekerja dengan baik untuk proyek-proyek yang lebih kecil dimana persyaratan dipahami dengan baik.
• Sederhana dan mudah dimengerti dan digunakan.
• Mudah dikelola karena setiap fase memiliki spesifik kiriman dan proses review.

Kekurangan dari V-Model SDLC

• Berisiko tinggi dan ketidakpastian.
• Tidak cocok untuk proyek-proyek yang kompleks dan berorientasi objek.
• Tidak cocok untuk proyek-proyek dimana persyaratan beresiko tinggi
• Tidak cocok untuk proyek-proyek yang lama dan berkelanjutan.
• Setelah aplikasi dalam tahap pengujian, sulit untuk kembali dan mengubah fungsionalitas.

gile Process merupakan sekelompok aktifitas pembangunan perangkat lunak secara iteratif yang menekankan pada aktifitas konstruksi (desain dan koding). Agile Process mengeliminasi sebagian besar waktu untuk melakukan perencanaan sistem dan berusaha sebisa mungkin mematuhi jadwal deliver sistem yang telah dijanjikan. Requirements yang dibutuhkan secara langsung di-drive oleh pelanggan itu sendiri, dan apabila terjadi perubahan terhadap requirements tersebut, pengembang dituntut mampu beradaptasi dengan perubahan yang terjadi.

Agil Prosese terbagi menjadi beberapa bentuk, diantaranya adalah:

1. Adaptive Software Development (ASD)
2. Dynamic Systems Development Method (DSDM)
3. Scrum
4. Crystal
5. Feature Driven Development (FDD)
6. Agile Modeling (AM)
7. Lean Software Development (LSD)
8. Agile Unified Process (AUP)

Kelebihan dari agile

         Meningkatkan kepuasan kepada klien.

         Dapat melakukan review pelanggan mengenai software yang dibuat lebih awal.

         Pembangunan system dibuat lebih cepat.

         Mengurangi resiko kegagalan implementasi software dari segi non-teknis.

       Jika pada saat pembangunan system terjadi kegagalan kerugian dari segi materi relatif kecil.

Kekurangan dari agile

         Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.

Extreme Programming Models

Extreme Programming (XP) merupakan salah satu metode pengembangan software yang termasuk dalam Agile Software Development. XP menggunakan pendekatan object-oriented.

proses Extreme Programming,yaitu :
Planning. Tahap planning dimulai dengan membuat user stories yang menggambarkan output, fitur, dan fungsi-fungsi dari software yang akan dibuat.

1. Design. Design di Extreme Programming mengikuti prinsip Keep It Simple (KIS). Untuk design yang sulit, Extreme Programming akan menggunaan Spike Solution dimana pembuatan design dibuat langsung ke tujuannya.
2. Coding. Proses coding pada XP diawali dengan membangun serangkaian unit test. Setelah itu pengembang akan berfokus untuk mengimplementasikannya.
3. Testing. Tahap ini dilakukan pengujian kode pada unit test. Dalam Extreme Programming, diperkenalkan XP acceptance test atau biasa disebut customer test.

Kelebihan model Extreme Programming :  

• Komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair programming). Developer didampingi oleh pihak clien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer.
• Setiap feed back ditanggapi dengan melakukan tes, unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang, tenaga, waktu).
• Banyak ide baru dan berani mencobanya, berani mengerjakan kembali dan setiap kali kesalahan ditemukan, langsung diperbaiki.

Kelemahan model Extreme Programming :

• Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.
• Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga).

 

ANALISIS SISTEM

1. ANALISI SISTEM

Dalam menganalisis sebuah sistem, biasanya akan dilakukan terhadap beberapa aspek antara lain adalah kinerja, informasi, ekonomi, keamanan aplikasi, efisiensi dan pelayanan pelanggan. Analisis ini disebut dengan PIECES Analysis (performance, information, economy, control, efficiency and service).

Analisis PIECES ini sangat penting untuk dilakukan sebelum menganalisis sebuah sitem informasi karena dalam analisis ini biasanya akan ditemukan beberapa masalah utama maupun masalah yang bersifat gejala dari masalah utama (Whitten, 2004 : p88).

-       SISTEM

Sistem adalah sekumpulan komponen yang saling berhubungan dan bekerjasama untuk mencapai tujuan (Sommerville, 2003: p20).

2. KEBUTUHAN PERANGKAT LUNAK

Kebutuhan PL Kebutuhan perangkat lunak adalah kondisi, kriteria, syarat atau kemampuan yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang diinginkan pemakai. Terdapat tiga jenis kebutuhan PL Kebutuhan Fungsional Kebutuhan Antar Muka Kebutuhan Unjuk Kerja

-       Kebutuhan Fungsional (functional requirement)

Disebut juga kebutuhan operasional Kebutuhan yang berkaitan dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh perangkat lunak. Contoh Perangkat lunak harus dapat menyimpan semua rincian data pesanan pelanggan. Perangkat lunak harus dapat membuat laporan penjualan sesuai dengan periode waktu tertentu. Perangkat lunak harus mampu menyajikan informasi jalur pengiriman barang terpendek.

-       Kebutuhan Antarmuka (interface requirement)

Kebutuhan yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak, atau basis data. Contoh Perangkat untuk memasukkan data dapat berupa PC, keyboard, mouse atau scanner (Antarmuka Perangkat Keras) Akses ke basisdata menggunakan ODBC (Open Database Connectivity) (Antarmuka Perangkat Lunak)

3. ANALISIS KEBUTUHAN PL

Mempelajari dan memahami persoalan Mengidentifikasi kebutuhan pemakai Mendefinisikan kebutuhan perangkat lunak Membuat dokumen spesifikasi kebutuhan perangkat lunak (SKPL) Mengkaji ulang (review) kebutuhan

-        Mempelajari dan memahami persoalan

Pada tahap ini, seorang analis mempelajari masalah yang ada pada perangkat lunak yang dikembangkan sehingga dapat ditentukan Siapa pemakai yang menggunakan perangkat lunak. Dimana perangkat lunak akan digunakan . Pekerjaan apa saja dari pemakai yang akan dibantu oleh perangkat lunak. Apa saja cakupan dari pekerjaan tersebut, dan bagaimana mekanisme pelaksanaannya. Apa yang menjadi kendala dilihat dari sisi teknologi yang digunakan atau dari sisi hukum dan standar.

Analisa Kebutuhan PL

Dalam pengumpulan data, akan digunakan beberapa metode untuk menentukan kebutuhan sistem yang akan dibangun. Adapun metode yang digunakan adalah:

a. Metode Observasi

Observasi yaitu melakukan pengamatan secara langsung ke objek penelitian untuk melihat dari dekat kegiatan yang dilakukan. Apabila objek penelitian bersifat perilaku dan tindakan manusia, fenomena alam (kejadian-kejadian yang ada di alam sekitar), dan proses kerja.

b. Metode Wawancara

Adalah suatu cara pengumpulan data yang digunakan untuk memperoleh informasi langsung dari sumbernya. Wawancara ini digunakan bila ingin mengetahui hal-hal dari user secara lebih mendalam.

Ada beberapa faktor yang mempengaruhi arus informasi dalam wawancara, yaitu : pewawancara, user, pedoman wawancara, dan situasi wawancara. Sedangkan, dalam wawancara ini sendiri terdiri dari wawancara terpimpin, wawancara bebas, dan wawancara bebas terpimpin. (Sugiyono, 2010 , p;14)

c. Observasi Lapangan

Adalah merupakan suatu kegiatan yang dilakukan oleh peneliti terjun langsung ke lokasi penelitian untuk mengamati subjek dan aspek-aspek yang diamati. Observasi lapangan dapat menjamin bahwa peneliti mencatat tiap-tiap kejadian sekecil apapun yang dianggap penting dalam melakukan penelitian.

SUMBER :

https://slideplayer.info/slide/11831041/ 

https://media.neliti.com/media/publications/237604-rancang-bangun-analisis-sistem-sistem-in-f6668a92.pdf