Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer e-issn: X

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer Vol. 1, No. 11, November 2017, hlm. 1178-1187

e-ISSN: 2548-964X http://j-ptiik.ub.ac.id

Pengembangan Sistem Peringatan Dini Masa Kontrak Kerja Karyawan dengan Menerapkan Pendekatan Kolaboratif Athena pada Elisitasi Kebutuhan (Studi Kasus PT. Surya Optima Nusa Raya) Reza Fahrur Rasyid1, Fajar Pradana2, Bayu Priyambadha3 Program Studi Teknik Informatika, Fakultas Ilmu Komputer, Universitas Brawijaya Email: [email protected], [email protected], [email protected] Abstrak PT. Surya Optima Nusa Raya adalah perusahaan manufaktur plastik. Dari hasil observasi dan diskusi yang telah dilakukan ditemukan bahwa karyawan kontrak yang telah habis masa kontraknya tidak dapat melakukan absensi secara otomatis pada sistem absensi yang telah ada diperusahaan karena proses pengurusan kontrak kerja yang belum selesai, dan perjanjian kerja hanya terjadi dari mulut saja, ditambah sistem absensi menganggap karyawan yang kontraknya belum selesai tersebut telah keluar dari perusahaan tanpa memperdulikan kepengurusan kontrak telah selesai atau belum. Sistem peringatan dini dapat menjadi solusi untuk melakukan monitoring kontrak serta memberikan peringatan. Dalam proses pembangunan sistem diupayakan untuk mampu mengkamodasi kebutuhankebutuhan dari manager dan staff HRD perusahaan. Salah satu metode yang bisa dipakai untuk menghasilkan kebutuhan lebih detil adalah dengan menerapkan pendekatan kolaboratif athena pada elisitasi kebutuhan. Berdasarkan hasil penelitian skripsi yang telah dilakukan maka dapat ditarik kesimpulan proses rekayasa kebutuhan perangkat lunak dengan menerapkan pendekatan kolaboratif Athena berhasil menganalisis 24 kebutuhan sistem dari total 26 kebutuhan. Berdasarkan hasil pengukuran requirement metric, dapat disimpulkan bahwa hasil kualitas dokumen kebutuhan spesifikasi kebutuhan perangkat lunak yang didapat dengan menerapkan pendekatan kolaboratif athena telah memenuhi beberapa standar metrics yang ada dalam requirement metric. Kata kunci: Peringatan Dini, Rekayasa Kebutuhan, Elisitasi Kebutuhan, Pendekatan Kolaboratif Athena, requirement metrics.

Abstract PT. Surya Optima Nusa Raya is a plastic Manufacturing Company. From the observations and discussions that have been conducted, found that the employees whose their contract have been expires can not confirm their attendance automatically on the attendance system that has existed in the company because the process of their extension contract has not been completed, and the agreements only occur by the mouth only, plus the attendance system considers that employees whose their contract expires has left the company without regard to the process of their extension contract has been completed or not. Early warning systems can be a solution for monitoring the contract and provide a warning. To do that, the system analyst must clarify the requirement by using some requirement analysis method in requirement engineering phase. One method that can be used to produce a more detailed requirements is to adopt a collaborative approach athena on requirements elicitation. Based on the results of the research, it can be concluded the process of requirements engineering software by applying a collaborative approach Athena successfully analyzed 24 system requirements from total of 26 requirements. Based on the results of measurement requirement metric, it can be concluded that the quality of document software requirements specification requirements that have been obtained by applying a collaborative approach athena has met some standard metrics that exist in the metric requirement Keywords: Early Warning, Requirements Engineering, Requirement Elicitation, Collaborative Approach Athena, requirement metrics.

Fakultas Ilmu Komputer Universitas Brawijaya

1178

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer

1. PENDAHULUAN Sistem kerja kontrak yang telah banyak digunakan oleh perusahaan-perusahaan di Indonesia mengakibatkan adanya diferensiasi atau pembeda karyawan pada satu perusahaan, berdasarkan status hubungan kerja yaitu karyawan tetap, karyawan kontrak dan karyawan outsourcing (Indrasari, Rina, & Suhadmadi, 2010). Menurut Indrasari, Rina, dan Suhadmadi (2010), Karyawan kontrak merupakan karyawan yang perjanjian kerjanya langsung dengan perusahaan tempatnya bekerja dan perjanjian kerjanya dibuat untuk waktu tertentu. PT. Surya Optima Nusa Raya adalah perusahaan manufaktur plastik yang berdomisili di Jl. Raya Wonoayu No 26 d, Gempol, Pasuruan, merupakan salah satu perusahaan yang menggunakan sistem kerja kontrak bagi sebagian karyawannya. Dari hasil diskusi yang telah dilakukan diantara penulis dan manager HRD pada perusahaan tersebut, penulis mendapati bahwa karyawan kontrak yang telah habis masa kontraknya tidak dapat melakukan absensi secara otomatis pada sistem absensi yang telah ada diperusahaan karena proses pengurusan kontrak kerja yang belum selesai, dan perjanjian kerja hanya terjadi dari mulut saja karena surat kontrak yang belum keluar, ditambah sistem absensi menganggap karyawan yang kontraknya belum selesai tersebut telah keluar dari perusahaan tanpa memperdulikan kepengurusan kontrak telah selesai atau belum. Dari permasalahan pihak HRD PT. Surya Optima Nusa Raya maka dibutuhkan perangkat lunak yang dapat membantu dalam memberikan informasi dan melakukan monitoring kontrak. Dalam proses pembangunan perangkat lunak tersebut diupayakan untuk mampu mengkamodasi kebutuhan-kebutuhan dari para pemangku kepentingan. Menurut Laporti, Borges dan Bragonholo (2009) kualitas dari kebutuhan sangatlah krusial dari kesuksesan suatu proyek. Dalam ranah industri, proses umum untuk memunculkan kebutuhan terfokus pada kelompok, seperti JAD, sesi brainstorming, dan wawancara pada satu atau banyak pemangku kepentingan (stakeholders). Hal ini berakibat, khususnya pada fase awal dari sebuah proyek, yaitu para pemangku kepentingan memiliki banyak perbedaan pemahaman, dan perbedaan interpretasi terhadap proyek (Boulila, Hoffman Fakultas Ilmu Komputer, Universitas Brawijaya

1179

& Herrman, 2011). Sebagai seorang analis muda, penulis mendapati sulitnya untuk mendapatkan kebutuhan-kebutuhan yang diinginkan maupun yang dibutuhkan oleh para pemangku kebutuhan. Hal ini pernah penulis alami selama menjalankan tugas akhir dari beberapa mata kuliah yang pernah diambil, serta praktek kerja lapangan yang sudah dilakukan oleh penulis, yaitu ketika hasil akhir sistem yang dibangun sebagai tugas akhir dapat berjalan lancar, namun tidak sesuai dengan ekspektasi dari para pemangku kepentingan karena kurangnya fitur akibat proses bisnis yang kurang tergali selama fase analisis kebutuhan berlangsung ataupun adanya fitur yang tidak perlu ada dalam sistem. Ini tidak terlepas dari kurangnya pengalaman dan pengetahuan yang dimiliki oleh penulis, menurut penjelasan pada paragraf diatas, hal ini akan berimbas kepada kesuksesan proyek yang akan dibangun dan dilakukan oleh penulis selama penelitian ini berlangsung. Dari penjelasan tersebut, penulis memutuskan untuk mencoba menggunakan metode yang dikemukakan oleh Laporti, Borges, dan Braganholo pada tahun 2009, dengan jurnalnya yang berjudul “Athena: A collaborative approach to requirements elicitation”. Jurnal ini membahas tentang model dan metode yang berdasarkan pendekatan kelompok bercerita (group storytelling), dimana para pemangku kepentingan bercerita tentang sistem saat ini dan masa lalu yang mendukung kegiatan tertentu. Cerita tersebut kemudian diubah menjadi skenario, dan dari skenario diubah menjadi definisi use case untuk membuat sebuah perangkat lunak yang sesuai dengan kebutuhan pengguna. Keunggulan dari Athena ini adalah untuk mencegah terjadinya identifikasi kebutuhan yang kurang atau ambigu. Dalam kerangka kerja ini, semua pemangku kepentingan melaporkan pengalaman dan sudut pandang mereka dan menegosiasikan kebutuhan sistem secara kolaboratif. Membangun sistem dari cerita narasi user menjadi definisi use case, ketika para pemangku kepentingan dapat menggunakan bahasa mereka sendiri sebagai alat untuk menyampaikan kebutuhan dan permintaan. Tidak hanya itu, dalam Athena juga memiliki modul-modul yang digunakan pada setiap langkah yang ada dalam Athena. Berkat penggunaaan modul-modul ini, Athena dapat memberikan kemudahan bagi para analis muda, salah satunya seperti penulis, untuk


