Abstrak —  Untuk  melakukan  evaluasi  dan  pelaporan Tri  Dharma  Perguruan  Tinggi,  ITS  telah  memiliki  Sistem Informasi  Terintegrasi Self  Assessment  Report sehingga  bisa menunjang realisasi Rencana Strategis (Restra) yang dijabarkan dalam  Tujuan  Strategis  Bidang  Akademik,  Bidang  Penelitian dan  Pengabdian  Masyarakat.  Sampai  saat  ini  ITS  hanya melakukan  evaluasi  dan  pelaporan  melalui  Sistem  Informasi Akademik Terintegrasi pada kegiatan Pendidikan dan Pengajaran  saja,  yaitu  dengan  SAR  Proses  Pembelajaran.  ITS juga  belum  menerapkan  alur  organisasi  yang  benar  dengan menggunakan  siklus Plan-Do-Check-Act (PDCA),  yaitu  dengan melakukan perencanaan diawal sebelum melaksanakan kegiatan kemudian melakukan kontrol terhadap apa yang dikerjakan dan selalu melakukan perbaikan untuk kedepannya. Oleh karenanya perlu  dikembangkan  lagi  sistem  tersebut  sehingga  bisa melakukan  melakukan  fungsi  evaluasi  serta  pelaporan  yang benar  dengan  menggunakan  siklus  PDCA  yang  bisa  mencakup seluruh kegiatan Tri Dharma Perguruan Tinggi di ITS.
Rencana  penelitian  ini  adalah  melakukan  analisis spesifikasi  kebutuhan  dan  desain  sistem  informasi  terintegrasi SAR untuk Tri Dharma Perguruan Tinggi dengan menggunakan metode  Prototyping.  Pada  Prototyping,  terdapat  3  tahapan pengerjaan yang dimulai dengan tahapan penggalian kebutuhan, analisis dan desain sistem, dan validasi.
Hasil  akhir  yang  didapatkan  dari  tugas  akhir  ini  yaitu dokumen  spesifikasi  kebutuhan  dan  desain  sistem  informasi terintegrasi  SAR  Tri  Dharma  PErguruan  Tinggi  yang disesuaikan  dengan  standart  ReadySet.  Diharapkan  nantinya dapat digunakan sebagai acuan programmer dalam mengembangkan  Sistem  Informasi    Terintegrasi  SAR  Tri Dharma Perguruan Tinggi lebih lanjut.
Kata  Kunci — Tri  Dharma  Perguruan  Tinggi, Self  Assessment Report , Siklus PDCA, Prototyping Model , ReadySet .

