PSI LAPAN

UNIVERSITAS INDONESIA

STUDI KASUS PADA LEMBAGA PENERBANGAN DAN ANTARIKSA NASIONAL

TUGAS METODOLOGI PENELITIAN & PENULISAN ILMIAH

SYAHRUL FATHI

1206302825

FAKULTAS ILMU KOMPUTER PROGRAM STUDI MAGISTER TEKNOLOGI INFORMASI

SALEMBA APRIL, 2013

ii Universitas Indonesia

DAFTAR ISI

DAFTAR ISI ........................................................................................................... ii DAFTAR GAMBAR ............................................................................................. iii DAFTAR TABEL .................................................................................................. iii DAFTAR LAMPIRAN .......................................................................................... iii Sejarah Perusahaan .................................................................................................. 1 Visi dan Misi ........................................................................................................... 1 Tugas pokok dan fungsi .......................................................................................... 1 Identifikasi Masalah ................................................................................................ 2 Analisis Masalah ..................................................................................................... 3 Perumusan Masalah ................................................................................................ 4 Rational Unified Process (RUP) ............................................................................. 5 Unified Modeling Language (UML) ....................................................................... 7 Diagram-Diagram UML .......................................................................................... 9

Diagram Use Case ............................................................................................... 9 Diagram Activity ............................................................................................... 10 Diagram Sequence ............................................................................................ 11 Diagram Class ................................................................................................... 11 Diagram Collaboration ...................................................................................... 12

Penelitian Terkait .................................................................................................. 13 Metodologi Terkait ................................................................................................ 14

Rational Unified Process (RUP) ....................................................................... 14 Inception Phase ............................................................................................. 15 Elaboration Phase ......................................................................................... 16 Construction Phase ....................................................................................... 17 Transaction Phase ......................................................................................... 18 Iteration ......................................................................................................... 19

Metodologi Perancangan Sistem Informasi ...................................................... 19 Teoritikal Framework ............................................................................................ 20 Endnote ................................................................................................................. 23

iii Universitas Indonesia

DAFTAR GAMBAR

Gambar 1 Fishbone diagram .................................................................................. 4 Gambar 2 Proses RUP ............................................................................................ 7 Gambar 3 Use case diagram .................................................................................. 9 Gambar 4 Activity Diagram ................................................................................. 10 Gambar 5 Sequence diagram ............................................................................... 11 Gambar 6 Class diagram ..................................................................................... 12 Gambar 7 Collaboration Dagram ........................................................................ 13 Gambar 8 Framework penelitian usability e-recruitment .................................... 14 Gambar 10 Metodologi RUP ............................................................................... 15 Gambar 11 Metodologi penelitian perancangan informasi PT FMI .................... 20 Gambar 12 Metodologi penelitian ....................................................................... 21

DAFTAR TABEL

Tabel 1 Tabel perbandingan kondisi saat ini dan kondisi yang diharapkan oleh LAPAN .................................................................................................... 3

DAFTAR LAMPIRAN

Lampiran 1 Laporan wawancara di LAPAN ....................................................... 22

Universitas Indonesia

1

Sejarah Perusahaan

Pada tanggal 31 Mei 1962, dibentuk Panitia Astronautika oleh Menteri Pertama

RI, Ir. Juanda (selaku Ketua Dewan Penerbangan RI) dan R.J. Salatun (selaku

Sekretaris Dewan Penerbangan RI). Tanggal 22 September 1962, terbentuknya

Proyek Roket Ilmiah dan Militer Awal (PRIMA) afiliasi AURI dan ITB. Berhasil

membuat dan meluncurkan dua roket seri Kartika berikut telemetrinya. Tanggal

27 November 1963, Lembaga Penerbangan dan Antariksa Nasional (LAPAN)

dibentuk dengan Keputusan Presiden Nomor 236 Tahun 1963 tentang LAPAN.

Visi dan Misi

Visi LAPAN adalah “Terwujudnya Kemandirian dalam IPTEK pernebangan dan

ANTARIKSA untuk meningkatkan kualitas kehidupan bangsa”.

Misi LAPAN adalah:

• Memperkuat dan melaksanakan pembinaan, penguasaan dan pemanfaatan

teknologi roket, satelit dan penerbangan.


teknologi dan data penginderaan jauh.


sains antariksa dan atmosfer.

• Mengembangkan kajian kebijakan Penerbangan dan antariksa nasional.

• Mengembangkan sistem manajemen kelembagaan.

Tugas pokok dan fungsi

Tugas pokoknya adalah melaksanakan tugas pemerintah di bidang penelitian dan

pengembangan kedirgantaraan dan pemanfaatannya sesuai dengan peraturan

perundangan yang berlaku. Dalam mengemban tugas pokok di atas LAPAN

menyelenggarakan fungsi-fungsi:

• Pengkajian dan penyusunan kebijaksanaan nasional di bidang penelitian

