Anda di halaman 1dari 38

MODUL ANALISIS DAN PERANCANGAN SISTEM INFORMASI

(IND214)

MODUL PERTEMUAN 4
ANALISIS SISTEM

DISUSUN OLEH
ARIO KURNIANTO, STP., MT.

UNIVERSITAS ESA UNGGUL


2020

Universitas Esa Unggul


http://esaunggul.ac.id
0 / 38
MANAJEMEN PROYEK

A. Kemampuan Akhir Yang Diharapkan


Setelah mempelajari modul ini, diharapkan mahasiswa mampu :
1. Menjelaskan analisis sistem dan hubungannya dengan tahapan metode
pengembangan sistem
2. Menjelaskan pendekatan analisis sistem sebagai alat bantu pemecahan masalah
bisnis
3. Menjelaskan definisi ruang lingkup, analisis masalah, analisis kebutuhan,
perancangan logika dan analisis keputusan terkait blok bangunan sistem
informasi
4. Menjelaskan definisi ruang lingkup, analisis masalah, analisis kebutuhan,
perancangan logika dan analisis keputusan terkait maksud, peserta, input,
output, cara, dan tahapan

B. Uraian Materi
1. Pengertian Analisis Sistem
Analisis Sistem merupakan sebuah teknik pemecahan masalah dengan cara
menguraikan sebuah sistem menjadi bagian-bagian kecil komponen sistem tersebut
yang bertujuan untuk mempelajari seberapa baik komponen-komponen tersebut
bekerja dan saling berinteraksi untuk mencapai tujuannya.
Analisis sistem merupakan prasyarat untuk perancangan sistem, yaitu
spesifikasi sitem yang baru dan lebih baik. Perancangan Sistem adalah sebuah
teknik pemecahan masalah yang melengkapi analisis sistem, yaitu dengan cara
menyusun ulang setiap bagian komponen sistem yang telah diuraikan sebelumnya
menjadi sebuah sistem yang utuh kembali, dengan harapan menjadi sebuah sistem
yang lebih baik. Proses ini melibatkan kegiatan penambahan, pengurangan,
perubahan satu atau beberapa bagian terkait dengan sistem awalnya. Secara umum
kerangka dari analisis sistem dapat dilihat pada Gambar 4.1.
Selama ini tidak ada definisi baku dari analisis sistem yang diterima secara
umum, bahkan tidak pernah ada kesepakatan bersama mengenai kapan analisis
Sistem Informasi berakhir dan perancangan Sistem Informasi dimulai. Analisis

Universitas Esa Unggul


http://esaunggul.ac.id
1 / 38
Sistem Informasi merupakan tahapan-tahapan pengembangan dalam proyek
pengembangan Sistem Informasi yang terutama berfokus pada masalah dan
kebutuhan bisnis, terlepas dari teknologi apapun yang dapat atau akan digunakan
untuk mengimplementasikan solusi untuk masalah tersebut.

Gambar 4.1. Kerangka Analisis Sistem

Analisis sistem didorong oleh kepentingan bisnis pemilik sistem dan


pengguna sistem. Karenanya, analisis sistem membahas mengenai blok bangunan
pengetahuan, proses, dan komunikasi dari sudut pandang pemilik sistem dan
pengguna sistem.
Dokumentasi dan hasil akhir yang dihasilkan oleh tugas-tugas dalam
analisis sistem biasanya disimpan di dalam repositori. Repositori adalah sebuah
(atau satu set) lokasi dimana analis sistem, perancang sistem, dan pengembang
sistem menyimpan seluruh bentuk dokumentasi terkait satu atau lebih sistem atau
proyek. Repositori biasanya merupakan gabungan dari beberapa hal berikut:

Universitas Esa Unggul


http://esaunggul.ac.id
2 / 38
 Direktori di dalam jaringan yang berisikan arsip baik dalam format word,
spreadsheet atau format lain yang dihasilkan oleh software komputer mengenai
korespondensi, laporan-laporan, dan data proyek.
 Satu atau lebih kamus atau ensiklopedia alat Computer Aided Software
Engineering (CASE)
 Dokumentasi yang dicetak
 Website Intranet yang berisikan semua hal di atas

2. Pendekatan Sistem Analisis


Secara mendasar, analisis sistem selalu tentang pemecahan masalah.
Terdapat beberapa pendekatan untuk melakukan pemecahan masalah, demikian
pula halnya dengan analisis sistem. Pada kenyataanya, beberapa pendekatan bisa
saling melengkapi satu sama lain.
a. Pendekatan Analisis Berdasarkan Model
Analisis berdasarkan model adalah pendekatan pemecahan masalah yang
menekankan pada penggambaran model sistem bergambar untuk
mendokumentasikan dan memvalidasi sistem yang sudah berjalan dan atau
yang akan diajukan. Model sistem tersebut akan menjadi blueprint untuk
merancang dan membangun sebuah sistem yang ditingkatkan. Contoh dari
analisis berdasarkan model antara lain, analisis terstruktur, teknik informasi,
dan analisis beorientasi objek.
Analisis berdasarkan model menggunakan gambar-gambar untuk
mengkomunikasikan masalah-masalah, kebutuhan, dan solusi bisnis. Model
adalah sebuah representasi dari realitas atau impian. Contoh model antara lain,
flowchart, diagram struktur, diagram hirarki, dan diagram struktur organisasi.

1) Pendekatan Tradisional
Berbagai macam pendekatan untuk analisis dan perancangan sistem
dikembangan telah dikembangkan sejak awal tahun 1970-an. Salah satu
pendekatan formal klasik yang sampai saat ini masih digunakan adalah
Analisis Terstrukur.

Universitas Esa Unggul


http://esaunggul.ac.id
3 / 38
Analisis Terstruktur adalah sebuah teknik berdasarkan model yang
berpusat pada proses yang digunakan untuk menganalisis sistem yang ada
atau menentukan kebutuhan bisnis untuk sistem baru atau keduanya. Salah
satu alat utama yang digunakan untuk memproses sebuah model pada
analisis terstruktur adalah Data Flow Diagram (DFD) atau Diagram Alir
Data (DAD), contohnya bisa dilihat pada Gambar 4.2.

Gambar 4.2. Contoh Data Flow Diagram

DFD menggambarkan sistem yang sudah berjalan dan atau yang baru akan
diajukan termasuk di dalamnya input, output dan data yang terlibat. Model
tersebut memperlihatkan aliran data di antara proses-proses dan yang
melalui proses tersebut dan lokasi penyimpanan data. Model proses tersebut
menjadi blueprint untuk mengimplementasi sebuah bisnis proses dan
software yang akan dibeli atau dikembangkan.

Universitas Esa Unggul


http://esaunggul.ac.id
4 / 38
Pendekatan lain dari pendekatan tradisional adalah Information
Engineering (IE) atau Rekayasa Informasi, yaitu sebuah teknik
berdasarkan model yang berpusat pada data namun memiliki proses yang
sensitif, yang digunakan untuk perencanaan, analisa, dan perancangan
Sistem Informasi. IE lebih berfokus pada struktur data yang disimpan di
dalam sistem daripada prosesnya. Alat utama yang digunakan untuk
membuat model data yang dibutuhkan pada pendekatan IE adalah Entity
Relationship Diagram (ERD) atau Diagram Hubungan Entitas. Contoh dari
ERD dapat dilihat pada Gambar 4.3.

Gambar 4.3. Contoh Entity Relationship Diagram

Awalnya, IE dipandang sebagai pendekatan yang menyaingi analisis


terstruktur, namun seiiring berjalannya waktu kedua pendekatan tersebut
menjadi saling melengkapi dimana DFD digunakan untuk membuat model
dari proses sistem, sedangkan ERD digunakan untuk membuat model
datanya.

2) Pendekatan Berorientasi Objek


Sebagian besar metode analisis sistem mencoba untuk mensinkronkan
model data dan proses, kenyataannya percobaan tersebut tidak selalu
berhasil. Teknologi Objek telah muncul untuk menghilangkan pemisahan
buatan dari data dan proses tersebut. Pendekatan berorientasi objek adalah

Universitas Esa Unggul


http://esaunggul.ac.id
5 / 38
sebuah teknik berdasarkan objek yang mengintegrasikan masalah data dan
proses-proses ke dalam konstruksi yang disebut objek.
Objek merupakan enkapsulasi data (disebut dengan properti) yang
menjelaskan mengenai orang, benda, lokasi, atau kejadian yang berlainan,
beserta seluruh proses yang terlibat (disebut dengan metode) yang
memungkinkannya untuk menggunakan atau melakukan update data dan
properti. Saat ini telah berkembang berbagai macam bahasa pemograman
berorientasi objek seperti misalnya Java, C++, dan bahasa .NET.
Pendekatan berorientasi objek memiliki seperangkat alat pemodelan yang
lengkap yang dikenal dengan Unified Modelling Language (UML). Salah
satu bentuk diagram UML, yaitu Diagram Kelas Objek dapat dilihat pada
Gambar 4.4.

