Impact Analysis

Abstrak Perubahan Software yang diperlukan dan tak terelakkan dalam pengembangan perangkat lunak, tetapi dapat mengakibatkan kerusakan perangkat lunak jika tidak dikontrol dengan baik. Analisis dampak adalah kegiatan mengidentifikasi apa yang perlu diubah untuk membuat perubahan, atau untuk menentukan konsekuensi pada sistem jika perubahan tersebut diterapkan. Kebanyakan penelitian tentang analisis dampak disajikan dan dibahas dalam literatur berhubungan dengan pemeliharaan software. Dalam bab ini, kami mengambil pendekatan yang berbeda dan membahas analisis dampak dari perspektif rekayasa persyaratan. Kami berhubungan perubahan perangkat lunak untuk analisis dampak, menguraikan sejarah analisis dampak dan sekarang strategi umum untuk melakukan analisis dampak. Kami juga menyebutkan aplikasi analisis dampak persyaratan non-fungsional dan membahas dukungan alat untuk analisis dampak. Akhirnya, kami menguraikan apa yang kita lihat sebagai masa depan alat manajemen perubahan penting ini.

Introduction Hal ini secara luas diakui bahwa perubahan adalah properti tak terhindarkan dari perangkat lunak apapun, untuk sejumlah alasan. Namun, perubahan perangkat lunak dapat, dan akan, jika tidak benar terkontrol, menyebabkan kerusakan software. Misalnya, ketika Mozilla 2.000.000 Source Line Of Code (SLOC) dianalisis, ada indikasi kuat bahwa software telah memburuk secara signifikan karena perubahan yang tidak terkendali, membuat software sangat sulit untuk mempertahankan [17].

Ini diungkapan pada Gambar. 6. 1 Ini diungkapan pada Gambar. 6.1. Perhatikan bahwa dalam proses pembangunan kurang idealis, situasi masih memegang; perubahan persyaratan mempengaruhi semua representasi sistem yang ada. Gambar. 6.1 Software life-cycle objects (SLOs) yang terkena dampak (kanan) akibat perubahan persyaratan dalam fase yang berbeda (kiri)

6.1.1 Konsep dan Persyaratan Pada bagian ini, kita secara singkat mengunjungi istilah dan konsep tersebut, dan menjelaskan bagaimana masing-masing berhubungan dengan dampak analisis dan istilah dan konsep lainnya. Software life-cycle objects (SLOs) juga disebut produk perangkat lunak, atau produk kerja) sangat penting untuk analisis dampak. Sebuah SLOs adalah hasilkan selama proyek, seperti persyaratan, komponen arsitektur, kelas dan sebagainya. Analisis dampak sering dilakukan dengan menganalisis hubungan berbagai entitas dalam sistem. Kami membedakan antara dua jenis analisis: analisis dependensi dan analisis traceability [3]. Dalam analisis ketergantungan, rinci hubungan antara entitas Program, misalnya variabel atau fungsi, yang diekstrak dari kode sumber. Analisis traceability (penelusuran), di sisi lain, adalah analisis hubungan yang telah diidentifikasi selama pengembangan antara semua jenis SLOs. Analisis traceability demikian cocok untuk menganalisis hubungan antara persyaratan, komponen arsitektur, dokumentasi dan sebagainya. Persyaratan traceability didefinisikan dan dibahas dalam Bab. 5.

Hal ini umum untuk menangani set dampak dalam analisis dampak Hal ini umum untuk menangani set dampak dalam analisis dampak. Set berikut telah didefinisikan oleh Arnold dan Bohner [3]: Sistem Set merupakan himpunan semua SLOS dalam sistem - semua set lain adalah himpunan bagian dari himpunan ini. Starting Impact Set (SIS) merupakan himpunan objek-objek yang pada awalnya dianggap berubah. SIS biasanya berfungsi sebagai masukan untuk mempengaruhi pendekatan analisis yang digunakan untuk menemukan Perkiraan Dampak Set. Estimated Impact Set (EIS) selalu meliputi SIS dan karena itu dapat dilihat sebagai perluasan dari SIS. Hasil pengembangan dari aplikasi mengubah aturan penyebaran dengan model objek internal berulang kali sampai semua obyek yang mungkin akan terpengaruh ditemukan. Idealnya, SIS dan EIS harus sama, yang berarti bahwa dampak terbatas pada apa yang awalnya dianggap berubah. Actual Impact Set (AIS), akhirnya, berisi yang SLOS yang telah terpengaruh setelah perubahan telah diimplementasikan. Dalam skenario kasus terbaik, yang AIS dan EIS adalah sama, yang berarti bahwa estimasi dampak yang sempurna.

