HASIL PENELITIAN

PERANCANGAN SISTEM INFORMASI

AKADEMIK INFORMAL:

STUDI KASUS

CAMBRIDGE ENGLISH COURSE

JAKARTA

Oleh :

Zulhalim, SKom, MTI

STMIK JAYAKARTA

JAKARTA

2011

KATA PENGANTAR

Dengan memanjatkan puji syukur atas karunia Allah yang Maha Esa atas

karunia yang dilimpahkan kepada penulis, sehingga penyusunan hasil penelitian yang

berjudul “PERANCANGAN SISTEM INFORMASI AKADEMIK INFORMAL:

STUDI KASUS CAMBRIDGE ENGLISH COURSE JAKARTA” ini dapat

diselesaikan dengan baik. Hasil penelitian ini penulus susun sebagai salah satu

perwujudan dari Tri Dharma Perguruan Tinggi yang akan dijadikan untuk menambah

perbendaharaan di Perpustakaan STIE / STMIK Jayakarta.

Penulis memilih pembahasan mengenai Sistem Informasi Akademik

dikarenakan pentingnya peranan sistem informasi bagi suatu lembaga pendidikan

khusus nya bidang informal. Pembahasan mulai dari pendaftaran siswa, pelaksanaan

belajar- mengajar sampai dengan kelulusan siswa. Semoga hasil penelitian ini dapat

berguna bagi lembaga pendidikan informal dan citivitas akademika STIE/STMIK

Jayakarta.

Jakarta, Nopember 2011

Penulis,

ii

ABSTRACT

Academic administration service is one of business process that maintain by an

institutional education in interaction with their customers. The service gift mechanism which

effective, efficient and do not make any complicated for student have come to be competitive

advantage for that institution. Manual services which automation a system not yet of course

reply the customer satisfaction. On that account, analysis to customer needs require to be

seen through deeper and entire all requirements to system require to be managed better.

Online Academic Information System is one of the online applications which needed

by Cambridge English Course Jakarta to serve an good academic service to the student which

it is used to done by manual/offline and usually not integrated. Some weakness which occur

on existing offline system and existence of policy change about adding branch in the future

trigger the existence of this Online Academic Information System, besides caused by its

desire from students to get the service which facilitating them with no difficulties.

To make this project success, a complete and well documented software requirements

becomes the main requisite. Software requirement specification yielded by adapting Rational

Unified Process (RUP) methodology is expected to help this software developer. In this

project, RUP adaptation particularly business modeling and requirement discipline will be

conformed to characters of application being developed.

iii

ABSTRAK

Pelayanan administrasi akademik merupakan salah satu proses bisnis yang dijalankan

oleh suatu lembaga pendidikan terkait dengan interaksinya kepada customer. Mekanisme

pemberian layanan yang efektif, efisien serta tidak menyulitkan mahasiswa telah menjadi

suatu competitive advantage bagi suatu perguruan tinggi saat ini. Layanan manual yang

diotomasi ke dalam suatu sistem belum tentu menjawab kepuasan pelanggan. Oleh sebab itu,

analisa terhadap customer needs perlu diselami lebih dalam dan seluruh requirement

terhadap sistem perlu dikelola dengan baik.

Sistem Informasi Akademik Online merupakan sebuah aplikasi online yang

diperlukan oleh Cambridge English Course Jakarta dalam memberikan layanan akademik

kepada siswa yang selama ini dijalankan melalui sistem offline. Beberapa kelemahan yang ada

pada sistem offline dan adanya perubahan kebijakan yang berlaku dari pihak akademik

mengenai rencana penambahan cabang dan kerjasama dengan tempat pelatihan yang lain

turut memicu keberadaan Sistem Informasi Akademik Online ini, selain karena adanya

keinginan dari siswa untuk memperoleh layanan yang memudahkan mereka.

Spesifikasi kebutuhan perangkat lunak yang lengkap dan terdokumentasi dengan baik

sangat dibutuhkan untuk menunjang berhasilnya pengembangan aplikasi ini. Dengan

memanfaatkan metodologi Rational Unified Process (RUP) diharapkan spesifikasi yang

dihasilkan dapat membantu dan mempermudah Departemen Pengembangan dalam

pengembangan aplikasi ini. Adaptasi RUP khususnya disiplin business modeling dan

requirement dalam proyek ini akan disesuaikan dengan karakter aplikasi yang akan

dikembangkan.

iv

BAB I

PENDAHULUAN

I.1. Latar Belakang

Pada era Teknologi Informasi sekarang, software sudah menjadi elemen

yang paling signifikan untuk membantu organisasi untuk meningkatkan

kinerja dan produktivitas. Dengan perkembangan tekonolgi informasi yagn

semakin pesat ini, sekolah - sekolah baik formal maupun informal mulai

menerapkan sebuah sistem informasi akademik berbasis Web guna

memudahkan orang - orang yang berkepentingan untuk mengakses sistem ini.

Sistem Informasi Akademik (SIAK) tidak bersifat komersil (tidak dijual

bebas dipasaran) sehingga pembuatannya bersifat tailor made. Oleh karena

pembuatannya yang bersifat tailor made tersebut, apabila ingin

mengembangkan sebuah SIAK yang baru maka Software Development

Process harus dilalui oleh pengembang terlebih dahulu, baru akhirnya dapat

menghasilkan sebuah SIAK untuk kebutuhannya.

Untuk memudahkan para pengembang software maka akan dibuat

sebuah generic model untuk SIAK. Dimana dalam pengembangan model

tersebut akan menggunakan metode 'RUP'. Sehingga ketika pengembang ingin

mengembangkan SIAK baru, tinggal hanya menambahkan fitur - fitur baru

untuk spesifik kegiatan bisnis dia.

RUP merupakan salah satu metodologi yang merupakan kumpulan

beberapa best practices dalam proses rekayasa perangkat lunak. Selain

merupakan metodologi yang lengkap, RUP juga didukung oleh perangkat

pengembangan yang baik dalam implementasinya. Proyek akhir ini akan

membahas bagaimana RUP digunakan dalam menentukan spesifikasi

perangkat lunak dalam domain masalah di pendidikan.

Setelah membuat generic model dari SIAK maka sebagai implementasi

dari model tersebut akan dibuat sebuah prototipe aplikasi dari SIAK dengan

mengambil Studi Kasus Cambridge English Course Jakarta.

Dengan adanya sistem ini diharapkan para stakeholder (baik owner,

siswa dan staff) mendapatkan informasi yang akurat dan update. Karena

modul ini sangat diperlukan oleh Lembaga Pendidikan dalam kegiatan

1

operasionalnya sehari-hari, maka diharapkan pengembangannya tepat waktu,

tidak melebihi anggaran, dan perangkat lunak yang dihasilkan sesuai dengan

kebutuhan dan berkualitas tinggi. Spesifikasi kebutuhan perangkat lunak yang

lengkap dan terdokumentasi dengan baik sangat dibutuhkan untuk menunjang

berhasilnya pengembangan modul ini.

Selain itu dengan adanya sistem ini diharapkan tidak hanya sebagai

tool/alat bantu dalam kegiatan operasional dalam sebuah institusi pendidikan

namun juga dapat dijadikan sebagai entry barrier dan enablers dalam bersaing.

I.2. I.3.

Tujuan dan Manfaat

Tujuan yang ingin dicapai dalam proyek akhir ini adalah

mengembangkan generic model dari Sistem Informasi Akademik (SIAK) yang

dapat diakses melalui internet.

Selain itu menentukan kebutuhan dan prasyarat perangkat lunak Sistem

Informasi Akademik Online yang sesuai dengan kebutuhan stakeholder.

Spesifikasi dan prasyarat perangkat lunak ini dihasilkan dengan memetakan

prosedur kerja dan proses bisnis yang ada. Spesifikasi dan prasyarat yang

dihasilkan dapat digunakan sebagai dasar implementasi selanjutnya.

Manfaat yang diberikan proyek akhir ini adalah mempermudah

pengembang perangkat lunak untuk membangun suatu perangkat lunak yang

dapat digunakan oleh pihak Lembaga Pendidikan Informal untuk mendukung

kegiatan pengelolaan/administrasi siswa.

Batasan

Batasan pengerjaan proyek akhir ini adalah sebagai berikut:

1. Lingkup pekerjaan yang akan dilakukan dibatasi pada dua core process

disciplines dalam RUP, yaitu business modelling dan requirements.

Hasilnya akan dituangkan dalam dokumen standar RUP untuk kedua

proses utama tersebut. , antara lain : dokumen Software Requirement

Specification (SRS), dokumen vision, dokumen usecase specification dan

dokumen glossary. Dokumen-dokumen ini disusun dengan mengikuti

pedoman dan template yang diberikan oleh RUP.

2. Spesifikasi yang akan dikembangkan tidak mencakup :

a. Modul Administrasi User dan pengaturan hak akses-nya

2

b. Aplikasi Keuangan

c. Data kursus.

d. Proses - proses di luar bisnis proses bisnis inti dari domain pendidikan

seperti Human Resource Management, procurement, technology

development, firm infrastructure

I.4. Sistematika Penulisan

Penulisan proyek akhir ini akan dibagi dalam 7 bab dan disusun

dengan sistematika penulisan sebagai berikut :

Bab I

BAB II

BAB II BAB IV

: Pendahuluan

Berisi latar belakang pembuatan proyek akhir. Tujuan dan

manfaat penulisan proyek akhir dan metodologi pengembangan.

: Profil Cambridge English Course

Jakarta

Berisi profil singkat mengenai Cambridge English Course.

Sejarah, visi dan misi serta struktur organisasinya.

: Landasan Teori

Membahas secara umum mengenai metodologi pengembangan

spesifikasi perangkat lunak RUP dalam penentuan spesifikasi dan

prasyarat perangkat lunak.

: Pemodelan Proses Bisnis Sistem Informasi Akademik Online

Membahas tentang workflow layanan Sistem Informasi

Akademik online dan menggambarkannya dalam bentuk diagram

aktvitas yang menjadi dasar untuk mengidentifikasi business

worker dan business worker operation dan untuk menentukan

proses mana yang akan diotomasi dengan bantuan perangkat

lunak.

BAB V

BAB VI

: Analisa Kebutuhan Perangkat Lunak

Menjelaskan tentang pendefinisian perangkat lunak berdasarkan

hasil pemodelan bisnis yang telah dilakukan sebelumnya.

: Implementasi RUP

Membahas tentang pemilihan aktivitas dalam kerangka kerja

RUP dan cuztomization workflow yang ada di RUP guna

diterapkan dalam pengerjaan proyek akhir ini.

3

BAB VII : Penutup

Berisi kesimpulan yang merupakan evaluasi dari seluruh kegiatan

dalam proyek akhir ini serta saran untuk pengembangan lebih

lanjut

4

BAB II

PROFIL CAMBRIDGE ENGLISH COURSE

JAKARTA

II.1.

Sejarah Cambridge English Course Jakarta

Cambridge English Course didirikan pada bulan 01 Juni 2000

dengan tujuan untuk mentransformasi sistem pengetahuan dibidang Teknologi