## I. PENDAHULUAN
ri  Dharma  Perguruan  Tinggi  yang  terdiri  dari  Pendidikan dan  Pengajaran,  Penelitian  dan  Pengembangan,  serta Pengabdian  kepada  Masyarakat  adalah  tugas  pokok Perguruan  Tinggi  di  Indonesia  dalam  menyelenggarakan sistem  pendidikan  Nasional  [ 1 ].  Untuk  itu  Institut  Teknologi Sepuluh  Nopember  (ITS)  telah  membuat  Rencana  Strategis (Restra)  dalam  melaksanakan  tugas  tersebut  yang  dijabarkan dalam Tujuan Strategis Bidang Akademik, Bidang Penelitian, dan  Pengabdian  Masyarakat  [ 2 ],  sehingga  ITS  mampu memenuhi seluruh pencapaian kegiatan Tri Dharma Perguruan Tinggi tersebut
Hal  ini  di  dukung  dalam  undang-undang  Republik Indonesia nomor 12 tahun 2012 tentang pendidikan tinggi. Di undang-undang  tersebut  terdapat  11  pasal  yang  menyebutkan berbagai  penjelasan  tentang  kewajiban,  manfaat,  standart, serta peran dan fungsi penyelenggaraan Tri Dharma Perguruan Tinggi  yang  harus  dilakukan  oleh  perguruan  tinggi  (UU-RI, 2012).  Untuk  itu  diperlukan  adanya  evaluasi  dan  pelaporan supaya ketiga sasaran Tri Dharma Perguruan Tinggi terpenuhi. Demi  mencapai  tiga  sasaran  tersebut  perlu  ditunjang  adanya sistem  informasi  terintegrasi  yang  bisa  digunakan  untuk mengevaluasi dan melaporkan secara mandiri (self assessment report),  berkesinambungan  (substain)  dan  berjenjang  dari ketiga tugas Tri Dharma Perguruan Tinggi tersebut [ 3 ]. Mulai tahun 2009 sampai saat ini, ITS telah melakukan evaluasi dan pelaporan  melalui  Sistem  Informasi  Akademik  Terintegrasi yang  hanya  pada  kegiatan  Pendidikan  dan  Pengajaran,  yaitu dengan  SAR  Proses  Pembelajaran  [ 4 ],  oleh  karenanya  perlu dikembangkan  lagi  sistem  tersebut  sehingga  bisa  mencakup seluruh  kegiatan  Tri  Dharma  Perguruan  Tinggi  ITS  [ 5 ]. Pada saat ini sistem terintegrasi Tri Dharma Perguruan Tinggi yang sudah  ada  yaitu  tentang  Pendidikan  dan  Pengajaran  belum menerapkan alur organisasi  yang benar dengan  menggunakan siklus  PDCA,  yang  artinya  semua  kegiatan  organisasi  dalam upaya  meningkatkan  kinerja  mutu  secara  berkesinambungan harus  dilakukan  Perencanaan  (Plan),  Pelaksanaan  (Do), Pengendalian  (Control),  dan  Perbaikan  (Action)  secara berulang ulang.
Seharusnya  alur  organisasi  yang  benar  dapat  di terapkan dalam sistem atau fungsi evaluasi dan pelaporan ini. Dengan  mmperhatikan  siklus  PDCA,  dosen  atau  pengajar selaku  orang  yang  menggunakansistem  ini  mampu  membuat perencanaan diawal sebelum melaksanakan kegiatan kemudian  melakukan  kontrol  terhadap  apa  yang  dikerjakan dan selalu melakukan perbaikan-perbaikan untuk kedepannya. Sehingga  evaluasi  tidak  hanya  dilakukan  diakhir  tetapi evaluasi  bisa  dilakukan  di  awal,  di  tengah,  maupun  di  akhir. Setelah  memperhatikan  alur  organisasi  yang  benar  dengan menerapkan  siklus  PDCA,  penggunaan  fungsi  evaluasi  dan pelaporan  melalui  Sistem  Informasi  Akademik  Terintegrasi pada  Tri  Dharma  Perguruan  Tinggi  dapat  di  optimalkan  dan diterapkan tidak hanya pada satu bidang saja namun pada tiga bidangnya  yaiutu  Pendidikan  dan  Pengajaran,  Penelitian  dan Pengembangan, dan Pengabdian Masyarakat. Dengan demikian  evaluasi  dan  pelaporan  bisa  dilakukan  secara maksimal  terhadap  seluruh  kegiatan  yang  dilakukan  oleh dosen  atau  pengajar  dalam  setiap  tahun  ajaran  atau  disetiap semesternya.

## Analisis dan Desain Self Assessments Report Untuk Tri Dharma Perguruan Tinggi pada Institut Teknologi Sepuluh Nopember Surabaya
Andrew Apriyan Dewantara, Sholiq, dan Mudjahidin Jurusan Sistem Informasi, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember (ITS)
Jl. Arief Rahman Hakim, Surabaya 60111 Indonesia e-mail : sholiq99@yahoo.com, mudjahidin.its@gmail.com
T
Untuk  bisa  mengembangkan  sistem  informasi  terintegrasi Tri  Dharma  Perguruan  Tinggi,  maka  dalam  pengerjaan  tugas akhir  ini  akan  dilakukan  analisis  spesifikasi  kebutuhan  dan desain  sistem  informasi  terintegrasi  SAR  Tri  Dharma Perguruan  Tinggi.  Metode  pengerjaan  tugas  akhir  ini menggunakan Prototyping Model yang  terdapat  3  tahapan pengerjaan  dimulai  dengan  tahapan  penggalian  kebutuhan, analisis dan desain sistem, dan validasi. Hasil dari keseluruhan berupa  dokumen  spesifikasi  kebutuhan  dan  desain  sistem sebagai  acuan  programmer  dalam  mengembangkan  sistem informasi  lebih  lanjut.  Dokumentasi  studi  kebutuhan  dan desain  menggunakan  standart  ReadySet,  serta  pemakaian Enterprise  Architect  (EA)  sebagai  tools  untuk  membuat Unified  Modeling  Language  (UML),  Sybase  Power  Designer untuk mendesain basis data, dan pemakaian Gui Design Studio dalam mendesain sistem.

