Rangkuman Pertemuan Bab 4 RPL KONSEP PERANCANGAN

 

Rangkuman Pertemuan 4

Konsep Perancangan

Nama                          : Ira Zulvia

Nim                             : 12182446

Kelas                           : 12.6AA.07 (Teknik Komputer)

Mata Kuliah              : Rekayasa Perangkat Lunak

Dosen                          : Tyas Setiyarini, M.Kom

A.    Pengertian Perancangan Perangkat Lunak

Yaitu disiplin manajerial dan teknis yang berkaitan dengan pembuatan dan pemeliharan produk perangkat lunak secara sistematis, termasuk pengembangan dan modifikasinya, yang dilakukan pada waktu yang tepat dan dengan mempertimbangkan faktor biaya. Perancangan Perangkat Lunak merupakan tempat dimana aturan kreativitas (kebutuhan stakeholder, kebutuhan bisnis, dan pertimbangan teknis) semuanya secara bersamaan disatukan untuk membentuk sebuah produk atau sistem atau Perangkat Lunak.

Adapun model perancangan tersebut memberikan detail tentang bagaimana arsitektur perangkat, struktur data, antarmuka, dan komponen yang diperlukan untuk mengimplementasikan sistem.

 

B.     Tujuan Perancangan Perangkat Lunak

Yaitu untuk memperbaiki kualitas produk perangkat lunak, dan meningkatkan produktivitas atau untuk menghasilkan model atau representasi perangkat lunak yang memperlihatkan kekuatan, komoditi, dan kenyamanan. Adapun produk perangkat lunak yaitu perangkat lunak yang digunakan oleh berbagai pengguna.

C.   Model Perancangan Perangkat Lunak

1.      Perancangan Data atau Kelas

1)      Mengubah model kelas  menjadi realisasi kelas perancangan dan struktur data yang diperlukan untuk mengimplementasikan perangkat lunak. Perancangan ini merupakan hal yanh harus dilakukan dalam perangkat lunak.

2)      Objek, hubungan dan konten data rinci yang digambarkan oleh atribut kelas dan notasi lainnya memberikan dasar untuk aktivitas perancangan data dan juga memberikan penjelasan tentang perangkat lunak.

3)      Perancangan kelas yang lebih rinci terjadi karena setiap komponen perangkat lunak yang dirancang.

 

2.      Perancangan Arsitektur

1)      Mendefinisikan hubungan antara elemen struktural utama dari perangkat lunak, gaya dan pola arsitektur yang dapat digunakan untuk mencapai kebutuhan yang ditentukan untuk sistem, dan kendala yang mempengaruhi cara dimana arsitektur dapat diimplementasikan. Hal ini memberikan penjelasan tentang asritektur atau bagaimana proses perancangan berlangsung.

3.      Perancangan Antarmuka

1)      Menggambarkan bagaimana perangkat lunak berkomunikasi dengan sistem, dan dengan manusia yang menggunakannya.

2)      Antarmuka menyiratkan aliran informasi (misalnya :data  atau kontrol) dan jenis perilaku tertentu.

3)      Perancangan antarmuka pada tingkat komponen mengubah elemen struktural dari arsitektur perangkat lunak menjadi deskripsi prosedural komponen perangkat lunak.

 D.    Proses Perancangan

1)      Perancangan PL adalah proses yang bersifat iteratif dimana spesifikasi kebutuhan PL diterjemahkan menjadi “blue print" untuk membangun perangkat lunak

2)      Blue print yaitu menggambarkan pandangan holistik perangkat lunak. Yaitu, perancangan diwakili pada tingkat abstraksi yang tinggi padatingkat yang dapat langsung ditelusuri ke tujuan sistem dan data yang lebih rinci, fungsional, dan kebutuhan perilaku.

3)      Saat iterasi perancangan perangkat lunak berlangsung, penghalusan lebih lanjut akan menggerakkan abstraksi yang lebih rendah. 

E.    Atribut-atribut Kualitas Perangkat Lunak

