• Tidak ada hasil yang ditemukan

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

N/A
N/A
Protected

Academic year: 2021

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

Copied!
45
0
0

Teks penuh

(1)Peningkatan Kualitas Kebutuhan Perangkat Lunak menggunakan Metode Refactoring disesuaikan dengan Matrix SQuaRE Presented By : Artha Patra Pradana (5209100023) 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. 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. Gambar 1. Traceability Relationship antar Kebutuhan perangkat lunak.

(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) Refactoring (Cont’d). • Exctract Requirements.

(23) Refactoring (cont’d). • Extract Requirements (Cont’d).

(24) • Move Actvity. Refactoring (cont’d).

(25) Refactoring (cont’d). • Inline Requirements.

(26) Refactoring (cont’d). • Extract Alternative Flows.

(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.

(38) Hasil dan Pembahasan (cont’d). • Proses Refactoring.

(39) Hasil dan Pembahasan (cont’d) • Proses Refactoring.

(40) Hasil dan Pembahasan (cont’d) • Proses Refactoring.

(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, 2004. • [2] Improving The Quality of Requirements with Refactoring. Ramos, Ricardo, et al., et al. 2009. • [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, 2005. • [5] Lyytinen, Kalle, et al., et al. Design Requirement Engineering: A Ten-Year Perspective. Ohaio : Springer, 2009. • [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, 2007. • [7] Writing Effective Use Case. Cockburn, Alistair. s.l. : Addison-Wesley, 2001. • [8] Managing Requirements & Improving Quality. Roy, Shambavi. s.l. : TraceCloud, 2009. • [9] Improving Requirements Engineering by Quality Modelling - A Quality-Based Requirements Engineering Framework. Donzelli, Paolo and Bresciani, Paolo. 2009. • [10] Suryn, Witold and Abran, Alain. 2003. 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, 2004. • [13] Use Cases and Aspects - Working Seamlessly Together. Jacobson, Ivar. Zurich : ETH Zurich, 2003. • [14] The Three Cs of Requirements: Correctness, Completeness,Consistency.Zowghi D., Gervasi V. s1. : University of Technology, Sidney. 2009.

(46)

Gambar

Gambar 1. Waterfall Model
Gambar 2. Use Case Diagram
Gambar 1. Traceability Relationship antar   Kebutuhan perangkat lunak

Referensi

Dokumen terkait

Menurut penelitian yang telah dilakukan peneliti di atas kapal MT.Green Global, ada berbagai faktor di dalam mesin induk yang dapat mengakibatkan terbakarnya stuffing

Panduan pemantapan Kemampuan Mengajar (PKM) dan Pemantapan Kemampuan Profesional (PKP), Kit Praktek dan Panduan Tugas Akhir. Bahan ajar yang disusun dengan benar dapat

Tutkimuksen pääkysymykseen haetaan vastausta seuraavien alaky- symysten avulla: millaista oli panssarivaunukoulutus Suomessa ennen jatkosotaa, mitkä teki- jät vaikuttivat

Flora transien pada tangan diperoleh melalui kontak dengan pasien ,petugas lain,atau permukaan lingkungan (meja,tensi,stetoskop atau toilet),organisme ini

Berdasarkan hasil penelitian yang peneliti lakukan, dewasa madya menunda pernikahan, dia ingin mempunyai calon suami berpendidikan yang lebih tinggi darinya, wanita

contingent asset (aset kontijensi) adalah aset yang mungkin timbul dari waktu lampau dan akan terjadi atau tidak akan terjadi tergantung pada kejadian yang akan terjadi pada masa

Ukuran uji (UU) atau ukuran kontrol, diukur dari tengah muka di bawah ban petar serong melalui puncak buah dada ke pencah lengan terus serong ke belakang sampai

Tetilik puniki madue tetujon nelatarang indik (1) film dokumenter pinaka serana nincapang kawagedan nyurat puisi Bali anyar sisia kelas X7 SMA Negeri 2 Banjar, (2)