## II. METODOLOGI PENELITIAN
Analisis
Desain Validasi Selesai Ya Tidak Prototyping Penggalian kebutuhan

## Gambar 1 Metode penelitian

## A. Elisitasi
Merupakan rancangan yang dibuat berdasarkan sistem baru yang diinginkan oleh pihak manajemen terkait [ 6 ]. Melakukan penggalian  kebutuhan  untuk  keperluan  sistem  dengan  cara wawancara  terhadap  stakeholder.  Dimulai  dari  rancangan sistem  baru  yang  diusulkan  oleh  pihak  stakeholder  dan selanjutnya  menentukan  rancangan  sistem  yang  penting  dan harus  ada  pada  sistem.  Tahap  ini  dilakukan  hingga  sesuai dengan kebutuhan user dalam pemenuhan desain sistem

## B. Analisis dan Spesifikasi Kebutuhan.
Analisis  kebutuhan  pengguna  merupakan  aktivitas yang  dilakukan  untuk  mengetahui  apa  saja  yang  dibutuhkan oleh  pengguna  pada  perangkat  lunak  yang  akan  dibuat.  Hasil dari identifikasi kebutuhan pengguna ini akan direpresentasikan  ke  dalam  fitur  perangkat  lunak  yang  akan dibuat  serta usecase .  Pada  tahap  ini  akan  menghasilkan dokumen Target Audience & Customer Benefit, User Needs & Stories, dan Interview Notes .

## C. Verifikasi Kebutuhan
Memetakan  kebutuhan  yang  akan  digunakan  dalam melakukan  proses  desain.  Dokumen  yang  dihasilkan  akan diverifikasi apakah sesuai dengan kebutuhan yang diinginkan.

## D. Desain

## 1) Desain sistem
Desain  sistem  yang  dilakukan  pada  tahapan  ini adalah desain struktural dan desain perilaku sistem. Desain struktural  sistem  merupakan  desain  database  dengan menggunakan ERD ( Entity Relational Diagram ). Sedangkan  pada  desain  perilaku  menggunakan  UML ( Unified Modelling Language ). Pada tahap ini juga dibuat rancangan desain tampilan muka ( interface ).
2) Desain structural
Seperti yang telah dijelaskan di atas bahwa desain struktural merupakan desain database yang digunakan oleh perangkat  lunak.  Aktivitas  yang  dilakukan  pada  tahap  ini adalah memodelkan database dengan ERD, dan melakukan generate ERD  ke  dalam  bentuk  CDM  ( Conceptual Diagram  Model ),  dan  PDM  ( Physical  Diagram  Model ). Hal ini dilakukan untuk mempermudah generate ke dalam bahasa SQL ( Structured Query Language ).
3) Desain perilaku
Tahap  desain  ini  adalah  tahapan  untuk  menbuat usecase  diagram,  Sequence  Diagram,  Activity  Diagram, dan class diagram menggunakan UML

## a) Class diagram
Pada  tahap  ini  akan  digambarkan  bagaimana hubungan antar objek dan method-method apa saja yang terdapat  pada  setiap  class.  Definisi  defines  class  yang diilustrasikan pada
class diagram akan diimplementasikan pada tahap construction b)

## Usecase diagram
Usecase  diagram  berisi  gambaran  mengenai interaksi  antara  sekelompok  proses  dengan  sekelompok actor, menggambarkan fungsionalitas dari sebuah sistem yang  dibangun  dan  bagaimana  sistem  berinteraksi dengan  dunia  luar.  Usecase  diagram  dapat  digunakan selama  proses  analisis  untuk  menangkap  kebutuhan sistem  dan  untuk  memahami  bagaimana  sistem seharusnya bekerja.

## c) Sequence diagram
Sequence  Diagram  menggambarkan  interaksi antar  objek  di  dalam  dan  di  sekitar  sistem  (termasuk pengguna  display,  dan  sebagaianya)  berupa  pesan  yang disusun  dalam  suatu  urutan  waktu.  Diagram  ini menjelaskan kelas –  kelas dan objek  yang terlibat  untuk menjalankan  fungsionalitas  dari  scenario  yang  ada. Secara khusus diagram ini berasosiasi dengan usecase.

