Analisis dan Desain PL

Analisis dan Desain Perangkat Lunak

    Pada dasarnya, tujuan metodologi pengembangan perangkat lunak adalah untuk berkontribusi pada pembuatan perangkat lunak berkualitas tinggi. Model proses PL adalah representasi abstrak dari suatu proses dari berbagai perspektif.  

Sumber: https://cdnwpedutorenews.gramedia.net/wp-content/uploads/2022/10/16120629/code-1839406__340.webp

I. Metodologi Analisis dan Desain 

    Secara konsep, pemrograman adalah penulisan, pengujian, debugging, dan pemeliharaan kode yang membentuk program komputer. Kode ini ditulis dalam bahasa pemrograman yang berbeda. Tujuan pemrograman adalah untuk menghasilkan program yang dapat melakukan perhitungan atau pekerjaan sesuai dengan keinginan programmer. 

    Ada banyak teknik untuk meganalisis pemrograman untuk membuat program. Lalu, apa perbedaan antara teknik menganalisis pemrograman terstruktur (SSAD) dan teknik menganalisis pemrograman berorientasi objek (OOAD).

    SSAD (Structured Systems Analysis and Design) dan OOAD (Object-Oriented Analysis and Design) adalah dua metodologi analisis dan desain yang berbeda dalam pendekatan dan konsepnya. Berikut penjelasannya:

1. SSAD (Structured Systems Analysis and Design)

    SSAD adalah metodologi analisis dan desain sistem yang menggunakan pendekatan berstruktur. Pendekatan ini terdiri dari beberapa tahapan, seperti analisis kebutuhan, desain logis, desain fisik, implementasi, dan pemeliharaan. Metodologi ini bertujuan untuk menghasilkan sistem yang terstruktur, terdokumentasi dengan baik, dan mudah dimengerti.

    Metodologi SSAD terdiri dari beberapa model yang digunakan untuk menggambarkan sistem, seperti Data Flow Diagram (DFD) yang menggambarkan aliran data di dalam sistem, Entity Relationship Diagram (ERD) yang menggambarkan hubungan antar entitas dalam sistem, dan Structured English yang digunakan untuk menuliskan prosedur sistem.

2. OOAD (Object-Oriented Analysis and Design)

    Sementara itu, OOAD adalah metodologi analisis dan desain sistem yang berfokus pada penggunaan konsep pemrograman berorientasi objek (OOP). Metodologi ini menggunakan konsep kelas, objek, pewarisan, polimorfisme, dan enkapsulasi untuk mendefinisikan struktur dan fungsi sistem.

    Metodologi OOAD terdiri dari beberapa tahapan, seperti analisis kebutuhan, perancangan konsep, perancangan objek, implementasi, dan pengujian. Metodologi ini bertujuan untuk menghasilkan sistem yang mudah dimodifikasi, terstruktur, dan memanfaatkan kembali kode yang telah ada.

    Dalam OOAD, model yang digunakan untuk menggambarkan sistem adalah Unified Modeling Language (UML), yang mencakup diagram kelas, diagram objek, diagram urutan, dan lain-lain.

II. Kekurangan dan Kelebihan Antara SSAD& OOAD

    Diantara kedua metode tersebut, mereka juga memiliki kekurangan serta kelebihan. Berikut ini adalah kelebihan dan kekurangan dari SSAD dan OOAD:

1. Kekurangan & Kelebihan SSAD

    a. Kelebihan SSAD:

    1. Metodologi SSAD dapat menghasilkan sistem yang terstruktur dan terdokumentasi dengan baik.

    2. Metodologi SSAD dapat memastikan bahwa seluruh proses bisnis terdokumentasi dengan baik.

    3. Metodologi SSAD mudah dipelajari dan dipahami oleh orang yang baru memulai dalam pengembangan sistem.

    4. Metodologi SSAD cocok untuk sistem yang relatif sederhana dan tidak terlalu kompleks.

    b. Kekurangan SSAD:

    1. Metodologi SSAD kurang fleksibel dan sulit untuk dimodifikasi ketika terjadi perubahan kebutuhan.

    2. Metodologi SSAD tidak mempertimbangkan aspek berorientasi objek dalam pengembangan sistem.

    3. Metodologi SSAD cenderung menghasilkan sistem yang kurang interaktif dan kurang responsif terhadap perubahan lingkungan bisnis.