1)    Perancangan perangkat lunak harus menerapkan semua spesifikasi kebutuhan yang secara eksplisit ada dalam model kebutuhan, dan mengakomodasi semua spesifikasi kebutuhan implisit yang diinginkan oleh stakeholder.

2)      Perancangan perangkat lunak harus menghasilkan produk kerja yang mudah dibaca dan dimengerti bagi mereka yang membuat kode-kode program dan yang akan melakukan mengujianuntukkemudian mendukung PL.

3)      Perancangan perangkat lunak seharusnya menyediakan gambaran lengkap tentang perangkat lunak, menangani permasalahan data, fungsional, dan perilaku dari perspektif implementasi.

F.    Panduan Kualitas Perangkat Lunak

Panduan kualitas perangkat lunak memiliki tujuan untuk mengevaluasi kualitas representasi perancangan.

1)      Rancangan perangkat lunak harus menunjukkan arsitektur yang :

a.     telah dibuat menggunakan gaya atau pola arsitektur yang dapat dikenali

b.      tersusun atas komponen-komponen yang menunjukkan karakteristik perancangan yang baik

c. dapat diimplementasikan secara evolusioner, danmemfasilitasi implementasi dan pengujian.

 

2)  Rancangan perangkat lunak harus bersifat modular, artinya perangkat lunak harus secara logis menjadi bagian dalam elemen-elemen atau subsistem.

3)  Rancangan perangkat lunak harus berisi representasi data, arsitektur, objek-objek, antarmuka, dan komponen yang berbeda.

4)  Rancangan perangkat lunak harus memuat struktur data yang sesuai untuk kelas yang akan diimplementasikan dan digambarkan dari pola-pola data yang dapat dikenali.

5)  Rancangan perangkat lunak harus mengarah pada komponen yang menunjukkan karakteristik fungsional yang bersifat independen.

6) Rancangan perangkat lunak harus memuat antarmuka yang mengurangi kompleksitas hubungan antar komponen dan dengan lingkungan eksternal.

7)   Rancangan perangkat lunak harus diturunkan dari metode perulangan yang dikendalikan oleh informasi yang diperoleh selama analisis kebutuhan perangkat lunak.

8) Sebuah perancangan harus direpresentasikan menggunakan notasi yang secara efektif mengkomunikasikan maknanya.

G.    Atribut-atribut Kualitas

1)      Fungsionalitas

2)      Penggunaan

3)      Keandalan

4)      Kinerja

5)      Daya Dukung

 

H.     Konsep-konsep Perancangan

1)    Kriteria yang digunakan untuk membagi perangkat lunak menjadi komponen yang bersifat mandiri

2)      Rincian fungsi/struktur data yang dapat dipisahkan dari representasi konseptual

3)      Kriteria yang digunakan untuk mendefinisikan kualitas teknis perancangan perangkat lunak.

 

I.    Abstraksi

1)    Pada tingkat abstraksi tertinggi, penyelesaian masalah dinyatakan dalam istilah luas menggunakan bahasa pada lingkungan permasalahan.

2)      Pada tingkat abstraksi yang paling rendah, penyelesaian masalah dapat langsung diimplementasikan menggunakan bahasa pemrograman yang dipilih.

 J.    Arsitektur

1)    Arsitektur sistem perangkat lunak merupakan struktur keseluruhan perangkat lunak dan cara bagaimana struktur tersebut memberikan integritas konseptual untuk suatu sistem perangkat lunak.

Properti sebagai bagian dari perancangan arsitektur, yaitu :

a.       Properti Struktural

b.      Properti fungsional tambahan

c.       Keluarga sistem yang berhubungan

 

K.     Pola  (Pattern)

1)      Pola adalah suatuwawasan yang di dalamnya memuat esensidari solusi yang terbukti untuk permasalahan perancangan perangkat lunak dalam konteks tertentu (Brad Appleton).

2)  Tujuan dari setiap pola perancangan adalah untuk memberikan deskripsi yang memungkinkan perancang untuk menentukan:

a.       Apakah pola berlaku untuk pekerjaan saat ini

b.      Apakah pola dapat digunakan kembali