6.1.2 Software Change and Impact Analysis Perubahan Software terjadi karena beberapa alasan, misalnya, dalam rangka untuk memperbaiki kesalahan, untuk menambahkan fitur baru atau untuk merestrukturisasi perangkat lunak untuk mengakomodasi perubahan masa depan [28]. Perubahan kebutuhan adalah salah satu motivasi yang paling signifikan untuk perubahan perangkat lunak. Persyaratan berubah dari titik waktu ketika mereka menimbulkan sampai sistem telah dianggap usang. Perubahan persyaratan mencerminkan bagaimana sistem harus berubah agar tetap berguna bagi pengguna dan tetap kompetitif di pasar. Pada saat yang sama, perubahan tersebut menimbulkan risiko besar karena mereka dapat menyebabkan kerusakan perangkat lunak. Dengan demikian, perubahan persyaratan harus ditangkap, dikelola dan dikendalikan dengan hati-hati untuk menjamin kelangsungan hidup sistem dari segi teknis. Faktor-faktor yang dapat menimbulkan perubahan persyaratan selama kedua pengembangan awal serta dalam evolusi perangkat lunak, menurut Leffingwell dan Widrig [23]:

Masalah bahwa sistem seharusnya untuk menyelesaikan perubahan, misalnya karena alasan ekonomi, politik atau teknologi. Para pengguna mengubah pikiran mereka tentang apa yang mereka ingin sistem untuk melakukan, karena mereka memahami kebutuhan mereka dengan lebih baik. Hal ini dapat terjadi karena pengguna awalnya adalah pasti tentang apa yang mereka inginkan, atau karena pengguna baru masukkan gambar. Lingkungan di mana sistem berada perubahan. Sebagai contoh, kenaikan dalam kecepatan dan kapasitas komputer dapat mempengaruhi harapan sistem. Sistem baru ini dikembangkan dan dirilis pengguna terkemuka untuk menemukan persyaratan baru.

Gambar. 6.2, membentuk kerangka kerja untuk proses manajemen perubahan yang memungkinkan tim proyek untuk mengelola perubahan dengan cara yang terkontrol. Plan for change melibatkan mengakui fakta bahwa perubahan terjadi, dan bahwa mereka adalah bagian penting dari pengembangan sistem. Persiapan ini sangat penting untuk perubahan yang akan diterima dan ditangani secara efektif. Baseline requirements berarti untuk membuat gambaran dari set saat persyaratan. Titik dari langkah ini adalah untuk memungkinkan perubahan berikutnya dalam persyaratan dapat dibandingkan dengan stabil, yang dikenal set persyaratan.

A single channel diperlukan untuk memastikan bahwa tidak ada perubahan diimplementasikan dalam sistem sebelum telah diteliti oleh seseorang, atau beberapa orang, yang menjaga sistem, proyek dan anggaran diketahui. Dalam organisasi yang lebih besar, saluran tunggal sering change control board (CCB). A change control system allows the CCB (atau setara) untuk mengumpulkan, melacak dan menilai dampak dari perubahan. Menurut Leffingwell dan Widrig, perubahan harus dinilai dalam hal dampak biaya dan fungsi, dampak pada stakeholder eksternal (misalnya, pelanggan) dan potensi untuk mengacaukan sistem. Jika yang terakhir diabaikan, sistem (seperti telah disebutkan sebelumnya) cenderung akan memburuk. To manage hierarchically menyalahkan baris perintah mungkin terlalu umum tindakan: perubahan diperkenalkan dalam code oleh programmer yang ambisius, yang lupa, atau menghadap, efek potensial perubahan telah di uji kasus, desain, arsitektur, persyaratan dan sebagainya. Perubahan harus diperkenalkan top-down, dimulai dengan persyaratan. Jika persyaratan yang terdekomposisi dan terkait dengan lainnya SLOs, adalah mungkin untuk menyebarkan perubahan dengan cara yang terkontrol.

Kerangka kerja ini untuk proses perubahan memulai membuka penentuan suatu proses perubahan yang sebenarnya. Proses yang diusulkan oleh Kotonya dan Sommerville, bagaimanapun, rinci dan terdiri dari langkah-langkah berikut [20]: Analisis Masalah dan perubahan spesifikasi Ubah analisis dan biaya, yang pada gilirannya terdiri dari: Periksa perubahan validitas permintaan Temukan persyaratan terkena dampak langsung Temukan persyaratan tergantung Mengusulkan perubahan persyaratan Menilai biaya perubahan Menilai biaya penerimaan Ubah implementasi