UML dan SDLC

Apa Pengertian SDLC?

SDLC (System Development Life Cycle), seperti namanya, didefinisikan sebagai proses (secara keseluruhan) dari sistem berkembang atau perangkat lunak untuk memenuhi persyaratan tertentu. Ini mencakup banyak kegiatan, mulai dari pemahaman mengapa sistem harus dibangun, mempelajari kelayakan proyek, menganalisis masalah, memilih desain sistem dan arsitektur, pelaksanaan dan pengujian itu, sampai dengan memberikan sistem sebagai produk kepada pengguna. SDLC adalah proses perbaikan bertahap, yang berarti bahwa hal itu dilakukan melalui beberapa tahapan pembangunan. Setiap fase terus dan memurnikan apa yang dilakukan dalam tahap sebelumnya. Tahapan pembangunan umum dikenal di SDLC adalah:

Planning Ini adalah proses memahami mengapa sistem harus dibangun dan mendefinisikan persyaratan. Ini juga mencakup studi kelayakan dari perspektif yang berbeda, teknis, ekonomi, dan aspek kelayakan organisasi.

Analysis Fase ini meliputi kegiatan seperti mengidentifikasi masalah dan analisis, dan bahkan memprediksi potensi masalah yang mungkin timbul di masa depan mengenai sistem. Kiriman / produk dari fase ini akan mendorong bagaimana sistem akan dibangun dan membimbing karya pengembang.

Design Analisis sistem mengarah ke desain keputusan, yang justru menentukan bagaimana sistem beroperasi dalam hal proses, data, perangkat keras, infrastruktur jaringan, antarmuka pengguna, dan faktor-faktor penting lainnya dalam lingkungan sistem.

Implamentation  Ini mungkin yang paling sumber daya, biaya, dan memakan waktu fase dari semua.Ini adalah ketika sistem sebenarnya dibangun, diuji, dan akhirnya diinstal. Ini juga mencakup kegiatan seperti pelatihan pengguna dan pemeliharaan sistem. Beberapa ahli seperti untuk memisahkan mereka ke dalam Penyebaran fase yang berbeda dan Pemeliharaan ( Development and Maintenance ). Namun empat fase yang paling umum dikenal dan langkah-langkah diterima.

SDLC mencoba untuk mencapai sistem berkualitas tinggi yang memenuhi atau melebihi persyaratan.Banyak metodologi telah dikembangkan dan diperkenalkan dalam rangka untuk melaksanakan SDLC, beberapa dari mereka juga mencoba untuk meningkatkan yang lain (sebelumnya) metodologi yang dikenal. Meskipun setiap metode berikut teknik yang berbeda dan langkah-langkah tertentu, mereka semua harus pergi ke dalam fase pembangunan yang sama dijelaskan di atas. Ada banyak metode pengembangan sistem yang dikenal hari ini, tapi kebanyakan dari mereka pada dasarnya diperpanjang dari tiga metodologi utama yang Terstruktur Desain, Analisis RAD (Rapid Application Development), dan berorientasi Obyek dan Desain.

Desain Terstruktur ( Structured Design )

Metode ini mengikuti pendekatan langkah-demi-langkah yang bergerak secara logis dari satu tahap ke tahap berikutnya. Bekerja dilakukan dalam setiap fase harus disetujui oleh sponsor proyek (ini biasanya pelanggan atau analis bisnis dalam sebuah organisasi) sebelum dapat melanjutkan ke tahap perkembangan berikutnya. Metodologi pengembangan Waterfall dapat diklasifikasikan sebagai metodologi semacam ini. Cara ini ketelitian dan fleksibel membuat metodologi ini rentan terhadap setiap perubahan bisnis yang terjadi saat pembangunan masih dalam perjalanan, karena sangat sulit untuk pergi ke belakang. Ini mungkin memerlukan mengulangi seluruh proses pembangunan dari awal dan membuang semua yang telah dilakukan, dan dalam kasus terburuk dapat menyebabkan perubahan kontrak proyek atau perjanjian dengan pelanggan.

Ada dua pendekatan dalam pengembangan sistem menggunakan metodologi ini, proses-berpusat dandata-berpusat pendekatan. Proses pendekatan yang berpusat pada upaya untuk mendapatkan pekerjaan dilakukan terutama dari perspektif proses yang ada dalam operasi sistem, yang kemungkinan akan menghasilkan sistem yang dibangun oleh proses-berorientasi komponen. Di sisi lain, pendekatan data-berpusat berkonsentrasi pada data yang digunakan oleh dan terlibat dalam sistem.

