PENERAPAN SCRUM DALAM AGILE DEVELOPMENT DAN USER-CENTERED DESIGN

DALAM PENGEMBANGAN SISTEM KNOWLEDGE REPOSITORY MANAGEMENT

DI DIVISI DIGITAL SERVICE PT TELEKOMUNIKASI INDONESIA Tbk.

LAPORAN

diajukan untuk memenuhi sebagian syarat kelulusan untuk

Mata Kuliah Program Latihan Akademik

Oleh:

Asep Saepul Achmad

1606172

PROGRAM STUDI ILMU KOMPUTER

DEPARTEMEN PENDIDIKAN ILMU KOMPUTER
FAKULTAS PENDIDIKAN MATEMATIKA DAN ILMU PENGETAHUAN ALAM
UNIVERSITAS PENDIDIKAN INDONESIA
BANDUNG
2019
 KATA PENGANTAR

Segala puji bagi Tuhan Yang Maha Esa, yang telah memberikan rahmat dan
hidayah-Nya sehingga penulis dapat menyelesaikan Laporan Program Latihan
Akademik (PLA) dengan judul “Penerapan Scrum dalam Agile Development dan
User-Centered Design dalam Pengembangan Sistem Knowledge Repository
Management di Divisi Digital Service PT Telekomunikasi Indonesia Tbk.”.

Laporan ini disusun untuk memenuhi tugas mata kuliah Program Latihan
Akademik (PLA) dan merupakan syarat kelulusan akademik pada Program Studi
Ilmu Komputer. Laporan ini dibuat berdasarkan hasil dari praktek kerja lapangan
yang dilakukan oleh penulis di Divisi Digital Service PT Telekomunikasi Indonesia
Tbk. kantor cabang Gegerkalong Hilir, Bandung.

Penulis Laporan PLA ini dapat terselesaikan tanpa peran serta beberapa
pihak. Oleh sebab itu penulis ingin berterimakasih yang sebesar-besarnya kepada:
1. Tuhan Yang Maha Esa yang telah memberikan kemudahan dalam menjalani
mata kuliah PLA.
2. Orang tua yang selalu mendoakan penulis sehingga kegiatan Program Latihan
Akademik dapat terselesaikan.
3. Ibu Dr. Rani Megasari, M.T. selaku Ketua Program Studi Ilmu Komputer
Universitas Pendidikan Indonesia.
4. Bapak Dr. Wahyudin, M.T. selaku Dosen Pembimbing Program Latihan
Akademik.
5. Bapak Adnan Sudrajat selaku Pembimbing Lapangan di PT Telekomunikasi
Indonesia Tbk.
6. Ibu Sendylenvi Regia selaku Manager Knowlegde Resource Management di
Unit General Affairs Divisi Digital Service.
7. Creation Team dan tim DEX yang senantiasa membantu dan membimbing
penulis dalam menyelesaikan pekerjaan yang diberikan.
8. Teman-teman angkatan 2016 Ilmu Komputer UPI dan semua pihak yang telah
membantu dalam pengerjaan laporan PLA ini, yang saya tidak bisa sebutkan
namanya satu persatu.

i
 Demikian Laporan Program Latihan Akademik ini dibuat. Segala bentuk
manfaat yang terkandung dalam laporan ini semoga dapat menjadi sesuatu yang
dapat dinikmati oleh beberapa generasi berikutnya. Segala bentuk kekurangan
dalam laporan ini juga semoga dapat menjadi pembelajaran pada generasi penerus
serta tak lupa juga penulis mengucapkan maaf atas kekurangan yang terdapat pada
laporan ini. Terima kasih.

Bandung, 17 Desember 2019

Asep Saepul Achmad

ii
 ABSTRAK

PT Telekomunikasi Indonesia, Tbk. adalah sebuah Badan Usaha Milik

Negara (BUMN) yang bergerak dalam bidang jasa telekomunikasi. Dengan
berkembangnya teknologi saat ini diperlukan untuk mengimplementasikan
teknologi dalam pengembangan sistem jaringan yang dapat dipergunakan
perusahaan dalam menjalankan visi dan misinya. PT Telekomunikasi Indonesia (PT
Telkom Indonesia) Divisi Digital Service tepatnya dalam pengembangan product
scooping khususnya digital product innovation, mengembangkan knowledge
repository management sebagai tempat penyimpanan pengetahuan dan dapat
digunakan di mana saja. Tujuan pengembangan knowledge repository management
adalah untuk meningkatkan penyimpanan, pemeliharaan, dan pemanfaatan
informasi dan pengetahuan yang diberikan kepada orang-orang yang memiliki hak
akses, serta untuk memantau tingkat pemanfaatan pengetahuan bagi perusahaan. .
Maka dari itu Program Latihan Akademik yang dilakukan oleh penulis adalah
mengembangkan software development dari perancangan dan pengembangan
sistem Knowlegde Repository Management menggunankan Agile Development,
User-Centered Design serta membuat dokumentasi pengembangan sistem ini,
mulai dari Requirement Analysis hingga Desain Sistem.

Keyword: Agile Development, User-Centered Design, Unitified Modeling

Language, Heuristic Evaluation.

iii
 DAFTAR ISI

KATA PENGANTAR ............................................................................................ i

ABSTRAK ............................................................................................................ iii

DAFTAR ISI ......................................................................................................... iv

DAFTAR TABEL ............................................................................................... vii

DAFTAR GAMBAR .......................................................................................... viii

DAFTAR LAMPIRAN ........................................................................................ xi

BAB I PENDAHULUAN .......................................................................................1

1.1. Latar Belakang ........................................................................................ 1

1.2. Identifikasi Masalah ................................................................................ 2

1.3. Tujuan Penelitian .................................................................................... 3

1.4. Ruang Lingkup ........................................................................................ 3

1.5. Sistematika Penulisan ............................................................................. 4

BAB II GAMBARAN UMUM PERUSAHAAN DAN KAJIAN PUSTAKA ...5

2.1. Profil Perusahaan .................................................................................... 5

2.1.1. Nama dan Logo Perusahaan .............................................................. 6
2.1.2. Visi .................................................................................................... 7
2.1.3. Misi ................................................................................................... 7
2.1.4. Struktur Grup Perusahaan ................................................................. 7
2.1.5. Budaya Perusahaan ........................................................................... 8
2.1.6. Divisi Digital Service PT Telekomunikasi Indonesia Tbk. .............. 9
2.1.7. Lokasi Divisi Digital Service PT Telekomunikasi Indonesia Tbk.. 11

2.2. Kajian Pustaka....................................................................................... 11

2.2.1. Software .......................................................................................... 11
2.2.2. Software Development .................................................................... 13
2.2.3. Metodologi dalam Pengembangan Perangkat Lunak ...................... 16

iv
 2.2.3. Requirements Analysis.................................................................... 20
2.2.4. Unitified Modeling Language ......................................................... 22
2.2.5. Agile Development ......................................................................... 24
2.2.6. Use Case .......................................................................................... 29
2.2.7. Information Architecture ................................................................. 33
2.2.8. User Flow / User Journey................................................................ 34
2.2.9. Activity Diagram............................................................................. 35
2.2.10. User-Centered Design dan Agile Development .......................... 37
2.2.11. Heuristic Evaluation.................................................................... 39

BAB III ANALISIS DAN PERANCANGAN ....................................................42

3.1. Metode Penelitian.................................................................................. 42

3.2. Analisis.................................................................................................. 42
3.2.1. Requirement .................................................................................... 42

3.3. Perancangan .......................................................................................... 45

3.3.1. Design Sprint................................................................................... 45
3.3.2. Backlog / Product Backlog.............................................................. 50
2.2.12. Mind Map dan Use Case ............................................................. 60

BAB IV HASIL KEGIATAN PLA .....................................................................63

4.1. Work Breakdown Structure ................................................................... 63

4.2. Pembagian Tugas .................................................................................. 66

4.3. Hasil Implementasi................................................................................ 68

4.3.1. Information Architecture (IA) ......................................................... 68
4.3.2. Use Case .......................................................................................... 72
2.2.13. User Flow .................................................................................... 72
2.2.14. Activity Diagram ......................................................................... 76
2.2.15. Desain Mockup dan Copywriting................................................ 82
2.2.16. Branding Development ................................................................ 87

v
 4.4. Pengujian ............................................................................................... 87

4.5. Hasil Pengujian ..................................................................................... 88

4.5.1. Kelebihan ........................................................................................ 90
4.5.2. Kekurangan ..................................................................................... 90

BAB V KESIMPULAN DAN SARAN ...............................................................92

5.1. Kesimpulan ........................................................................................... 92

5.2. Saran...................................................................................................... 92

DAFTAR PUSTAKA ...........................................................................................93

LAMPIRAN ..........................................................................................................95

vi
 DAFTAR TABEL

Tabel 2.1 Kelebihan dan Kekurangan Agile Development .................................. 29

Tabel 2.2 Simbol-simbol pada Use Case .............................................................. 32

Tabel 2.3 Simbol-simbol dalam Activity Diagram ............................................... 37

Tabel 2.4 Manifesto Agile dan Filosofi UCD ....................................................... 39

Tabel 3.1 Scrum Artifact Product Backlog sistem KRM...................................... 58

Tabel 3.2 User Role untuk Admin dan Superadmin .............................................. 60

Tabel 4.1 WBS Work Plan TW4 Desember ‘19 ................................................... 63

Tabel 4.2 WBS Terbaru Hasil Penelitian .............................................................. 65

Tabel 4.3 RACI Matrix ......................................................................................... 67

vii
 DAFTAR GAMBAR

Gambar 2.1 Logo Telkom Indonesia ...................................................................... 6

Gambar 2.2 Struktur Telkom Group ....................................................................... 8

Gambar 2.3 Telkom Culture ................................................................................... 8

Gambar 2.4 DDS Struktur Organisasi Telkom Indonesia..................................... 10

Gambar 2.5 Peta Lokasi Divisi Digital Service .................................................... 11

Gambar 2.6 Diagram Software Development Process .......................................... 17

Gambar 2.7 Class Diagram dari Diagram-Diagram UML .................................... 23

Gambar 2.8 Skema Siklus Agile Development ..................................................... 29

Gambar 2.9 Contoh extend dalam use case diagram ............................................ 32

Gambar 2.10 Contoh include dalam use case ....................................................... 33

Gambar 3.1 Metode Penelitian Pengembangan sistem KRM dengan Agile ........ 42

Gambar 3.2 Halaman Utama sistem Digital Administrative Management DDS.. 43

Gambar 3.5 User Journey Super Admin – proses ................................................. 47

Gambar 3.6 User Journey Super Admin – goal .................................................... 48

Gambar 3.7 User Journey Admin – proses............................................................ 48

Gambar 3.8 User Journey Admin - goal ............................................................... 48

Gambar 3.9 User Journey Approval – proses ....................................................... 49

Gambar 3.10 User Journey Approval – goal ........................................................ 49

viii
Gambar 3.11 User Journey Creator – proses ....................................................... 49

Gambar 3.12 User Journey Creator – goal .......................................................... 50

Gambar 3.13 User Journey Viewer – proses......................................................... 50

Gambar 3.14 User Journey Viewer – goal ......................................................... 50

Gambar 3.3 Use Case sistem Knowledge Repositroy Management ..................... 61

Gambar 3.4 Mind Map Knowledge Repository Management ............................... 62

Gambar 4.1 Information Architecture staff - leader ............................................. 69

Gambar 4.2 IA admin - superadmin ..................................................................... 70

Gambar 4.3 IA guest ............................................................................................. 71

Gambar 4.4 Use case sistem KRM terbaru ........................................................... 72

Gambar 4.5 User flow untuk staff – leader dan guest ........................................... 73

Gambar 4.6 User flow untuk admin – superadmin ............................................... 74

Gambar 4.7 User flow untuk guest........................................................................ 75

Gambar 4.8 Activity diagram - Login ................................................................... 76

Gambar 4.9 Activity diagram - Cari Dokumen ..................................................... 77

Gambar 4.10 Activity diagram - Unduh Dokumen ............................................... 78

Gambar 4.11 Activity diagram - Persetujuan Minta Izin Unduh Dokumen .......... 79

Gambar 4.12 Activity Diagram - Upload Dokumen ............................................. 80

Gambar 4.13 Activity diagram - Persetujuan Unggah Dokumen .......................... 81

ix
Gambar 4.14 Aplikasi desain mockup Figma ....................................................... 82

Gambar 4.15 Desain Halaman Beranda sebelum copywriting.............................. 86

Gambar 4.16 Desain halaman Beranda setelah copywriting................................. 87

Gambar 4.17 Branding sistem Knowledge Repository Management. .................. 87

x
 DAFTAR LAMPIRAN

Lampiran 1 Surat Pernyataan ................................................................................ 96

Lampiran 2 Formulir Permohonan PLA ............................................................... 97

Lampiran 3 Lembar Bimbingan ............................................................................ 98

Lampiran 4 Lembar Persetujuan Seminar ............................................................. 99

Lampiran 5 Lembar Penilaian ............................................................................. 100

Lampiran 6 Dokumentasi Kegiatan Program Laithan Akademik ....................... 104

Lampiran 7 Lembar Laporan Harian................................................................... 107

xi
 1

BAB I
PENDAHULUAN
1.1. Latar Belakang
Pengetahuan, informasi, dan data yang dapat diandalkan dianggap sangat
penting dalam penghidupan dan pengembangan suatu perusahaan. Pengetahuan
menjadi kunci utama dalam sebuah perusahaan yang merupakan modal intelektual
bagi perusahaan. Manajemen pengetahuan dalam perusahaan dibutuhkan supaya
dapat meningkatkan dan mendukung produktivitas pekerjaan serta menghasilkan
nilai baru bagi perusahaan. Melalui proses manajemen pengetahuan, perusahaan
berharap dapat mengelola pengetahuan dan menyebarluaskan pengetahuan untuk
semua orang didalam perusahaan. Tentunya manajemen yang kuat diperlukan agar
pengetahuan ini berakar pada setiap individu di perusahaan dengan dukunagn
infrastruktur untuk penyebaran informasi di dalam perusahaan. Salah satu tempat
yang digunakan oleh perusahaan dalam mengelola pengetahuan adalah membuat
sistem Knowledge Repository Management.
PT Telekomunikasi Indonesia (PT Telkom Indonesia) Divisi Digital
Service tepatnya dalam pengembangan product scooping khususnya digital product
innovation, mengembangkan knowledge repository management sebagai sistem
penyimpanan pengetahuan dan dapat digunakan di mana saja. Tujuan
pengembangan knowledge repository management adalah untuk meningkatkan
penyimpanan, pemeliharaan, dan pemanfaatan informasi dan pengetahuan yang
diberikan kepada orang-orang yang memiliki hak akses, serta untuk memantau
tingkat pemanfaatan pengetahuan bagi perusahaan. Salah satu output dari digital
product innovation adalah dokumen laporan dalam bentuk hasil penelitian bisnis,
hasil penelitian teknis, dan dokumen lainnya. Selain itu, karyawan Telkom
Indonesia juga sering membuat karya ilmiah atau riset pribadi untuk mendukung
pekerjaan mereka.
Divisi Digital Service (DDS) yang memiliki fungsi untuk "mengelola
penelitian tentang teknologi, infrastruktur, produk baru dan bisnis sesuai dengan
rencana strategis perusahaan" berencana menjadikan manajemen penyimpanan
pengetahuan sebagai tempat penyimpanan pengetahuan dan dapat digunakan di
mana saja (tidak perlu untuk jaringan Telkom Indonesia). Sebagai bentuk berbagi
 2