dan Pengembangan kedirgantaraan dan pemanfaatannya.

• Koordinasi kegiatan fungsional dalam pelaksanaan tugas LAPAN.


2

• Pemantauan, pemberian bimbingan dan pembinaan terhadap kegiatan

instansi pemerintah di bidang kedirgantaraan dan pemanfaatannya.

• Penyelenggaraaan pembinaan dan pelayanan administrasi umum di bidang

perencanaan umum, ketatausahaan, organisasi dan tata laksana,

kepegawaian, keuangan, kearsipan, hukum, persandian, perlengkapan dan

rumah tangga.

Lingkup kegiatan LAPAN mencakup pengembangan teknologi dan pemanfaatan

penginderaan jauh, pemanfaatan sains atmosfer, iklim dan antariksa,

pengembangan teknologi dirgantara, dan pengembangan kebijakan kedirgantaraan

nasional.

Identifikasi Masalah

LAPAN menggunaan sistem informasi e-recruitment untuk proses penerimaan

pegawai. E-recruitment dibentuk pada tahun 2007 dan digunakan pada tahun 2007

juga. E-recruitment dibuat oleh Budi Riyanto, staf Bagian Kepegawaian dan E-

recruitment digunakan oleh Bag. Kepegawaian. E-recruitment dibentuk

berdasarkan kebijakan pimpinan yang bertujuan memudahkan proses rekrutmen

pegawai LAPAN, menghindari unsur KKN dan transparasi proses rekrutmen

pegawai sampai mendapatkan NIP. Namun dalam implementasinya ternyata

ekpektasi e-recruitment ini masih belum tercapai. Berikut beberapa kendala

berdasarkan hasil wawancara dengan ibu Ratih selaku penanggungjawab bidang

kepegawaian: (Sumber hasil wawancara dengan Ibu Ratih Pratiwi sebagai

penanggung jawab bidang kepegawaian di LAPAN)

• Masih tergantungnya sistem dengan orang kepegawaian

• Otomasi sistem belum tercapai. Masih ada tahapan dalam proses

rekrutmen yang harus dilakukan secara manual oleh pegawai LAPAN.

Masih ada proses rekrutmen yang belum termasuk dalam e-recruitment

• Infrastruktur yang digunakan belum memadai. Ketika masuk waktu

proses rekrutmen, orang yang mengakses e-recrutment akan semakin

banyak sehingga Sistem akhirnya tidak dapat diakses


3

Dari analisis diatas, kondisi saat ini dan kondisi yang diharapakan LAPAN

terhadap e-recruitment ternyata belum tercapai. Tujuan LAPAN untuk

mempercepat proses rekrutmen belum tercapai. Untuk itu perlu dianalisis lebih

lanjut untuk mengetahui akar masalah dari e-recruitment di LAPAN.

Tabel 1 Tabel perbandingan kondisi saat ini dan kondisi yang diharapkan oleh LAPAN

Kondisi Saat ini Kondisi yang diharapkan

Sistem informasi e-recruitment yang

sekarang ternyata belum membuat proses

rekrutmen di LAPAN cepat dan akurat.

Masih ada bisnis proses yang belum

terintegrasi sehingga otomasi sistem tidak

tercapai. Infrastruktur juga belum memadai

sehingga menghambat proses yang berada

di e-recruitment

Dengan adanya e-recrutment maka akan

membuat proses rekrutmen pegawai lebih

cepat, akurat, dan transparan.

Analisis Masalah

Gap yang dihasilkan dari identifikasi masalah tersebut harus dianalisis lebih lanjut

menggunakan fishbone diagram. Fishbone diagram akan membantu menentukan

akar masalah tentang e-recruitment di LAPAN. Setelah dianalisis terdapat 4 akar

permasalahan e-recruitment milik LAPAN. Akar pertama adalah dalam hal

manajemen sistem informasinya. Pada proses e-recruitment ternyata masih ada

proses bisnis yang belum terintegrasi. Jadi masing-masing proses tersebut

terpisah, tidak menyatu dalam e-recruitment. Seharusnya proses tersebut masuk

kedalam proses bisnis milik e-recruitment sehingga tidak ada waktu jeda dan

integritas data lebih terjaga. Hal tersebut juga mengakibatkan otomasi belum

tercapai dalam penggunaan e-recruitment.

Akar kedua adalah dalam hal Infrastrukturnya. Ketika sistem menerima load yang

besar saat jadwal rekrutmen dibuka, sistem tidak dapat menangani load tersebut

sehingga sistemnya down. Data yang seharusnya terintegrasi masih disimpan

dalam format excel. Ini akan mempersulit proses audit dan tracking data ketika

dibutuhkan.


4

Akar ketiga masalah ini adalah pada pihak SDM. E-recruitment tersebut masih

bergantung dengan SDM untuk operasionalnya. Akar masalah terakhir adalah

dalam hal birokrasi. Masih ada campur tangan pihak lain di proses rekrutmen

