Bab tinjauan pustaka rekayasa Perangkat Lunak

BAB 2
TINJAUAN PUSTAKA
2.1 Rekayasa Perangkat Lunak

Rekayasa perangkat lunak adalah pembuatan perangkat lunak yang mencakup proses pembuatan, metode yang digunakan dan alat-alat yang digunakan untuk membangun sebuah perangkat lunak dengan kualitas yang baik (Roger S. Pressman & Bruce R. Maxim, 2015:14-19). Dalam pengembangannya harus memperhatikan para pekerja agar dalam membangun perangkat lunak komputer dapat menyesuaikan pendekatan yang cocok untuk mereka dengan cara yang sesuai dengan kebutuhan.

2.1.1 Defining The Discipline

Software engineering adalah teknologi berlapis. Teknologi lapisan pada software engineering adalah sebagai berikut:

Gambar 2. Lapisan Software Engineering

1. 
   A quality focus
   

Landasan yang mendukung rekayasa perangkat lunak. Pendekatan rekayasa apa pun harus berkomitmen pada organisasi untuk kualitas.

2. 
   Process
   

Dasar dari rekayasa perangkat lunak. Proses rekayasa perangkat lunak adalah sebagai pelekat yang memegang lapisan teknologi tetap bersama dan memungkinkan pengembangan rasional dan waktu perangkat lunak komputer.

3. 
   Methods
   

Memberikan cara teknis bagaimana cara membangun software. Metode mencakup banyak hal seperti communication, requirement analysis, design modeling, program construction, testing dan support.

4. 
   Tools
   

Memberikan dukungan secara otomatis ataupun semi otomatis untuk process dan methods. Ketika tools terintegrasi sehingga informasi yang diciptakan oleh satu alat dapat digunakan oleh yang lain, sistem yang mendukung pengembangan perangkat lunak, yang disebut computer-aided software engineering, sudah didirikan.
2.1.2 The Software Process

Proses software dibagi menjadi 3, yaitu :

1. 
   The Process Framework
   

Kerangka proses mencakup rangkaian umbrella activities yang berlaku di seluruh proses perangkat lunak (Roger S. Pressman & Bruce R. Maxim, 2015:14-19). Kerangka proses generik untuk rekayasa perangkat lunak meliputi lima kegiatan, yaitu:

1. 
   Communication, sebelum melakukan kerja teknis, lebih baik membicarakan dan membahasnya dengan pelanggan.
   
2. 
   Planning, setiap perjalanan yang rumit dapat disederhanakan jika direncanakan.
   
3. 
   Modeling, apakah seorang penata taman, seorang insinyur penerbangan, tukang kayu, pembangun jembatan atau seorang arsitek, harus bekerja dengan model setiap hari.
   
4. 
   Construction, apa yang Anda desain harus Anda bangun.
   
5. 
   Deployment, software tersebut dikirim ke pengguna dan pengguna tersebut mengevaluasi produk tersebut dan pengguna memberikan feedback berdasarkan yang mereka evaluasi.
   

2. 
   Umbrella Activities
   

Pada umumnya, kegiatan umbrella avtivities diterapkan di seluruh proyek perangkat lunak dan membantu software team dalam mengelola dan mengendalikan kemajuan, kualitas, perubahan dan resiko (Roger S. Pressman & Bruce R. Maxim, 2015:14-19). Ciri khas umbrella activities adalah:

1. 
   Software project tracking and control, mengizinkan software team untuk menilai perkembangan terhadap resiko dari rencana proyek dan mengambil tindakan apa saja yang perlu di lakukan untuk menjaga jadwal yang sudah di rencanakan.
   
2. 
   Risk management, menilai resiko yang mungkin berpengaruh pada hasil dari proyek atau kualitas dari produk
   
3. 
   Software quality assurance, mendefinisikan dan melakukan kegiatan yang diperlukan untuk memastikan kualitas software.
   
4. 
   Technical review, menilai produk kerja rekayasa perangkat lunak dalam upaya untuk mengungkapkan dan menghapus kesalahan sebelum dilanjutkan ke aktivitas selanjutnya.
   
5. 
   Measurement, mendefinisikan dan mengumpulkan langkah-langkah proses, proyek dan produk membantu tim dalam memberikan software yang memenuhi kebutuhan stakeholder.
   