pengetahuan, akan ada kriteria dokumen, penomoran yang valid dan hak akses
untuk digunakan. Dokumen hasil research dan inovasi DDS sudah dibuat dengan
tahapan dan penomoran yang benar. Namun, saat ini DDS belum mempunyai
sistem knowledge management berbasis online sebagai sistem penyimpanan
dokumen hasil riset dan inovasi.
Berdasarkan permasalahan yang ada, perlu adanya pembangunan dan
pengembangan sistem Knowledge Repository Management. Maka, dibutuhkan
perancangan yang baik dalam pengembangan sistem ini agar bisa digunakan
dengan mudah oleh banyak orang. Oleh karena itu, diperlukan metode
pengembangan perangkat lunak yang sesuai dengan kebutuhan sistem Knowledge
Repository Management. Beberapa metode yang digunakan dalam pengembangan
sistem Knowledge Repository Management adalah Agile Development dan User-
Centered Design.
Diharapkan dalam PLA di PT Telekomunikasi Indonesia ini dapat menjadi
sebuah media yang dapat menjadikan kontribusi positif bagi perusahaan maupun
pemohon dalam pengembangan sistem Knowledge Repository Management.

1.2. Identifikasi Masalah

Berdasarkan permsalahan yang terdapat pada latar belakang, maka dapat
disimpulkan bahwa masalah yang ingin diselesaikan ialah:
1. Belum terbangunnya sistem Knowledge Repository Management sesuai
dengan kebutuhan DDS yang dapat diakses secara online dan digunakan
banyak orang.
2. Belum tercapainya user-friendly dalam tampilan sistem Knowledge
Repository Management.
3. Belum tercapainya metode software development yang sesuai dalam
pengembangan sistem Knowledge Repository Management dengan.
 3

1.3. Tujuan Penelitian

Beberapa tujuan dari PLA yang akan dilaksanakan pada PT Telekomunikasi
Indonesia yaitu:
1. Menerapkan Agile Development dalam proses pengembangan sistem
Knowledge Repository Management.
2. Menerapkan User-Centered Design dalam proses desain sistem Knowledge
Repository Management.
3. Meningkatkan teknik dokumentasi software development dalam
pengembangan sistem Knowledge Repository Management.
4. Membuat dokumentasi desain sistem dari sistem Knowledge Repository
Management.

1.4. Ruang Lingkup

Adapun ruang lingkup dalam pelaksanaan Program Latihan Akademik yang
dilaksanakan pada PT Telekomunikasi Indonesia yaitu:
1. Pengenalan
Pengenalan ini mencakup lingkungan kerja pembimbing, detail topik
riset yang akan dikembangkan, dan sistem internal yang bekerja di PT
Telekomunikasi Indonesia.
2. Orientasi Lapangan
Mempelajari tentang proses-proses yang ada di knowledge & resource
management, terutama fungsi yang berhubungan dengan bidang proyek sistem
Knowledge Repository Management yang akan dikembangkan oleh pemohon.
3. Tugas Khusus
Diikutsertakan dalam kegiatan atau proyek yang dapat menambah
pengetahuan mahasiswa yang disesuaikan dengan kebutuhan PT
Telekomunikasi Indonesia Tbk.
4. Membuat Produk PLA
Dalam melaksanakannya pemohon akan membuat desain sistem
Knowledge Repository Management yang akan menjadi desain rancangan
pengembangan sistem Knowledge Repository Management kedepannya.
 4

1.5. Sistematika Penulisan

Sistematika penyusunan pada laporan ini adalah sebagai berikut:

BAB I PENDAHULUAN

Berisi pembahasan masalah umum yang diangkat pada penelitian, di dalamnya

terdapat latar belakang, identifikasi masalah, tujuan penelitian dan sistematika
penulisan.

BAB II GAMBARAN UMUM PERUSAHAAN DAN KAJIAN PUSTAKA

Berisi mengenai kajia teori yang digunakan di dalam penelitian. Pada bagian ini
akan membahas tentang pengenalan PT Telkomunikasi Indonesia Tbk., Agile
Software Development, User-Centered Design, dan Scrum Methodology.

BAB III ANALISIS DAN PERANCANGAN

Analisis dan perancangan sistem yang di dalamnya terdapat pembahasan tentang

perancangan sistem Knowledge Repository Management, mulai dari User
Requirement hingga desain sistem.

BAB IV HASIL KEGIATAN PLA

Berisi tentang perancangan sistem Knowledge Repository Management serta

pengujian terhadap desain sistem berdasarkan skenario yang terdapat pada bab
sebelumnya.

BAB V PENUTUP

Berisi tentang pencapaian tujuan dari sistem dibuat. Juga terdapat saran berisi hal-
hal atau tujuan dari pembuatan sistem yang dirasa belum sempurna atau tidak
tercapai.
 5

BAB II
GAMBARAN UMUM PERUSAHAAN DAN KAJIAN PUSTAKA

2.1. Profil Perusahaan

PT Telekomunikasi Indonesia Tbk. (Persero) yang biasa disebut sebagai

Telkom Indonesia adalah sebuah perusahaan Badan Usaha Milik Negara yang
bergerak di bidang jasa teknologi informasi dan komunikasi industri dan jaringan
telekomunikasi di Indonesia. Saat ini Telkom Indonesia sedang diubah menjadi
perusahaan yang menerapkan telekomunikasi digital berorientasi pelanggan.
Transformasi ini akan membuat organisasi Telkom Indonesia lebih ramping
dan gesit dalam beradaptasi dengan perubahan dalam industri telekomunikasi yang
berlangsung sangat cepat. Organisasi baru ini juga diharapkan dapat meningkatkan
efisiensi dan efektivitas dalam menciptakan pengalaman pelanggan yang
berkualitas.
Telkom Indonesia saat ini mengelola enam portofolio bisnis yang melayani
empat segmen pelanggan, yaitu korporasi, perumahan, individu dan
lainnya. Portofolio bisnis Telkom Indonesia adalah sebagai berikut:
1. Mobile
Portofolio ini menawarkan produk mobile voice, SMS dan value added service,
serta mobile broadband. Produk tersebut ditawarkan melalui entitas anak,
Telkomsel, dengan merk Kartu Halo untuk pasca bayar dan simPATI, Kartu As
dan Loop untuk pra bayar.
2. Fixed
Portofolio ini memberikan layanan fixed service, meliputi fixed voice, fixed
broadband, dengan brand IndiHome.
3. Wholesale & International
Produk yang ditawarkan antara lain layanan interkoneksi, network service,
Wi-Fi, VAS, hubbing data center dan content platform, data dan internet, dan
solution.
 6

4. Network Infrastructure
Produk yang ditawarkan meliputi network service, satelit, infrastruktur dan
tower.
5. Enterprise Digital
Terdiri dari layanan information and communication technology platform
service dan smart enabler platform service.
6. Consumer Digital
Portofolio ini terdiri dari media dan edutainment service, seperti e-commerce
(blanja.com), video/TV dan mobile based digital service. Selain itu, kami juga
menawarkan digital life service seperti digital life style (Langit Musik dan
VideoMax), digital payment seperti TCASH, digital advertising and analytics
seperti bisnis digital advertising dan solusi mobile banking serta enterprise
digital service yang menawarkan layanan Internet of Things (IoT).

2.1.1. Nama dan Logo Perusahaan

Desain logo sangat penting bagi perusahaan. Logo adalah simbol
yang merupakan ciri khas perusahaan. Dimana logo akan menjadi simbol
khusus yang dapat memberikan penjelasan tentang citra suatu
perusahaan. Ini juga sering disebut sebagai branding atau identitas
perusahaan. Penggunaan logo produk atau kemasan produk dapat
meningkatkan gengsi pengguna atau konsumen dan meningkatkan
kepercayaan bagi konsumen yang menggunakannya. Mengingat peran logo
sangat penting untuk meningkatkan pemasaran produk/jasa dari
perusahaan, maka dibutuhkan desain logo yang menarik dan mudah diingat
oleh banyak konsumen.

Gambar 2.1 Logo Telkom Indonesia

 7

2.1.2. Visi
“Be the King of Digital in the Region”
Visi di atas berarti bahwa Telkom Indonesia berubah menjadi
perusahaan berbasis telekomunikasi digital, melalui penguatan konektivitas
broadband, pengembangan platform mediasi digital, dan peningkatan
layanan digital & layanan solusi. Telkom Indonesia juga mendigitalkan
proses bisnis internal dan mengadopsi budaya digital, untuk menciptakan
pengalaman pelanggan terbaik dan meningkatkan daya saing dan nilai
perusahaan.

2.1.3. Misi
“Lead Indonesian Digital Innovation and Globalization”

a. Telkom Indonesia memimpin peran aktif dalam meningkatkan daya

saing Indonesia.
b. Menjadi perusahaan digital terkemuka, Telkom Indonesia harus
menjadi panutan dalam mengembangkan ekosistem digital dan
kolaborasi untuk melakukan berbagai inovasi.
c. Telkom Indonesia mempromosikan dan memberdayakan inovasi &
pengembangan digital lokal.

2.1.4. Struktur Grup Perusahaan

Sebagai perusahaan teknologi informasi dan komunikasi terbesar
dan paling beragam di Indonesia, Telkom Indonesia mengadakan grup yang
sangat besar yang terdiri dari banyak anak perusahaan. Struktur anak
perusahaan Telkom Indonesia dapat dilihat pada Gambar dibawah ini.
 8

Gambar 2.2 Struktur Telkom Group

2.1.5. Budaya Perusahaan

Gambar 2.3 Telkom Culture

Sumber: Telkom, 2019
 9

“The Telkom Way” adalah budaya Perusahaan atau nilai-nilai

Perusahaan yang dimiliki Telkom Indonesia sejak 10 Juni 2013
sebagaimana ditentukan oleh Direksi PT Telekomunikasi Indonesia Tbk.

2.1.6. Divisi Digital Service PT Telekomunikasi Indonesia Tbk.

Divisi Digital Service adalah salah satu divisi “centralized” yang

diperankan untuk penyelenggaraan aktivitas bisnis dengan fokus pada
pengelolaan pengembangan product scooping khususnya digital product
innovation melalui coherence innovation, discovery, incubation &
acceleration (DIA) process, research, standardization & quality assurance
(RSQA) process dan big data analytic.

DDS memiliki lima fungsi utama, yaitu:

a. Mengelola penelitian tentang teknologi, infrastruktur, produk, dan
bisnis baru sesuai dengan rencana strategis perusahaan.

b. Mengelola TIMES (Telecommunication Information Media Education)

Pusat Pengembangan Produk melalui manajemen inkubasi inovasi.

c. Mengembangkan ekosistem bisnis baru yang dikembangkan melalui

tahap inkubasi inovasi dan terbukti mampu menjadi solusi bagi masalah
pelanggan nyata sehingga dapat menjadi portofolio bisnis baru Telkom
Indonesia.

d. Mengelola kesiapan implementasi teknologi, infrastruktur dan produk

melalui persiapan standar dan implementasi jaminan produk &
infrastruktur untuk memastikan kesesuaian rencana dan kualitas
implementasi produk dan infrastruktur ICT (Information
Communication Technology) di Telkom Group
 10

e. Mengelola rekomendasi untuk perbaikan bisnis, produk dan

infrastruktur, melalui implementasi riset operasional untuk
memberikan solusi terhadap masalah operasional manajemen produk
dan infrastruktur dalam bentuk analisis teknis.
Di bawah ini adalah struktur organisasi DDS Telkom Indonesia:

Gambar 2.4 DDS Struktur Organisasi Telkom Indonesia

Sumber: Telkom Indonesia Employee

Unit ini bertanggung jawab atas beberapa proyek seperti:

a. Innovation Day adalah kegiatan bagi karyawan Telkom Indonesia
untuk berbagi pengetahuan dengan karyawan lainnya. Kegiatan ini
mengambil bentuk seminar online yang disiarkan langsung di saluran
TV DDS di YouTube .
b. Kunjungan Industri adalah CSR untuk memperkenalkan lingkungan
kerja Telkom Indonesia ke lembaga yang ingin dikunjungi. Biasanya
untuk melakukan kunjungan dapat mendaftar di situs web kunjungan
industri DDS.
c. Program Magang memberikan kesempatan bagi siswa untuk
melakukan penelitian atau mendukung program kerja di lingkungan
bisnis DDS Telkom dalam jangka waktu 6 (enam) bulan hingga 1 (satu)
tahun.
 11

d. Manajemen sumber daya yang di tempat penilaian dan penilaian

peristiwa.
e. Human Centered Design plan adalah merancang produk atau layanan
sesuai dengan kebutuhan, kebiasaan, dan kemampuan manusia.
f. DDS TV adalah saluran video (YouTube dan situs web) atau streaming
langsung yang menampilkan semua aktivitas yang telah dilakukan oleh
unit DDS.
g. Pengembangan digital touch point menurut pengunjung dan intensif.

2.1.7. Lokasi Divisi Digital Service PT Telekomunikasi Indonesia

Tbk.

Kantor PT Telkom Indonesia, Tbk. Beralamat di Jl. Gegerkalong

Hilir no.47, Sukasari, Kota Bandung. Gambar dibawah ini merupakan
tampilan lokasi PT Telkom Indonesia, Tbk.

Gambar 2.05 Peta Lokasi Divisi Digital Service

2.2. Kajian Pustaka

2.2.1. Software

Perangkat lunak atau Software adalah sekumpulan instruksi, data,

atau program yang digunakan untuk mengoperasikan komputer dan
menjalankan tugas tertentu. Berlawanan dengan perangkat keras, yang
menggambarkan aspek fisik komputer, perangkat lunak adalah istilah
 12

umum yang digunakan untuk merujuk pada aplikasi, skrip, dan program
yang berjalan pada perangkat. Perangkat lunak dapat dianggap sebagai
bagian variabel dari komputer dan perangkat keras bagian yang tidak
berubah-ubah. Dalam ilmu komputer dan rekayasa perangkat lunak,
perangkat lunak komputer adalah semua informasi yang diproses oleh
sistem komputer, program, dan data. Perangkat lunak komputer mencakup
program komputer, perpustakaan, dan data terkait yang tidak dapat
dieksekusi, seperti dokumentasi online atau media digital.

Ada tipe-tipe dasar perangkat lunak:

 System software - menyediakan fungsi inti seperti sistem operasi,

manajemen disk, utilitas, manajemen perangkat keras, dan kebutuhan
operasional lainnya.
 Programming software - memberikan alat programmer seperti editor
teks, kompiler, linker, debuggers dan alat-alat lain untuk membuat kode.
 Application software - membantu pengguna melakukan tugas. Suite
produktivitas kantor, perangkat lunak manajemen data, pemutar media,
dan program keamanan adalah contohnya. Aplikasi juga mengacu pada
aplikasi web dan seluler seperti yang digunakan untuk berbelanja di
Amazon.com, bersosialisasi dengan Facebook atau memposting gambar
ke Instagram.
 Software development tool - seperti Kompilator atau Compiler untuk
bahasa pemrograman tingkat tinggi seperti Pascal dan bahasa
pemrograman tingkat rendah yaitu bahasa “rakitan”.
 Device driver yaitu penghubung antara hardware, dan software. Banyak
dipakai di swalayan, dan juga sekolah, yaitu penggunaan barcode
scanner pada aplikasi database lainnya.
 Firmware - seperti yang dipasang dalam jam tangan digital, dan