## d) Activity diagram
Activity diagram menggambarkan berbagai alur aktifitas dalam sistem yang sedang dirancang bagaimana masing-masing  alur  berawal,  decision  yang  mungkin terjadi,  dan  bagaimana  mereka  berakhir.  Activity Diagram juga dapat menggambarkan proses pararel yang mungkin terjadi pada beberapa eksekusi.

## e) Desain interface
Pada  tahapan  ini  dilakukan  rancangan  user interface  secara  deskriptif.  Hal  ini  bertujuan  untuk memudahkan  dalam  pengimplementasian  rancangan perangkat lunak.

## E. Validasi Desain
Pada  tahapan  ini  desain  yang  telah  dirancang dilakukan  validasi  dengan  tujuan  menyesuaikan  desain  yang telah  dirancang  dengan  kebutuhan  yang  diperlukan  untuk proses  pengembangan  perangkat  lunak.  Dokumen  pada  tahap sebelumnya  divalidasi  apakah  sudah  sesuai  dengan  yang diinginkan.

## III. TINJAUAN PUSTAKA
A. Self Assessment Report (SAR)
Self Assessments Report (SAR) adalah suatu kegiatan yang ditunjukkan untuk mengevaluasi kinerja dari proses yang dilakukan  oleh  dosen  terkait  dengan  tugas  Tri  Dharma Perguruan  Tinggi.  SAR  ini  diperlukan  untuk  menjamin terjadnya peningkatan  mutu proses secara berkesinambungan, serta  tercapainya  sasaran  mutu  yang  telah  ditetapkan  dalam Restra ITS 2008-2007.Tujuan akhir  yang ingin dicapai dalam SAR  adalah  menumbuhkan  kepedulian  semua  pihak  yang terkait,  untuk  melakukan  pengawasan  melekat  dan  mandiri, dalam  menerapkan  sistem  penjaminan  yang  baik,  sehingga mutu layanan jasa pendidikan meningkat secara berkesinambungan [ 4 ].
B. Tri Dharma Perguruan Tinggi
Setiap perguruan tinggi di Indonesia wajib menyelanggarakan  fungsi  Tri  Dharma  Perguruan  Tinggi meliputi 3 hal, yaitu [ 1 ]:
1. Pendidikan dan Pengajaran, meneruskan pengetahuan  atau  ilmu  pengetahuan  yang  telah dikembangkan  melalui  penelitian  oleh  mahasiswa di perguruan tinggi (transfer of knowledge).
2. Penelitian  dan  Pengembangan,  diarahkan  tidak hanya pada penelitian terapan saja, tetapi juga pada penelitian ilmu-ilmu dasar yang punya kemanfaatan di masa mendatang.
3. Pengabdian kepada Masyarakat, merupakan serangkaian  aktifitas  dalam  rangka  kontribusi perguruan tinggi terhadap masyarakat yang bersifat konkrit dan langsung dirasakan manfaatnya.

## C. Siklus Pengembangan Perangkat Lunak Dengan Prototype Model
Sebuah  desain  prototype  adalah  bagian  dari  produk yang  mengekspektasikan  logika  maupun  fisik interface eksternal yang ditampilkan. Pendekatan prototyping memungkinkan  nantinya pengguna  memberi  masukan  kepada pengembang  perangkat  lunak.  Pengguna  akan  melihat  dan memberikan  evaluasi  setiap  desain  perangkat  lunak  yang diusulkan,  proses  tersebut  terus  berkelanjutan  hingga  desain tersebut telah mencukupi kebutuhan pengguna. Berikut proses yang dilakukan dalam prototype [ 7 ].
1. Mengumpulkan  dan  menganalisis  kebutuhan perangkat lunak (Initial Requirement)
2. Melakukan perancangan cepat (Quick Design)
3. Membuat prototype
4. Evaluasi  dilakukan  oleh  pengguna  terhadap prototype (Customer evaluation)
5. Apabila  desain  tidak  sesuai  dengan  kebutuhan pengguna,  maka  prosesnya  akan  masuk  siklus iterasi  pada  langkah  berikutnya.  Apabila  telah memenuhi kebutuhan maka dapat berlanjut pada langkah berikutnya.
6. Perubahan  rancangan  dan  desain  (Review  & Update)
7. Pengembangan  perangkat  lunak  berskala  besar dapat dimulai (Development)

