BAB 3 ANALISIS DAN PERANCANGAN SOLUSI 3.1 Gambaran …thesis.binus.ac.id/doc/Bab3/2010-1-00236-IF-Bab 3.pdf · Untuk membuat aplikasi yang sesuai dengan permintaan dan kebutuhan pengguna,

43

BAB 3 ANALISIS DAN PERANCANGAN SOLUSI

3.1 Gambaran Umum Studi Kasus

3.1.1 Sejarah Dan Perkembangan IT Directorate Bina Nusantara

Information Technology Directorate (IT Directorate) didirikan pada

agustus 2005 dan sekarang dipimpin oleh Eddy Santosa Jaya (General Manager

IT). Pada saat itu pula IT Directorate tidak hanya bertanggung jawab atas

masalah di dalam BINUS UNIVERSITY tetapi juga bertanggung jawab atas

masalah dalam semua BINUS Group. Dengan kekuatan IT yang dimilikinya,

BINUS dapat meningkatkan keunggulannya yang kompetitif baik dalam

Indonesia maupun di dunia pada umumnya.

Berikut adalah perkembangan dari IT Directorate:

1. 1981

Didirikan Electronic Data Processing (EDP).

2. 1993

Didirikan departemen Management Information System

(MIS).

3. 1995

Didirikan Applied Technology Laboratory (ATL) dan

Unit Pelaksana Teknis (UPT) Computer Center (PUSKOM).

ATL dan PUSKOM berperan untuk memenuhi kebutuhan

44

BINUS. Peran ATL adalah pada pengembangan aplikasi yang

berbasis web atau internet, sedangkan PUSKOM berperan

dalam pengembangan aplikasi berbasis desktop.

4. 1998

Didirikan UPT Perangkat Jaringan (UPT network

services) yang sebelumnya adalah BINUS net yang

dikoordinasikan oleh UPT Computer Services pada tahun 1997.

5. 2001

Didirikan Biro Layanan Operasi IT (IT Operation

Services Bureau) yang merupakan hasil gabungan antara UPT

PUSKOM dan UPT Perangkat Jaringan. Pada saat yang sama,

IT Developtment Center didirikan dari ATL.

6. 2005

Didirikan IT Directorate Bina Nusantara.

Sejarah perjalanan perkembangan IT Directorate Bina Nusantara dapat

dilihat pada Gambar 3.1.

45

Gambar 3.1 Sejarah Perjalanan Perkembangan IT Directorate.

3.1.2 Struktur Organisasi Perusahaan

Struktur Organisasi IT Directorate BINUS dapat dilihat pada Gambar

3.2.

Gambar 3.2 Struktur Organisasi IT Directorate.

46

Tanggung jawab dan wewenang tiap bagian adalah sebagai berikut :

1. IT General Manager

Mengendalikan seluruh kegiatan pengembangan dan

kegiatan operasional IT di Bina Nusantara.

2. Information System Development Manager

Mengendalikan dan mengelola pengembangan sistem

informasi di seluruh BINUS.

3. University Information System Development Manager


informasi di dalam cakupan universitas. Meliputi BINUS

UNIVERSITY, BINUS BUSINESS SCHOOL, dan BINUS

Online Learning.

4. School Information System Development Manager


informasi di dalam cakupan sekolah. Meliputi BINUS SCHOOL

SIMPRUG, BINUS SCHOOL SERPONG, dan semua

perpustakaan BINUS Group.

5. Technology Development Manager

Mengendalikan dan mengelola riset dan pengembangan

teknologi terbaru yang dapat diimplementasi di BINUS,

manajemen sumber daya manusia, dan mediator antara IT

Directorate dengan user.

47

6. Information Technology Operation Manager

Departemen ini bertanggung jawab membantu operasi IT

di BINUS. Departemen ini memiliki dua fungsi utama yaitu

Network and Communication dan Data Center.

7. Network and Communication Manager

Bertanggung jawab atas seluruh operasional jaringan dan

manajemen jaringan di BINUS. Serta bertanggung jawab atas

deployment komputer ke semua business unit di BINUS.

8. Data Center Manager

Bertanggung jawab atas seluruh server aplikasi dan

database di BINUS. Serta bertanggung jawab atas layanan

technical support untuk semua business unit di BINUS.

Berikut adalah tanggung jawab dan wewenang dari masing – masing

yang berada didalam Information System Development:

1. Senior System Analyst

• Identifikasi dan memenuhi kebutuhan pengguna dan

proses bisnis yang ada.

• Berperan sebagai fasilitator dan penghubung untuk

semua unit bisnis dalam membantu menangani dan

memecahkan masalah IT di proyek yang ada.

• Memberikan arahan teknis dan rekomendasi dalam

pengembangan aplikasi.

48

2. System Analyst

• Menganalisa kebutuhan sistem dan membuat user

requirement untuk pengembangan sistem informasi baru.

• Merancang tampilan untuk aplikasi desktop yang akan

dibangun.

• Melakukan testing pada pada aplikasi.

3. Designer

• Menentukan tata letak, bentuk, warna dan penyusunan

yang baik dari tampilan web.

• Merealisasikan rancangan formulir – formulir aplikasi ke

dalam bentuk Hypertext.

• Menentukan komponen – komponen yang tepat pada

pembuatan formulir aplikasi berbasis web.

4. E-media Specialist

• Bertanggung jawab membuat User Interface (UI) yang

user friendly.