pengendali jarak jauh.
 Free 'libre' software dan Perangkat lunak sumber terbuka (open source
software)
 13

 Perangkat lunak gratis (freeware)

 Perangkat lunak uji coba (shareware / trialware)
 Perangkat lunak perusak (malware)
 Embedded software digunakan untuk mengontrol mesin dan perangkat
yang biasanya tidak dianggap komputer - jaringan telekomunikasi,
mobil, robot industri, dan lainnya. Perangkat ini, dan perangkat
lunaknya, dapat dihubungkan sebagai bagian dari Internet of Things
(IoT).

Desain dan implementasi perangkat lunak bervariasi tergantung

pada kompleksitas perangkat lunak. Sebagai contoh, desain dan pembuatan
Microsoft Word membutuhkan lebih banyak waktu daripada merancang dan
mengembangkan Microsoft Notepad karena yang terakhir memiliki fungsi
yang jauh lebih mendasar. Perangkat lunak biasanya dirancang dan dibuat
dalam Integrated Development Environments (IDE) seperti Eclipse, IntelliJ
dan Microsoft Visual Studio yang dapat menyederhanakan proses dan
mengkompilasi perangkat lunak (jika ada).

2.2.2. Software Development

Software development atau pengembangan perangkat lunak adalah

serangkaian kegiatan dalam ilmu komputer yang didedikasikan untuk
proses membangun, merancang, menggunakan, dan mendukung perangkat
lunak. Dengan kata lain, pengembangan perangkat lunak menangani semua
aspek penulisan dan menjalankan kode perangkat lunak. Software
Development bertujuan untuk mengembangkan sistem dan memberikan
panduan yang bertujuan untuk menyukseskan proyek pengembangan sistem
melalui tahap demi tahap (Carol & Doake, 2001). Pengembangan perangkat
lunak dapat mencakup penelitian, pengembangan baru, pembuatan
prototipe, modifikasi, penggunaan kembali, rekayasa ulang, pemeliharaan,
atau kegiatan lain apa pun yang menghasilkan produk perangkat lunak.
 14

Selama beberapa tahun terakhir, perangkat lunak telah menjadi

komponen vital dari hampir setiap bisnis. Keberhasilan semakin tergantung
pada penggunaan perangkat lunak sebagai senjata kompetitif. Lebih dari
satu dekade yang lalu, mencari biaya yang lebih rendah dan akses ke sumber
daya terampil, banyak organisasi mulai bereksperimen dengan fasilitas
pengembangan perangkat lunak yang terletak jauh dan dengan outsourcing.
Beberapa faktor telah mempercepat tren ini adalah sebagai berikut
(Herbsleb & Moitra, 2001):

 Kebutuhan untuk memanfaatkan kumpulan sumber daya global untuk

berhasil dan bersaing secara kompetitif menggunakan sumber daya
yang langka, di mana pun berada;
 Keuntungan bisnis kedekatan dengan pasar, termasuk pengetahuan
pelanggan dan kondisi lokal, serta niat baik yang ditimbulkan oleh
investasi lokal;
 Pembentukan cepat korporasi virtual dan tim virtual untuk
mengeksploitasi peluang pasar;
 Tekanan berat untuk meningkatkan waktu-pasar dengan menggunakan
perbedaan zona waktu dalam pengembangan "sepanjang waktu"; dan
 Kebutuhan akan fleksibilitas untuk memanfaatkan peluang merger dan
akuisisi di mana pun mereka hadir.

Akibatnya, pengembangan perangkat lunak semakin menjadi usaha

multisite, multikultural, dan didistribusikan secara global. Para insinyur,
manajer, dan eksekutif menghadapi banyak tantangan yang hebat di
berbagai tingkatan, mulai dari teknis hingga sosial dan budaya. Perangkat
lunak dapat dikembangkan untuk berbagai keperluan, tiga yang paling
umum adalah untuk memenuhi kebutuhan spesifik dari klien / bisnis
tertentu (kasus dengan perangkat lunak khusus), untuk memenuhi
kebutuhan yang dirasakan dari sejumlah pengguna potensial (kasus dengan
komersial dan perangkat lunak open source), atau untuk penggunaan
 15

pribadi (mis. seorang ilmuwan dapat menulis perangkat lunak untuk

mengotomatiskan tugas biasa).

Pengembangan Perangkat Lunak melibatkan alat, metodologi, dan

proses yang diperlukan untuk membuat perangkat lunak, juga menyangkut
kode dan algoritma yang harus ditulis oleh fisikawan, pembuat perangkat,
ilmuwan layanan, ahli kimia, dan pembuat perangkat keras selama
melakukan pekerjaan mereka. Selain itu, pengembangan perangkat lunak
juga melibatkan aktivitas individu-individu terampil yang
mengembangkan kode perangkat lunak khusus proyek meskipun mereka
sendiri bukan pengembang perangkat lunak.

Pengembangan perangkat lunak juga menyinggung pada masalah ilmu

komputer inti lainnya, diantaranya adalah:

 Interaktivitas dan interoperabilitas. Pengembang perangkat lunak perlu

mengantisipasi apa yang salah dan tindakan pencegahan apa yang dapat
diambil untuk memastikan program perangkat lunak yang berbeda
dapat bekerja bersama. Mereka juga perlu memperhitungkan "mashup"
teknologi perangkat lunak baru dengan sistem perangkat lunak lama.
 Keamanan dan Privasi. Pengembang perangkat lunak harus
mengamankan integritas operasi perangkat lunak; memastikan privasi
pengguna; mencegah pelanggaran keamanan data, dan mengakomodasi
redudansi untuk melindungi dari hasil yang tidak diinginkan.

Pengembangan perangkat lunak dilakukan oleh programmer,

software engineer, dan software developer. Peran-peran ini berinteraksi
dan tumpang tindih, dan dinamika di antara mereka sangat bervariasi di
seluruh departemen dan masyarakat pembangunan. Programmer, atau
coders, menulis kode sumber ke komputer program untuk tugas-tugas
tertentu seperti menggabungkan basis data, memproses pesanan online,
komunikasi routing, melakukan pencarian atau menampilkan teks dan
grafik. Pemrogram biasanya menafsirkan instruksi dari pengembang dan
 16

insinyur perangkat lunak dan menggunakan bahasa pemrograman seperti C

++ atau Java untuk melaksanakannya.

Software engineers menerapkan prinsip-prinsip rekayasa untuk

membangun perangkat lunak dan sistem untuk menyelesaikan masalah.
Mereka menggunakan bahasa pemodelan dan alat-alat lain untuk
menemukan solusi yang sering dapat diterapkan untuk masalah secara
umum, bukan hanya penyelesaian untuk contoh atau klien tertentu. Solusi
rekayasa perangkat lunak mematuhi metode ilmiah dan harus bekerja di
dunia nyata, seperti dengan jembatan atau elevator. Software developers
memiliki peran yang kurang formal daripada insinyur dan dapat terlibat erat
dengan bidang proyek tertentu - termasuk kode penulisan. Pada saat yang
sama, mereka mendorong siklus pengembangan perangkat lunak secara
keseluruhan - termasuk bekerja lintas tim fungsional untuk mengubah
persyaratan menjadi fitur, mengelola tim dan proses pengembangan, dan
melakukan pengujian dan pemeliharaan perangkat lunak.

2.2.3. Metodologi dalam Pengembangan Perangkat Lunak

Software development process (bisa juga disebut software

development methodology, model, atau life cycle) adalah framework atau
proses yang membagi pekerjaan pengembangan perangkat lunak ke dalam
fase yang berbeda untuk menyusun, merencanakan, dan mengendalikan
proses pengembangan perangkat lunak. Software development process bisa
juga disebut Software Development Life Cycle (SDLC). Metodologi dapat
mencakup pra-definisi kiriman dan “artefak” tertentu yang dibuat dan
diselesaikan oleh tim proyek untuk mengembangkan atau memelihara
aplikasi (Burns & Dennis, 1985).

Ada beberapa yang berbeda untuk pengembangan perangkat lunak:

beberapa mengambil pendekatan yang lebih terstruktur, berbasis rekayasa
digunakan untuk mengembangkan solusi bisnis, sedangkan yang lain
mungkin mengambil pendekatan yang lebih bertahap, di mana perangkat
 17

lunak berkembang seiring dikembangkan sepotong demi sepotong. Satu

metodologi pengembangan sistem belum tentu cocok untuk digunakan oleh
semua proyek. Setiap metodologi yang tersedia bisa digunakan untuk jenis
proyek tertentu, berdasarkan berbagai pertimbangan teknis, organisasi,
proyek, dan tim dalam proyek tersebut (Shi, Ph, Murthy, & Ph, 2011).

Gagasan utama Software Development Life Cycle (SDLC) adalah "untuk

melanjutkan pengembangan sistem informasi dengan cara yang tenang dan
berhati-hati, terstruktur dan metodis, membutuhkan setiap tahap siklus
hidup - dari awal gagasan hingga pengiriman sistem akhir - untuk menjadi
dilakukan secara kaku dan berurutan " dalam konteks kerangka kerja yang
diterapkan. Sasaran utama kerangka metodologi ini adalah "untuk
mengembangkan sistem bisnis fungsional skala besar di era konglomerat
bisnis dengan skala besar. Aktivitas sistem informasi berputar di sekitar
pemrosesan data dan rutinitas angka-angka" (Elliott, 2004).

Gambar 2.6 Diagram Software Development Process

Aktivitas yang dilakukan pada saat proses pengembangan perangkat lunak

adalah sebagai berikut:
 18

 Identifikasi Kebutuhan
Software dibuat dan dibangun dari kebutuhan. Kebutuhan
tersebut bisa muncul dari mana saja dengan berbagai macam
kondisi. Sebelum suatu produk diciptakan, maka dia harus
memerlukan bahan. Bahan-bahan tersebut tidak bisa tersedia
sebagai kebutuhan awal dari suatu produk jika bahan tersebut belum
diidentifikasi sebagai bahan yang bagus dan cocok untuk produk
yang akan dibuat. Seperti halnya dengan kebutuahan dalam
pengembangan perangkat lunak, pengembang harus mencari
kebutuhan yang cocok untuk software yang akan dibangun atau
dikembangkan. Kebutuhan tersebut bisa bersumber dari ilmu
komputer maupun dari luar ilmu komputer.
Permisalan identifikasi kebutuhan perangkat lunak bisa dilihat dari
apa yang dipelajari oleh seseorang. Contohnya, Siswa teknik belajar
teknik dan jarang terpapar keuangan atau pemasaran. Siswa
pemasaran belajar pemasaran dan jarang terpapar keuangan atau
teknik. Sebagian besar dari kita menjadi spesialis hanya dalam satu
bidang. Untuk memperumit masalah, beberapa dari kita bertemu
orang-orang interdisipliner di dunia kerja, jadi ada beberapa peran
untuk ditiru. Namun, perencanaan produk perangkat lunak sangat
penting untuk keberhasilan pengembangan dan benar-benar
membutuhkan pengetahuan berbagai disiplin ilmu.

 Planning
Tanpa rencana yang sempurna, menghitung kekuatan dan
kelemahan proyek, pengembangan perangkat lunak tidak ada
artinya. Perencanaan memulai proyek dengan sempurna dan
memengaruhi kemajuannya secara positif. Perencanaan adalah
sasaran dari setiap kegiatan dan ingin menemukan hal-hal yang
berkaitan dalam proyek. Tugas penting dalam membuat program
perangkat lunak adalah mengekstraksi persyaratan atau analisis
persyaratan (Ralph & Wand, 2009). Pelanggan biasanya memiliki
 19

gagasan abstrak tentang apa yang mereka inginkan sebagai hasil

akhir atau sebuah produk tetapi tidak tahu perangkat lunak apa yang
harus dilakukan. Software engineer yang terampil dan
berpengalaman mengakui persyaratan tidak lengkap, ambigu, atau
bahkan bertentangan pada saat ini.

 Desain
Setelah persyaratan ditetapkan ketika identifikasi kebutuhan,
desain perangkat lunak dapat ditetapkan dalam dokumen desain
perangkat lunak. Dokumen tersebut melibatkan desain awal atau
desain tingkat tinggi dari modul-modul utama dengan gambaran
keseluruhan (seperti diagram blok) tentang bagaimana bagian-
bagiannya bersatu. Bahasa, sistem operasi, dan komponen perangkat
keras semuanya harus diketahui saat ini. Kemudian desain rinci
dibuat, mungkin dengan prototyping sebagai bukti konsep atau
untuk memperkuat persyaratan.
 Implementasi, Testing, dan Dokumentasi
Implementasi adalah bagian dari proses di mana software
engineer memprogram kode untuk proyek tersebut. Pengujian
perangkat lunak adalah “fase integral” yang penting dari proses
pengembangan perangkat lunak. Bagian dari proses ini memastikan
bahwa cacat dari program yang dibuat dikenali sesegera mungkin.
Dalam beberapa proses, umumnya dikenal sebagai test-driven
development, yaitu tes dapat dikembangkan sesaat sebelum
implementasi dan berfungsi sebagai panduan untuk implementasi
yang sesuai dengan software yang dibuat. Mendokumentasikan
desain perangkat lunak bertujuan untuk memelihara dan
meningkatkan kulaias perangkat lunak, serta bisa dilakukan
sepanjang pengembangan. Proses rekayasa perangkat lunak yang
dipilih oleh tim pengembang akan menentukan berapa banyak
dokumentasi internal (jika ada) yang diperlukan.
 20

 Deployment dan Maintenance

Deployment dimulai langsung setelah kode diuji dengan
tepat, disetujui untuk dirilis, dan dijual atau didistribusikan ke
lingkungan produksi. Ini mungkin melibatkan instalasi, kustomisasi
(seperti dengan menetapkan parameter ke nilai-nilai pelanggan),
pengujian, dan mungkin periode evaluasi yang diperpanjang.
Pelatihan dan dukungan perangkat lunak sangatlah penting, karena
perangkat lunak hanya efektif jika digunakan dengan benar.
Maintenance dan meningkatkan perangkat lunak untuk mengatasi
kesalahan atau persyaratan yang baru ditemukan dapat
membutuhkan waktu dan upaya yang substansial, karena
persyaratan yang terlewat dapat memaksa mendesain ulang
perangkat lunak. Dalam kebanyakan kasus, pemeliharaan
diperlukan secara berkala untuk memperbaiki masalah yang
dilaporkan dan menjaga perangkat lunak tetap berjalan.

2.2.3. Requirements Analysis

Requirements Analysis atau Requirements engineering mengacu

pada proses mendefinisikan, mendokumentasikan dan memelihara
persyaratan dalam proses desain teknik. Ini adalah peran umum dalam
rekayasa sistem dan rekayasa perangkat lunak. Requirements Analysis
berfokus pada tugas-tugas yang menentukan kebutuhan atau kondisi untuk
memenuhi produk atau proyek yang baru atau diubah, dengan
mempertimbangkan persyaratan yang mungkin bertentangan dari berbagai
stakeholder yang berkepentingan, menganalisis, mendokumentasikan,
memvalidasi dan mengelola persyaratan perangkat lunak atau sistem
(Kotonya & Sommerville, 1998).

Requirements Analysis sangat penting untuk keberhasilan atau

kegagalan suatu sistem atau proyek perangkat lunak. Persyaratan harus
didokumentasikan, dapat ditindaklanjuti, dapat diukur, diuji, dilacak, terkait
 21