## Gambar 2 Proses dalam prototype model

## D. Human Computer Interaction (HCI)
HCI  atau  yang  biasa  disebut  Interaksi  Manusia  dan Komputer  (IMK)  adalah  disiplin  ilmu  pengetahuan  yang mengulas  tentang  perancangan,  evaluasi  dan  implementasi dari sistem computer interaktif terkait dengan penggunaannya oleh  manusi  beserta  hal-hal  yang  terkait  dengan  itu.  Tujuan utama  dari  IMK  adalah  menghasilkan  sistem  computer  yang mampu  digunakan  dengan  baik  oleh  pengguna  (good usability)  melalui  desain  antarmuka  dengan  memperhatikan beberapa hal penting seperti memahami factor yang membuat manusia  menggunakan  teknologi,  mengembangkan  teknik- teknik  yang  memungkinkan  untuk  membangun  sistem  yang sesuai  dengan  tujuan  serta  mencapai  interaksi  yang  aman, efektif,  dan  efisien.  Selain  desain  antarmuka,  karateristik manusia tentu saja sangat memperhatikan IMK [ 8 ].

## E. Standar Dokumentasi (ReadySET)
ReadySET merupakan  salah  satu  template  atau kumpulan  dokumentasi  untuk  rekayasa  perangkat  lunak. Pembuatan ReadySET didasarkan  pada    pengalaman  ( best practice ) dari ratusan proyek pengembangan perangkat lunak. Kelebihan  yang  dimiliki ReadySET adalah  bisa  digunakan untuk  menjaga agar  tim proyek dapat  menganalisis  kesalahan sedini mungkin dan tetap sesuai pada perencanaan [ 9 ].

## F. UML (Unified Modeling Language)
Unified  Modeling  Language  (UML)  adalah  ‘bahasa’ pemodelan  untuk  sistem  atau  perangkat  lunak  yang berparadigma  ‘berorientasi  objek’.  Pemodelan  ( modelling ) sesungguhnya digunakan untuk penyederhanaan permasalahan-permasalahan  yang  kompleks  sedemikian  rupa sehingga lebih mudah dipelajari dan dipahami.
1) Use-case Diagram Use case diagram dapat digunakan selama proses analisis  untuk  menangkap  kebutuhan  sistem  dan  untuk memahami  bagaimana  sistem  seharusnya  bekerja  [ 10 ]. Pada  diagram Use  case ,  orang  –  orang  atau  sistem  yang berinteraksi  dengan  sistem  target  dinamakan actors , sedangakan fitur yang digunakan oleh actor disebut dengan Use  case .  Antara Use  case satu  dengan Use  case lainnya dapat memiliki hubungan yang dihubungkan dengan panah ketergantungan ( dependency arrow ). Tujuan dari Use case adalah  untuk  menggambarkan  fitur  apa  saja  yang diinginkan  Pengguna  namun  tidak  mengungkapkan  secara detail bagaimana fitur tersebut diimplementasikan [ 11 ].
2) Activity Diagram
Activity  diagram  memodelkan  alur  logika  dari Use case yang dibuat pada Use case diagram pada metode – metode yang mendukung Use case tersebut [ 11 ]. Activity diagram meminjam banyak notasi dari Flowchart diagram, namun menambahkan konsep konkurensi untuk mendukung  banyak  aplikasi  modern. Activity  diagram dinilai penting karena beberapa alasan berikut:
a. Merepresentasikan kebutuhan logika tentrang perilaku sistem
b. Merepresentasikan  logika  dari  berbagai  level  desain, dari  sebuah  alur  sistem  menjadi  metode  –  metode individual
c. Mudah untuk dimengerti
d. Sangat  familiar  bagi  pengguna  yang  telah  biasa mengikuti pelatihan bisnis ataupun membaca manual dari prosedur.
3) Class Diagram
Class  Diagram memodelkan  sumber  daya  yang essential secara tepat pada sistem yang ingin dibangun.Diagram lainnya mendefinisikan tentang sumber daya  seperti  nilai  atribut,    kedaaan,  batasan  pada  perilaku yang  harus  dipetakan  ke  dalam Class  Diagram . Class Diagram
merupakan sumber rujukan dalam mengembangkan kode aplikasi perangkat lunak [ 11 ]. 4) Sequence Diagram Sequence  diagram menggambarkan  interaksi antar  objek  di  dalam  dan  di  sekitar  sistem  (termasuk pemakai,  display,  dan  sebagainya)  berupa  message  yang disusun dalam suatu urutan waktu. Secara khusus, diagram ini berasosiasi dengan Use case [ 10 ] .