LAPAN. Berikut gambar fishbone diagramnya.

Gambar 1 Fishbone diagram

Penulis mengambil akar masalah perancangan sistem informasi untuk dianalisis

lebih lanjut. Diharapkan ketika perancangan sistem informasi e-recruitment

diproses dengan baik, maka permasalahan lainnya dapat diminimalisir. Jika

perancangan sistem informasinya baik, maka diharapkan ekspektasi LAPAN

untuk proses rekrutmennya secara cepat dan akurat akan tercapai.

Perumusan Masalah

Berdasarkan analisis masalah tersebut, maka dapat dibentuk research question

yaitu:

Bagaimana rancangan sistem informasi e-recruitment di LAPAN?


5

Berikut akan dijelaskan 3 teori yang relevan dengan penelitian ini. Yaitu Rational

Unified Process (RUP), Unified Modeling Language (UML), dan diagram-

diagram UML. Setelah itu akan dibahas tiga penelitian yang berhubungan dengan

e-recruitment. Lalu dijelaskan dua metodologi penelitian yang terkait dengan

perancangan sistem informasi. Pada bagian terakhir dibentuk kerangka penelitian

yang dibuat oleh penulis untuk pengerjaan penelitian ini.

Rational Unified Process (RUP)

Rational Unified Process (RUP) adalah framework pengembangan software

engineering. RUP mengatur bagaimana development membagi tugas dan

tanggung jawab saat proses pengembangan software di organisasi. Tujuannya

untuk membuat software yang memiliki kualitas tinggi dan memenuhi kebutuhan

user dengan waktu yang terjadwal dan biaya yang seefisien mungkin. RUP dapat

digunakan sebagai panduan penggunaan Unified Modeling Language (UML)

secara efektif.i

RUP menjelaskan bagaimana membuat software komersial di dalam

pengembangan software kepada developer. Semua itu adalah best practice atau

sekumpulan metode yang telah teruji secara sukses di industri. RUP menyediakan

panduan, templates, dan berbagai tools untuk membangun software yang

berkualitas dengan best practice yang terdiri dari:

• Develop software iteratively

• Manage requirements

• Use component-based architectures

• Visually model software

• Verify software quality

• Control changes to software

Untuk mendapatkan software yang memuaskan berdasarkan kebutuhan konsumen

sangatlah sulit. Mengetahui semua kebutuhan user di awal pengembangan

software tidaklah mudah. Terkadang ketika ditengah proses development, ada

penambahan proses bisnis yang tidak terdeteksi pada tahap awal analisis.

Pendekatan secara iteratif diperlukan untuk melengkapi bisnis proses yang tidak


6

terdeteksi saat analisis awal ketika sedang masa development software. RUP

mendukung pendekatan secara iteratif untuk menanggulangi berbagai resiko di

semua lifecycle development. Setiap iterasi dalam proses ini menghasilkan suatu

versi software yang siap pakai sehingga tim development tetap produktif

menghasilkan produk selagi proses koreksi tetap berjalan dan akan

diimplementasikan di iterasi berikutnya.

RUP menjelaskan bagaimana cara untuk memperoleh, mengorganisasikan

kebutuhan fungsional dokumen, tracking setiap aktifitas development, dan

memudahkan mendapatkan bisnis proses apa saja yang dibutuhkan. Penggunan

use case dan skenario saat mendeskripsikan bisnis proses terbukti sebagai cara

yang paling ampuh untuk mendapatkan kebutuhan fungsional dan memastikan

desain, implementasi dan software testing sesuai dengan kebutuhan user.

Dalam RUP fokus pada awal development adalah untuk membuat baseline

arsitektur yang kuat sebelum melakukan pengembangan dengan skala penuh. Hal

tersebut menjelaskan bagaimana membangun arsitektur yang fleksibel, dapat

mengakomodasi perubahan, mudah dimengerti secara intuitif, dan mendukung

reusable software. RUP mendukung pengembangan software secara component-

based dan pendekatan yang sistematik untuk menentukan infrastruktur

menggunakan komponen baru atau yang sudah ada.

Setiap proses pada RUP memperlihakan secara visual software model agar dapat

menentukan jenis arsitektur dan komponen software tersebut. Visualisasi secara

abstrak dapat membantu mengkomunikasikan berbagai aspek di software

development. Unified Modeling Language (UML) adalah pondasi dasar suksesnya

visual modeling.

Rendahnya performa aplikasi dan reability dari sebuah software adalah

permasalahan software yang sering ditemui. Karenanya, harus ada review kualitas

terhadap kebutuhan berdasarkan realibilitas, fungsionalitas, performa aplikasi dan

performa sistem. RUP memandu tim development saat perencanaan, desain,

implementasi, eksekusi, dan evaluasi sesuai kualitas yang ditentukan.


7

Kemampuan mengatur perubahan memungkinkan setiap perubahan itu diterima