dengan kebutuhan atau peluang bisnis yang teridentifikasi, dan ditetapkan

ke tingkat rincian yang cukup untuk desain sistem.

Kegiatan yang terlibat dalam requirements analysis sangat

bervariasi, tergantung pada jenis sistem yang dikembangkan dan praktik
khusus organisasi yang terlibat. Aktivitas yang dimaksud adalah sebagai
berikut:

 Requirements inception - Pengembang dan pemangku kepentingan

bertemu, yang terakhir ditanya tentang kebutuhan dan keinginan
mereka mengenai produk perangkat lunak.
 Analisis dan negosiasi persyaratan - Persyaratan diidentifikasi
(termasuk yang baru jika pembangunan itu berulang) dan konflik
dengan pemangku kepentingan diselesaikan. Baik alat tertulis maupun
grafis (yang terakhir biasa digunakan dalam tahap desain tetapi
beberapa menemukan mereka membantu pada tahap ini, juga) berhasil
digunakan sebagai alat bantu. Contoh alat analisis tertulis: kasus
penggunaan dan cerita pengguna. Contoh alat grafis: UML dan LML.
 Pemodelan sistem - Beberapa bidang teknik (atau situasi tertentu)
mengharuskan produk dirancang dan dimodelkan sepenuhnya sebelum
konstruksi atau fabrikasi dimulai dan, oleh karena itu, fase desain harus
dilakukan sebelumnya. Banyak bidang mungkin menurunkan model
sistem dengan Bahasa Pemodelan Siklus Hidup, sedangkan yang lain,
mungkin menggunakan UML. Catatan: Di banyak bidang, seperti
rekayasa perangkat lunak, sebagian besar kegiatan pemodelan
diklasifikasikan sebagai aktivitas desain dan bukan sebagai aktivitas
rekayasa kebutuhan.
 Spesifikasi persyaratan - Persyaratan didokumentasikan dalam artefak
formal yang disebut Requirements Specification (RS), yang akan
menjadi resmi hanya setelah validasi. RS dapat berisi informasi tertulis
dan grafis (model) jika perlu. Contoh: Software Requirements
Specification (SRS).
 22

 Validasi persyaratan - Memeriksa bahwa persyaratan dan model yang

didokumentasikan konsisten dan memenuhi kebutuhan pemangku
kepentingan. Hanya jika draf akhir melewati proses validasi, RS
menjadi resmi.
 Manajemen persyaratan - Mengelola semua kegiatan yang terkait
dengan persyaratan sejak awal, mengawasi saat sistem dikembangkan
dan, bahkan sampai setelah digunakan (mis., Perubahan, ekstensi, dll.)

Aktivitas diatas kadang-kadang disajikan sebagai tahap kronologis

meskipun, dalam praktiknya, ada banyak interleaving dari kegiatan ini.

2.2.4. Unitified Modeling Language

Unified Modeling Language (UML) adalah bahasa spesifikasi
standar untuk mendokumentasikan, menspesifikasikan, dan membangun
sistem perangkat lunak. UML adalah metodologi untuk mengembangkan
sistem OOP dan sekelompok perangkat tool untuk mendukung
pengembangan sistem tersebut. UML juga sebagai dasar bagi perangkat
desain berorientasi objek dari IBM. UML dikembangkan sebagai suatu alat
untuk analisis dan desain berorientasi objek oleh Grady Booch, Jim
Rumbaugh, dan Ivar Jacobson. Namun demikian UML dapat digunakan
untuk memahami dan mendokumentasikan setiap sistem informasi.
Penggunaan UML dalam industri terus meningkat. Ini merupakan standar
terbuka yang menjadikannya sebagai bahasa pemodelan yang umum dalam
industri peranti lunak dan pengembangan sistem (Dharwiyanti & Wahono,
2003).

UML mempunyai cara untuk memvisualisasikan cetak biru

arsitektur sistem dalam diagram, termasuk elemen-elemen seperti
(Specification, 2007):
 segala kegiatan (pekerjaan);
 komponen individual dari sistem dan bagaimana mereka dapat
berinteraksi dengan komponen perangkat lunak lain;
 bagaimana sistem akan berjalan;
 23

 bagaimana entitas berinteraksi dengan orang lain (komponen dan

antarmuka);
 antarmuka pengguna eksternal.

Meskipun awalnya ditujukan untuk dokumentasi desain berorientasi

objek, UML telah diperluas ke set dokumentasi desain yang lebih besar
(seperti yang tercantum di atas), dan telah ditemukan bermanfaat dalam
banyak konteks. UML memiliki banyak jenis diagram, yang dibagi menjadi
dua kategori. Beberapa tipe mewakili informasi struktural, dan sisanya
mewakili tipe perilaku umum, termasuk beberapa tipe yang mewakili
berbagai aspek interaksi. Diagram ini dapat dikategorikan secara hierarkis
seperti yang ditunjukkan pada diagram berikut:

Gambar 2.7 Class Diagram dari Diagram-Diagram UML

Structure diagrams menekankan hal-hal yang harus ada dalam

sistem yang dimodelkan. Karena diagram struktur mewakili struktur,
diagram tersebut digunakan secara luas dalam mendokumentasikan
arsitektur perangkat lunak sistem perangkat lunak. Sebagai contoh, diagram
komponen menjelaskan bagaimana sistem perangkat lunak dipecah menjadi
beberapa komponen dan menunjukkan ketergantungan di antara komponen-
komponen ini.
 24

Behavior diagram menekankan apa yang harus terjadi dalam sistem

yang dimodelkan. Karena diagram perilaku menggambarkan perilaku suatu
sistem, diagram perilaku digunakan secara luas untuk menggambarkan
fungsionalitas sistem perangkat lunak. Sebagai contoh, diagram aktivitas
menggambarkan kegiatan bisnis dan operasional langkah demi langkah
komponen dalam suatu sistem.

Interaction diagram, bagian dari diagram perilaku, menekankan

aliran kontrol dan data di antara hal-hal dalam sistem yang dimodelkan.
Sebagai contoh, diagram urutan menunjukkan bagaimana objek
berkomunikasi satu sama lain mengenai urutan pesan.

2.2.5. Agile Development

Agile Development Methods adalah sekelompok metodologi
pengembangan perangkat lunak yang didasarkan pada prinsip-prinsip yang
sama atau pengembangan sistem jangka pendek yang memerlukan adaptasi
cepat dari pengembang terhadap perubahan dalam bentuk apapun. Agile
Development didasarkan pada kerja tim, kolaborasi erat dengan pelanggan
dan pemangku kepentingan, fleksibilitas, dan kemampuan untuk cepat
menanggapi perubahan. Agile development methods merupakan salah satu
dari metodologi pengembangan perangkat lunak yang digunakan dalam
pengembangan perangkat lunak.

Blok bangunan dasar agile development adalah iterasi; masing-

masing termasuk perencanaan, analisis, desain, pengembangan, dan
pengujian. Metode gesit tidak memerlukan dokumentasi komprehensif di
awal. Sehingga saat membuat perangkat lunak dengan menggunakan agile
development methods diperlukan inovasi dan responsibiliti yang baik antara
tim pengembang dan klien agar kualitas dari perangkat lunak yang
dihasilkan bagus dan kelincahan dari tim seimbang.

A. Manifesto untuk Agile Software Development

 25

 Individu dan interaksi atas proses dan alat. Lebih penting daripada
proses dan alat, di dalam agile interaksi antar anggota tim sangatlah
penting, karena tanpa adanya interaksi yang baik maka proses
pembuatan perangkat lunak tidak akan berjalan sesuai rencana.
 Working software atas dokumentasi yang komprehensif. Lebih
penting daripada dokumentasi yang lengkap, saat melakukan proses
demonstrasi kepada klien, perangkat lunak yang berfungsi dengan
baik akan lebih berguna daripada dokumentasi yang lengkap.
 Kolaborasi pelanggan atas negosiasi kontrak. Lebih penting
daripada negosiasi kontrak, salah satu ciri dari agile adalah klien
menjadi bagian dari tim pengembangan perangkat lunak.
Kolaborasi yang baik dengan klien saat proses pembuatan
perangkat lunak sangatlah penting ketika menggunakan agile.
Karena fungsi-fungsi dari perangkat lunak yang dikembangkan
harus terus menerus dibicarakan dan diimprovisasi disesuaikan
dengan keinginan klien.
 Menanggapi perubahan setelah mengikuti rencana. Lebih penting
daripada mengikuti rencana, agile development methods berfokus
terhadap kecepatan respon tim ketika klien menginginkan
perubahan saat proses pembuatan perangkat lunak.

A. Tujuan Agile Development Methods

Secara garis besar tujuan dirumuskannya agile development
methods, yaitu:

1. High-value & working App system, diharapkan dengan

memakai agile development methods dapat dihasilkan
perangkat lunak yang mempunyai nilai jual yang tinggi, biaya
pembuatan bisa di tekan dan perangkat lunak bisa berjalan
dengan baik.
2. Iterative, incremental, evolutionary, agile adalah metode
pengembangan perangkat lunak yang iteratif, selalu mengalami
 26

perubahan, dan evolusioner. Tim harus bekerja dalam waktu

yang singkat (biasanya 1-3 minggu) dan juga selalu menambah
fungsionalitas dari perangkat lunak sesuai dengan kebutuhan
klien. Agile dapat dianalogikan ketika seseorang ingin pergi ke
suatu kota dan dia tidak tahu jalannya. Lalu bagaimana dia bisa
sampai tujuan? Dengan sering bertanya kepada orang yang dia
temui dijalan hingga dia sampai di tempat tujuan.
3. Cost control & value-driven development, salah satu tujuan
dari agile yaitu pengembangan perangkat lunak disesuaikan
dengan kebutuhan pengguna, tim bisa dengan cepat merespon
kebutuhan yang diinginkan pengguna sehingga waktu dan biaya
pembuatan perangkat lunak bisa dikontrol.
4. High-quality production, walaupun biaya pembuatan perangkat
lunak bisa ditekan dan proses pembuatan bisa dipercepat, tetapi
kualitas dari perangkat lunak yang dibuat harus tetap dijaga.
Dengan melakukan tes setiap fungsionalitas perangkat lunak
setelah selesei dibuat berarti agile juga mengakomodir
kebutuhan ini.
5. Flexible & risk management, jika kita menggunakan metode
pembuatan yang biasanya dipakai, jika ingin mengubah
fungsionalitas dari wireframe yang telah dibuat di butuhkan
proses yang rumit. Mulai dari pertemuan dengan sistem analis
untuk mengubah sistem perangkat lunak, perubahan rencana
rilis produk hingga perubahan biaya produksi. Pertemuan
dengan klien untuk melakukan tes perangkat lunak juga sering
dilakukan sehingga fungsionalitas perangkat lunak mudah
diubah dan akhirnya kegagalan perangkat lunakpun bisa
diminimalisir.
6. Collaboration, dengan menggunakan agile, tim pengembang
diharuskan sering bertemu untuk membahas perkembangan
proyek dan feedback dari klien yang nantinya akan ditambahkan
 27

dalam perangkat lunak, sehingga tim bisa berkolaborasi dengan

maksimal.
7. Self-organizing, self-managing teams, rekrut orang terbaik,
beri dan dukung kebutuhan mereka dan biarkan mereka bekerja.
Dengan agile, developer dapat memanajemen dirinya sendiri,
sedangkan manajer tim hanya bertugas
mengkolaborasikan developer perangkat lunak dengan klien.
Sehingga terciptalah tim yang solid.

B. Cara Kerja Agile Development Methods

1. Tim Agile Development
Komposisi dari sebuah tim software development yaitu:
a) Product Owner / Client. Tugasnya ialah menentukan fungsi
dari perangkat lunak yang akan di buat, melakukan testing
dan memberikan feedback.
b) Project Manager / Scrum Master. Tugasnya ialah
mengkolaborasikan developer dengan klien, membuat dan
mengevaluasi target pengerjaan perangkat lunak.
c) Sistem Analis. Tugasnya ialah membuat arsitektur sistem
dari perangkat lunak yang akan dibuat.
d) Developer. Tugasnya ialah coding program. Developer
Merupakan titik vital dalam tim, tanpa developer perangkat
lunak tidak akan bisa dibuat.
2. Story
Story adalah daftar kebutuhan atau fitur yang nanti akan
dibuat. Story berisi apa yang klien kehendaki, dan ditulis dalam
bahasa yang dimengerti klien. Dalam scrum methodology, story
adalah bagian paling penting.
Komposisi dari story adalah sebagai berikut:
a) ID – Nomor Identitas.
b) Nama – Nama story. 2 sampai 10
 28

c) Kepentingan – Derajat kepentingan bersumber dari client

terhadap story. Derajat tersebut menggunakan deret
Fibonacci. Tinggi rendahnya prioritas pengerjaannya
tergantung pada nilai derajatnya.
d) Perkiraan awal – Perkiraan awal tentang berapa banyak kerja
yang diperlukan tim untuk mengimplementasikan sebuah
story.
e) Demo – Deskripsi pendemoan dari sebuah story.

3. Sprint
Sprint (Rapat perencanaan pembuatan perangkat lunak dilakukan 2-
8 minggu sekali), yang perlu diperhatikan saat melaksanakan sprint
adalah sebagai berikut (Kniberg, 2007):

1) Tujuan sprint.
2) Daftar anggota tim harus lengkap.
3) Sprint backlog (daftar story yang akan diikutkan dalam
sprint).
4) Tanggal demo yang pasti.
5) Tempat dan waktu yang jelas untuk pelaksanaan sprint
berikutnya.
 29

Gambar 2.8 Skema Siklus Agile Development

Contoh sprint:
Sprint 1, tim membuat fungsi login, logout dan demo
perangkat lunak akan dilakukan 3 minggu kemudian. Setelah
dilakukan demo untuk mengevaluasi kerja yang dilakukan tim pada
Sprint 1, maka Sprint 1 dianggap selesei. Bahan evaluasi dari Sprint
1 akan dibawa ke Sprint 2 begitu seterusnya sampai aplikasi selesei
dikerjakan.

C. Kelebihan dan Kekurangan Agile Development

Kelebihan Kekuarangan

1) Agile tidak akan

berjalan dengan
1) 82% Menambah
baik jika komitmen
produktivitas tim.
tim kurang.
2) 77% Menambah
2) Tidak cocok dalam
kualitas perangkat
skala tim yang
lunak.
besar (>20 orang).
3) 78% Menambah
3) Perkiraan waktu
kepuasan klien.
release dan harga
4) 37% Menghemat
perangkat lunak
biaya.
sulit ditentukan.

Tabel 2.001 Kelebihan dan Kekurangan Agile Development

2.2.6. Use Case

Use case adalah struktur untuk mendokumentasikan persyaratan

fungsional untuk suatu sistem, biasanya melibatkan perangkat lunak,
apakah itu baru atau sedang diubah. Setiap use case menyediakan
 30

serangkaian skenario yang menyampaikan bagaimana sistem harus

berinteraksi dengan pengguna manusia atau sistem lain, untuk mencapai
tujuan bisnis tertentu. Kasus penggunaan biasanya menghindari jargon
teknis, lebih memilih bahasa pengguna akhir atau ahli domain. Kasus
penggunaan sering ditulis bersama oleh insinyur persyaratan dan pemangku
kepentingan. Use case adalah alat yang tampak sederhana untuk
menggambarkan perilaku perangkat lunak atau sistem. Sebuah use case
berisi deskripsi tekstual tentang cara-cara pengguna dimaksudkan untuk
bekerja dengan perangkat lunak atau sistem. Kasus penggunaan tidak boleh
menggambarkan cara kerja internal sistem, dan mereka juga tidak boleh
menjelaskan bagaimana sistem itu akan dilaksanakan. Sebaliknya, mereka
menunjukkan langkah-langkah yang diperlukan untuk melakukan tugas
tanpa asumsi berurutan.