Gambar 4.4. Model Objek menggunakan Unified Modelling Language


Standar

Universitas Esa Unggul


http://esaunggul.ac.id
6 / 38
b. Pendekatan Analisis Sistem Terakselerasi
Pendekatan Analisis Sistem Terakselerasi (Accelerated System Analysis
Approach) merupakan sebuah pendekatan yang menekankan pada
pembangunan prototipe untuk secara cepat dapat mengidentifikasi kebutuhan
bisnis dan pengguna untuk sistem yang baru. Contohnya antara lain Penemuan
Prototyping dan Analisis Rancang Bangun Cepat. Prototipe adalah sebuah
contoh model sistem yang diinginkan dalam ukuran kecil, belum lengkap,
namun sudah bisa bekerja. Dimana yang dimaksud dengan belum lengkap
adalah tidak termasuk pengecekan kesalahan, validasi input data, keamanan,
proses yang lengkap dari aplikasi yang sudah selesai.

1) Penemuan Prototyping
Penemuan Prototyping merupakan sebuah teknik yang digunakan untuk
mengidentifikasi kebutuhan bisnis dari sisi user dengan cara implementasi
cepat-dan-kasar dari kebutuhan-kebutuhan tersebut.
Sebagai contoh, seorang analis sistem menggunakan alat pengembangan
sederhana seperti Microsoft Access untuk menciptakan secara cepat sebuah
database sederhana, formulir masukan user, dan laporan sampel untuk
mengumpulkan respon pengguna untuk mengetahui apakah database,
formulir, dan laporan yang ada dapat merepresentasikan kebutuhan bisnis
sebenarnya.
Salah satu kelebihan dari pendekatan metode analisis penemuan prototyping
ini adalah cara kerjanya yang menyesuaikan dengan karakter dari sebagian
besar user dan manajer yaitu cara berfikir “Saya akan tahu apa yang saya
mau saat saya melihatnya”, dimana maksudnya adalah ketika pengguna atau
manajer diberikan sebuah sampel sebuah produk atau sistem yang belum
jadi secara sempurna, mereka akan mengetahui apa yang diinginkannya
karena sudah melihat wujudnya sehingga bisa menentukan keputusannya.
Beberapa kekurangan dari metode pendekatan ini adalah:
 Pengguna bisa sangat terpaku dengan kondisi yang dianggap final dari
produk atau sistem akhir yang direncanakan, dimana kondisi ini belum
tentu sama pada akhir penyelesaian proyek.

Universitas Esa Unggul


http://esaunggul.ac.id
7 / 38
 User bisa salah mengartikan bahwa sistem yang lengkap bisa
diselesaikan dengan cepat dengan menggunakan alat prototyping,
dimana kondisi sebenarnya bisa saja lebih lama dari perkiraan awal.

2) Analisis Rapid Architected


Analisis Rapid Architected adalah sebuah pendekatan yang mencoba untuk
mendapatkan model sistem dari sistem yang ada atau penemuan prototipe.
Untuk memperoleh model yang terbentuk secara otomatis memerlukan
teknik rekayasa balik (reverse engineering).
Reverse Engeineering adalah sebuah teknologi yang digunakan untuk
membaca kode-kode program dari database yang ada, program aplikasi, dan
atau antar-muka pengguna dan secara otomatis menghasilkan model sistem
yang setara. Model sistem yang dihasilkan dapat diedit dan ditingkatkan
oleh analis sistem dan pengguna untuk menyediakan sebuah blueprint untuk
sistem baru dan atau sistem yang ditingkatkan.

c. Metode Penemuan Kebutuhan (Requirement Discovery Method)


Baik pendekatan analisis berdasarkan model ataupun accelerated system
berusaha untuk mengekspresikan kebutuhan user untuk sistem baru, baik
sebagai model atau prototipe. Semua pendekatan untuk analisis sistem
memerlukan sebuah bentuk Penemuan Kebutuhan. Metode Penemuan
Kebutuhan adalah sebuah proses yang digunakan oleh analis sistem dalam
mengidentifikasi atau mencari tahu permasalahan sistem dan kebutuhan akan
solusi yang tepat dari sekelompok user.
Terdapat dua pendekatan dari metode penemuan kebutuhan, yaitu:
1) Teknik Fact-Finding (Pencarian Fakta)
Fact-Finding adalah adalah sebuah proses mengumpulkan informasi
mengenai permasalahan, peluang, kebutuhan solusi dan prioritas dari
sebuah sistem. Terdapat beberapa teknik fact-finding, yaitu:
 Pengambilan sampel dari dokumen, laporan, formulir, arsip, database,
dan memo yang sudah ada

Universitas Esa Unggul


http://esaunggul.ac.id
8 / 38
 Penelitian terhadap literatur yang relevan, pembandingan dengan solusi
lain, dan kunjungan lapangan
 Pengamatan terhadap sistem saat ini ketika sedang bekerja dan
lingkungan pekerjaan
 Kuisioner dan survey terhadap manajemen dan komunitas user
 Wawancara terhadap manajer yang sesuai, pengguna, dan karyawan
teknik

2) Joint Requirement Planning (JRP)


Teknik-teknik fact-finding di atas sangat bermanfaat, namun bisa menjadi
sangat memakan waktu. Untuk menghindari hal tersebut, alternatifnya
adalah menggunakan teknik Joint Requirement Planning (JRP) atau
Perencanaan Kebutuhan Bersama untuk mempercepat proses penemuan
kebutuhan dan pengelolaannya. JRP adalah sebuah teknik penemuan
kebutuhan dengan mengadakan sebuah workshop yang difasilitasi untuk
mengumpulkan seluruh pemilik, user, dan analis sistem serta beberapa
perancang dan pengembang sistem untuk bersama-sama melakukan analisa
sistem.
Di dalam pelaksanaannya, sebuah sesi JRP memerlukan seorang fasilitator
untuk memperlancar kegiatan tersebut, yaitu seorang analis yang
tersertifikasi atau seseorang yang telah memperoleh pelatihan JRP secara
komprehensif. JRP diadakan selama 3-5 hari, namun bisa menghemat waktu
yang biasanya bisa berminggu-minggu kadang hingga berbulan-bulan bila
menggunakan teknik pencarian fakta klasik dan pertemuan yang berulang-
ulang.

d. Metode Business Process Redesign (BPR)


Metode BPR merupakan penerapan metode analisis sistem yang bertujuan
untuk mengubah secara dramatis dan meningkatkan proses bisnis secara
fundamental dari sebuah organisasi, yang tidak bergantung dengan teknologi
informasi. Penggunaan BPR utamanya adalah karena diperoleh temuan bahwa

Universitas Esa Unggul


http://esaunggul.ac.id
9 / 38
sebagian besar Sistem Informasi dan aplikasi terkini hanya mengotomatiskan
proses bisnis yang ada dan kenyataannya tidak efisien.
Beberapa proyek BPR fokus pada seluruh proses bisnis, terlepas dari
kondisi terotomasinya. Setiap proses bisnis dipelajari secara menyeluruh dan
dianalisa untuk dicari bottleneck, nilai yang dikembalikan, dan peluang untuk
eliminasi dan perampingan. Setelah proses bisnis selesai dirancang ulang,
sebagian besar proyek BPR berakhir dengan menguji bagaimana teknologi
informasi bisa diterapkan dengan baik pada proses bisnis yang telah
ditingkatkan.

e. Metode Tangkas (Agile Method)


Metode Tangkas merupakan integrasi dari beberapa pendekatan analisis
sistem dan perancangan untuk aplikasi yang dianggap sesuai dengan masalah
yang sedang diselesaikan dan sistem yang dikembangkan.

3. Tahap Definisi Ruang Lingkup


Tahap Definisi Ruang Lingkup merupakan tahap pertama dalam proses
pengembangan sistem klasik. Tahap ini akan menjawab pertanyaan: “Apakah
proyek ini layak untuk dijalankan?”
Untuk menjawab pertanyaan tersebut, maka terlebih dahulu harus diperjelas
ruang lingkup dari proyek dan masalah, peluang, dan arahan yang dirasakan yang
akan memicu proyek tersebut. Misalnya suatu proyek dianggap layak untuk dilirik,
maka pada tahap pendefinisian ruang lingkup harus bisa dimantapkan rencana
proyek tersebut dalam hal skala proyek, strategi pengembangan, jadwal, kebutuhan
sumber daya, dan anggaran.
Tahap ini idealnya dilaksanakan dengan cepat. Seluruh tahapan tugas
seharusnya tidak melebihi dari dua atau tiga hari untuk hampir semua jenis proyek.
Tugas-tugas yang terdapat pada tahap ini dapat dilihat pada Gambar 4.5,
penjelasannya sebagai berikut:
a. Tugas 1.1 – Identifikasi Pokok Masalah dan Peluang
Salah satu tugas paling utama pada tahap definisi ruang lingkup adalah
menetapkan dasar awal dari masalah, peluang, dan arahan yang memicu proyek.