Metodologi desain terstruktur memiliki beberapa keunggulan dalam bahwa cara kekakuan dari metode ini memaksa pengembang (analis dan / timnya) dengan baik mengidentifikasi dan memahami persyaratan sistem lama sebelum tahap implementasi dimulai. Setidaknya harus telah disetujui oleh sponsor sebelum pengembang mulai coding program apapun.

Kurangnya kemampuan untuk pergi ke belakang dari tahap pengembangan metodologi ini membuat unaccommodateable perubahan proses bisnis sebagai hasil proyek. Proyek dilakukan dengan menggunakan metodologi ini memakan waktu lama sampai pengguna menerima beberapa kiriman karena biasanya sistem yang dibangun tidak dapat disajikan sampai benar-benar dilakukan pada akhir fase implementasi.

Gambar 1. Desain Terstruktur Metodologi

RAD ( Rapid Application Development )

Metodologi RAD masuk untuk mengatasi kelemahan metode Desain Terstruktur. RAD pembangunan berbasis mencoba untuk menyesuaikan fase SDLC memiliki beberapa bagian dari sistem (kemungkinan besar fungsi inti dari sistem) yang dikembangkan dengan cepat untuk disampaikan kepada pengguna.Beberapa jenis metode RAD juga mencoba untuk menjadi adaptif terhadap perubahan mungkin dalam proses bisnis dengan bersamaan melakukan semua fase pengembangan di (sekitar) waktu yang sama, seperti yang diwujudkan dalam Prototyping RAD dan Metodologi Pengembangan Agile.

RAD metodologi memperkenalkan penggunaan alat pengembangan maju seperti generator kode dangenerasi keempat bahasa pemrograman visual yang (4G) seperti Microsoft Visual Basic dan Borland Delphi.Penggunaan alat ini mempercepat proses pembangunan dan dalam tingkat tertentu menghasilkan kualitas yang lebih tinggi kode. Namun sebagai sistem dapat disampaikan dengan cepat, pengguna cenderung untuk mengubah harapan mereka tentang apa sistem dapat lakukan, sehingga persyaratan cenderung untuk berubah dan berkembang.

Ada tiga kategori dari RAD:

Phased Development ( Pengembangan bertahap )

Metode ini istirahat persyaratan menjadi serangkaian versi, berdasarkan yang beberapa versi dari sistem akan dibangun secara berurutan, menjadi fungsi yang paling mendasar dan penting dibundel dalam versi pertama. Berurutan di sini berarti bahwa pengembangan versi berikutnya akan dimulai hanya setelah versi sebelumnya telah disetujui dan dilaksanakan. Setiap versi memiliki sendiri Analisis-Desain-Implementasi fase (dalam skala yang lebih kecil dibandingkan dengan sistem secara keseluruhan). Semua versi ini nantinya akan disesuaikan untuk membentuk sistem yang lengkap yang memenuhi metode requirements. memberikan sistem yang berguna sangat cepat bagi pengguna, meskipun tidak mencakup semua fungsi dulu. Dan sebagai sistem akan dibangun berdasarkan versi berurutan banyak, sangat penting untuk mengidentifikasi fungsi penting dan mendasar untuk dimasukkan dalam versi pertama, sebuah analisis mendalam awal dari sistem ini adalah diperlukan.

Gambar 2. Metodologi Pengembangan bertahap

Prototyping

Metodologi ini digunakan biasanya ketika proses bisnis kemungkinan akan berubah sebagai hasil proyek atau ketika sponsor proyek memiliki sedikit gagasan tentang apa sistem yang akan dibangun. Analisis, Desain, dan fase Implementasi dilakukan secara bersamaan dan pada setiap siklus sehingga menghasilkan prototipe sistem yang akan ditinjau oleh sponsor proyek. Siklus diulang terus-menerus berdasarkan komentar sponsor sampai prototipe berhasil memenuhi persyaratan. Prototipe terakhir kemudian akan disebut pengembangan system.Prototyping hanya membutuhkan analisis dan desain dasar awal, tetapi sebagai akibatnya fungsi sistem yang penting tidak dapat diakui sampai di suatu tempat di tengah-tengah waktu proyek. Jadi ada kemungkinan untuk mengubah keputusan desain awal dan mulai dari awal lagi dari awal. Hal ini dapat memberikan sistem cepat bagi pengguna, meskipun tidak persis memenuhi persyaratan.

Figure 3. Metologi Prototyping 

Throw-away Prototyping

