Disiplin teknik seperti rekayasa perangkat lunak hanya menggunakan prinsip-prinsip yang dipahami dan didokumentasikan dengan baik. Pada bagian ini, kita akan mengkaji bagaimana disiplin rekayasa perangkat lunak telah berkembang selama bertahun-tahun.
PROYEK PENGEMBANGAN PERANGKAT LUNAK
Disebut produk perangkat lunak generik karena banyak pengguna pada dasarnya menggunakan perangkat lunak yang sama. Biasanya perusahaan pengembang mengembangkan perangkat lunak khusus dengan mengadaptasi beberapa perangkat lunak yang ada.
GAYA EKSPLORASI PENGEMBANGAN PERANGKAT LUNAK
Seperti yang ditunjukkan pada Gambar 1-5, memori jangka pendek berpartisipasi dalam semua interaksi pikiran manusia dengan lingkungannya. Selain itu, informasi yang diambil dari memori jangka panjang disimpan terlebih dahulu di memori jangka pendek.
MUNCULNYA TEKNIK PERANGKAT LUNAK
Hal ini sangat mengurangi upaya yang diperlukan untuk mengembangkan perangkat lunak dan membantu pemrogram menulis program yang lebih besar (mengapa?). Dapat dilihat bahwa kemajuan luar biasa dalam teknik desain perangkat lunak terjadi hampir setiap dekade.
PERUBAHAN UTAMA DALAM PRAKTIK PENGEMBANGAN PERANGKAT LUNAK Sebelum kita membahas rincian berbagai prinsip rekayasa perangkat lunak, ada Sebelum kita membahas rincian berbagai prinsip rekayasa perangkat lunak, ada
Bagaimana pemrograman berorientasi aspek, desain berbasis klien-server, dan teknik desain perangkat lunak tertanam dengan cepat muncul. Selain kemajuan dalam teknik desain perangkat lunak, beberapa konsep dan teknik baru untuk pengembangan perangkat lunak yang efektif juga telah diperkenalkan.
TEKNIK SISTEM KOMPUTER
Dalam rekayasa sistem, pengujian perangkat lunak selama pengembangan adalah masalah yang kompleks, perangkat keras tempat perangkat lunak akan dijalankan dan diuji masih dalam pengembangan - ingatlah bahwa perangkat keras dan perangkat lunak sedang dikembangkan pada saat yang bersamaan. Untuk menguji perangkat lunak selama pengembangan, biasanya diperlukan pengembangan simulator yang meniru karakteristik perangkat keras yang sedang dikembangkan.
RINGKASAN
LATIHAN
Bagaimana prinsip-prinsip rekayasa perangkat lunak membantu mengatasi peningkatan pesat dalam waktu dan biaya pengembangan. Apa yang Anda pahami tentang gaya pengembangan perangkat lunak eksploratif (juga dikenal sebagai build and fix)?
MODEL SIKLUS HIDUP PERANGKAT LUNAK
BEBERAPA KONSEP DASAR
Dalam penggunaannya, proses pengembangan perangkat lunak menggambarkan aktivitas siklus hidup yang lebih rinci dan kompleks dibandingkan dengan SDLC. Saat ini, organisasi pengembangan perangkat lunak yang baik biasanya mendokumentasikan proses pengembangan mereka dalam bentuk buklet.
MODEL AIR TERJUN DAN PERLUASANNYA
Oleh karena itu, model air terjun klasik hampir tidak berguna untuk pengembangan perangkat lunak. Pada bagian sebelumnya saya menunjukkan bahwa untuk proyek pengembangan perangkat lunak praktis, model air terjun klasik sulit digunakan.
Model
- RAPID APPLICATION DEVELOPMENT (RAD)
- MODEL PENGEMBANGAN CEPAT
- MODEL SPIRAL
Pengembangan Berulang: Setelah klien menyetujui prototipe, perangkat lunak sebenarnya dikembangkan menggunakan pendekatan air terjun berulang. Penggunaan model air terjun secara berulang menghasilkan produksi dokumentasi berkualitas baik yang dapat membantu selama pemeliharaan perangkat lunak.
Kegiatan selama kuadran ketiga terdiri dari pengembangan dan verifikasi perangkat lunak tingkat berikutnya. Pada akhir kuadran ketiga, fitur yang diidentifikasi telah
Kuadran 4: Kegiatan selama kuadran keempat berkaitan dengan meninjau hasil tahapan yang dilalui sejauh ini (yaitu versi perangkat lunak yang dikembangkan) dengan
- PERBANDINGAN MODEL SIKLUS HIDUP YANG BERBEDA
- RINGKASAN
- LATIHAN
Model air terjun berulang mungkin merupakan model pengembangan perangkat lunak yang paling banyak digunakan hingga saat ini. Model siklus hidup berikut ini yang tidak melibatkan pembuatan prototipe pada tahap apa pun selama pengembangan perangkat lunak. Model siklus hidup evolusioner cocok untuk mengembangkan perangkat lunak yang tampaknya penuh dengan beragam risiko.
Model siklus hidup manakah yang akan Anda ikuti untuk mengembangkan perangkat lunak untuk setiap aplikasi berikut. Bandingkan keuntungan relatif menggunakan model air terjun berulang dan model spiral pengembangan perangkat lunak untuk mengembangkan aplikasi MIS. Jelaskan dengan menggunakan contoh yang sesuai jenis proyek pengembangan perangkat lunak yang sesuai dengan model siklus hidup evolusioner.
Untuk mengembangkan perangkat lunak penggajian untuk organisasi ini, model siklus hidup mana yang harus digunakan.
MANAJEMEN PROYEK PERANGKAT LUNAK
KOMPLEKSITAS MANAJEMEN PROYEK PERANGKAT LUNAK
Perubahan ini biasanya diakibatkan oleh perubahan praktik bisnis, perubahan pada perangkat keras atau perangkat lunak yang mendasarinya (misalnya sistem operasi, aplikasi lain), atau sekadar dari pikiran pelanggan. Karena kompleksitas fungsional yang melekat pada produk perangkat lunak dalam hal bagian dasar yang membentuk perangkat lunak, banyak jenis risiko yang terkait dengan pengembangannya. Akibatnya, seorang manajer proyek perangkat lunak harus menghadapi banyak masalah yang tidak terduga di hampir setiap proyek yang dikelolanya.
Persyaratan ini tidak hanya mempersulit pembuatan dan pengoperasian produk perangkat lunak, namun juga mempersulit penggunaan kembali bagian-bagian dari satu produk perangkat lunak. Persyaratan kecocokan yang tepat dari parameter fungsional ini menimbulkan risiko tambahan dan menambah kompleksitas pengelolaan proyek perangkat lunak. Pekerjaan yang berorientasi tim dan intelektual: Proyek pengembangan perangkat lunak mirip dengan proyek penelitian karena melibatkan pekerjaan yang berorientasi tim dan intensif intelijen.
Dalam proyek pengembangan perangkat lunak, tidak hanya aktivitas siklus hidup yang sangat intensif, namun setiap anggota harus berkomunikasi, meninjau, dan berinteraksi dengan beberapa anggota lainnya, yang merupakan dimensi lain dari kompleksitas proyek perangkat lunak.
TANGGUNG JAWAB MANAJER PROYEK PERANGKAT LUNAK
Kompleksitas: Bahkan perangkat lunak berukuran sedang memiliki jutaan bagian (fungsi) yang berinteraksi satu sama lain dalam banyak cara—koneksi data, pemrosesan serial dan bersamaan, transisi status, ketergantungan kontrol, berbagi file, dll. Karena keunikan proyek perangkat lunak, seorang manajer proyek dalam pelaksanaan suatu proyek menghadapi banyak masalah yang sangat berbeda dengan masalah lain yang pernah ia temui di masa lalu. Fokus kegiatan pemantauan dan pengendalian proyek adalah untuk memastikan bahwa pengembangan perangkat lunak berjalan sesuai rencana.
Pengetahuan teoritis tentang berbagai teknik manajemen proyek sangat penting untuk menjadi manajer proyek yang sukses. Manajemen proyek perangkat lunak yang efektif memerlukan penilaian kualitatif dan keterampilan pengambilan keputusan yang baik. Selain memiliki pemahaman yang baik tentang teknik manajemen proyek perangkat lunak terbaru seperti estimasi biaya, manajemen risiko dan manajemen konfigurasi, dll., manajer proyek memerlukan keterampilan komunikasi yang baik dan kemampuan untuk menyelesaikan pekerjaan.
Setelah membahas secara singkat tanggung jawab umum seorang manajer proyek perangkat lunak dan keterampilan yang diperlukan untuk mencapainya, bagian selanjutnya membahas beberapa masalah perencanaan proyek yang penting.
PERENCANAAN PROYEK
Kita masih dapat mengklasifikasikan kegiatan-kegiatan ini secara luas ke dalam dua jenis utama – perencanaan proyek serta pemantauan dan pengendalian proyek. Saat melakukan aktivitas pemantauan dan pengendalian proyek, manajer proyek terkadang merasa perlu mengubah rencana untuk menangani situasi tertentu yang ada. Namun, pengetahuan teoretis murni tentang berbagai teknik manajemen proyek tidak akan menjadikan manajer proyek sukses.
Oleh karena itu, perencanaan proyek dilakukan oleh manajer proyek dengan sangat hati-hati dan penuh perhatian. Namun, untuk perencanaan proyek yang efektif, pengalaman sebelumnya serta pengetahuan menyeluruh tentang berbagai teknik estimasi sangatlah penting. Dengan mempertimbangkan perkembangan ini, manajer proyek dapat merencanakan aktivitas masa depan dengan lebih tepat dan dengan tingkat kepercayaan yang lebih tinggi.
Setelah perencanaan proyek selesai, manajer proyek mendokumentasikan rencana mereka dalam dokumen rencana manajemen proyek perangkat lunak (SPMP).
METRIK UNTUK ESTIMASI UKURAN PROYEK
Dari sudut pandang manajer proyek, kelemahan utama metrik LOC adalah total LOC sangat sulit diperkirakan selama tahap perencanaan proyek dan hanya dapat dihitung secara akurat setelah pengembangan perangkat lunak selesai. Keuntungan penting dari metrik titik fungsi dibandingkan metrik LOC adalah bahwa metrik tersebut dapat dengan mudah dihitung dari spesifikasi masalah itu sendiri. Ukuran produk perangkat lunak secara langsung bergantung pada jumlah fungsi berbeda atau tingkat tinggi yang didukungnya.
Secara konseptual, metrik titik fitur didasarkan pada gagasan bahwa produk perangkat lunak yang mendukung banyak fitur tentu akan lebih besar dibandingkan produk dengan fitur lebih sedikit. Hal ini diperhitungkan dengan metrik titik fungsi dengan menghitung jumlah item data masukan dan keluaran serta jumlah file yang diakses oleh fungsi tersebut. Oleh karena itu, kita dapat mengatakan bahwa menghitung jumlah item data masukan dan keluaran akan memberikan representasi ukuran kode yang lebih akurat dibandingkan dengan sekadar menghitung jumlah fungsi tingkat tinggi yang didukung oleh sistem.
Titik fungsi yang tidak disesuaikan (UFP) dihitung sebagai jumlah bobot lima karakteristik produk seperti yang ditunjukkan dalam ekspresi berikut.
- TEKNIK ESTIMASI PROYEK
- TEKNIK ESTIMASI EMPIRIS
- COMO—TEKNIK ESTIMASI HEURISTIS
- COCOMO 2
- ILMU PERANGKAT LUNAK HALSTEAD—TEKNIK ANALITIS
- ESTIMASI TINGKAT STAF
- PENJADWALAN
- ORGANISASI DAN STRUKTUR TIM
- STAF
- MANAJEMEN RISIKO
- MANAJEMEN KONFIGURASI PERANGKAT LUNAK
- RENCANA LAINNYA
- RINGKASAN
- LATIHAN
Ini dapat digunakan untuk memperkirakan biaya proyek dalam berbagai fase produk perangkat lunak. Organisasi perangkat lunak menugaskan tim pengembang yang berbeda untuk mengerjakan proyek perangkat lunak yang berbeda. Mengapa manajemen konfigurasi perangkat lunak penting bagi keberhasilan proyek pengembangan produk perangkat lunak yang besar (tuliskan alasan pentingnya saja).
ANALISIS KEBUTUHAN DAN SPESIFIKASI
PENGUMPULAN DAN ANALISIS PERSYARATAN
Pengumpulan persyaratan terbukti sangat menantang jika tidak ada model kerja untuk perangkat lunak yang sedang dikembangkan. Misalnya, berbagai kategori pengguna perangkat lunak otomasi perpustakaan mungkin adalah pustakawan, pustakawan, dan akuntan. Anggota perpustakaan ingin menggunakan perangkat lunak untuk menanyakan ketersediaan buku dan menerbitkan serta mengembalikan buku.
Pustakawan mungkin ingin menggunakan perangkat lunak untuk mengidentifikasi buku-buku yang sudah lewat jatuh tempo, membuat akun anggota, menghapus akun anggota, dll. Dalam konteks ini, analis mencoba mengidentifikasi dan memahami berbagai tugas yang harus dilakukan oleh perangkat lunak. Tujuan utama dari kegiatan analisis persyaratan adalah untuk menganalisis persyaratan yang dikumpulkan untuk menghilangkan semua ambiguitas, ketidaklengkapan dan inkonsistensi dari persyaratan pelanggan yang dikumpulkan dan untuk mendapatkan pemahaman yang jelas tentang perangkat lunak yang akan dikembangkan.
Contoh 4.6 Dalam perangkat lunak otomasi pabrik kimia, misalkan salah satu persyaratannya adalah jika suhu internal reaktor melebihi 200C, bel alarm harus dibunyikan.
SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK (SRS)
Memberikan dasar untuk validasi dan verifikasi: Dokumen SRS memberikan dasar yang dapat digunakan untuk memeriksa kesesuaian perangkat lunak yang dikembangkan. Oleh karena itu, dalam praktiknya, dokumen SRS mengalami beberapa kali revisi selama pengembangan perangkat lunak. Oleh karena itu, dokumen SRS disebut juga spesifikasi kotak hitam untuk perangkat lunak yang sedang dikembangkan.
Persyaratan non-fungsional adalah kewajiban yang tidak dapat dinegosiasikan yang harus didukung oleh perangkat lunak. Bagian 'tujuan implementasi' dari dokumen SRS memberikan beberapa saran umum mengenai perangkat lunak yang akan dikembangkan. Antarmuka Perangkat Keras: Bagian ini harus menjelaskan antarmuka antara komponen perangkat lunak dan perangkat keras sistem.
Software harus mampu menampilkan seluruh buku yang telah dipinjam dari berbagai teman atas permintaan pemiliknya.
Basis Data: Sistem manajemen basis data yang tersedia gratis di domain publik harus digunakan
- SPESIFIKASI SISTEM FORMAL
- SPESIFIKASI AXIOMATIS
- SPESIFIKASI ALJABAR
- SPESIFIKASI YANG DAPAT DILAKUKAN DAN 4GL
- RINGKASAN
- LATIHAN
Contoh 4.10 Perangkat lunak manajemen keanggotaan perpustakaan (LMS) perlu mendukung tiga opsi berikut - anggota baru, perpanjangan, dan pembatalan keanggotaan. Ketika opsi anggota baru dipilih, perangkat lunak harus meminta nama, alamat, dan nomor telepon anggota. 34;Perangkat lunak harus menyediakan kemampuan untuk mengimpor gambar yang ada, tersedia sebagai file jpeg, ke dalam dokumen yang sedang dibuat." Yang mana dari jenis persyaratan berikut.
Diskusikan aspek produk perangkat lunak yang ingin Anda dokumentasikan dalam dokumen spesifikasi kebutuhan perangkat lunak (SRS). Misalkan Anda mencoba mengumpulkan persyaratan perangkat lunak yang akan dikembangkan untuk mengotomatisasi aktivitas pembukuan supermarket. Perangkat lunak jam kosmopolitan akan dikembangkan menampilkan hingga 6 jam dengan nama kota dan waktu setempat.
Misalkan Anda ingin mengembangkan perangkat lunak pengolah kata yang memiliki fitur mirip dengan Microsoft Word.
DESAIN SOFTRWARE
- TINJAUAN PROSES DESAIN
- BAGAIMANA KARAKTERISASI DESAIN PERANGKAT LUNAK YANG BAIK?
- KOHESI DAN COUPLING
- PENYUSUNAN MODUL BERLAPIS
- PENDEKATAN UNTUK DESAIN PERANGKAT LUNAK
- RINGKASAN
- LATIHAN
Sekalipun mereka menggunakan metodologi desain yang sama, desainer yang berbeda biasanya menghasilkan solusi desain yang sangat berbeda. Namun, pertanyaan mendasar yang muncul saat ini adalah: bagaimana Anda membedakan solusi desain yang superior dan solusi desain yang inferior? Kecuali kita mengetahui apa itu desain perangkat lunak yang baik dan bagaimana membedakan solusi desain yang unggul dan yang lebih rendah, kita tidak mungkin merancangnya.
Efisiensi: Solusi desain yang baik harus mengatasi masalah optimalisasi sumber daya, waktu dan biaya secara memadai. Kita sekarang dapat mendefinisikan karakteristik desain yang dapat dipahami sebagai berikut: Solusi desain dapat dipahami, jika bersifat modular dan modul-modulnya disusun dalam lapisan yang berbeda. Dapat dengan mudah dilihat bahwa solusi desain pada Gambar 5.2(a) akan lebih mudah dipahami karena interaksi antar modul yang berbeda rendah.
Suatu solusi desain dikatakan sangat modular jika modul-modul yang berbeda dalam solusi tersebut memiliki koherensi yang tinggi dan konektivitas antar modul yang rendah.