Universitas Esa Unggul


http://esaunggul.ac.id
10 / 38
Setiap masalah, peluang, dan arahan tersebut dinilai dengan memperhatikan
tingkat urgensi, visibilitas, manfaat nyata, dan prioritas.

Gambar 4.5. Tugas-tugas pada Tahap Definisi Ruang Lingkup dalam


Analisis Sistem

Pemimpin dari tugas ini adalah seorang analis sistem senior atau manajer
proyek. Peserta yang lainnya bisa diklasifikasikan sebagai pemilik sistem,
termasuk para sponsor eksekutif, yaitu para manajer yang akan membiayai dan
mendukung proyek. Pengguna, perancang, dan pengembang sistem tidak
terlibat pada tugas ini.
Hasil akhir utama dari tugas ini terdiri dari masalah, peluang dan arahan
yang sudah teridentifikasi. Contoh dari Pernyataan Masalah (Problem

Universitas Esa Unggul


http://esaunggul.ac.id
11 / 38
Statement) dapat dilihat pada Gambar 4.6, dimana pada contoh tersebut sudah
merangkum masalah, peluang, dan arahan terkait dengan beberapa hal berikut:
 Urgensi, yaitu rentang waktu dimana masalah harus bisa diselesaikan, atau
peluang atau arahan bisa disadari. Bisa menggunakan rentang skala yang
jelas untuk mengisinya.
 Visibilitas, yaitu level dari solusi atau sistem baru bisa dilihat oleh
pelanggan dan atau manajemen eksekutif. Bisa menggunakan rentang skala
yang jelas untuk mengisinya.
 Keuntungan, yaitu perhitungan yang tepat mengenai seberapa banyak solusi
atau sistem baru dapat meningkatkan pendapatan tahunan atau mengurangi
biaya tahunan. Diisi dengan menggunakan perkiraan yang paling rasional.
 Prioritas, berdasarkan isian sebelumnya, apakah prioritas secara konsensus
untuk setiap masalah, peluang, dan arahan.

Gambar 4.6. Contoh Problem Statement (Pernyataan Masalah)

Universitas Esa Unggul


http://esaunggul.ac.id
12 / 38
 Solusi yang diusulkan, dimana pada tahap awal suatu proyek, kemungkinan
solusi yang ada dinyatakan menggunakan istilah yang seerhana, misalnya
(a) dibiarkan saja apa adanya; (b) diperbaiki dengan cepat; (c) buat
peningkatan sedang untuk sistem yang ada; (d) rancang ulang sistem yang
ada; dan (e) rancang sistem baru.

Lembar pernyataan masalah yang sudah diisi nantinya akan disimpan di


dalam repositori sebagai dokumen penting.

b. Tugas 1.2 – Negosiasi Dasar Ruang Lingkup


Ruang lingkup menentukan batasan dari proyek, yaitu aspek-aspek bisnis
apa saja yang akan dimasukkan atau tidak ke dalam proyek. Ruang lingkup bisa
berubah selama berjalannya proyek, namun perencanaan awal proyek harus
memperjelas ruang lingkup awal dan sebagai landasan dasar awal. Sehingga
ketika terjadi perubahan yang signifikan terhadap ruang lingkup, semua pihak
yang terlibat bisa memahami dengan lebih baik terhadap perubahan jadwal dan
anggaran.
Pemimpin dari tugas ini adalah seorang analis sistem senior atau manajer
proyek. Peserta yang lainnya bisa diklasifikasikan sebagai pemilik sistem,
termasuk para sponsor eksekutif, yaitu para manajer yang akan membiayai dan
mendukung proyek. Pengguna, perancang, dan pengembang Sistem tidak
terlibat pada tugas ini.
Pada tugas ini digunakan lembar formulir penyataan masalah sebagai dasar
proses negosiasi. Hasil akhirnya berupa Pernyataan Ruang Lingkup Proyek,
yang akan disimpan di dalam repositori.
Ruang lingkup proyek dapat dijelaskan dalam beberapa hal berikut:
 Tipe data pada sistem yang sedang dipelajari. Misalnya, sebuah Sistem
Informasi Penjualan akan membutuhkan data tentang pelanggan, pesanan,
produk, dan staf sales.
 Proses bisnis yang termasuk dalam sistem yang sedang dipelajari. Misalnya,
sebuah Sistem Informasi Penjualan akan menyertakan proses bisnis seperti
Manajemen Katalog, Manajemen Pelanggan, Pesanan Masuk, Pemenuhan

Universitas Esa Unggul


http://esaunggul.ac.id
13 / 38
Pesanan, Manajemen Pesanan, dan Customer Relatioship Management
(CRM) atau Manajemen Hubungan Pelanggan.
 Interaksi sistem dengan pengguna, lokasi, dan sistem lainnya. Misalnya,
potensi interaksi yang terjadi pada Sistem Informasi Penjualan bisa
menyertakan pelanggan, staf sales, manajer dan administrasi penjualan,
kantor penjualan regional, piutang, dan Sistem Informasi pengendalian
persediaan.

Teknik yang digunakan untuk penyelesaian tugas ini adalah pencarian fakta
dan pertemuan.

c. Tugas 1.3 – Penilaian Kelayakan Dasar Proyek


Pada tahapan tugas ini muncul pertanyaan awal “Apakah proyek ini layak
untuk dijalankan?”. Pada tahapan awal, jawaban pertanyaan tersebut hanya
akan berupa perkiraan terbaik. Karena masih belum memungkinkan untuk
melakukan analisis kelayakan secara menyeluruh hanya dengan mengandalkan
informasi yang sudah diperoleh pada tahap awal.
Seorang analis sistem senior atau manajer proyek yang akan memimpin
tugas ini, namun pemilik sistem, sponsor eksekutif, manajer masing-masing
unit bisnis, dan manajer Sistem Informasi yang akan membuat keputusan.
Hasil akhir pada tahapan tugas ini adalah keputusan terhadap keberlanjutan
proyek. Proyek bisa saja disetujui atau ditolak, dan ruang lingkup proyek bisa
dinegosiasikan ulang (ditambah atau dikurangi).

d. Tugas 1.4 – Mengembangkan Jadwal dan Anggaran Dasar


Setelah suatu proyek dianggap layak untuk dilanjutkan, maka tahap
selanjutnya adalah merencanakan proyek lebih dalam. Rencana awal proyek
sebaiknya meliputi beberapa hal berikut:
 Rencana Induk awal yang menyertakan jadwal dan penugasan sumber daya
untuk keseluruhan proyek. Rencana ini akan diupdate di setiap akhir
tahapan pada proyek. Disebut juga dengan rencana dasar.

Universitas Esa Unggul


http://esaunggul.ac.id
14 / 38
 Rencana rinci dan jadwal untuk menyelesaikan tahap selanjutnya pada
proyek.

Tahapan tugas ini menjadi tanggung jawab manajer proyek. Biasanya


manajer proyek sebisa mungkin akan mengikutsertakan hampir keseluruhan tim,
termasuk pemilik sistem, pengguna, perancang, dan pengembang.
Hasil akhir dari tahapan tugas ini adalah Rencana dan Jadwal Proyek Dasar,
yang akan disimpan di dalam repositori.

e. Tugas 1.5 – Komunikasi Rencana Proyek


Sebagian besar perusahaan menggunakan sebuah Dewan Pengarah untuk
menyetujui dan mengawasi sebuah proyek. Dewan Pengarah adalah sebuah
komite khusus yang terdiri dari Direksi dan Manajer dari setiap bagian dan
sistem di perusahaan yang mempelajari dan menentukan prioritas terhadap
seluruh proposal proyek yang diajukan untuk dipilih menjadi proyek yang akan
memberikan keuntungan terbaik bagi perusahaan, dan yang layak untuk
menjadi sistem yang akan dikembangkan secara berkelanjutan.
Mayoritas Dewan Pengarah beranggotakan para profesional atau manajer
yang bukan membidangi Sistem Informasi. Manajer Sistem Informasi
bertanggung jawab kepada Dewan Pengarah hanya terkait dengan menjawab
pertanyaan dan mengkomunikasikan prioritas yang ada kepada pengembang
dan Manajer Proyek.
Terlepas dari sebuah proyek memerlukan persetujuan dari Dewan Pengarah,
merupakan sebuah hal yang penting untuk sebuah proyek diluncurkan secara
resmi, dan tujuan dan jadwal proyek dikomunikasikan kepada seluruh bagian
perusahaan. Membuka jalur komunikasi termasuk salah satu hal penting dalam
tahapan penyelidikan awal. Salah satu cara yang bisa diterapkan adalah dengan
mengadakan “Kickoff Meeting” dan membuat sebuah Website Intranet terkait
Proyek. “Kickoff Meeting” proyek yang akan berjalan terbuka untuk seluruh
bagian di perusahaan, bukan hanya unit bisnis yang merasakan secara langsung
dan tim proyek. Website Intranet terkait proyek memunculkan sebuah portal