• Menentukan peletakan dan penyusunan informasi pada

web.

5. Senior Programmer

• Merekomendasikan system analyst untuk penggunaan

teknologi yang digunakan dalam suatu proyek.

• Melakukan coding sesuai dengan rancangan aplikasi

yang diberikan.

49

• Melakukan alpha testing terhadap aplikasi yang dibuat.

6. Programmer

• Melakukan coding sesuai dengan rancangan aplikasi.

• Melakukan alpha testing terhadap aplikasi yang dibuat.

7. Software Architect

Merancang framework yang akan digunakan pada

pembangunan aplikasi.

8. User Acceptance Test (UAT) Tester

Melakukan pengecekan pada hasil aplikasi berdasarkan

business requirement dari User.

9. System DocumentationTelemarketing Staff

• Membuat dokumentasi atau panduan penggunaan untuk

sistem informasi yang telah dikembangkan.

• Mengendalikan dan mengelola job-request (surat

pengajuan aplikasi) yang masuk pada pihak IT

Directorate.

• Melakukan back-up aplikasi.

3.2 Analisis Permasalahan

3.2.1 Analisis Visual Studio 2008 dan NetBeans 6.0

Tabel 3.1 Perbandingan Visual Studio 2008 dan NetBeans 6.0

Fitur Visual Studio 2008

NetBeans 6.0 Komentar

Bahasa yang C/C++, C#, C/C++, Java, J# telah dihapus dari Visual

50

didukung

VB.net, XAML, HTML/CSS, Javascript, LINQ (Language Integrated Query), ASP.net, XML/XSLT,

Ruby, Php, Javascript, HTML/CSS, JSP, JavaFX, XSL, WSDL, UML

Studio. Jadi semua, pengembang dapat kembali ke Java. NetBeans 6.0 mendukung banyak bahasa dan memiliki sistem plugin yang sangat baik untuk mendukung banyak bahasa lainnya.

LINQ adalah baru dalam VS2008 di mana Anda dapat menulis seperti SQL-query dalam program untuk berkomunikasi dengan database dan file. XAML mendapatkan desainer visual yang luar biasa di VS2008.

OS / Platform yang didukung

Windows dan berbagai versi Windows

Windows, Linux, Unix, Solaris (SPARC, x86/x64), Mac OSX (Intel, PowerPC)

NetBeans 6.0 dapat diinstal dan dijalankan di sejumlah platform yang berbeda. VS2008 di sisi lain hanya ditargetkan ke arah windows pengembang.

Source Code Editor

Editing sederhana dan mudah. Beralih antara layar desain dan layar kode dengan mengklik dua kali pada kontrol

Editing sederhana dan mudah. NetBeans menyediakan berbagai event ketika Anda klik kanan pada komponen dan kode.

Source code editing sama baik dalam keduanya.

Compiler /Loader / Debugger

Kompilasi paralel pada sistem multicore, Standard Template Library (STL) untuk C + + devs untuk digunakan. Net framework, Web Services hosting untuk aplikasi berbasis WCF.

Newer Lexer, Javascript debugger dengan Phobos support dan jMaki

Kompilasi multicore di VS2008 telah memperbaiki kinerja dengan baik 25-30% dari versi sebelumnya pada C# apps.

Visual Studio 2008 mengintegrasikan web services hosting, yang sebelumnya harus dilakukan secara terpisah oleh pengguna. NetBeans memiliki tomcat 6 dan Glassfish v2 yang terintegrasi, jadi VS2008 setara dengan NetBeans 6.0. Baik NetBeans dan VS2008 memiliki javascript debugger yang baru.

51

Spesialis lain Visual Studio 2008 memiliki sesuatu yang disebut "Visual Studio 2008 Shell". Hal ini memungkinkan pengembang untuk menciptakan IDE mereka sendiri berdasarkan platform.

NetBeans 6.0 juga telah Ruby on Rails Template untuk membuat blog cepat. NetBeans 6,0 memiliki derby sebagai database yang terintegrasi (meskipun JDK 6 memiliki derby). Ini berarti Anda dapat memiliki database tertanam di dalam aplikasi Anda dan tidak ada persyaratan untuk server basis data eksternal seperti SQL Server atau MySQL.

3.2.2 Analisis Proses Bisnis Berjalan

Sistem pengajuan aplikasi yang berjalan di IT Directorate Binus

University masih dilakukan secara manual dan menggunakan kertas. Untuk

melakukan satu pengajuan aplikasi, ada beberapa prosedur yang harus

dilakukan, antara lain:

3.2.2.1 Prosedur Pengajuan Aplikasi (Job Request)

Apabila seorang pengguna ingin mengajukan pembuatan

aplikasi, maka pengguna harus mengajukan melalui atasannya dari

departemennya masing-masing. Formulir Job Request dapat di

download langsung dari lotus note dan di print atau langsung

mengambil di Information Technology Directorate (IT Directorate).

Pengguna mengisi formulir Job Request dan menyerahkan formulir

tersebut kepada atasannya dari departemen yang sama untuk

diperiksa. Apabila diterima dan ditandatangani oleh atasannya, maka

formulir Job Request akan diserahkan ke IT Directorate melalui

office boy (OB) atau oleh pengguna maupun staff lain. Manajer IT

akan memeriksa formulir tersebut untuk disetujui atau ditolak dengan

52

menandatanginya. Manajer IT atau bisa diwakilkan oleh

sekretarisnya, akan memberitahukan status pengajuan aplikasi

