Manajemen Kualitas TI

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.

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

Tugas Manajemen Kualitas TI

1

NAMA KELOMPOK Nanda F Nugraha

5209100030

Yan Azmi Edo Arizanur

5210100140


2

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 ...................................................................................................................................................................................................................... 18 Kesimpulan ............................................................................................................................................................................................................................................................. 26


3

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

 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

PENJABARAN 11 FAKTOR MC CALL


6

PEMBAHASAN ASPEK FUNGSIONAL

Aspek Mccall Correctness

Kebutuhan fungsional Kf-01 Sistem dapat mengakomodasi proses pendaftaran sidang tugas akhir.


Uraian dan bukti testing yang telah dilakukan 1. Sistem dapat mengakomodasi proses pendaftaran sidang tugas akhir, yang diawali dengan pendaftaran sidang proposal, sidang progres, hingga sidang akhir tugas akhir.

7

(gambar 1 s/d 4)


8

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

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

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.


4. Sistem dapat menampilkan informasi pribadi dari mahasiswa seperti : jadwal, berita acara, jumlah bimbingan, dan waktu sidang.

5. Sistem dapat mengakomodir segala kepentingan mahasiswa dalam proses bimbingan tugas akhir, seperti dalam meng-upload dan download tugas akhir

6.

Sistem dapat menampilkan rekap rata rata mahasiswa yang melakukan bimbingan TA per periode.

11

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


7.

Sistem dapat memperlihatkan keseluruhan berita acara yang telah ada pada pada saat proses awal pada pelaksanaan siding proposal hingga siding 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.

9.

Kegiatan mengupload file panduan Tugas akhir terdapat pada system, dan berikut merupakan testingnya.

12

akhir.

Reliability

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 :

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

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

Integrity

Tidak di jelaskan pada studi kasus

-

Usability

Tidak di Jelaskan pada studi kasus

-


15

Maintainibility

Flexibility

Seluruh kebutuhan Fungsional yang ada, telah diberikan test case di dalam lampiran,

Seluruh Kebutuhan Fungsional


Setiap kebutuhan fungsional telah diberikan sebuah dokumen test case, sehingga kedepan bisa dengan mudah mendeteksi sebuah permasalahan.

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

Testability

Seluruh Kebutuhan Fungsional telah dilakukan testing.

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.

-


Sistem ini telah diuji dengan melakukan testing disetiap kebutuhan fungsionalnya.

17

PEMBAHASAN ASPEK NON-FUNGSIONAL Faktor McCall

Kebutuhan Non-Fungsional  Reability and up-time Requirement

Correctness

1. Sistem harus dapat beroperasi selama hari kerja khususnya pada saat dibutuhkan oleh user.

Uraian dan bukti testing yang telah dilakukan 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

 Reability and up-time Requirement

Reliability



Tidak ada dokumen testing yang digunakan untuk melakukan testing pada kebutuhan non fungsional.

18



Efficiency



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


19

memiliki hak akses yang berbeda beda sesuai dengan kebutuhan dan fungsinya masing masing


Integrity


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


Usability

1. Sistem harus dapat beroperasi selama hari kerja khususnya pada saat



20

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



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


21

mahasiswa. 2. Tiap-tiap aktor atau pengguna memiliki hak akses yang berbeda beda sesuai dengan kebutuhan dan fungsinya masing masing


Flexibility





22


Testability





Portability



2. Sistem bisa diakses oleh banyak pengguna secara bersamaan.


23

 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



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


24

fungsinya masing masing


Interoperability





25

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 TERINTEGRASI SESUAI KEBUTUHAN PENGISIAN BORANG AKREDITASI BAN-PT PADA JURUSAN SISTEM INFORMASI ITS

PENGEMBANGAN

SISTEM

INFORMASI

Belum memiliki kualitas yang maksimal.


26


27

Manajemen Kualitas TI

Recommend Documents