serta kemampuan menelusuri perubahan sangat dibutuhkan di dalam software

development. Proses tersebut menjelaskan bagaimana untuk mengontrol,

mengikuti, dan memonitor perubahan untuk menunjang software development

yang iteratif. Hal tersebut juga membimbing kita membuat lingkungan

development yang aman untuk developer dengan cara menyediakan isolasi dan

kontrol terhadap perubahan di semua artifak software.

Proses yang terjadi di RUP pada Gambar 1 dibagi menjadi dua dimensi. Bagian

yang horizontal melambangkan waktu dan aspek lifecycle dari development yang

terbagi menjadi empat fase yaitu inception, elaboration, construction, dan

transition. Bagian yang vertikal melambangkan aspek dasri setiap proses

development. Bagian tersebut menjelaskan aktifitas, artifak, developer, dan alur

kerja.

Gambar 2 Proses RUP

Unified Modeling Language (UML)

The Unified Modeling Language (UML) adalah bahasa modeling visual yang

universal dan digunakan secara spesifik untuk membuat spesifikasi, menggambar,

dan membentuk artifak untuk sebuah software system. UML digunakan untuk

memudahkan saat desain, konfigurasi, maintain dan mengontrol informasi di


8

sebuah sistem. Hal ini dimaksudkan agar dapat digunakan disemua tahapan proses

development, tahapan lifecycle, aplication domain, dan media. UML meliputi

konsep semantik, notasi dan guidelines. UML tidak mendefinisikan standar

proses, tetapi berguna pada saat proses development yang iteratif.ii

UML menangkap informasi dari sistem yang bersifat statis maupun dinamis.

Sebuah sistem dimodelkan sebagai sekumpulan dari objek yang berbeda yang

saling berinteraksi untuk melakukan suatu pekerjaan yang berguna bagi user.

Elemen yang bersifat statis mendefinisikan bermacam objek yang penting

terhadap sistem beserta implementasinya. Elemen yang bersifat dinamis

mendefinisikan perubahan objek dari waktu ke waktu dan hubungan komunikasi

antar objek untuk mencapai tujuan objek tersebut. UML juga mendukung

konstruksi organisasi untuk mengatur model kedalam paket-paket yang digunakan

tim development untuk memecah sebuah sistem yang besar menjadi beberapa

bagian, yang mudah dimengerti dan dapat dikontrol di lingkungan development

yang sangat rumit. UML bukanlah bahasa pemograman namun sebuah sistem

dapat mengubah suatu notasi UML menjadi berbagai macam bahasa pemograman.

Tujuan dibentuknya UML adalah memudahkan berbagai macam permodelan.

Penggunaannya tidak ekslusif dan dibuat oleh persetujuan komunitas komputasi.

UML tidak dibuat untuk menjadi development method yang menyeluruh. UML

juga tidak menyediakan step-by-step proses development. UML dan proses yang

menggunakan UML adalah hal yang berbeda. UML menyediakan semua konsep

untuk mendukung metode software development yang moderen dan iteratif

berdasarkan arsitekur yang kuat untuk menyelesaikan permasalahan user. Yang

termasuk dalam konsep area milik UML adalah:

• Static Structure

• Dynamic Behaviour

• Implementation constructs

• Model Organization

• Extensibility Mechanisms


9

Diagram-Diagram UML

Berikut adalah beberapa diagram yang ada di UML beserta penjelasan dan contoh

notasinya.

Diagram Use Case

Diagram use case adalah unit eksternal yang terlihat secara fungsional yang

disediakan oleh unit sistem dan mengekspresikan secara sekuensial pertukaran

pesan oleh unit sistem diantara satu atau lebih aktor dalam sistem unit. Tujuan

dari use case adalah mendefinisikan bagian dari keterhubungan tanpa

memperlihatkan struktur internal dari sistem. Definisi use case termasuk semua

tingkah laku dari semua variasi yang normal maupun yang eksepsional. Dari sudut

pandang user, ini adalah kondisi yang tidak biasa, tetapi dari sisi sistem variasi ini

harus didefinisikan dan dapat ditanggulangi

Di dalam model, eksekusi dari setiap use case tidak tergantung dari use case yang

lain, walaupun dalam implementasinya use case secara implisit dependen

terhadap dua objek. Use case yang bervariasi dapat di gambarkan melalui UML

seperti state chart diagram, sequence diagram, collaboration diagrams atau

informal text description. Ketika use case di implementasi, setiap use case pada

akhirnya saling berkolaborasi. Diagram use case Terdiri dari aktor, dan

lingkungan atau ruang lingkup use case tersebut.

Gambar 3 Use case diagram


10

Diagram Activity

Activity diagram adalah notasi dari activity graph. Activity diagram memiliki

beberapa simbol spesial yang disusun berdasarkan tingkat kenyamanan. Simbol

tersebut dapat berupa state chart diagram.

Setiap fase aktivitas ditampilkan dalam bentuk box rounded. Notasi untuk transisi

