SDLC

SDLC (Systems Development Life Cycle, Siklus Hidup Pengembangan Sistem) atau Systems Life Cycle (Siklus Hidup Sistem), dalam rekayasa sistem dan rekayasa perangkat lunak, adalah proses pembuatan dan pengubahan sistem serta model dan metodologi yang digunakan untuk mengembangkan sistem-sistem tersebut. Konsep ini umumnya merujuk pada sistem komputer atau informasi. SDLC juga merupakan pola yang diambil untuk mengembangkan sistem perangkat lunak, yang terdiri dari tahap-tahap:

·         rencana(planning)

·         analisis (analysis)

·         desain (design)

·         implementasi (implementation)

·         uji coba (testing)

·         pengelolaan (maintenance)

Dalam rekayasa perangkat lunak, konsep SDLC mendasari berbagai jenis metodologi pengembangan perangkat lunak. Metodologi-metodologi ini membentuk suatu kerangka kerja untuk perencanaan dan pengendalian pembuatan sistem informasi, yaitu proses pengembangan perangkat lunak. Terdapat 3 jenis metode siklus hidup sistem yang paling banyak digunakan, yakni:

·         siklus hidup sistem tradisional (traditional system life cycle),

·         siklus hidup menggunakan protoyping (life cycle using prototyping)

·         siklus hidup sistem orientasi objek (object-oriented system life cycle)

1.     Pengembangan sistem siklus hidup

Model Siklus Hidup Pengembangan Sistem

Pengembangan Sistem siklus hidup (SDLC), atau proses pengembangan perangkat lunak dalam rekayasa sistem , sistem informasi dan rekayasa perangkat lunak , adalah proses menciptakan atau mengubah sistem informasi, dan model dan metodologi yang digunakan orang untuk mengembangkan sistem ini.

Dalam rekayasa perangkat lunak konsep SDLC mendasari banyak jenis metodologi pengembangan perangkat lunak . Metodologi ini membentuk kerangka kerja untuk perencanaan dan pengendalian penciptaan sistem informasi yaitu proses pengembangan perangkat lunak .

2.     Sejarah

Kehidupan sistem siklus (SLC) adalah metodologi yang digunakan untuk menggambarkan proses untuk membangun sistem informasi , dimaksudkan untuk mengembangkan sistem informasi dengan cara yang sangat disengaja terstruktur dan teratur, mengulangi setiap tahap siklus hidup . Pengembangan sistem siklus hidup, menurut Elliott & Strachan & Radford (2004), "berasal dari tahun 1960, untuk mengembangkan skala besar fungsional sistem bisnis di zaman skala besar konglomerat bisnis Sistem informasi kegiatan berkisar berat. pengolahan data dan angka-angka rutinitas ".

Beberapa sistem kerangka pengembangan telah sebagian didasarkan pada SDLC, seperti analisis sistem terstruktur dan metode desain (SSADM) diproduksi untuk pemerintah Inggris Kantor Pemerintah Commerce pada tahun 1980. Sejak saat itu, menurut Elliott (2004), "tradisional pendekatan siklus hidup pengembangan sistem telah semakin digantikan dengan alternatif pendekatan dan kerangka kerja, yang berusaha mengatasi beberapa kekurangan yang melekat pada SDLC tradisional.

3.     Sistem tahapan pembangunan

Pengembangan Sistem Siklus Hidup kerangka menghasilkan urutan kegiatan untuk desainer sistem dan pengembang untuk mengikuti. Ini terdiri dari serangkaian langkah atau fase di mana setiap tahapan SDLC menggunakan hasil dari yang sebelumnya.

Sebuah Pengembangan Sistem Life Cycle (SDLC) mematuhi tahapan penting yang penting bagi para pengembang, seperti perencanaan , analisis , desain , dan implementasi , dan dijelaskan di bagian bawah. Sejumlah siklus hidup pengembangan sistem (SDLC) model telah diciptakan: air terjun, air mancur, spiral, membangun dan memperbaiki, prototyping cepat, incremental, dan sinkronisasi dan menstabilkan. Paling tua ini, dan yang paling terkenal, adalah model air terjun : urutan tahap di mana output dari setiap tahap menjadi masukan untuk selanjutnya. Tahap ini dapat dicirikan dan dibagi dalam berbagai cara, termasuk yang berikut:

• Pendahuluan analisis: Tujuan phase1 adalah melakukan analisis awal, mengajukan solusi alternatif, menggambarkan biaya dan manfaat dan menyerahkan rencana awal dengan rekomendasi.