c.       Apakah pola dapat berfungsi sebagai panduan untuk mengembangkan pola yang serupa, tetapi berbeda secara fungsional atau struktural.

 L.    Pemisahan Perhatian

        Pemisahan perhatian adalah konsep perancangan yang menunjukkan bahwa masalah yang kompleks dapat diselesaikan jika permasalahan itu dibagi menjadi bagian-bagian yang lebih kecil yang lebih mudah diselesaikan dan/atau dioptimalkan secara independen.

 

M.     Modularitas

1)      Modularitas adalah atribut tunggal dari perangkat lunak yang memungkinkan suatu program untuk dapat dikelola secara cerdas. Perangkat lunak monolitik adalah program besar yang terdiri dari satu modul. Tujuan modularitas :

a. Pengembangan perangkat lunak dapat lebih mudah direncanakan

b.Versi-versi perangkat lunak dapat didefinisikan

c. Perubahan-perubahan dapat dengan mudah diakomodasikan

d. Testing dan debugging dapat dilakukan secara lebih efisien

e. Mudah dalam pemeliharaan perangkat lunak.

 

N.    Penyembunyian Informasi

            

     Maksudnya bahwa Modul perangkat lunak harus dispesifikasikan dan dirancang sedemikian rupa sehingga informasi (algoritma dan data) yang terdapat dalam modul tidak dapat diakses oleh modul lain yang tidak memerlukan informasi tersebut. Penyembunyian informasi (Information hiding) menyiratkan bahwa modularitas yang efektif dapat dicapai dengan mendefinisikan sejumlahmodul independen yang berkomunikasi satu sama lain dalam halinformasi yang diperlukan untuk mencapai fungsi perangkat lunak. Manfaatnya ketika modifikasi tertentu perlu dilakukan selama pengujian peragkat lunak dan selama pemeliharaan perangkat lunak

O.    Independensi Fungsional

       Konsep independensi fungsional adalah hasil langsung dari pemisahan masalah, modularitas, dan konsep abstraksi dan penyembunyian informasi. Independensi fungsional dicapai dengan cara mengembangkan modul yang memiliki fungsi tunggal (single-minded) dan memiliki interaksi yang bersifat tertutup dengan modul lain. Modul indenpendensi memiliki kriteria kualitatif, yaitu :

a.       Kohesivitas yaitu indikasi dari kekuatan fungsional suatu modul.

b.      Kebergantungan (Coupling) yaitu indikasi dari kemandirian antar modul.

P.    Penghalusan

Penghalusan merupakan proses elaborasi yang dimulai dengan pernyataan fungsi (atau deskripsi informasi) yang didefinisikan pada tingkat abstraksi yang tinggi. Penghalusan langkah demi langkah menggunakan strategi perancangan top-down. Penghalusan membantu untuk mendapatkan rincian pada tingkat rendah saat perancangan berlangsung.

 

Q.     Refaktorasi

Refaktorisasi adalah teknik reorganisasi perancangan perangkat lunak yang bertujuan untuk menyederhanakan perancangan (atau kode) dari komponen tanpa harus mengubah fungsi atau perilakunya.  Refaktorisasi perangkat lunak, diperiksa kembali untuk :

a. Menemukan redundansi

b. Menemukan elemen perancangan yang tidak digunakan

c. Menemukanalgoritma yang tidak efisien (tidak perlu)

d. Menemukan struktur data yangkonstruksinyaburuk

e. Menemukan kegagalan perancangan lainnya yang dapat diperbaiki untuk menghasilkan perancangan yang lebih baik.

 

 

 

 

 

 

TUGAS PERTEMUAN 3 TUJUH KEGIATAN REKAYASA KEBUTUHAN PADA RPL

 

TUGAS PERTEMUAN 3

REKAYASA PERANGKAT LUNAK

Nama                          : Ira Zulvia

Nim                             : 12182446

Kelas                           : 12.6AA.07

Kode Mata Kuliah    : 956

Dosen                          : Tyas Setiyarini, M.Kom