yang selesai digambarkan dengan garis panah. Percabangan dibentuk dengan garis

atau diamond dengan berbagai label sesuai kondisi kebutuhan sistem.

Penggabungan setelah percabangan digambarkan seperti state chart dengan garis

panah. Untuk situasi eksternal, input dari sebuah event dapat ditampilkan sebagai

trigger untuk transisi.

Gambar 4 Activity Diagram


11

Diagram Sequence

Sequence diagram menggambarkan interaksi dengan grafik dua dimensi. Bagian

yang vertikal adalah dimensi waktu. Bagian horizontal adalah klasifikasi dari

berbagai objek sesuai dengan peran objek tersebut. Ketika objek sedang aktif,

maka notasi akan berbentuk garis putus-putus. Sendangkan ketika prosedur

sedang aktif, garis akan digambarkan dengan garis yang double.

Gambar 5 Sequence diagram

Diagram Class

Static view konsep di dalam model aplikasi adalah bagian dari internal

implementasi. Hal ini bersifat statis karena tidak menggambarkan waktu dari

sistem yang digambarkan di permodelan yang lain. Objek utama dari static view

adalah class dan relationshipnya beserta asosiasi, generalisasi, dan beberapa

macam dependensi. Class adalah gambaran dari konsep dari aplikasi domain.

Class digambarkan persegi panjang. List atribut dan operasi di tampilkan di

bagian bawahnya. Relationship antar class digambarkan oleh garis yang

menghubungakn class satu dengan yang lain.


12

Gambar 6 Class diagram

Diagram Collaboration

Diagram collaboration adalah class diagram yang berisi tentang klasifikasi dan

asosiasi terhadap peran suatu objek. Peran tersebut menerangkan konfigurasi dari

objek dan menghubungkanya ketika instance dari kolaboration dijalankan. Ketika

kolaborasi terbentuk, objek bergantung dengan classifier role dan

menghubungkannya dengan asociation roles. Asociation rolse dapat berperan

sebagai penghubung sementara seperti prosedur argumen, atau lokal variabel

prosedur.

Hanya objek yang tergabung dengan kolaborasi ditampilkan meskipun masih ada

yang lain di keseluruhan sistem. Dengan kata lain, kolaborasi model diagram dari

objek dan links bersatu di dalam tahap implementasi dari hasil interaksi dan

menghiraukan yang lain


13

Gambar 7 Collaboration Dagram

Penelitian Terkait

Karetsos & Manouselis (2009) melakukan penelitian tentang modeling untuk e-

government untuk skala small medium enterprise (SME) di pedesaan

menggunakan UML dan RUP. Mereka ingin mengetahui pengaruh ICT di daerah

pedesaan yang tidak terlalu maju dibandingkan di kota. Mereka fokus pada

analisis, design dan implementasi e-government untuk daerah SME dengan

modelling language UML serta berdsarkan RUP untuk software life cycle

approach. Tujuan penelitian ini untuk menggerakan SME mendapatkan informasi

dari pemerintah pusat atau pemerintah daerah, selagi mereka mendapatkan akses

untuk menggunakan e-learning seperti menggunakan service yang adaiii. Proses

penelitian mereka menggunakan empat proses workflow RUP yaitu business

modeling, requirements use case modeling, analysis & design, dan

implementation.

Musa et al (2006) melakukan penelitian tentang sistem e-recruitment di

pemerintahan Serawak, Malaysia. Peneliti fokus pada usability dari penggunan

website e-recruitment. Kriteria dari usability adalah navigasi berupa hyperlinks,

panjang halaman, penempatan layout pencarian ataupun informasi user. Dalam

penelitian ini, yang diteliti adalah penggunaan warna dan gambar, layout website,

dan konsistensi. Hasil penelitian menunjukan bahwa kriteria tersebut menentukan

sukses atau tidaknya sebuah sistem informasi e-recruitment. Karena pengguna

sistem adalah orang yang sering melakukan lamaran secara tradisional, usability

dari website tersebut adalah hal yang vital yang memfasilitasi proses rekrutmen


14

secara efektif dan efisieniv. Berikut adalah framework yang digunakan dalam

penelitian diatas:

Gambar 8 Framework penelitian usability e-recruitment

Manzoni & Price (2003) melakukan penelitian tentang asesmen pada proses RUP

berdasarkan CMM. Dalam penelitiannya, setiap key practice (KP) diidentifikasi

untuk setiap key process area (KPA), RUP dinilai untuk menentukan apakah

hasilnya sesuai dengan KP atau tidak. Untuk setiap KPA, presentase dari key

practice yang disupport dijumlahkan. Hasilnya berupa seberapa besar proses area

yang mendukung dari hasil RUP yang mendukung CMMI level 2 dan level 3.

Kesimpulannya dari penelitian ini adalah asesmen dari RUP dapat memenuhi