Melakukan analisis awal: pada langkah ini, Anda perlu mengetahui tujuan organisasi dan sifat dan ruang lingkup masalah yang diteliti. Bahkan jika ada masalah yang hanya merujuk ke segmen kecil dari organisasi itu sendiri maka Anda perlu mencari tahu apa tujuan dari organisasi itu sendiri berada. Kemudian Anda perlu melihat bagaimana masalah yang sedang dipelajari cocok dengan mereka.

Mengusulkan alternatif solusi: menggali ke dalam tujuan organisasi dan masalah tertentu, Anda mungkin sudah ditutupi beberapa solusi, solusi lain yang mungkin bisa beberapa bentuk wawancara mungkin telah menemukan beberapa solusi, solusi lain yang mungkin dapat beberapa dari orang-orang wawancara dalam organisasi, klien atau pelanggan terpengaruh olehnya, pemasok dan konsultan. Anda juga dapat mempelajari apa yang pesaing lakukan. Dengan data ini, Anda dapat memiliki tiga pilihan. Anda dapat meninggalkan sistem seperti, meningkatkan, atau mengembangkan sistem baru.

Menjelaskan biaya dan manfaat.

• Analisis sistem, persyaratan definisi: Mendefinisikan tujuan proyek menjadi fungsi didefinisikan dan operasi dari aplikasi yang dimaksud. Menganalisa kebutuhan pengguna akhir informasi.

• Sistem desain: Menggambarkan fitur yang diinginkan dan operasional secara rinci, termasuk layar layout, aturan bisnis, diagram proses, pseudocode dan dokumentasi lainnya.

• Pelaksanaan: Kode nyata ditulis di sini.

• Integrasi dan pengujian: Membawa semua potongan ke dalam lingkungan pengujian khusus, kemudian memeriksa untuk kesalahan, bug dan interoperabilitas.

• Penerimaan, instalasi, penyebaran: Tahap akhir pengembangan awal, di mana perangkat lunak yang dimasukkan ke dalam produksi dan menjalankan bisnis yang sebenarnya.

• Pemeliharaan: Apa yang terjadi selama sisa hidup perangkat lunak: perubahan, koreksi, penambahan, bergerak ke platform komputasi yang berbeda dan banyak lagi. Hal ini sering terpanjang tahap.

Pada contoh berikut (lihat gambar) ini tahap siklus hidup pengembangan sistem dibagi dalam sepuluh langkah dari definisi untuk penciptaan dan modifikasi dari kerja IT produk:

Fase kesepuluh terjadi ketika sistem dibuang dan tugas yang dilakukan adalah baik dihapuskan atau ditransfer ke sistem lain. Tugas dan produk kerja untuk setiap tahap dijelaskan dalam bab-bab selanjutnya.

Tidak setiap proyek akan mengharuskan tahapan akan dijalankan secara berurutan. Namun, fase saling bergantung. Tergantung pada ukuran dan kompleksitas proyek, tahapan dapat dikombinasikan atau mungkin tumpang tindih.

Analisis sistem

Tujuan dari analisis sistem adalah untuk menentukan di mana masalahnya adalah dalam upaya untuk memperbaiki sistem. Langkah ini melibatkan mogok sistem dalam bagian yang berbeda untuk menganalisis situasi, menganalisis tujuan proyek, meruntuhkan apa yang perlu dibuat dan berusaha untuk melibatkan pengguna sehingga pasti persyaratan dapat didefinisikan.

Desain

Dalam desain sistem fungsi desain dan operasi dijelaskan secara rinci, termasuk layar layout, aturan bisnis, diagram proses dan dokumentasi lainnya. Output dari tahap ini akan menjelaskan sistem yang baru sebagai kumpulan modul atau subsistem.

Tahap desain mengambil sebagai masukan awal persyaratan diidentifikasi dalam dokumen persyaratan disetujui. Untuk kebutuhan masing-masing, satu set satu atau lebih elemen desain akan diproduksi sebagai hasil dari wawancara, lokakarya, dan / atau upaya prototipe.

Elemen desain menggambarkan fitur software yang diinginkan secara detail, dan umumnya meliputi diagram hirarki fungsional, diagram layar layout, aturan bisnis tabel, diagram proses bisnis, pseudocode, dan diagram relasi entitas lengkap dengan kamus data penuh. Unsur-unsur desain dimaksudkan untuk menggambarkan perangkat lunak secara cukup rinci bahwa programmer terampil dapat mengembangkan perangkat lunak dengan desain input yang minimal tambahan.

Pengujian