1.      Latar Belakang dan Penjelasan Tentang 7 Kegiatan Pada Rekayasa Kebutuhan

Latar belakang mengapa perlu adanya rekayasa kebutuhan dalam suatu kegiatan adalah kenyataan bahwa menemukan kebutuhan konsumen secara lengkap yaitu tidak mudah dan mahal. Tidak mudah karena :

1)      klien tidak selalu mengetahui dengan pasti dan jelas apa yang diperlukan

2)      kebutuhan yang diutarakan oleh klien tidak selalu sesuai dengan apa yang dimaksud

3)      kebutuhan klien berubah-ubah di sepanjang kegiatan pembangunan perangkat lunak

Hal-hal di atas menyebabkan biaya pembangunan perangkat lunak menjadi mahal karena ada tambahan biaya lagi untuk perubahan yang dilakukan dan waktu yang dibutuhkan lebih dari seharusnya atau target yang telah ditetapkan sebelumnya.

Contohnya pada rekayasa kebutuhan dalam membangun sebuah sistem penggajian karyawan menuju desain dan pembangunan perangkat lunak dengan menyediakan mekanisme yang tepat untuk memahami apa yang diinginkan konsumen Perusahaan Metland Transyogi, menganalisis kebutuhan apa saja yang diinginkan, menguji kelayakan sistem penggajian karyawan, bernegosiasi untuk solusi yang masuk akal, menetapkan solusi yang dapat dipahami dua belah pihak, uji spesifikasi dan mengelola kebutuhan yang akan diwujudkan ke sistem operasional. Rekayasa kebutuhan pun terdiri dari 7 fungsi, yaitu :

1)      Inception (Permulaan)

Inception atau permulaan, merupakan awal dari terjadinya pembicaraan tentang kebutuhan akan software yang diinginkan oleh konsumen seperti pada pihak Perusahaan Metland Transyogi dalam pembuatan sistem penggajian karyawan. Permulaan ini dapat terjadi karena dari pembicaraan biasa, kebutuhan bisnis yang dirasakan, adanya pasar potensial, atau munculnya layanan potensial yang dapat dilakukan oleh software.

Aktifitas diawali dengan penetapan siapa stakeholder/pihak-pihak terkait dengan perangkat lunak yang akan dibangun. Misalnya, yaitu :

a.       Business operation manager

b.      Product managers

c.       Marketing people

d.       Internal + external customer

e.        End-users

f.       Consultants

g.       Product engineers

h.      Software engineers

i.        Support and maintenance engineers

j.        Others.

Kebutuhan dieksplorasi dari berbagai pandangan dari masing-masing stakeholders. Kebutuhan yang sama dan berbeda dari masing-masing dicatat, perbedaan persepsi diluruskan atau segera diperbaiki agar tidak terjadi ketidakseimbangan antara kedua belah pihak. Pertanyaan-pertanyaan awal/dasar dilontarkan kepada setiap stakeholder.

2)      Elicitation (Pengungkapan)

           Konsumen mengungkapkan kebutuhan apa saja yang ingin diwujudkan atau ingin segera dilakukan agar sistem penggajian karyawan pun segera terlaksana. Proses ini tidak mudah karena, batasan sistem sering tidak jelas, konsumen tidak cukup paham apa yang dibutuhkan dan kebutuhan sering berubah. Aktifitas dilakukan dalam bentuk pertemuan, dimana setiap stakeholder yang diundang diminta untuk membuat daftar kebutuhan software yang disertai penjelasan tentang karakteristik atau detail dari kemampuan tersebut. 

3)      Elaboration (Penjelasan)

    Apa yang diungkapkan pada proses permulaan dan pengungkapan kebutuhan, dijelaskan panjang lebar. Fokus pada pemodelan fungsi, fitur dan batasan dari perangkat lunak. Dalam kasus OOP, maka class, atribute dan hubungan antar class diidentifikasi pada aktifitas ini. Penjelasan ini bertujuan untuk menjabarkan atau menyampaikan secara rinci tentang kebutuhan yang diinginkan agar tidak terjadi kesalahpahaman antar kedua belah pihak yang bersangkutan.