beberapa kebutuhan CMM tetapi ada beberapa aspek manajerial yang tidak dapat

didukung. RUP memang dibentuk untuk pendekatan software manajemen dan

proses software engineering, tetapi bukan untuk pendekatan sistem manajemen.

Karena RUP tidak mencakup cost management, human resources management,

communication management, dan contracts management.v

Metodologi Terkait

Rational Unified Process (RUP)

Rational Unified Process (RUP) adalah framework pengembangan software

engineering. RUP mengatur bagaimana development membagi tugas dan


15

tanggung jawab saat proses pengembangan software di organisasi. Tujuannya

untuk membuat software yang memiliki kualitas tinggi dan memenuhi kebutuhan

user dengan waktu yang terjadwal dan biaya yang seefisien mungkin. RUP dapat

digunakan sebagai panduan penggunaan Unified Modeling Language (UML)

secara efektif

Gambar 9 Metodologi RUP

Inception Phase

Pada tahap inception, tim development menentukan kasus bisnis yang akan ada di

sistem dan menentukan batasan dari project tersebut. Untuk mencapai hal

tersebut, tim harus menentukan semua entitas yang berinteraksi ke sistem dan

definisikan interaksi tersebut dalam high level. Proses ini melibatkan identifikasi

semua use case dan definisikan yang penting-penting saja. Hal itu termasuk

kriteria sukses, risk assesment, estimasi sumber daya yang dibutuhkan, dan

milestone di software developement tersebut. Keluaran dari proses ini adalah:

• Vision document

• Use case model (10% – 20%)

• Tahap awal project glosary

• Tahap awal pengembangan bisnis case

• Tahap awal risk assesment

• Project plan (perlihatkan fase dan iterasinya)

• Bisnis model jika diperlukan


16

• Beberapa prototipe

Akhir dari fase ini adalah tahap awal dari milestone yaitu lifecycle objectives

milestone. Kriteria evaluasi dari fase inception adalah:

• Stakeholder

• Requirement understanding

• Credibility of the cost

• Depth and breadth

• Actual expenditures

Project dapat dibatalkan atau didevelop ulang jika tidak memenuhi kriteria diatas

Elaboration Phase

Tujuan fase elaboration adalah menganalisa problem domain, menentukan

pondasi arsitektural, membuat project plan, dan menghilangkan elemen yang

mempunyai resiko paling tinggi di dalam project. Untuk tujuan tersebut,

developer harus tau secara luas dan mendalam aplikasi yang akan dibuat.

Keputusan untuk membuat sebuah arsitektur harus dibuat dengan pengetahuan

akan keseluruhan sistem, cakupan aplikasi sesuai requirements, kebutuhan

fungsional dan nonfungsional sistem.

Fase elaboration adalah fase terpenting diantara empat fase yang ada di RUP. Fase

ini menentukan apakah proses berlanjut ke pembuatan fase konstruksi dan fase

transisi. Fase ini juga memastikan apakah arsitektur, kebutuhan dan rencana sudah

matang atau belum. Sehingga tim development dapat memprediksi biaya dan

jadwal yang dibutuhkan untuk pengembangan aplikasi ini.

Di fase elaboration, arsitektur prototype yang siap pakai adalah hasil dari

beberapa iterasi development tergantung dari batasan, besar dan resiko dari suatu

project. Fase tersebut minimal menunjukan use case yang penting yang di dapat

pada fase inception, yang biasanya mendapatkan major technical risk yang

terdapat dalam project. Keluaran dari fase ini adalah:


17

• Use case model minimal 80%

• Supplementary requirements menangkap semua non functional

requirements

• Deskripsi arsitektur software

• Arsitektur prototype yang siap pakai

• List revisi dari resiko dan bisnis case

• Development plan dari keseluruhan project

• Update dari development case

• Preliminary user manual (optional)

Akhir dari fase ini adalah bagian terpenting kedua di dalam proses RUP karena

pada fase ini sudah mendapatkan secara detil objektif sistem dan ruang

lingkupnya, arsitektur apa yang akan dipakai, dan resolusi dari resiko yang major.

Kriteria evaluasi pada tahap ini adalah:

• Apakah product vision sudah stable?

• Apakah arsitektur sudah stable?

• Apakah demo project sudah mencakup semua major risk yang sudah

diperbaiki?

• Apakah plan dari fase konstruksi sudah secara mendetail dan akurat?

• Apakah semua stakeholders setuju versi yang sekarang ini dan

arsitektur yang sekarang jika dieksekusi dapat membangun

keseluruhan sistem?

• Apakah resource expenditure yang sekarang dan expenditure yang

direncanakan sudah dapat diterima?

Construction Phase

Pada saat fase konstruksi, semua komponen dan fitur aplikasi yang tersisa sudah

dibuat dan diintegrasikan kedalam produk dan sudah diuji. Pada fase ini cara

pandang berubah dari pengembangan intelektual properti di fase inception dan