6. 
   Software configuration management, mengelolah efek untuk merubah keseluruhan dari proses software.
   
7. 
   Reusability management, mendefinisikan kriteria untuk digunakan kembali produk kerja dan mendirikan mekanisme untuk menerima komponen yang dapat digunakan kembali.
   
8. 
   Work product preparation and production, mencakup kegiatan yang dibutuhkan untuk membuat model, dokumen, logs, forms dan lists
   

3. 
   Process Adaptation
   

Projek diadopsi untuk satu proyek mungkin berbeda secara signifikan dari proses diadopsi untuk proyek lain (Roger S. Pressman & Bruce R. Maxim, 2015:14-19).

1. 
   Aliran keseluruhan kegiatan, tindakan , tugas dan saling ketergantungan di antara mereka.
   
2. 
   Sejauh mana tindakan dan tugas didefinisikan dalam setiap kerangka aktivitas
   
3. 
   Sejauh mana produk kerja telah teridentifikasi dan diperlukan.
   
4. 
   Cara di mana kegiatan jaminan kualitas dapat diterapkan.
   
5. 
   Cara di mana pelacakan proyek dan kontrol kegiatan dapat diterapkan.
   
6. 
   Secara keseluruhan sejauh mana tingkat detail dan ketelitian dengan proses yang sudah digambarkan
   
7. 
   Sejauh mana pelanggan dan stakeholder lainnya terlibat dengan proyek tersebut.
   
8. 
   Tingkat otonomi yang diberikan kepada software team.
   
9. 
   Sejauh mana tim organisasi dan peran yang ditentukan
   

2.2 Agile Software Development

Agile software development adalah sebuah metode pengembangan software yang fokus pada kepuasan pengguna dan dapat melakukan pengembangan software dengan cepat. Agile software development memberikan petunjuk pengembangan mengenai pentingnya analisis dan desain, dan komunikasi yang aktif secara berkelanjutan antara developers dan customer (Pressman Maxim 2015:66).
2.2.1 Scrum

Scrum adalah salah satu metode dari agile software development yang diusulkan oleh Jeff Sutherland dan tim-nya pada awal tahun 1990. Scrum mempunyai beberapa framework activites yaitu requirement, analysis, design, evolution, dan delivery. Pada setiap framework activites akan muncul tugas dalam susunan proses yang disebut sprint. Tugas yang dilaksanakan pada setiap sprint akan beradaptasi dengan masalah yang dihadapi dan sering mendapatkan perubahan oleh tim Scrum.

Scrum menekankan penggunaan pola pengembangan software yang terbukuti efektif untuk proyek yang mempunyai timeline yang ketat, kebutuhan yang berubah dan bisnis yang penting. Setiap susunan proses mendefinisikan satu set aktivitas pengembangan :

1. 
   Backlog
   

Daftar kebutuhan proyek yang diutamakan dan fitur yang menyediakan bussines value untuk customer. Backlog menyediakan list fitur yang akan dikembangkan pada tahap pengembangan. Item apa pun dapat ditambahkan pada backlog setiap saat. Seorang product manager melakukan penilaian pada backlog dan melakukan perubahan sesuai kebutuhan.

2. 
   Sprints
   

Terdiri dari pekerjaan yang dibutuhkan untuk mencapai kebutuhan yang didefinsikan pada backlog. Setiap fitur yang telah ditentukan pada backlog akan dikembangkan. Setiap Sprint memiliki definisi mengenai apa yang akan dikembangkan, sebuah disain dan perencanaan yang fleksibel yang akan membimbing pengembangan, pekerjaan yang akan dilakukan dan hasil dari produk. Pekerjaan yang akan dilaksanakan di dalam Sprint direncanakan pada saat Sprint Planning. Sprint Goal merupakan sekumpulan tujuan yang akan dicapai dalam satu Sprint sepanjang pengimplementasian Product Backlog yang ditentukan pada bagian Sprint Planning. Tidak ada perubahan pada proses sprint. Oleh karena itu, sprint mengizinkan tim untuk bekerja pada waktu yang singkat tetapi stabil.

3. 
   Scrum meetings
   

Pertemuan yang dilakukan secara singkat setiap hari oleh tim scrum. Tiga pertanyaan kunci di tanyakan dan dijawab oleh seluruh tim scrum, yaitu :