mendapatkan kebutuhan yang tidak ambigu, benar dan lengkap. Untuk memastikan penelitian yang dihasilkan sesuai harapan maka dilakukan dua model pengujian. Model yang pertama adalah menguji perangkat lunak dengan melakukan pengujian white box dan pengujian black box. Model yang kedua adalah mengukur kualitas kebutuhan yang telah didapatkan dari metode Athena dengan dilakukan pengukuran menggunakan requirement metrics. Berdasarkan pemaparan diatas, akan dirancang sebuah sistem peringatan dini masa kontrak kerja karyawan di PT. Surya Optima Nusa Raya. Sistem Peringatan dini ini akan membantu bagian HRD perusahaan dalam memantau karyawan yang akan habis masa kontraknya. Analisis kebutuhan sebagai dasar dari perancangan dan pembangunan sistem peringatan dini ini akan menerapkan kerangka kerja atau metode yang bernama Athena pada fase elisitasi kebutuhannya. 2. LANDASAN KEPUSTAKAAN 2.1 Rekayasa Kebutuhan Rekayasa Kebutuhan (Requirement Engineering) adalah bagian dari rekayasa perangkat lunak yang berkaitan dengan penemuan (discovering), pengembangan (developing), pelacakan (tracing), penganalisaan (analyzing), pengkualifikasian (qualifying), pengkomunikasian (comunicating), dan pengelolaan (managing) kebutuhan yang mendefinisikan sistem pada tingkat abstraksi (Hull, Jackson & Dick, 2010). Daniel Siahaan (2012) menjelaskan rekayasa kebutuhan adalah aktivitas-aktivitas menyelidiki, mencari, atau mengidentifikasi spesifikasi kebutuhan sistem serta mengkomunikasikannya kepada pelanggan maupun pengembang, baik secara lisan maupun tulisan. Kebutuhan pengguna memainkan peran sentral dalam proses pengembangan perangkat lunak dengan menjembatani kebutuhan bisnis untuk perangkat lunak dan pada berbagai kondisi, para pemangku kepentingan (stakeholder) yang memiliki perspektif tentang sistem perlu ikut bekerja sama untuk mengklarifikasi kebutuhan sistem dengan cara yang efisien dan efektif (Azadegan, Papamichail & Sampaio, 2013). Bashir dan Salam (2015) menyebutnya sebagai pondasi untuk setiap SDLC (Software Development Life Fakultas Ilmu Komputer, Universitas Brawijaya

1180

Cycle), dan rekayasa kebutuhan adalah bagian terpenting dari sebuah rekayasa perangkat lunak sebagaimana kegagalan dari fase ini memungkinkan dikenakan biaya yang tinggi pada sebuah projek. Daniel Siahaan (2012) pada bukunya menjelaskan bahwa terdapat 4 aktivitas yang terkait dengan pengembangan kebutuhan yaitu elisitasi, analisis, spesifikasi, serta validasi dan verifikasi. 2.1.1 Elisitasi Kebutuhan Elisitasi Kebutuhan atau yang biasa disebut dengan Requirement Elicitation adalah salah satu tahapan proses penting yang berfungsi sebagai pendifinisian awal dari sebuah kebutuhan pada perangkat lunak. Beberapa permasalahan rumit yang sering muncul pada tahap pengembangan dapat dihindari dengan cara mengidentifikasi stakeholder dan elisitasi kebutuhan secara tepat (Pacheco & Garcia, 2012). Pressman (2010) menyebutkan requirement elicitation dapat disebut juga sebagai requirement gathering yaitu menggabungkan unsur-unsur dari penyelesaian masalah, elaborasi, negosiasi, dan spesifikasi. Dengan tujuan agar menjadi bersifat kolaboratif, pada pendekatan berorientasi pada tim untuk memperoleh kebutuhan-kebutuhan, para pemangku kepentingan (stakeholders) harus saling bekerja sama untuk mengusulkan solusi-solusi atas permasalahan-permasalahan itu, menegosiasikan pendekatan-pendekatan yang berbeda dan menetapkan sejumlah solusi kebutuhan yang bersifat pendahuluan. 2.1.2 Analisis Kebutuhan Analisis kebutuhan merupakan bagian dari rekayasa kebutuhan yang bertujuan untuk menetapkan spesifikasi-spesifikasi dasar perangkat lunak selama pekerjaan-pekerjaan inception, elicitation, serta negoitation (Pressman, 2010). Pressman dalam bukunya menggambarkan analisis kebutuhan sebagai jembatan antara deskripsi sistem dengan perancangan perangkat lunak. Dalam buku yang ditulis oleh Daniel Siahaan(2012) yang menjelaskan mengenai bab analisis kebutuhan yaitu analisa kebutuhan yang baik hendaklah menitik beratkan pada ranah permasalahan dan bukan pada ranah solusi.


2.2 Pendekatan Kolaboratif Athena Athena adalah sebuah model, metode, dan alat untuk mengindentifikasi kebutuhan sistem yang dikembangkan oleh Laporti, Borges, dan Braganholo pada tahun 2007 hingga 2009. Pendekatan ini mempromosikan dan mendukung pertukaran pengetahuan (knowledge exchange) dan negoisasi antara stakeholder. Langkah-langkah dari athena ini terdiri dari tiga langkah. Langkah pertama adalah mengeksplorasi bahasa natural menggunakan teks narasi. Kemudian pada langkah kedua mengumpulkan informasi yang didapat dari langkah pertama menggunakan deskripsi skenario. Setiap skenario fokus pada sebuah aktivitas dan mengadakan perbaikan dari deskripsi-deskripsi yang ada pada langkah pertama. Dan pada langkah ketiga adalah membangun use case menggunakan skenario dari langkah kedua (Laporti, Borges & Bragonholo, 2009).

Untuk lebih jelas mengenai keterangan diatas dapat dilihat pada gambar 1 dibawah.

1181

Deskripsi umum skenario n antara skenario

Cerita

(kelengkapan/ketergantungan/penyeba b-konsekuensi/kontradiksi/konfirmasi)

Tabel 2. Konversi Detail Skenario Detail Skenario Deskripsi aksi Deskripsi operasi

Cerita Jalan eksekusi cerita Deskripsi aksi skenario

Tabel 3. Informasi Pelengkap Skenario Informasi Pelengkap Skenario Peran

Pembatasan peran Kebutuhan yang terpenuhi Input informasi Hasil yang diharapkan Formula yang terkait Variabilitas eksekusi

Deskripsi fungsionalitas Deskripsi fungsionalitas Ketergantungan pada fungsi yang lain atau perangkat lunak yang lain

Pengubahan dari satu langkah ke langkah selanjutnya, dimulai dengan pengubahan dari cerita ke skenario, kemudian pengubahan dari skenario ke use case. Tabel 1 sampai 4 dibawah menjelaskan konstruksi skenario dari ceritacerita yang ada pada langkah pertama, dan tabel 5 sampai 6 menjelaskan tentang use case yang di dapat dari skenario. Tabel 1. Dari Cerita ke Deskripsi Umum Skenario Deskripsi umum skenario Nama Deskripsi lokal Tujuan Skenario yang terkait Ketergantunga

Orang-orang yang terlibat dalam aktivitas eksekusi, orang-orang yang terlibat dalam kultur organisasi Kemampuan yang dibutuhkan untuk eksekusi dalam aktivitas Kesulitan yang dikenakan oleh aktivitas Aktivitas yang terkait Tujuan cerita Jalan eksekusi Deskripsi perbedaan aktivitas cerita

Tabel 4. Kebutuhan Perangkat Lunak Skenario perangkat lunak Nama fungsionalitas

Gambar 1. Tiga Langkah Athena

Cerita