tersebut dengan cara langsung (lisan) ataupun melalui email atau

telepon. Dan kemudian, manajer IT akan menghubungi developer

untuk membicarakan perancangan aplikasi tersebut.

Diagram Aliran Data dari prosedur pengajuan aplikasi yang

sedang berjalan dapat dilihat pada Gambar 3.3 dibawah ini:

53

Job Request

OBDeveloperManager ITHead ManagerUser Approval

Formulir Job Request

Pilih

Mendownload form Job Request dari

Lotus note

Mengambil di IT

directorate

Mengantar Dokumen

Memeriksa form Job Request

Form Job Request

Setuju / tidak setuju

Mulai

Mengisi Form Job Request

tidakMenandatang

ani fom job request

ya


ya

Memeriksa form Job Request

Setuju / tidak setuju



Menandatangani fom job request

Mengantar Dokumen

tidak

Membahas Form Job Request


Selesai

Gambar 3.3 DAD Prosedur Pengajuan Aplikasi.

54

3.2.2.2 Prosedur Kebutuhan Pengguna (User Requirement)

Untuk membuat aplikasi yang sesuai dengan permintaan dan

kebutuhan pengguna, developer akan mengisi formulir User

Requirement sesuai dengan kebutuhan pengguna. Formulir tersebut

akan diserahkan kepada pengguna melalui office boy (OB) atau oleh

pengguna maupun staff lain. Formulir akan diperiksa oleh pengguna

untuk disetujui atau ditolak. Apabila ditolak, maka pengguna akan

menjelaskan kepada developer alasan ditolaknya requirement tersebut

melalui telepon, email atau langsung. Kemudian developer akan

memperbaiki dan mengajukan kembali kepada pengguna yang

bersangkutan. Apabila disetujui oleh pengguna, maka developer akan

melanjutkan ke proses perancangan aplikasi (application

developtment) dan memberikan timeline.

Diagram Aliran Data dari prosedur pemenuhan kebutuhan

user yang sedang berjalan dapat dilihat pada Gambar 3.4 dibawah ini:

55

Gambar 3.4 DAD Prosedur Pemenuhan Kebutuhan Pengguna.

56

3.2.2.3 Prosedur Evaluasi (Testing)

Developer akan mengajukan permintaan testing internal

kepada system tester dengan memberikan formulir evaluation dan

aplikasi. System tester akan memeriksa sistem aplikasi. Apabila masih

ditemukan error, maka system tester akan mencatat error tersebut

kedalam formulir evaluation yang akan diserahkan kepada developer

melalui office boy (OB) atau oleh pengguna maupun staff lain.

Kemudian developer akan memperbaiki error tersebut dan

mencatatnya juga kedalam formulir evaluation. Formulir tersebut

kemudian diserahkan lagi kepada system tester melalui office boy

(OB) atau oleh pengguna maupun staff lain untuk diperiksa. Apabila

tidak ditemukan error, maka developer akan melanjutkan

pemeriksaan kebagian external.

Diagram Aliran Data dari prosedur evaluasi internal yang


57

Gambar 3.5 DAD Prosedur Evaluasi Internal.

58

Developer akan memberikan formulir evaluation dan aplikasi

kepada user tester untuk diperiksa oleh user tester. Apabila

ditemukan error, maka error tersebut akan dicatat di formulir

evaluation dan dikembalikan lagi kepada developer melalui office boy

(OB) atau oleh pengguna maupun staff lain. Developer akan

memperbaiki error tersebut dan mencatatnya kembali di formulir

evaluation yang kemudian diserahkan kembali kepada system tester

melalui office boy (OB) atau oleh pengguna maupun staff lain.

Apabila tidak ditemukan error, maka developer akan memberikan

formulir evaluation dan aplikasi kepada user tester untuk diperiksa

oleh user tester. Apabila tidak ditemukan error, maka developer dapat

melanjutkan ke proses instalasi.

Diagram Aliran Data dari prosedur evaluasi eksternal yang


59

Gambar 3.6 DAD Prosedur Evaluasi Eksternal.

60

3.2.2.4 Prosedur Instalasi (Installation)

Developer akan memberikan bukti instalasi aplikasi dengan

memberikan formulir instalasi kepada pengguna melalui office boy

(OB) atau oleh pengguna maupun staff lain, untuk diperiksa dan

disetujui atau ditolak. Apabila ditolak, maka pengguna akan

memberitahukan alasannya kepada developer melalui telepon, email

atau langsung. Developer akan memberikan kembali bukti

penginstalan aplikasi kepada pengguna. Setelah disetujui oleh

pengguna, maka developer dapat melanjutkan ke proses pelatihan

atau penutupan proyek.

Diagram Aliran Data dari prosedur instalasi yang sedang

berjalan dapat dilihat pada Gambar 3.7 dibawah ini:

61

Gambar 3.7 DAD Prosedur Instalasi.

62

3.2.2.5 Prosedur Pelatihan (Training)

Pelatihan dilakukan untuk melatih pengguna agar bisa

menggunakan aplikasi yang baru. Ada atau tidaknya pelatihan

ditentukan oleh developer, tergantung tingkat kesulitan menggunakan

aplikasi baru tersebut. Jika developer mengadakan pelatihan, maka

developer akan mengundang pengguna yang akan menggunakan

aplikasi tersebut dan menentukan instruktur yang akan mengajar pada

pelatihan tersebut. Pada saat pelatihan, pengguna akan mengisi