Universitas Esa Unggul


http://esaunggul.ac.id
15 / 38
komunikasi untuk lingkungan internal perusahaan yang berisi berita dan
dokumentasi yang tidak sensitif terkait proyek.

4. Tahap Analisis Masalah


Tahap Analisis Masalah memberikan kesempatan kepada analis sistem
untuk dapat memahami lebih menyeluruh terhadap masalah, peluang, dan atau
arahan yang memicu pelaksanaan proyek. Tahap ini akan menjawab pertanyaan:
“Apakah masalah yang ada layak untuk diselesaikan?”; dan “Apakah sistem yang
baru layak untuk dibangun?”.
Tujuan akhir dari tahap analisis masalah adalah untuk mempelajari dan
memahami terhadap domain masalah yang cukup baik untuk digunakan
menganalisa secara menyeluruh masalah, peluang, dan batasan. Dan hasil akhirnya
berupa Objektif Pengembangan Sistem.
Tahap Analisis Masalah bisa berlangsung dari satu hingga enam minggu,
tergantung dari ukuran sistem, kompleksitasnya dan tingkat kelayakan proyek.
Tugas-tugas yang terdapat pada tahap ini dapat dilihat pada gambar 4.7,
penjelasannya sebagai berikut:
a. Tugas 2.1 – Pemahaman Domain Masalah
Pada tahap Analisis Masalah, tim pelaksana proyek berusaha untuk
mempelajari sistem yang berjalan. Baik pemilik, pengguna, maupun analis
sistem memiliki tingkat pemahaman masing-masing terhadap sistem, termasuk
perbedaan dalam hal detil, khazanah, persepsi, dan pendapat. Oleh karena itu
sangat penting untuk mempelajari dan memahami terlebih dahulu domain
masalah, yaitu domain dimana terdapat masalah, peluang, arahan, dan batasan
yang dimiliki perusahaan.
Tahapan tugas ini akan dipimpin oleh Manajer Proyek dengan difasilitasi
oleh Ketua Analis Sistem. Analis sistem yang lain juga terlibat dalam tahap ini
terutama untuk tugas wawancara, mencatat hasil pertemuan, dan temuan-
temuan dokumen. Penelitian yang komprehensif diperlukan untuk menyertakan
perwakilan dari pemilik dan pengguna sistem dari seluruh bagian di perusahaan
yang akan didukung atau terdampak oleh sistem maupun proyek. Keterlibatan
perancang dan pengembang sistem sangat jarang pada tahap tugas ini, kecuali

Universitas Esa Unggul


http://esaunggul.ac.id
16 / 38
sebagai narasumber untuk diwawancarai mengenai batasan-batasan teknis dari
sistem yang berjalan.

Gambar 4.7. Tugas-tugas pada Tahap Analisis Masalah dalam Analisis


Sistem

Pada Gambar 4.7 dapat dilihat tahapan tugas ini dipicu oleh persetujuan
untuk menjalankan proyek dari tahap definisi ruang lingkup. Persetujuan
tesebut datang dari Pemilik Sistem atau Dewan Pengarah. Masukan informasi
utamanya adalah Anggaran Dasar (AD) Proyek dan Dokumentasi Sistem yang
terdapat di dalam repositori dan perpustakaan program untuk sistem yang
berjalan. Hasil akhir dari tahapan tugas ini adalah pemahaman terhadap domain
masalah dan khazanah bisnis, yang kemudian akan disimpan di dalam repositori.

Universitas Esa Unggul


http://esaunggul.ac.id
17 / 38
Diagram Konteks
Tujuan dari diagram konteks adalah untuk menganalisa interaksi sistem
dengan dunia di sekitarnya dan menentukan kondisi umum dari input dan output
sistem. Diagram konteks merupakan tahap awal Diagram Alir Data (DAD) atau
Data Flow Diagram (DFD). Diagram konteks dapat digambarkan dalam
berbagai cara. Salah satu contoh dari bentuk diagram konteks dapat dilihat pada
Gambar 4.8. Diagram konteks pada gambar tersebut menggunakan pendekatan
hybrid, yaitu dengan menggunakan simbol Use Case.

Gambar 4.8. Contoh Diagram Konteks

Pada gambar di atas, figur stik yang berada di sekitar luaran diagram adalah
orang, organisasi, dan Sistem Informasi lainnya yang akan berinteraksi dengan
sistem. Pada Use Case, figur stik ini disebut aktor. Sedangkan pada diagram
konteks tradisional disebut agen eksternal. Garis dengan tanda panah menuju

Universitas Esa Unggul


http://esaunggul.ac.id
18 / 38
sistem disebut input yang disediakan oleh aktor atau agen eksternal, dan garis
dengan tanda panah merupakan output yang dihasilkan sistem. Setiap input dan
output ditulis dengan kata benda yang mendeskripsikannya. Hanya terdapat satu
input dan satu output untuk masing-masing aktor atau agen eksternal.
Untuk membuat sebuah diagram konteks, yang harus dilakukan adalah
menanyakan kepada pengguna tentang transaksi bisnis yang harus direspon oleh
sistem, dalam hal ini sebagai input. Dan juga menanyakan tentang laporan,
notifikasi, dan output lainnya yang harus dihasilkan oleh sistem.
Sebuah Sistem Informasi tidak bisa dibangun begitu saja dari sebuah
diagram konteks, namun diagram konteks bisa dijadikan pijakan awal yang
mantap untuk merancang sebuah sistem. Dari diagram konteks, dapat diketahui
input yang harus direspon sistem dan output yang harus dihasilkan sistem.
Dengan kata lain, mempermudah dalam mempelajari domain masalah.

b. Tugas 2.2 – Analisa Masalah dan Peluang


Untuk lebih memahami kondisi sistem yang sedang berjalan, tim pelaksana
proyek harus bekerjasama dengan pemilik dan pengguna sistem untuk
menganalisa masalah dan peluang. Pada dasarnya masalah dan peluang sudah
diidentifikasi pada tahap penyelidikan awal, namun masalah-masalah awal
tersebut hanya merupakan gejala dari masalah yang lain.
Dalam prosesnya, analis sistem menganalisa seluruh permasalahan sistem
baik yang terlihat secara ekplisit maupun yang dirasakan berdasarkan intuisi
dengan mengaitkannya dengan sebab akibat. Analisa sebab akibat dapat
memberikan pemahaman yang sesungguhnya dari suatu masalah dan bisa
mengarahkan kepada sebuah solusi yang lebih kreatif dan berharga.
Tahapan tugas ini difasilitasi oleh analis sistem, namun pemilik dan
pengguna sistem harus berperan serta aktif dalam proses analisa sebab akibat.
Perancang dan pengembang sistem tidak terlalu terlibat pada tahapan tugas ini
kecuali mereka diminta untuk menganalisa masalah teknis yang kemungkinan
akan muncul pada sistem yang berjalan.
Tahapan tugas ini dipicu oleh Domain Sistem dan Khazanah Bisnis. Input-
nya adalah Pernyataan Masalah awal (dari tahap ruang lingkup). Hasil akhir dari

Universitas Esa Unggul


http://esaunggul.ac.id
19 / 38
tahapan tugas ini adalah Pernyataan Masalah yang sudah diupdate dan hasil
Analisa Sebab Akibat untuk setiap masalah dan peluang. Salah satu contoh cara
pendokumentasi analisa sebab akibat dapat dilihat pada Gambar 4.9.

Gambar 4.9. Contoh Analisa Sebab Akibat

c. Tugas 2.3 – Analisa Proses Bisnis


Tahapan tugas ini hanya cocok untuk proyek Business Process Redesign
(BPR) atau proyek pengembangan sistem yang berdasarkan atau memerlukan
BPR. Pada kedua jenis proyek tersebut, tim pelaksana proyek harus memeriksa
keseluruhan proses bisnis hingga detail terkecil untuk dapat mengukur nilai
tambah atau nilai yang hilang dari setiap proses terkait dengan proses di sebuah
perusahaan.

Universitas Esa Unggul