Kode ini diuji di berbagai tingkatan dalam pengujian perangkat lunak . Unit, sistem dan user pengujian penerimaan sering dilakukan. Ini adalah wilayah abu-abu sebagai pendapat yang berbeda dengan apa yang ada sebagai tahap pengujian dan berapa banyak, jika setiap iterasi terjadi. Iterasi umumnya tidak bagian dari model air terjun, tapi biasanya beberapa terjadi pada tahap ini. Dalam pengujian seluruh sistem menguji satu per satu

Berikut ini adalah jenis pengujian:

• Cacat menguji skenario gagal, termasuk pelacakan cacat
• Jalur pengujian
• Kumpulan data pengujian
• Unit testing
• Sistem pengujian
• Integrasi pengujian
• Black-kotak pengujian
• White-kotak pengujian
• Pengujian regresi
• Otomasi pengujian
• Penerimaan pengguna pengujian
• Kinerja pengujian

Operasi dan pemeliharaan

Para penyebaran sistem meliputi perubahan dan perangkat tambahan sebelum dekomisioning atau matahari terbenam dari sistem. Mempertahankan sistem ini merupakan aspek penting dari SDLC. Sebagai perubahan posisi personil dalam organisasi kunci, perubahan baru akan dilaksanakan, yang akan memerlukan sistem.

Analisis sistem dan desain

Analisis Sistem dan Desain (SAD) adalah proses mengembangkan Sistem Informasi (IS) yang efektif menggunakan perangkat keras, perangkat lunak, data, proses, dan orang-orang untuk mendukung tujuan bisnis perusahaan.

Obyek analisis berorientasi

Analisis berorientasi objek (OOA) adalah proses menganalisis tugas (juga dikenal sebagai domain masalah ), untuk mengembangkan model konseptual yang kemudian dapat digunakan untuk menyelesaikan tugas. Sebuah model OOA khas akan menjelaskan perangkat lunak komputer yang dapat digunakan untuk memenuhi satu set pelanggan didefinisikan dengan persyaratan. Selama fase analisis pemecahan masalah, programmer mungkin mempertimbangkan pernyataan persyaratan tertulis, dokumen visi formal, atau wawancara dengan para pemangku kepentingan atau pihak berkepentingan lainnya. Tugas ditangani mungkin akan dibagi menjadi beberapa sub-tugas (atau domain), masing-masing mewakili bisnis yang berbeda, teknologi, atau daerah lain yang menarik. Setiap subtask akan dianalisis secara terpisah. Pelaksanaan kendala, (misalnya, konkurensi , distribusi , ketekunan , atau bagaimana sistem ini akan dibangun) tidak dipertimbangkan selama tahap analisis, melainkan, mereka ditangani selama desain berorientasi objek (OOD).

Model konseptual yang dihasilkan dari OOA biasanya akan terdiri dari serangkaian kasus penggunaan , satu atau lebih UML diagram kelas , dan sejumlah diagram interaksi . Ini juga termasuk beberapa jenis antarmuka pengguna mock-up.

Input (sumber) untuk desain berorientasi obyek

Masukan untuk desain berorientasi obyek disediakan oleh output dari analisis berorientasi objek . Sadarilah bahwa artefak keluaran tidak harus benar-benar dikembangkan untuk melayani sebagai masukan dari desain berorientasi objek, analisis dan desain dapat terjadi secara paralel, dan dalam praktek hasil satu kegiatan dapat memberi makan yang lain dalam siklus umpan pendek melalui iteratif proses. Kedua analisis dan desain dapat dilakukan secara bertahap, dan artefak dapat terus tumbuh bukan sepenuhnya dikembangkan dalam satu tembakan.

Beberapa artefak masukan khas untuk desain berorientasi obyek adalah:

• Model konseptual : model konseptual adalah hasil dari analisis berorientasi objek, ia menangkap konsep-konsep dalam domain masalah . Model konseptual secara eksplisit memilih untuk tidak tergantung pada rincian pelaksanaan, seperti konkurensi penyimpanan atau data.

• Gunakan kasus : Gunakan kasus adalah deskripsi dari urutan peristiwa yang, bila digabungkan, menyebabkan sistem melakukan sesuatu yang bermanfaat. Setiap use case menyediakan satu atau lebih skenario yang menyampaikan bagaimana sistem harus berinteraksi dengan pengguna yang disebut aktor untuk mencapai tujuan bisnis tertentu atau fungsi. Gunakan aktor kasus mungkin end user atau sistem lainnya. Dalam keadaan banyak kasus penggunaan yang dijabarkan lebih lanjut ke dalam diagram use case. Gunakan kasus diagram digunakan untuk mengidentifikasi aktor (pengguna atau sistem lain) dan proses yang mereka lakukan.