formulir training untuk menandakan kehadirannya di pelatihan

tersebut. Kemudian formulir training akan dikembalikan kepada

instruktur dan instruktur memberikan formulir training kepada

developer.

Diagram Aliran Data dari prosedur pelatihan yang sedang

berjalan dapat dilihat pada Gambar 3.8 dibawah ini:

63

Training

DeveloperinstrukturUser Training

Mulai

Mengisi Form

Formulir Training

Memeriksa Document

Formulir Training

SelesaiYa / tidak yatidak

Gambar 3.8 DAD Prosedur Pelatihan.

64

3.2.2.6 Prosedur Penutupan Proyek (Project Closing)

Apabila aplikasi telah dianggap selesai dan memenuhi

kebutuhan pengguna, maka developer akan mengisi formulir project

closing yang kemudian akan diserahkan kepada pengguna melalui

office boy (OB) atau oleh pengguna maupun staff lain, untuk

diperiksa. Apabila pengguna menolak penutupan proyek, maka

pengguna akan memberitahukan alasannya kepada developer melalui

telepon, email atau langsung. Kemudian developer akan mengajukan

kembali penutupan proyek kepada pengguna. Apabila pengguna

menyetujui penutupan proyek, maka pengerjaan proyek telah

dianggap selesai.

Diagram Aliran Data dari prosedur penutupan proyek yang


65

Gambar 3.9 DAD Prosedur Penutupan Proyek.

66

3.2.3 Analisis Wawancara

Setelah menganalisa prosedur – prosedur yang dilakukan dalam proses

pengajuan aplikasi yang sedang berjalan di IT Directorate BINUS University,

dilakukan wawancara untuk menganalisa permasalahan yang dialami serta data

yang dibutuhkan. Wawancara dilakukan sebanyak tiga kali.

Wawancara pertama dilakukan terhadap seorang Developer untuk

mengetahui masalah-masalah yang dihadapi dalam melakukan tugas-tugasnya

serta memperoleh data yang dibutuhkan untuk merancang solusi terhadap

permasalahan tersebut. Hasil dari wawancara pertama dapat dilihat pada Tabel

3.2 di bawah ini.

Tabel 3.2 Draft Wawancara I.

Nama Rudy

Jabatan Developer

Tanggal wawancara 22 Desember 2009

Waktu wawancara 16.15 – 17.00 WIB

Tempat wawancara Ruang rapat kecil IT Directorate

1. Apakah anda puas dengan sistem pengajuan aplikasi (Job Request) yang berjalan

sekarang ini ?

Jawab :

Sistem sudah bagus dan form sudah rapi. Tetapi dalam pelaksanaannya

kurang bagus, antara lain disebabkan oleh :

67

- Di dalam penulisan form, sering kali bahasa user dan bagian IT developer

berbeda sehingga susah dimengerti oleh pihak developer. Sehingga sering

kali PM menuliskan kembali job request tersebut di form job request yang

baru.

- Time schedule tidak bisa dijaga karena tidak diatur oleh sistem. Sehingga

sering kali tertunda dan terlupakan.

- Sering kali user tidak mengikuti prosedur yang seharusnya dilakukan.

Dengan adanya aplikasi diharapkan user diwajibkan menjalankan prosedur

yang berjalan.

2. Berapa lama waktu ideal yang dilakukan dalam mengajukan / melakukan ?

Jawab :

a. User requirement = Tergantung aplikasi. Idealnya 1-2 minggu.

b. Testing internal = Tergantung aplikasi. Idealnya 1 aplikasi 1-3 hari.

c. Testing eksternal = Lebih lama, karena user harus mencoba-coba dan

waktu user tidak fokus untuk testing saja. Idealnya 1 aplikasi 3 hari.

d. Instalasi = Jika tidak ada kendala, 1 hari.

e. Training = Tergantung aplikasi. Idealnya 1-2 hari.

f. Project Closing = 1 hari.

3. Untuk satu kali Job Request yang diajukan, berapa kali pengajuan User

Requirement yang dilakukan ?

Jawab :

68

Idealnya 3 kali. Tapi dalam penerapannya, sering kali user requirement

diajukan setelah aplikasi selesai. Diharapkan dengan adanya aplikasi maka

proses pengajuan aplikasi bisa sesuai dengan prosedur yang diharapkan.

4. Apakah ada masalah dalam penyampaian form user requirement yang biasanya

dilakukan secara berulang antara pihak developer dan user dengan masih

digunakannya cara penyampaian manual ? Jika ada, apa saja masalahnya ?

Jawab :

Ya, dalam penerapannya sering kali terjadi kesalahan prosedur.

administratif sering kali tidak diperhatikan. Biasanya aplikasi dikerjakan dahulu

baru diadministratifkan.

5. Untuk sistem pengajuan aplikasi yang berjalan sekarang ini, apakah perlu

dibuatkan menjadi sistem yang terkomputerisasi untuk mempercepat berjalannya

proses pengajuan ? Jika ya, apa harapan anda dari sistem baru tersebut ?

Jawab :

Ya, diharapkan dengan adanya aplikasi maka bisa membantu

memberikan informasi yang diperlukan sehingga mempercepat melakukan

tindakan selanjutnya.

6. Apa saja kendala teknis yang sering dihadapi dalam sistem pengajuan aplikasi di

IT Directorate ?

Jawab :

69

- Developer tidak memperhatikan spesifikasi dari komputer pengguna. Sering