1. 
   Apa yang anda lakukan setelah pertemuan terakhir?
   
2. 
   Apa masalah yang anda hadapi?
   
3. 
   Apa yang anda rencakan untuk diselesaikan hingga pertemuan berikutnya?
   

Pemimpim tim disebut Scrum Master yang memimpin pertemuan dan menilai respon yang diberikan oleh setiap anggota. Scrum Meeting dapat membantu tim untuk menemukan sebuah masalah secepat mungkin

4. 
   Demo
   

Pada tahap ini tim mengirimkan perkembangan software di mana fungsinya sudah bisa diimplementasi. Setelah mengirimkan perkembangan tersebut software akan mulai didemonstrasikan dan dievaluasi kepada customer.

Gambar 2.2 Scrum Process

2.3 UML

Unified Modeling Language (UML) adalah metode permodelan desain yang digunakan untuk menentukan atau menggambarkan suatu sistem perangkat lunak berorientasi objek (Whitten & Bentley 2007:246). UML dapat memberikan gambaran suatu sistem dengan menampilkan banyak notasi grafik dan seperangkat diagram. Dengan menggunakan UML dapat mendefinisikan suatu sistem yang kompleks menjadi lebih sederhana.
2.3.1 Use Case Diagram

Use Case Diagram adalah sebuah diagram yang digunakan untuk menggambarkan hubungan antara sistem dan eksternal sistem dan pengguna (Whitten & Bentley 2007:246). Selain itu use case diagram juga menggambarkan dan menjelaskan siapa yang akan menggunakan sistem dan bagaimana cara pengguna berinteraksi dengan sistem. Dalam menggambarkan use case diagram terdapat bagian-bagian utama yaitu boundaries, actor, use case dan relationships.

Gambar 2.3 Contoh Use Case Diagram

1. 
   Boundaries
   

Boundaries pada use case diagram digunakan untuk membatasi sistem yang dibuat. Boundaries digambarkan dengan persegi panjang di mana use case berada di dalamnya dan aktor terdapat di luar. Dengan adanya boundaries akan lebih mudah untuk melihat cakupan dari suatu sistem.

2. 
   Use Case
   

Use Case digunakan untuk mendeskripsikan suatu fungsi sistem dari perspektif pengguna eksternal dengan menggunakan cara dan istilah yang mudah dimengerti oleh pengguna (Whitten & Bentley 2007:246). Use Case di gambarkan dengan bentuk bulatan panjang di mana nama use case dituliskan di dalamnya.

Use Case

Simbol

Gambar 2.4 Contoh Use Case Simbol

3. 
   Actor
   

Aktor pada use case diagram digunakan untuk menggambarkan seorang pengguna, perangkat atau sistem eksternal yang dibutuhkan untuk berinteraksi dengan sistem untuk mendapatkan informasi (Whitten & Bentley 2007:247). Aktor pada use case diagram digambarkan dengan stick man di mana nama dari aktor tersebut tertulis di bawahnya.

Aktor pada use case diagram dibagi menjadi 4 tipe, yaitu :

1. 
   Primary Business Actor
   

Stakeholder pada tipe ini akan merasakan manfaat dari berjalannya suatu use case dengan menerima suatu nilai yang terukur. Aktor utama dapat memulai dan boleh tidak memulai dalam suatu kejadian.

2. 
   Primary System Actor
   

Stakeholder pada tipe ini langsung berinteraksi dengan sistem untuk menjalankan suatu kejadian. Primary system actor dapat langsung berinteraksi dengan primary business actor untuk mencapai tujuan dengan menggunakan sistem yang sebenarnya. Tipe ini juga memfasilitasi suatu kejadian untuk digunakan langsung dari sistem yang menguntungkan primary business actor.

3. 
   External Server Actor
   

Stakeholder pada tipe ini akan merespon permintaan dari use case.

4. 
   External Receiver Actor
   

Stakeholder pada tipe ini tidak menjadi aktor utama tetapi menjadi penerima dari suatu use case yang menerima suatu nilai yang dapat diukur atau dapat diamati.

Actor

Gambar 2.5 Contoh Actor pada Use Case Diagram

4. 
   Relationships
   

Sebuah relationships pada use case diagram digambarkan dengan sebuah garis di antara dua simbol. Arti dari setiap relationships berbeda-beda tergantung pada garis yang digambarkan dan tipe simbol yang menghubungkan keduanya.

