Manajemen Kualitas TI

Transkripsi

1 2013 Manajemen Kualitas TI [KORELASI KEBUTUHAN FUNGSIONAL DAN NON FUNGSIONAL DENGAN TEORI SOFTWARE QUALITY MCCALL] Merupakan sebuah gambaran penilaian terhadap kualitas software, dengan menggunakan prinsip kualitas software pada teori McCall.

2 JUDUL TUGAS AKHIR RANCANG BANGUN PERANGKAT LUNAK SISTEM MONITORING TUGAS AKHIR (TA) UNTUK PENGEMBANGAN SISTEM INFORMASI TERINTEGRASI SESUAI KEBUTUHAN PENGISIAN BORANG AKREDITASI BAN-PT PADA JURUSAN SISTEM INFORMASI ITS 1

3 NAMA KELOMPOK Nanda F Nugraha Yan Azmi Edo Arizanur

4 CONTENTS JUDUL TUGAS AKHIR... 1 Nama Kelompok... 2 List Kebutuhan... 4 Fungsional... 4 Non-Fungsional... 4 Penjabaran 11 Faktor Mc Call... 6 Pembahasan Aspek Fungsional... 7 Pembahasan Aspek non-fungsional Kesimpulan

5 LIST KEBUTUHAN FUNGSIONAL KF-01 Sistem dapat mengakomodasi proses pendaftaran sidang tugas akhir. KF-02 Sistem dapat digunakan untuk melakukan penjadwalan sidang. KF-03 Sistem dapat digunakan untuk melakukan perekaman berita acara sidang. KF-04 Sistem dapat menampilkan informasi tugas akhir pribadi dari masing masing mahasiswa seperti jadwal, berita acara, lama waktu sidang, dan jumlah bimbingan yang telah dilakukan. KF-05 Sistem dapat mengakomodasi proses pembimbingan tugas akhir. KF-06 Sistem dapat menghasilkan rekap data meliputi rekap rata-rata lama TA per periode, rekap jumlah rata-rata jumlah mahasiswa bimbingan per periode. KF-07 Sistem dapat menghasilkan rekap data berita acara tugas akhir mulai dari sidang proposal hingga sidang final. KF-08 Sistem dapat sebagai media pengumuman terkait proses tugas akhir. KF-09 Sistem dapat digunakan untuk melakukan upload file terkait panduan tigas akhir. KF-10 Sistem dapat digunakan untuk melakukan pengelolaan tanggal terkait yudisium. NON-FUNGSIONAL Reability and up-time Requirement 1. Sistem harus dapat beroperasi selama hari kerja khususnya pada saat dibutuhkan oleh user. 2. Sistem bisa diakses oleh banyak pengguna secara bersamaan. 4

6 Safety Requirement 1. Sistem menyediakan 4 jenis login yang berbeda yaitu dosen, koordinator PPM, koordinator kerjasama, dan mahasiswa. 2. Tiap-tiap aktor atau pengguna memiliki hak akses yang berbeda beda sesuai dengan kebutuhan dan fungsinya masing masing 5

7 PENJABARAN 11 FAKTOR MC CALL 6

8 PEMBAHASAN ASPEK FUNGSIONAL Aspek Mccall Kebutuhan fungsional Uraian dan bukti testing yang telah dilakukan Correctness Kf-01 Sistem dapat mengakomodasi proses pendaftaran sidang tugas akhir. 1. Sistem dapat mengakomodasi proses pendaftaran sidang tugas akhir, yang diawali dengan pendaftaran sidang proposal, sidang progres, hingga sidang akhir tugas akhir. 7

9 (gambar 1 s/d 4) 8

10 Kf-02 Sistem dapat digunakan untuk melakukan penjadwalan sidang 2. Sistem dapat digunakan untuk melakukan penjadwalan sidang akhir, list kelola jadwal sidang, melihat detail jadwal sidang dan melihat jadwal sidang tugas akhir. (gambar 5 s/d 7) 9

11 Kf-03 Sistem dapat digunakan untuk melakukan perekaman berita acara sidang 3. Sistem dapat digunakan untuk melakukan perekaman berita acara sidang, dari penanggung jawab lab (gambar 8 s/d 9) 10