kali aplikasi tidak berjalan sesuai dengan keinginan ketika dijalankan di

komputer pengguna.

- Pengguna tidak mengerti proses bisnis, sehingga aplikasi yang diminta tidak

terpakai.

7. Jika ada perubahan proses pengajuan aplikasi, seberapa cepat sosialisasi dan

penerapannya ?

Jawab :

Dibagian internal tidak terlalu banyak masalah, tetapi untuk bagian

eksternal, butuh waktu karena sering kali pengguna hanya menggunakan sistem

ketika mereka butuh.

8. Apakah masalah sekarang yang paling perlu untuk dibenahi ?

Jawab :

Sistem sekarang sudah cukup bagus, tetapi akan lebih baik jika aplikasi

yang dibuat dapat memberikan informasi yang diperlukan lebih dini kepada

pengguna sehingga bisa membantu dalam sisi manajemen dan monitoring.

70

Wawancara kedua dilakukan terhadap seorang Project Manager pada

IT Directorate BINUS University untuk mengetahui masalah-masalah yang

dihadapi dalam melakukan tugas-tugasnya serta memperoleh data yang

dibutuhkan untuk merancang solusi terhadap permasalahan tersebut. Hasil dari

wawancara kedua dapat dilihat pada Tabel 3.3 di bawah ini.

Tabel 3.3 Draft Wawancara II.

Nama John Chandra

Jabatan Project Manager



Tempat wawancara Ruang rapat kecil IT Directorate


sekarang ini ?

Jawab :

Untuk sistemnya sudah cukup bagus, tetapi dalam penerapannya sering

kali pengguna tidak mengikuti prosedur sehingga tidak aneh jika akhirnya yang

menulis form job request adalah pihak developer.

2. Berapa lama waktu ideal yang dilakukan dalam mengajukan / melakukan ?

Jawab :

a. User requirement = tergantung permintaan user. Jika hanya pendataan

idealnya 3 hari. Jika sudah menyangkut transaksi sekitar 1 minggu. Dan

71

jika sudah membuat 1 sistem keseluruhan maka bisa memakan waktu 1

bulan.

b. Testing internal = Diharapkan dalam 1 minggu sudah selesai.

c. Testing eksternal = Diharapkan dalam 1 minggu sudah selesai. Jika

terlalu lama sering kali terlupakan dan ada yang ketinggalan.

d. Instalasi = Idealnya 1 sampai 2 hari.

e. Training = idealnya 1 hari. Developer juga akan memberikan user manual

kepada pengguna untuk dipelajari.

f. Project Closing = idealnya 1 minggu. Tetapi diharapkan bisa selesai

dalam waktu 2 hari.



Jawab :

Idealnya 3 kali. Tergantung seberapa besar sistem yang dibuat.




Jawab :

User tidak terlalu mengerti bahasa teknis dari developer sehingga untuk

mengatasinya hanya diberikan dalam bentuk gambar atau user interface.

72

5. Untuk sistem pengajuan aplikasi yang berjalan sekarang ini, apakah perlu

dibuatkan menjadi sistem yang terkomputerisasi untuk mempercepat berjalannya

proses pengajuan ? Jika ya, apa harapan anda dari sistem baru tersebut ?

Jawab :

Iya, sangat diharapkan. Karena sering kali penerapan selama ini tidak

mengikuti prosedur dengan benar. Sehingga form – form yang seharusnya diisi

selama proses pembuatan aplikasi menjadi diisi setelah aplikasi selesai dibuat.

6. Apa saja kendala teknis yang sering dihadapi dalam sistem pengajuan aplikasi di

IT Directorate ?

Jawab :

User melakukan pengisian form setelah aplikasi selesai dikerjakan

sehingga apabila diaudit akan muncul masalah karena tanggal pada tanda tangan

tidak sesuai dengan tanggal pada saat direquest.

73

Wawancara ketiga dilakukan terhadap seorang User untuk

mengetahui masalah-masalah yang dihadapi dalam melakukan tugas-

tugasnya serta memperoleh data yang dibutuhkan untuk merancang solusi

terhadap permasalahan tersebut. Hasil dari wawancara kedua dapat dilihat

pada Tabel 3.4 di bawah ini.

Tabel 3.4 Draft Wawancara III.

Nama Ivone

Jabatan User



Tempat wawancara Ruang CMC (Coorporate Marketing

Communication)


sekarang ini ?

Jawab :

Tidak, terutama dalam proses minta tanda tangan. Atasan tidak selalu ada

ditempat sehingga proses minta tanda tangan jadi tertunda. Alasan lainnya adalah

terkadang aplikasi yang diminta tidak sesuai dengan harapan, karena pemikiran

pengaju dan pembuat sering kali berbeda.

2. Berapa lama informasi yang didapat mengenai approval job request yang

74

diajukan?

Jawab :

Tergantung dari tingkat urgent. Jika urgent bisa kejar dalam sehari, tetapi

jika tidak maka bisa memakan waktu seminggu. Untuk mencari atasan juga agak

sulit sehingga memakan waktu yang cukup lama untuk mengajukan satu job

request.



Jawab :

Untuk aplikasi agak jarang jadi kurang tahu. Tapi untuk website,

biasanya cepat karena sudah berupa tampilan user interfacenya.




Jawab :

Sering kali bahasa teknis dari developer kurang dipahami oleh user

sehingga pada saat pembuatan aplikasi sering terjadi kesalahpahaman dan

