Analisis dan Design PL

Structured System Analisys and Design (SSAD) atau Analisis dan Desain Sistem Terstruktur adalah salah satu metodologi dalam mengembangkan sistem maupun perangkat lunak. Metodologi ini digunakan dalam menjalankan 3 fase di SDLC yaitu fase analisis, desain dan implementasi sebuah sistem dan perangkat lunak. SSAD berorientasi pada data dan proses.

Analisis dan desain perangkat lunak terstruktur memiliki beberapa karakteristik penting, yaitu :

1. Berdasarkan modul

Dalam metodologi ini semua proses di bagi menjadi modul-modul yang independen atau dapat berdiri sendiri sehingga setiap modul dapat digunakan kembali di projek lain. Setiap modul mengandung proses-proses yang mengolah data lebih detail. Antara setiap proses itu memiliki keterikatan sehingga di kelompokkan kedalam modul.

2. Pendekatan Top-Down

Pendekatan Top-Down memiliki arti bahwa dalam perancangannya sistem di definisikan lebih dahulu secara umum lalu turun ke level ke yang lebih spesifik. Pendekatan ini sering di lakukan dengan menggunakan Diagram Arus Data atau Data Flow Diagram(DFD).

3. Iterasi

Perancangan dan implementasi sistem di lakukan secara iterasi yaitu berulang ulang kali sehingga kesalahan kesalahan dari iterasi sebelumnya dapat di perbaiki. Contoh metode iterasi adalah metode spiral.

4. Paralel

Karena setiap modul dapat bekerja secara independen maka dalam pengembangannya dapat dilakukan secara terpisah. Pengembangan secara terpisah dapat mempercepat proses pembuatan sistem ini sehingga sumberdaya yang dikeluarkan menjadi lebih sedikit. 

Object Oriented Analysis Design (OOAD) atau Analisis dan Desain Berorientasi Objek adalah cara baru dalam memikirkan suatu masalah dengan menggunakan model yang dibuat menurut konsep sekitar dunia nyata. Dasar pembuatan adalah objek, yang merupakan kombinasi antara struktur data dan perilaku dalam satu entitas. Pengertian “berorientasi objek” berarti bahwa kita mengorganisasi perangkat lunak sebagai kumpulan dari objek tertentu yang memiliki struktur data dan perilakunya.

Konsep OOAD mencakup analisis dan desain sebuah sistem dengan pendekatan objek, yaitu analisis berorientasi objek (OOA) dan desain berorientasi objek (OOD). 

OOA adalah metode analisis yang memeriksa requirement (syarat/keperluan) yang harus dipenuhi sebuah sistem) dari sudut pandang kelas-kelas dan objek-objek yang ditemui dalam ruang lingkup perusahaan. Hasil OOA adalah deskripsi dari apa sistem secara fungsional diperlukan untuk melakukan, dalam bentuk sebuah model konseptual. Itu biasanya akan disajikan sebagai seperangkat menggunakan kasus, satu atau lebih UML diagram kelas, dan sejumlah diagram interaksi.

OOD adalah metode untuk mengarahkan arsitektur software yang didasarkan pada manipulasi objek-objek sistem atau subsistem. OOD mengubah model konseptual yang dihasilkan dalam analisis berorientasi objek memperhitungkan kendala yang dipaksakan oleh arsitektur yang dipilih dan setiap non-fungsional – teknologi atau lingkungan – kendala, seperti transaksi throughput, response time, run , lingkungan pengembangan, atau bahasa pemrograman.

Karakteritik Metodologi Berorientasi Objek

Metodologi pengembangan sistem berorientasi objek mempunyai tiga karakteristik utama :

1. Encapsulation (Pengkapsulan)

• Encapsulation merupakan dasar untuk pembatasan ruang lingkup program terhadap data yang diproses. 
• Data dan prosedur atau fungsi dikemas bersama-sama dalam suatu objek, sehingga prosedur atau fungsi lain dari luar tidak dapat mengaksesnya. 
• Data terlindung dari prosedur atau objek lain, kecuali prosedur yang berada dalam objek itu sendiri.

2. Inheritance (Pewarisan)

• Inheritance adalah teknik yang menyatakan bahwa anak dari objek akan mewarisi data/atribut dan metode dari induknya langsung. 
• Atribut dan metode dari objek dari objek induk diturunkan kepada anak objek, demikian seterusnya. 
• Inheritance mempunyai arti bahwa atribut dan operasi yang dimiliki bersama di anatara kelas yang mempunyai hubungan secara hirarki. 
• Suatu kelas dapat ditentukan secara umum, kemudian ditentukan spesifik menjadi subkelas. Setiap subkelas mempunyai hubungan atau mewarisi semua sifat yang dimiliki oleh kelas induknya, dan ditambah dengan sifat unik yang dimilikinya. 
• Kelas Objek dapat didefinisikan atribut dan service dari kelas Objek lainnya. Inheritance menggambarkan generalisasi sebuah kelas.

3. Polymorphism (Polimorfisme)

• Polimorfisme yaitu konsep yang menyatakan bahwa seuatu yang sama dapat mempunyai bentuk dan perilaku berbeda.
• Polimorfisme mempunyai arti bahwa operasi yang sama mungkin mempunyai perbedaan dalam kelas yang berbeda.
• Kemampuan objek-objek yang berbeda untuk melakukan metode yang pantas dalam merespon message yang sama.
• Seleksi dari metode yang sesuai bergantung pada kelas yang seharusnya menciptakan Objek

Source:

https://medium.com/@agungtuahananda/analisis-dan-desain-sistem-terstruktur-1722b4b51a64

https://peterdraw.wordpress.com/2011/10/30/konsep-ooad-object-oriented-analysis-design/

Rekayasa Kebutuhan

Rekayasa Kebutuhan

Software requirements adalah deskripsi fitur dan fungsi dari sistem target. Persyaratan menyampaikan harapan pengguna dari produk perangkat lunak. Persyaratan dapat jelas atau tersembunyi, diketahui atau tidak diketahui, diharapkan atau tidak diharapkan dari sudut pandang klien. Rekayasa kebutuhan yang baik akan menjadi pondasi membangun high quality software dan sesuai dengan user expectation (keinginan pengguna).

User Requirement

User requirement adalah requirement yang berperan dalam menjalankan dalam sebuah sistem yang dibuat. Dan dapat dikatakan tanpa adanya user requirements ini maka sebuah sistem tidak akan berguna untuk diterapkan dalam suatu organisasi karena sebuah sistem tidak bisa berjalan sesuai dengan fungsi-fungsi yang telah dibuat. Karena suatu proses yang telah digambarkan dalam suatu business requirement menunjukkan peran awal yang harus ada dalam sebuah sistem adalah adanya entity atau bisa disebut seorang stakeholder atau seorang user. Yang harus diketahui user masih mengandung arti luas karena setiap sistem dalam sebuah organisasi, lingkungan memiliki peran yang spesifik. Misal dalam sebuah sistem aplikasi akuntansi terdapat beberapa user yang terlibat antara lain karyawan accounting, manager accounting dan director accounting. Begitu juga dalam sebuah game RPG misalnya disana terdapat beberapa peran dari gamer ada yang bertindak sebagai hero, assasin dan lain-lain. Jadi ketika membuat suatu business requirement atau dokumentasi gunakan nama-nama user atau stakeholder yang lebih spesifik berperan dalam aplikasi yang akan dikembangkan.

System Requirement

System Requirement merupakan penjelasan dari user requirement atau detail dari user requirement dengan kata lain spesifikasi yang dibutuhkan untuk menggunakan suatu perangkat keras atau lunak, seperti kapasitas RAM, versi sistem operasi, kecepatan prosesor, dan sebagainya.

Fungsional Requirement dan Non Fungsional Requirement 

Persyaratan fungsional dan non-fungsional menggambarkan karakteristik khusus yang harus dimiliki suatu produk untuk memenuhi kebutuhan pemangku kepentingan dan bisnis itu sendiri. Tapi, seperti yang bisa Anda ketahui dari namanya, mereka fokus pada hal yang berbeda.

Persyaratan fungsional menentukan apa yang harus dilakukan oleh produk perangkat lunak: fitur dan fungsinya. Contoh persyaratan fungsional untuk messenger adalah seperti, "Pengguna harus dapat mengedit pesan setelah dikirim untuk memperbaiki kesalahan."

Persyaratan non-fungsional menentukan atribut kualitas sistem, oleh karena itu nama keduanya adalah atribut kualitas. Melanjutkan contoh platform perpesanan kami, persyaratan non-fungsional dapat berupa kecepatan sistem harus melakukan pengeditan untuk memenuhi harapan pengguna, “Pesan harus diperbarui untuk semua pengguna dalam obrolan dalam waktu 0,1 detik, mengingat semua pengguna sedang online dan memiliki koneksi LTE atau lebih baik.”

Analisis Kebutuhan

Analisa kebutuhan adalah suatu proses untuk mendapatkan informasi, mode, spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna. Kedua belah pihak, yaitu klien dan pembuat perangkat lunak terlibat aktif dalam tahap ini. Informasi dari klien yang akan menjadi acuan untuk melakukan desain perangkat lunak.

Ada tiga faktor yang harus dipenuhi ketika melakukan analisis kebutuhan ini, yaitu lengkap, detail, dan benar. Lengkap artinya semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisis. Detail maksudnya adalah berhasil mengumpulkan informasi yang terperinci. Semua data dari analisis kebutuhan ini haruslah benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yang dipikirkan oleh pihak analisis.

Analisis kebutuhan yang dilakukan terhadap perangkat lunak akan menghasilkan spesifikasi perangkat lunak tersebut. Analisa kebutuhan ini terdiri dari lima langkah pokok:

• Identifikasi Masalah
• Evaluasi dan sintesis
• Pemodelan
• Spesifikasi
• Review

Kesimpulan

Software requirements adalah deskripsi fitur dan fungsi dari sistem target. Persyaratan menyampaikan harapan pengguna dari produk perangkat lunak. Software requirements terdiri dari 4 yaitu: User Requirement, System Requirement, Functional Requirement dan Non Functional Requirement.

Analisa kebutuhan adalah suatu proses untuk mendapatkan informasi, mode, spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna. Kedua belah pihak, yaitu klien dan pembuat perangkat lunak terlibat aktif dalam tahap ini. Analisis kebutuhan yang dilakukan terhadap perangkat lunak akan menghasilkan spesifikasi perangkat lunak tersebut. Analisa kebutuhan ini terdiri dari lima langkah pokok yaitu: Identifikasi Masalah, Evaluasi dan sintesis, Pemodelan, Spesifikasi, Review

Source :

http://greskit.com/2019/10/10/tipe-tipe-requirement-engineering-bagian-i/

http://lea.si.fti.unand.ac.id/2014/04/requirement-system-perancangan-system-part-i/

https://www.altexsoft.com/blog/non-functional-requirements/