## G. Entity Relationship Diagram
Entity  Relationship  Diagram biasa  digunakan  untuk mengembangkan  inisial  dari  desain  basis  data.  ERD menyediakan  satu  konsep  yang  bermanfaat  yang  dapat mengubah  deskripsi  informal  dari  apa  yang  diinginkan  oleh pengguna menjadi hal yang lebih detail, presisi, dan deskripsi detail  tersebut  dapat  diimplementasikan  ke  dalam  DBMS ( Database Manajemen Sistem) [ 12 ].

## IV. HASIL DAN PEMBAHASAN
A. Penggalian Kebutuhan
Tahap penggalian kebutuhan sistem dengan menggunakan  metode  wawancara  terhadap  stakeholder.  Hasil dari  wawancara  yang  dilakukan  yaitu  berupa  minimum kebutuhan  sistem,  aturan,  maupun  kebijakan  terhadap pengguna  sistem.  Hasil  dari  wawancara  yang  terlampir, sebagai  acuan  awal  dalam  melakukan  desain  prototype  dan sistem.

## B. Analisis dan Desain
Pertama  telah  dilakukan  spesifikasi  kebutuhan pengguna  yang  tertulis  dalam  kebutuhan  fungsional  dan kebutuhan  non  fungsional.  Kemudian  yang  kedua,  dilakukan pembuatan  gambaran  desain  secara  visial  tanggapan  yang diterima  pada  saat  iterasi  yang  dilakukan  sebelumnya.  Proses prototype  ini  menggunakan  GUI  ( Graphical  User  Interface ). Tampilan  GUI  dapat  menjadi  salah  satu  cara  untuk mempresentasikan  perangkat  lunak  yang  akan  dibuat  dalam bentuk  visual.  Stakeholder  diharapkan  lebih  memahami maksud  dari  pengembang  perangkat  lunak.  Output  yang dihasilkan  dari  proses prototype akan  digunakan  untuk menyusun  spesifikasi  kebutuhan  sistem yang  dibuat menggunakan  UML  ( Unifed  Modeling  Language ).  Beberapa contoh prototype yang dihasilkan seperti Gambar berikut:
Gambar 3 Prototype halaman awal SAR 5
Gambar 4 Prototype halaman kategori SAR 5

## Gambar 6 Prototype halaman PDCA SAR 5
C. Kebutuhan Fungsional dan Kebutuhan non
Fungsional
1) Kebutuhan Fungsional
Pada tahap berikut ini akan dilakukan pengelompokan  kebutuhan  yang  berdasarkan  fungsional pada unit yang berhubungan dengan perangkat lunak yang akan  dibuat.  Berikut  merupakan  kebutuhan  fumgsional utama yang dibutuhkan pengguna:
KF-01  Sistem  dapat  menampilkan  bagi  dosen  untuk mengelola PDCA SAR 5
KF-02  Sistem  dapat  menampilkan  bagi  dosen  selaku pemegang SAR 4 untuk mengelola PDCA SAR 4 KF-03  Sistem  dapat  menampilkan  bagi  dosen  selaku pemegang SAR 3 untuk mengelola PDCA SAR 3 KF-04  Sistem  dapat  menampilkan  bagi  dosen  selaku pemegang SAR 2 untuk mengelola PDCA SAR 2 KF-05  Sistem  dapat  menampilkan  bagi  dosen  selaku pemegang SAR 1 untuk mengelola PDCA SAR 1 KF-06  Sistem  menyediakan  fitur  bagi  admin  SAR  untuk mengelola  PDCA  SAR,  yang  didalamnya  terdapat SAR 1, SAR 2, SAR 3, SAR 4, dan SAR 5.
KF-07  Sistem  menyediakan  fitur  bagi  admin  untuk mengatur jadwal pengelolaan SAR.
KF-08  Sistem  menyediakan  fitur  bagi  admin  SAR  untuk mengubah SAR diluar jadwal pengisian
KF-09  Sistem dapat menampilkan kategori SAR KF-10  Sistem  dapat  menampilkan  semua  daftar  atau  hasil
PDCA tiap SAR
KF-11  Sistem dapat mengunggah dokumen
KF-12  Sistem dapat mengunduh dokumen KF-13  Sistem  dapat  menampilkan  histori  dari  hasil  SAR
yang pernah diisi oleh dosen
2) Kebuthan non Fungsional
Berikut ini merupakan kebutuhan non fungsional perangkat lunak:
KNF-01 Semua  fitur  yang  tersedia,  dapat  digunakan sebagaimana fungsinya KNF-02 Tidak adanya menu atau tombol yang membingungkan (ambiguitas) bagi pengguna
KNF-03 Sistem  dapat  menampilkan  keseluruhan  konten
dari sistem
KNF-04 Hanya administrator yang dapat melihat keseluruhan database KNF-05 Hanya  administrator  yang  dapat  menghapus  atau mengubah data yang dirasa kurang tepat atau salah diluar batas waktu pengisian KNF-06 Waktu  untuk  penanganan  server  saat  down  hanya 1x24 jam (1hari) KNF-07 Sistem dapat diakses di berbagai device KNF-08 Sistem  dapat  diakses  dilingkungan  internal  ITS maupun eksternal KNF-09 Sistem  dapat  diakses  pada  segala  OS  (Operating System) KNF-10 Sistem dapat diakses di semua browser