akhirnya aplikasi yang jadi tidak sesuai dengan yang diinginkan.

5. Apakah masalah sekarang yang paling perlu untuk dibenahi ?

Jawab :

75

Kalau bisa ada sisi konsultasi, dimana pembuat sistem sebagai konsultan

sehingga mengurangi kesalahpahaman dalam pembuatan aplikasi.

3.2.4 Analisis Pengukuran


pengajuan aplikasi yang sedang berjalan di IT Directorate BINUS University,

dilakukan pengukuran antara aplikasi yang dibuat dengan code tradisional dan

aplikasi yang berbasis layanan dan menerapkan workflow.

Hasil pengukuran dari perubahan proses antara aplikasi yang dibuat

dengan code konvensional dengan aplikasi yang berbasis layanan dan

menerapkan workflow dapat dilihat pada Tabel 3.5.

76

76 Tabel 3.5 Hasil Pengukuran Waktu Antara Aplikasi Dengan Code Konvensional Dan Aplikasi Yang Menggunakan Workflow.

No. Nama Aplikasi Yang Di Uji

Deskripsi Perubahan Waktu Perubahan Untuk Aplikasi Code Konvensional (jam : menit : detik)

Waktu Perubahan Untuk Aplikasi Workflow (jam : menit : detik)

1 Program Olah Kata

Perulangan untuk melakukan inputan akan berhenti sampai angka 5 di tekan. Pertukaran menu pilihan 1 dengan 3 dan pilihan 2 dengan 4.

00:02:01 00:01:59

2 Program Simpan Buku

Penyimpanan data ke database 00:06:09 00:04:35

3 Program Bio Data Mahasiswa

Menampilkan semua bio data yang ada di database

00:04:58 00:04:07

4 Program Validasi Email

Perubahan urutan validasi yaitu validasi inputan harus mengandung karakter ‘@’ dan validasi inputan harus mengandung karakter ‘.’.

00:03:23 00:01:20

5 Program Penerimaan Mahasiswa

Perubahan urutan proses dimana pengembalian form dilakukan setelah memilih jadwal ujian saringan masuk, dan semua pendataan di catat ke dalam database.

00:10:12 00:09:39

77

Dilakukan juga evaluasi pengukuran dengan bantuan Associate Member

yang berjumlah 27 orang. Dengan aplikasi yang diuji adalah program validasi

email dan perubahan yang terjadi adalah perubahan urutan validasi yaitu

validasi inputan harus mengandung karakter ‘@’ dan validasi inputan harus

mengandung karakter ‘.’. Hasil pengukuran dapat dilihat pada Tabel 3.6.

Tabel 3.6 Hasil Pengukuran Dengan Aplikasi Program Validasi Email.

No. Nim Waktu Perubahan

Untuk Aplikasi Code Konvensional (jam : menit : detik)

Waktu Perubahan Untuk Aplikasi Workflow (jam : menit : detik)

1. 1000836590 00:03:27 00:02:30

2. 1200990073 00:02:59 00:02:02

3. 1200989992 00:03:10 00:02:43

4. 1200996921 00:04:03 00:03:16

5. 1301057425 00:02:52 00:01:55

6. 1200967461 00:02:21 00:01:31

7. 1200991372 00:03:15 00:02:46

8. 1200943745 00:03:44 00:03:15

9. 1200972480 00:04:32 00:03:41

10. 1200976112 00:05:27 00:04:24

11. 1301059960 00:04:36 00:03:28

12. 1200967045 00:03:29 00:02:31

13. 1301010176 00:03:05 00:02:48

78

14. 1200975684 00:02:31 00:02:04

15. 1200976024 00:03:08 00:02:54

16. 1301037985 00:03:16 00:03:02

17. 1200973092 00:05:08 00:04:24

18. 1200993200 00:04:18 00:03:42

19. 1301050785 00:03:22 00:02:59

20. 1301021261 00:04:39 00:03:44

21. 1200947232 00:03:42 00:02:36

22. 1200978824 00:03:57 00:02:21

23. 1301068712 00:03:59 00:03:46

24. 1301023632 00:04:26 00:03:18

25. 1000879904 00:03:19 00:02:20

26. 1200978093 00:05:28 00:03:36

27. 1100028605 00:03:37 00:02:25

3.2.5 Identifikasi Permasalahan


pengajuan aplikasi yang sedang berjalan di IT Directorate BINUS University

dan dari hasil pengukuran antara aplikasi yang dibuat dengan code tradisional

dan aplikasi yang berbasis layanan dan menerapkan workflow, maka dapat

disimpulkan permasalahan yang dihadapi oleh para pelaku pengajuan aplikasi

di IT Directorate BINUS University.

79

Berikut adalah permasalahan-permasalahan yang dihadapi oleh IT

Directorate BINUS University.

1. Permintaan perubahan proses bisnis dengan menggunakan

aplikasi yang dibuat dengan code konvensional masih berjalan

lambat dalam mengikuti permintaan pengguna.

2. Sistem yang masih belum terkomputerisasi sehingga

memperlambat sistem pengajuan aplikasi yang dilakukan di IT

Directorate BINUS University.

3. Tidak adanya sebuah sistem basis data yang mampu

mempercepat dan mempermudah proses pengumpulan,

penginputan, dan peng-update-an informasi dan data – data

perusahaan dan transaksi perusahaan dengan valid.

3.2.6 Analisis Pemecahan Masalah