Cerita Nama aktivitas cerita, nama skenario Deskripsi aktivitas, tujuan aktivitas, deskripsi aksi dan operasi Aktivitas yang terkait cerita, hubungan antara aktivitas cerita, hubungan antara aktivitas skenario

Tabel 5. Dari Skenario ke Use Case Use Case Nama Tujuan Aktor Pra-kondisi Aliran utama Aliran Utama Pasca-kondisi Ketergantungan antar use case

Cerita

Skenario Nama Kebutuhan yang terpenuhi, tujuan Peran Pembatasan peran, input informasi Aksi, operasi, formula, deskripsi fungsional, input informasi Kebutuhan yang terpenuhi, hasil yang diharapkan Skenario yang terkait, ketergantungan antar skenario, ketergantungan pada fungsi yang lain

Tabel 6. Kebutuhan Non-Fungsional Nama aktivitas Fitur lokal/ kultur organisasi Tujuan aktivitas (activity goal) Aktivitas yang terkait Hubungan antar aktivitas

Fakultas Ilmu Komputer, Universitas Brawijaya

Kebutuhan non-fungsional Daftar kebutuhan nonfungsional

Skenario Deskripsi lokasi, pembatasan


2.3 Requirement Metric Rekayasa Kebutuhan adalah ranah penting dari siklus hidup pengembangan perangkat lunak (SDLC). Rekayasa Kebutuhan memainkan peranan penting dalam menjaga kualitas suatu perangkat lunak. Kualitas perangkat lunak tergantung pada banyak faktor seperti ketepatan waktu, kesesuaian anggaran dalam memenuhi kebutuhan pengguna. Kebutuhan perangkat lunak adalah dasar dari kualitas dapat diukur. Kualitas harus dijaga dari mulai tahap pengembangan perangkat lunak. kualitas perangkat lunak selama proses rekayasa kebutuhan dapat dilakukan melalui requirement metrics (Haleem, Beg & Ahmad, 2013). Software metrics (metrik perangkat lunak) adalah bidang rekayasa perangkat lunak yang berhubungan dengan beragam pengukuran perangkat lunak komputer dan perkembangannya. Dalam jurnalnya yang berjudul “Overview of Impact of Requirement Metrics in Software Development Environment” Haleem, beg dan Ahmad (2013) mengungkapkan bahwa metrik perangkat lunak adalah tindakan yang memungkinkan pengembang perangkat lunak (developer) dan analis perangkat lunak (Software Analyst) untuk mendapatkan efisiensi proses perangkat lunak dan proyek-proyek yang dilakukan dengan menggunakan proses sebagai kerangka kerjanya. Metrik kualitas perangkat lunak (Software Quality Metrics ) adalah bagian dari metrik perangkat lunak yang berfokus pada aspek kualitas perangkat lunak. Metrik kualitas perangkat lunak terkait oleh proses dan produk metrik dengan metrik proyek. Metrik kualitas perangkat lunak dapat dibagi lebih lanjut ke metrik kualitas produk akhir dan dalam proses metrik kualitas (Haleem, Beg & Ahmad, 2013). Rekayasa kebutuhan terdiri dari elisitasi, analisis, komunikasi dan validasi kebutuhan. Haleem, Beg dan Ahmad (2013) menuturkan Jika kesalahan dapat ditemukan dalam tahap awal maka akan memudahkan dalam melakukan perbaikan dari pada menemukan kesalahan pada tahap selanjutnya. Dan biaya memperbaiki kesalahan ini dalam tahap awal jauh lebih rendah daripada memperbaiki mereka di tahap akhir pengembangan perangkat lunak . Haleem, Beg, dan Ahmad (2013) menjelaskan use case dan alat-alat tradisional Fakultas Ilmu Komputer, Universitas Brawijaya

1182

lainnya memang digunakan untuk mengumpulkan dan menggambarkan arsitektur sistem. Namun, untuk memeriksa kualitas dari kebutuhan yang telah dikumpulkan, banyak kualitas metrik kebutuhan (requirements quality metrics) yang dapat digunakan. Kualitas metrik-metrik kebutuhan yang dijelaskan oleh Haleem, Beg dan Ahmad (2013) dapat dilihat pada tabel 7dibawah. Tabel 7. Requirement Metrics untuk Memastikan Kualitas Dalam Proses Rekayasa Kebutuhan No 1

Nama Metric Kejelasan (unambiguous)

Rumus/Formula

Dimana, = Kebutuhan dengan penjelasan yang sama =Total Kebutuhan

2

Kelengkapan (completeness) Dimana,

Ukuran 0 atau mendekati 0 berarti ambigu 1 atau mendekati 1 berati kebutuhan tersebut tidak ambigu Mendekati 1 maka akan lebih lengkap

= Jumlah kebutuhan yang unik = Total Kebutuhan

3

Kebenaran (correct) Dimana, = Total kebutuhan yang memiliki penafsiran yang sama = Total Kebutuhan

4

Konsisten (consistent) Dimana, = Total kebutuhan yang dispesifikasikan secara unik = Total dari fungsi unik yang tidak deterministik

5

Keunikan (uniqueness) Dimana, = Kebutuhan dengan penjelasan yang berbeda

0 berati tidak benar 1 berati benar

0 berarti tidak konsisten 1 berati konsisten

Mendekati 1 maka akan semakin unik

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer No

Nama Metric

Rumus/Formula = Kebutuhan

6

Dimengerti (understandable)

Dimodifikasi (modifiable)

Gambar 2. act Alur Athena Dalam Model Spiral Pada Analisis Kebutuhan

Total

Dimana, = Kebutuhan yang dimengerti = Total Kebutuhan 7

