ANALISIS KETERKAITAN ANTARA VOLATILITAS KEBUTUHAN PERANGKAT LUNAK DENGAN STABILITAS RANCANGAN PERANGKAT LUNAK BERBASIS OBJEK

HANDANI, FELIX (2017) ANALISIS KETERKAITAN ANTARA VOLATILITAS KEBUTUHAN PERANGKAT LUNAK DENGAN STABILITAS RANCANGAN PERANGKAT LUNAK BERBASIS OBJEK. Masters thesis, Institut Teknologi Sepuluh Nopember.

[img]
Preview
Text
5114201041-Master_Theses.pdf - Published Version

Download (2MB) | Preview

Abstract

Arsitektur perangkat lunak adalah struktur inti dari sebuah perangkat lunak. Arsitektur perangkat lunak mencerminkan fungsi dan tujuan latar belakang dari perangkat lunak yang dibangun. Pada faktanya perangkat lunak selalu mengalami evolusi dari waktu ke waktu. Evolusi ini disebabkan berbagai hal seperti perkembangan teknologi dan perubahan kebutuhan penggunanya. Perubahan kebutuhan pengguna merupakan faktor utama terjadinya evolusi. Dalam menyikapi evolusi, beberapa peneliti mengungkapkan rancangan perangkat lunak yang baik memiliki kecenderungan stabil terhadap perubahan minor agar menghindari terjadinya erosi perangkat lunak. Erosi menyebabkan munculnya kerusakan komponen akibat salah perubahan kode sumber yang seharusnya tidak diubah, dan pelanggaran keputusan rancangan dari komponen yang telah direncanakan pada awalnya. Hal ini menyebabkan kecacatan yang akan muncul pada kemudian hari. Penelitian ini menjabarkan analisis mendalam tentang hubungan stabilitas arsitektur perangkat lunak dengan volatilitas kebutuhan perangkat lunak. Stabilitas rancangan perangkat lunak diukur berdasarkan tingkat penggunaan kembali komponen seperti Kelas Diagram, Paket Diagram dan Relasi antar kelas. Pengukuran dilakukan dengan memperhatikan perubahan jumlah kelas dalam satu paket dan jumlah relasi antar atau dalam paket. Pengukuran volatilitas kebutuhan dilakukan dengan memperhatikan perubahan fitur pada setiap versi. Dari dua pengukuran tersebut, peneliti mengamati perkembangan fenomena yang terjadi di dalamnya. Terdapat tiga kondisi yang membuat ketidakstabilan rancangan perangkat lunak. Pertama, penambahan fitur perangkat lunak yang tidak terdefinisi pada awal, sehingga pada versi sebelumnya komponen perangkat lunak tidak dapat dirancangan terlebih dahulu. Hal ini dapat melebarkan lingkup perangkat lunak itu sendiri dan memungkinkan adanya degradasi pada komponen tertentu. Hal ini terlihat pada kasus AB2-3, AB3-4, AB6-7, AB7-8, AB9-10, NS1-2, dan NS2-3. Namun apabila rancangan sudah dibentuk pola perancangan yang lebih general, maka nilai stabilitas rancangan akan lebih tinggi dibanding dengan rancangan yang tidak memiliki pola perancangan. Faktor kedua adalah pengubahan fitur yang berdampak pada pelebaran lingkup perangkat lunak. Hal ini tercermin pada kasus AB¬2-3, dan NS3-4. Faktor terakhir adalah penghapusan fitur inti yang dimiliki oleh lebih dari 50% fitur dari seluruh versi yang ada. Hal ini tercermin pada kasus AB3-4, dan NS2-3. ========================================================== Software architecture is the core structure of a software. Software architecture reflects functional background and purpose of the software is built. In fact the software is always evolving from time to time. This evolution is due to various things such as technological development and the needs for minor changes. The user need afford a change is a major factor in the evolution. In addressing the evolution, some researchers revealed that architectural and component design good software has a stable trend towards minor changes in order to avoid erosion of the software. Erosion caused the emergence of elemental damage as a result of changes to the source code that should not be changed, and violations of the architectural design decisions that had been initially planned. It causes disability that will appear at a later date. In this study, I conducted a thorough analysis on relationship between the software component stability and volatility of the software requirements. The stability of the software component is measured according to a study presented by Aversano and Constantinou. Component measurement done by considering the number of classes in one package and the number of relationships among or within the package. Volatility measurements conducted with respect to the needs of the changing needs of each version. From the two measures, the researcher observes the development of phenomena that occur in it. There are three conditions that create instability software design. First, the addition of software features that are not defined at the beginning, so that the previous version of the software component can’t be designed first. It can widen the scope of the software itself and allows the degradation of certain components. This is seen in the case of AB2-3, AB3-4, AB6-7, AB7-8, AB9-10, NS1-2, and NS2-3. However, if the software component is already established design patterns that are more general, then the value of the stability of the design will be higher than with a design that does not have a pattern design. The second factor is the conversion feature that impact on widening the scope of the software. This is reflected in the case AB2-3, and NS3-4. The last factor is the elimination of the core features that are owned by more than 50% of the features of the entire existing version. This is reflected in the case AB¬, and NS2-3.

Item Type: Thesis (Masters)
Uncontrolled Keywords: Analysis, Measurement of the stability of the software component, Reuseability, Statistical analysis, Volatility software requirement
Subjects: Q Science > QA Mathematics > QA76 Computer software
T Technology > T Technology (General)
Divisions: Faculty of Information Technology > Informatics Engineering > (S2) Master Theses
Depositing User: FELIX HANDANI -
Date Deposited: 27 Feb 2017 02:56
Last Modified: 05 Mar 2019 03:56
URI: http://repository.its.ac.id/id/eprint/1627

Actions (login required)

View Item View Item