Berdasarkan permasalahan yang di temukan dari hasil observasi dan

wawancara, berikut adalah solusi yang dapat digunakan untuk memecahkan

masalah yang dihadapi oleh IT Directorate BINUS University.

1. Membuat aplikasi menggunakan workflow berbasis layanan

sehingga dalam mengikuti perubahan proses bisnis dapat

berjalan cepat.

2. Membuat aplikasi yang terkomputerisasi dengan didukung oleh

suatu penyimpanan basis data yang terintegrasi sehingga

80

menyajikan informasi yang bermanfaat guna mendukung

pengambilan keputusan secara tepat dan bermanfaat bagi semua

pihak.

3.2.7 Perancangan Solusi

Dalam rancangan solusi yang diusulkan untuk memecahkan

permasalahan yang dialami pada sistem pengajuan aplikasi di IT Directorate

BINUS University terdapat tiga server, yaitu Active Directory, Web Front End

dan Database yang dihubungkan oleh layanan (service). Di server Active

Directory terinstal Windows Server 2003 dan Windows Component berupa

Active Directory. Di server Web Front End terinstal Windows Server 2003 dan

.Net Framework 3.5. Sedangkan di Server Database terinstal SQL Server 2005

dan Sql Server Management Studio. Rancangan solusi berupa diagram modular

dapat dilihat pada Gambar 3.10.

81

Gambar 3.10 Diagram Modular.

3.2.8 Perancangan Sistem

3.2.8.1 Workflow Sistem yang diusulkan

1. Workflow Pengajuan Aplikasi (Job Request)

User approval mengajukan pembuatan aplikasi pada

halaman web yang tersedia, setelah selesai mengisi formulir

pengajuan aplikasi dan menekan tombol submit, maka sistem

akan mengirimkan notifikasi berupa email kepada head user

approval. Head user approval membuka halaman web dan

82

memeriksa pengajuan aplikasi yang diajukan oleh user

approval, apabila head user approval setuju dan menekan

tombol approve, maka sistem akan mengirimkan notifikasi

lagi kepada manager IT berupa email. Manager IT membuka

halaman web dan memeriksa pengajuan aplikasi yang

diajukan oleh user approval, apabila manager IT setuju, maka

manager IT harus menentukan developer terlebih dahulu baru

menekan tombol approve. Developer menerima notifikasi

email dan kemudian memerika formulir pengajuan aplikasi.

Workflow dari formulir job request yang diusulkan

dapat dilihat pada Gambar 3.11 dibawah ini :

83

Gambar 3.11 Workflow Pengajuan Aplikasi.

84

2. Workflow Kebutuhan Pengguna (User Requirement)

Setelah developer memeriksa formulir pengajuan

aplikasi, maka selanjutnya developer membuat user

requirement yang berupa rancangan layar, jadwal proyek, dan

sebagainya yang bisa di upload berupa file pada halaman web

yang tersedia. Setelah developer selesai dan menekan tombol

submit, user approval akan dikirimkan notifikasi email bahwa

user requirement telah disediakan. User approval melihat

requirement yang diberikan oleh developer, jika user approval

tidak setuju dan menekan tombol reject serta mengisi alasan

penolakan dan tambahan – tambahan, maka developer akan

dikirimkan email notifikasi dan developer membuat ulang

requirement. Jika user approval setuju dan menekan tombol

approve, maka developer diberitahukan melalui notifikasi

email dan developer mulai membangun aplikasi.

Workflow dari formulir user requirement yang

diusulkan dapat dilihat pada Gambar 3.12 dibawah ini :

85

Gambar 3.12 Workflow Kebutuhan Pengguna.

86

3. Workflow Evaluasi Internal (Internal Evaluation)

Setelah developer selesai membangun aplikasi, maka

tahap selanjutnya yang dilakukan adalah testing internal yang

dilakukan oleh system tester. Jika dalam tahap testing internal,

terdapat kesalahan atau kekurangan pada aplikasi yang

dibangun, maka system tester akan mengisi formulir evaluasi

yang terdapat pada halaman web. Setelah selesai mengisi

formulir evaluasi dan menekan tombol submit, maka

developer akan dikirimkan notifikasi email, developer

memeriksa kesalahan yang dihasilkan dari hasil testing

internal, dan memperbaiki kesalahan yang ada. Setelah selesai

memperbaiki, memberikan tanda check pada formulir evaluasi

dan menekan tombol submit, maka system tester akan

dikirimkan notifikasi lagi bahwa kesalahan yang ditemukan

telah diperbaiki dan siap untuk di testing lagi. Jika tidak

terdapat kesalahan lagi, maka aplikasi yang dibangun akan

dilakukan testing eksternal.

Workflow dari formulir testing internal yang diusulkan

dapat dilihat pada Gambar 3.13.

87

4. Workflow Evaluasi Eksternal (External Evaluation)

Setelah selesai dilakukan testing internal, maka

aplikasi yang dibangun akan dilakukan testing eksternal oleh

user tester. Jika dalam tahap testing eksternal, terdapat

kesalahan atau kekurangan pada aplikasi yang dibangun, maka

user tester akan mengisi formulir evaluasi yang terdapat pada

halaman web. Setelah selesai mengisi formulir evaluasi dan

menekan tombol submit, maka developer akan dikirimkan

notifikasi email, developer memeriksa kesalahan yang

dihasilkan dari hasil testing eksternal, dan memperbaiki