Throw-away Prototyping adalah mirip dengan metode Prototyping dalam hal itu juga mengembangkan prototipe. Tapi prototipe membuang-jauhnya agak presentasi saja, prototipe sebenarnya tidak apa-apa.Hal ini dimaksudkan untuk membantu pengguna memvisualisasikan sistem yang dibangun. Berdasarkan komentar pengguna, prototipe berikutnya terus dibangun sampai dapat memvisualisasikan sistem kerja yang nyata. Langkah berikutnya akan menerapkan sistem nyata. Ini prototipe membuang-jauhnya juga disebut dummy (mock-up) prototipe. Yang terbaik adalah jika mungkin untuk melakukan analisis awal menyeluruh sebelum pengembang mulai bekerja pada prototipe boneka pertama, sebagai dummy harus berisi rincian yang cukup tentang sistem nyata . Metode ini tidak memberikan sistem lengkap dalam timeline proyek seperti metode prototyping, tetapi pada akhirnya itu memberikan sistem yang lengkap sangat cepat. Ini umumnya memiliki waktu proyek yang lebih pendek dibandingkan dengan metode lain, karena bangunan boneka dianggap lebih mudah dan lebih memakan waktu daripada membangun prototipe bekerja.

Gambar 4. Throw-away Prototyping Metodologi

Object-oriented Analysis and Design ( Analisis berorientasi objek dan Desain )

Metodologi berorientasi objek dikembangkan berdasarkan pada kurangnya sinergi antara pendekatan proses-berpusat dan data-berpusat di SDLC. Dekomposisi sistem menjadi serangkaian proses (proses sentris) atau data (data sentris) tidak dapat dengan mudah diperoleh, karena kedua aspek yang erat terkait satu sama lain. Hal ini sulit untuk mengembangkan sistem dengan memfokuskan terutama hanya untuk satu aspek. Akibatnya, sistem yang dihasilkan cenderung diperpanjang hanya dalam satu dunia.Sebuah sistem proses yang dikembangkan sentris tidak dapat dengan mudah diperpanjang ketika ada perubahan dalam jenis data dalam sistem. Masalah seperti ini juga ada dalam sistem sentris data yang dikembangkan.

OO masalah metodologi terurai menjadi obyek. Objek dianggap sebagai bagian dari sistem yang mengandung baik proses dan data, sebuah objek dapat melakukan beberapa kegiatan / proses (dipetakan sebagai metode objek), sebuah objek juga mungkin memiliki negara (dipetakan sebagai atribut objek). Dengan cara ini, pengembang akan fokus pada entitas dalam sistem yang benar-benar proses dan membawa data, daripada fokus terutama hanya untuk satu aspek. OO berbasis pengembangan sistem ekstensif menggunakan alat yang disebut UML (Unified Modeling Language), yang merupakan set standar dalam diagram dan pemodelan teknik diciptakan oleh tiga juara OO, Grady Booch, Ivar Jacobson, dan James Rumbaugh, ketika mereka bekerja bersama dalam Rasional perangkat lunak. Pada tahun 1997 diusulkan untuk UML dan diterima oleh Object Management Group (OMG)sebagai notasi diagram standar dalam pengembangan berorientasi objek sistem.

Sebuah pendekatan OO dalam pengembangan sistem harus:

Use-case Drive

Ini berarti bahwa penggunaan-kasus adalah alat pemodelan utama untuk menentukan perilaku sistem. Gunakan-kasus menggambarkan bagaimana para pengguna sistem berinteraksi dengan sistem untuk melakukan aktivitas. Dan sebagai use case berfokus hanya untuk satu kegiatan pada satu waktu, itu adalah inheren sederhana.

Architecture Centric

Para arsitektur sentris jangka memberikan pandangan tingkat tinggi dari sistem yang dikembangkan.Arsitektur perangkat lunak yang dipilih untuk sistem harus drive spesifikasi, konstruksi, dan dokumentasi dari sistem itu sendiri. Arsitektur sistem harus mendukung tiga tampilan dari sistem:

• Functional View ( Tampilan Fungsional ) Menjelaskan perilaku sistem dari perspektif pengguna sistem. Gunakan kasus diagram digunakan untuk menggambarkan pandangan fungsional.
• Static view ( Tampilan Statis ) Menjelaskan struktur sistem dalam hal kelas, metode, atribut, dan hubungan objek dalam sistem.Pandangan ini digambarkan menggunakan CRC (Class Responsibility Kolaborasi) kartu, serta menggunakan diagram kelas dan objek.
• Dynamic View ( Tampilan Dinamis ) Menggambarkan perilaku sistem internal dalam hal komunikasi objek dan perubahan negara. Alat UML digunakan untuk menggambarkan pandangan ini adalah sequence diagram, diagram kolaborasi, dan negara-objek grafik.