Informasi, sistem peluang pengembangan profesionalisme melalui

peningkatan skill di bidang Teknologi Informasi, serta menyiapkan tenaga

kerja yang handal bagi perusahaan-perusahaan dalam menghadapi AFTA.

Untuk menghadapi tantangan ini maka Cambridge English Course

memiliki rasa tanggung jawab yang sangat besar untuk dapat meningkatkan

kemampuan sumber daya manusia yang ada saat ini. Cambridge English

Course berusaha untuk dapat meningkatkan mutu pendidikan dengan

membuat kurikulum yang dapat dengan mudah mentransfer ilmu-ilmu yang

dibutuhkan dalam pengembangan Teknologi Informasi dimana pendidikan

Teknologi Informasi ini juga harus

diimbangi dengan penyediaan sarana pendidikan yang berkualitas dan

memadai. Seperti yang kita ketahui bahwa pendidikan bidang Teknologi

Informasi memerlukan biaya yang tidak sedikit oleh karena itu masih sedikit

sekali orang-orang yang bisa menikmati pendidikan di bidang ini. Dengan

demikian, diperlukan dana yang cukup besar untuk mewujudkan SDM yang

berkualitas dan mampu bersaing dalam bidang Teknologi Informasi.

Cambridg Campus menyediakan program-program pendidikan yang

mengupas habis tentang teknologi e-commerce. Cambridge English Course

menawarkan program profesional yang dapat menjadikan masyarakat menjadi

seorang Profesional TI. Program Cambridge English Course terdiri dari 3 jenis

yaitu:

• Professional Cambridge Expert (1 Tahun)

• Short Programs (1 bulan) :

Web Programmer

Web Developer

Web Design

Professional Class for Database

5

Professional VB Developer dll

• Special Application Training

WAP Database Application

Java mobile (J2ME) Application Training

Seluruh materi disampaikan dalam Bahasa Indonesia. Hal ini

dimaksudkan agar setiap siswa dapat lebih cepat memahami dan menguasai

materi yang dipelajari. Setiap materi telah dirancang sedemikian rupa agar

dapat membuat siswa menjadi ahli pada bidang Teknologi Informasi.

Untuk memudahkan siswa yang berkualitas, setiap siswa akan

ditantang dengan rancangan kasus-kasus latihan mandiri yang kami berikan

melalui Program Interaktif. Program ini akan memberikan motivasi untuk

melatih kemampuan siswa dalam menyelesaikan setiap kasus yang diberikan

dengan metoda belajar profesional (lihat Metode Belajar).

Seiring dengan semakin matangnya usia Cambridge English Course

dalam

penyelenggaran dan bimbingan konsultasi IT kepada siswanya,Cambridge

English Course mulai melebarkan sayapnya dalam pembangunan dan

pengembangan aplikasi sistem informasi. Pembangunan dan pengembangan

sistem informasi ini ditujukan untuk dapat menambah keuntungan secara

umum terhadap proses

bisnis ataupun aktifitas instansi,perusahaan,badan usaha,ataupun

pribadi.Dengan penggunaan IT dan sistem informasi yang handal diharapkan

proses bisnis ataupun aktifitas sehari-hari yang cheaper ,better dan faster

dapat diwujudkan.

II.2. Visi dan Misi

Lembaga Pendidikan Cambridge Campus, bermaksud untuk

menyelenggarakan sekolah non formal diseluruh tingkatan yang berbasis dan

berkompetensi khusus dalam bidang Teknologi Informasi (Information

Technology) dan diharapkan dapat terlaksana diseluruh Indonesia.

Adapun tujuannya adalah: Memasyarakatkan Information Technology

secara meluas dan merata ditengah-tengah masyarakat tentang betapa

pentingnya arti dan manfaat Information Technology dalam pergaulan,

6

pekerjaan sebagai suatu System jaringan kerjasama (Networking). Adapun

Visi dan Misi Cambridge English Course adalah sebagai

berikut:

VISI

Cambridge English Course sebagai wahana dan pelopor pengembangan

Information

Technology untuk mewujudkan masyarakat IT

MISI

Membangun dan mengembangkan sistim informasi yang handal dengan

menggunakan IT

Mengutamakan kemampuan dalam bidang IT sebagai upaya untuk

memiliki kompetensi dan berbasis IT

Melaksanakan pendidikan IT disetiap jenjang pendidikan sedini mungkin

dan secara luas dalam rangka akselerasi masyarakat yang sadar IT

Mendayagunakan tenaga profesional IT sebagai sumber daya dan

menciptakan lingkungan yang bernuansa dan bernafaskan IT

Menggunakan tools kit (alat bantu) yang senantiasa sejalan dan seiring

dengan nilai-nilai dan norma yang berlaku di masyarakat

Menciptakan tenaga profesional IT yang dapat menjadi enterpreneur dan

warga dunia

II.3. Strategi

• Cambridge English Course menjalin kerjasama dengan instansi,

perusahaan, badan usaha, ataupun pribadi dalam pem bangunan dan

pengembangan sistem informasi dengan menggunakan perangkat high

technology.

• Cambridge English Course menjadikan siswa/peserta pelatihan sebagai

subjek didalam proses pengembangan dan penyebarluasan IT.

• Cambridge English Course mengadakan hubungan kerjasama yang erat

dengan

institusi terkait sebagai partnership serta menjalin hubungan koordinasi

dengan lembaga yang memiliki kompetensi yang sama dalam

penyelenggaraan pelatihan IT.

7

• Cambridge English Course menjalin kerjasama dengan instansi,

perusahaan, badan

usaha, ataupun pribadi dalam mengadakan sosialisai kemajuan Teknologi

Informasi.

• Cambridge English Course menjalin kerjasama dengan instansi,

perusahaan, badan

usaha, ataupun pribadi dalam menyediakan tenaga profesional bidang IT.

• Cambridge English Course menjalin kerjasama dengan instansi,

perusahaan, badan

usaha, ataupun pribadi dalam membentuk serta mematangkan nilai-nilai

luhur bangsa kepada siswa pada khususnya dan masyarakat pada

umumnya.

• Cambridge English Course menjalin kerjasama dengan instansi,

perusahaan, badan

usaha, ataupun pribadi dalam meningkatkan dan mengoptimalkan potensi

diri siswa.

II.4. Struktur Organisasi

Struktur organisasi Cambridge English Course dirancang secara

spesifik, terutama untuk dapat mendukung Visi dan Misi yang telah dicanangkan.

Gambar 2.1. Struktur Organisasi Cambridge

English Course

8

BAB III

LANDASAN TEORI

III.1. Rational Unified Proses

Rational Unified Process (RUP) merupakan suatu metode rekayasa

perangkat lunak yang dikembangkan dengan mengumpulkan berbagai best

practise yang terdapat dalam industri pengembangan perangkat lunak. Ciri

utama metode ini adalah menggunakan use-case driven dan pendekatan iteratif

untuk siklus pengembangan perangkat lunak. Dalam pendekatan ini,

pengembangan diorganisasikan sebagai serangkaian proyek kecil yang pendek

dan mempunyai waktu pengembangan yang tetap yang disebut sebagai iterasi.

[CRA02]. Setiap iterasi terdiri dari aktivitas analisa kebutuhan, perancangan,

implementasi, dan pengujian. Perangkat lunak akan semakin lengkap seiring

dengan iterasi yang dilakukan. Karena itu pendekatan ini disebut iterative and

incremental development [CRA02]. Gambar 2.1 menunjukkan secara

keseluruhan arsitektur yang dimiliki RUP [RUP03][PHI00].

Gambar 3.1: Arsitektur Rational Unified Process [RUP03]

9

RUP menggunakan konsep object oriented dengan aktifitas yang

berfokus pada pengembangan model dengan menggunakan unified model

language (UML). UML adalah bahasa standar untuk penulisan blueprint

perangkat lunak [BOO99]. UML dapat digunakan untuk memvisualisasikan,

mendefinisikan, membangun, dan mendokumentasikan artifact pengembangan

perangkat lunak.

Dalam gambar 3.1 dapat dilihat bahwa RUP memiliki dua dimensi,

yaitu [RUP03]:

1. Dimensi pertama digambarkan secara horizontal. Dimensi ini mewakili

aspek-aspek dinamis dari pengembangan perangkat lunak. Aspek ini

dijabarkan dalam tahapan pengembangan atau fase. Setiap fase akan

memiliki suatu major milestone yang menandakan akhir dari awal dari fase

selanjutnya. Setiap fase dapat terdiri dari satu atau beberapa iterasi.

2. Dimensi kedua digambarkan secara vertikal. Dimensi ini mewakili aspek-

aspek statis dari proses pengembangan perangkat lunak yang

dikelompokkan ke dalam beberapa disiplin. Proses pengembangan

perangkat lunak yang dijelaskan kedalam beberapa disiplin terdiri dari

empat elemen penting, yakni who is doing what, how and when

III.1.1. Dimensi Dinamis

RUP membagi siklus pengembangan perangkat lunak atau siklus hidup

perangkat lunak ke dalam empat sequential phases, yaitu:

• Inception

Fokus utama fase ini adalah mendapatkan pemahaman mengenai

keseluruhan requirement perangkat lunak dan menentukan lingkup

pengembangan perangkat lunak tersebut. Milestone fase ini disebut

lifecycle objective yang memberikan gambaran mengenai kelangsungan

hidup suatu proyek. Secara garis besar lifecycle objective terdiri dari ruang

lingkup dan batasan dari proyek, perkiraan biaya dan waktu, dan

penentuan risiko-risiko yang akan dihadapi. Melalui fase inception akan

diperoleh kesepakatan antara semua pihak yang terlibat dalam proyek

tersebut (stakeholder) untuk menentukan apakah suatu proyek layak yang

mungkin untuk dilanjutkan atau tidak.

10

• Elaboration

Fokus utama fase ini terletak pada requirement perangkat lunak. Beberapa

fungsi perangkat lunak yang penting dan kritis mulai dirancang dan

diimplementasikan. Milestone fase ini disebut lifecycle architecture yang

merupakan arsitektur sistem yang menjadi landasan dalam melakukan

perancangan dan implementasi fase selanjutnya. Untuk menghasilkan

arsitektur sistem ini diperlukan pemahaman yang luas dan umum

mengenai sistem yang ingin dihasilkan, termasuk didalamnya

fungsionalitas utama dan kebutuhan non fungsional serta batasan-batasan

dari sistem yang akan dikembangkan.

• Construction

Fokus fase ini terletak pada rancangan dan implementasi perangkat lunak

dimana prototipe awal yang dihasilkan dalam fase sebelumnya akan

dikembangkan hingga menjadi first operational product. Milestone fase ini

adalah initial operational capability. Dalam fase ini sistem akan

dikembangkan berdasarkan baseline architecture yang telah dihasilkan

dalam fase sebelumnya. Jika sistem telah siap untuk melalui beta testing

maka milestone fase ini telah terpenuhi.

• Transition

Fokus fase ini adalah untuk memastikan apakah perangkat lunak atau

sistem yang dihasilkan telah memenuhi batasan kualitas yang ditentukan.