http://esaunggul.ac.id
20 / 38
Tahapan tugas ini difasilitasi oleh satu orang atau lebih analis sistem. Analis
sistem tersebut harus orang yang berpengalaman, terlatih, atau bersertifikat
dalam metode BPR. Peserta yang lain adalah pemilik dan pengguna sistem.
Analisis proses bisnis harus sebisa mungkin menghindari godaan terhadap
solusi yang berfokus pada teknologi informasi, terutama sampai seluruh proses
bisnis selesai dirancang ulang pada kondisi efisiensi terbaik.
Hasil akhir dari tahapan tugas ini adalah Model Proses dan Model Analisis
bisnis apa adanya. Model prosesnya bisa berupa menyerupai DFD namun
terdapat keterangan tambahan berupa:
1) Volume data yang mengalir di dalam proses
2) Waktu respon setiap proses
3) Semua delay atau bottleneck yang kemungkinan muncul di dalam sistem

Proses analisis data menyediakan informasi tambahan seperti:


1) Biaya setiap proses
2) Nilai tambah yang diberikan oleh setiap proses
3) Konsekuensi dari pengurangan atau perampingan proses

d. Tugas 2.4 – Penetapan Tujuan Perbaikan Sistem


Tujuan dari tahapan tugas ini adalah untuk menetapkan kriteria untuk
mengukur setiap peningkatan dan untuk mengidentifikasi kendala yang dapat
membatasi fleksibilitas dalam mencapai peningkatan tersebut. Kriteria
keberhasilan dapat diukur dalam bentuk Objektif atau Tujuan. Objektif
merepresentasikan percobaan awal dalam menetapkan ekspektasi dari sistem
baru. Untuk menentukan objektif, harus diikuti dengan mengidentifikasi
kendala. Kendala akan memberikan batasan dalam mencapai objektif. Contoh
dari kendala misalnya tenggat waktu, anggaran, dan teknologi yang diperlukan.
Seorang analis sistem akan menjadi fasilitator untuk tahapan tugas ini.
Peserta lainnya adalah pemilik dan pengguna sistem yang telah turut serta pada
tahapan tugas sebelumnya. Perancang dan pengembang sistem tidak terlibat
dalam tahap ini.

Universitas Esa Unggul


http://esaunggul.ac.id
21 / 38
Objektif pengembangan sistem harus seakurat mungkin, pernyataan kinerja
perusahaan harus bisa diukur sesuai dengan ekspektasi dari sistem yang baru.
Beberapa contoh hasil dari tahapan tugas ini, yaitu berupa objektif, adalah
sebagai berikut:
 Mengurangi jumlah akun pelanggan yang tidak tertagih hingga 50% dalam
tahun depan
 Meningkatkan permohonan pinjaman yang bisa diproses hingga 25%
selama shift delapan jam
 Menurunkan hingga 50% waktu yang diperlukan untuk penjadwalan ulang
lot produksi saat terjadi masalah pada stasiun kerja

Berikut ini salah satu contoh yang salah dalam membuat objektif:
 Membuat laporan akun yang menunggak
Contoh tersebut salah karena hanya menyatakan kebutuhan, bukan objektif
sesungguhnya. Contoh tersebut bisa dirubah menjadi objektif yang benar
dengan merubah kata-kata yang digunakan, misalnya:
 Mengurangi kerugian kredit hingga 20 persen melalui identifikasi rekening
tunggakan yang telah dilakukan sebelumnya
Dengan begini akan memberikan fleksibilitas yang lebih. Walaupun laporan
akun yang menunggak akan bisa dilakukan, namun dengan menyelidiki
tunggakan pelanggan akan memberikan cara yang lebih baik dalam mencapai
objektif yang sama.

Objektif perbaikan sistem dapat diredam oleh kendala yang dapat


diidentfikasi. Kendala dapat dibagi ke dalam empat kategori, yaitu:
 Jadwal. Misal: Sistem yang baru harus bisa beroperasi pada tanggal 15
April.
 Biaya. Misal: Biaya sistem yang baru tidak boleh melebihi Rp. 1 Milyar
 Teknologi. Misal: Sistem yang baru harus online, atau Sistem yang baru
harus menggunakan sistem manajemen database.
 Kebijakan. Misal: Sistem yang baru harus menggunakan teknik persediaan
saldo menurun ganda.

Universitas Esa Unggul


http://esaunggul.ac.id
22 / 38
e. Tugas 2.5 – Perbaharui atau Perbaiki Rencana Proyek
Berdasarkan jadwal dan anggaran pokok yang telah ditetapkan sebelumnya,
ruang lingkup proyek bisa berkembang atau berkurang dari segi ukuran dan
kompleksitas. Oleh karena itu, ruang lingkup proyek sebaiknya dievaluasi ulang
dan dilakukan pembaharuan atau perbaikan terhadap rencana proyek yang
sesuai.
Pada tahapan ini manajer proyek bersama-sama dengan pemilik sistem dan
seluruh anggota tim menjadi fasilitator. Analis dan pemilik sistem harus
mempertimbangkan kemungkinan bahwa tidak semua objektif akan diperoleh
dari sistem yang baru. Hal ini dimungkinkan karena sistem yang baru ternyata
lebih besar dari perkiraan awal, dan harus dilakukan penyesuaian terhadap
ruang lingkup proyek untuk bisa sesuai dengan deadline. Dalam hal ini pemiliki
sistem harus melakukan perankingan objektif berdasarkan tingkat
kepentingannya.
Tahapan tugas ini dipicu oleh penyelesaian dari Objektif Pengembangan
Sistem. Input kunci lainnya adalah Rencana Awal Proyek, dan output kuncinya
adalah Rencana Proyek yang Diperbaharui.

f. Tugas 2.6 – Penyampaian Temuan dan Rekomendasi


Hasil akhir dari tahap analisis masalah harus dikomunikasikan kepada
seluruh elemen perusahaan. Manajer proyek dan sponsor eksekutif bersama-
sama menjadi fasilitator pada tahap ini. Website intranet yang telah dibuat
sebelumnya sebagai media komunikasi proyek, harus selalu diupdate untuk
perkembangan pelaksanaan proyek.
Tahapan tugas ini dipicu oleh penyelesaian Update Rencana Proyek. Input
dalam bentuk informasi menyertakan masalah yang dianalisa, model sistem,
objektif perbaikan sistem, dan dokumentasi apapun yang dihasilkan selama
tahap analisis masalah. Hasil akhir utama dari tahap analisis masalah adalah
Objektif Perbaikan Sistem yang merupakan gabungan dari elemen-elemen yang
tepat. Formatnya bisa dalam bentuk laporan tertulis, presentasi verbal, atau
inspeksi oleh internal auditor. Contoh kerangka laporan tertulis dapat dilihat
pada Gambar 4.10.

Universitas Esa Unggul


http://esaunggul.ac.id
23 / 38
Analisis Sistem ……………

I. Ringkasan Eksekutif (2 halaman)


A. Ringkasan rekomendasi
B. Ringkasan masalah, peluang, dan arahan
C. Pernyataan singkat objektif pengembangan sistem
D. Penjelasan singkat isi laporan
II. Informasi latar belakang (2 halaman)
A. Daftar wawancara dan kesimpulan pertemuan kelompok
B. Daftar informasi lain yang ditemukan
C. Deskripsi teknik analisis yang digunakan
III. Gambaran sistem saat ini (5 halaman)
A. Implikasi strategis (bila proyek merupakan bagian atau
mempengaruhi rencana strategis sistem informasi saat ini)
B. Model sistem saat ini
1. Model antarmuka (memperlihatkan ruang lingkup proyek)
2. Model data (memperlihatkan ruang lingkup proyek)
3. Model geografik (memperlihatkan ruang lingkup proyek)
4. Model proses (memperlihatkan ruang lingkup proyek)
IV. Analisis sistem saat ini (5 – 10 halaman)
A. Kinerja terkait masalah, peluang, dan analisis sebab akibat
B. Informasi terkait masalah, peluang, dan analisis sebab akibat
C. Ekonomi terkait masalah, peluang, dan analisis sebab akibat
D. Pengendalian terkait masalah, peluang, dan analisis sebab akibat
E. Efisiensi terkait masalah, peluang, dan analisis sebab akibat
F. Layanan terkait masalah, peluang, dan analisis sebab akibat
V. Rekomendasi terperinci (5 – 10 halaman)
A. Objektif dan prioritas perbaikan sistem
B. Kendala
C. Rencana proyek
1. Penilaian ulang dan perbaikan ruang lingkup
2. Revisi rencana induk
3. Rencana rinci untuk fase definisi
VI. Lampiran
A. Seluruh model sistem terperinci yang digunakan
B. Dokumen lain yang sesuai

Gambar 4.10. Contoh Kerangka Laporan Objektif Perbaikan Sistem dan


Rekomendasi

Pada akhir dari tahap analisis masalah, salah satu dari keputusan di bawah
ini harus dipilih berdasarkan kesimpulan dari tahap ini:
 Proyek diijinkan untuk dilanjutkan apa adanya ke tahap analisis kebutuhan.
 Dilakukan penyesuaian terhadap ruang lingkup, biaya, dan atau jadwal proyek