12 Kf-04 Sistem dapat menampilkan informasi tugas akhir pribadi dari masing masing mahasiswa seperti jadwal, berita acara, lama waktu sidang, dan jumlah bimbingan yang telah dilakukan 4. Sistem dapat menampilkan informasi pribadi dari mahasiswa seperti : jadwal, berita acara, jumlah bimbingan, dan waktu sidang. Kf-05 Sistem dapat mengakomodasi proses pembimbingan tugas akhir 5. Sistem dapat mengakomodir segala kepentingan mahasiswa dalam proses bimbingan tugas akhir, seperti dalam meng-upload dan download tugas akhir Kf-06 Sistem dapat menghasilkan rekap data meliputi rekap rata-rata lama TA per periode, rekap jumlah rata-rata jumlah mahasiswa bimbingan per periode. 6. Sistem dapat menampilkan rekap rata rata mahasiswa yang melakukan bimbingan TA per periode. 11

13 Kf-07 Sistem dapat menghasilkan rekap data berita acara tugas akhir mulai dari sidang proposal hingga sidang final. 7. Sistem dapat memperlihatkan keseluruhan berita acara yang telah ada pada pada saat proses awal pada pelaksanaan siding proposal hingga siding akhir. Kf-08 Sistem dapat sebagai media pengumuman terkait proses tugas akhir. 8. Pada penjelasan ini, seharusnya sudah tidak usah diragukan lagi, hal tersebut dikarenakan, semua list yang seharusnya ada dalam setiap pengerjaan Tugas Akhir sudah ada. Kf-09 Sistem dapat digunakan untuk melakukan upload file terkait panduan tigas 9. Kegiatan mengupload file panduan Tugas akhir terdapat pada system, dan berikut merupakan testingnya. 12

14 akhir. Kf-10 Sistem dapat digunakan untuk melakukan pengelolaan tanggal terkait yudisium. 10. Pengelolaan tanggal untuk yudisium merupakan salah satu hal yang penting, sehingga dalam pengaplikasiannya harus memiliki patokan yang jelas, sehingga keseluruhannya dapat dilihat pada : Reliability Kf-04 Sistem dapat menampilkan informasi tugas akhir pribadi dari masing masing mahasiswa seperti jadwal, berita acara, lama waktu sidang, dan jumlah bimbingan yang telah dilakukan Sistem dapat memfasilitasi kebutahan, mahasiswa dari segala keperluan dalam menyiapkan tugas akhir seperti jadwal tugas akhir, pencatatan berita acara, lama waktu sidang dan jumlah bimbingan yang di lakukan 13

15 Effisiensi Kf-05 Sistem dapat mengakomodasi proses pembimbingan tugas akhir Sistem dikatakan effisiensi karena, semua fungsi yang ada telah disesuaikan dengan kebutuhan-kebutuhan yang diperlukan untuk tujuan proses bisnis. 14

16 Integrity Tidak di jelaskan pada studi kasus - Usability Tidak di Jelaskan pada studi kasus - 15

17 Maintainibility Seluruh kebutuhan Fungsional yang ada, telah diberikan test case di dalam lampiran, Setiap kebutuhan fungsional telah diberikan sebuah dokumen test case, sehingga kedepan bisa dengan mudah mendeteksi sebuah permasalahan. Flexibility Seluruh Kebutuhan Fungsional Salah satu ciri bahwa system tersebut memiliki sifat flexibilitas adalah dibuktikan dengan test yang pernah mengenainya, sehingga dengan adanya dokumen test case dapat memberikan sisi fleksibel dari system tersebut untul pengaplikasiannya, apakah mau dirubah ataukah tetap. 16

18 Testability Seluruh Kebutuhan Fungsional telah dilakukan testing. Sistem ini telah diuji dengan melakukan testing disetiap kebutuhan fungsionalnya. Portability Tidak dijelaskan pada studi kasus untuk kebutuhan fungsionalitas - Reusability Tidak dijelaskan pada studi kasusu untuk kebutuhan fungsionalitas. - Interoperability Tidak dijelaskan pada sistem kebutuhan fungsionalitas. - 17