Adapun syarat penamaan pada use case digram sendiri adalah nama
didefinisikan sesederhana mungkin sehingga bisa dipahami. Ada dua hal
utama pada use case yaitu pendefinisian apa yang disebut aktor dan use case.

 Use case merupakan fungsionalitas yang disediakan sistem sebagai

unit-unit yang saling bertukar pesan antar unit atau aktor

 Aktor adalah orang atau system lain yang berinteraksi dengan

system yang akan dibuat, jadi meskipun simbol dari aktor adalah
gambar orang tapi aktor belum tentu merupakan orang

Berikut adalah simbol-simbol yang ada pada diagram use case:

Simbol Deskripsi

Use case Use case adalah fungsionalitas yang

disediakan sistem sebagai unit-unit
yang saling bertukar pesan antar unit
atau actor. Biasanya use case diberikan
nama use case
 31

penamaan dengan menggunakan kata

kerja di awal frase nama use cass.

Aktor / actor Aktor adalah orang, proses, atau sistem

lain yang berinteraksi dengan sistem
informasi yang akan dibuat, jadi
meskipun simbol dari aktor ialah
gambar orang, tapi aktor belum tentu
merupakan orang. Biasanya penamaan
aktor dinamakan menggunakan kata

nama aktor benda di awal frase nama actor.

Asosiasi / association Asosiasi adalah komunikasi antara

Eksternal / extend
<<extend>>
Generalisasi / generalization
aktor dan use case yang berpartisipasi
pada use case diagram atau use case
yang memiliki interaksi dengan aktor.
Asosiasi merupakan simbol yang
digunakan untuk menghubungkan link
antar elemen.
Relasi use case tambahan ke sebuah
use case dimana use case yang
ditambahkan dapat berdiri sendiri
meski tanpa use case tambahan itu.
Arah panah mengarah pada use case
yang ditambahkan.
Hubungan generalisasi dan spesialisasi
(umum - khusus) antara dua buah use
case dimana fungsi yang satu
merupakan fungsi yang lebih umum
dari lainnya.
 32

Arah panah mengarah pada use case

yang menjadi generalisasinya (umum)
Menggunakan / include / uses Relasi use case tambahan ke sebuah
use case dimana use case yang
ditambahkan membutuhkan use case
ini untuk menjalankan fungsinya atau
sebagai syarat dijalankan use case ini.
<<include>> Arah panah include mengarah pada use
case yang dipakai (dibutuhkan) atau
mengarah pada use case tambahan.
Tabel 2.2 Simbol-simbol pada Use Case

3. Penjelasan Simbol Extend

Validasi User

<<extend>>

Validasi Sidik Jari

Gambar 2.9 Contoh extend dalam use case diagram

Pada gambar diatas, use case Validasi User merupakan use case
yang ditambahkan, dimana use case ini dapat berdiri sendiri tanpa use case
tambahan (Validasi Sidik Jari). pada contoh diatas setelah pengguna
melakukan validasi user, pengguna dapat mengembangkannya (opsional)
dengan validasi sidik jari atau tidak.

4. Penjelasan Simbol Include

 33

Mengelola Pinjaman

<<include>>

Login

<<include>>

Mengeelola Anggota

Gambar 2.010 Contoh include dalam use case

Pada gambar diatas Use Case Login merupakan syarat / selalu

dipanggil terlebih dahulu sebelum dijalankannya use case Mengelola
Anggota atau use case Mengelola Peminjaman. Intinya perbedaan mendasar
dari use case extend dan use case include adalah extend dalam use case
digunakan untuk mengembangkan sebuah use case (use case inti) misalnya
setelah melakukan Buka Rekening selanjutnya bisa melakukan apa lagi?
dimana pada hubungan extend arah panah mengarah pada use case inti (use
case ditambahkan). sedangkan use case include digunakan untuk
menjelasakan bahwa sebuah use case memiliki sebuah syarat agar /
ketentuan sebelum bisa dijalankan, misalnya saat kita akan mengelola
anggota maka kita diwajibkan login terlebih dahulu. pada hubungan include
arah panah mengarah pada use case tambahan (use case yang dipakai /
dibutuhkan).

2.2.7. Information Architecture

Information Architecture (IA) adalah desain struktural lingkungan
berbagi informasi; seni dan ilmu mengatur dan pelabelan website, intranet,
komunitas online dan perangkat lunak untuk dukungan kegunaan dan
findability; dan masyarakat yang muncul dari praktek difokuskan pada
membawa prinsip-prinsip desain, arsitektur dan ilmu informasi dengan
lanskap digital (Pérez-Montoro, 2013). IA melibatkan model atau konsep
informasi yang digunakan dan diterapkan pada kegiatan yang membutuhkan
rincian eksplisit dari sistem informasi yang kompleks.
 34

Komponen-komponen dalam IA adalah sebagai berikut:

 Desain struktural dari lingkungan informasi suatu sistem.

 Seni dan ilmu pengorganisasian dan pelabelan situs web, intranet,
komunitas online, dan perangkat lunak untuk mendukung
kemampuan menemukan dan kegunaan.
 Komunitas praktik yang muncul berfokus pada membawa prinsip-
prinsip desain dan arsitektur ke lanskap digital.
 Kombinasi organisasi, pelabelan, pencarian dan sistem navigasi di
dalam situs web dan intranet.
 Mengekstrak parameter / data yang diperlukan dari Engineering
Designs dalam proses menciptakan basis pengetahuan yang
menghubungkan berbagai sistem dan standar.
 Cetak biru dan alat bantu navigasi untuk konten sistem yang kaya
informasi.
 Subset arsitektur data tempat data yang dapat digunakan, dibuat,
dirancang, atau disusun dengan cara yang paling bermanfaat atau
secara holistik secara holistik bagi para pengguna data ini.
 Praktek pengorganisasian informasi / konten / fungsionalitas situs
web sehingga menyajikan pengalaman pengguna terbaik, dengan
informasi dan layanan yang mudah digunakan dan ditemukan.
 Kerangka konseptual seputar informasi, menyediakan konteks,
kesadaran lokasi dan struktur berkelanjutan.

2.2.8. User Flow / User Journey

User flow adalah langkah langkah yang harus dilakukan oleh user
dalam mengerjakan suatu task. Membuat user flow diagram juga akan
membantu memetakan bagian yang berpotensi bermasalah dan
memperbaikinya sampai websitemu bisa beropoerasi lebih efektif. User
flow dapat dilakukan dengan membuat mapping website atau wireframing.
Namun ada beberapa hal perlu diperhatikan terlebih dahulu. Pertama,
ketahui siapa yang akan berkunjung ke websitemu. Segmentasi sangatlah
 35

penting agar fokus pada target yang akan dibidik. Kedua, ketahui bagaimana
pengunjung sampai ke websitemu (entry points). Ada beberapa
kemungkinan entry points yaitu direct entry (langsung datang ke website),
organic search (menemukan alamat websitemu dari search engine), referrals
(link dari website lain), sosial media, email marketing atau ads. Entry point
sangat penting karena berdampak pada bagaimana selanjutnya pengunjung
berperilaku di websitemu.

2.2.9. Activity Diagram

Activity diagram pada dasarnya menggambarkan macam-macam

alir aktifitas yang akan dirancang dalam sebuah sistem. Dalam Unified
Modeling Language, Activity diagram dimaksudkan untuk memodelkan
proses komputasi dan organisasi (yaitu alur kerja), serta aliran data yang
bersinggungan dengan aktivitas terkait. Meskipun diagram aktivitas
terutama menunjukkan keseluruhan aliran kontrol, mereka juga dapat
menyertakan elemen yang menunjukkan aliran data antara aktivitas melalui
satu atau lebih penyimpanan data. Activity diagram pada dasarnya memiliki
struktur yang hampir mirip dengan flowchart atau diagram alir dalam
perancangan sistem secara terstruktur. Activity diagram ini dibuat
berdasarkan sebuah use case atau beberapa use case dalam use case
diagram. Berikut adalah simbol-simbol yang ada di dalam activity diagram:

Simbol Deskripsi

Activity
Memperlihatkan bagaimana masing-
Activity masing kelas antarmuka saling
berinteraksi satu sama lain. Digunakan
untuk mewakili serangkaian action.
 36

Action
State dasri sistem yang mencerminkan
eksekusi dari suatu aksi. Tugas yang
Action
harus dilakukan.

Control Flow
Memperlihatkan urutan eksekusi.

Object Flow Tampilkan aliran suatu objek dari satu

aktivitas (atau aksi) ke aktivitas lain
(atau aksi).
Initial Node Menggambarkan awal dari
serangkaian tindakan atau kegiatan.

Activity Final Node Menghentikan semua aliran kontrol

dan objek mengalir dalam suatu
kegiatan (atau tindakan).
Object Node
Mewakili objek yang terhubung ke
ObjectNode serangkaian Arus Objek.

Decision Node
Mewakili kondisi pengujian untuk
memastikan bahwa aliran kontrol atau
guard-x guard-y
aliran objek hanya turun satu jalur.

Merge Node
Menyatukan kembali jalur keputusan
berbeda yang dibuat menggunakan
simpul keputusan.
 37

Fork Node

Membagi perilaku menjadi

seperangkat kegiatan (atau tindakan)
yang paralel atau bersamaan.

Join Node
Menyatukan kembali serangkaian
kegiatan (atau tindakan) yang paralel
atau bersamaan.

Swimlane atau Partition

Title
Cara mengelompokkan aktivitas yang
Function Function
dilakukan oleh aktor yang sama pada
diagram aktivitas atau
mengelompokkan aktivitas dalam satu
utas.
Phase

Tabel 2.3 Simbol-simbol dalam Activity Diagram

2.2.10. User-Centered Design dan Agile Development

UCD (User-Centered Design) adalah sebuah filosofi perancangan
yang menempatkan pengguna sebagai pusat dari sebuah proses
pengembangan sistem. Kesulitan pengguna (end user) selama ini untuk
membaca dan menerjemahkan dokumen-dokumen yang ada dalam setiap
pengembangan dapat terbantu menggunakan metode UCD. Teknik, metode,
tools, prosedur dan proses yang membantu perancangan sistem interaktif
dibangun herdasarkan pengalaman pengguna. UCD adalah menerjemahkan
partisipasi dan pengalaman manusia ke dalam rancangan.
 38

Ada empat proses dalam UCD yakni:

A. Memahami dan menentukan konteks pengguna.

B. Menentukan kebutuhan pengguna dan organisasi.
C. Solusi perancangan yang dihasilkan.
D. Evaluasi perancangan terhadap kebutuhan pengguna.

Ada sejumlah manfaat yang muncul saat mengadvokasi filosofi

yang berpusat pada pengguna. Penelitian berbasis pengguna menyediakan
mekanisme yang dengannya keputusan desain dapat divalidasi dan diuji.
Keputusan berbasis bukti berarti bahwa dugaan diminimalkan. Apa yang
harus dibangun menjadi jauh lebih tidak penting untuk diperdebatkan.
Lebih penting lagi, dengan menjadikan pengguna akhir produk sebagai
jantung dari desain dan proses pengembangannya, hasil akhirnya jauh lebih
baik.

Kesamaan Antara User-Centered Design dan Agile development

Kesamaan mencolok antara agile dan UCD yang sering diabaikan
adalah bahwa keduanya sering secara mendasar disalahpahami sebagai
metodologi — resep ajaib, langkah-demi-langkah yang dapat Anda ikuti
untuk menjamin keberhasilan proyek. Sebenarnya, Agile dan UCD
keduanya adalah mengandalkan filosofi. Filosofi Agile dan UCD
keduanya berulang; mereka maju dalam langkah-langkah kecil yang
menyediakan peluang untuk verifikasi dan penyempurnaan di sepanjang
proses.

Konflik Antara UCD dan Agile

Ada konflik antara pengembang Agile dan desainer UX.
Pengembangan perangkat lunak tangkas didominasi oleh filosofi yang
dipimpin oleh pengembang, sementara UCD, di banyak organisasi,
diperjuangkan oleh kreatif. Ada akan selalu menjadi sehat, ketegangan
alami antara individu-individu kiri-berotak dan berotak kanan. Untuk lebih
memahami, mari kita bandingkan beberapa prinsip Agile Manifesto yang
menyebabkan konflik dengan filosofi UCD:
 39

Manifesto Agile Filosofi UCD

Prioritas tertinggi kami adalah

untuk membantu menciptakan
Prioritas tertinggi kami adalah pengalaman bagi pengguna
untuk memuaskan pelanggan akhir di mana mereka dapat
melalui pengiriman awal dan terus mencapai tujuan mereka dengan
menerus perangkat lunak mudah dan efisien dengan
berharga. gangguan minimal pada model
mental mereka dari ruang
masalah.
Kepuasan kebutuhan pengguna
Perangkat lunak yang berfungsi akhir (tujuan pengguna)
adalah ukuran utama dari diimbangi dengan pencapaian
kemajuan. tujuan bisnis adalah ukuran utama
kesuksesan.
Sering-seringlah mengirimkan
Pengiriman awal ke pelanggan
perangkat lunak yang berfungsi,
memungkinkan uji beta atau uji
mulai dari beberapa minggu
coba kegunaan dilakukan dan
hingga beberapa bulan, dengan
pelanggan menyesuaikan kembali
preferensi ke skala waktu yang
prioritasnya berdasarkan temuan.
lebih pendek.
Tabel 2.4 Manifesto Agile dan Filosofi UCD

Masalah Umum Saat Mengintegrasikan UCD dan Agile.

A. Desain tanpa Batasan
B. Validasi dengan penggunaan di dunia nyata
C. Serah terima adalah musuh pemahaman
D. Tidak ada waktu untuk beralih
E. Tanggung jawab yang dibagi; tim yang dibagi

2.2.11. Heuristic Evaluation

 40

Heuristic Evaluation adalah metode evaluasi di mana satu atau lebih

ahli membandingkan desain produk digital dengan daftar prinsip-prinsip
desain yang telah ditentukan (biasanya disebut sebagai heuristik) dan
mengidentifikasi di mana produk tidak mengikuti prinsip-prinsip tersebut.

10 Heuristik Kegunaan untuk Desain Antarmuka Pengguna oleh

Nielsen Norman Group digunakan sebagai 10 kriteria evaluasi yang
menentukan.

A. Visibility of system status

Sistem harus selalu memberi informasi kepada pengguna tentang apa
yang terjadi, melalui umpan balik yang sesuai dalam waktu yang wajar.
B. Match between system and the real world
Sistem harus berbicara dalam bahasa pengguna, dengan kata-kata,
frasa, dan konsep yang akrab bagi pengguna, bukan istilah yang
berorientasi sistem. Ikuti konvensi dunia nyata, membuat informasi
muncul dalam urutan yang alami dan logis.
C. User control and freedom
Pengguna sering memilih fungsi sistem secara tidak sengaja dan akan
membutuhkan "pintu darurat" yang ditandai dengan jelas untuk
meninggalkan kondisi yang tidak diinginkan tanpa harus melalui dialog
yang diperpanjang. Mendukung undo dan redo.
D. Consistency and standards
Pengguna tidak perlu bertanya-tanya apakah kata-kata, situasi, atau
tindakan yang berbeda memiliki arti yang sama.
E. Error prevention
Bahkan lebih baik daripada pesan kesalahan yang baik adalah desain
yang hati-hati yang mencegah masalah terjadi di tempat pertama. Baik
menghilangkan kondisi rawan kesalahan atau memeriksa mereka dan
memberikan opsi konfirmasi kepada pengguna sebelum mereka
melakukan tindakan.
 41