Ukuran

1183

Sosialisasi

0 berarti tidak ada kebutuhan yang dimengerti 1 berati semua kebutuhan dimengerti Tidak Dijelaskan

Eksternalisasi

Internalisasi

Kombinasi

Mulai

Langkah Pertama Athena

Diskusi

Pengumpulan Cerita

Pemilahan Deskripsi Cerita

Konversi cerita ke skenario

Pendokumentasian Skenario

Penggabungan, Pencantuman Deskripsi dan Komentar Dalam Skenario

Dimana, = kebutuhan diubah = Kebutuhan 8

Total yang

Konversi Skenario ke Use Case

Total Pendokumentasian Use Case

Dapat Dilacak (Traced)

Tidak Dijelaskan

Penggabungan Use Case dan penyisipan komentar dalam Use Case

Pemahaman Aktivitas, Proses, dan Kebutuhan

Langkah Kedua Athena

Pemahaman Tentang Setiap Aktivitas dan Konteksnya, Kebutuhan dan Semua Operasi yang Mendukung Perangkat Lunak

Langkah Ketiga Athena

Pemahaman Kebutuhan Sistem dan kebutuhan User

Selesai

Dimana, = kebutuhan dapat dilacak = Kebutuhan 9

4. ANALISIS KEBUTUHAN

Total

Diverifikasi (Veriviable) Dimana, = Kebutuhan = Biaya diperlukan memverifikasi = Waktu diperlukan memverifikasi

Gambar 2. Alur Athena Dalam Model Spiral Pada Analisis Kebutuhan

Total yang

Total

0 berarti sangat buruk 1 berarti sangat bagus

yang untuk yang untuk

3. METODOLOGI 3.1. Analisis Kebutuhan Analisis Kebutuhan pada penelitian ini mengacu pada kerangka kerja dari pendekatan kolaboratif athena yang didasari dengan model manajemen pengetahuan spiral untuk menggambarkan pertukaran pengetahuan yang didapat selama proses elisitasi, sehingga teknik yang dilakukan dalam pengumpulan data kebutuhan ini adalah dengan kelompok bercerita baik itu dilakukan pada tempat dan waktu yang sama maupun tempat dan waktu yang berbeda karena urusan masing-masing para pemangku kepentingan (stakeholders). Alur kerja athena dapat dilihat seperti pada Fakultas Ilmu Komputer, Universitas Brawijaya

Pada tahap ini memproses daftar kebutuhan yang diutarakan pemangku kepentingan (Stakeholder) hingga menghasilkan spesifikasi kebutuhan perangkat lunak (SKPL). Hasil elisitasi kebutuhan dengan menerapkan pendekatan kolaboratif athena pada salah satu cerita aktivitas sistem yaitu aktivitas autentikasi dapat dilihat pada tabel 8(a), 8(b). pengubahan dari cerita ke skenario dapat dilihat pada tabel 9(a), 9(b), 9(c), 9(d). Dan pengubahan dari skenario ke definisi use case dapa dilihat pada tabel 10(a), 10(b). Tabel 8(a). Hasil langkah 1 Athena pada Aktivitas Autentikasi Deskripsi Aktivitas Autentikasi Sistem mengenali pengguna yang mengakses sistem Alur pengeksekusian “Seperti pada umumnya aktivitas sistem yang memiliki fitur login, ada username dan password-nya, atau misal kalau lupa passwordnya ada yang menangani. Jadi saya bisa menggunakan seluruh fitur yang ada sistem sedangkan staf saya hanya fitur tertentu saja.” Karyawan HRD: “Kalo bisa untuk username langsung menggunakan nrp saja, agar mudah ingat Nama aktivitas Tujuan

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer Deskripsi Aktivitas username-nya.” Apakah aktivitas Tidak dieksekusi dalam grup Hubungan dengan Tidak ada aktivitas Bagaimana aktivitas ini Tidak ada terhubung

Tabel 8(b). Hasil langkah 1 Athena pada Aktivitas Autentikasi Informasi Pelengkap Sistem dapat mengenali pengguna yang mengakses sistem Sistem dapat menambah, melihat, menghapus dan memperbarui data pengguna. Kesulitan Fitur Lokasi “Menggunakan komputer kantor, selama terhubung dengan jaringan perusahaan.” Kultur organisasi Aktivitas tidak berelasi dengan aktivitas yang lain Kemampuan

Tabel 9(a) Hasil Langkah Kedua Athena Pada Aktivitas Autentikasi untuk Skenario Login Deskripsi Umum Skenario Nama Deskripsi Lokal

Tujuan

Skenario yang Terkait Ketergantungan antar Skenario

Cerita Login. Komputer di perusahaan atau laptop maupun gadget lainnya selama terhubung dengan jaringan perusahaan. Sistem dapat mengenali pengguna yang mengakses sistem. Tidak ada. Tidak ada ketergantungan.

1184

Informasi Pelengkap Skenario Input Informasi Hasil diharapkan

yang

Formula terkait Variabilitas eksekusi

yang

Deskripsi Operasi

Cerita 1. Pengguna memasukkan username dan password. 2. Sistem memvalidasi username dan password yang telah dimasukkan. 1. Pengguna memasukkan username dan password. 2. Sistem memvalidasi username dan password yang telah dimasukkan.

Tabel 9(c) Hasil Langkah Kedua Athena Pada Aktivitas Autentikasi untuk Skenario Login Informasi Pelengkap Skenario Peran Pembatasan Peran

Kebutuhan Terpenuhi

yang

Cerita

