Nama Kelompok 7:
Rama Nevta Hendra | 55415621
Rizky Nugraha Putra | 56415191
Robi Pradana M | 56415227
Rosiyana Dwi Anggarani | 56415276
Kelas :
4IA17
Perancangan dan Implementasi Perangkat Lunak (RPL)
Tahap implementasi pengembangan perangkat lunak ialah: Suatu proses
pengubahan spesifikasi sistem menjadi sistem yang dapat dijalankan. Pada
kegiatan-kegiatan proses perancangan yang spesifik terdapat lima bagian
diantaranya: Perancangan arsitektural merupakan subsistem-subsistem
yang membentuk sistem dan hubungan mereka diindentifikasikan dan
didokumentasikan. Spesifikasi abstrak untuk setiap subsistem, spesifikasi
abstrak dari layanan dan batas operasinya harus ditentukan. Perancangan
interface untuk setiap subsistem, interface dengan subsistem dirancang dan
didokumentasikan. Spesifikasi interface harus sudah jelas karena memungkinkan
subsistem dipakai tanpa mengetahui operasi sistem. Perancangan
komponen layanan dialokasikan pada komponen yang berbeda dan interface
komponen-komponen dirancang. Perancangan struktur data struktur data yang
dipakai pada implementasi sistem dirancang secara rinci dan dispesifikasi.
Model Umum
Proses Perancangan
Untuk model umum
proses perancangan, bisa dilihat pada gambar di bawah ini :
Model Umum
Proses Perancangan
Metode Perancangan dan Metode Terstruktur
Pendekatan yang
lebih metodis terhadap perancangan perangkat lunak adalah metode terstruktur
yang terdiri dari serangkaian notasi dan panduan. Sedangkan metode terstruktur
dapat mendukung beberapa atau semua model sistem berikut ini:
1.
Model aliran data: Sistem
dimodelkan dengan menggunakan transformasi dengan menggunakan transformasi data
yang terjadi pada saat pemrosesan.
2.
Model relasi entitas: Digunakan
untuk mendeskripsikan entitas-entitas dasar pada perancangan dan hubungan
diantaranya.
3.
Model Struktural: Komponen-komponen
sistem dan interaksinya didokumentasikan.
4.
Metode berorientasi obyek:
Terdiri dari model inheritansi (pewarisan) sistem, model hubungan statis dan
dinamis diantara objek dan bagaimana objek berinteraksi satu sama lain ketika
sistem dijalankan.
Proses Debug
Programmer melakukan pengujian terhadap kode yang telah
dikembangkan. Kegiatan tersebut menunjukkan error program yang harus
dihilangkan, kegiatan ini disebut debugging. Pengujian error dan debug ialah
proses yang berbeda. Pengujian menentukan adanya error sedangkan debug
berhubungan dengan pencarian lokasi dan pembetulan error.
Proses perangkat lunak ialah suatu kegiatan dalam pembuatan sistem
perangkat lunak. Model proses perangkat lunak adalah representasi abstrak dari
proses ini.
Rekayasa Persyaratan
Proses
pengembangan spesifikasi PL (perangkat lunak) mencangkup kegiatan berikut ini:
1.
Pengembangan spesifikasi yang
dapat dipahami oleh user sistem.
2.
Spesifikasi yang lebih rinci
bagi pengemban sistem
Validasi
Perangkat Lunak
Suatu proses pemeriksaan
untuk menjamin agar sistem telah sesuai dengan spesifikasi, memenuhi kebutuhan
sesungguhnya dari user sistem.
Teknologi CASE
(Computer Aided Software Engineering)
Memberikan
dukungan terotomasi bagi proses perangkat lunak.
CASE tool
Mendukung kegiatan
proses individual. Lingkungan CASE mendukung semua atau sebagian besar kegiatan
proses perangkat lunak (PL).
Pendukung Proses Terotomasi
Computer Aided
Software Engineering (CASE) adalah perangkat lunak yang digunakan untuk
mendukung kegiatan proses rekayasa perangkat lunak. Teknologi CASE memberikan
dukungan proses perangkat lunak yang mengotomasi beberapa kegiatan proses dan
memberikan informasi mengenai perangkat lunak yang sedang dikembangkan.
Contoh Proses
Pendukung Otomasi
–
Pengembangan model sistem
grafis sebagai bagian dari spesifikasi perancangan lunak.
–
Pemahaman rancangan dengan
kamus data yang menyimpan informasi entitas dan hubungan pada rancangan.
–
Pembuatan interface user dari
deskripsi interface grafis yang interaktif dengan user.
–
Debug program, menyediakan
informasi tentang program yang berjalan.
–
Terjemahan program yang
terotomasi dari bahasa pemrograman versi lama, contoh: cobol menjadi versi
lebih baru.
Klasifikasi CASE
Fugetta(1993)
mengusulkan klasifikasi sistem CASE dalam tiga kategori:
1.
tool (alat bantu) mendukung
pekerjaan proses indivudal seperti:
a.
periksa konsistensi
perancangan.
b.
kompilasi program
c.
membandingkan hasil pengujian.
Tool bisa berupa
berisfat umum (general purpose) atau dikelompokkan menjadi workbench.
2.
Workbench mendukung
fase/kegiatan proses seperti spesifikasi dan perancangan. Workbench biasanya
terdiri dari serangkaian tool dengan derajat integrasi yang lebih besar/lebih
kecil.
3.
Lingkungan mendukung semua atau
paling tidak bagian yang penting dari proses perangkat lunak. Lingkungan
biasanya mencakup beberapa workbench yang terintegrasi dengan suatu
cara.
4.
Workbench CASE adalah suatu
alat bantu yang mendukung fase khusus dari proses perangkat lunak seperti
perancangan, implementasi, atau pengujian.
5.
Keuntungan pengelompokkan CASE
Tool menjadi Workbench CASE adalah bahwa alat bantu tersebut dapat
bekerja bersama untuk memberikan dukungan yang lebih komprehensif yang dapat
dilakukan dengan satu alat bantu.
lihat gambar di
bawah ini:
Definisi persyaratan user adalah pernyatan, dalam bahasa natural
ditambah program, mengenai apa yang bisa kita harapkan oleh sistem dan batasan
operasinya. Definisi persyaratan sistem menentukan layanan dan batasan sistem
secara rinci. Dokumen persyaratan sistem atau spesifikasi fungsional harus
tepat. Dokumen ini berlaku sebagai kontrak antara pembeli dengan pengembang
perangkat lunak. Spesifikasi perancangan sistem adalah deskripsi abstrak dari
perancangan perangkat lunak yang menjadi dasar bagi perancangan yang lebih
rinci serta implementasi.
Persyaratan
Fungsional : Pernyataan layanan yang harus diberikan sistem, bagaimana
sistem harus berlaku pada situasi-situasi tertentu dan bagaimana sistem harus
bereaksi terhadap input tertentu.
Persyaratan non
Fungsional : Persyaratan ini merupakan batasan layanan atau fungsi yang diberikan
sistem. Dokumen ini meliputi batasan waktu, batasan pada proses pengembangan,
Standar.
Persyaratan
Domain : Dokumen ini adalah persyaratan yg datang dari domain aplikasi sistem
dan Merefleksikan karakteristik domain tersebut.
Persyaratan User
Persyaratan user untuk sistem harus mendeskripsikan persyaratan
fungsional & Non-fungsional sehingga dapat dipahami oleh user sistem yg
tidak memiliki Pengetahuan yang rinci. Persyaratan user tidak boleh
didefinisikan dengan model Implementasi. Persyaratan user harus ditulis dengan
memakai bahasa natural,Format dan diagram intuitif yg sederhana.
Persyaratan Sistem
Persyaratan
sistem digunakan sebagai titik awal perancangan sistem. Berisi model – model
sistem yg berbeda seperti model objek / model aliran data. Pada prinsipnya,
persyaratan ini menyatakan apa yg harus dilakukan sistem dan bukan bagaimana
sistem tersebut harus diimplementasi.
Spesifikasi Bahasa Terstruktur
Bahasa natural terstruktur adalah bentuk yang terbatas dari
bahasa natural untuk menulis persyaratan sistem. Formstandar digunakan untuk menspesifikasi persyaratan fungsional,
Informasi-informasi berikut ini harus dimasukkan :
1.
Deskripsi fungsi/ entitas yang
dispesifikasi.
2.
Deskripsi inputnya dan darimana
asalnya.
3.
Deskripsi outputnya dan kemana
perginya.
4.
Indikasi untuk apa entitas
lainnya digunakan.
5.
Deskripsi efek samping operasi.
Pada spesifikasi bahasa natural masih terdapat adanya kemenduaan
arti yang mungkin masih ada walaupun variabilitas sudah berkurang jauh. Metode
alternatif spesifikasi persyaratan menggunakan PDL dapat mengatasi masalah
tersebut.
Spesifikasi Persyaratan dengan PDL
Persyaratan dapat didefinisikan secara
operasional dengan PDL (Program Description Language )
untuk menghindari kemenduaan arti. PDL
merupakan bahasa yang berasal dari java.
Keuntungan PDL bahasa ini dapat diperiksa secara sintaksis
dan semantik dengan alat bantu Perangkat Lunak. Sedangkan
kerugian PDL diantaranya:
1.
Bahasa yg dipakai menulis
spesifikasi mungkin tidak cukup ekprsif memberi deskripsi fungsionalitas
sistem.
2.
Notasinya hanya dipahami oleh
oleh orang yang memiliki cukup pengetahuan tentang bahasa pemrograman.
3.
Persyaratan bisa diambil
sebagai perancangan spesifikasi desain ketimbang sebagai model utk membantu
user pahami sistem.
Spesifikasi Interface
Mayoritas sistem perangkat lunak
harus beroperasi dengan sistem lain yang telah diimplementasi dan diinstal pada suatu
lingkungan. Apabila sistem yang baru dan sistem yang sudah ada
bekerjasama, maka harus dibuat interface sistem dengan tepat.
End User
Development
Pengembangan
perangkat lunak oleh pemakai akhir
1.
Dikerjakan tanpa bantuan
profesional.
2.
Didukung oleh hadirnya Personal
Computer
Dengan bantuan
4GL
1.
Fourth generation language.
2.
Nonprocedural (less procedural)
language.
Jenis
–jenis 4GL antara lain:
1.
Query language.
2.
Report generator.
3.
Graphic language.
4.
Application generator.
5.
Very high level programming
language
6.
Application software package
7.
Microcomputer tools.
Perancangan Perangkat Lunak
Merancang adalah
proses kreatif, kuncinya harus sering berlatih. Terdapat tiga tahapan dalam
mengatasi problema dalam perancangan:
1.
Pelajari & pahami
permasalahan, Tanpa pemahaman tidak bermanfaat. Pemahaman bisa salah dengan
pemahaman yang salah membawa kearah yang salah. Pemahaman yang benar memudahkan
penerimaan oleh user. Kemudian lihat dari berbagai sudut pandang seperti:
kebutuhan bisa terlihat berbeda dan cara memenuhi kebutuhan (gunakan berbagai
pemodelan).
2.
Tentukan rancangan global, Buat garis besar
pemecahan masalah, rancang lebih dari satu alternatif dan lakukan evaluasi
bersama user. Untuk pilihan solusi tergantung pengalaman dan pengetahuan akan
mempengaruhi bentuk dan pilihan solusi. Ketersediaan reusable component
(komponen yang diadopsi dari sistem lain) kesederhaan (simplicity), rancangan
harus diupayakan sederhana.
3.
Buat rancangan rinci, Solusi yang
terpilih dirinci, dilakukan pada tahap-tahap implementasi. Rancangan dapat
memperlihatkan : kesalahan dan ketidaklengkapan.
Rancangan fungsional merupakan sistem yang dirancang dengan meilihat
proses apa saja yang ada didalamnya. Bertahap dari high level ke detial design.
Strategi yang dipakai structure design dengan memanfaatkan diantaranya: data
flow model, entity relationship model dan structure model (structure chart).
Rancangan Berorientasi Obyek Sistem dirancang sebagai
koleksi dari obyek. Ide dasarnya adalah information hiding (penyembunyian
informasi). Tiap obyek mempunyai sejumlah atribut dan operasi berdasarkan
atribut yang ada. Obyek berkomunikasi dengan obyek lainnya melalui message.
Kualitas Rancangan Tidak ada kesepakatan tentang rancangan yang baik. Rancangan harus sesuai spesifikasi.
Rancangan yang baik kemungkinan berbentuk:
1.
Rancangan efisien, menghasilkan
program yang bekerja efisien.
2.
Rancangan minimal, menghasilkan
program sangat kompak, ukurannya kecil.
3.
Rancangan yang mudah dirawat:
mudah diadaptasi dan disesuaikan dengan kebutuhan (diubah, ditambah, dikurangi)
4.
Rancangan terpadu: perubahan
bersifat lokal, kohesi tinggi dan kopling rendah.
Kohesi
Kohesi adalah keterkaitan aktivitas didalam modul-modul. Semakin tinggi kohesi semakin baik. Terdapat 7 macam kohesi:
Kohesi adalah keterkaitan aktivitas didalam modul-modul. Semakin tinggi kohesi semakin baik. Terdapat 7 macam kohesi:
1.
Functon cohesion – Hanya
mengerjakan tugas – Hanya mempunyai satu tujuan
2.
Sequential cohesion – Modul
mengerjakan tugas – Dengan memakai struktur data yang sama.
3.
Communicational cohesion – Modul berisi
sejumlah aktivitas, dengan memakai data yang sama. Contoh: update record in
database and write it to audit file
4.
Procedural cohesion – Modul
menerjakan tugas urutan proses tertentu. Contoh: read part from database and
update repair_rec on maint_file
5.
Temporal cohesion Modul berisi
kelompok komponen-komponen modul. – Terkelompok karena kesamaan waktu eksekusi.
6.
Logical cohesion – Modul berisi
kelompok komponen-komponen yang mengerjakan tugas yang sama. Contoh: sebuah
modul yang berisi semua kegiatan mencetak.
7.
Coincidental cohesion – Modul
mengerjakan beragam tugas, yang tidak saling terkait.





Tidak ada komentar:
Posting Komentar