Peningkatan Kualitas Kebutuhan Perangkat Lunak menggunakan Metode Refactoring disesuaikan dengan Matrix SQuaRE

Transkripsi

1 Peningkatan Kualitas Kebutuhan Perangkat Lunak menggunakan Metode Refactoring disesuaikan dengan Matrix SQuaRE Presented By : Artha Patra Pradana ( ) Jurusan Sistem Informasi Fakultas Teknologi Informasi Institut Teknologi Sepuluh Nopember Surabaya 2013

2 Outline

3 Pendahuluan Latar Belakang Perumusan Masalah Batasan Masalah Tujuan Tugas Akhir Relevansi atau manfaat tugas akhir

4 Latar Belakang

5 Perumusan Masalah Sejauh mana kualitas kebutuhan perangkat lunak aplikasi SSN sebelum dilakukan refactoring? Bagaimana melakukan Refactoring pada tahap requirements studi kasus aplikasi SSN (School Social Network)? Sejauh mana kualitas kebutuhan perangkat lunak SSN (School Social Network) setelah dilakukan refactoring?

6 Batasan Masalah Metode Refactoring ini hanya digunakan pada tahap Requirements terutama bagian use case scenario Dokumen kebutuhan perangkat lunak yang digunakan adalah dokumen pengembangan aplikasi SSN (School Social Network) Kriteria kualitas yang digunakan ada 4 diantaranya Completeness, Correctness, Consistency dan Non-Ambiguity.

7 Tujuan Tugas Akhir Meningkatkan kualitas kebutuhan perangkat lunak SSN dengan menggunakan teknik refactoring Membandingkan kondisi kualitas kebutuhan saat ini dengan kualitas kebutuhan setelah dilakukan refactoring dengan melihat hasil pengukuran kualitas kebutuhan perangkat lunak SSN

8 Relevansi atau Manfaat Tugas Akhir Memberikan pemahaman lebih detail terhadap aspek-aspek teknis yang ada pada tahap kebutuhan pengembangan Aplikasi SSN Mempermudah tim pengembang desain untuk mengembangkan aplikasi SSN ini kedepannya karena informasi tentang kebutuhan system yang lebih jelas dan lebih detail. Memberikan saran dan alternative kepada tim pengembang untuk pengembangan aplikasi SSN kedepannya.

9 Tinjauan Pustaka SDLC (Software Development Life Cycle) Software Quality Requirement Analysis Use Case Software Requirement Problems Metode Meningkatkan Kualitas Kebutuhan Pengukuran Kualitas Kebutuhan Perangkat Lunak

10 Software Development Life Cycle SDLC adalah serangkaian aktivitas terstruktur pada proses pengembangan perangkat lunak. Aktivitas ini terdiri dari beberapa tahapan-tahapan penting dalam keberadaan perangkat lunak dilihat dari aspek pengembangannya Tahapnya berupa Planning, Implementation, Testing and Documenting, Deployment and Maintenance Ada beberapa model pengembangan perangkat lunak diantaranya adalah Waterfall model, Spiral model, Iterative model, Agile development, Rapid application development

11 Software Development Life Cycle (cont d) Proses disamping merupakan salah satu proses yang ada pada SDLC (Waterfall Model) Tahap Requirement menjadi fokus dalam pengerjaan studi kasus tugas akhir Gambar 1. Waterfall Model

12 Software Quality Software dikatakan berkualitas apabila sesuai dengan kebutuhan yang telah ditentukan. Software quality mengacu pada kesesuaian antara perangkat lunak yang dibangun dengan spesifikasi dan kebutuhan yang telah ditentukan oleh pengguna dan para professional

13 Software Quality (cont d) Penyebab buruknya kualitas sebuah perangkat lunak diantaranya : 1) Faulty definition of requirements 2) Client-developer communication failures 3) Deliberate deviantions from software requirements 4) Logical design error 5) Coding error 6) Non compliance with documentation and coding instruction 7) Documentation error

14 Requirment Analysis Mendapatkan dan mengidentifikasi kebutuhan perangkat lunak yang akan dibangun dan kondisi-kondisi yang harus dipenuhi selama pengembangan perangkat lunak Ada 3 aktivitas utama diantaranya adalah Eliciting Requirements, Analyzing Requirements, Recording Requirements 1) Eliciting Requirements Mengidentifikasi kebutuhan perangkat lunak 2) Analyzing Requirements Memastikan kebutuhan perangkat lunak sudah jelas 3) Recording Requirements Mendokumentasikan aktivitas sebelumnya