2. Kekurangan & Kelebihan OOAD

    a. Kelebihan OOAD:

    1. Metodologi OOAD dapat menghasilkan sistem yang mudah dimodifikasi dan dapat memanfaatkan kembali kode yang telah ada.

    2. Metodologi OOAD dapat menghasilkan sistem yang memiliki kualitas yang lebih baik dan lebih andal.

    3. Metodologi OOAD dapat memastikan bahwa sistem yang dihasilkan lebih interaktif dan lebih responsif terhadap perubahan lingkungan bisnis.

    4. Metodologi OOAD lebih cocok untuk sistem yang kompleks dan besar.

    b. Kekurangan OOAD:

    1.Metodologi OOAD membutuhkan waktu dan sumber daya yang lebih besar untuk implementasi dibandingkan dengan SSAD.

    2. Metodologi OOAD membutuhkan tingkat keahlian yang lebih tinggi dalam pemrograman berorientasi objek.

    3. Metodologi OOAD membutuhkan analisis yang lebih detail dalam mengidentifikasi kelas dan objek yang diperlukan.

III. Kesimpulan

    Perbedaan antara SSAD dan OOAD adalah pada pendekatan dan konsepnya. SSAD menggunakan pendekatan berstruktur dan fokus pada aliran data dalam sistem, sedangkan OOAD menggunakan konsep OOP dan fokus pada objek dalam sistem. Keduanya memiliki kelebihan dan kekurangan masing-masing dan dapat dipilih berdasarkan kebutuhan dan lingkungan pengembangan sistem yang berbeda.

Share link: https://f24.link/kTXrc

Penulis: Muhammad Fathur Rizqi (D1041221020) - Mahasiswa Semester 2 Fakultas Teknik Prodi Informatika Untan

Disunting pada: Sabtu, 11 Maret 2023, 17:20 WIB

Sumber dan Referensi:

Academia - Paradigma Analisis Desain SSAD & OOAD: https://www.academia.edu/37469514/Paradigma_Analisis_Desain_SSAD_and_OOAD (diakses 11 Maret 2023)

BSI Web - Bagian F: https://repository.bsi.ac.id/index.php/unduh/item/324140/Bagian-F.pdf (diakses 11 Maret 2023)

Tags: Software, engineering, analisis kebutuhan, requirement engineering, SSAD, OOAD, Analisis Desain SSAD & OOAD, OOP, perangkat lunak, metodologi, kelebihan & kekurangan SSAD dan OOAD, desain perangkat lunak, PL.

Read More

Rekayasa Kebutuhan

Rekayasa Kebutuhan (Requirements Engineering)

    Di zaman sekarang penggunaan software sangatlah umum. Tidak dapat dipungkiri lagi, hal tersebut sudah menjadi kebutuhan dizaman sekarang. Kali ini saya akan menjelaskan tentang rekayasa kebutuhan, lebih tepatnya kebutuhan software.

Sumber: https://e-learning.untan.ac.id/learning/mod/lesson/view.php?id=32835

I. Penjelasan dan Contoh Requirement Engineering

   Requirement Engineering adalah sekumpulan informasi yang menjelaskan persyaratan yang harus dipenuhi oleh perangkat lunak atau sistem komputer. Dalam pengembangan perangkat lunak, software requirement diperlukan untuk memandu pengembangan perangkat lunak berdasarkan kebutuhan pengguna dan sistem.

    Berikut ini adalah penjelasan dan contoh beberapa jenis software requirement:

1. User Requirement (Kebutuhan Pengguna)

    User Requirement adalah kebutuhan fungsional dan nonfungsional yang harus dipenuhi oleh perangkat lunak untuk memenuhi kebutuhan pengguna. Persyaratan pengguna didasarkan pada kebutuhan bisnis dan kebutuhan pengguna akhir. Contoh user requirement:

    a.Perangkat lunak harus mudah digunakan dan intuitif bagi pengguna akhir. 

    b. Perangkat lunak harus mampu mengolah data dengan cepat dan akurat.

    c. Perangkat lunak harus dapat berjalan di berbagai sistem operasi, seperti Windows, MacOS, dan Linux.