Dalam fase ini dilakukan pengujian produk, perbaikan bugs yang

ditemukan, memberikan pelatihan bagi pengguna, atau melakukan

penyesuaian fitur-fitur perangkat lunak (minor adjustment) berdasarkan

saran dan masukan dari pengguna. Milestone fase ini adalah product

release yang siap digunakan oleh pengguna akhir. Pada akhir fase ini

seharusnya semua lifecycle objective yang telah didefinisikan pada fase

inception harus telah dipenuhi dan proyek ini siap untuk ditutup.

Selesainya suatu lifecycle mungkin merupakan awal suatu lifecycle lainnya

untuk produk yang sama.

11

III.1.2. Dimensi Statis

Dimensi statis RUP diorganisasikan ke dalam beberapa disiplin.

Suatu disiplin merupakan kumpulan dari berbagai aktivitas yang perlu

dilakukan oleh individu maupun tim yang memiliki peran tertentu untuk

menghasilkan suatu artifact. Rangkaian aktivitas dalam suatu disiplin

dijabarkan dalam suatu workflow. RUP mendefinisikan sembilan disiplin

yang perlu dilakukan dalam mengembangkan suatu produk perangkat lunak,

yaitu [RUP03]:

• Business Modeling

Tujuannya untuk memahami struktur dan dinamika organisasi dimana

sistem akan dikembangkan, permasalahan yang dihadapinya dan

mengidentifikasi langkah-langkah perbaikan yang dapat dilakukan, serta

memastikan customer, end-user, dan pengembang mempunyai persepsi

yang sama terhadap target organisasi serta memperoleh requirement yang

diperlukan untuk mendukung pencapaian target organisasi.

• Requirement

Tujuan disiplin ini adalah membuat dan memelihara kesepakatan yang

telah ada antara customer atau stakeholder lainnya mengenai apa yang

dapat dilakukan oleh sistem, memberikan pengertian yang lebih baik

mengenai kebutuhan sistem kepada pihak pengembang, menentukan

batasan dan lingkup sistem, menyediakan landasan perkiraan biaya dan

waktu yang dibutuhkan dan perencaan iterasi yang akan dilakukan, serta

menentukan user-interface sistem sesuai dengan kebutuhan.

• Analysis and Design

Tujuan disiplin ini adalah melakukan transformasi requirement ke dalam

bentuk rancangan sistem yang akan dikembangkan, menyusun robust

architecture, dan melakukan perubahan terhadap rancangan agar sesuai

dengan lingkungan implementasi.

• Implementation

Tujuan disiplin ini adalah untuk menentukan pengelompokan atau

organisasi program, mengimplementasikan semua kelas dan objek ke

dalam bentuk komponen seperti source file, binary, executable dan

12

lainnya, melakukan pengujian terhadap komponen-komponen yang telah

dikembangkan, dan mengintegrasikan komponen-komponen yang telah

dihasilkan tersebut ke dalam satu executable system.

• Test

Fokus utama disiplin ini adalah melakukan evaluasi dan pengujian

terhadap kualitas produk. Hal ini dilakukan dengan mencari dan

mendokumentasikan defect yang ada, menjaga kualitas perangkat lunak,

membuktikan keabsahan asumsi yang dibuat dalam rancangan dan

spesifikasi kebutuhan melalui suatu demonstrasi yang nyata, melakukan

validasi terhadap fungsi perangkat lunak yang telah dirancang dan

kesesuaian implementasi kebutuhan perangkat lunak.

• Deployment

Disiplin ini menjelaskan mengenai aktivitas-aktivitas yang perlu dilakukan

untuk memastikan produk perangkat lunak telah siap digunakan oleh end-

user.

• Configuration and Change Manegement

Disiplin ini bertujuan untuk memastikan berbagai artifact yang dihasilkan

dalam suatu proyek tetap terjaga integritasnya, mengelola perubahan

artifact berdasarkan kebijakan yang berlaku, dan melakukan penelusuran

perubahan atau versi.

• Project Management

Disiplin ini bertujuan untuk menyediakan kerangka kerja yang digunakan

untuk mengelola proyek, menyediakan pedoman praktis untuk

perencanaan, pemilihan staf, pelaksanaan dan pemantauan suatu proyek,

dan pengelolaan risiko proyek

• Environment

Disiplin ini bertujuan untuk menyediakan hal-hal yang dibutuhkan baik itu

berupa proses maupun alat bantu yang akan mendukung tim pengembang

untuk menghasilkan suatu produk perangkat lunak.

III.2. Skenario dalam Pemodelan Bisnis

Aktivitas-aktivitas yang dilakukan dalam kegiatan pemodelan bisnis

dilaksanakan sesuai dengan ruang lingkup pemodelan bisnis yang

13

bersangkutan. Ruang lingkup pemodelan bisnis tergantung pada konteks dan

kebutuhan yang ingin dicapai. Ada beberapa jenis skenario yang dapat

digunakan, yaitu:

• Organizaition chart

Apabila perangkat lunak yang akan dikembangkan tidak bertujuan untuk

mengubah bisnis ataupun proses bisnis, maka pemodelan bisnis yang

dilakukan cukup dengan membangun penjelasan singkat mengenai

organisasi dan proses-proses yang ada dalam organisasi yang bersangkutan

guna mendapatkan pemahaman yang lebih baik mengenai kebutuhan-

kebutuhan perangkat lunak atau aplikasi yang akan dikembangkan.

• Domain modeling

Apabila perangkat lunak yang akan dikembangkan bertujuan untuk

mengelola dan mempresentasikan informasi seperti sistem perbankan atau

order management system, maka pemodelan bisnis yang dilakukan adalah

membangun model informasi pada level bisnis saja tanpa

mempertimbangkan alur kerja dalam bisnis secara keseluruhan.

• One business many systems

Apabila suatu sistem yang akan dibangun berupa sistem yang sangat besar

atau keluarga aplikasi, maka pemodelan bisnis dilakukan untuk

mendapatkan kebutuhan fungsional perangkat lunak dan menjadi masukan

untuk membangun arsitektur keluarga aplikasi yang bersangkutan.

• Generic Business Model

Apabila perangkat lunak yang dikembangkan akan digunakan oleh

berbagai organisasi sebagai contoh aplikasi untuk sales support atau

billing application, maka upaya-upaya yang dilakukan dalam pemodelan

bisnis untuk menyesuaikan perangkat lunak dengan kebutuhan organisasi

dapat diabaikan.

• New business

Jika suatu organisasi menginginkan suatu line of business yang baru dan

membangun sistem informasi yang mendukungnya, maka pemodelan

bisnis yang dilakukan tidak hanya sebatas mengidentifikasi kebutuhan

perangkat lunak namun juga melakukan penilaian kelayakan antara

requirement yang ada dengan line of business yang baru itu.

14

• Revamp

Jika suatu organisasi memutuskan untuk melakukan perubahan terhadap

cara mereka melakukan proses bisnis, maka pemodelan bisnis yang

dilakukan umumnya juga meliputi business reengineering.

III.3. Model Bisnis dan Model Sistem

Salah satu keunggulan pendekatan pemodelan bisnis adalah

kemudahan untuk menghasilkan requirement perangkat lunak. Perubahan dari

model bisnis menjadi kebutuhan sistem dapat dilakukan seperti digambarkan

berikut ini.

Gambar 3.2: Hubungan Antara Model Bisnis dan Model Sistem [RUP03]

Gambar 3.3: Empat Lapisan dalam Arsitektur Sistem [RUP03]

15

Model bisnis merupakan masukan use-case view dan logical view yang

disajikan dalam analysis model seperti yang tampak dalam gambar 3.3 di atas.

Ada beberapa mekanisme utama pada tingkat analisa yang dapat

dipertimbangkan, yaitu:

• Untuk setiap business use-case yang akan mendapat dukungan dari sistem

akan diidentifikasi sebagai sub sistem dalam analysis model.

• Untuk setiap business worker yang akan didukung oleh sistem identifikasi

use-case yang merepresentasikan apa yang akan diotomasi.

• Untuk setiap business entity yang akan didukung oleh sistem, identifikasi

identity classess dalam analysis model. Beberapa diantaranya adalah

kandidat yang dipertimbangkan sebagai key mechanism dan component

entity dalam sistem.

• Untuk setiap cluster dari business entity - kelompok entiti bisnis yang

hanya digunakan dalam satu business use-case atau sebuah grup yang

sangat berhubungan dengan business entity- buat sebuah sub sistem dalam

business specific layer.

III.3.1. Relasi antara Business Model dan Business Actor dengan Sistem

Untuk mengidentifikasi use-case untuk sistem informasi, mulai

dengan business worker dalam business analysis model sperti dalam

gambar 3.4. Untuk setiap business worker, lakukan:

• Tentukan apakah business worker tersebut akan menggunakan

sistem informasi yang akan dibangun.

• Jika ya, identifikasi sebuah system actor dalam model system use-

case tersebut. Mulai dengan membuat actor dengan nama yang

sama dengan business worker.

• Untuk setiap business use-case dimana business worker

berpartisipasi, buatlah sebuah system use-case.

• Ulangi langkah di atas untuk semua business worker.

16

Gambar 3.4: Dari Business worker & Use-case Menjadi System

Actor & Use-case [RUP03]

Gambar 3.5 merupakan contoh perubahan dari model bisnis

menjadi model sistem pada proses bisnis transaksi keuangan (money

transaction) suatu bank. Dalam melakukan transaksi keuangan,

customer sebagai business actor akan berinteraksi dengan clerk

ataupun loan specialist yang berperan sebagai business worker. Ketika

melakukan transaksi keuangan clerk maupun loan specialist perlu

melakukan pengecekan terhadap profil, account ataupun catatan

pinjaman customer tersebut. Diharapkan pengecekan ini dapat

dilakukan dengan bantuan suatu sistem. Dengan demikian clerk dan

loan specialist merupakan business worker yang berinteraksi secara

langsung dengan sistem, artinya clerk dan loan specialist merupakan

kandidat system actor.

17

III.3.2.

Gambar 3.5: Ilustrasi Perubahan Business worker Menjadi Kandidat

System Actor [RUP03]

Business Worker Yang Diotomasi

Untuk setiap business worker yang akan diotomasi dengan

menggunakan sistem informasi dapat diidentifikasi sebagai kandidat

system use-case dan untuk setiap business actor yang secara langsung

akan menggunakan sistem informasi dapat diidentifikasi sebagai

kandiat system actor seperti yang diilustrasikan dalam gambar 3.6.

Apabila pada proses bisnis money transaction terdapat perubahan

skenario dimana transaksi dilakukan melalui internet banking maka

customer dapat berinteraksi langsung dengan sistem untuk melakukan

transaksi dan fungsi clerk untuk mengecek profil, account, serta

catatan pinjaman akan digantikan oleh sistem. Hal ini berarti customer

sebagai business actor akan menjadi kandidat system actor dan fungsi

clerk akan dmasukkan dalam system use-case money transaction.

18

III.3.3.

Gambar 3.6: Perubahan Business Actor Menjadi Kandidat System