dan kemudian dilanjutkan ke tahap analisis kebutuhan.
 Membatalkan proyek dikarenakan (1) kurangnya sumber daya untuk
mengembangkan proyek lebih jauh; (2) masalah dan peluang yang ada ternyata

Universitas Esa Unggul


http://esaunggul.ac.id
24 / 38
tidak terlalu penting seperti yang diharapkan di awal; atau (3) keuntungan yang
diperoleh dari sistem yang baru tidak akan melebihi dari biaya yang
dikeluarkan.

5. Tahap Analisis Kebutuhan


Tahap Analisis Kebutuhan akan mendefinisikan kebutuhan bisnis untuk
sistem yang baru. Tahap ini akan menjawab pertanyaan: “Apakah yang dibutuhkan
dan diinginkan oleh pengguna pada sistem yang baru?”. Tahap analisis kebutuhan
memiliki peranan yang sangat penting dalam mensukseskan Sistem Informasi yang
baru. Tahap ini tidak bisa diabaikan, karena sistem yang baru akan terus dievaluasi,
baik sistem tersebut berhasil atau tidak memenuhi objektif dan kebutuhan
perusahaan, terlepas dari seberapa bagus dan kompleks solusi teknologi yang
dgunakan.
Tugas-tugas dalam tahap analisis kebutuhan diperlihatkan pada Gambar
4.11. Hasil akhir dari tahap ini adalah Pernyataan Kebutuhan Perusahaan yang
akan melengkapi objektif perbaikan sistem pada tahap sebelumnya. Berikut ini
penjelasan dari tugas-tugas tersebut:
a. Tugas 3.1 – Identifikasi dan Pernyataan Kebutuhan Sistem
Tahapan tugas awal dari tahap analisis kebutuhan ini terlihat mudah, namun
pada kenyataannya seringkali menjadi sumber dari berbagai kesalahan,
kelalaian dan konflik. Fondasi dari tahapan tugas ini terdapat pada tahap analisis
masalah, yaitu objektif perbaikan sistem. Tahapan tugas ini akan
menterjemahkan objektif yang sudah ditetapkan menjadi kerangka kebutuhan
fungsional dan non-fungsional yang diperlukan agar sesuai dengan objektif.
Kebutuhan fungsional adalah deskrispi dari aktivitas dan layanan sistem yang
harus disediakan. Kebutuhan fungsional seringkali diidentifikasi sebagai input,
output, proses dan data yang disimpan yang dibutuhkan untuk menyesuaikan
dengan objektif perbaikan sistem. Kebutuhan non-fungsional adalah deskripsi
dari fitur-fitur, karakteristik, dan kendala lainnya yang mendefinisikan
kepuasan terhadap sistem. Contoh dari kebutuhan non-fungsional misalnya
kinerja (hasil dan waktu respon); kemudahan dalam mempelajari dan
menggunakan; anggaran, biaya, dan penghematan biaya; jadwal dan tenggat

Universitas Esa Unggul


http://esaunggul.ac.id
25 / 38
waktu; dokumentasi dan kebutuhan training; manajemen kualitas; dan
keamanan dan pengendalian audit internal.

Gambar 4.11. Tugas-tugas pada Tahap Analisis Kebutuhan dalam Analisis


Sistem

Analis sistem sebagai fasilitator tahap tugas ini, dan mendokumentasikan


hasilnya. Pengguna sistem sebagai sumber informasi utama dari kebutuhan
perusahaan. Peran dari pemilik sistem adalah menentukan kerangka objektif
perbaikan sistem yang akan mengarahkan penyelesaian tugas. Perancang dan
pengembang sistem tidak perlu terlibat pada tahap tugas ini, karena cenderung
akan mengarahkan perhatian kepada solusi teknis dan teknologi.

Universitas Esa Unggul


http://esaunggul.ac.id
26 / 38
Pemicu dari tahap tugas ini adalah persetujuan terhadap keberlanjutan
pelaksanaan proyek dari tahap analisis masalah. Input kuncinya adalah objektif
perbaikan sistem dari tahap analisis masalah (melalui repositori). Hasil akhir
dari tahapan tugas ini adalah draf kebuthan fungsional dan non-fungsional.
Dalam format yang paling sederhana, garis besarnya dapat dibagi menjadi
empat bagian logis, daftar asli objektif perbaikan sistem dimana untuk setiap
objektif terdapat sub daftar yaitu (a) input, (b) proses, (c) output, dan (d) data
yang disimpan untuk memenuhi tujuan.

b. Tugas 3.2 – Penentuan Prioritas Kebutuhan Sistem


Penentuan priotitas kebutuhan sistem dapat difasilitasi dengan
menggunakan teknik Timeboxing. Timeboxing adalah teknik yang digunakan
untuk menyampaikan fungsionalitas dan kebutuhan sistem informasi
berdasarkan versi. Timeboxing mencoba memecah kebutuhan-kebutuhan
sistem menjadi “bongkahan” yang bisa diimplementasikan ke dalam periode
waktu yang tidak membebani kesabaran kelompok pengguna dan manajer.
Analis sistem memfasilitasi tugas penentuan prioritas. Pemilik dan
pengguna sistem yang menentukan prioritas aktualnya. Perancang dan
pengembang sistem tidak terlibat pada tahap tugas ini. Tahapan tugas ini dipicu
oleh kebutuhan yang telah divalidasi. Hasil akhirnya adalah Kebutuhan dengan
Prioritas. Prioritas bisa diklasifikasikan berdasarkan tingkat kepentingannya,
yaitu:
 Kebutuhan wajib, yaitu kebutuhan yang harus dipenuhi oleh sistem
walaupun dengan kondisi paling minimal. Karena sistem akan menjadi tidak
berarti tanpa kebutuhan tersebut. Kebutuhan wajib tidak dapat dirangking
karena sangat diperlukan untuk semua jenis solusi.
 Kebutuhan yang diinginkan, yaitu kebutuhan yang tidak terlalu penting bagi
sistem. Walaupun cukup penting bagi perkembangan sistem di masa depan.
Kebutuhan ini bisa dan seharusnya dirangking, untuk mengetahui
prioritasnya.

Universitas Esa Unggul


http://esaunggul.ac.id
27 / 38
c. Tugas 3.3 – Perbaharui atau Perbaiki Rencana Proyek
Setelah kebutuhan sistem perusahaan dapat diidentifikasi, maka sebaiknya
dilakukan pendefinisian ulang pemahaman terhadap ruang lingkup proyek dan
melakukan update yang sesuai terhadap proyek.
Pada tahapan ini manajer proyek bersama-sama dengan pemilik sistem dan
seluruh anggota tim menjadi fasilitator. Manajer dan pemiliki sistem memiliki
peran penting pada tahap tugas ini. Mereka harus mempertimbangkan
kemungkinan bahwa kebutuhan saat ini berkembang melebihi visi asli yang
telah ditetapkan untuk proyek dan sistem yang baru. Kemungkinannya harus
dilakukan penyesuaian terhadap ruang lingkup proyek untuk bisa sesuai dengan
deadline.
Tahapan tugas ini dipicu oleh penyelesaian dari Kebutuhan dan Prioritas
Sistem. Input kunci lainnya adalah Rencana Proyek yang up-to-date, dan di-
update juga di dalam repositori.

d. Tugas 3.4 – Penyampaian Pernyataan Kebutuhan


Komunikasi adalah tugas yang selalu berlangsung selama tahap analisis
kebutuhan. Kebutuhan dan prioritas harus selalu disampaikan kepada seluruh
bagian di perusahaan selama proses tahap ini berjalan. Untuk
mengkomunikasikannya bisa melalui website intranet atau portal perusahaan.
Beberapa sistem memberikan fitur subscribe agar pengguna dan manajer bisa
selalu memperoleh notifikasi ketika terjadi perubahan.

6. Tahap Perancangan Logika


Perancangan logika melanjutkan dokumen kebutuhan bisnis dengan
menggunakan model sistem yang mengilustrasikan struktur data, proses bisnis,
aliran data, dan antar-muka pengguna. Tahapan tugas-tugas pada tahap
perancangan logika ini dapat dilihat pada Gambar 4.12, dimana penjelasannya
sebagai berikut:
a. Tugas 4.1a – Menyusun Kebutuhan Fungsional
Salah satu pendekatan pada perancangan logika adalah dengan menyusun
kebutuhan fungsional. Dengan menggunakan metode tangkas (agile method),

Universitas Esa Unggul


http://esaunggul.ac.id
28 / 38
satu atau lebih model sistem dilakukan pembaharuan untuk membuat ilustrasi
kebutuhan fungsional, yang melibatkan kombinasi data, proses, dan model
objek yang secara akurat menggambarkan kebutuhan bisnis dan pengguna
(namun bukan solusi teknis). Model sistem belum bisa dinyatakan lengkap
hingga semua kebutuhan fungsional yang sesuai telah dimodelkan.