2. System Requirement (Kebutuhan Sistem)

    System requirement adalah kebutuhan software yang terkait dengan infrastruktur teknologi dan lingkungan operasi di mana perangkat lunak akan dijalankan. Berikut adalah contoh System Requirement:

    a. Perangkat lunak harus dapat beroperasi di lingkungan jaringan yang aman.

    b. Perangkat lunak harus dapat diinstal dan dijalankan di server dengan spesifikasi minimum tertentu, seperti RAM, prosesor, dan penyimpanan yang memadai. 

    c. Perangkat lunak harus dapat memenuhi persyaratan privasi dan keamanan data, seperti enkripsi dan autentikasi pengguna.

3. Functional Requirement (Kebutuhan Fungsi)

    Persyaratan fungsional adalah kebutuhan yang terkait dengan fitur perangkat lunak dan fungsionalitas yang harus dipenuhi. Berikut adalah contoh dari persyaratan fungsional:

    a. Perangkat lunak harus dapat menyimpan data pengguna dan mengambilnya saat dibutuhkan.

    b. Perangkat lunak harus dapat melakukan perhitungan dan analisis data sesuai dengan kebutuhan bisnis.

    c. Perangkat lunak harus dapat menghasilkan laporan dan grafik yang memudahkan pengambilan keputusan. 

4. Non-functional Requirement (Persyaratan nonfungsional)

    Persyaratan nonfungsional adalah kebutuhan yang tidak terkait dengan fitur dan fungsionalitas perangkat lunak, tetapi dengan kinerja, keamanan, dan kualitas perangkat lunak. Berikut adalah contoh dari persyaratan nonfungsional:

    a. Perangkat lunak harus mampu memberikan waktu respons yang cepat dan kinerja yang konsisten.

    b. Pengguna dengan disabilitas, seperti pengguna tunanetra atau tunanetra, harus mengakses dan menggunakan perangkat lunak ini.

    c. Perangkat lunak harus mematuhi standar keamanan dan privasi data yang berlaku, seperti GDPR atau HIPAA. 

II. Analisis Kebutuhan

    Analis sistem (System Analyst) dalam organisasi TI adalah orang yang bertugas dalam menganalisis persyaratan sistem yang diusulkan dan memastikan bahwa persyaratan disusun dan didokumentasikan dengan baik & benar. Peran analis dimulai selama Fase Analisis Perangkat Lunak SDLC. Merupakan tanggung jawab analis untuk memastikan bahwa perangkat lunak yang dikembangkan memenuhi persyaratan klien.

    Analis Sistem memiliki tanggung jawab sebagai berikut:

    a. Menganalisis dan memahami persyaratan perangkat lunak yang dimaksud

    b. Memahami bagaimana proyek akan berkontribusi dalam tujuan organisasi

    c. Mengidentifikasi sumber kebutuhan

    d. Validasi persyaratan

    e. Mengembangkan dan menerapkan rencana manajemen kebutuhan

    f. Dokumentasi persyaratan bisnis, teknis, proses dan produk

    g. Koordinasi dengan klien untuk memprioritaskan persyaratan dan menghapus dan ambiguitas

    h. Menyelesaikan kriteria penerimaan dengan klien dan pemangku kepentingan lainnya

III. Hal Lainnya Tentang Rekayasa Kebutuhan Perangkat Lunak (Software Requirement)

1. Karakteristik Kebutuhan Perangkat Lunak

    Mengumpulkan persyaratan perangkat lunak merupakan dasar dari keseluruhan proyek pengembangan perangkat lunak. Oleh karena itu mereka harus jelas, benar dan terdefinisi dengan baik.

    Karakteristik software requirement yang baik harus:

    a. Bersih (Clear)

    b. Benar (Correct)

    c. Konsisten (Consistent)

    d. Koheren (Coherent)

    e. Dapat dipahami (Comprehensible)

    f. Dapat dimodifikasi (Modifiable)

    g. Dapat diverifikasi (Verifiable)

    h. Diprioritaskan (Prioritized)

    i. Jelas /tidak ambiguis (Unambiguous)

    j. Dapat dilacak (Traceable)

    k. Sumber yang dapat dipercaya (Credible source)