Actor [RUP03]

Business Model dan Entity classes dalam Analysis Model

Untuk setiap business entity dan attribut dari business entity

yang akan dikeloka oleh sistem informasi dapat diidentifikasi sebagai

entity class dari sistem. Gambar 3.7 menunjukkan perubahan business

entity menjad entity class, dimana profil, account, serta catatan

peminjaman customer merupakan entitas yang peru dikelola oleh

sistem.

19

Gambar 3.7: Perubahan Business entity Menjadi Entity class [RUP03]

III.4. Pengelolaan Kebutuhan Perangkat Lunak

Kebutuhan perangkat lunak dapat didefinisikan sebagai [LEF03][OBE02]:

a. Kemampuan perangkat lunak yang dibutuhkan oleh pengguna untuk

menyelesaikan masalah guna mencapai suatu tujuan.

b. Kemampuan perangkat lunak yang harus dimiliki oleh suatu sistem atau

komponen sistem untuk memenuhi kontrak, standar, dan dokumentasi lain

yang diwajibkan.

Kebutuhan perangkat lunak ini harus dikelola dengan baik agar proyek

pengembangan perangkat lunak tersebut sukses. Kesalahan pendefinisian

kebutuhan merupakan kesalahan yang paling banyak terjadi dan paling mahal

untuk diperbaiki [LEF03]. Karena kebutuhan merupakan hal yang harus

dipenuhi oleh sistem yang sedang dibangun, dan kesesuaian kebutuhan

tersebut akan menentukan kesuksesan proyek, maka diperlukan upaya untuk

mengetahui tentang kebutuhan yang diperlukan, menuliskannya,

20

mengorganisasikannya, dan menelusuri setiap perubahannya. Karena itu

pengelolaaan kebutuhan adalah [OBE02]:

a. pendekatan sitematik untuk memperoleh, mengorganisasikan, dan

mendokumentasikan kebutuhan suatu sistem, dan

b. suatu proses untuk membangun dan memelihara kesepakatan antara

customer dengan tim proyek menyangkut perubahan kebutuhan sistem

yang dikembangkan.

RUP sebagai suatu metodologi juga menyediakan panduan bagaimana

mengelola kebutuhan perangkat lunak ini. Pengelolaan kebutuhan perangkat

lunak ini dijelaskan dalam disiplin requirement. Keahlian yang dibutuhkan

dalam mengelola kebutuhan perangkat lunak ini adalah:

i. Menganalisa masalah

ii. Memahami kebutuhan stakeholder

iii. Mendefinisikan sistem

iv. Mengelola ruang lingkup sistem

v. Memperbaiki definisi sistem

vi. Mengelola perubahan kebutuhan

III.5. Pelayanan Akademik saat ini

Pelayanan Akademik yang ada pada saat ini masih bersifat manual dan

belum terintegrasi. Dimana data - data siswa masih dalam bentuk file

Microsoft Word dan Excel. Proses tersebut adalah sebagai berikut:

1. Pengunjung datang ke Cambridge Campus, bagian sales dan marketing akan

menyambut kedatangan pengunjung.

2. Lalu pengunjung akan bertanya mengenai kursus - kursus yang ada di

Cambridge Campus.

3. Setelah mendapatkan penjelasan yang cukup dan merasa tertarik maka

pengunjung akan diberikan form pendaftaran dan pengunjung akan

mengisi form tersebut.

4. Apabila hanya berminat saja maka pengunjung diminta untuk

mencatat/menuliskan data - datanya di dalam buku tamu.

5. Setelah diisi dengan lengkap, maka pengunjung akan diminta untuk

memberikan sejumlah biaya registrasi dan kursus kepada bagian sales &

marketing.

21

6. Apabila data dalam form belum lengkap, bagian sales & marketing

meminta pengunjung untuk mengisinya dengan secara lengkap.

7. Setelah menyerahkan biaya registrasi dan kursus ke sales & marketing,

maka bagian sales & marketing akan memberikan tanda bukti pembayaran

(kwitansi) kepada pengunjung.

8. Selain kwitansi, pengunjung akan diberikan modul kursus sesuai dengan

mata kursus yang diminati.

9. Setelah mendapatkan modul kursus, pengunjung akan diberikan jadwal

kursus oleh bagian sales & marketing.

10. Bagian sales & marketing akan memberikan salinan kwitansi kepada

bagian accounting untuk dibukukan.

11. Setelah datang waktu kursus (jadwal) maka pengunjung akan berubah

menjadi seorang siswa. Dan selanjutnya proses belajar dan mengajar yang

akan dipandu oleh pengajar akan berjalan .

12. Setelah selesai proses belajar selesai, maka pengajar akan memberikan

sebuah proyek akhir sesuai dengan mata kursus yang diambil.

13. Apabila siswa sudah selesai menyelesaikan pembuatan proyek akhir, maka

siswa dapat mempresentasikan hasil proyek akhir. Dan proyek akhir

tersebut akan di nilai oleh bagian pengajar.

14. Apabila lulus, maka bagian sertifikat akan membuat dan mencetak

sertifikat serta memberikannya kepada siswa sebagai tanda bahwa proses

belajar dan mengajar telah selesai.

15. Apabila siswa belum lulus (masih banyak perbaikan dan perubahan), maka

dia harus memperbaiki terlebih dahulu proyek akhir miliknya tersebut.

Dan setelah selesai, siswa tersebut bisa mempresentasikan kembali ke

pengajar untuk dinilai.

22

Berikut adalah gambaran proses layanan akademik pada saat ini:

Gambar 3.8. Pelayanan Akademik saat ini

Dengan menggunakan sistem yang sudah ada sekarang, ditemukan beberapa

permasalahan sebagai berikut:

1. Data yang ada tidak terintegrasi dan tidak terkendali.

2. Lama waktu respon atas suatu permintaan, baik itu informasi kelas yang

sedang berjalan, kelas yang akan dibuka, lalu jumlah siswa dan pencetakan

sertifikat, sehingga menyebabkan Quality of Service menjadi rendah.

3. Kemungkinan terjadinya duplikasi data sangat besar karena masih

menggunakan pengolah kata dan data yang standard.

23

BAB IV

PEMODELAN PROSES BISNIS

SISTEM INFORMASI AKADEMIK ONLINE

Pemodelan proses bisnis ini dilakukan dengan menggambarkan rangkaian

proses bisnis ke dalam bentuk diagram aktivitas. Tujuan utama pemodelan bisnis ini

adalah untuk mengidentifikasi business worker, business worker operation dan

business entity. Dari pemodelan bisnis ini selanjutnya akan diturunkan menjadi

spesifikasi kebutuhan perangkat lunak SIAK online yang akan dijelaskan pada bab

selanjutnya. IV.1. Alasan Menggunakan Aplikasi Berbasis Web

Setelah melihat permasalahan yang ada di dalam sistem layanan akademik

Cambridge English Course dan juga melihat visi, misi dan strategi Cambridge

English Course yang akan memperluas jaringan dan tempat pelatihan IT ke

beberapa tempat yang lain sehingga dibutuhkan sebuah sistem yang akan

mengakomodir data yang terpusat maka dapat ditarik sebuah kesimpulan

bahwa dibutuhkan sebuah

sistem informasi yang mempunyai karakteristik, yaitu:

- terintegrasi

- dapat diakses kapan saja dan dimana saja.

- data yang terkini/up to date.

- sejalan dengan visi, misi serta strategi perusahaan.

- data terpusat

Sistem informasi yang mempunyai ciri - ciri sesuai dengan diatas adalah

sistem informasi yang berbasis web. Dimana dampak positif dari sistem

informasi berbasis web itu antara lain:

- meningkatkan waktu respon terhadap permintaan

- meningkatkan kualitas pelayanan.

- Sebagai media promosi untuk

- Sebagai salah satu alat bersaing

- Meningkatkan produktivitas pegawai.

24

Maka untuk itulah dirancang sebuah sistem informasi yang sesuai dengan

kebutuhan perusahaan yaitu sistem informasi akademik online.

IV.2. Business Worker, Business Worker Operation, dan Business Entity

Berdasarkan hasil analisa pada proses operasional seperti yang

dijelaskan dalam bagian sebelumnya, maka dapat disusun rincian lengkap

daftar business worker, business worker operation dan business entity.

Business worker dan business worker operation akan menjadi masukan untuk

melakukan identifikasi kebutuhan perangkat lunak yang akan dijelaskan di bab

5. Sedangkan business entity akan menjadi masukan untuk tahapan analisa dan

perancangan. Tahap analisa dan perancangan ini tidak akan dijelaskan dalam

proyek akhir ini karena di luar lingkup pengerjaan proyek akhir yang telah

ditetapkan. Berikut ini adalah daftar business worker, business worker

operation, dan business entity.

IV.2.1. Rincian Business Worker

Identifikasi business worker ini dimulai dengan mengevaluasi posisi

untuk mendapatkan peran spesifik yang dilakukan masing-masing

posisi yang ada. Selain itu diidentifikasi juga peran yang dilakukan

oleh sistem lain yang terhubung langsung dengan Sistem Informasi

Akademik online yang akan dikembangkan ini. Pada penjelasan

sebelumnya, business worker yang digambarkan dalam business

analysis model adalah business worker yang diidentifikasi dari

posisi. Tabel berikut menunjukkan daftar business worker yang

berhasil diidentifikasi pada tahap ini.

Tabel 4.1. Business Worker

No.

1

2

Business worker

Business Marketing

Business Pengajar

Peran

Berperan dalam melakukan registrasi dan menerima

pembayaran dari siswa.

Berperan dalam melakukan :

- kegiatan belajar mengajar

- memberikan tugas proyek akhir -

membimbing tugas proyek akhir

- menguji kelayakan proyek akhir yang dibuat

25

3 Business Berperan dalam membuat, mencetak dan memberikan Administrator sertifikat kepada siswa yang telah menyelesaikan kursus

dan telah lulus dari pengujian kelayakan proyek akhir

siswa.

IV.2.2. Rincian Business Worker Operation

Identifikasi business worker operation ini dilakukan dengan

menganalisa setiap aktivitas yang ada dalam setiap diagram aktivitas diatas dan

melengkapinya dengan melakukan identifikasi aktivitas untuk setiap business

worker yang ada. Tabel berikut menunjukkan daftar business worker operation

yang berhasil diidentifikasi dalam proses analisa kegiatan operasional harian

ini.

Tabel 4.2. Business Worker Operation

No.

1

2

3

4

Business Worker

Operation

Pendaftaran

Pengajaran

Pembuatan Proyek

Akhir

Sertifikat

Deskripsi

Melakukan kegiatan pendaftaran

siswa serta menerima pembayaran

biaya kursus

Melakukan kegiatan belajar dan

mengajar

Memberikan, membimbing serta

menguji proyek akhir

Membuat, mencetak dan

memberikan sertifikat kepada

siswa yang telah lulus kursus

Business worker

yang terlibat

Business Marketing

Business Pengajar

Business Pengajar

Business

Administrator

IV.2.3. Rincian Business Actor

Identifikasi business actor ini dilakukan dengan menganalisa setiap