elaboration menjadi pengembangan produk di fase construction dan transition.

Minimal fase ini menghasilkan:


18

• Software produk yang terintegrasi ke platform

• User manuals

• Deskripsi dari rilis yang terbaru

Setelah fase ini tim development menentukan apakah software sudah layak rilis

dan dapat digunakan secara layak. Biasanya produk rilis ini disebut produk beta.

Kriteria evaluasi pada tahap ini diantaranya:

• Apakah produk ini sudah stabil dan layak dioperasikan oleh komunitas

pengguna?

• Apakah semu stakeholders sudah siap dengan transisi ke komunitas

pengguna?



Transaction Phase

Tujuan tahap ini adalah melakukan transisi produk yang telah dibangun ke

komunitas user. Setelah produk sudah diberikan ke user, biasanya muncul

masalah yang harus diperbaiki pada rilis selanjutnya. Masa transisi ini terjadi

ketika baseline sekiranya sudah cukup matang untuk di jalankan pada end user.

Tahapan ini membutuhkan beberapa subset yang berfungsi dan diterima oleh

batas kualitas tertentu sehingga menghasilkan hasil yang positif bagi semua pihak.

Fase ini menghasilkan:

• Beta testing untuk validasi apakah sistem ini sesuai dengan kebutuhan

user

• Melakukan operasi yang paralel selagi mengganti sistem yang lama

• Konversi database

• Pelatihan untuk user

• Memberitahukan kepada tim di bagian marketing, distribusi dan sales

Fase transition fokus kepada aktifitas yang dibutuhkan untuk menyampaikan

produk ke user. Biasanya fase ini terdiri dari beberapa iterasi termasuk beberapa

beta rilis. Objektif utama dari fase transisi termasuk:


19

• Memperoleh dukungan dari user

• Memperoleh kepastian dari stakeholder apakah baseline sudah cukup

matang, konsisten dan sesuai dengan kriteria dari visi produk

• Memperoleh baseline produk yang efektif secara cost

Fase ini memiliki rentang kesulitan dari simpel hingga kompleks tergantung dari

tipe produknya. Sebagai contoh, produk baru yang menggantikan produk lama

dapat dilakukan dengan mudah, tetapi jika dalam konteks produk yang besar hal

tersebut sangat sulit dilakukan. Pada titik ini, tim menentukan apakah objek telah

terpenuhi dan tim akan mulai melakukan iterasi berikutnya. Kriteria untuk

evaluasi tahap ini adalah:

• Apakah user sudah puas?



Iteration

Setiap fase pada RUP dapat dipecah menjadi beberapa iterasi. Iterasi adalah

sebuah perulangan secara menyeluruh pada tahap development yang

menghasilkan suatu produk release. Iterasi termasuk dari bagian sebuah final

product, yang berkembang dari iterasi ke iterasi selanjutnya. Keuntungan

menggunakan pendekatan iterasi adalah:

• Resiko akan terdeteksi lebih cepat

• Sebuah perubahan dapat lebih mudah diatur

• High level penggunaan ulang suatu bagian software

• Team project dapat belajar bertahap dari iterasi ke iterasi yang lain

• Mendapatkan kualitas yang lebih baik

Metodologi Perancangan Sistem Informasi

Metodologi perancangan sistem informasi ini diambil dari karya akhir Irman

Triharyanto, MTI UI 2006. Penelitiannya berjudul “Perancangan Sistem

Informasi Terpadu Jaringan Apotek PT. FMI”. Peneliti melakukan tahapan

penelitiannya berawal dari tahap wawancara, studi literatur, melakukan survey,


20

tahap analisis, tahap perancangan dan tahap pelaporan. Peneliti menggunakan

metode analisis FAST untuk merumuskan langkah-langkah yang ditempuh untuk

menyelesaikan tahap analisa permasalahan. vi

Gambar 10 Metodologi penelitian perancangan informasi PT FMI

Dalam penelitiannya, problem analysis FAST digunakan untuk meliputi domain-

domain: memahami problem domain, menganalisa masalah dan peluang-peluang,

dan menganalisa proses bisnis, dan menentukan system improvement objectives.

Untuk identifikasi masalah dan peluang-peluang arahan yang ada dalam sistem

tersebut, peneliti menggunakan PIECES framework.

Teoritikal Framework

Untuk rencana pengerjaan penelitian, dibentuk teoritikal framework untuk

panduan langkah-langkah pengerjaan penelitian perancangan sistem informasi e-

recruitment di LAPAN. Penelitian ini diawali dengan pengumpulan data awal.

Data ini berupa informasi permasalahan apa yang ditemui oleh organisasi?

Apakah permasalahan tersebut dapat diselesaikan menggunakan pendekatan

secara ilmiah? Apakah memungkinkan data yang diperlukan mudah didapat? dan

sebagainya.


21

Gambar 11 Metodologi penelitian

Dari masalah tersebut dibentuk pertanyaan penelitian untuk membuat ruang