F. Recognition rather than recall

Perkecil pemuatan memori pengguna dengan membuat objek, tindakan,
dan opsi terlihat. Pengguna tidak harus mengingat informasi dari satu
bagian dialog ke bagian lainnya. Petunjuk penggunaan sistem harus
terlihat atau mudah diambil kapan pun diperlukan.
G. Flexibility and efficiency of use
Akselerator - tidak terlihat oleh pengguna pemula - mungkin sering
mempercepat interaksi untuk pengguna ahli sehingga sistem dapat
melayani pengguna yang tidak berpengalaman maupun yang
berpengalaman. Izinkan pengguna untuk menyesuaikan tindakan yang
sering dilakukan.
H. Aesthetic and minimalist design
Dialog tidak boleh mengandung informasi yang tidak relevan atau
jarang dibutuhkan. Setiap unit informasi tambahan dalam dialog
bersaing dengan unit informasi yang relevan dan mengurangi visibilitas
relatifnya.
I. Help users recognize, diagnose, and recover from errors
Pesan kesalahan harus dinyatakan dalam bahasa sederhana (tanpa
kode), menunjukkan masalah secara tepat, dan secara konstruktif
menyarankan solusi.
J. Help and documentation
Meskipun lebih baik jika sistem dapat digunakan tanpa dokumentasi,
mungkin perlu memberikan bantuan dan dokumentasi. Setiap informasi
seperti itu harus mudah dicari, difokuskan pada tugas pengguna, daftar
langkah konkret yang harus dilakukan, dan tidak terlalu besar.
 42

BAB III
ANALISIS DAN PERANCANGAN
3.1. Metode Penelitian

Metode penelitian adalah adalah langkah yang dimiliki dan dilakukan oleh
peneliti dalam rangka untuk mengumpulkan informasi atau data serta melakukan
investigasi pada data yang telah didapatkan tersebut.

Gambar 03.1 Metode Penelitian Pengembangan sistem KRM dengan Agile

Metode penelitian diatas dibuat berdasarkan siklus software development

dengan Agile.

3.2. Analisis
3.2.1. Requirement
Requirement adalah kebutuhan fisik atau fungsional terdokumentasi
tunggal yang ingin dipenuhi oleh desain, produk, atau proses tertentu.
Tahapan Requirement dalam pengembangan sistem Knowledge Repository
Management adalah sebagai berikut:
 43

A. Problem Identification
Proses ini bertujuan untuk memahami masalah sehingga solusi
yang tepat dapat disampaikan. Dalam sistem Digital Administrative
Management, ada beberapa masalah yang terjadi sehingga sistem ini
tidak digunakan di lingkungan DDS.

Gambar 03.2 Halaman Utama sistem Digital Administrative Management DDS

Digital Administrative Management DDS dapat diakses

menggunakan jaringan Telkom Indonesia. Digital Administrative
Management DDS saat ini tidak digunakan karena kebutuhan untuk
menyimpan dokumen (proses bisnis) tidak terstruktur dengan baik.
Menu pada dashboard terlalu ramai, jadi ketika memasuki Digital
Administrative Management DDS pengguna bingung untuk memilih
menu aktivitas yang akan dituju (tidak jelas apa menu yang harus
dilakukan). Tampilan Digital Administrative Management DDS tidak
ramah pengguna karena kurangnya tata letak informasi aktivitas dan
tata bahasa asing dari pengguna. Proses memuat juga terganggu ketika
Digital Administrative Management DDS sedang digunakan, meskipun
sudah menggunakan koneksi yang kuat dari jaringan Telkom Indonesia.

Pada 2017 hingga 2019 diidentifikasi bahwa Digital

Administrative Management DDS tidak berjalan. Ini dibuktikan dengan
dokumen karyawan yang telah diserahkan pada tahun 2017 tetapi
 44

dokumen tersebut tidak ditindaklanjuti (disetujui, direvisi, atau ditolak

dokumen) oleh pemeriksa atau pemberi persetujuan sampai tahun 2019.

Dokumen dari hasil penelitian teknis, hasil penelitian bisnis, dan

dokumen lain di DDS tersebar di setiap divisi. Ketika atasan meminta
dokumen, karyawan merasa kesulitan untuk menemukan dokumen
yang dihasilkan dari penelitian teknis, hasil penelitian bisnis, dan
dokumen lain karena penyebaran dokumen di masing-masing divisi ini.
Mereka membutuhkan tempat untuk mengumpulkan semua informasi
sehingga tersimpan dengan rapi dan baik.

Knowledge Repository yang akan dikembangkan dapat

menggantikan Digital Administrative Management DDS yang relatif
tidak digunakan. Karyawan pernah bermaksud untuk menghidupkan
kembali Digital Administrative Management DDS, tetapi setelah
berdiskusi dengan para ahli mereka menyatakan bahwa Digital
Administrative Management DDS tidak dapat digunakan lagi. Ahli
berpendapat bahwa kembali ke proses pengembangan Digital
Administrative Management DDS tidak melalui tahapan seperti sprint
design, atau pengecekan (validasi).

B. Brainstorming
Sesi Brainstorming:
 Ini adalah teknik kelompok.
 Ini dimaksudkan untuk menghasilkan banyak ide baru sehingga
menyediakan platform untuk berbagi pandangan.
 Seorang fasilitator yang sangat terlatih diperlukan untuk
menangani prasangka kelompok dan konflik kelompok.
 Setiap ide didokumentasikan sehingga semua orang dapat
melihatnya.
 Akhirnya sebuah dokumen disiapkan yang terdiri dari daftar
persyaratan dan prioritasnya jika memungkinkan.
 45

Ide-ide baru yang dihasilkan dari proses ini bersumber dari fitur-fitur
yang ada di Kampiun dan Digital Administrative Management DDS.

C. User Interview
Tujuan melakukan wawancara adalah untuk memahami harapan
pelanggan dari perangkat lunak. Tidak mungkin untuk mewawancarai
setiap pemangku kepentingan sehingga perwakilan dari kelompok
dipilih berdasarkan keahlian dan kredibilitas mereka.

Wawancara mungkin bersifat terbuka atau terstruktur.

 Dalam wawancara yang berakhir tidak ada agenda yang ditentukan
sebelumnya. Pertanyaan bebas konteks dapat diminta untuk
memahami masalahnya.
 Dalam wawancara terstruktur, agenda pertanyaan yang cukup
terbuka disiapkan. Terkadang kuesioner yang tepat dirancang
untuk wawancara.

Wawancara yang dilakukan pada Requirement ini adalah

wawancara seputar sistem Kampiun dan Digital Administrative
Management DDS. Wwancara ini meliputi faslitas yang disediakan
dari kedua sistem dan cara penggunaannya.

3.3. Perancangan
3.3.1. Design Sprint
Design Sprint adalah proses untuk menjawab pertanyaan bisnis
melalui desain, pembuatan prototipe, dan pengujian ide dengan pelanggan.

A. User
1) Super Admin : Pak Roesso
2) Admin : Pak Roesso
3) Approver : Pak David
4) Creator : Bu Anna, Bu Lesmin, Bu Yovita, Bu Retno, Bu
Yuyun
5) Viewer : Bu Yovita, Bu Retno, Bu Yuyun
 46

B. Kategori How Might We (HMW)

1) Kategori Approval
a. Membuat proses approval lebih cepat dan mudah.
b. Membuat proses approval berjalan secara fleksibel.
c. Menyediakan reminder approval via email (gmail).
d. Merevisi dokumen memakai kolom komentar.
e. Mengupload jenis dokumen yang tidak memerlukan proses
approval.
f. Menyediakan level tingkatan dalam proses approval.
2) Kategori Pengelolaan Dokumen
a. Menampilkan versi dalam setiap revisi.
b. Menggunakan sistem simpan draft untuk upload
dokumen.
c. Menyediakan layanan document on-going atau versi
terbaru.
d. Mengetahui dokumen jika digantikan dengan versi
terbaru.
e. Menyampaikan versi terbaru dari sebuah dokumen.
3) Kategori Aktivitas Utama
a. Mengadukan kesalahan dengan fitur report atau
comment.
b. Mempermudah user dalam proses create document.
c. Memastikan dokumen yang di-upload sudah final.
d. Menyediakan fitur tag kepada pihak terkait (pembuat
dokumen).
e. Menyediakan fitur preview dokumen.
f. Membuat tampilan yang user-friendly.
g. Mencari dokumen menggunakan filter dan keyword.
4) Kategori Aktivitas Admin
a. Mem-backup dan restore data via server playcourt.
b. Melakukan sinkronisasi user via address book (SSO).
c. Meng-upload dokumen lama.
 47

d. Memberikan kewenangan kepada user tertentu.

5) Kategori Fitur Tambahan
a. Menyediakan fitur watermark untuk dokumen
confidential.
b. Menyediakan fitur history dan status proses.
c. Menyediakan fitur integrasi dengan email, slack, gmail,
dll.
d. Menyediakan tampilan struktur organisasi.
C. 4 How Might We (HMW) Terbaik
1) Memudahkan pencarian dokumen menggunakan fitur filter dan
keyword, serta melaporkan dokumen jika terjadi kesalahan
menggunakan fitur report dan comment.
2) Mengetahui status dokumen jika terdapat versi terbaru.
3) Menyediakan fitur watermark pada dokumen confidential dan
dapat diketahui telah diunduh oleh siapa saja.
4) Memberikan kode berdasarkan jenis dokumen.
D. User Journey dari Design Sprint
1) Super admin – proses dan goal

Gambar 3.003 User Journey Super Admin – proses

 48

Gambar 3.4 User Journey Super Admin – goal

2) admin – proses dan goal

Gambar 3.5 User Journey Admin – proses

Gambar 03.6 User Journey Admin - goal

 49

3) Approver – proses dan goal

Gambar 3.7 User Journey Approval – proses

Gambar 3.8 User Journey Approval – goal

4) User Journey Creator atau Uploader – proses dan goal

Gambar 3.9 User Journey Creator – proses

 50

Gambar 3.10 User Journey Creator – goal

5) User Journey Viewer – proses dan goal

Gambar 3.11 User Journey Viewer – proses

Gambar 03.12 User Journey Viewer – goal

3.3.2. Backlog / Product Backlog

Product Backlog adalah perincian dari kebutuhan produk yang
disiapkan dan disimpan oleh tim proyek. Product Backlog mencantumkan
semua fitur, fungsi, persyaratan, penyempurnaan, dan perbaikan yang
 51

merupakan perubahan yang akan dibuat pada produk di rilis mendatang.

Item Product Backlog memiliki atribut deskripsi, pesanan, perkiraan, dan
nilai. Item ini biasanya disebut sebagai User Stories. Product Owner
bertanggung jawab atas Product Backlog, termasuk konten, ketersediaan,
dan pemesanannya.
Product Backlog sistem Knowledge Repository Management ini
bersumber dari sistem yang sudah dibuat sebelumnya oleh PT Telkom
Indonesia Tbk., yaitu Kampiun dan Digital Administrative Management
DDS. Saat ini, seluruh karyawan di Telkom memperoleh kesempatan yang
luas untuk menyampaikan ide, pengalaman, pengetahuan dan pembelajaran
dalam bentuk tulisan yang dikelola Perusahaan dalam system pengelolaan
pengetahuan yang disebutnya KAMPIUN. Di Divisi Digital Service, pernah
dibangun sistem knowledge management bernama Digital Administrative
Management. Tujuan dari pengembangan sistem Knowledge Repository
Management di DDS adalah untuk membangun sistem knowledge
management yang serupa dengan Kampiun dan memperbaiki sistem Digital
Administrative Management.

A. Definisi Knowledge Repository Management

Knowledge repository adalah portal web untuk menyimpan
dokumen hasil research dan inovasi DDS yang valid, ter-update, dan
mudah diakses dengan proses yang secure dan user-friendly. Knowledge
repository hanya dapat diakses menggunakan Jaringan Telkom (intranet).
Bagi karyawan yang ingin melakukan login diharuskan menggunakan NIK
dan password.

B. User Role
Berikut adalah user role dari sistem Knowledge Repository
Management.
1. Viewer
Role viewer dapat melakukan pekerjaan sebagai berikut:
a) Cari dokumen
b) Lihat dokumen
 52

c) Unduh dokumen
d) Minta izin unduh dokumen
e) Laporkan dokumen
f) Komentar
g) Lihat profil orang lain
h) Lihat riwayat aktivitas
i) Lihat permintaan unduh
j) Lihat riwayat unduhan
k) Lihat riwayat dokumen yang sudah dilihat
l) Lihat menu bantuan
2. Uploader
a) Lihat profil sendiri
b) Unggah dokumen
c) Lihat status unggah dokumen
d) Lihat dokumen terbit
3. Owner
a) Melihat dokumen yang perlu persetujuan pemilik dokumen
b) Melakukan persetujuan dokumen sebagai pemilik dokumen
c) Melihat dokumen yang telah disetujui/dikembalikan/ditolak
sebagai pemilik dokumen
4. Approver
a) Melihat dokumen yang perlu persetujuan leader
b) Melakukan persetujuan dokumen sebagai leader
c) Melihat dokumen yang telah disetujui/dikembalikan/ditolak
sebagai leader

B. Profil Pengguna
1. Guest
Guest adalah karyawan Telkom Group Non-DDS yang mempunyai
hak sebagai role viewer pada web portal Knowledge Repository.
2. Staff
Staff adalah karyawan Telkom DDS yang mempunyai hak sebagai
role viewer dan owner pada web portal Knowledge Repository.
 53

3. Leader
Leader adalah karyawan Telkom DDS yang mempunyai bawahan
maka mempunyai hak sebagai role viewer, owner dan approver pada
web portal Knowledge Repository.

C. Pengguna Khusus Sistem

1. Admin : dapat mengelola report user, melihat data statistik,
mengunggah dokumen lama.
2. Super admin : dapat mem-backup & restore database, sinkronisasi
user berdasarkan address book.
D. User Story untuk Guest, Staff dan Leader
Keterangan:
User story khusus untuk guest, staff, dan leader
User story khusus untuk staff dan leader
User story khusus untuk leader

ID Product User Story Priority Notes

Bcklog Item

1 Login Sebagai user, saya Must Username dan Password

ingin login Have menggunakan NIK dan
Password SSO

2 Halaman Sebagai user, saya Must Beranda menampilkan

Beranda ingin melihat Have Dokumen Populer, Dokumen
beranda Pilihan, dan Dokumen Terbaru

3 Cari Sebagai user, saya Must User dapat mencari dokumen

Dokumen ingin mencari Have sesuai kata kunci:
dokumen ● Judul
● Pemilik dokumen
● Kategori dokumen
● Unit
Tampilan hasil pencarian
● Cover dokumen/logo
pdf
● Waktu terbit dokumen
● Jumlah view dan unduh
dokumen
 54

Pencarian Lanjutan:
● Pemilik Dokumen dan
Kategori)
● Urutkan (Tanggal
Upload, Judul, Unit,
Jumlah Lihat, Jumlah
Unduh)
● Tampilan (Grid dan
List)