entity (orang, sistem atau sesuatu) yang berinteraksi dengan bisnis. Tabel

berikut menunjukkan daftar business Actor yang berhasil diidentifikasi dalam

sistem layanan SIAK Online ini.

Tabel 4.3. Business Actor

No. Business Actor Peran

1 Siswa Berperan aktif terhadap sistem dalam melakukan

pendaftaran, pengajaran, pembuatan proyek akhir dan

sertiikat.

IV.2.4. Rincian Business Entity

Identifikasi business entity dilakukan dengan menganalisa setiap

aktivitas yang ada dalam diagram aktivitas di atas dan setiap business worker

26

operation yang ada. Tabel berikut menunjukkan daftar business entity yang

berhasil diidentifikasi dalam proses analisa kegiatan operasional harian ini.

Tabel 4.4. Business Entity

No Business Deskripsi Dimanipulasi Terlibat

Entity Oleh Dalam

1 Pendaftaran Meyimpan data-data tentang pendaftaran Marketing Pendaftaran siswa

IV.3. Object Modelling System

Selanjutnya untuk mendeskripsikan hubungan business actor, business

worker dan business entity pada aktifitas proses sistem SIAK Online di atas

akan digambarkan pada diagram business object model dan business analysis

model berikut ini :

Gambar 4.1. Business object model sistem SIAK Online

27

Gambar 4.1. Business analysis model sistem SIAK Online

28

BAB V

ANALISA KEBUTUHAN PERANGKAT LUNAK

Identifikasi kebutuhan lunak merupakan hal yang penting dalam

pengembangan perangkat lunak. Pada proyek akhir ini, identifikasi kebutuhan

dilakukan berdasarkan hasil pemodelan bisnis seperti yang telah dijelaskan pada bab

IV. Bab ini akan menjelaskan proses identifikasi kebutuhan perangkat lunak dan

hasilnya yang dituangkan dalam bentuk kebutuhan fungsional dan kebutuhan non

fungsional perangkat lunak.

V.1.

Metode Penyusunan Kebutuhan Perangkat Lunak

Kebutuhan perangkat lunak diturunkan dari model bisnis yang

dihasilkan dalam bab sebelumnya. Dalam mengidentifikasi kebutuhan

perangkat lunak ini penulis menggunakan acuan yang diberikan oleh RUP

seperti yang telah dijelaskan pada bagian III.3. Pemetaan model bisnis ke

model bisnis untuk menentukan kebutuhan perangkat lunak dapat dilihat

dalam tabel berikut 5.1.

Tabel 5.1 Pemetaan model bisnis ke model sistem

No Model Bisnis Model Sistem

1 Business use-case Subsistem

2 Business worker Actor

3 Business worker operation Use case

4 Business entity Class dalam analysis model,

Kebutuhan perangkat lunak yang dihasilkan akan dibagi menjadi dua

kelompok yaitu kebutuhan fungsional dan non-fungsional. Kebutuhan

perangkat lunak ini akan ditunagkan ke dalam dokumen software requirement

specification. Kebutuhan fungsional akan dimodelkan dalam bentuk diagram

use-case dan untuk setiap use-case yang ada akan dibuat spesifikasinya.

Sedangkan kebutuhan non fungsional akan dijelaskan dalam dokumen

supplementary specification.

29

V.2. V.3.

Pemetaan Dari Aktivitas Menjadi Use-Case

Langkah-langkah dilakukan pemetaan dari aktivitas menjadi use-case

adalah:

1. Mengidentifikasi aktivitas-aktivitas yang akan didukung oleh perangkat

lunak.

2. Mengorganisakan use-case dengan mengidentifikasi include dan extend

relationship serta generalisasi.

3. Memastikan bahwa use-case yang dihasilkan mudah dipahami dan

dipelihara. Kriteria RUP untuk memastikan hal ini adalah [SAN05]:

c. Setiap use-case tidak memiliki ketergantungan dengan use-case

lainnya.

d. Perubahan yang terjadi pada suatu use-case yang memiliki include use-

case tidak akan mempengaruhi include use-case tersebut, demikian

pula sebaliknya.

e. Beberapa use-case yang memiliki kesamaan pola kerja dan tujuan

sebaiknya digabungkan menjadi satu.

f. Use-case yang memiliki peluang untuk menjadi terlalu kompleks

sebaiknya dipisahkan menjadi beberapa use-case.

g. Setiap use-case yang harus memiliki nama yang unik, jelas, intuitive,

dan memiliki makna yang menjelaskan maksud use-case secara

keseluruhan.

Hasil pemetaan dari aktivitas menjadi use-case secara lengkap dapat dilihat

pada tabel berikut ini. Tabel ini menjelaskan nama use-case beserta penjelasan

aktivitas awal/business worker operation.

Identifikasi Actor

Identifikasi actor diturunkan dari business worker. Selain dari business

worker, ada satu aktor lagi yaitu mahasiswa. Business Siswa merupakan yang

secara langsung akan menggunakan sistem informasi sehingga diidentifikasi

sebagai kandidat system actor. Berikut ini daftar actor yang ada dalam aplikasi

SIAK online ini.

30

Tabel 5.2: Daftar Actor

No Nama Actor Deskripsi

1

2.

3

4

5

6

Pengunjung

Siswa Pengajar

Administrator

Marketing

General Manager

Aktor yang berperan dalam mengunjungi situs SIAK online dimana setelah dia mengakses SIAK online, dia dapat

mendaftarkan diri ke dalam situs ataupun kalau sudah terdaftar dia bisa

masuk ke dalam situs. Aktor yang berperan untuk ikut dalam suatu kursus. Actor yang berperan dalam memberikan status perubahan atas siswa apakah seorang siswa sudah lulus suatu kursus atau belum. Actor yang berperan dalam memelihara content, memelihara user, siswa dan pengajar. Actor yang berperan dalam memelihara content dan memberikan persetujuan kepada seorang calon siswa untuk ikut ke dalam suatu

mata kursus setelah membayar sejumlah biaya kursus. Actor yang berperan dalam melihat laporan siswa beserta grafik.

V.4. Kebutuhan Fungsional Perangkat Lunak

Identifikasi kebutuhan fungsional perangkat lunak ini diturunkan dari

business worker operation. Setelah dilakukan pemetaan awal yang

menghasilkan kandidat sistem use-case, langkah selanjutnya adalah

merestrukturisasi use-case tersebut sampai diperoleh model use-case yang

sesuai dengan kebutuhan stakeholder. Use-case yang dihasilkan dapat

digambarkan dalam diagram seperti yang ditunjukkan gambar 5.1. Tabel 5.3

menjelaskan rincian kebutuhan fungsional yang ada dalam gambar 5.1 tersebut

secara garis besar.

31

Gambar 5.1. Usecase SIAK online

Tabel 5.3: Kebutuhan Fungsional Perangkat Lunak

No Use-case Deskripsi Aktor

1 Login Aktifitas login dari pengguna untuk masuk ke dalam Pengunjung sistem

2

3

4

5

6

7

8

9

10

Register Browse Course View Promotion Administrasi Course Administrasi Pengajar

Administrasi Siswa

Administrasi User

Enroll Course

Enrollment Approval

Aktifitas mendaftarkan diri ke dalam sistem

Aktifitas melihat daftar kursus yang tersedia

Aktifitas melihat promosi yang ada. Aktifitas menambah, merubah dan menghapus course yang akan buka Aktifitas menambah, merubah, menghapus serta mengatur hak merubah status siswa dari setiap pengajar Aktifitas menambah, merubah siswa. setelah seorang yang terdaftar di dalam sistem SIAK menyerahkan biaya pendaftaran ke bagian sales &

marketing. Aktifitas menambah, merubah dan menghapus user (baik itu General Manager, Marketing, ataupun Administrator) Aktifitas mendaftarkan diri (siswa) ke dalam suatu kursus Aktifitas menyetujui bahwa seorang siswa boleh ikut dalam suatu kelas apabila dia sudah

Pengunjung

Pengunjung

Pengunjung Administrator

Administrator

Administrator

Administrator

Siswa

Marketing

32

No Use-case Deskripsi Aktor menyerahkan sejumlah biaya kursus

11 Input FeedBack Aktifitas memasukkan komentar, kritik dan saran Siswa atas penyelenggaraan pelatihan baik kepada instansi,

pengajar ataupun staf.

12

13

14 15

16

17

18

19

20

Print Certificate

View Berita View FeedBack View Grafik

View Jadwal View Rencana Kelas

View Running Class

View Siswa

Change Status Siswa

Aktifitas mencetak sertifikat kursus sebagai tanda berakhirnya proses kegiatan belajar mengajar atas suatu mata pelajaran kursus, dimana kegiatan ini di awali dengan pengecekan status seorang siswa sudah lulus untuk suatau mata kursus atau belum. Aktifitas melihat berita terbaru Aktifitas melihat komentar, kritik dan saran yang telah di masukkan/dikirimkan oleh siswa Aktifitas melihat grafik/statistik kursus Aktifitas melihat jadwal kursus Aktifitas melihat rencana kelas yang akan dibuka

Aktifitas melihat kelas yang sedang berjalan pada bulan yang bersangkutan Aktifitas melihat siswa untuk suatu mata kursus tertentu Aktifitas merubah status siswa dari belum lulus menjadi lulus untuk sebuah mata kursus

Administrator

Siswa General Manager General Manager Siswa

Siswa General Manager

General Manager

Pengajar

Gambar 5.2 Class Diagram Sistem Informasi Akademik Online

33

V.5. Kebutuhan Non-Fungsional Perangkat Lunak

Identifikasi kebutuhan non-fungsional diturunkan dari kebutuhan

stakeholder yang tidak dapat dimodelkan dengan use-case. Kebutuhan non

fungsional ini dikelompokkan menjadi usability, reliability, performance, dan

supportability. Daftar kebutuhan non-fungsional ini dapat dilihat dalam

dokumen supplementary specification. Beberapa contoh kebutuhan non-

fungsional pada sistem SIAK Online adalah:

Meminimalisasi terjadinya kesalahan pencatatan data

Mencegah terjadinya penyimpanan data yang redundant

Mudah digunakan

Toleransi terhadap anggaran biaya sekitar 5 persen

Pencarian data tidak boleh lebih dari 10 detik

Total sistem breakdown 0 persen pada server agar seluruh transaksi

dapat diselesaikan(bukan disebabkan oleh force majeure)

Mudah digunakan

Hak akses pengguna harus didefinisikan dengan jelas

Response time terhadap transaksi yang dilakukan dibawah 4 menit

Dapat melayani 300 pelanggan sekaligus secara bersamaan online

Permasalahan dalam sistem harus dapat ditangani dalam waktu paling

lama 1 x 24 jam

Sistem Mampu Beroperasi selama 24 jam selama hari kerja

34

BAB VI

IMPLEMENTASI RUP

VI.1. Workflow

Dalam bab ini penulis akan membahas tentang adaptasi metodologi

RUP dalam penyelesaian proyek akhir ini. Penulis mengacu pada RUP versi

2003.06.12.01. Langkah-langkah penyelesaian proyek akhir ini disusun