• Sistem Urutan Diagram : Sistem diagram Sequence (SSD) adalah gambar yang menunjukkan, untuk skenario tertentu dari sebuah use case, peristiwa yang menghasilkan aktor-aktor eksternal, pesanan mereka, dan mungkin antar-sistem acara.

• User interface dokumentasi (jika ada): Dokumen yang menunjukkan dan menggambarkan tampilan dan nuansa dari produk akhir yang user interface . Hal ini tidak wajib untuk memiliki, tapi membantu untuk memvisualisasikan produk akhir dan karena itu membantu desainer.

• Relational data model (jika ada): Sebuah model data adalah model abstrak yang menggambarkan bagaimana data direpresentasikan dan digunakan. Jika objek database tidak digunakan, model data relasional biasanya harus dibuat sebelum desain, karena strategi yang dipilih untuk objek-relasional pemetaan ini merupakan hasil dari proses desain OO. Namun, adalah mungkin untuk mengembangkan model data relasional dan object-oriented artefak desain secara paralel, dan pertumbuhan artefak dapat merangsang penyempurnaan artefak lainnya.

Pengembangan sistem siklus hidup

Manajemen dan kontrol

SPIU terkait dengan kontrol manajemen fase.

Tahapan SDLC berfungsi sebagai panduan untuk memproyeksikan program kegiatan dan menyediakan cara yang fleksibel tetapi konsisten untuk melakukan proyek dengan kedalaman yang cocok dengan lingkup proyek. Setiap tujuan fase SDLC dijelaskan di bagian ini dengan kiriman kunci, deskripsi tugas yang direkomendasikan, dan ringkasan tujuan pengendalian terkait untuk manajemen yang efektif. Hal ini penting bagi manajer proyek untuk menetapkan dan memantau tujuan pengendalian selama setiap fase SDLC ketika menjalankan proyek. Tujuan pengendalian membantu memberikan pernyataan yang jelas dari hasil yang diinginkan atau tujuan dan harus digunakan selama proses SDLC keseluruhan. Tujuan pengendalian dapat dikelompokkan menjadi kategori utama (domain), dan berhubungan dengan fase-fase SDLC seperti yang ditunjukkan pada gambar.

Untuk mengelola dan mengendalikan setiap inisiatif SDLC, setiap proyek akan diminta untuk membuat beberapa derajat dari Struktur Perincian Kerja (WBS) untuk menangkap dan jadwal pekerjaan yang diperlukan untuk menyelesaikan proyek. WBS dan semua materi program harus disimpan di bagian "proyek description" dari notebook proyek. Format WBS sebagian besar diserahkan kepada manajer proyek untuk membangun dengan cara yang paling menggambarkan pekerjaan proyek. Ada beberapa area kunci yang harus didefinisikan dalam WBS sebagai bagian dari kebijakan SDLC. Diagram berikut ini menjelaskan tiga bidang utama yang akan dibahas dalam WBS dengan cara yang ditetapkan oleh manajer proyek.

Kerja terstruktur rincian organisasi

Struktur rincian kerja.

Bagian atas dari struktur rincian kerja (WBS) harus mengidentifikasi tahapan dan tonggak utama dari proyek secara ringkasan. Selain itu, bagian atas harus memberikan gambaran tentang ruang lingkup penuh dan timeline proyek dan akan menjadi bagian dari upaya deskripsi awal proyek yang mengarah ke persetujuan proyek. Bagian tengah WBS didasarkan pada tujuh siklus hidup pengembangan sistem (SDLC) tahapan sebagai panduan untuk pengembangan tugas WBS. Elemen-elemen WBS harus terdiri dari tonggak dan "tugas" sebagai lawan dari "kegiatan" dan memiliki periode yang pasti (biasanya dua minggu atau lebih). Setiap tugas harus memiliki output yang terukur (ex dokumen, keputusan, atau analisis). Sebuah tugas WBS dapat mengandalkan pada satu atau lebih kegiatan (misalnya rekayasa perangkat lunak , rekayasa sistem ) dan mungkin memerlukan koordinasi erat dengan tugas-tugas lain, baik internal maupun eksternal untuk proyek. Setiap bagian dari proyek yang memerlukan dukungan dari kontraktor harus memiliki pernyataan kerja (SOW) ditulis untuk mencakup tugas-tugas yang sesuai dari fase SDLC. Perkembangan SOW tidak terjadi selama fase tertentu SDLC tetapi dikembangkan untuk menyertakan kerja dari proses SDLC yang mungkin dilakukan oleh sumber daya eksternal seperti kontraktor dan struct.