4 Lihat Sebagai user, saya Must User membuka dokumen, akan

Dokumen ingin melihat Have menampilkan:
dokumen ● Judul dokumen
● Pemilih dokumen
● Approver dokumen
● Uploader dokumen
● Nomor dokumen
● Versi dokumen
● Kata kunci
● Deskripsi
● Kategori dokumen
● Preview dokumen
● Waktu terbit
● Jumlah view dokumen
● Jumlah unduh dokumen
● Tombol laporkan
● Tombol unduh/Minta
izin unduh
● Kolom komentar

5 Unduh Sebagai user, saya Must Saat tombol unduh diklik maka
Dokumen ingin mengunduh Have menampilkan pop-up disclaimer
dokumen

6 Minta Izin Sebagai user, saya Must Meminta izin unduh dilakukan
Unduh ingin meminta izin Have oleh user ketika ingin
unduh mengunggah dokumen yang
tidak bebas untuk diunduh.
Ketika tombol minta izin unduh
diklik maka muncul pop-up
yang berisi textbox yang harus
diisi oleh user

7 Laporkan Sebagai user, saya Should Dokumen yang dianggap

Dokumen ingin melaporkan Have bermasalah dapat dilaporkan
dokumen dengan kriteria sebagai berikut:
● Dokumen terindikasi
 55

ganda
● Dokumen kadaluarsa
● Dokumen rusak
● Informasi dokumen
salah
● Alasan lainnya. (user
dapat mengetik 55las an
secara manual)

8 Komentar Sebagai user, saya Should User dapat memberi komentar

ingin mengomentari Have pada halaman dokumen. Fitur
dokumen komentar berisi:
● Nama user
● Waktu pengiriman
komentar
● Isi komentar
● Field komentar dan
tombol kirim

9 Lihat Profil Sebagai user, saya Must

ingin melihat profil Have
Pemilik Dokumen

10 Unggah Sebagai user, saya Must Proses unggah dokumen dibagi

Dokumen ingin mengunggah Have menjadi 5 tahap:
dokumen 1. Isi metadata
● Pemilik
dokumen (dicari:
sudah nama
sudah ada di
database)
● Judul
● Deskripsi
● Kategori dan
Sub kategori
● Nomor dokumen
● Tahun
● Versi
● Unit
2. Tentukan kata kunci
3. Unggah dokumen
● File berekstensi
(.pdf)
● Maksimum
ukuran file 25
MB
4. Persetujuan izin unduh
 56

● Bebas akses
unduh
● Perlu izin unduh
5. Konfirmasi
Menampilkan
kesimpulan dari data
yang sudah diinput dan
dapat mengeditnya
kembali

11 Status Sebagai user, saya Must Menampilkan list dokumen

Unggah ingin melihat daftar Have yang sudah diunggah dengan
Dokumen status unggah menampilkan informasi sebagai
dokumen berikut:
● Nomor dokumen
● Judul dokumen
● Kategori
● Approver
● Status (Menunggu
persetujuan, disetujui,
direvisi, ditolak)
● Action lihat detail yang
berisi timeline status
dokumen

12 Daftar Sebagai user, saya Must

Dokumen ingin melihat daftar Have
Terbit dokumen terbit

13 Dokumen Sebagai user, saya Must

Perlu ingin melihat daftar Have
Persetujuan dokumen perlu
(Pemilik persetujuan
Dokumen)

14 Persetujuan Sebagai user, saya Must

Dokumen ingin Have
(Pemilik menyetujui/mengem
Dokumen) balikan/menolak
dokumen

15 Dokumen Sebagai user, saya Must

Disetujui ingin melihat daftar Have
(Pemilik dokumen yang telah
Dokumen) disetujui

16 Dokumen Sebagai user, saya Must

 57

Dikembalikan ingin melihat daftar Have

(Pemilik dokumen yang telah
Dokumen) dikembalikan

17 Dokumen Sebagai user, saya Must

Ditolak ingin melihat daftar Have
(Pemilik dokumen yang telah
Dokumen) ditolak

18 Dokumen Sebagai user, saya Must

Perlu ingin melihat daftar Have
Persetujuan dokumen perlu
(Leader) persetujuan

19 Persetujuan Sebagai user, saya Must

Dokumen ingin Have
(Leader) menyetujui/mengem
balikan/menolak
dokumen

20 Dokumen Sebagai user, saya Must

Disetujui ingin melihat daftar Have
(Leader) dokumen yang telah
disetujui

21 Dokumen Sebagai user, saya Must

Dikembalikan ingin melihat daftar Have
(Leader) dokumen yang telah
dikembalikan

22 Dokumen Sebagai user, saya Must

Ditolak ingin melihat daftar Have
(Leader) dokumen yang telah
ditolak

23 Riwayat Sebagai user, saya Must

Aktivitas ingin melihat Have
keseluruhan riwayat
aktivitas

24 Riwayat Sebagai user, saya Must

Permintaan ingin melihat Have
Unduh riwayat permintaan
unduh

25 Riwayat Sebagai user, saya Must

Unduhan ingin melihat Have
riwayat dokumen
yang telah diunduh
 58

26 Riwayat Sebagai user, saya Must

Dilihat ingin melihat Have
riwayat dokumen
yang telah dilihat

27 Bantuan Sebagai user, saya Must Berisi panduan penggunaan

ingin melihat Have aplikasi dan FAQ
bantuan

28 Profil Sebagai user, saya Must Profil terdiri dari:

ingin mengedit profil Have ● Foto profil
saya ● Nama
● NIK
● Email
● Bio
● List dokumen yang
dimiliki
● Statistik dokumen yang
dimiliki
● Medals/pencapaian

29 Keluar Sebagai user, saya Must

ingin keluar Have
Tabel 3.1 Scrum Artifact Product Backlog sistem KRM

E. User Role untuk Admin dan Superadmin

Keterangan:
User story khusus untuk admin dan superadmin
User story khusus untuk superadmin

id Product User Story Priority Notes

Backlog

1 Login Sebagai admin, saya Must Have Login menggunakan NIK dan
ingin Login Password namun masuk ke laman staff
terlebih dahulu.
Menu admin dapat diakses pada menu
dropdown di beranda

2 Statistik Sebagai admin, saya Must Have Kategori statistik dokumen dan filter
Dokumen ingin melihat statistik
 59

statistik dokumen

3 Export Sebagai admin, saya Must Have Admin dapat melakukan export lebih
Statistik ingin mengexport dari satu matriks statistik dokumen
Dokumen laporan statistik menjadi file pdf
dokumen

4 Unggah Sebagai admin, saya Must Have Unggah dokumen tanpa perlu approval
Dokumen ingin mengunggah leader namun masih perlu approval
dokumen owner

5 Kelola Sebagai admin, saya Must Have Admin dapat melakukan fungsi CRUD
Dokumen ingin mengelola pada dokumen yang diupload.
dokumen ● Admin dapat melakukan
backdoor approval
● Admin dapat melakukan
unpublish dokumen

6 Kelola Sebagai admin, saya Must Have Admin dapat melakukan fungsi CRUD
Kategori ingin mengelola untuk kategori dokumen
Dokumen kategori dokumen

7 Kelola Sebagai admin, saya Must Have Admin mengelola tiket laporan yang
Pengaduan ingin mengelola dilaporkan oleh user. Admin dapat
(Laporan) pengaduan menindaklanjuti laporan atau
(laporan) mengabaikan laporan.
- Jika laporan ditindaklanjuti,
maka admin akan
menghubungi dokumen
owner/uploader atau
melakukan perbaikan langsung
jika yang dilaporkan adalah
kesalahan metadata
- Owner/uploader dapat
meminta admin untuk
mengabaikan laporan
- Owner/uploader dapat
meminta admin untuk
menindaklanjuti laporan
- owner/uploader dapat
memperbaiki sendiri
- Jika sudah selesai, admin dapat
menutup tiket laporan

8 Kelola Sebagai Must Have Superadmin dapat melakukan fungsi

Admin superadmin, saya CRUD untuk akun Admin
ingin mengelola
admin
 60

9 Kelola Sebagai Must Have Superadmin dapat melihat semua user

User superadmin, saya dari SSO dan megubah privilage/role
ingin mengelola secara manual
user

10 Kelola Sebagai Must Have Superadmin dapat melakukan backup

Data superadmin, saya dan restore data dokumen yang yang di
ingin mengelola sistem
data portal web

11 Riwayat Sebagai Must Have

Aktivitas superadmin, saya
Admin ingin melihat
riwayat aktivitas
admin

12 Riwayat Sebagai admin, saya Must Have

Aktivitas ingin melihat
riwayat aktivitas
sendiri

13 Keluar Sebagai admin, saya Must Have

ingin keluar
Tabel 03.2 User Role untuk Admin dan Superadmin

2.2.12. Mind Map dan Use Case

Mind Map adalah suatu metode untuk memaksimalkan potensi pikiran
manusia dengan menggunakan otak kanan dan otak kirinya secara simultan.
Mind map menggunakan teknik curah gagasan dengan menggunakan kata
kunci bebas, simbol, gambar, dan melukiskannya secara kesatuan di sekitar
Tema Utama seperti pohon dengan akar, ranting, dan daun-daunnya. Tahap
pertama setelah tema ditentukan dan kata kunci hasil curah gagasan
dituliskan, dilukis, dan ditandai dengan warna atau simbol tertentu adalah
menyusun ulang kata kunci tersebut. Kemudian proses curah gagasan
diteruskan kembali secara bebas. Kata kunci yang digunakan disarankan
hanya satu kata tunggal. Hasil dari problem identification, brainstorming,
dan user interview disusun menjadi kata kunci dari pencurahan gagasan dan
digambarkan dengan mind map.
 61

Use case yang dibuat dari requirement adalah sebagai berikut.

Gambar 3.0013 Use Case sistem Knowledge Repositroy Management

62

Gambar 3.0014 Mind Map Knowledge Repository Management

 63

BAB IV
HASIL KEGIATAN PLA

BAB IV ini menjelaskan tentang bagaimana proyek ini dikerjakan, dan juga
penjelasan pembagian tugas tiap masing-masing aggota dalam kelompok,
kemudian penjelasan tentang lingkungan implementasi, dan hasil implementasi dari
rencana kerja proyek sehingga menjadi aplikasi yang dapat berfungsi sesuai dengan
kebutuhan perusahaan.

4.1. Work Breakdown Structure

Work breakdown structure (WBS) adalah suatu metode pengorganisasian proyek
menjadi struktur pelaporan hierarakis.

No Milestone Name Start Date End Date Status Progress

1 User Requirement 20 Mei 2019 2 Agustus 2019 Completed 100%

2 Design System
a. Design Information
2 Agustus 2019 9 September 2019 Completed 100%
Architecture Preparation
b. Design Information
10 September 2019 6 November 2019 Completed 100%
Architecture
c. User Flow 6 November 2019 5 Desember 2019 Completed 100%
d. Design Mockup 21 Oktober 2019 31 Desember 2019 On Going Progress 42%
e. Heuristic Evaluation
f. Design Mockup Revise
4 Backlog Management 13 Januari 2020 17 Januari 2020 Not Started Yet 0%
5 Development Not Started Yet 0%
6 Usability Testing Not Started Yet 0%
7 Kickstart Not Started Yet 0%
Total 36.47%

Tabel 4.1 WBS Work Plan TW4 Desember 2019

 64

WBS Task Name Duration Start Finish % Complete

1 Project Knowledge 411 days? Mon 5/20/19 Mon 12/14/20 37%
Repository
1.1 User 67 days Mon 5/20/19 Tue 8/20/19 100%
Requirement
1.1.1 Problem 8 days Mon 5/20/19 Wed 5/29/19 100%
Identification
1.1.6 Brainstroming 11 days Mon 6/10/19 Mon 6/24/19 100%
1.1.7 Interview with 12 days Tue 6/25/19 Wed 7/10/19 100%
User
1.1.8 Mind Map and 12 days Thu 7/4/19 Fri 7/19/19 100%
Use Case
1.1.9 Persiapan 3 days Mon 7/22/19 Wed 7/24/19 100%
Design Sprint
1.1.10 Design Sprint 8 days Wed 7/24/19 Fri 8/2/19 100%
1.2 Desain Sistem 144 days? Fri 8/2/19 Wed 2/19/20 66%
1.2.1 Design 27 days Fri 8/2/19 Mon 9/9/19 100%
Information
Architecture -
Persiapan
1.2.2 Design 42 days? Tue 9/10/19 Wed 11/6/19 100%
Information
Architecture
1.2.2.1 IA Staff Leader 14 days Tue 9/10/19 Fri 9/27/19 100%
1.2.2.2 IA Guest 16 days Fri 9/27/19 Fri 10/18/19 100%
1.2.2.3 IA Admin 14 days Wed 10/16/19 Mon 11/4/19 100%
Superadmin
1.2.3 User Flow 22 days? Wed 11/6/19 Thu 12/5/19 100%
1.2.3.1 User Flow 9 days Wed 11/6/19 Mon 11/18/19 100%
Staff Leader
1.2.3.2 User Flow 8 days Mon 11/18/19 Wed 11/27/19 100%
Admin Superadmin
1.2.3.3 User Flow 7 days Wed 11/27/19 Thu 12/5/19 100%
Guest
1.2.4 Design Mockup 73 days? Mon 10/21/19 Wed 1/29/20 32%
1.2.4.1 Design 52 days Mon 10/21/19 Fri 1/17/20 42%
Mockup (Staff -
Leader, Guest)
1.2.4.2 Design 16 days Thu 11/28/19 Thu 12/19/19 0%
Mockup (Admin &
Superadmin)
1.2.5 Heuristic 2 days Fri 1/17/20 Tue 1/21/20 0%
Evaluation
1.2.6 Design Mockup 13 days Fri 1/17/20 Wed 2/5/20 0%
Revise
 65

1.3 Backlog 2 days Thu 2/20/20 Fri 2/21/20 0%

Management

1.4 Development 168 days Mon 2/24/20 Wed 10/14/20 0%

1.4.1 Struktur 14 days Thu 1/30/20 Tue 2/18/20 0%
Database
1.4.2 Modul 1 (Login, 18 days Wed 1/1/20 Fri 1/24/20 0%
Beranda)
1.4.3 Modul 2 (My 32 days Wed 1/1/20 Thu 2/13/20 0%
Document, Cari
Dokumen)
1.4.4 Modul 3 (My 32 days Wed 1/1/20 Thu 2/13/20 0%
Approval, Profil)
1.4.5 Modul 4 30 days Wed 1/1/20 Tue 2/11/20 0%
(Riwayat Aktivitas,
Bantuan, Notifikasi)
1.4.6 Modul 5 (Admin 18 days Thu 1/30/20 Mon 2/24/20 0%
Dashboard, Admin
Dokumen)
1.4.7 Modul 6 (Admin 18 days Thu 1/30/20 Mon 2/24/20 0%
Kelola User, Admin
Kelola Data, Admin
Riwayat Aktivitas)
1.5 Testing 10 days Mon 10/19/20 Fri 10/30/20 0%
1.5.1 Unit Testing 5 days Fri 3/13/20 Thu 3/19/20 0%
1.5.2 Usability Testing 5 days Mon 10/26/20 Fri 10/30/20 0%
1.6 Kickstart 2 days Mon 11/2/20 Tue 11/3/20 0%
1.6.1 Launching 2 days Mon 11/2/20 Tue 11/3/20 0%
1.7 Dokumentasi 382 days? Mon 5/20/19 Tue 11/3/20 34%
1.7.1 Dokumentasi 67 days Mon 5/20/19 Thu 8/22/19 100%
User Requirement
1.7.2 Dokumentasi 144 days Fri 8/2/19 Wed 6/10/20 45%
Desain Sistem
1.7.4 Dokumentasi 2 days Mon 2/24/20 Tue 2/25/20 40%
Backlog
Management
1.7.5 Dokumentasi 168 days Mon 2/24/20 Wed 10/14/20 0%
Development
1.7.6 Dokumentasi 10 days Mon 10/19/20 Fri 10/30/20 0%
Testing
1.8 Training 30 days? Tue 11/3/20 Mon 12/14/20 0%