Gambar 4.12. Tugas-tugas pada Tahap Perancangan Logika dalam Analisis


Sistem

Analis sistem menjadi fasilitator pada tahapan tugas ini, termasuk


mendokumentasikan hasilnya. Pengguna sistem memiliki peran sebagai sumber
informasi utama terhadap fakta-fakta terperinci yang digunakan untuk membuat

Universitas Esa Unggul


http://esaunggul.ac.id
29 / 38
model. Tahapan ini dipicu oleh setiap kebutuhan fungsional. Output-nya adalah
model sistem dan spesifikasi rinci aktual.

b. Tugas 4.1b – Kebutuhan Struktur Prototype (alternatif)


Prototyping bisa menjadi alternatif dalam memodelkan sistem. Prototyping
digunakan pada tahap analisis kebutuhan untuk membuat sampel input dan
output. Input dan output ini akan digunakan untuk membantu membangun
database dasar dan program untuk memasukkan dan mengeluarkan data yang
ke dalam dan dari database.
Pengembang sistem menjadi fasilitator pada tahapan tugas ini. Analis sistem
bertugas mendokumentasikan dan menganalisa hasilnya. Pengguna sistem
menjadi sumber informasi faktual.

c. Tugas 4.2 – Validasi Kebutuhan Fungsional


Baik model sistem maupun prototype merupakan representasi dari
kebutuhan-kebutuhan pengguna. Keduanya harus divalidasi untuk kelengkapan
dan ketepatan. Analis sistem memfasilitasi tugas penentuan prioritas secara
interaktif dengan mengajak pengguna sistem untuk mengidentifikasi kesalahan
dan kelalaian atau membuat klarifikasi.

d. Tugas 4.3 – Mendefinisikan Uji Kasus Penerimaan


Uji coba sistem bisa dilakukan pada tahapan awal proses pengembangan
sistem, walaupun bukan merupakan tugas yang dipersyaratkan. Model sistem
dan prototype secara efektif mendefinisikan kebutuhan pemrosesan, aturan data,
dan aturan bisnis untuk sistem yang baru. Spesifikasi ini bisa digunakan untuk
mendefinisikan uji kasus yang dapat digunakan untuk menguji program untuk
mencari kebenaran.

7. Tahap Analisis Keputusan


Setelah diperoleh kebutuhan bisnis untuk Sistem Informasi yang
ditingkatkan, langkah selanjutnya adalah menentukan bagaimana sistem yang baru
akan diimplementasikan dengan teknologi. Tujuan dari tahap analisis keputusan

Universitas Esa Unggul


http://esaunggul.ac.id
30 / 38
adalah untuk mengidentifikasi kandidat solusi, menganalisa setiap kandidat solusi,
dan merekomendasikan sistem yang ditargetkan untuk dirancang, dibangun, dan
diimplementasikan.

Gambar 4.13. Tugas-tugas pada Tahap Analisis Keputusan dalam Analisis


Sistem

Tahapan tugas-tugas pada tahap perancangan logika ini dapat dilihat pada
Gambar 4.13, dimana penjelasannya sebagai berikut:
a. Tugas 5.1 – Identifikasi Kandidat Solusi
Setelah diperoleh kebutuhan bisnis pada tahap pendefinisian dalam tahap
analisis sistem, tahap beritkunya adalah mengidentifikasi kandidat alternatif
solusi. Beberapa kandidat solusi bisa datang dari ide perancangan dan pendapat
dari pemilik dan pengguna sistem. Kandidat solusi lainnya bisa berasal dari

Universitas Esa Unggul


http://esaunggul.ac.id
31 / 38
sumber lainnya, termasuk analis sistem, perancan sistem, konsultan teknik, dan
tenaga IT profesional. Tujuan dari tahapan ini adalah bukan untuk menilai
setiap kandidat, namun untuk mendefinisikan setiap kemungkinan kandidat
yang ada untuk dipertimbangkan.
Fasilitator tahap tugas ini adalah analis sistem. Pemilik dan pengguna sistem
tidak terlibat secara langsung, namun bisa berkontribusi dengan memberikan
ide dan pendapat yang memulai tahapan tugas.
Tugas ini dipicu oleh persetujuan untuk keberlanjutan proyek dari tahap
analisis kebutuhan. Seluruh ide yang dimunculkan dianggap sebagai kandidat
solusi untuk kebutuhan bisnis.
Jumlah informasi yang mendeskripsikan karakteristik dari seluruh kandidat
solusi bisa sangat banyak. Untuk memudahkan proses pemilihan kandidat solusi
bisa menggunakan Matriks Kandidat yang bisa dilihat pada Tabel 4.1 di atas,
dimana alat ini akan sangat berguna untuk secara efektif menangkap,
mengorganisir dan membandingkan karakteristik dari kandidat solusi yang
berbeda.

b. Tugas 5.2 – Analisa Kandidat Solusi


Masing-masing kandidat solusi harus dianalisa untuk kelayakan. Hal ini
bisa dilakukan bila seluruh kandidat sudah teridentifikasi. Analisis kelayakan
tidak terbatas pada biaya dan keuntungan. Terdapat empat kriteria dalam
melakukan analisis kelayakan, yaitu:
1) Kelayakan Teknis
 Apakah solusi praktis secara teknis?
 Apakah karyawan perusahaan memiliki keahlian teknis untuk
merancang dan membangun solusi tersebut?
2) Kelayakan Operasional
 Apakah solusi akan sesuai dengan kebutuhan pengguna?
 Hingga sejauh apa?
 Bagaimana solusi akan mengubah lingkungan kerja pengguna?
 Apa yang dirasakan oleh pengguna terhadap solusi tersebut?

Universitas Esa Unggul


http://esaunggul.ac.id
32 / 38
3) Kelayakan Ekonomi
 Apakah solusi tersebut efektif dari segi biaya?
4) Kelayakan Jadwal
 Apakah solusi bisa dirancang dan diimplementasikan dalam waktu yang
ditetapkan?

Tabel 4.1. Matriks Kandidat Sistem