berdasarkan panduan yang diberikan RUP khususnya dalam disiplin business

modeling dan requirement. Tidak semua aktivitas dalam metologi RUP

dilakukan dan tidak semua artifactnya dibuat dalam proyek akhir ini.

Penyesuaian aktivitas dan artifact ini dilakukan agar penerapan RUP dalam

proyek ini menjadi lebih sederhana dan spesifik sesuai dengan karakter proyek

yang penulis kerjakan.

Beberapa hal yang menjadi pertimbangan penulis dalam melakukan

penyesuaian metodologi RUP adalah:

Proyek akhir ini dilakukan untuk menentukan spesifikasi dan prasyarat

perangkat lunak sistem SIAK Online yang disesuaikan dengan

kebutuhan stakeholder.

Aplikasi ini dibuat untuk mengotomasi layanan akademik antara pihak

penyelenggara pelatihan dan siswa ke sistem berbasis web (online) agar

diperoleh mekanisme layanan yang efektif dan efisien serta yang

terpenting adalah customer satisfaction.

Proses bisnis yang menjadi sentral permasalahan bukan merupakan

bisnis baru melainkan perubahan dari bisnis (proses operasional) yang

ada yang semula dijalankan secara manual oleh bagian Sales &

Marketing dan Administrator.

Perangkat lunak ini hanya akan digunakan dalam lingkungan internal

Cambridge English Course dan tidak dipasarkan kepada pihak ketiga.

Jumlah tim pengembang yang terlibat dalam proyek ini sangat kecil.

Berdasarkan pertimbangan di atas dan konsultasi dengan pembimbing,

maka proyek ini hanya akan menekankan dalam dua disiplin utama, yaitu

35

business modeling dan requirement serta dua fase yaitu inception dan

elaboration. Bagian yang ditandai dengan elips pada gambar 6.1 menunjukkan

tahapan yang akan dilakukan dalam proyek ini:

Gambar 6.1: Fokus Pelaksanaan Proyek [RUP03]

Karena implementasi RUP dalam proyek ini bersifat custumization,

maka aktivitas-aktivitas yang ada dalam business modeling tidak akan

dilakukan semua. Gambar 6.2 menunjukkan aktivitas apa saja yang penulis

lakukan dalam disiplin business modeling.

Berdasarkan landasan teori di bab 3, skenario pemodelan bisnis yang

sesuai dengan proyek ini adalah skenario 6 (revamp). Dengan berpedoman

pada karakteristik proyek dan skenario business modelling yang digunakan

maka workflow detail develop a domain model tidak perlu dilakukan.

Workflow business yang akan dilakukan diperlihatkan seperti yang ditunjukan

dalam gambar berikut:

36

Gambar 6.2: Workflow Business modeling Yang Dilakukan

Requiremet workflow mengikuti workflow yang telah ditetapkan dan

tidak ada workflow detail yang tidak dilakukan, hanya saja titik berat workflow

detail yang dilakukan tidak sama antara fase inception dan fase elaboration.

Fase inception dititikberatkan untuk memahami masalah/problem domain

sehingga workflow detail yang dilakukan adalah 'Analyze The Problem' dan

'Understand The Stakeholder Needs' untuk menghasilkan system vision

document. Requirement workflow pada fase inception adalah sebagai berikut:

37

Gambar 6.3: Requirement Workflow pada Fase Inception

Sedangkan pada fase elaboration titik beratnya adalah pembuatan

software requirement specification sesuai dengan proses bisnis yang menjadi

fokus iterasi yang sedang berjalan. Untuk setiap iterasi akan dilakukan analisa

kebutuhan sistem dan stakeholder, pendefinisian kebutuhan perangkat lunak

dan bagaimana mengelola kebutuhan tersebut dengan baik. Gambar di bawah

ini menunjukkan requirement workflow dilakukan dalam tahap elaboration:

38

Gambar 6.4: Requirement Workflow pada Fase Elaboration

Setelah menentukan pemilihan model dan workflow detail yang akan

dilalui dalam setiap disiplin yang dipilih, langkah selanjutnya adalah

menentukan aktivitas-aktivitas yang lebih rinci dalam fase inception dan

elaboration. Penentuan aktivitas ini didasarkan pada workflow detail yang

dipilih untuk setiap disiplin yang dilakukan. Penjelasan rinci tentang aktivitas

dalam setiap fase akan dijelaskan dalam sub bab berikut.

VI.2. Fase Inception

Berdasarkan workflow detail yang akan dilakukan, maka penulis

menyusun rincian aktivitas apa saja yang akan dilakukan dalam fase inception

berdasarkan workflow detail tersebut. Bagian ini akan menjelaskan tentang

rincian langkah-langkah yang akan dilakukan dalam fase inception.

39

VI.2.1. Mendefinisikan model bisnis dan vision

Tahap ini bertujuan untuk menyusun vision dan model bisnis

dari permasalahan yang ada sehingga diperoleh informasi yang cukup

tentang status bisnis yang ada dan stakeholder terkait. Hasil dari tahap

ini akan digunakan untuk menyusun dokumen vision sistem.

Langkah-langkah dalam pendefinisian model bisnis dan vision

sebagai berikut:

2. Set and adjust goals -business modeling discipline

Aktivitas ini bertujuan untuk menentukan target yang ingin dicapai

dari proyek ini, batasan dari kegiatan dan upaya yang dilakukan

selama business modeling serta menjelaskan target yang

diharapkan dan stakeholder system.

Langkah-langkah yang dilakukan dalam aktivitas ini adalah:

• Mendefinisikan batasan target organisasi

Dilakukan dengan membuat asumsi-asumsi mengenai target

yang dimiliki oleh Universitas. Hasil dari aktivitas ini akan

dimasukkan dalam dokumen vision bagian positioning.

• Mengidentifikasi stakeholder

Hal ini dilakukan dengan mengumpulkan informasi dari

dokumen terkait dan melakukan wawancara langsung pada

pengguna utama. Dari aktivitas ini akan dihasilkan profil

stakeholder dan customer beserta kebtuhannya. Hasilnya akan

menjadi bagian dari stakeholder and customer description

dalam dokumen vision.

• Mengidentifikasi batasan yang dapat menghambat pelaksanaan

Beberapa faktor yang dapat menghambat pelaksanaan proyek

adalah politik, ekonomi, lingkungan, teknis, kelayakan, dan

sistem lainnya yang berinteraksi dengan sistem yang akan

dikembangkan. Proyek ini hanya menganalisa faktor-faktor

yang mempengaruhi kondisi serta lingkungan pengguna atau

sistem yang akan menjadi bagian stakeholder and customer

description dalam vision. Faktor yang mempengaruhi pasar

tidak akan dievaluasi karena produk ini dikembangkan dan

40

digunakan hanya untuk lingkungan Cambridge English Course dan tidak

dipasarkan kepada pihak ketiga.

• Mengidentifikasi masalah yang dihadapi

Tujuan aktivitas ini adalah untuk mengetahui masalah-masalah

yang mungkin dihadapi oleh calon pengguna dan akan

dicarikan pemecahannya dengan membangun aplikasi ini. Hasil

dari aktivitas ini akan dituangkan dalam bagian problem

statement dalam dokumen vision.

• Menentukan prioritas dari proses bisnis yang akan diotomasi

Dalam aktivitas ini akan ditentukan prioritas proses operasional

layanan akademik yang akan diotomasi serta prioritas

pengembangannya. Hasilnya akan dimasukkan dalam bagian

precedence and priority dalam vision.

Role: business process analyst

Artifact: draft awal vision

3. Maintain business rule - disiplin business modeling

Business rule adalah penjelasan tentang kebijakan atau kondisi

yang harus dipenuhi oleh bisnis. Tujuan aktivitas ini adalah:

• Menentukan business rule yang mempengaruhi proyek

• Mendefinisikan business rule dengan lebih detil

Role: business process analyst

Artifact: hasil dari aktivitas ini adalah dokmen business rule yang

akan digunakan sebagai dasar penyusunan dokumen spefisikasi

perangkat lunak, spesifikasi use-case, supplementary specification,

dan alur algoritma dalam tahapan perancangan.

4. Capture common business vocabulary - disiplin business modeling

Tujuan aktivitas ini adalah untuk mendefinisikan kosakata umum

yang digunakan dalam pengembangan sistem SIAK Online ini,

baik yang merupakan istilah bisnis maupun istilah teknis. Hal ini

membantu konsistensi penggunaan istilah dan menghindari

terjadinya salah persepsi mengenai suatu istilah tertentu. Pencarian

41

kosakata ini dilakukan dengan studi literatur khususnya dalam

dokumen spesifikasi bisnis.

Referensi: dokumen spesifikasi bisnis analisa aktivitas

Role: business process analyst

Artifact: dalam proyek akhir ini semua istilah dan kosa kata

dirangkum dalam dokumen glossary.

5. Develop requirement management plan - disiplin requirement

Aktivitas ini dilakukan dengan tujuan untuk:

• Membuat rencana untuk mendokumentasikan atribut

requirement dan pedoman penelusuran (traceability)

requirement.

• Mengelola requirement produk yang akan dikembangkan.

Sedangkan langkah-langkah yang dilakukan dalam penyusunan

requirement management plan ini adalah:

• Membangun traceability

• Menenukan atribut-atribut requirement

• Mempersiapkan tools yang akan digunakan untuk mengelola

requirement

Role: System analyst

Artifact: dokumen requirement management plan

6. Elicit stakeholder request - disiplin requirement

Identifikasi stakeholder request dalam proyek ini dilakukan dengan

menentukan sumber-sumber kebutuhan dan prioritasnya dan

kemudian melakukan pengumpulan informasi melalui wawancara

terhadap terkait. Pada dasarnya aktivitas ini dilakukan dengan

tujuan untuk:

• Memahami siapa stakeholder proyek •

Mengidentifikasi stakeholder sistem

• Mendefinisikan batasan sistem

• Menggambarkan fitur-fitur utama yang dimiliki oleh sistem.

Role: system analyst

42

Artifact: hasil identifikasi stakeholder request dan prioritasnya

akan disajikan dalam dokumen stakeholder request.

7. Develop vision - disiplin requirement

Dalam aktivitas ini dilakukan penyusunan dokumen vision sesuai

dengan template yang diberikan oleh RUP. Input dokumen vision

ini diperoleh dari langkah-langkah sebelumnya khususnya

langakah 'set and adjust ojective'. Tujuan dari penyusunan

dokumen ini adalah:

• menyamakan persepsi tentang permasalahan yang dihadapi

• mengidentifikasi stakeholder sistem

• mendefinisikan batasan sistem

• menggambarkan fitur-fitur utama yang dimiliki oleh sistem

Role: system analyst

Artifact: hasil aktivitas ini adalah dokumen vision

VI.2.2. Mendefinisikan fungsi sistem

Setelah mendapakan gambaran tentang deskripsi, sasaran,

batasan proyek, serta stakeholder request, langkah selanjutnya adalah

mendapatkan gambaran tentang fungsi perangkat lunak yang akan