baseline dalam SDLC

Baseline merupakan bagian penting dari siklus hidup pengembangan sistem (SDLC). Acuan dasar yang ditetapkan setelah empat dari lima fase SDLC dan sangat penting untuk sifat iteratif dari model. baseline Setiap dianggap sebagai tonggak dalam SDLC.

• dasar fungsional: didirikan setelah tahap desain konseptual.
• dasar dialokasikan: didirikan setelah tahap desain awal.
• dasar produk: didirikan setelah detail desain dan tahap pembangunan.
• dasar produk updated: didirikan setelah tahap konstruksi produksi.

Melengkapi SDLC

Pelengkap metode pengembangan perangkat lunak untuk siklus hidup pengembangan sistem (SDLC) adalah:

• Software prototyping
• Bersama pengembangan aplikasi (JAD)
• Pengembangan aplikasi cepat (RAD)
• Ekstrim pemrograman (XP); pengembangan dari pekerjaan sebelumnya di Prototyping dan RAD.
• Open source pengembangan
• Akhir-pengguna pengembangan
• Pemrograman berorientasi obyek

Perbandingan Pendekatan Metodologi (Post, & Anderson 2006)
	SDLC	RAD	Open source	Objek	JAD	Prototyping	Pengguna Akhir
Kontrol	Resmi	MIS	Lemah	Standar	Bersama	Pengguna	Pengguna
Waktu bingkai	Panjang	Pendek	Medium	Apa pun	Medium	Pendek	Pendek -
Pengguna	Banyak	Beberapa	Beberapa	Bervariasi	Beberapa	Satu atau dua	Satu
MIS staf	Banyak	Beberapa	Ratusan	Membagi	Beberapa	Satu atau dua	Tidak ada
Transaksi / DSS	Transaksi	Kedua	Kedua	Kedua	DSS	DSS	DSS
Antarmuka	Minimal	Minimal	Lemah	Jendela	Sangat penting	Sangat penting	Sangat penting
Dokumentasi dan pelatihan	Vital	Terbatas	Intern	Dalam Objects	Terbatas	Lemah	Tidak ada
Integritas dan keamanan	Vital	Vital	Diketahui	Dalam Objects	Terbatas	Lemah	Lemah
Usabilitas	Terbatas	Beberapa	Mungkin	Vital	Terbatas	Lemah	Tidak ada

Kekuatan dan kelemahan

Hanya sedikit orang di dunia komputasi modern akan menggunakan ketat model air terjun untuk hidup pengembangan sistem siklus mereka (SDLC) sebagai metodologi modern telah digantikan pemikiran ini. Beberapa akan berpendapat bahwa SDLC tidak lagi berlaku untuk model seperti komputasi Agile, tetapi masih istilah yang secara luas digunakan di kalangan teknologi. Praktek SDLC memiliki keunggulan dalam model tradisional pengembangan perangkat lunak, yang lebih cocok untuk lingkungan yang terstruktur. Kelemahan menggunakan metodologi SDLC adalah ketika ada kebutuhan untuk pengembangan iteratif atau (yakni pengembangan web atau e-commerce) dimana stakeholders harus meninjau secara rutin perangkat lunak yang akan dibuat. Alih-alih melihat SDLC dari perspektif kekuatan atau kelemahan, itu jauh lebih penting untuk praktek-praktek terbaik dari model SDLC dan menerapkannya ke apapun mungkin paling tepat untuk perangkat lunak yang akan dibuat.

Suatu perbandingan kekuatan dan kelemahan dari SDLC:

Kekuatan dan Kelemahan dari SDLC
Kekuatan	Kelemahan
Kontrol.	Peningkatan waktu pengembangan.
Memantau proyek-proyek besar.	Peningkatan biaya pembangunan.
Langkah-langkah rinci.	Sistem harus didefinisikan di depan.
Mengevaluasi biaya dan target penyelesaian.	Kekakuan.
Dokumentasi.	Sulit untuk memperkirakan biaya, overruns proyek.
Didefinisikan dengan baik input pengguna.	Input pengguna kadang-kadang terbatas.
Kemudahan pemeliharaan.
Pengembangan dan desain standar.
Tahan terhadap perubahan staf MIS.

Sebuah alternatif untuk SDLC adalah pengembangan aplikasi yang cepat , yang menggabungkan prototyping, pengembangan aplikasi bersama dan pelaksanaan CASE tools. Kelebihan RAD adalah kecepatan, biaya pembangunan dikurangi, dan keterlibatan pengguna aktif dalam proses pembangunan.