19 PEMBAHASAN ASPEK NON-FUNGSIONAL Faktor McCall Kebutuhan Non-Fungsional Uraian dan bukti testing yang telah dilakukan Correctness Reability and up-time Requirement 1. Sistem harus dapat beroperasi selama hari kerja khususnya pada saat dibutuhkan oleh user. 2. Sistem bisa diakses oleh banyak pengguna secara bersamaan. Safety Requirement 1. Sistem menyediakan 4 jenis login yang berbeda yaitu dosen, koordinator PPM, koordinator kerjasama, dan mahasiswa. 2. Tiap-tiap aktor atau pengguna memiliki hak akses yang berbeda beda sesuai dengan kebutuhan dan fungsinya masing masing Tidak ada dokumen testing yang digunakan untuk melakukan testing pada kebutuhan non fungsional. Reliability Reability and up-time Requirement 1. Sistem harus dapat beroperasi selama hari kerja khususnya pada saat dibutuhkan oleh user. Tidak ada dokumen testing yang digunakan untuk melakukan testing pada kebutuhan non fungsional. 18

20 2. Sistem bisa diakses oleh banyak pengguna secara bersamaan. Safety Requirement 1. Sistem menyediakan 4 jenis login yang berbeda yaitu dosen, koordinator PPM, koordinator kerjasama, dan mahasiswa. 2. Tiap-tiap aktor atau pengguna memiliki hak akses yang berbeda beda sesuai dengan kebutuhan dan fungsinya masing masing Efficiency Reability and up-time Requirement 1. Sistem harus dapat beroperasi selama hari kerja khususnya pada saat dibutuhkan oleh user. 2. Sistem bisa diakses oleh banyak pengguna secara bersamaan. Safety Requirement 1. Sistem menyediakan 4 jenis login yang berbeda yaitu dosen, koordinator PPM, koordinator kerjasama, dan mahasiswa. 2. Tiap-tiap aktor atau pengguna Tidak ada dokumen testing yang digunakan untuk melakukan testing pada kebutuhan non fungsional. 19

21 memiliki hak akses yang berbeda beda sesuai dengan kebutuhan dan fungsinya masing masing Integrity Reability and up-time Requirement 1. Sistem harus dapat beroperasi selama hari kerja khususnya pada saat dibutuhkan oleh user. 2. Sistem bisa diakses oleh banyak pengguna secara bersamaan. Safety Requirement 1. Sistem menyediakan 4 jenis login yang berbeda yaitu dosen, koordinator PPM, koordinator kerjasama, dan mahasiswa. 2. Tiap-tiap aktor atau pengguna memiliki hak akses yang berbeda beda sesuai dengan kebutuhan dan fungsinya masing masing Tidak ada dokumen testing yang digunakan untuk melakukan testing pada kebutuhan non fungsional. Usability Reability and up-time Requirement 1. Sistem harus dapat beroperasi selama hari kerja khususnya pada saat Tidak ada dokumen testing yang digunakan untuk melakukan testing pada kebutuhan non fungsional. 20

22 dibutuhkan oleh user. 2. Sistem bisa diakses oleh banyak pengguna secara bersamaan. Safety Requirement 1. Sistem menyediakan 4 jenis login yang berbeda yaitu dosen, koordinator PPM, koordinator kerjasama, dan mahasiswa. 2. Tiap-tiap aktor atau pengguna memiliki hak akses yang berbeda beda sesuai dengan kebutuhan dan fungsinya masing masing Maintainibility Reability and up-time Requirement 1. Sistem harus dapat beroperasi selama hari kerja khususnya pada saat dibutuhkan oleh user. 2. Sistem bisa diakses oleh banyak pengguna secara bersamaan. Safety Requirement 1. Sistem menyediakan 4 jenis login yang berbeda yaitu dosen, koordinator PPM, koordinator kerjasama, dan Tidak ada dokumen testing yang digunakan untuk melakukan testing pada kebutuhan non fungsional. 21