lingkup pengerjaan penelitian lebih sempit agar pengerjaannya lebih fokus dan

terarah. Setelah pertanyaan penelitian di dapat, dicarilah teori-teori pendukung

yang dapat membantu menyelesaikan masalah. Setelah teori pendukung diperoleh,

maka dirancang metode penelitian untuk menentukan tahapan penelitian. Untuk

melaksanakan penelitian lebih lanjut diperlukan data yang lengkap sesuai

kebutuhan penelitian, maka dilakukan penggalian data lebih lanjut menggunakan

teknik wawancara atau pengambilan data yang lain. Setelah data diperoleh maka

dibentuk mulai masuk tahapan development menggunakan RUP seperti yang telah

dijelaskan di bagian atas. Hasilnya dibahas untuk mengetahui lebih lanjut. Pada

proses terakhir ditarik kesimpulan berdasrkan hasil analisa penelitian yang telah

dilakukan.


22

Lampiran 1 Laporan wawancara di LAPAN

Hari, Tanggal pelaksanaan: Kamis, 28 Maret 2013

Waktu Pelaksanaan: 10:00 – 17-00

Media Pelaksanaan: email

Narasumber: Ratih Pratiwi (Penanggung jawab sebagai Kabag. Kepegawaian)

Pewawancara: Syahrul Fathi

Tema Wawancara: Penggunaan Sistem Informasi e-recruitment di LAPAN

Tujuan Wawancara: Untuk mengetahui apakah e-recruitment ini sudah berjalan sesuai strategi LAPAN.

• Pertanyaan: Ibu Ratih menjabat sebagai apa di LAPAN? Jawaban: Penanggungjawab Kabag. Kepegawaian

• Pertanyaan: E-recruitment ini dibentuk tahun berapa? Dan kapan mulai digunakan? Jawaban: E-recruitment ini dibentuk tahun 2007 dan mulai digunakan tahun 2007 juga.

• Pertanyaan: Siapa yang membuat sistem informasi ini? Jawaban: Budi Riyanto, staf Bagian Kepegawaian

• Pertanyaan: Siapa yang menggunakan aplikasi ini? Jawaban: Aplikasi ini digunakan oleh Bag. Kepegawaian

• Pertanyaan: Apa alasan dibentuknya aplikasi ini? Jawaban: e-recruitment dibentuk karena berdasarkan kebijakan pimpinan. Dengan aplikasi ini juga diharapkan dapat mengurangi unsur KKN dalam proses rekrutmen di LAPAN. Transparasi juga hal yang perlu diperhatikan dalam proses rekrutmen di LAPAN. Sehingga setiap rekrutmen yang ada dapat dipertanggungjawabkan

• Pertanyaan: Apa tujuan dan ekspektasi untuk e-recruitment di lapan? Jawaban: Diharapkan proses rekrutmen di LAPAN dapat berlangsung cepat dan akurat. Serta diharapkan dapat mengenalkan LAPAN ke masyarakat luas.

• Pertanyaan: Apakah ekspektasi tersebut sudah tercapai? Jawaban: Ekspektasinya belum semuanya tercapai

• Pertanyaan: Apa saja kendalanya? Jawaban: Masih tergantungnya sistem dengan orang kepegawaian. Otomatisasi sistem belum tercapai. Masih ada tahapan dalam proses rekrutmen yang harus dilakukan secara manual oleh pegawai LAPAN. Infrastruktur yang digunakan belum memadai. Ketika masuk waktu proses rekrutmen, orang yang mengakses e-recrutment akan semakin banyak sehingga Sistem akhirnya tidak dapat diakses


23

Endnote

i Process, Rational Unified. Best practices for software development teams. A Rational Software ii James Rumbaugh, Ivar Jacobson, and Grady Booch. 2004. Unified Modeling Language

Reference Manual, the (2nd Edition). Pearson Higher Education.

iii Karetsos, S., Manouselis, N., & Costopoulou, C. (2011). Modeling an e-government observatory

for rural SMEs using UML with RUP. Operational Research, 11(1), 59-75. doi:

http://dx.doi.org/10.1007/s12351-009-0060-8 iv Musaa, N., Junaini, S. N., & Bujang, Y. R. (2006, January). Improving usability of e-recruitment

website: A preliminary study on Sarawak government website. In Pacific Asia Conference on

Information Systems (10). v Manzoni, L. V., & Price, R. T. (2003). Identifying extensions required by RUP (rational unified

process) to comply with CMM (capability maturity model) levels 2 and 3. IEEE Transactions on

Software Engineering, 29(2), 181-192. doi: http://dx.doi.org/10.1109/TSE.2003.1178058 vi Triharyanto, I. 2006. Perancangan sistem informasi terpadu jaringan apotek PT. FMI. Program

Magister Teknologi Informasi. Fakultas Ilmu Komputer. Universitas Indonesia, 2006.

Documents

PSI LAPAN