Karakteristik Kandidat 1 Kandidat 2 Kandidat 3 Kandidat n
Bagian dari Sistem Penjelasan singkat mengenai bagian yang akan
Terkomputerisasi terkomputerisasi pada setiap kandidat
Keuntungan Penjelasan singkat dari keuntungan bisnis yang akan
muncul dari setiap kandidat
Server dan Penjelasan tentang server dan workstation yang
Workstation diperlukan untuk mendukung setiap kandidat
Alat Software yang Alat software yang digunakan untuk merancang dan
Diperlukan membangun setiap kandidat (mis: manajemen sistem
database, emulator, sistem operasi (Windows, Mac, dll),
bahasa pemograman, dll.)
Tidak akan digunakan bila memilih membeli paket
software aplikasi
Software Aplikasi Penjelasan mengenai software yang akan dibeli,
dibangun, dinilai, atau kombinasi diantara ketiga teknik
tersebut
Metode Pemrosesan Kombinasi antara online, batch, batch yang tertunda,
Data batch jarak jauh, dan realtime
Alat untuk Output Deskripsi mengenai alat untuk menghasilkan output
dan Implikasinya yang akan digunakan, persyaratan output khusus (mis:
jaringan, formulir yang sudah dicetak, dll), dan
pertimbangan ouput (mis: kendala waktu)
Alat untuk Input Deskripsi mengenai metode input yang akan digunakan,
dan Implikasinya alat untuk memasukkan input (mis: keyboard, mouse,
dll), persyaratan khusus input (mis: formulir baru atau
yang direvisi dari data yang akan diinput),
pertimbangan masukan (misal: waktu yang tepat untuk
input aktual)
Alat untuk (Penjelasan singkat tentang data yang akan disimpan,
Penyimpanan dan data yang akan dinilai dari tempat penyimpanan, media
Implikasinya penyimpanan yang akan digunakan, kapasitas media
penyimpanan yang diperlukan, dan bagaimana data
akan diorganisir

Dalam proses penyelesaian tahapan tugas ini, yang harus diperhatikan


adalah analis dan pengguna agar tidak membandingkan tingkat kelayakan
antara setiap kandidat. Pada dasarnya analisis kelayakan dilakukan pada setiap
kandidat tanpa memperhitungkan kelayakan kandidat yang lain.
Analis sistem berperan sebagai fasilitator pada tahapan tugas ini. Pemilik
dan pengguna sistem akan menganalisa kelayakan operasional, ekonomi, dan

Universitas Esa Unggul


http://esaunggul.ac.id
33 / 38
jadwal. Perancang dan pengembang sistem akan berkontribusi dalam
melakukan analisa kelayakan teknis.
Tahapan tugas ini dipicu dari penyelesaian dari setiap kandidat solusi,
namun masih bisa diterima apabila terjadi penundaan, setidaknya hingga
seluruh kandidat solusi dapat teridentifikasi. Hasil dari analisis kelayakan
disimpan di dalam repositori.

c. Tugas 5.3 – Perbandingan Kandidat Solusi


Setelah analisis kelayakan untuk setiap kandidat selesai dilakukan, maka
langkah selanjutnya adalah membandingkan setiap kandidat dan memilih satu
atau lebih solusi untuk direkomendasikan ke pemilik dan pengguna sistem. Pada
tahap ini kandidat yang tidak layak akan langsung disisihkan, karena yang dicari
adalah kandidat solusi yang paling layak berdasarkan dari kombinasi analisis
kelayakan yang sudah dilakukan. Pada saat melakukan perbandingan tersebut,
belum tentu kandidat yang dipilih memiliki kelayakan paling baik dari masing-
masing jenis kelayakan.
Sebagai fasilitator pada tahapan tugas ini adalah analis sistem. Baik
perancang dan pengembang sistem harus bisa memberikan jawaban terhadap
pertanyaan dalam analisis kelayakan teknis. Pemilik dan pengguna sistem
sebaiknya diberi wewenang untuk menentukan analisis dan rekomendasi final.
Tahapan tugas ini dipicu oleh penyelesaian analisis kelayakan dari semua
kandidat solusi. Input-nya adalah seluruh hasil analisis kelayakan kandidat
solusi. Untuk mengatasi informasi yang sangat banyak dan beragam, bisa
menggunakan sebuah matriks sebagai alat bantu untuk komunikasi. Matriks
yang dimaksud adalah Matriks Analisis Kelayakan, bisa dilihat pada Tabel 4.2,
dimana pada matriks tersebut dapat dilihat perbandingan hasil analisis
kelayakan dari setiap kandidat solusi. Pada tabel tersebut disertakan contoh
kandidat.
Hasil dari tahapan tugas ini adalah Solusi yang direkomendasikan. Bila
terdapat lebih dari satu solusi, maka perlu ditentukan prioritasnya.

Universitas Esa Unggul


http://esaunggul.ac.id
34 / 38
Tabel 4.2. Matriks Analisis Kelayakan
Kriteria Kelayakan Bobot Kandidat 1 Kandidat 2 Kandidat 3 Kandidat n
Kelayakan Operasional 30% Hanya mendukung kebutuhan Sepenuhnya mendukung fungsionalitas Sama dengan kandidat 2
 Fungsionalitas layanan anggota, dan proses bisnis yang dibutuhkan pengguna
(Deskripsi seberapa baik kandidat akan saat ini harus dimodifikasi untuk
memberikan kebaikan untuk perusahaan dan memperoleh keuntungan dari
seberapa baik sistem akan bekerja) fungsionalitas software
 Politis
(Deskripsi seberapa baik penerimaan solusi
dari perspektif pengguna, manajemen, dan
perusahaan)
Nilai: 60 Nilai: 100 Nilai: 100
Kelayakan Teknis 30% Rilis produksi paket Platinum Plus Walaupun staff teknis saat ini hanya Walaupun staff teknis saat ini sudah
 Teknologi saat ini adalah versi 1.0 dan telah memiliki keahlian Powerbuilder, analis merasa nyaman dengan Powerbuilder,
(Penilaian kematangan, ketersediaan, dan berada di pasar selama 6 minggu. senior yang melihat demonstrasi dan pihak manajamen khawatir dengan
keinginan untuk menggunakan teknologi Kematangan produk beresiko, dan presentasi MS Visual Basic sepakat akuisisi Powerbuilder oleh Sybase
computer yang diperlukan untuk mendukung perusahaan mengenakan biaya bahwa transisi akan mudah dan mencari Inc. MS SQL Server adalah standar
kandidat) tambahan per bulan untuk programmer VB berpengalaman lebih yang dipakai perusahaan saat ini, dan
 Keahlian dukungan teknis. mudah daripada mencari programmer merupakan saingan dari Sybase di
(Penilaian keahlian teknis yang diperlukan Powerbuilder, dan biayanya lebih murah. pasar client/server DBMS.
untuk mengembangkan, mengoperasikan, dan Perlu untuk mempekerjakan atau Karena hal ini, perusahaan tidak
memelihara kandidat sistem) melatih ahli C++ untuk melakukan MS Visual Basic 5.0 kondisinya sudah memiliki jaminan atas versi terbaru
modifikasi untuk kebutuhan matang secara teknologi berdasarkan Powerbuilder akan cocok dengan
integrasi angka versi. versi SQL Server perusahaan saat ini.

Nilai: 50 Nilai: 95 Nilai: 60


Kelayakan Ekonomi 30%
 Biaya pengembangan $350,000 $418,040 $400,000
 Payback Period (diskonto) 4,5 tahun 3,5 tahun 3,3 tahun
 Net Present Value $210,000 $306,748 $325,500
 Perhitungan Lihat lampiran A Lihat lampiran A Lihat Lampiran A

Nilai: 60 Nilai: 85 Nilai: 90


Kelayakan Jadwal 10% Kurang dari 3 bulan 9 – 12 bulan 9 bulan
(Penilaian terhadap waktu yang diperlukan untuk
merancang dan mengimplementasikan sistem)
Nilai: 90 Nilai: 80 Nilai: 85
Ranking 100% 60,5 92 83,5

Universitas Esa Unggul


http://esaunggul.ac.id 35 / 38
d. Tugas 5.4 – Update Rencana Proyek
Sekali lagi harus dilakukan evaluasi ulang ruang lingkup proyek dan
melakukan update rencana proyek. Manajer proyek bersama pemilik sistem dan
seluruh tim pelaksana menjadi fasilitator tahap tugas ini. Karena pada tahap ini
sudah memasuki masa transisi proses perancangan sistem dari sisi teknis, maka
perlu untuk melibatkan perancang dan pengembang sistem.
Tahap tugas ini dipicu oleh penyelesaian dari solusi yang
direkomendasikan. Jadwal dan pembagian sumber daya terbaru harus direview
dan di-update. Output kunci tahap tugas ini adalah Rencana Proyek yang sudah
di-update.

e. Tugas 5.5 – Rekomendasi Solusi Sistem


Penutup pada tahap analisis keputusan adalah tugas komunikasi, dimana
solusi sistem yang sudah dipilih harus direkomendasikan kepada seluruh bagian
perusahaan.
Manajer proyek dan sponsor eksekutif bersama-sama menjadi fasilitator
tahapan tugas ini. Website intranet harus selalu di-update untuk semua
perkembangan proyek yang telah dilakukan agar bisa diketahui oleh seluruh
bagian perusahaan.
Tahapan tugas ini dipicu oleh penyelesaian Rencana Proyek yang sudah di-
update. Target solusi sistem diformat ulang untuk dipresentasikan sebagai
Proposal Sistem. Kerangka umum Proposal Sistem dapat dilihat pada Gambar
4.14.

C. Latihan
Jawablah pertanyaan di bawah ini untuk bahan latihan Anda.
1. Sebutkan lima tahap dalam analisis sistem?
2. Sebutkan lima tahapan tugas yang yang dilakukan pada tahap definisi ruang
lingkup?
3. Apakah yang dimaksud dengan analisis berdasarkan model? Mengapa
digunakan? Sebukan contohnya.

Universitas Esa Unggul


http://esaunggul.ac.id
36 / 38
D. Kunci Jawaban
Berikut ini jawaban pertanyaan di atas
1. Tahap dalam Analisis Sistem:
a. Definisi Ruang Lingkup
b. Analisis Masalah
c. Analisis Kebutuhan
d. Perancangan Logika
e. Analisis Keputusan

2. Tahapan tugas dalam tahap Definisi Ruang Lingkup:


a. Identifikasi Pokok Masalah dan Peluang
b. Negosiasi Ruang Lingkup Dasar
c. Penilaian Kelayakan Dasar Proyek
d. Mengembangkan Jadwal dan Anggaran Dasar
e. Komunikasi Rencana Proyek

3. Analisis Berdasarkan Model adalah pendekatan pemecahan masalah yang


menekankan pada penggambaran model sistem bergambar untuk
mendokumentasikan dan memvalidasi sistem yang sudah berjalan dan atau
yang akan diajukan.
Model sistem tersebut akan menjadi blueprint untuk merancang dan
membangun sebuah sistem yang ditingkatkan.
Contoh dari analisis berdasarkan model antara lain, analisis terstruktur,
rekayasa informasi, dan analisis beorientasi objek.

E. Daftar Pustaka
Brien, James O’. 2013. Introduction to Information System. 12th Edition. McGraw-
Hill/Irwin, New York
Whitten, Jeffrey L. & Lonnie D. Bentley. 2008. Introduction to System Analysis
and Design. McGraw-Hill/Irwin, New York

Universitas Esa Unggul


http://esaunggul.ac.id
37 / 38

Anda mungkin juga menyukai