## D. Alur sistem

## Gambar 7 Alur sistem

## E. Usecase
Pada  tahap  ini  akan  dilakukan  pembuatan  usecase berdasarkan  fungsi-fungsi  yang  ada  pada  perangkat  lunak yang  akan  dikembangkan.  Berikut  adalah  beberapa  contoh usecase dari kebutuhan pengguna:
1. Pengelolaan SAR
 UC-01.01 Lihat SAR 5
 UC-01.02 Lihat SAR 4
 UC-01.03 Lihat SAR 3
2. Pengelolaan jadwal SAR
 UC-06.01 Atur jadwal SAR
 UC-06.03 Lihat laporan evaluasi SAR 5
 UC-06.04 Ubah status SAR 5
3. Pengelolaan dokumen SAR
 UC-01.11 Unggah hasil SAR 5
 UC-01.12 Unduh hasil SAR 5
 UC-01.12 Unduh form SKP
Mulai Apakah ingin mengelola SAR? Apakah ingin mengelola SAR 5? Apakah ingin mengelola SAR 4? Apakah ingin mengelola SAR 3? Apakah ingin mengelola SAR 2? Apakah ingin mengelola SAR 1?
Ya Mengelola PDCA SAR 5 Mengelola PDCA SAR 4
Mengelola PDCA SAR 3 Mengelola PDCA SAR 2 Mengelola PDCA SAR 1 Ya Selesai Ya Ya Ya Ya Menampilkan output PDCA Apakah ingin melihat output SAR lain? Memilih Level yang ingin dilihat Menampilkan output PDCA Apakah ingin keluar dari menu SAR? Ya Tidak Ya Tidak Tidak Tidak Tidak Tidak

## F. Desain sistem
Setelah  mendapatkan  hasil  analisis  dari  kebutuhan pengguna  dan  kebutuhan  sistem.  Pada  tahap  berikutnya  akan dilakukan pembuatan desain sistem. Desain sistem  yang akan dibuat  meliputi  CDM  (Conceptual  data  Model),  PDM (Physical Data Model), class diagram, sequence diagram, dan desain interface.

## V. KESIMPULAN