15 Use Case Gambar 2. Use Case Diagram Use case menggambarkan interaksi antara actor dengan sistem yang saling berhubungan diantara keduanya. Use case merupakan bagian dari use case diagram. Use case diagram sangat penting dalam menjelaskan apa yang dilakukan oleh sebuah system yang kemudian dispesifikasikan cara kerjanya oleh Flow of Event.

16 Software Requirements Problem Poor Requirement Quality Over emphasis on simplistic use case modelling Inappropriate Constraints Missing Requirements Requirements no trace

17 Metode Peningkatan Kualitas Kebutuhan Perangkat Lunak Requirement Management Plan Quality Modeling based Requirements Engineering Framework Refactoring

18 Metode Peningkatan Kualitas Kebutuhan Perangkat Lunak Gambar 1. Traceability Relationship antar Kebutuhan perangkat lunak Requirement Managemnet Plan metode ini tepat digunakan untuk mendokumentasi segala proses identifikasi kebutuhan perangkat lunak dan mengajak seluruh partisipan untuk ikut dalam perencanaan yang akan dibuat Tipe Kebutuhan perangkat lunak yang akan dibangun Atribut kebutuhan perangkat lunak Struktur folder untuk menyimpan kebutuhan perangkat lunak Memberikan role dan hak akses

19 Metode Peningkatan Kualitas Kebutuhan Perangkat Lunak Gambar 3. Salah satu contoh quality modelling untuk promptly available Quality Modelling based Requirement Engineering Framework satu teknik yang berfokus pada identifikasi, analisis, serta formalisasi dari sebuah kebutuhan yang didalamnya terdapat informasi yang mampu mengakomodasi kebutuhan perusahaan secara spesifik Hal yang melatarbelakangi metode REF ini adalah teknik ini menggabungkan mekanisme permodelan sebuah organisasi dengan mekanisme pada teknik quality modelling

20 Refactoring Refactoring adalah suatu teknik untuk melakukan restrukturisasi kode pemrograman tanpa mengubah fungsionalitas dari pemrograman itu sendiri. Tujuan dari refactoring adalah untuk meningkatkan pemahaman dari kode pemrograman yang ditulis dan mengurangi kompleksitas yang berdampak pada peningkatan maintainability dari kode pemrograman itu sendiri Ada 2 keuntungan yang didapatkan dari penggunaan metode refactoring yaitu : Maintainability Refactoring akan membuat kode pemrograman lebih mudah dipahami terutama pada saat melakukan perbaikan terhadap bug yang ditemukan dalam perangkat lunak. Extensibility Refactoring akan mempermudah melakukan extend terhadap kapabilitas dari suatu perangkat lunak.

21 Refactoring (cont d) Untuk melakukan refactoring ada 5 cara yang bisa dilakukan, diantaranya : Extract Requirements Rename Requirements Move Activity Inline Requirement Exctract Alternative Flows

22 Exctract Requirements Refactoring (Cont d)

23 Extract Requirements (Cont d) Refactoring (cont d)

24 Move Actvity Refactoring (cont d)

25 Inline Requirements Refactoring (cont d)

26 Extract Alternative Flows Refactoring (cont d)

27 Pengukur Kualitas Kebutuhan Perangkat Lunak Establish Evaluation Requirements Fase ini terdiri dari 3 tahapan, pertama yaitu menetapkan tujuan dari melakukan pengukuran kualitas kebutuhan perangkat lunak. Kedua menentukan produk / perangkat lunak yang akan diukur dan ketiga menentukan model kualitas. Output dari fase ini adalah sebuah kebutuhan perangkat lunak yang digunakan untuk pengukuran kebutuhan perangkat lunak.

28 Pengukuran Kualitas Kebutuhan Perangkat Lunak (cont d) Specification of the Evaluation Fase ini terdiri dari pemilihan matriks untuk pengukuran kualitas kebutuhan perangkat lunak, lalu menetapkan rating level untuk metrics serta menentukan kriteria kriteria berdasarkan model kualitas untuk melakukan pengukuran dan dibandingkan dengan produk saat ini. Output dari fase ini adalah sebuah matriks, rating level, dan kriteria matriks untuk pengukuran kebutuhan perangkat lunak yang diambil dari model kualitas. Design of the evaluation Berisi tentang perencanaan pengukuran secara menyeluruh seperti tools yang akan dipakai, jadwal pengukuran, dan sebagainya