Iteratif dan incremental

Iteratif dan incremental paradigma berarti bahwa setiap iterasi pengembangan sistem harus membawa sistem dekat dengan kebutuhan. Sebagai SDLC adalah proses bertahap, diagram UML digunakan dalam OO bergerak berbasis pengembangan dari hal yang konseptual dan abstrak dalam analisis dan tahap desain untuk menjadi lebih detail dan lebih dalam tahap implementasi.  

Apa itu UML?

UML itu singkatan dari Unified Modelling Language. Sesuai dengan kata terakhir dari kepanjangannya, UML ituadalah salah satu bentuk language atau bahasa. Menurut pencetusnya, UML di definisikan sebagai bahasa visual untuk menjelaskan, memberikan spesifikasi, merancang, membuat model, dan mendokumentasikan aspek-aspek dari sebuah system.

Karena tergolong bahasa visual, UML lebih mengedepankan penggunaan diagram untuk menggambarkan aspek dari system yang sedang dimodelkan. Memahami UML itu sebagai bahasa visual itu penting, karena penekanan tersebut membedakannya dengan bahasa pemrograman yang lebih dekat ke mesin. Bahasa visual lebih dekat ke mental model pikiran kita, sehingga pemodelan menggunakan bahasa visual bisa lebih mudah dan lebih cepat dipahami dibandingkan apabila dituliskan dalam sebuah bahasa pemrograman. Sebenernya hampir semua disiplin ilmu memiliki notasi, cara, atau bahasa dalam memodelkan problem dengan notasi diagram yang visual. Ambil contoh dibidang elektro, untuk menggambarkan sebuah system radio, insinyur-insinyur menggunakan diagram sirkuit kelistrikan yang sudah didefinisikan dengan jelas. Dengan diagram sirkuit ini, insinyur elektro bisa mengkomunikasikan komponen-komponen apa saja yang terdapat dalam sebuah system radio kepada insinyur elektro yang lain atau kepada teknisi.UML adalah salah satu bentuk notasi atau bahasa yang sama yang digunakan oleh professional dibidang software untuk menggambarkan atau memodelkan sebuah system software. Sebelumnya ada banyak notasi atau bahasa lain untuk mencapai keperluan yang sama misalnya DFD (Data Flow Diagram) dan Booch Diagram. Tetapi sejak matang dan populernya teknologi pemrograman, perancangan, dan analisis berorientasi object, UML telah menjadi de facto standard language.Apa saja yang bisa digambarkan / dimodelkan oleh UML? Sesuai dengan kata pertama dari kepanjangannya, UML mencoba untuk mendeskripsikan pemodelan sebuah system dari segala aspek: pemodelan struktur (aspek statis), pemodelan perilaku (aspek dinamis), dan pemodelan arsitektur. Gambar berikut menunjukan taksonomi pendiagraman UML.Secara detail UML tidak akan dibahas dalam posting ini, tetapi kita akan banyak menggunakannya dalam pembahasan-pembahasan selanjutnya. Jadi sambil melakukan pemodelan, dijelaskan juga dengan notasi UMLyang cocok dengan konteks pemodelan yang dilakukan. Ada tiga cara dalam memakai UML dalam melakukan pemodelan system: 1. UML sebagai sketsa UML digambarkan dalam sketsa coretan-coretan dalam kertas atau whitboard secara tidak formal. Biasanya digunakan dalam sesi diskusi tim untuk membahas aspek tertentu dalam tahap analisis dan perancangan. 2. UML sebagai blueprint system Seperti diagram kelistrikan adalah blueprint dari komponen atau produk yang akan dihasilkan, UML juga bisa menggambarkan blueprint yang identik untuk sebuah system software. 3. UML sebagai bahasa pemrograman UML berfungsi sebagai bahasa pemrograman mencoba melakukan semuanya dengan UML sampai kepada produk jadinya. Analisis dan perancangan dilakukan dengan diagram-diagram yang ada dalam UML, sementara sebuah tool atau generator bisa menghasilkan produk akhir dari diagram-diagram ini. Saat ini UML paling banyak digunakan dengan cara pertama dan kedua. Khusus dalam metode agile (cepat dan ringan), UML digunakan dengan cara pertama.