## A. Kesimpulan
Kesimpulan  yang  dapat  diambil  dari  pengerjaan  tugas akhir ini adalah sebagai berikut:
1. Hasil  analisis  yang  telah  diperoleh  dari  stakeholder didapatkan  kebutuhan  fungsional  sistem  sebagai berikut:
 Sistem  dapat  menampilkan  bagi  dosen  untuk mengelola PDCA SAR 5.
 Sistem  dapat  menampilkan  bagi  dosen  selaku pemegang SAR 4 untuk mengelola PDCA SAR 4.
 Sistem  dapat  menampilkan  bagi  dosen  selaku pemegang SAR 3 untuk mengelola PDCA SAR 3.
 Sistem  dapat  menampilkan  bagi  dosen  selaku pemegang SAR 2 untuk mengelola PDCA SAR 2.
 Sistem  dapat  menampilkan  bagi  dosen  selaku pemegang SAR 1 untuk mengelola PDCA SAR 1.
 Sistem  menyediakan  fitur  bagi  admin  SAR  untuk mengelola  PDCA  SAR,  yang  didalamnya  terdapat SAR 1, SAR 2, SAR 3, SAR 4, dan SAR 5.
 Sistem  menyediakan  fitur  bagi  admin  untuk mengatur jadwal pengelolaan SAR.
 Sistem  menyediakan  fitur  bagi  admin  SAR  untuk mengubah SAR diluar jadwal pengisian.
 Sistem dapat menampilkan kategori SAR.
 Sistem dapat menampilkan daftar berupa hasil dari PDCA SAR.
 Sistem dapat mengunggah dokumen.
 Sistem dapat mengunduh dokumen.
 Sistem  dapat  menampilkan  histori  dari  hasil  SAR yang pernah diisi oleh dosen.
2. Diluar  usecase  utama  setiap  pengguna,  ada  beberapa usecase  yang  dapat  digunakan  oleh  semua  pengguna, misalnya  melihat  semua  hasil  SAR  dari  semua pengguna.
3. Evaluasi  desain  dilakukan  menggunakan  checklist pemenuhan  kebutuhan,  pandangan  dari  segi  HCI,  dan beberapa  kali  uji  coba  terhadap  desain  sistem  dan menghasilkan saran yang membangun dan mempermudah penggunan nantinya.
4. Validasi  desain  dilakukan  dengan  membuat  matrik kerunutan.  Hasil  validasi  ini  adalah  semua  kebutuhan yang  diperoleh  dari  wawancara  dan  dokumentasi desain telah sesuai.
B. Saran
1. Pihak  PJM  ITS  sebagai  pihak  pengelola  sistem  ini, sebagai penelitian lebih
lanjut dapat diimplementasikan  dan  dikembangkan  untuk  lebih baik lagi.
2. Hasil  dari  desain  sistem  menggunakan GUI  Design Studio
dengan hasil pengembangan, agar dikembangkan  menjadi  lebih  baik  menyesuaikan dengan  kebutuhan  kedepan  seiring  berkembangnya ilmu pengetahuan dan teknologi.

## DAFTAR PUSTAKA
[1]  Dikti, "Tugas Pokok Perguruan Tinggi," 2007.
[2]  Restra-ITS, "Rencana Strategis (Restra) ITS 2008-2014," Surabaya, 2008.
[3]  QAS-PJM, "Implementation of Integrated its Quality Assurance System ITS," Surabaya, 2009.
[4]  SAR-ITS, Surabaya, 2009.
[5]  Proker-Rektor, "Program Kerja Rektor," Surabaya, 2011.
[6]  Untung Rahardja, "Elisitasi," Rancangan Sistem Informasi Penilaian Skripsi , vol. I, no. 1, p. 63, 2011.
[7]  P Roger, Rekayasa Perangkat Lunak . Yogyakarta, 2012.
[8]  Irfan Surbakti, Interaksi Manusia Dan Komputer, Edisi Jurusan Teknik Informatika-ITS ., 2006.
[9]  Labs, M. (2010) Readyset Pro. [Online]. http://www.readysetpro.com
[10]  Doug dan Stephens, Matt Rosenberg, Use Case Driven Modelling with UML: Theory and Practice . Newyork: Apress, 2007.
[11]  T. (2003). UML Bible. Indianapolis: Wiley Publishing. Pender, UML Bible . Indianapolis: Wiley Publishing, 2003.
[12]  Jason Charvat, Project Management Methodologies: Selecting, Implementing, and Supporting Methodologies and Processes for Projects . United States: Wiley, 2003.
[13]  Sholiq, Pemodelan Sistem Informasi Berorientasi Objek Dengan UML , ISBN, Ed. Surabaya: Graha Ilmu, 2006.
[14]  R. S. Pressman, Software Engineering a Practitioner's Approach 7th Edition . New York: McGraw-Hill, 2010.
[15]  Moore, Alan, and Rick Stainer, Moore, ASystems Engineering with SysML/UML: Modeling, Analysis, Design .: Stanford Friedenthal, 2008.