29 Pengukuran Kualitas Kebutuhan Perangkat Lunak (cont d) Execution of the Evaluation Fase ini merupakan fase final dari keseluruhan fase metrics, yaitu terdiri dari menguruk karakteristik produk, lalu pembandingan produk dengan kriteria yang sudah ada pada fase Specification of the evaluation. Terakhir adalah menilai hasil akhir dari proses evaluasi tersebut.

30 Metodologi Tugas Akhir

31 Metodologi Tugas Akhir

32 Metodologi Tugas Akhir (cont d)

33 Hasil dan Pembahasan Pengukuran Kualitas Use Case Scenario

34 Hasil dan Pembahasan (cont d) Peerhitungan menggunakan rumus

35 Hasil dan Pembahasan (cont d) Proses Refactoring

36 Hasil dan Pembahasan (cont d) Proses Refactoring BEFORE AFTER

37 Hasil dan Pembahasan (cont d) BEFORE AFTER

41 Hasil dan Pembahasan (cont d) Proses Pengukuran

42 Hasil dan Pembahasan (cont d) Proses Perhitungan menggunakan Rumus

43 Hasil dan Pembahasan (cont d) Hasil perbandingan kualitas use case scenario sebelum dan sesudah refactoring

44 Kesimpulan dan Saran Kesimpulan Simpulan yang dapat diambil dari pengerjaan tugas akhir ini adalah sebagai berikut : Perbaikan menggunakan refactoring sangat tepat digunakan pada use case scenario kebutuhan perangkat lunak karena langsung berfokus pada fungsional dari suatu aplikasi sehingga mampu membuat sebuah use case scenario menjadi lebih mudah dipahami Perbaikan menggunakan refactoring bukan merupakan satu-satunya cara untuk melakukan perbaikan terhadap use case scenario, akan tetapi dapat digunakan sebagai metode yang tepat membuat sebuah use case scenario menjadi lebih mudah dipahami dan dimengerti. Pengukuran kualitas menggunakan Metrics SQuaRE sangat membantu dalam mengetahui sejauh mana kualitas dari sebuah kebutuhan perangkat lunak. Saran Saran yang diharapkan dapat dikembangkan di masa mendatang adalah: Sebaiknya kualitas dalam pembuatan use case skenario perlu diperhatikan lagi karena masih banyak terdapat beberapa use case skenario yang tidak sesuai dengan kondisi sistem yang ada sehingga akan menyebabkan kesulitan dalam pengembangan aplikasi SSN selanjutnya.

45 Daftar Pustaka [1] Gallin, Daniel. Software Quality Assurance from Theory to Implementation. Edinburgh Gate : Pearson Education, [2] Improving The Quality of Requirements with Refactoring. Ramos, Ricardo, et al., et al [3] Common Requirements Problems, Their NegativeConsequences, and the Industry Best Practices to Help Solve Them. Firesmith, Donald. s.l. : ETH Zurich, 2007, Vol. 6. [4] Kerievsky, Joshua. Refactoring to Patterns. s.l. : Addison Wesley, [5] Lyytinen, Kalle, et al., et al. Design Requirement Engineering: A Ten-Year Perspective. Ohaio : Springer, [6] Chapter 2 : Software Requirements Guide to the software engineering body of knowledge. Abran, Alain, et al., et al. s.l. : IEEE Computer Science Press, [7] Writing Effective Use Case. Cockburn, Alistair. s.l. : Addison-Wesley, [8] Managing Requirements & Improving Quality. Roy, Shambavi. s.l. : TraceCloud, [9] Improving Requirements Engineering by Quality Modelling - A Quality-Based Requirements Engineering Framework. Donzelli, Paolo and Bresciani, Paolo [10] Suryn, Witold and Abran, Alain ISO/IEC SQuaRE. The second generation of standards for software product quality. [11] Essado, Marcelo and Ambrosio, Ana Maria. A Requirement Metric Applied on the ITASAT-1:A Small Technological Sattelite. [12] Software Engineering. Sommerville, I. s.l. : Pearson Education, [13] Use Cases and Aspects - Working Seamlessly Together. Jacobson, Ivar. Zurich : ETH Zurich, [14] The Three Cs of Requirements: Correctness, Completeness,Consistency.Zowghi D., Gervasi V. s1. : University of Technology, Sidney. 2009