2. UI Requirement

    UI adalah bagian penting dari perangkat lunak atau perangkat keras atau sistem hybrid apa pun. Perangkat lunak diterima secara luas apabila:

    a. mudah dioperasikan

    b. cepat dalam menanggapi

    c. efektif menangani kesalahan operasional

    d. menyediakan antarmuka pengguna yang sederhana namun konsisten

3. Requirement Elicitation Process (Proses Elisitasi Kebutuhan)

    Proses elisitasi kebutuhan dapat digambarkan dengan menggunakan diagram berikut:

sumber: https://www.tutorialspoint.com/software_engineering/images/requirement_elicitation_process.png

    Urutan proses elisitasi adalah sebagai berikut:

a. Requirement Gathering

    Developer berdiskusi dengan klien dan pengguna akhir dan mengetahui harapan mereka dari perangkat lunak.

b. Organizing Requirements

    Pengembang memprioritaskan dan mengatur persyaratan dalam urutan kepentingan, urgensi, dan kenyamanan.

c. Negotiation & discussion (Negosiasi & diskusi )

    Jika persyaratan ambigu atau ada beberapa konflik dalam persyaratan dari berbagai pemangku kepentingan, jika ya, maka akan dinegosiasikan dan didiskusikan dengan pemangku kepentingan. Persyaratan kemudian dapat diprioritaskan dan dikompromikan secara wajar.

    Persyaratan tersebut berasal dari berbagai pemangku kepentingan. Untuk menghilangkan ambiguitas dan konflik, mereka didiskusikan untuk kejelasan dan kebenaran. Persyaratan yang tidak realistis dikompromikan secara wajar.

d. Documentation (Dokumentasi) 

    Semua persyaratan formal & informal, fungsional dan non-fungsional didokumentasikan dan tersedia untuk pemrosesan tahap berikutnya.

IV. Kesimpulan

    Requirements engineering adalah proses mendefinisikan, menganalisis, dan mengelola kebutuhan-kebutuhan software atau sistem. Proses ini sangat penting dalam pengembangan software karena keberhasilan suatu proyek software sangat bergantung pada kemampuan tim pengembang untuk memahami dan memenuhi kebutuhan pengguna dan sistem.

    Kesimpulannya, requirements engineering sangatlah penting dalam proses pengembangan software karena:

1. Membantu memahami dan memenuhi kebutuhan pengguna dan sistem

2. Meningkatkan kualitas dan keberhasilan software

3. Mengurangi biaya dan waktu pengembangan dengan mencegah kesalahan dan perubahan kebutuhan yang tidak perlu

4. Memungkinkan tim pengembang untuk bekerja lebih efisien dan efektif dengan panduan yang jelas dan terorganisir.

    Dengan demikian, penggunaan requirements engineering secara efektif dapat membantu dalam mencapai tujuan pengembangan software yang sukses.

Penulis: Muhammad Fathur Rizqi (D1041221020) - Mahasiswa Semester 2 Fakultas Teknik Prodi Informatika Untan

Disunting pada: Jumat, 3 Maret 2023, 21:05

Sumber dan Referensi:

Wikipedia - Software Requirements: https://en.wikipedia.org/wiki/Software_requirements (diakses 3 Maret 2023)

Tutorials Point - Software Requirements: https://www.tutorialspoint.com/software_engineering/software_requirements.htm (diakses 3 Maret 2023)

Geeksforgeeks - Software Engineering | Classification of Software Requirements: https://www.geeksforgeeks.org/software-engineering-classification-of-software-requirements/ (diakses 3 Maret 2023)

Badr - Panduan Menyusun Dokumen Software Requirement Specification (SRS): https://badr.co.id/id/panduan-menyusun-dokumen-software-requirement-specification-srs/ (diakses 3 Maret 2023)

Studocu - Software Requirements: https://www.studocu.com/id/document/universitas-lambung-mangkurat/rekayasa-perangkat-lunak/software-requirements/44263896 (diakses 3 Maret 2023)

Tags: Software, engineering, elisitasi, elicitation, analisis kebutuhan, requirement engineering, srs, sw requirement

Read More