4)      Negotiation (Konflik Resolusi)

     Jika terjadi konflik kepentingan karena perbedaan kebutuhan antara bagian pada konsumen, atau antar end-user, maka aktifitas negosiasi diperlukan untuk membuat prioritas kebutuhan, mengevaluasi tiap kebutuhan untuk mengurangi atau mengubah sesuai dengan yang dimaksud pihak-pihak yang berkonflik. Dalam suatu kebutuhan di setiap kegiatan yang dilakukan akan selalu ada konflik yang timbul. Oleh sebab itu, harus adanya komunikasi yang baik dan mencari jalan terbaik untuk memecahkan masalah atau konflik yang sedang terjadi.

5)      Specification (Sfesisikasi)

      Spesifikasi dapat berupa dokumen, model grafik, model matematika, skenario atau prototype yang merupakan produk akhir dari rekayasa kebutuhan. Apa yang disajikan sebagai spesifikasi merupakan hasil identifikasi kebutuhan melalui aktifitas-aktifitas sebelumnya. Spesifikasi menggambarkan fungsi dan kinerja dari perangkat lunak dan batasan-batasan yang ditentukan oleh kedua belah pihak yang telah sepakat. Dalam kasus ini ada biasanya memakai model prototype. Model prototype adalah pendefinisian sejumlah sasaran perangkat lunak berdasarkan kebutuhan dan pemahaman secara umum, tetapi tidak bisa mengidentifikasi kebutuhan secara rinci untuk beberapa fungsi dan fitur-fitur.

Tahap-tahapan prototype yaitu :

1) Sebelum kita membuat atau merancang suatu sistem, tentunya kita harus mengomunikasikan terlebih dahulu apa yang ingin dituju atau bagaimana prosesnya. Pada Perusahaan Metland Transyogi, sebaiknya terlebih dahulu membicarakan untuk membuat sistem penggajian karyawannya kepada pimpinan.

2) Setelah itu, sasaran yang dilakukan yaitu seluruh karyawan Metland Transyogi dan bagaimana proses atau tujuan yang dijalankannya dan dibicarakan kepada pimpinan tersebut.

3) Membuat suatu model atau desain yang tepat dalam pembuatan sistem penggajian karyawan Metland Transyogi.

4) Prototype yang telah dibuat diserahkan kepada pimpinan untuk di evaluasi dan diberi masukan, jika ada yang kurang memuaskan.

5) Kemudian, ada perbaikan dan pengembangan sistem yang dilakukan dalam proses tersebut dan biasanya bersifat dinamis serta ada timbal balik yang diberikannya dalam pembuatan sistem tersebut.

6)      Validation (Validasi)

     Menguji kualitas dari spesifikasi untuk memastikan kebutuhan yang dinyatakan dapat diterima/sepaham, konsisten, lengkap dan bebas kesalahan. Mekanisme yang dapat dilakukan adalah formal technical review atau pertemuan evaluasi teknis. Validasi Ini adalah juga penting untuk memverifikasi bahwa dokumen persyaratan sesuai dengan standar perusahaan, dan bahwa hal itu dapat dipahami, konsisten, dan lengkap.

         Persyaratan validasi berkaitan dengan proses pemeriksaan dokumen persyaratan untuk memastikan bahwa perangkat lunak mendefinisikan hak (yaitu, perangkat lunak yang mengharapkan para pengguna). 

7)      Management Kebutuhan (Requirement Management)

      Mengelola kebutuhan dengan identifikasi, kontrol dan mengikuti perkembangan kebutuhan software yang dikerjakan selama sistem yang dibuat dan perubahan-perubahan yang terjadi. Management kebutuhan merupakan sekumpulan kegiatan yang membantu tim sistem untuk mengindentifikasi, pengawasan, dan melacak perubahan kebutuhan setiap saat pada tahapan pembuatan sistem penggajian karyawan di Perusahaan Metland Transyogi.

Sumber referensi :

http://lecturer.ukdw.ac.id/othie/index.php?itemid=36