23 mahasiswa. 2. Tiap-tiap aktor atau pengguna memiliki hak akses yang berbeda beda sesuai dengan kebutuhan dan fungsinya masing masing Flexibility Reability and up-time Requirement 1. Sistem harus dapat beroperasi selama hari kerja khususnya pada saat dibutuhkan oleh user. 2. Sistem bisa diakses oleh banyak pengguna secara bersamaan. Safety Requirement 1. Sistem menyediakan 4 jenis login yang berbeda yaitu dosen, koordinator PPM, koordinator kerjasama, dan mahasiswa. 2. Tiap-tiap aktor atau pengguna memiliki hak akses yang berbeda beda sesuai dengan kebutuhan dan fungsinya masing masing Tidak ada dokumen testing yang digunakan untuk melakukan testing pada kebutuhan non fungsional. 22

24 Testability Reability and up-time Requirement 1. Sistem harus dapat beroperasi selama hari kerja khususnya pada saat dibutuhkan oleh user. 2. Sistem bisa diakses oleh banyak pengguna secara bersamaan. Safety Requirement 1. Sistem menyediakan 4 jenis login yang berbeda yaitu dosen, koordinator PPM, koordinator kerjasama, dan mahasiswa. 2. Tiap-tiap aktor atau pengguna memiliki hak akses yang berbeda beda sesuai dengan kebutuhan dan fungsinya masing masing Tidak ada dokumen testing yang digunakan untuk melakukan testing pada kebutuhan non fungsional. Portability Reability and up-time Requirement 1. Sistem harus dapat beroperasi selama hari kerja khususnya pada saat dibutuhkan oleh user. 2. Sistem bisa diakses oleh banyak pengguna secara bersamaan. Tidak ada dokumen testing yang digunakan untuk melakukan testing pada kebutuhan non fungsional. 23

25 Safety Requirement 1. Sistem menyediakan 4 jenis login yang berbeda yaitu dosen, koordinator PPM, koordinator kerjasama, dan mahasiswa. 2. Tiap-tiap aktor atau pengguna memiliki hak akses yang berbeda beda sesuai dengan kebutuhan dan fungsinya masing masing Reusability Reability and up-time Requirement 1. Sistem harus dapat beroperasi selama hari kerja khususnya pada saat dibutuhkan oleh user. 2. Sistem bisa diakses oleh banyak pengguna secara bersamaan. Safety Requirement 1. Sistem menyediakan 4 jenis login yang berbeda yaitu dosen, koordinator PPM, koordinator kerjasama, dan mahasiswa. 2. Tiap-tiap aktor atau pengguna memiliki hak akses yang berbeda beda sesuai dengan kebutuhan dan Tidak ada dokumen testing yang digunakan untuk melakukan testing pada kebutuhan non fungsional. 24

26 fungsinya masing masing Interoperability Reability and up-time Requirement 1. Sistem harus dapat beroperasi selama hari kerja khususnya pada saat dibutuhkan oleh user. Tidak ada dokumen testing yang digunakan untuk melakukan testing pada kebutuhan non fungsional. 2. Sistem bisa diakses oleh banyak pengguna secara bersamaan. Safety Requirement 1. Sistem menyediakan 4 jenis login yang berbeda yaitu dosen, koordinator PPM, koordinator kerjasama, dan mahasiswa. 2. Tiap-tiap aktor atau pengguna memiliki hak akses yang berbeda beda sesuai dengan kebutuhan dan fungsinya masing masing 25

27 KESIMPULAN Melihat beberapa pertimbangan yang ada, dilihat dari kurangnya korelasi antara factor software quality dengan masing masing keutuhan, bahkan tidak ada testing yang dilakukan untuk melihat kesesuaian kebutuhan non-fungsional, sehingga : RANCANG BANGUN PERANGKAT LUNAK SISTEM MONITORING TUGAS AKHIR (TA) UNTUK PENGEMBANGAN SISTEM INFORMASI TERINTEGRASI SESUAI KEBUTUHAN PENGISIAN BORANG AKREDITASI BAN-PT PADA JURUSAN SISTEM INFORMASI ITS Belum memiliki kualitas yang maksimal. 26

28 27