Rekayasa Perangkat Lunak Pressman Pdf 269
Sofie Kovalcheck
Hampir tiga dekade lamanya sejak edisi pertama buku ini ditulis. Selama tiga dekade tersebut, rekayasa perangkat lunak meluas dari sebuah gagasan kabur yang dipraktikkan oleh sejumlah kecil pengikut setia sampai pada ilmu rekayasa yang sah. Buku edisi 7 ini mengalami pembaruan yang cukup signifikan. Buku ini direvisi dan distruktur ulang untuk meningkatkan bobot akademisnya. Juga menekankan proses-proses dan praktik-praktik rekayasa perangkat lunak yang baru serta penting.Tiga puluh dua bab dari edisi tujuh ini telah diatur ulang menjadi lima bagian (dalam Buku 1 dan Buku 1). Pengaturan ini, yang berlainan dengan edisi enam, dilakukan untuk menggolongkan dengan lebih baik topik-topik serta membantu para dosen yang barangkali tidak memiliki cukup waktu untuk menyelesaikan seluruh isi buku dalam satu semester.
Perangkat lunak komputer (computer software) kemungkinan besar merupakan salah satu hasil karya manusia yang paling kompleks yang pernah dikerjakannya. Rekayasa perangkat lunak (software engineering) ... Lihat Selengkapnya
Lima puluh persen lebih program aplikasi yang pernah dikembangkan oleh berbagai vendor perangkat lu nak di Amerika Serikat sebelum tahun 2000 pada akhirnya tidak pernah digunakan oleh calon ... Lihat Selengkapnya
Buku ini memberikan gambaran mengenai metode untuk mendapatkan nilai fator kepastian pengguna dalam aplikasi sistem pakar, yaitu dengan kuantifikasi pertanyaan. Untuk mendukung pemahaman mengenai ... Lihat Selengkapnya
Perpustakaan Universitas Bina Sarana Informatika merupakan layanan yang diberikan kepada civitas akademik khususnya mahasiswa untuk memperoleh informasi seperti buku, majalah, jurnal, prosiding, dll.
Metodologi merupakan kerangka pijakan utama dalam perancangan dan pengembangan perangkat lunak profesional untuk menghasilkan sebuah sistem informasi yang sesuai dengan kebutuhan bisnis sebuah organisasi. Keberhasilan pengembangan perangkat lunak bergantung pada pengelolaan proyek perangkat lunak secara keseluruhan. Tidak ada metodologi yang benar-benar sesuai dengan semua jenis organsasi, sehingga dibutuhkan pendekatan lebih lanjut untuk memilih metodologi mana yang paling sesuai untuk dapat diterapkan pada organisasi tertentu. Paper ini menjelaskan dan menganalisa metodologi pengembangan perangkat lunak yang meliputi: Linear Sequential Model atau Waterfall, Parallel Model, Iterative Model, Prototyping Model, RAD (Rapid Application Development) Model, Spiral Model, VShaped Model dan Agile Development untuk membuat perbandingan yang menunjukan kelebihan dan kelemahan masing-masing. Hasil paper ini menunjukan pertimbangan pemilihan metodologi yang didasarkan pada faktor-faktor kriteria penilaian yang terdiri dari kejelasan persyaratan pengguna, keakraban dengan teknologi, kompleksitas sistem, sistem keandalan, jadwal waktu singkat dan visibility jadwal hingga mereferensi beberapa pendapat dari jurnal ilmiah.
1. Model Pengembangan Prototyping (Evolusioner)
Pengembangan evolusioner berdasarkan pada ide untuk mengembangkan implementasi awal, memperlihatkannya kepada user untuk dikomentari, dan memperbaikinya secara bertahap sampai sistem yang memenuhi persyaratan diperoleh.
Pengembangan prototyping terbagi dua:
Masalah dalam metode ini:
Proses tidak bisa dilihat. Manajer membutuhkan hasil reguler untuk mengukur kemajuan. Jika sistem dikembangkan dengan cepat, tidaklah efektif dari segi biaya jika dihasilkan dokumen yang merefleksikan setiap versi sistem.
Sistem seringkali memiliki struktur yang buruk. Perubahan yang terus-menerus cenderung merusak struktur perangkat lunak. Penyesuaian perubahan perangkat lunak menjadi semakin sulit dan mahal.
Diperlukan alat bantu dan teknik khusus. Keperluan ini memungkinkan pengembangan yang cepat tetapi mungkin tidak kompatibel dengan alat bantu atau teknik lain dan relatif hanya sedikit orang yang memiliki keahlian untuk memakainya.
2. Model Pengembangan Sistem Formal
Pengembangan sistem formal merupakan pendekatan terhadap pengembangan perangkat lunak yang memiliki kesamaan dengan model waterfall, tetapi proses pengembangannya didasarkan pada transformasi matematis dan dari spesifikasi sistem menjadi program yang dapat dijalankan.
Perbedaan antara pendekatan formal dengan waterfall:
1) Spesifikasi persyaratan perangkat lunak diperbaiki menjadi spesifikasi formal yang rinci yang dinyatakan dalam notasi matematis.
2) Proses pengembangan perancangan, implementasi, dan pengujian unit digantikan oleh proses pengembangan transformasional di mana spesifikasi formal diperbaiki, melalui serangkaian transformasi menjadi program.
Pada proses transformasi, representasi matematis formal dari sistem secara sistematis diubah menjadi representasi sistem yang lebih rinci, tetapi tetap benar secara matematis. Setiap langkah menambahkan perincian sampai spesifikasi formal diubah menjadi program yang ekivalen.
Keuntungan pendekatan transformasional adalah suatu program telah memenuhi spesifikasinya, bahwa jarak Antara setiap transformasi lebih kecil daripada jarak Antara spesifikasi dan program.
Contoh yang paling dikenal tentang proses pengembangan formal ini adalah proses Cleanroom, yang aslinya dikembangkan oleh IBM. Proses Cleanroom bergantung pada pengembangan perangkat lunak incremental dan setiap tahap dikembangkan dan kebenarannya di demonstrasikan dengan menggunakan pendekatan formal. Tidak ada pengujian kesalahan pada proses dan pengujian sistem difokuskan pada penilaian keandalan sistem.
3. Model Pengembangan Berorientasi Pemakaian Ulang (Reuse-oriented software engineering)
Metode pengembangan yang berorientasi pemakaian ulang ini bergantung pada sejumlah besar komponen perangkat lunak yang dapat didaur ulang, yang bisa didapat, dan beberapa kerangka kerja integrasi untuk komponen-komponen ini.
4. Model Pengembangan Waterfall
Model pertama yang diterbitkan untuk proses pengembangan perangkat lunak yang diambil dari proses rekayasa lain (Royce, 1970).
Tahap-tahap utama dari pengembangan ini:
Prinsip dari metode ini hasil dari setiap fase merupakan satu atau lebih dokumen yang disetujui. Fase berikutnya tidak boleh dimulai sebelum sebelumnya selesai. Pada prakteknya, tahap-tahap ini bertumpang tindih dan memberikan informasi satu sama lain.
Kekurangan model pengembangan Waterfall:
Untuk mengatasi masalah yang muncul pada model ini, komitmen harus dilakukan pada tahap awal proses. Model harus digunakan hanya ketika persyaratan dipahami dengan baik. Secara konsekuen, proses perangkat lunak yang berdasarkan pada pendekatan ini masih digunakan untuk pengembangan perangkat lunak, terutama jika merupakan bagian dari sistem proyek rekayasa yang lebih besar.
Setiap Loop dibagi menjadi beberapa sektor :
a. Objective settings (menentukan tujuan): menentukan tujuan dari fase yang ditentukan. Batasan-batasan pada proses dan produk sudah diketahui. Perencanaan sudah disiapkan. Resiko dari proyek sudah diketahui. Alternatif strategi sudah disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan.
b. Risk assessment and reduction (Penanganan dan pengurangan resiko): setiap resiko dianalisis secara detil pada sektor ini. Langkah-langkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan kebutuhan.
c. Development and Validation (Pembangunan dan pengujian): Setelah evaluasi resiko, maka model pengembangan sistem dipilih. Misalnya jika resiko user interface dominan, maka membuat prototype User Interface. Jika bagian keamanan yang bermasalah, maka menggunakan model formal dengan perhitungan matematis, dan jika masalahnya adalah integrasi sistem model waterfall lebih cocok
d. Planning: Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya rencana untuk loop selanjutnya.
Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan dalam waktu yang hampir bersamaan dalam batasan waktu yang sudah ditentukan.
a) Business modelling : menjawab pertanyaan-pertanyaan: informasi apa yang mengendalikan proses bisnis? Informasi apa yang dihasilkan? Siapa yang menghasilkan informasi? Kemana informasi itu diberikan? Siapa yang mengolah informasi? untuk kebutuhan dari sistem
b) Data modelling: aliran informasi yang sudah didefinisikan, disusun menjadi sekumpulan objek data. Ditentukan karakteristik/atribut dan hubungan antar objek-objek tersebut untuk analisis kebutuhan dan data
c) Process Modelling : objek data yang sudah didefinisikan diubah menjadi aliran informasi yang diperlukan untuk menjalankan fungsi-fungsi bisnis.
d) Application Generation: RAD menggunakan component program yang sudah ada atau membuat component yang bisa digunakan lagi, selama diperlukan.
e) Testing and Turnover: karena menggunakan component yang sudah ada, maka kebanyakan component sudah melalui uji atau testing. Namun, component baru dan interface harus tetap diuji.
5. Concurrent Models
Model ini bisa digunakan untuk pengembangan sistem client/server. Model pengembangan concurrent, disebut juga concurrent engineering, yang memungkinkan tim software untuk mewakili unsur-unsur berulang dan bersamaan pada salah satu model proses. Sebagai contoh, kegiatan pemodelan yang ditetapkan untuk model spiral dicapai dengan menerapkan satu atau lebih dari perangkat lunak tindakan rekayasa berikut: prototipe, analisis, dan desain. Kegiatan modeling dalam salah satu negara yang mencatat pada waktu tertentu. Demikian pula, kegiatan lainnya, tindakan, atau tugas (misalnya, komunikasi atau konstruksi) dapat direpresentasikan secara analog. Semua kegiatan rekayasa perangkat lunak yang ada secara bersamaan namun berada di negara-negara yang berbeda.
Pemodelan Concurrent mendefinisikan serangkaian acara yang akan memicu transisi dari negara ke negara untuk masing-masing kegiatan rekayasa perangkat lunak, tindakan, atau tugas. Sebagai contoh, selama tahap awal desain (tindakan rekayasa perangkat lunak utama yang terjadi selama kegiatan modeling), inkonsistensi dalam model persyaratan yang ditemukan. Ini menghasilkan analisis event koreksi model, yang akan memicu aksi analisis kebutuhan dari negara yang dilakukan ke negara perubahan menunggu.
Pemodelan Concurrent ini berlaku untuk semua jenis pengembangan perangkat lunak dan memberikan gambaran yang akurat tentang keadaan proyek. Setiap kegiatan, tindakan, atau tugas pada jaringan berjalan bersamaan dengan kegiatan, tindakan, atau tugas lain . Event yang dihasilkan pada satu titik dalam memicu transisi jaringan proses antara states.