Pengunjung Sistem. Dalam aktivitas ini, pengunjung harus mengetahui username dan passwordnya. Sistem menampilkan halaman utama sistem sesuai hak akses aktor yang teridentifikasi oleh sistem.


Informasi mengenai username dan password. Pengunjung atau pengakses sistem dapat masuk ke halaman sistem sesuai hak aksesnya. Tidak ada Formula yang terkait dalam aktivitas ini. -

Tabel 9(d) Hasil Langkah Kedua Athena Pada Aktivitas Autentikasi untuk Skenario Login Skenario perangkat lunak Nama Fungsionalitas Deskripsi Fungsionalitas

Ketergantungan pada fungsionalitas lain atau pada sistem lain

Cerita Login. Pengunjung atau pengakses sistem harus memiliki username dan password yang telah diidentifikasi oleh sistem. Tidak ada ketergantungan.

Tabel 10(a) Hasil Langkah Ketiga Athena Pada Aktivitas Autentikasi untuk Definisi Use Case Login Use Case Nama Tujuan Aktor Pra-kondisi Alur utama Alur Utama

Tabel 9(b) Hasil Langkah Kedua Athena Pada Aktivitas Autentikasi untuk Skenario Login Detail Skenario Deskripsi Aksi

Cerita

Alur alternatif Pasca-kondisi

Ketergantungan anta Use Case

Skenario Login. Sistem dapat mengenali pengguna yang mengakses sistem. Pengunjung. Aktor mengakses halaman login sistem. 1. Aktor memasukkan username dan password. 2. Sistem memeriksa validalitas input aktor. 3. Sistem menampilkan halaman utama sistem sesuai hak akses. Sistem menampilkan halaman utama sesuai hak akses aktor yang teridentifikasi oleh sistem. Tidak ada.

Tabel 10(b) Hasil Langkah Ketiga Athena Pada Aktivitas Autentikasi untuk Definisi Use Case Login Kebutuhan non-fungsional Daftar kebutuhan nonfungsional

Skenario Komputer yang menyala selama 24 jam/7

Setelah seluruh kebutuhan telah didapatkan dan terkumpul maka dibentuklah pemodelan sistem yang berupa diagram use case. Gambar 3 merepresentasikan diagram use case. Total use case yang didapat dalam penelitian ini adalah 23 use case.


1185

uc Use Case Sistem Peringatan Dini Kontrak

Sistem Peringatan Dini Masa Kontrak Karyawan Membuat Akun Pengguna

Melihat Akun Pengguna

Mengubah Akun Pengguna

Mengirimkan Peringatan Tidak Ada Absensi Jam Keluar

Menghapus Akun Pengguna Membuat Penerima Peringatan

Manager HRD

Mengirimkan Peringatan Kontrak

Melihat Penerima Peringatan

Mengubah Penerima Peringatan

Windows Task Scheduler

Menghapus Penerima Peringatan

Staff HRD

Mengubah Karyawan Kontrak Melihat Karyawan Kontrak Memperbarui Kontrak Manajemen Akun Membuat Libur Nasional

Kunci Layar Melihat FAQ Pengiriman

Menghapus Libur Nasional

Mengubah Libur Nasional

Melihat Libur Nasional

Menghapus Kontrak yang Tidak Diperpanjang

Mencetak Form Permohonan Cuti

Login

Gambar 4. Perancangan Arsitektural Sistem Peringatan Dini Masa Kontrak Kerja Karyawan

5.2 Perancangan Kelas Pengunjung

Gambar 3. Diagram Use Case

5. PERANCANGAN 5.1 Perancangan Arsitektural Sistem peringatan dini masa kontrak karyawan ini menggunakan arsitektur clientserver yang bertujuan untuk dapat diakses dari berbagai komputer di dalam perusahaan selama komputer terhubung dijaringan perusahaan. Dari gambar 4 tersebut bahwa sistem ini nantinya akan menggunakan layanan web service yang akan disediakan oleh pihak perusahaan untuk menghubungkan sistem ini dengan database perusahaan. Layanan web service yang dibuka adalah untuk menampilkan seluruh data karyawan yang ada diperusahaan serta menampilkan data absensi karyawannya dan mengubah data karyawan kontrak sesuai yang dibutuhkan oleh sistem yaitu alamat, tanggal awal dan akhir kontrak, gaji serta tunjangan-tunjangan yang diberikan oleh perusahaan kepada karyawan kontrak yang bersangkutan.

Mekanisme perancangan diagram kelas dimulai dengan merancang diagram kelas level analisis, lalu diagram kelas model level implementasi, dan diagram kelas controller level implementasi. Gambar 5 Menampilkan Diagram kelas level analisis. Gambar 6 menampilkan diagram kelas model level implementasi. Gambar 7 menampilkan diagram kelas controller level implementasi. class Kelas Lev el Analisis

LiburNasional + id_libur + tanggal_libur + keterangan

Pengguna + + + + + +

idPengguna namaPengguna alamatEmail username password Hak Akses

+ + + + + + +

modMembuatPengguna(): void modMelihatPengguna(): void modMengubahPengguna(): void modGetPengguna(): void modMenghapusPengguna(): void modManajemenAkun(): void modUbahPassword(): void

+ + + + + + +

modMelihatLiburNasional(): void modMembuatLiburNasional(): void modGetLiburNasional(): void modMengubahLiburNasional(): void modMenghapusLiburNasional(): void modTanggalLibur(): void tglIndo(): void

Penerima Peringatan + idPenerimaPeringatan + namaPenerimaPeringatan + alamatEmailPenerimaPeringatan