dibangun. Pada tahap ini akan dilakukan pemodelan business worker

dan entity. Selanjutnya disusun requirement management plan.

Langkah terakhir adalah menentukan actor dan use-case dalam sistem

berdasarkan business worker dan activity diagram yang telah

dikembangkan sebelumnya. Gambar 6.5 menunjukkan aktivitas dan

artifact yang dihasilkan dalam tahap ini. Bagian berikutnya akan

menjelaskan aktivitas-aktivitas dalam gambar tersebut satu demi satu.

43

Gambar 6.5: Langkah-langkah Dalam Pendefinisian Fungsi Sistem [RUP03]

Aktivitas-aktivitas yang ada dalam gambar 5.6 di atas dapat

dijelaskan sebagai berikut:

1. Find business actors and usecase - business modeling discipline

Tujuan dari aktifitas ini untuk memberikan gambaran umum

mengenai proses bisnis dan memodelkannya ke dalam diagram

business usecase model.

Langkah-langkah yang dilakukan dalam aktifitas ini adalah :

• Find business actors, dilakukan dengan mengidentifikasi pihak-

pihak yang akan berinteraksi dengan layanan SIAK Online

• Find business usecases, dilakukan dengan mengidentifikasi

proses-proses yang dilakukan dalam bisnis dan layanan yang

diharapkan dari system SIAK Online

• Membuat prioritas utama terhadap proses bisnis yang terdapat

dalam layanan SIAK online yang telah diidentifikasi

• Membuat alur kerja yang terdapat dalam setiap business

usecase

Role : business process analyst

Artifact : business actor, business usecase model,business

usecase, dan apabila ditemukan business rule yang

baru maka dimasukkan ke dalam dokum supplementary

specification.

44

2. Find business workers and entities - disiplin business modeling

Aktivitas ini dilakukan untuk mengidentifikasi semua peran,

serahan, dan event dalam bisnis dan menggambarkan bagaimana

business worker dan entity membentuk use-case realization. Hal

ini akan digambarkan dalam activity diagram dalam business

object model. Untuk setiap business worker diidentifikasi pada use-

case apa dia terlibat.

Langkah-langkah yang dilakukan dalam melakukan aktivitas ini

adalah:

• Mengidentifikasi business worker dengan mengidentifikasi

semua peran yang terlibat dalam alur kerja.

• Mengidentifikasi business entity dilakukan dengan memeriksa

hal-hal yang dihasilkan atau digunakan business worker dalam

melaksanakan perannya.

• Untuk setiap business worker yang ada diidentifikasi apa yang

dilakukannya dalam melaksanakan perannya. Hal ini akan

membentuk business use-case.

• Membuat use-case realization dengan nama yang sama untuk

setiap business use-case. Business use-case realization ini

dibuat dalam bentuk activity diagram berdasarkan alur kerja

yang telah dijabarkan pada aktvitas sebelumnya. Activity

diagram yang dibuat akan dijelasakan pada bab 5.

Role: business designer

Artifact: business analysis model/business object model (business

entity only), business entity, business worker, business use-case

(outline), business use-case realization (activity diagram)

3. Find actors and usecase - requirement discipline

Tujuan dari activity ini dalam inception phase adalah membangun

gambaran umum mengenai kebutuhan perangkat lunak. Penjelasan

detail mengenai activity ini dapat dilihat pada bab V proyek akhir

45

ini yang menjelaskan bagaimana mengubah business object model

menjadi kebutuhan perangkat lunak.

Role : system analyst

Artifact : Actors, usecase, usecase model (outlined)

VI.2.3. Kategori Kebutuhan

Dari fase inception diperoleh gambaran apa yang akan dalam

perangkat lunak Analisa Aktivitas ini beserta prioritas

pengembangannya. Selain itu ditentukan pula deskripsi, tujuan, dan

batasan proyek yang dituangkan dalam dokumen vision. Fungsionalitas

yang akan dikembangkan dalam proyek ini dibuat dalam bentuk use-

case model yang menggambarkan requirement yang harus dipenuhi

oleh perangkat lunak ini.

Berdasarkan prioritas fungsi yang harus ada dalam perangkat

lunak SIAK online, maka requirement perangkat lunak SIAK online

ini dibagi menjadi dua kategori (dari prioritas tertinggi ke prioritas

terendah), yaitu:

1. Kategori 1: requirement yang mendukung proses layanan

pendaftaran, pengajaran, status proyek akhir dan pembuatan

sertifikat.

2. Kategori 2: requirement yang mendukung proses layanan SIAK,

reporting serta melengkapi sistem SIAK Online yang akan

dikembangkan.

VI.3. Fase Elaboration

Pada fase elaboration ini, pengerjaan proyek dititikberatkan pada

pengelolaan requirement perangkat lunak yang telah diidentifikasi.

Pendefinisian rincian kebutuhan dilakukan secara bertahap sesuai dengan

prioritas yang telah ditetapkan. Bagian ini akan menjelaskan tentang

pembagian iterasi yang dilakukan dalam pengerjaan proyek di fase

elaboration dan langkah-langkah yang dilakukan dalam setiap iterasi.

46

VI.3.1. Penentuan Iterasi

Pembagian iterasi dilakukan berdasarkan prioritas requirement yang

mendukung suatu proses bisnis. Karena ada dua kategori requirement yang

akan dikembangkan maka ada dua iterasi yang dilakukan. Kedua iterasi yang

akan dilakukan adalah:

1. Iterasi 1: modul pendaftaran, pengajaran, status proyek akhir siswa dan

cetak sertifikat

Iterasi ini menitikberatkan pada requirement perangkat lunak yang

termasuk pada kategori 1. Di akhir iterasi ini diharapkan spesifikasi

kebutuhan yang termasuk kategori satu sudah diidentifikasi dengan jelas

disertai dokumen spesifikasi setiap use-case yang terlibat. Selanjutnya

requirement yang dihasilkan akan dievaluasi apakah sudah sesuai dengan

kebutuhan stakeholder atau tidak. Hasil evaluasi digunakan untuk

menetukan fokus iterasi selanjutnya. Jika hasil evauasi menunjukkan

bahwa requirement yang dihasilkan masih terdapat kekurangan maka

iterasi kedua akan tetap mengidentifikasi requirement kategori satu dengan

area yang lebih spesifik sesuai dengan kekurangan yang ditemukan.

2. Iterasi 2: modul cetak laporan, grafik, jadwal dan content

Fokus iterasi ini adalah pendefinisian requirement kategori dua. Pada

iterasi ini pengembangan sistem SIAK online akan dilengkapi sampai jadi

seutuhnya. Jika hasil evaluasi terhadap hasil iterasi ini kurang lengkap

maka iterasi selanjutnya akan fokus pada requirement dan proses bisnis

kategori 2.

Penjelasan tentang aktivitas-aktivitas yang dilakukan dalam setiap iterasi akan

dijelaskan pada bagian berikut ini.

VI.3.2. Melengkapi Model Bisnis

Pada bagian ini akan dilakukan serangkaian aktivitas untuk melengkapi

model bisnis yang sudah dibuat dalam fase sebelumnya. Proses bisnis yang

menjadi fokus tergantung pada titik berat setiap iterasi yang sedang dilakukan.

Aktifitas-aktifitas yang dilakukan adalah :

47

1. Detail business use case - business modeling discipline

Focus dari aktifitas ini adalah mendetailkan alur kerja dalam setiap usecase

termasuk didalamnya alternate flow maupun sub flow. Langkah - langkah

yang dilakukan dalam aktifitas ini adalah :

• Memberikan keterangan lebih detail mengenai alur kerja yang terdapat

dalam business use case.

• Melakukan strukturisasi alur kerja yang telah diidentifikasi ke dalam

sub workflow atau optional workflow

• Mendeskripsikan special requirement dari suatu business use case

Role

Artifact

: business designer

: business usecase yang telah dilengkapi dengan alternate

flow dan subflow. Apabila ditemukan business rule yang baru

maka dimasukkan ke dalam daftar dokumen supplementary

specification.

2. Find business workers and entities - disiplin business modeling

Tujuan aktivitas ini adalah melengkapi object model yang dikembangkan

dalam fase/iterasi sebelumnya sesuai dengan proses bisnis yang menjadi

fokus iterasi yang sedang berjalan. Langkah-langkah yang dilakukan

dalam aktivitas ini adalah:

• Mereview business object model sebelumnya.

• Mengidentifikasi business worker dengan mengidentifikasi semua

peran yang terlibat dalam alur kerja dan business use-case yang telah

diidentifikasi pada fase sebelumnya.

• Untuk setiap business worker tentukan dalam business use-case apa

dia terlibat.

• Mengidentifikasi business entity dengan memeriksa hal-hal yang

dihasilkan atau digunakan oleh business worker dalam melaksanakan

perannya berdasarkan business use-case yang telah didapat

sebelumnya.

• Membuat use-case realization untuk setiap business use-case. Business

use-case realization ini dibuat dengan nama yang sama dengan

business use-casenya.

48

• Melakukan strukturisasi business object model

Role: business designer

Artifact: business worker, business entitiy, business use-case, business

use-case realization (activity diagram)

3. Define automation requirements - business modeling discipline

Tujuan dari aktifitas ini adalah mengidentifikasi bagian-bagian dari proses

bisnis yang dapat diotomasi dengan bantuan system. Hasil tersebut

kemudian dituangkan dalam diagram system usecase untuk menambahkan

system usecase yang telah dikembangkan pada phase sebelumnya.

Langkah-langkah yang dilakukan dalam aktifitas ini adalah :

• Explore new technologies dilakukan untuk membangun pemahaman

yang baik mengenai teknologi-teknologi yang mungkin untuk

dimanfaatkan dalam pengembangan system

• Identify system actor and usecase

Secara detail teknik yang digunakan untuk mengidentifikasi system

actor dan usecase dapat dilihat dalam bab analisa kebutuhan pada

laporan proyek akhir ini.

Role : business designer

Artifact : system usecase

4. Detail a business entity - disiplin business modeling

Tujuan aktivitas ini adalah untuk memastikan bahwa business entity dapat

menyediakan behavior yang dibutuhkan dan mengevaluasi hubungan

struktural antar business entity. Langkah-langkah yang dilakukan dalam

aktivitas ini adalah:

• Menentukan area responsibility

• Mendefinisikan operasi yang dikenakan terhadap business entity yang

bersangkutan

• Mendefinisikan attribut setiap business entity

• Menganalisa hubungan antar business entity yang ada

Role: business designer

Artifact: business entity dengan attributnya dan business event

49

5. Melengkapi glossary, business rule, dan vision

Selama melakukan aktivitas pendefinisian business worker dan business

entity, aktivitas lain yang harus dilakukan adalah melengkapi glossary

dengan istilah-istilah bisnis dan teknir, mereview business rule, dan

memperbaiki dokumen vision. Dokumen vision yang dihasilkan dalam

tahap ini lebih lengkap dan disertai dengan dokumen supplementary

specification.

VI.3.3. Mengelola Perubahan Kebutuhan

Dalam proses pengembangan perangkat lunak biasanya akan terjadi