Tabel 4.2 WBS Terbaru Hasil Penelitian

 66

4.2. Pembagian Tugas

Dalam penyelesaian Sistem Knowledge Repository Management ini

dilakukan oleh tim General Affairs dan tim DEX.

Nama Tim Nama Tugas

1. Bu Sendylenvi Regia Product Owner

2. Pak Adnan Sudrajat Project Manager
3. Gema Rendrahadi System Analyst
4. Zalmah Nur H System Analyst
5. Ricky Hilmi S. System Analyst

Tim General Affairs : 6. Candra Nur Fajar System Analyst

7. Hafizah Dellya S. System Analyst
8. Bezky Dwiyantama System Analyst
9. Iin Ayu Lestari System Analyst
10. Masruri Ramadhaniyah System Analyst
11. Asep Saepul Achmad System Analyst
1. Sherly Widi Lestari System Analyst
2. Bu Angel System Analyst
Tim DEX :
3. Rita Ajeng System Analyst
4. Amalia Huwaidah System Analyst

Pembagian tugas dalam proyek ini saya sajikan dalam RACI Matrix. RACI
model adalah singkatan dari Responsible, Accountable, Consulted and
Informed. RACI Model adalah matriks untuk seluruh aktivitas atau otorisasi
keputusan yang harus diambil dalam suatu organisasi yang dikaitkan dengan
seluruh pihak atau posisi yang terlibat.
 67

Simbol Nama Keterangan

A Orang yang akhirnya bertanggung jawab dan memiliki otoritas
Accountable
untuk memutuskan suatu perkara.
C Orang yang diperlukan sarannya dan berkontribusi akan kegiatan

Consulted tersebut atau sebagai pihak yang menjadi support dalam

pengerjaan proses pekerjaan.
I Orang yang perlu tahu hasil dari suatu pekerjaan yang sudah
dilakukan atau orang yang mengkonsumsi hasil pekerjaan
Informed
tersebut. Bisa sebagai penerima informasi/hasil pekerjaan sebagai
dasar pekerjaan/proses lainnya.
R Orang yang melakukan suatu kegiatan atau melakukan pekerjaan
Responsible
secara langsung.

Tabel 0.3 RACI Matrix

 68

Keterangan:

A/C = Accountable dan Consulted, A/I = Accountable dan Informed,

A/R = Accountable dan Responsible, C/I = Consulted dan Informed,
C/R = Consulted dan Responsible, I/R = Informed dan Responsible.

4.3. Hasil Implementasi

Berikut adalah hasil implementasi dari pengembangan sistem Knowlegde
Repository Management.

4.3.1. Information Architecture (IA)

Diagram Information Architectur dibuat menjadi 3 diagram. Yaitu
diagram IA untuk staff – leader, diagram IA untuk guest, diagram IA untuk
admin – superadmin.
69

Gambar 4.1 Information Architecture staff - leader

70

Gambar 0.2 IA admin - superadmin

71

Gambar 0.3 IA guest

 72

4.3.2. Use Case

Use case dibawah ini adalah hasil pengembangan dari use case
sebelumnya.

Gambar 4.4 Use case sistem KRM terbaru

2.2.13. User Flow

Diagram user flow dibuat menjadi 3 diagram. Yaitu diagram user flow
untuk staff – leader, diagram user flow untuk guest, dan diagram user flow
untuk admin – superadmin.
73

Gambar 0.5 User flow untuk staff – leader dan guest

74

Gambar 0.6 User flow untuk admin – superadmin

75

Gambar 0.7 User flow untuk guest

 76

2.2.14. Activity Diagram

Activity Diagram dibuat untuk menjelaskan aktivitas dalam user flow.

A. Activity diagram Login

Gambar 4.8 Activity diagram - Login

 77

B. Activity diagram Cari Dokumen

Gambar 4.09 Activity diagram - Cari Dokumen

 78

C. Activity Diagram Unduh Dokumen

Gambar 4.10 Activity diagram - Unduh Dokumen

 79

D. Activity Diagram Persetujuan Minta Izin Unduh Dokumen

Gambar 0.11 Activity diagram - Persetujuan Minta Izin Unduh Dokumen

 80

E. Activity Diagram Upload Dokumen

Gambar 4.12 Activity Diagram - Upload Dokumen

 81

F. Activity Diagram Persetujuan Unggah Dokumen

Gambar 4.13 Activity diagram - Persetujuan Unggah Dokumen

 82

2.2.15. Desain Mockup dan Copywriting

A. Pemilihan color palette bernuansa hijau-tosca

B. Design Mockup menggunakan design tools Figma

Gambar 4.14 Aplikasi desain mockup Figma

C. Progress Mockup Staff-Leader dan Guest = 100%

83
84
85
 86

D. Copywriting adalah sebuah teknik menghasilkan tulisan yang membuat

pembaca memberikan respon yang kita inginkan – tulisan ini di disebut
copy. Copy dibuat agar pembaca mulai membeli, mendaftar, mengingat,
atau melakukan tujuan lain yang Anda inginkan dari tulisan Anda.

Copywriting Staff-Leader dan Guest 9 dari 24 flow (37,5%),

Copywriting Admin-Superadmin 0%.

Gambar 4.15 Desain Halaman Beranda sebelum copywriting

 87

Gambar 4.16 Desain halaman Beranda setelah copywriting

2.2.16. Branding Development

Pemetaan nama website repository (existing), website aplikasi

Telkom (existing), dan istilah-istilah. Beberapa nama website yang sudah
ditemukan:

Gambar 0.17 Branding sistem Knowledge Repository Management.

4.4. Pengujian
Pengujian ini dilakuan untuk prototipe desain mockup staff – leader dan
guest. Pengujian ini dilakukan dengan metode Heuristic Evaluation UX design.
Heuristic Evaluation adalah suatu analisis digunakan untuk mengidentifikasi
masalah umum kegunaan produk sehingga masalah dapat diselesaikan, akibatnya
 88

meningkatkan kepuasan dan pengalaman pengguna dan meningkatkan peluang

keberhasilan produk digital secara keseluruhan.

4.5. Hasil Pengujian

Setelah melakukan perancangan dan pengembangan pada sistem ini penulis

akan menjabarkan hasil pengujian dan analisis terhadap sistem ini. Dibawah ini
adalah hasil pengujian prototipe desain mockup staff – leader dan guest
menggunakan metode Heuristic Evaluation.

A. Visibility of system status

Nilai (1-5) Tanggapan Saran
Status sistem sudah
cukup jelas, hanya saja
pada bagian
pengapprove masih System status
4 tidak jelas siapa yang berdasarkan perannya
approve karena ada diteliti lebih jeli lagi
yang tab menunya
untuk supervisor tapi
masih status approver

B. Match between system and the real world

Nilai (1-5) Tanggapan Saran
Untuk sistem sudah
5 mirip dengan sistem
katalog yang sudah ada

C. User control and freedom

Nilai (1-5) Tanggapan Saran
Untuk navigasi
memang sudah jelas, Tambahkan fungsi
3
hanya saja belum ada undo atau redo
sistem undo atau redo

D. Consistency and standards

Nilai (1-5) Tanggapan Saran
Tampilan sudah bisa
dibilang konsisten Tampilan pada
hanya pada bagian pencarian semua dan
4
Guest, pencarian semua pencarian biasa
dan pencarian biasa dimiripkan
bagian awal berbeda
 89

E. Error prevention
Nilai (1-5) Tanggapan Saran
Belum ada tampilan
meyakinkan kembali
Tambahkan tampilan
apa yang hendak
meyakinkan kembali
dilakukan pada
2 sehingga bisa
beberapa bagian,
mencegah salah
seperti pada bagian
keputusan
Uploader saat akan
mengupload dokumen

F. Recognition rather than recall

Nilai (1-5) Tanggapan Saran
Tampilan memang
sudah familiar dengan
Diberi penjelasan atau
sistem yang sudah ada
judul singkat yang
hanya saja, seperti pada
3 agak besar mengenai
bagian riwayat
informasi halaman
persetujuan, masih agak
yang sedang dibuka
memikir sedikit
fungsinya untuk apa

G. Flexibility and efficiency of use

Nilai (1-5) Tanggapan Saran
Sudah fleksibel dan
5
efisien

H. Aesthetic and minimalist design

Nilai (1-5) Tanggapan Saran
Tampilan sudah cukup
5 dan memberikan
informasi penting saja

I. Help users recognize, diagnose, and recover from errors

Nilai (1-5) Tanggapan Saran
Meskipun sudah ada
Tambahkan sistem
2 FAQ namun belum ada
troubleshooting
sistem troubleshooting

J. Help and documentation

Nilai (1-5) Tanggapan Saran
Sudah ada FAQ, namun
FAQ lebih
belum secara spesifik
3 dispesifikkan lagi dan
dan masih belum ada
tambahkan User Guide
User Guide
 90

4.5.1. Kelebihan

Dengan dikembangkannyanya sistem ini menggunakan metode-

metode yang telah digunakan dalam penelitian ini, hasilnya memiliki
beberapa kelebihan, yaitu:
A. Proses requirement bisa menghasilkan banyak informasi yang
dibutuhkan dalam pengembangan sistem Knowlegde Repository
Management. Hal ini dikarenakan metode pengumpulan informasi
dan bahan untuk pembangunan sistem ini menggunakan metode
design sprint dan produck backlog.
B. Dengan adanya diagram UML, pihak pengembang dapat membuat
dan memahami alur proses dan spesifikasi sistem yang dilustrasikan
ke dalam bentuk diagram. Keuntungan dari membuat diagram UML
adalah pihak pengembang dapat meringkas detail proses dan detail
arsitektur sistem sehingga pengguna bisa langsung memahami
sistem dengan melihat diagram UML yang dibuat.
C. Dengan adanya copywriting dalam User-Centered Design, phak
pengembang dapat menetapkan bahasa dari kata-kata yang
digunakan dalam diagram UML, dan mockup design sistem ini.
D. Agile Development mempermudah pihak pengembang dalam
mengembangkan suatu sistem. Harapan bagi para pengembang
adalah dapat membuat sistem yang baik dan dapat digunakan oleh
orang banyak. Tentunya tujuan tersebut bisa tercapai jika pihak
pengembang mengikuti aturan dan persyaratan yang berlaku dan
meyelesaikan tugasnya sebagai pengembang hingga tuntas.

4.5.2. Kekurangan
Kemudian dalam pengembangan sistem ini juga memiliki beberapa
kekurangan, yaitu:

A. Tidak konsisten ketika membangun dan mengembangkan suatu

sistem menggunakan proses tertentu dalam Agile Development
membuat penegmbangan sistem menjadi kacau.
 91

B. Durasi pekerjaan memerlukan waktu yang lebih lama daripada yang

direncanakan.
C. Beberapa permintaan penambahan fungsi atau proses baru ketika
sistem dikembangkan membuat beberapa proses pembangunan
sistem harus “mundur satu tahap kebelakang”.
D. Perlu memaksimalkan dokumentasi pengembangan perangkat
lunak, khususnya dalam penggambaran alur proses, interaksi
penggun dengan sistem, dan arsitektur sistem dengan diagram.
 92

BAB V
KESIMPULAN DAN SARAN
5.1. Kesimpulan

Knowledge repository adalah portal web untuk menyimpan dokumen hasil

research dan inovasi DDS yang valid, ter-update, dan mudah diakses dengan
proses yang secure dan user-friendly. Sistem ini dibangun karena ingin
memperbaiki sistem yang sebelumnya dibangun di Divisi Digital Service, yaitu
sistem Digital Administrative Management DDS. Dalam laporan ini, disajikan
dokumentasi pembangunan dan pengembangan sistem Knowlegde Repository
Management. Adapun isi dokumentasi sistem ini meliputi:

A. Analisis
a. Requirement
B. Perancangan
a. Backlog / Product Backlog
b. Mind Map dan Use Case
c. Design Sprint
C. Work Breakdown Structure
D. Information Architecture (IA)
E. Pengembangan Use Case
F. User Flow
G. Activity Diagram
H. Desain Mockup dan Copywriting
I. Branding Development

5.2. Saran
Metode pengembangan perangkat lunak yang diterapkan dalam
pengembangan sistem Knowledge Repository Management sudah bagus namun
perlu dikembangkan lebih lanjut karena masih banyak metode yang bisa dipelajari
dan digunakan agar sistem yang sedang dibangun dan dikembangkan menjadi
sistem yang lebih efisien.
 93

DAFTAR PUSTAKA

Burns, R. N., & Dennis, A. R. (1985). Selecting the appropriate application

development methodology. ACM SIGMIS Database, 17(1), 19–23.
https://doi.org/10.1145/1040694.1040696

Carol, B., & Doake, J. (2001). Object-Oriented Systems Development. McGraw-

Hill.

Dharwiyanti, S., & Wahono, R. S. (2003). Pengantar Unified Modeling LAnguage

(UML). IlmuKomputer.Com, 1–13. Retrieved from
http://www.unej.ac.id/pdf/yanti-uml.pdf

Elliott, G. (2004). Global business information technology: an integrated systems

approach. Pearson Education.

Herbsleb, J. D., & Moitra, D. (2001). Global software development. IEEE Software,
18(2), 16–20. https://doi.org/10.1109/52.914732

Kniberg, H. (2007). Scrum and XP Practice. C4Media, USA.

Kotonya, G., & Sommerville, I. (1998). Requirements engineering: processes and

techniques. Wiley Publishing.

Pérez-Montoro, M. (2013). What Is Information Architecture? Oc.Ac.Ge, 2013.

Retrieved from
http://www.iainstitute.org/documents/learn/What_is_IA.pdf%5Cnhttp://oc.ac
.ge/file.php/16/What_is_Information_Architecture.pdf

Ralph, P., & Wand, Y. (2009). A proposal for a formal definition of the design
concept. Lecture Notes in Business Information Processing, 14 LNBIP, 103–
136. https://doi.org/10.1007/978-3-540-92966-6_6

Shi, N. S., Ph, D., Murthy, V. K., & Ph, D. (2011). Architectural Issues of Web-
Enabled Electronic Business. In Architectural Issues of Web-Enabled
 94

Electronic Business. https://doi.org/10.4018/978-1-59140-049-3

Specification, O. M. G. A. (2007). Omg unified modeling language (omg uml),

superstructure, v2. 1.2. Object Management Group, 70.
 95

LAMPIRAN

LAMPIRAN
 Lampiran 5 Lembar Penilaian 100

Halaman Sengaja dikosongkan

 101

Halaman sengaja dikosongkan

 102

Halaman sengaja dikosongkan

 103

Halaman sengaja dikosongkan

 104

Lampiran 6 Dokumentasi Kegiatan Program Laithan Akademik

1. Innovation Day
 105

2. Proyek Knowledge Repository Management

 106

3. Kunjungan Industri dan Acara Internal Telkom DDS