5. 
   Associations
   

Associations adalah sebuah penghubung yang menghubungkan antara aktor dan suatu use case. Terdapat dua tipe associations, yang pertama adalah tipe association dengan tanda panah yang menghubungkan aktor dengan suatu use case sedangkan tipe association yang kedua adalah tipe association tanpa tanda panah yang menghubungkan use case dengan aktor penerima atau external receiver actor.

Gambar 2.6 Contoh Associations pada Use Case Diagram

6. 
   Extends
   

Extension use case adalah bagian dari suatu use case yang dipecah karena terlalu kompleks dengan tujuan untuk menyederhanakan use case tersebut agar lebih mudah untuk dipahami (Whitten & Bentley 2007:248). Hasil dari pemecahan dari suatu use case disebut extension use case yang mana extension use case memperluas fungsionalitas dari use case yang asli. Hubungan antara extension use case dan use case dapat disebut extends relationship. Suatu extends relationship digambarkan dengan tanda panah dan dengan memberi label nama “<>” pada penghubungnya. Dalam menggambarkan suatu extends relationship, garis penghubung dimulai dari extension use case dan menunjuk ke use case. Sebuah use case dapat memiliki banyak extends relationship, tetapi suatu extension use case hanya dapat dipanggil oleh use case yang memecah atau memperluasnya.

Gambar 2.7 Contoh Extends pada Use Case Diagram

7. 
   Uses (includes)
   

Dalam pembuatan use case diagram akan sering menemui keadaan di mana dua atau lebih use case memiliki fungsi sama. Apabila suatu use case memiliki fungsi yang sama lebih baik untuk memecah atau memisahkan ke dalam bagiannya sendiri yang disebut abstract use case. Sebuah abstract use case dapat ditampilkan berulang-ulang yang membuat abstract use case menjadi alat terbaik untuk mengurangi redundansi pada use case. Suatu abstract use case dapat digunakan banyak use case lain apabila suatu use case membutuhkan fungsi dari abstract use case. Hubungan antara abstract use case dan use case dapat disebut uses relationship yang dihubungkan dengan garis. Pada penggambarannya garis dimulai dari use case dan menunjuk dengan tanda panah ke abstract use case. Setiap uses relationship diberi nama <>.

Gambar 2.8 Contoh Uses (Includes) pada Use Case Diagram

8. 
   Depends On
   

Dalam pengembangan suatu sistem, penting untuk mengetahui use case mana yang memiliki ketergantungan dengan use case lain. Hal ini bertujuan untuk menentukan urutan dari use case mana yang nantinya akan dikembangkan. Contohnya seperti use case penarikan uang yang tidak dapat dijalankan sampai use case membuat deposit dijalankan dan use case membuat deposit tidak dapat dijalankan sampai use case mendaftarkan diri ke bank dilakukan. Karena adanya ketergantungan tersebut, para pengembang harus mengembangkan bagian use case mendaftarkan diri ke bank terlebih dahulu, kemudian yang kedua use case membuat deposit dan yang terakhir use case penarikan uang. Untuk menggambarkan depends on relationship pada suatu use case diagram, garis yang menghubungkan keduanya diberi label <>. Penghubung garis dimulai dari suatu use case dan menunjuk dengan tanda panah ke use case yang bergantung kepadanya.

Gambar 2.9 Contoh Depends On pada Use Case Diagram

9. 
   Inheritance
   

Ketika dua atau lebih aktor berbagi sifat yang sama, semua aktor tersebut dapat menggunakan use case yang sama. Untuk mengatasi hal tersebut, dibutuhkan suatu abstract actor untuk mengurangi komunikasi redundan dengan sistem.

Gambar 2.10 Contoh Inheritance pada Use Case Diagram

2.3.2 Use Case Narrative

Use case narrative merupakan deskripsi teks yang menjelaskan cara pengguna berinteraksi dengan sistem untuk menyelesaikan tugas. Use case narrative bertujuan supaya pengguna lebih cepat memahami dan mengetahui seberapa besar sistem tersebut (Whitten & Bentley 2007:256-260).

Gambar 2.11 Contoh Use Case Narrative