KontrakTidakPerpanjang + nrp + namaKaryawan + enddate

+ + + + + +

modMembuatPenerimaPeringatan(): void modMelihatPenerimaPeringatan(): void modMengubahPenerimaPeringatan(): void modMenghapusPenerimaPeringatan(): void modGetPenerimaPeringatan(): void check_unique_email(): void

+ modFilterTidakPerpanjangKontrak(): void + modTidakPerpanjangKontrak(): void + modHapusKontrakTidakPerpanjang(): void

Gambar 5. Diagram Kelas Level Analisis class Model

CI_Model

Kontrak Tidak Perpanjang + + +

modAutentikasi + + +

cekStatusAutentikasi(): void modLogin(): void cekUnlock(): void Pengguna

+ + + + + +

idPengguna namaPengguna alamatEmail username password hakAkses

+ + + + + + +

modMembuatPengguna(): void modMelihatPengguna(): void modMengubahPengguna(): void modGetPengguna(): void modMenghapusPengguna(): void modManajemenAkun(): void modUbahPassword(): void

PenerimaPeringatan + + +

idPenerimaPeringatan namaPenerimaPeringatan alamatEmailPenerimaPeringatan

+ + + + + +

modMembuatPenerimaPeringatan(): void modMelihatPenerimaPeringatan(): void modMengubahPenerimaPeringatan(): void modMenghapusPenerimaPeringatan(): void modGetPenerimaPeringatan(): void check_unique_email(): void

modFilterKontrakTidakPerpanjang(): void modTidakPerpanjangKontrak(): void modHapusKontrakTidakPerpanjang(): void

LiburNasional + + +

id_libur tanggal_libur keterangan

+ + + + + + +

modMembuatLiburNasional(): void modMelihatLiburNasional(): void modGetLiburNasional(): void modMengubahLiburNasional(): void modMenghapusLiburNasional(): void modTanggalLibur(): void tglIndo(): void

Gambar 6. Diagram Kelas Model Level Implementasi


Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer class Controller

CI_Controller

PengelolaanKontrakTidakPerpanjang + _construct(): void + tidakPerpanjangKontrak(): void + hapusKontrakTidakPerpanjang(): void

Autentikasi + + + + + +

_construct(): void index(): void login(): void logout(): void kunci_layar(): void unlock(): void

Early Warning + + + + +

index(): void cariKaryawanyangAkanHabisKontrak(): void mengirimPeringatanAbsensiJamKeluar(): void mengirimPeringatanKontrak(): void faq(): void

PengelolaanPengguna + + + + + + + + +

_construct(): void index(): void menambahPengguna(): void melihatPengguna(): void mengubahPengguna(): void menghapusPengguna(): void mengirimUsernamePassword(): void manajemenAkun(): void ubahPassword(): void

Pengelolaan Karyawan Kontrak + + + + + + + + +

PengelolaanPenerimaPeringatan + + + + + +

_construct(): void index(): void membuatPenerimaPeringatan(): void melihatPenerimaPeringatan(): void mengubahPenerimaPeringatan(): void menghapusPenerimaPeringatan(): void

_construct(): void index(): void memanggilWebServiceMelihatKaryawanKontrak(): void memanggilWebServiceMengubahKaryawanKontrak(): void memanggilWebServicePerpanjangKontrak(): void DateToIndo(): void cetakKontrak(): void cetakEvaluasi(): void terbilang(): void

PengelolaanLiburNasional

PengelolaanCuti + + + + +

_Construct(): void index(): void menghitungWaktuCuti(): void mencetakFormCuti(): void DateToIndo(): void

+ + + + + +

_construct(): void index(): void menambahLiburNasional(): void melihatLiburNasional(): void mengubahLiburNasional(): void menghapusLiburNasional(): void

Gambar 7. Diagram Kelas Controller Level Implementasi

6. IMPLEMENTASI Implementasi program memaparkan interaksi pengguna dengan komponenkomponen dari sistem yang dikembangkan. Sistem berbasis web sehingga dapat dijalankan pada semua komputer yang ada dalam perusahaan selama komputer tersebut berada dalam jaringan perusahaan. Berikut adalah tampilan antarmuka program .

Gambar 8. Antarmuka Sistem

7. PENGUJIAN Pengujian dalam penelitian ini terdiri dari 3 jenis pengujian, yaitu pengujian white-box, pengujian black-box, dan pengukuran kualitas kebutuhan yang didapat dari penggunaan pendekatan kolaboratif athena pada fase elisitasi kebutuhan. 7.1 Hasil Pengujian White-box Berdasarkan hasil pengujian white box menggunakan metode basis path terhadap 5 fitur utama pada sistem, yaitu mengirim peringatan kontrak, mengirim peringatan tidak ada absensi jam keluar, membuat penerima peringatan, mengubah penerima peringatan, dan memperpanjang kontrak. Pada tiap-tiap algoritmanya menghasilkan hasil pengujian jalur independen yaitu 100% valid.


1186