perubahan atau penentuan prioritas kebutuhan, baik yang datang dari user

maupun dari stakeholder yang lain. Perubahan tersebut bisa berupa

penambahan kebutuhan baru, pengubahan ataupun membuang kebutuhan yang

telah diidentifikasi sebelumnya. Agar semua perubahan yang ada tetap tercatat

dengan baik dan semua pihak dapat mengetahui status pengembangan terbaru,

maka perubahan tersebut harus dikelola dengan baik. RUP memberikan

panduan bagaimana mengelola perubahan kebutuhan. Dalam proyek ini

aktivitas tersebut akan disesuaikan dengan ruang lingkup proyek. Berikut ini

langkah-langkah yang dilakukan dalam mengelola kebutuhan perangkat lunak:

1. Manage dependencies - disiplin requirement

Setiap penambahan ataupun perubahan pada suatu requirement perlu

ditelusuri apa penyebab perubahan tersebut dan apa akibat yang

ditimbulkannya serta siapa yang meminta perubahan tersebut. Dalam

proyek akhir ini, tools yang digunakan oleh penulis dalam mengelola

perubahan dan ketergantungannya adalah Rational RequisitePro.

Perubahan akan diimplementasikan jika sudah disetujui oleh project

sponsor. Dampak penambahan dan perubahan terhadap requirement

perangkat lunak dapat mempengaruhi attribut dan traceability dari

requirement yang bersangkutan. Selain itu perubahan dapat juga

mempengaruhi artifact yang ada misalnya vision, use-case model, use-case

specification, dan software requirement specification.

Langkah-langkah yag dilakukan dalam aktivitas ini adalah:

• Menentukan attribut requirement yang berubah

50

• Membuat dan memeriksa traceability akibat perubahan yang terjadi

• Mengelola perubahan requirement dengan mengupdate dokumen

terkait dan membuat traceability matrix yang up-to-date

Role: system analyst

Artifact: requirement attribute dan dokumen lain yang terpengaruh

perubahan tersebut

2. Structure the use-case model - disiplin requirement

Perubahan requirement dapat menyebabkan perubahan struktur use-case

model yang telah dibuat. Karena itu perlu dilakukan strukturisasi use-case

yang ada. Langkah-langkah untuk melakukan strukturisasi use-case

adalah:

• Mengidentifikasi requirement umum.

• Membuat include relationship, extend relationship, dan generalization

antara use-case yang ada.

Role: system analyst

Artifact: use-case model (restructure)

3. Prioritize use-case - disiplin requirement

Perubahan requirement juga dapat menyebabkan berubahnya prioritas

suatu use-case yang menjelaskan tentang requirement tersebut. Untuk itu

perlu dilakukan prioritasi use-case yang ada terkait dengan perubahan

yang dilakukan. Aktivitas ini dapat dilakukan dengan langkah-langkah

sebagai berikut:

• Menentukan prioritas use-case dan skenario

• Mendokumentasikan use-case view

Role: software architect

Artifact: requirement attribute

Gambar 6.6 menunjukkan urutan aktivitas yang dilakukan dalam

mengelola perubahan kebutuhan seperti yang telah dijelaskan di atas.

51

Gambar 6.6: Langkah-langkah Dalam Mengelola Perubahan Kebutuhan [RUP03]

VI.3.4. Membuat Rincian Kebutuhan Perangkat Lunak

Kebutuhan fungsional perangkat lunak didefinisikan dalam dokumen

use-case specification. Sedangkan kebutuhan non-fungsional

didokumentasikan dalam supplementary specification. Aktivitas-aktivitas yang

perlu dilakukan untuk melengkapi detil kebutuhan perangkat lunak sebagai

berikut

1. Detail a use-case - disiplin requirement

Dalam membuat detil suatu use-case, hal utama yang harus dibuat adalah

basic flow yang menggambarkan primary scenario dan alternate flow yang

menggambarkan secondary scenario. Basic flow disusun berdasarkan

sudut pandang actor dan ditulis untuk urutan kegitan yang normal dan

tanpa masalah. Dalam basic flow ini setidaknya menjelaskan bagaimana

suatu use-case dimulai dan berakhir dan menjelaskan pertukaran data yang

terjadi antara actor dan sistem.

52

Selain basic flow, diidentifikasi juga alternate flow dan kemungkinan

terjadinya kesalahan dalam suatu use-case. Hal ini dapat dilakukan dengan

memeriksa setiap event dari basic flow dengan menjawab pertanyaan

apakah kemungkinan kesalahan yang dapat terjadi atau apakah ada action

lain yang mungkin dilakukan oleh actor. Setelah kemungkinan alternate

flow diidentifikasi maka setiap alternate flow tersebut diberi nama dan

penjelasan lengkap mengenai detil event dan langkah-langkah yang terjadi

dari awal hingga akhir.

Jadi aktivitas ini bertujuan untuk menggambarkan satu atau lebih flow of

event dari suatu use-case dengan cukup detil sebagai dasar pengembangan

perangkat lunak. Sedangkan langkah-langkah yang dapat dilakukan

adalah:

• Mereview dan memperbaiki skenario (optional)

• Membuat detil flow of event

• Melakukan strukturisasi flow of event

• Menggambarkan hubungannya dengan actor dan use-case lain

• Mendefinisikan kebutuhan khusus

• Mendefinisikan pre condition (optional)

• Mendefinisikan post condition (optional)

• Mendefinisikan extention point (jika ada)

Role: requirement specifier

Artifact: use-case specification untuk setiap use-case, supplementary

specification

2. Detail a software requirements - disiplin requirement

Aktivitas ini bertujuan untuk mengumpulkan dan mengorganisasikan

sekumpulan artifact yang menggambarkan kebutuhan perangkat lunak

suatu sistem atau sub sistem dengan lengkap. Adapun langkah-langkah

yang dilakukan adalah:

• Membuat detil kebutuhan perangkat lunak dengan melengkapi

supplementary specification dan membuat software requirement

specification (SRS)

53

• Membuat laporan pendukung misalnya traceability matrix dan

requirement attribute

Role: requirements specifier

Artifact: software requirement specification, supplementary spesification

3. Review requirement - disiplin requirement

Fokus kegiatan ini adalah memastikan semua kebutuhan fungsional telah

didefinisikan dan memastikan semua dokumen use-case, SRS, dan

supplementary specification yang dihasilkan pada iterasi yang

bersangkutan telah terdokumentasi dengan baik dan benar berdasarkan

check points yang diberikan oleh RUP. Hasil review ini digunakan sebagai

dasar untuk menentukan fokus iterasi selanjutnya. Apabila hasil review

menyatakan masih ada kekurangan, maka perlu dilakukan pengulangan

iterasi dengan fokus proses bisnis atau requirement yang lebih spesifik

sesuai dengan hasil review.

Role: technical reviewer

Artifact: review record

Gambar 6.7 menunjukkan rangkaian aktivitas yang dilakukan untuk

membuat detil kebutuhan perangkat lunak dalam fase elaboration.

54

Gambar 6.7: Langkah-langkah Dalam Membuat Detil Kebutuhan Perangkat

Lunak [RUP03]

55

BAB VII

KESIMPULAN DAN SARAN

VII.1. Kesimpulan

Setelah melakukan pengembangan aplikasi Sistem Informasi

Akademik Online dengan menggunakan RUP dalam proyek akhir ini ada

beberapa kesimpulan yang dapat diambil, yaitu:

1. Ditemukan beberapa kendala dalam proses penggunaan metodologi RUP

ini, seperti :

• Banyak dokumen - dokumen yang harus dilengkapi

• Menentukan skenario business modellingnya terkait dengan scope

sistem

• Untuk requirement, elicitation requirement itu harus jeli

• Membagi aktifitas - aktifitas menjadi beberapa iterasi.

2. Diperlukan pemahaman yang baik tentang metodologi RUP baik

aktivitas-aktivitas dalam suatu workflow ataupun isi dari setiap artifact

yang seharusnya dibuat agar proses penyederhaan dan adaptasi RUP

menjadi lebih mudah.

3. Adaptasi dan penyederhanaan aktivitas-aktivitas pengembangan

perangkat lunak yang diberikan oleh RUP sebaiknya dilakukan pada

awal dimulainya proyek tersebut. Hal ini bertujuan agar proses dan

tahapan pengembangan menjadi lebih sederhana dan lebih spesifik

sesuai dengan karakter dari proyek tersebut.

4. Requirement perangkat lunak dapat diturunkan dari model bisnis yang

diperoleh dari disiplin business modeling. Dalam konteks domain

modeling, RUP kurang memberikan panduan untuk menurunkan model

bisnis menjadi requirement karena penekanan domain modeling adalah

pemodelan business worker dan business entity dan tidak ada aktivitas

untuk mengidentifikasi business actor dan business use-case. Pada

proyek akhir ini, untuk mendapat requirement yang dituangkan dalam

bentuk use-case model, penulis melakukan pendekatan dengan

mengidentifikasi business worker operation untuk setiap business

56

worker yang terlibat. Hal ini akan digunakan sebagai kandidat use-case

dalam pemodelan sistem.

5. Untuk dapat mengimplementasikan model bisnis yang dihasilkan dalam

proyek akhir ini harus dilakukan beberapa tahap yang merupakan

tahapan lanjutan dalam RUP sehingga akan mendapatkan gambaran

lengkap mengenai rancangan sistem secara keseluruhan.

VII.2.

Saran

Saran - saran dari penulis adalah:

1. Pelaksanaan disiplin analisa dan perancangan sebaiknya menggunakan

business analysis model yang telah dihasilkan dalam proyek ini karena

penekanan domain modeling akan banyak membantu dalam identifikasi

class dalam disiplin ini.

2. Diharapkan hasil yang diperoleh dari proyek akhir ini dapat menjadi

dasar dalam pengembangan Sistem Informasi Akademik selanjutnya.

57

DAFTAR PUSTAKA

[BOO99]

[CYB00]

[CRA02]

[LEF03]

[OBE02]

[RUP03]

[SAN05]

Booch, G., Rumbaugh, J., dan Jacobson, I. 1999. Unified Modelling

Language - User's Guide. Addision Wesley.

Cyber Campus, Company Profile. 2000.

Larman, Craig. 2002. Applying UML and Patterns, 2nd Edition.

Prentice Hall.

Leffingwell, Dean dan Don, Widrig. 2003. Managing Software

Requirement: A Use Case Approach, 2nd Edition ion. Boston:Addision

Wesley.

Oberg, R., Probasco, L., dan Ericsson, M. 2002. Applying

Requirements Management with Use Cases. Rational Software White

Paper.

Rational Unified Process version 2003..

Sandhiyadnya, I.N. 2005. Penerapan Metodologi Rational Unified

Process Dalam Menentukan Spesifikasi dan Prasyarat Perangkat Lunak

Pendukung Operasional Help Desk Yang Sesuai Dengan Microsoft

Operational Framework, Proyek Akhir Kekhususan Teknologi

Informasi, Program Magister Ilmu Komputer, Fakultas Ilmu

Komputer, Universitas Indonesia. Jakarta.

58