(Sumber: Whitten & Bentley, 2007:257)
Bagian-bagian dari contoh use case narrative adalah sebagai berikut :

1. 
   Author, nama dari pengguna yang berkontribusi dalam pembuatan use-case dan menyediakan kontak bagi siapa saja yang membutuhkan informasi tambahan tentang use case tersebut.
   
2. 
   Date, tanggal terakhir pada saat use case diubah.
   
3. 
   Version, versi dari use case.
   
4. 
   Use-case name, nama dari use case tersebut yang mewakili tujuan dari use case yang sedang dicoba untuk menyelesaikannya. Nama dari use case harus diawali dengan kata kerja.
   
5. 
   Use-case type, pemodelan use case, kebutuhan bisnis use case, yang berfokus pada visi strategi dan tujuan dari berbagai stakeholders. Jenis dari use case ini adalah bisnis orientasi dan mencerminkan pandangan tingkat tinggi yang diinginkan dari sistem tersebut.
   
6. 
   Use-case ID, pengenal yang unik untuk mengidentifikasi use case tersebut.
   
7. 
   Priority, prioritas yang memperlihatkan seberapa penting use case.
   
8. 
   Source, sumber yang mendefinisikanentitas yang memicu dalam pembuatan use case. Dapat berupa kebutuhan, dokumen spesifik, atau stakeholder.
   
9. 
   Primary business actor, pelaku usaha utama adalah stakeholder yang mendapatkan manfaat utama dari eksekusi sebuah use case dengan menerima nilai yang dapat diukur atau diamati.
   
10. 
    Other participation actors, actor lain yang berpartisipasi dalam use case untuk menyelesaikan tujuannya.
    
11. 
    Interested stakeholder(s), siapa yang memiliki saham dalam pengembangan dan pengoperasian sistem perangkat lunak.
    
12. 
    Description, deskripsi singkat yang terdiri dari beberapa kalimat yang menguraikan tujuan dari use case dan aktifitasnya.
    

Gambar 2.12 Contoh Use Case Narrative yang Telah diperluas

(Sumber: Whitten & Bentley, 2007:259)

Gambar 2.13 Lanjutan Use Case Narrative yang Telah diperluas

(Sumber: Whitten & Bentley, 2007:260)
Bagian-bagian dari contoh use case narrative yang sudah diperluas adalah sebagai berikut :

1. 
   Precondition, sebuah kendala pada sistem sebelum use case dapat dieksekusi. Khususnya ini mengacu pada use case lainnya yang harus dieksekusi sebelumnya.
   
2. 
   Tigger, pemicu adalah hal yang memprakarsai pelaksanaan sebuah use case. Sering kali adalah tindakan fisik, seperti seorang pelanggan berjalan menuju loket penjualan atau mengecek surat yang datang.
   
3. 
   Typical course of event, urutan dari sebuah kegiatan yang dilakukan oleh aktor dan sistem untuk mencapai tujuan dari use case. Ini termasuk interaksi antara sistem dan aktor dan kegiatan yang dilakukan oleh sistem dalam menanggapi interaksi.
   
4. 
   Alternate course, mendokumentasikan sifat-sifat dari use case apabila terjadi pengecualian atau perubahan pada typical course.
   
5. 
   Conclusion, menspesifikasikan kesimpulan ketika use case berhasil berhenti, dalam kata lain, ketika aktor utama menerima suatu nilai terukur.
   
6. 
   Postconditon, sebuah kendala pada sistem sesudah use case berhasil dieksekusi. Ini bisa menjadi data yang tercatat dalam database atau menjadi tanda terima yang dikirim ke pelanggan.
   
7. 
   Bussiness rules, menentukan kebijaksanaan dan prosedur dari bisnis dengan sistem baru yang harus dipatuhi. Termasuk perhitungan biaya pengiriman atau aturan pemberian syarat kredit.
   
8. 
   Implementation constraints and specifications, menentukan persyaratan nonfungsional yang dapat mempengaruhi realisasi dari use case dan dapat membantu dalam setiap perencanaan dan pencakupan arsitektural.
   
9. 
   Assumption, setiap asumsi yang dibuat oleh penciptanya ketika mendokumentasikan use case.
   
10. 
    Open issues, setiap pertanyaan atau masalah perlu dilakukan penyelesaian atau penyelidikan sebelum use case tersebut dapat diselesaikan.