7.2 Hasil Pengujian Black-box Pengujian Black-box dilakukan dengan menggunakan 2 teknik pengujian yaitu teknik pengujian kelas ekuivalen dan teknik kebutuhan. Berdasarkan hasil pengujian black box dengan menggunakan teknik kelas ekuivalen dan teknik kebutuhan, maka didapatkan total kasus uji sebanyak 49 kasus uji yang dilakukan pada sistem. Berdasarkan total kasus uji tersebut, seluruh kasus uji yang didefinisikan telah berjalan dengan valid atau sukses. Hal ini mengindikasikan bahwa pengujian black box yang dilakukan terhadap sistem menghasilkan nilai pengujian sebesar 100% dan melalui traceability matrix mengindikasikan bahwa seluruh spesifikasi kebutuhan perangkat lunak yang telah didefinisikan pada tahap sebelumnya telah terpenuhi. 7.3 Hasil Pengukuran Requirement Metric Pengukuran menggunakan requirement metrics dilakukan dengan 8 metrics yaitu unambiguous metric, completeness metric, correct metric, consistent metric, uniqueness metric, understandable metric, modifiable metric, dan traced metric. Berdasarkan pengukuran yang telah dilakukan dengan 8 mteric tersebut hasil kualitas dokumentasi kebutuhan perangkat lunak telah memenuhi standar pengukuran requirement metric dari 8 metric. 8. KESIMPULAN Berdasarkan hasil penelitian skripsi yang telah dilakukan maka dapat ditarik kesimpulan sebagai berikut: 1. Proses rekayasa kebutuhan perangkat lunak dengan menerapkan pendekatan kolaboratif Athena berhasil menganalisa 24 kebutuhan dari seluruh total kebutuhan sistem yang berjumlah 26 kebutuhan yang terdiri dari 23 kebutuhan fungsional dan 3 kebutuhan non-fungsional. Kebutuhan yang dihasilkan dengan menerapkan pendekatan kolaboratif athena terdiri dari 21 kebutuhan fungsional dan 3 kebutuhan non-fungsional. 2. Sistem peringatan dini yang telah dibangun menghasilkan 23 fitur yang dapat digunakan oleh PT. Surya Optima Nusa Raya. 3. Berdasarkan hasil pengujian white box menggunakan metode basis path terhadap


5 fitur utama pada sistem, pada tiap-tiap algoritmanya menghasilkan hasil pengujian jalur independen yaitu 100% valid. Lalu, berdasarkan pengujian black box menggunakan teknik kelas ekuivalen dan teknik kebutuhan dengan total kasus uji sebanyak 49 kasus uji terhadap fiturfitur fungsional yang ada pada sistem menghasilkan hasil pengujian yaitu 100% valid. 4. Berdasarkan hasil pengukuran requirement metrics, hasil kualitas dokumentasi kebutuhan perangkat lunak telah memenuhi standar pengukuran requirement metric dari 8 metric yang digunakan dalam pengujian. DAFTAR PUSTAKA Azadegan, A., Papamichail, K.N., Sampaio, P., 2013. Applying collaborative process design to user requirements elicitation: A case study. Computer in Industry 64, pp. 798-812. Bashir, M. M. G. N. B. & Salam, R. A., 2015. Tacit Requirements Elicitation Framework. ARPN Journal of Engineering and Applied Sciences, pp. 572-578. Boulila, N., Hoffmann, A., Herrmann, A., 2011. Using Storytelling to Record Requirements: Element for an Effective Requirements Elicitation Approach. [online] Tersedia di: [Diakses 2 Juni 2017] Bider, I., 2012. Knowledge Transformation in Software Development Processes. Knowledge Transformation in Software Development Processes, pp. 1-3. Chikh, A., 2011. A Knowledge Management Framework in Software Requirements Engineering Based on the SECI Model. Journal of Software Engineering and Applications, pp. 718-728. Haleem, M., Beg, M.R., Ahmad, S.F., 2013. Overview of Impact of Requirement Metrics in Software Development Environment. International Journal of Advanced Research in Computer Engineering & Technology Hull, E., Jackson, K., Dick, J., 2010. Requirements Engineering. 3rd Ed. London: Springer.


1187

Khan, M.E., 2011. Different Approaches to Black Box Testing Technique For Finding Errors. International Journal of Software Engineering & Applications (IJSEA), pp.31-40. Laporti, V., Borges, M. R. S. & Braganholo, V. P., 2007. A Collaborative Approach to Requirements Elicitation. Proceedings of the International Conference on Computer Supported Cooperative Work in Design, pp. 734-739. Laporti, V., Borges, M. R. & Braganholo, V., 2009. Athena: A collaborative approach to requirements elicitation. Computers in Industry, pp. 367-380. Microsoft, 2008. Task Scheduler Overview. [online] Tersedia di: [Diakses 31 Januari 2017] Mulyanto, A.R., 2008. Rekayasa Perangkat Lunak. Jilid 1. Jakarta : Direktorat Pembinaan Sekolah Menengah Kejuruan, Direktorat Jenderal Manajemen Pendidikan Dasar dan Menengah, Departemen Pendidikan Nasional. Pacheco, C. & Garcia, I., 2012. A systematic literature review of stakeholder identification methods in requirements elicitation. The Journal of Systems and Software, pp. 2171-2181. Pressman, R.S., 2010. Rekayasa Perangkat Lunak: Pendekatan Praktisi, jilid 7. Diterjemahkan oleh Adi Nugroho. 2012. Yogyakarta : Andi. Rumbaugh, J., Jacobson, I., Booch, G., 1999. The Unified Modeling Language Reference Manual. California: AddisonWesley. Saputra, A., 2011. Trik Kolaborasi Codeigniter dan Jquery. Yogyakarta: Lokomedia. Siahaan, D., 2012. Analisa Kebutuhan dalam Rekayasa Perangkat Lunak. Yogyakarta : Andi. Sommerville, I., 2007. Software Engineering. 8th ed. New York: McGraw-Hill. Sukamto, R.A., Shalahuddin, M., 2013. Rekayasa Perangkat Lunak: Terstruktur dan Berorientasi Objek. Bandung: Informatika

Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer e-issn: X

Recommend Documents