kesalahan yang ada. Setelah selesai memperbaiki,

memberikan tanda check pada formulir evaluasi dan menekan

tombol submit, maka akan dilakukan tahap testing internal lagi

dan kemudian akan di testing lagi secara eksternal. Jika tidak

terdapat kesalahan lagi, maka aplikasi yang dibangun telah

selesai di testing.

Workflow dari formulir testing eksternal yang

diusulkan dapat dilihat pada Gambar 3.13 dibawah ini :

88

Gambar 3.13 Workflow Evaluasi Eksternal.

89

5. Workflow Instalasi (Installation)

Setelah selesai melalui tahap testing, aplikasi yang

dibangun akan diinstal dan digunakan. Developer akan

mengisi formulir instalasi pada halaman web. Setelah selesai

mengirim formulir dan menekan tombol submit, user yang

berhubungan akan dikirimkan notifikasi email. Kemudian user

memeriksa formulir instalasi dan apabila menolak dan

menekan tombol reject, maka user akan mengisi alasan

penolakan dan developer akan menerima notifikasi email. Jika

user setuju dan menekan tombol approve, developer akan

dikirimkan notifikasi email. Dan developer akan melakukan

instalasi.

Workflow dari formulir installation yang diusulkan


90

Gambar 3.14 Workflow Instalasi.

91

6. Workflow Pelatihan (Training)

Pelatihan dilakukan untuk melatih pengguna agar bisa

menggunakan aplikasi yang baru. Ada atau tidaknya pelatihan

ditentukan oleh developer, tergantung tingkat kesulitan

menggunakan aplikasi baru tersebut. Jika developer

mengadakan pelatihan, maka developer akan mengisi formulir

instalasi yang terdapat pada halaman web serta menentukan

pengguna yang diundang untuk melakukan pelatihan. Pada

saat pelatihan, pengguna akan mengisi formulir training untuk

menandakan kehadirannya di pelatihan tersebut. Kemudian

instruktur akan memeriksa formulir training apakah pengguna

yang hadir sesuai dengan daftar pengguna di halaman web,

jika terdapat perbedaan (pengguna tidak mengisi daftar

kehadiran), maka instruktur akan mengisi daftar kehadiran

yang kemudian di submit. Setelah di submit, developer akan

dikirimkan notifikasi email.

Workflow dari formulir training yang diusulkan dapat

dilihat pada Gambar 3.15 dibawah ini :

92

Gambar 3.15 Workflow Pelatihan.

93

7. Workflow Penutupan Proyek (Project Closing)

Apabila aplikasi telah dianggap selesai dan telah

memenuhi kebutuhan pengguna, maka developer akan

mengisi formulir project closing di halaman web, dan mengisi

keterangan jika ada. Setelah developer selesai mengisi

formulir project closing dan menekan tombol submit, maka

pengguna yang bersangkutan akan dikirimkan notifikasi

email. Pengguna akan melihat formulir project closing, dan

apabila pengguna tidak setuju pada penutupan proyek dan

menekan tombol reject, pengguna akan mengisi alasan

penolakan dan developer akan dikirimkan notifikasi email.

Apabila pengguna setuju pada penutupan proyek dan menekan

tombol approve, developer akan dikirimkan notifikasi email

dan proyek dinyatakan telah selesai.

Workflow dari formulir project closing yang diusulkan


94

Gambar 3.16 Workflow Penutupan Proyek.

3.2.8.2 Perancangan Diagram Use Case

Gambar 3.17 merupakan gambar diagram use case dari sistem

Pengajuan Aplikasi di IT Directorate BINUS University.

95

Gambar 3.17 Diagram Use Case.

96

Tabel 3.7 Dokumentasi Use Case.

Use Case Aktor Deskripsi

Mengisi Job Request User Approval User Approval mengisi

formulir pengajuan

aplikasi di web pengajuan

aplikasi.

Memeriksa Job Request Head User Approval Head User Approval

memeriksa formulir

pengajuan aplikasi yang

diajukan dan memilih

untuk menyetujui atau

menolak.

Manager IT Manager IT memeriksa

formulir pengajuan

aplikasi yang diajukan dan

memilih untuk menyetujui

atau menolak. Kemudian

Manager IT memilih

Developer yang akan

terlibat.

Mengisi User Requirement Developer Developer mengisi

formulir kebutuhan

pengguna di web

97

pengajuan aplikasi.

Memeriksa User Requirement User Approval User Approval memeriksa

formulir kebutuhan

pengguna yang diajukan

dan memilih untuk

menyetujui atau menolak.

Mengisi Testing Internal Developer Developer mengisi

formulir evaluasi internal

di web pengajuan aplikasi.

Memeriksa Testing Internal System Tester System Tester memeriksa

formulir evaluasi internal

yang diajukan dan


atau menolak.

Mengisi Testing Eksternal Developer Developer mengisi

formulir evaluasi eksternal

di web pengajuan aplikasi.

Memeriksa Testing Eksternal User Tester User Tester memeriksa

formulir evaluasi eksternal

yang diajukan dan


atau menolak.

Mengisi Pemberitahuan Developer Developer mengisi

Documents

BAB 3 ANALISIS DAN PERANCANGAN SOLUSI 3.1 Gambaran …thesis.binus.ac.id/doc/Bab3/2010-1-00236-IF-Bab 3.pdf · Untuk membuat aplikasi yang sesuai dengan permintaan dan kebutuhan pengguna,