Transcript Bab 7 Pengembangan Sistem

PENGEMBANGAN
SISTEM
Mengenal pendekatan sistem sebagai kerangka kerja
dasar pemecahan segala jenis masalah.
Mengetahui bagaimana cara menerapkan pendekatan
sistem untuk memecahkan masalah-masalah sistem.
Memahami bahwa siklus hidup pengembangan sistem
(system development life cycle—SDLC) merupakan
sebuah metodologi-suatu cara yang direkomendasikan
untuk mengembangkan sistem.
Mengenal pendekatan-pendekatan SDLC yang utama—
siklus air terjun tradisional. Prototyping, rapid
application development, pengembangan berfase, dan
desain ulang proses bisnis.
Mengetahui dasar-dasar proses pemodelan dengan
diagram arus data (data flow diagram) dan kasus-kasus
penggunaan (fase case).
Memahami bagaimana proyek-proyek pengembangan
sistem dikelola dengan cara dari atas ke bawah.
Mengenal proses-proses dasar pengestimasian biaya
proyek.
Baik manajer maupun para pengembang sistem dapat menerapkan
pendekatan sistem ketika memecahkan masalah. Pendekatan sistem
terdiri atas tiga tahapan kerja: Persiapan, definisi, dan solusi. Ketika
diterapkan pada masalah pengembangan sistem, pendekatan sistem ini
disebut siklus hidup pengembangan sistem (System Development Life
Cycle—SDLC). Pendekaan SDLC tradisional terdiri atas lima tahap yang
terjadi satu demi satu.
Prototyping adalah penyempurnaan dari pendekatan tradisional.
Pendekatan ini menyadari adanya keuntungan dari meminta permohonan
umpan balik dari pengguna berulang kali dan meresponnya dengan
perbaikan sistem dan tetap meneruskan siklus sampai Sistem memenuhi
kebutuhan para pengguna. Satu pendekatan filosofi prototyping bagi
pengembangan sistem-sistem berskala besar adalah Rapid Application
Development (RAD) atau pengembangan aplikasi cepat. Selain dari
menerapkan prototyping, RAD juga mendorong penggunaan pendekatanpendekatan lain, seperti penggunaan alat-alat pemodelan komputer dan
tim-tim khusus, yang dimaksudkan untuk mempercepat proses
pengembangan.
Satu pendekaan SDLC yang saat ini populer adalah pengembangan
berfase (phase development). Pendekatan ini didasarkan atas pemikiran
bahwa suatu proyek akan dibagi menjadi modul-modul dan analisis,
perancangan dan pekerjaan-pekerjaan konstruksi awal yang ditujukan
untuk setiap modul. Modul-modul ini kemudian diintegrasikan dalam
suatu pekerjaan konstruksi akhir.
Ketika terdapat kebutuhan untuk mengambil pendekatan yang sama
sekali baru untuk memperbaiki suatu sistem yang sudah ada, metodologi
desain ulang proses bisnis (Business Process Redesign) sering kali
dipergunakan. Istilah rekayasa ulang (reengineering) juga dipergunakan,
meskipun itu hanyalah salah satu aspek dari desain ulang proses bisnis.
Aspek yang lainnya adalah rekayasa terbalik (reverse engineering).
Diagram arus data atau Data Flow Diagram (DFD), telah menjadi alat
pemodelan yang paling populer selama kurang lebih 20 tahun terakhir.
DFD adalah cara yang sangat alamiah untuk mendokumentasikan proses
dan dapat dibuat dalam suatu hierarki untuk menyajikan berbagai
rincian. Meskipun DFD adalah alat yang baik untuk menggambarkan
tinjauan pemrosesan, DFD gagal memberikan hasil yang baik dalam
menampilkan detail pemrosesan. Alat-alat lainnya, seperti kasus-kasus
penggunaan (use case) dapat digunakan untuk menunjukan detail.
Sepanjang akhir tahun 1960 an dan awal 1970 an, minat akan pemecahan
masalah secara sistematis mulai menguat. Ilmuawan manajemen dan
spesialis informasi mencari cara-cara yang efisien dan efektif untuk
memecahkan masalah, dan kerangka kerja yang direkomendasikan
menjadi apa yang dikenal sebagai Pendekatan (sistem approach)serangkaian langkah-langkah pemecahan masalah yang memastikan
bahwa suatu masalah telah dipahami, solusi-solusi alternatif telah
dipertimbangkan, dan bahwa solusi yang dipiliah berhasil.
Urut-urutan Langkah
Meskipun banyak uraian mengenai pendekatan sistem mengikuti pola
dasar yang sama, namun jumlah langkahnya dapat bervariasi. Kita
menggunakan 10 langkah, yang dikelompokan menjadi tiga tahapan:
upaya persiapan, upaya definisi, dan upaya solusi, seperti yang
digambarkan pada figur 7.1
Tahapan I: Upaya persiapan
Langkah 1. Melihat perusahaan sebagai suatu sistem
Langkah 2. Mengenal sistem lingkungan
Langkah 3. Mengidentifikasikan subsistem-subsistem perusahaan
Tahapan II: Upaya definisi
Langkah 4. Melanjutkan dari tingkat sistem ke tingkat subsistem
Langkah 5. Menganalisis bagian-bagian sistem dalam suatu urutanurutan
tertentu
Tahapan III: Upaya solusi
Langkah 6.
Langkah 7.
Langkah 8.
Langkah 9.
Langkah 10.
Mengidentifikasikan solusi-solusi alternatif
Mengevaluasi solusi-solusi alternatif
Memilih solusi yang terbaik
Mengimplementasikan solusi
Menindaklanjuti untuk memastikan bahwa solusi tersebut
efektif
Pendekatan sistem merupakan sebuah metodologi. Metologi adalah
suatu cara yang direkomendasikan dalam melakukan sesuatu. Pendekatan
sistem adalah metodologi dasar dalam memecahkan segala jenis masalah.
Siklus hidup pengembangan sistem (system development life
cycle)—SDLC) adalah aplikasi dari pendekatan sistem bagi
pengembangan suatu sistem informasi.
SDLC TRADISIONAL
Jika suatu proyek ingin memiliki kemungkinan berhasil yang paling besar.
Tahapan-tahapan yang perlu dilakukuan yaitu:
• Perencanaan
• Analisis
• Desain
• Implementasi
• Penggunaan
Proyek direncanakan dan sumber-sumber daya yang dibutuhkan untuk
melakukan pekerjaankemudian disatukan. Sistem yang ada juga dianalisis
untuk memahami masalah dan menentukan persyaratan fungsional dari
sistem yang baru. Sistem baru ini kemudian dirancang dan
diimplementasikan. Setelah implementasi, sistem kemudian digunakan—
idealnya untuk jangka waktu yang lama.
Mudah bagi kita untuk melihat bagaimana SDLC tradisional dapat
dikatakan sebagai suatu aplikasi dari pendekatan sistem. Masalah akan
didefinisikan dalam tahap-tahap perencanaan dan analisis. Solusi-solusi
alternatif diidentifikasi dan dievaluasi dalam tahap desain. Lalu, solusi
yang terbaik diimplementasikandan digunakan. Selama tahap
penggunaan, umpan balik dikumpulkan untuk melihat seberapa baik
sistem mampu memecahkan masalah yang telah ditentukan.
PROTOTYPING
Dalam penerapannya pada pengembangan sistem, prototipe adalah satu
versi dari sebuah sistem potensial yang memberikan ide bagi para
pengembang dan juga calon pengguna, bagaimana sistem akan berfungsi
dalam bentuk yang telah selesai. Proses pembuatan prototipe ini disebut
prototyping. Dasar pemikirannya adalah membuat prototipe secepat
mungkin, bahkan dalam waktu semalam, lalu memperoleh umpan balik
dari pengguna yang akan memungkinkan prototipe tersebut diperbaiki
kembali dengan cepat.
Jenis-jenis Prototipe
Terdapat dua jenis prototipe: evolusioner dan persyaratan. Prototipe evolusioner
(evolutionary prototype) terus-menerus disempurnakan sampai memiliki
selurunh fungsionalitas yang dibutuhkan pengguna dati sistem yang baru.
Prototipe ini kemudian dilanjutkan ke produksi. Jadi, satu prototipe evolusioner
akan menjadi sistem aktual. Akan tetapi, prototipe persyaratan (requirements
prototype) dikembangkan sebagai satu cara untuk mendefinisikan persyaratanpersyaratan fungsional dari sistem baru ketika pengguna tidak mampu
mengungkapkan dengan jelas apa yang mereka inginkan. Dengan meninjau
prototipe persyaratan seiring dengan ditambahkannya fitur-fitur, pengguna akan
mampu mendefinisikan pemrosesan yang dibutuhkan dari sistem yang baru.
Ketika persyaratan ditentukan, prototipe persyaratan telah mencapai tujuannya
dan proyek lain akan dimulai untuk pengembangan sistem baru. Oleh karena itu,
Suatu prototipe persyaratan tidak selalu menjadi sistem aktual.
1.
Mengidentifika
si
Kebutuhan
pengguna
2.
Membuat
Sebuah
prototipe
3.
Apakah
Prototip
e dpt di
terima ?
Y
4.
Menggunakan
Prototipe
T
1
2
3
T
Y
4
5
6
Y
7
T
Daya Tarik Prototyping
Pengguna maupun pengembang menyukai prototyping karena alasanalasan di bawah ini:
• Membaiknya komunikasi antara pengembang dan pengguna.
• Pengembang dapat melakukan pekerjaan yang lebih baik dalam
menentukan kebutuhan pengguna.
• Pengguna memainkan peranan yang lebih aktif dalam pengembangan
sistem.
• Pengembang dan pengguna menghabiskan waktu dan usaha yang lebih
sedikit dalam mengembangkan sistem.
• Implementasi menjadi jauh lebih mudah karena pengguna tahu apa
yang diharapkannya.
• Keuntungan di atas memungkinkan prototyping memangkas biaya
pengembangan dan meningkatkan kepuasan pengguna atas sistem yang
diserahkan.
Potensi Kesulitan dari Prototyping
Prototyping bukannya tidak memiliki potensi kesulitan. Kesulitankesulitan tersebut antara lain:
• Terburu-buru dalam menyerahkan prototipe dapat menyebabkan
diambilnya jalan pintas dari definisi masalah, evaluasi alternatif, dan
dokumentasi.
• Pengguna dapat terlalu gembira dengan prototipe yang diberikan, yang
mengarah pada ekspektasi yang tidak realitas sehubungan dengan
sistem produksi nantinya.
• Prototipe evolusioner bisa jadi tidak terlalu efisien.
• Antarmuka komputer-manusia yang diberikan oleh beberapa alat
prototyping tertentu kemungkinan tidak mencerminkan teknik-teknik
desain yang baik.
Istilah RAD, dari Rapid application Development atau
pengembangan aplikasi capat diperkenalkan oleh konsultan komputer
dan penulis James Martin, dan istilah ini mengacu pada suatu
pengembangan siklus hidup yang dimaksudakan untuk memproduksi
sistem dengan cepat tanpa mengorbankan mutunya.
RAD adalaj kumpulan strategi, metodologi, dan alat terintegerasi yang
terdapat di dalam suatu kerangka kerja yang disebut rekayasa informasi.
Rekayasa informasi (Information Engineering—IE) adalah nama
yang diberikan martin kepada keseluruhan pendekatan pengembangan
sistemnya, yang ia perlakukan suatu aktivitas perusahaan secara
menyeluruh.
Komunitas
pengguna
Perencanaa
n
persyaratan
Departemen
Sistem informasi
Desain
pengguna
Waktu
Konstruksi
Serah
terima
Unsur-unsur Penting RAD
Manajemen. Manajemen, Khususnya manajemen puncak, hendaknya
menjadi penguji coba (experimenter) yang suka melakukan hal-hal
dengan cara baru atau pengadaptasi awal (early adapter) yang dengan
cepat mempelajari bagaimana cara menggunakan metodologi-metodologi
baru.
Orang. Daripada hanya memanfaatkan satu tim untuk melakukan
seluruh aktivitas SDLC, RAD menyadari adanya efisiensi yang dapat
dicapai melalui penggunaan tim-tim khusus. Anggota dari tim ini adalah
para ahli dalam metodologi dan alat yang dibutuhkan untuk melakukan
tugas-tugas khusus mereka masing-masing. Martin menggunakan istilah
tim SWAT, di mana SWAT merupakan singkatan dari “skilled with
advances tools” (ahli dengan alat-alat canggih).
Metodologi. Metodologi dasar RAD adalah siklus hidup RAD.
Alat-alat. Alat-alat RAD terutama terdiri atas bahasa-bahasa generasi
keempat dari alat-alat rekayasa peranti lunak dengan bantuan komputer
(computer-aided software engineering—CASE) yang memfasilitasi
prototyping dan penciptaan kode. Alat-alat CASE menggunakan
komputer untuk membuat dokumentasi yang dapat diubah menjadi
peranti lunak dan basis data operasional.
Pengembangan berfase (phased development) adalah suatu
pendekatan bagi pengembangan sistem informasi yang terdiri atas enam
tahap—investigasi awal, analisis, desain, konstruksi awal, konstruksi
akhir, serta pengujian dan pemasangan sistem. Tahap-tahap analisis,
desain, dan konstruksi awal dilaksanakan untuk setiap modul sistem
Tahap-tahap Pengembangan berfase
• Investigasi awal
• Analisis
• Desain
• Konstruksi awal
• Konstruksi akhir
• Pengujian dan pemasangan sistem
Investigasi
awal
Modul sistem
Analisis
Desain
Konstruks
i
awal
tinjaua
n
Meminta revisiKonstruks
i
akhir
Pengujian &
Pemasanga
n
sistem
Diterima
Fase-fase Modul
Jika prototyping paling sesuai digunakan untuk sistem kecil, metodologi
RAD paling sesuai untuk sistem besar, maka pengembangan berfase dapat
digunakan untuk pengembangan segala jenis ukuran sistem. Kuncinya
adalah cara bagaimana sistem dibagi menjadi modul-modul yang masingmasing akan dianalisis, dirancang, dan dibuat secara terpisah.
Investigasi
awal
Pembuat
Laporan
Meminta revisi
Analisis
Basis data
Analisis
Antarmuka web
Analisis
Desain
Desain
Desain
Konstruks
i
awal
Konstruks
i
awal
Konstruks
i
awal
Tinjaua
n
Tinjaua
n
Tinjaua
n
Meminta revisi
Konstruks
i
akhir
Pengujian &
Pemasanga
n
Meminta revisi
Rekayasa ulang (reengineering) yaitu proses pengerjaan ulang sistem
atau disebut juga dengan istilah desain ulang proses bisnis (business
process redesign—BPR). BPR mempengaruhi operasi TI perusahaan
dalam dua hal. Pertama, TI dapat menerapkan BPR untuk mendesain
ulang sistem-sistem informasi yang hidupnya tidak dapat dipertahankan
lagi dengan pemeliharaan biasa. Sistem-sistem seperti ini disebut sistem
warisan (legacy systems), karena mereka terlalu berharga untuk
dihapuskan namun menghisap sumber-sumber daya yang dimiliki oleh
IS. Kedua, ketika sebuah perusahaan menerapkan BPR pada operasi-
operasi utamanya, usaha ini akan selalu memberikan efek gelombang
yang menyebabkan perancangan ulang sistem informasi.
Inisisasi Strategis Proyek-proyek BPR
BPR memiliki potensi pengaruh dramatis pada perusahaan dan
operasinya hingga proyek-proyek seperti ini biasanya dicetuskan di
tingkat manajemen strategis. Manajemen strategis memutuskan bahwa
BPR layak untuk dilakukan dan menyetujui proses-proses fisik didesain
ulang.
Manajemen strategis juga dapat mengijinkan sistem informasi dirancang
ulang guna mengambil manfaat dari teknologi modern.
Ketika proses-proses fisik dirancang ulang, sering kali akan terjadi efek
domino yang akhirnya menyebabkan terjadinya perancangan ulang sistem
informasi yang terkait. Karena alasan ini, BPR biasanya akan melibatkan
layanan informasi.
IS menciptakan dua teknik dalam menerapkan BPR—rekayasa terbalik
dan rekayasa ulang. Komponen-komponen ini dapat diterapkan secara
Masalah
Atau
peluang
1
2
Proses-proses fisik
Proses-proses konseptual
Manajemen
strategis
Logistik
masuk
3
AktivitasAktivitas
pendukung
Operasi
Logistik
keluar
Sistem
informasi
Rekayasa Terbalik
Rekayasa terbalik adalah proses menganalisis sistem yang sudah ada untuk
mengidentifikasi unsur-unsur dan saling keterhubungan di antara unsur-unsur
tersebut sekaligus untuk membuat dokumentasi pada tingkat abstraksi yang
lebih tinggi daripada yang telah ada saat ini.
Titik awal dalam rekayasa terbalik sebuah sistem adalah kode komputernya,
yang diubah menjadi dokumentasi. Dokumentasi ini kemudian dapat diubah
ke dalam uraian-uraian yang lebih abstrak, seperti diagram arus data, kasuskasus penggunaan, dan diagram relasi entitas. Pengubahan ini dapat dilakukan
secara manual atau dengan menggunakan peranti lunak BPR.
Rekayasa Ulang
Rekayasa ulang (reengineering) adalah merancang ulang sebuah sistem
seluruhnya dengan tujuan mengubah fungsionalitasnya. Akan tetapi, ini
bukanlah pendekatan yang “bersih,” karena pengetahuan dari sistem yang ada
saat ini tidak sepenuhnya diabaikan. Pengetahuan tersebut diperoleh pertama
kali dengan melakukan rekayasa terbalik. Lalu sistem yang baru kemudian
dikembangkan dengan cara yang normal. Nama rekayasa ke depan (forward
engineering) diberikan untuk proses mengikuti SDLC dengan crara yang
normalsambil sekaligus menjalankan BPR.
Pemilihan Komponen-komponen BPR
Komponen-komponen BPR dapat diterapkan secara terpisah atau
digabung, tergantung pada tingkat kemungkinan yang dicari. Kombinasi
yang tepat akan tergantung pada kondisi sistem yang ada saat inijika
dilihat dari segi fungsionalitas dan sifat teknisnya. Mutu fungsionalitas
adalah ukuran dari apa yang dikerjakan oleh sistem. Mutu teknis adalah
ukuran dari seberapa baik sistem tersebut melaksanakannya.
Baik
Rekayasa
terbalik
Tidak melakukan
Apa-ap
Rekayasa
Ke depan
Rekayasa
ulang
Mutu
Fungsionalitas
(apa ?)
Buruk
Buruk
Baik
Mutu teknis
(bagaimana ?)
SDLC Tradisional, prototyping, RAD, dan BPR semuanya adalah
metodologi. Semuanya adalah car-cara yang direkomendasikan dalam
mengembangkan sistem informasi. SDLC tradisional adalah suatu penerapan
pendekatan sistem terhadap masalah pengembangan sistem.
Prototyping merupakan bentuk singkatan dari pendekatan sistem yang
berfokus pada definisi dan pemenuhan kebutuhan pengguna. Prototyping dapat
berada dalam SDLC.
RAD merupakan suatu pendekatan alternatif terhadap fase-fase desain dan
implementasi SDLC. Kontribusi utama yang diberikan adalah kecepatan untuk
menggunakan sistem, yang tercapai terutama melalui penggunaan alat-alat
berbasis komputer dan tim-tim proyek khusus.
Di BAB 6, telah di uraikan dua alat pemodelan data-diagram relasi entitas
dan diagram kelas. Kedua alat ini telah bertahun-tahun populer dan banyak
digunakan, tetapi masih dilakukan untuk memerbaiki penggunaannya.
Sebagai contoh, penelitian dan pemodelan proses dan data model-model
objek dapat ditingkatkan dengan menggunakan pola-pola yang pada
umumnya terjadi diantara objek.
Selama tahun-tahun awal pengembangan sistem komputer, praktis
hampir seluruh perhatian diberikan ke proses-proses yang akan dikerjakan
oleh komputer, sebagai kebalikan dari data yang akan dipergunakan.
Munculnya sistem manajemen basis data di tahun 1970-an menarik
perhatian akan pentingnya desain data. Alat-alat pemodelan data seperti
diagram relasi entitas dan diagran kelas adalah bukti dari perhatian ini.
Kini kita mengembalikan prhatian kita pada pemodelan proses-proses
yang dilakukan oleh sistem.
Pemodelan proses pertama kali dilakukan dengan diagram
alur (flowchart). Diagram ini mengilustrasikan aliran data melalui
sistem dan program.Internasional Organization for Standardization
(ISO) menciptakan standar untuk bentuk-bentuk simbol flowchart,
memastikan seluruh penggunaannya di seluruh dunia.
Diagram arus data sangat baik untuk membuat model proses pada
tingkat ringkasan. Akan tetapi, diagram arus data kurang baik dalam
menangkap detail-detail pemerosesan. Karena alasan ini, diagram
arus data pada umumnya dilengkapi oleh alat-alat lain yang lebih
berorientasi pada detail, seperti menggunakan diagram kasus
penggunaan (use case diagram).
Diagram arus data (flowchart) adalah penyajian grafis dari sebuah
sistem yang mempergunakan empat bentuk simbol untuk mengilustrasikan
bagaimana data mengalir melalui proses-proses yang saling tersambung.
Simbol-simbol tersebut mencerminkan
(1) unsur-unsur lingkungan dengan mana sistem berinteraksi,
(2) proses, (3) arus data, (4) penyimpana data.
(1). Unsur-unsur lingkungan, berada di luar batas sistem. Unsur-unsur ini
memberikan input data kepada sistem dan menerima output data dari sistem.
Istilah terminator sering kali dipergunakan untuk menyatakan unsur-unsur
lingkungan dan bentuknya persegi panjang, karena menunjukkan titik-titik di
mana sistem berakhir.
Terminator dapat berupa :
Orang, seperti seorang manajer, yang menerima laporan dari sitem.
Organisasi, seperti departemen lain dalam perusahaan atau perusahaan
lain.
Sistem lain yang mengalami antarmuka dengan sistem.
Terminator juga melakukan pekerjaan yang penting yaitu dalam
analisis dan desain sistem.
(2). Proses, adalah sesuatu yang mengubah input menjadi output. Bentuknya
lingkaran, persegi panjang horizontal, atau sebuah persegi panjang tegak
bersudut melingkar. Ini harus menggunakan teknik pemberian label, dan yang
paling umum digunakan adalah dengan menggunakan kata kerja dan objek,
tetapi dapat juga menggunakan nama dari suatu sistem atau program
komputer.
(3). Arus data, terdiri dari sekumpulan unsur –unsur data yang berhubungan
secara logis (mulai dari satu unsur data tunggal hingga satu file atau lebih)
yang bergerak dari satu titik atua proses ke titik atau proses yang lain. Simbol
panah digunakan untuk menggambarkan arus ini dan dapat digambar dengan
menggunaka garis lurus maupun melingkar.
(4). Penyimpanan Data Ketika kita perlu menyimpan data karena suatu
alasan tertentu, maka kita akan menggunakan pnyimpanan data. Penyimpanan
data adalah suatu gudang data. Bayangkanlah penyimpanan data sebagai
“data yang beristirahat”. Peyimpanan data dapat ditunjukkan oleh sekumpulan
garis-garis sejajar, sebuah kotak dengan ujung terbuka atau bentuk oval.
Figur 7.12 mengidentifikasi proses-proses utama system.
Proses utama system ini disebut diagram nomor 0 (figure 0
diagram). Kita akan menjelaskan bagaimana nama tersebut diperoleh
nanti. Tambahan DFD dapat digunakan untuk menghasilkan
dokumentasi dengan tingkat yang lebih ringkas dan lebih terinci.
Sebuah diagram yang mendokumentasi system pada tingkat yang
lebih ringkas disebut diagram konteks (context program); sebuah
diagram yang memberikan lebih banyak detail disebut diagram nomor
n (figure n diagram).
pelanggan
Mengirimkan surat
1
Membuka
surat
Pesanan
penjualan
Data pesanan
Penjualan yang
2
Memasuka
n
Data
Pesanan
penjualan
Pesanan
penjualan
File
formulir
Pesanan
yang dimasukan
penjualan
Telah dimasukan3
Menyortir
PesananPesanan
penjualan
Catatan
Penjualan yang
4
Telah disortir
Menhitung
Komisi
penualan
Laporan
Manajer
penjualan
Diagram konteks menempatkan system dalam suatu konteks
lingkungan. Diagram ini terdiri atas satu symbol proses tunggal yang
melambangkan keseluruhan system. Figur 7.13 adalah sebuah diagram
konteks dari system komisi penjualan.
Ketika menggambarkan sebuah diagram konteks, Anda :
1. Hanya menggunakan satu symbol proses saja.
2. Memberikan label pada symbol proses untuk mencerminkan
keseluruhan system.
3. Jangan memberikan nomor pada symbol proses tunggal.
4. Memasukkan seluruh terminator dan system.
5. Menunjukkan seluruh arus data yang terjadi antara terminator dan
system.
Meskipun diagram konteks mendokumentasikan sebuah system
pada tingkat yang tertinggi, biasanya akan lebih mudah untuk memulai
dokumentasi pada tingkat yang lebih rendah – misalnya, tingkat Nomor 0.
Mengirimkan surat
Pelanggan
Sistem
Komisi
penjualan
Laporan
Komisi penjualan
Manajer
penjualan
3
Catatan
Penjualan
Yang telah
4.1 disortir
Menghitun
g
Jumlah
komisi
Jumlah
komisi
4..2
Mengaku
m-ulasi
total
Laporan
Komisi
Penjualan
Manajer
penjualan
Ketika kita perlu mendokumentasikan system dengan detail yang
lebih besar daripada diagram diagram nomor 0, Anda akan
menggunakan satu atau lebih diagram nomor n. Diagram nomor n
(figure n diagram) mendokumentasikan satu proses dari sebuah DFD
dengan tingkat detail yang lebih besar. n melambangkan nomor proses
pada tingkat yang lebih tinggi dari yang sesuatu sedang
didokumentasikan.
Istilah DFD bertingkat (leveled DFD)digunakan untuk menguraikan
hierarki dari diagram, dimulai dari diagram konteks hingga diagram
Nomor n dengan tingkat yang paling rendah, yang digunakan untuk
mendokumentasikan sebuah system.
Terdapat dua aturan umum yang memandu para pengembang
dalam memutuskan berpa banyak tingkat DFD yang akan digunakan.
Pertama adalah membatasi satu DFD menjadi tidak lebih dari enam
hingga delapan proses. Kedua adalah menggunakan alat lain untuk
mendokumentasikan tingkat detail yang paling rendah, tetapi dengan
menggunakan tidak lain lebih dari satu halaman. Jika Anda
membutuhkan lebih banyak tempat, maka Anda terlalu berhenti
menggunakan pendiagraman arus data. Alat pemodelan proses yang
cocok untuk digunakan bagi jumlah detail yang lebih banyak adalah
kasus penggunaan (use case).
Kasus Penggunaan (use case) adalah suatu uraian naratif dalam
bentuk kerangka dari dialog yang terjadi antara system primer dengan
system sekunder. Dalam kebanyakan kasus, system primer adalah
sebuah program computer dan system sekunder adalah orang yang
berinteraksi dengan program computer. Dialog biasanya terdiri atas
tindakan-tindakan yang diambil oleh seorang operator entri data dan
system komputer.
Seorang operator entri data melakukan log on dengan menggunakan
kata sandi . System memverikasi kata sandi atau menolak entri.
Operator entri data memasukan data pesanan penjualan ke dalam
stasiun kerja.
Data pesanan meliputi :
 Nomor pelanggan
 Nomor barang
 Jumlah barang
Program entri pesanan mengakses file induk untuk memverifikasi
keakuratan :
 Nomor pelanggan
 Nomor barang
Ketika nomor tidak dapat diverifikasi dengan benar, program akan
menampilkan satu pesan kesalahan dan meminta operator
memasukkan ulang informasi.
Ketika operator ingin mengakhiri proses entri pesanan, ia akan
melakukan log off.
Nama kasus penggunaan : Memasukan data pesanan penjualan
Uraian :
Operasi entri data untuk sistem dari pesanan
Prasyarat :
Menciptakan pelanggan, menciptakan barang
Asosiasi :
Menu utama
Pelaku utama :
Operator data entri
Operator data entri
1.0
Operator log on dengan kata sandi
1.0-A Kembali ke menu utama
1.1-A Ke 7.0-A
3.0
Operator memasukan nomor pelanggan,
nomor barang, dan jumlah barang
3.0-A Kembali ke menu utama
3.1-A ke 7.0-A
6.0
Ke 3.0
6.0-A Kembali ke menu utama
6.0-A log off
Sistem
2.0
Sistem memverifikasi operator dan
meminta operator memasukan informasi
tambahan
2.0-A Sistem tidak memverifikasi operator dan
mengeluarkan pesan untuk melakukan entri
ulang
2.1-A Ke 1.0
4.0
Sistem memverifikasi nomor pelanggan
dan nomor barang
4.1-A Sistem menampilakan pesan kesalahan
dan meminta operator memasukan ulang
4.2-A ke 3.0
5.0
Sistem menyimpan data pesanan
7.0
Sistem mencatat log keluar karyawan
7.0-A Sistem menampilkan menu utama
Panduan kasus penggunaan
1. Mulai penomoran dengan 1.0 di sisi sebelah kiri untuk mewakili tindakan pertama pengguna.
Contoh : 1.0 karyawan melakukan log on dengan melakukan kata sandi.
2. Entri pertama di sebelah kanan seharusnya adalah 2.0, untuk tindakan sistem yang pertama.
3. Gunakan angak-angka desimal untuk menunjukan langkah-langlah yang diambil dalam suatu urutanurutan yang semuanya merupakan bagian dari suatu tindakan tertentu, Jika tidak, gunakan angka bulat
yang menurun (3,4,5, dan sterusnya).
Contoh : 2.0 Sistem memverifikasi pengguna
1.1 Sistem meminta pengguan untuk memasukan informasi tambahan
4. Menambahkan abjad pada satu urutan nomor untuk suatu peristiwa alternatif.
Contoh : 2.0-A Sistem tidak memverifikasi pengguna
2.1-A Sistem meminta pengguna untuk memasukan kata sandi kembali
5. Ketika terdapat peristiwa-peristiwa alternatifyang saling ekslusif, gunakan beberapa abjad.
6. Untuk tindakan turunan, gunakan satu angka bulat untuk tindakan dasar, diikuti dengan angka
desimal untuk tindakan-tindakn turunan.
Contoh : 3.0 Pengguna membuat laporan
3.1 Pengguna menentuka tanggal awal dan tanggal akhir
3.2 Pengguna menentukan jenis laporan
7. Untuk tindakan-tindakan opsional, gunakan angak bulat untuk tindakna dasar, diikuti dengan angka
desimal dan abjad untuk tindakan-tindakan opsional.
Contoh : 3.2 Pengguna menentukan jenis laporan
3.2-A Pengguna menentukan laporan tabel ringkasan
3.2-B Pengguna menentukan laporan tabel detail
3.2-C Pengguna menentukan laporan grafik
8. Pada akhir proses, pengguna hendaknya memilih untuk mengulang proses atau melakukan log off.
Contoh : 10.0 Pengguna kembali ke menu utama
10.0-A Pengguna log off
9. Ketika pengguna melakukan log off, sistem seharusnya merespon dengan mengeluarkan pengguna.
Contoh : 11.0-A Sistem mengeluarkan pengguna.
Proyek-proyek pengembangan sistem yang pertama dikelola oleh manajer unit
TI, dengan dibantu oleh manajer dari analisis sitem, pemrograman, dan
operasi. Melalui percobaan, tanggung jawab manaemen secara bertahap
telah mencapai tingkat manajemen yang lebih tinggi—yaitu tingkat strategis
dalam kebanyakan kasus.
Ketika sistem memiliki nilai strategis atau pengaruhnya meliputi keseluruhan
organisasi, direktur utama atau komite eksekutif perusahaan dapat
memutuskan untuk mengawasi sendiri proyek pengembangan tersebut.
Banyak perusahaan membentuk komite khusus di bawah tingkat komite
eksekutif yang menerima tanggung jawab untuk mengawasi seluruh proyek
sistem. Ketika tujuan dari dibentuknya sebuah komite adalah untuk
memberikan panduan, arah, dan kendali secara terus-menerus, maka ia
disebut sebagai streering committee (komite pengarah).
Eksekutif
Steering
Committee
SIM
Pemasaran
Pimpinan
Proyek tim
Model
Lokasi
gudang
Pimpinan
Proyek
Tim MRP II
Produksi
Keuangan
Sumber
Daya Manusia
Pimpinan
Proyek
Tim ISDN
Pimpinan proyek
Tim sistem
Persetujuan
kredit
Pimpinan
Proyek
Tim HRIS
Steering Committee SIM
Steering committee menjalankan tiga fungsi utama yaitu:
• Menciptakan kebijakan yang memastikan dukungan komputer untuk
mencapai sasaran strategis perusahaan.
• Melakukan pengendalian fiskal dengan bertindak sebagai yang
berwenang dalam memberikan persetujuan untuk seluruh permintaan
akan pendanaan yang berhubungan dengan komputer.
• Menyelesaikan perselisihan yang terjasi sehubungan dengan prioritas
penggunaan komputer.
Jika secara tidak langsung, tugas steering committee SIM adalah
melaksanakan seluruh strategi yang dibuat oleh komite eksekutif maupun
rencana strategis untuk sumber daya informasi.
Dengan memusatakan manajemen siklus hidup sistem dalam steering
committee, maka akan didapatkan dua keuntungan utama yaitu:
• Komputer akan digunakan untuk mendukung pengguna di seluruh
perusahaan.
• Proyek-proyek komputer akan memiliki ciri-ciri perencanaan dan
pengendalian yang baik.
Kepemimpinan Proyek
Steering committee SIM jarang ikut terlibat langsung dengan detail
pekerjaan. Tanggung jawab itu jatuh ke tangan tim proyek. Tim proyek
meliputi semua orang yang ikut berpartisipasi dalam pengembangan
sistem informasi. Satu tim dapat terdiri dari beberapa orang yang terdiri
dari pengguna, spesialis informasi, dan mungkin auditor internal.
Aktivitas tim akan diarahkan oleh seorang ketua tim atau pimpinan
proyek yang memberikan arahan di sepanjang masa proyek.
Mekanisme Manajemen Proyek
Dasar dari manajemen proyek adalah rencana proyek, yang dibuat selama
tahap investigasi awal ketika metodologi pengembangan berfase diikuti.
Setelah tujuan-tujuan proyek, kendala, dan ruang lingkupnya telah selesai
didefinisikan,kita akan dapat mengidentifikasi pekerjaan-pekerjaan yang
harus dilaksanakn. Rencana ini pertama-tama dirancang dalam bentuk
umum dan selanjutnya dibuat menjadi lebih spesifik. Satu format yang
populer untuk rencana terinci adalah grafik gantt. Grafik gantt (gantt
chart) adalah sebuah grafik batang horizontal yang mencantumkan satu
grafik batang untuk setiap pekerjaan yang dilaksanakan.
Satu pelengkap dari grafik gantt adalah diagram jaringan. Diagram
jaringan (network diagram) yang disebut juga diagram CPM (Critical
Path Method) atau PERT (Program Evaluation and Review Technique)
adalah sebuah gambar yang mengidentifikasikan aktivitas-aktivitas dan
menghubungkannya dengan panah-panah untuk menunjukan urutan-
1
2
3
5
4
6
Dukungan Web bagi Manajemen Proyek
Selain sistem manajemen proyek berbasis peranti lunak seperti Microsoft
Project, dukungan juga dapat diperoleh dari internet. Sebagai contoh,
sebuah perusahaan yang berbasis di Toronto, menawarkan sebuah sistem
manajemen proyek yang disebut easyproject.net. Perusahaan tersebut
juga menawarkan kursus manajemen proyek secara online sebagai bagi
perusahaan untuk meningkatkan pengetahuan manajemen proyek para
karyawannya.
Banyak metode yang dapat digunakan untuk mengestimasi biaya dan jadwal
proyek. Semua metode ini kurang lebih mengandalkan pada tiga komponen
yaitu:
1.
Informasi mengenai sistem tertentu yang sedang dibuat dan orang yang
akan melakukan pengembangan.
2.
Pengalaman historis.
3.
Pengetahuan mengenai proses pengembangan peranti lunak dan alat-alat
serta teknik estimasi.
Input Pengestimasian Biaya
Sebuah work breakdown Structure (WBS) mengidentifikasikan aktivitasaktivitas proyek yang akan membutuhkan sumber daya. Contoh WBS
adalah grafik gantt dan diagram jaringan. Kebutuhan sumber daya
(resource requirement) mencantumkan sumber daya tertentu yang akan
dibutuhkan dan berapa jumlahnya. Tarif sumber daya (resource rates)
adalah biaya perunit untuk setiap jenis sumber daya. Estimasi durasi
aktivitas (activity duration estimates) menybutkan periode pekerjaan
yang dibutuhkan untuk menyelesaikan aktivitas. Informasi historis
(historical information) terdiri atas file-file dari data proyek masa lalu,
basis data pengestimasian biaya komersial, dan pengetahuan tim proyek.
Alat-alat dan Teknik Estimasi Biaya
Etimasi analogis (analogous estimating) menggunakan biaya aktual
proyek-proyek serupa yang telah dilakukan di masa lalu sebagai dasar
untuk memproyeksikan biaya dari proyek yang sedang dipertimbangkan.
Estimasi dari bawah ke atas (bootom-up estimating) dimulai dengan
detail, seperti aktivitas di dalam grafik gantt, lalu mengalikannya dengan
data biaya, seperti tarif per jam untuk karyawan, untuk menghasilkan
estimasi biaya proyek.
Alat-alat terkomputerisasi (computerize tools) dapat digunakan secara
terpisah atau untuk menyederhanakan alat-alat yang baru saja diuraikan.
Satu sumber bagi alat-alat terkomputerisasi adalah
WWW.CONSTRUX.COM.
Model-model matematis (mathematical models) dapat digunakan untuk
menguantifikasi karakteristik proyek dan membuat simulasi dari berbagi
Output Pengestimasian Biaya
Estimasi biaya dibuat untuk seluruh sumber daya yang dibebankan ke
proyek dan biasanya dinyatakan dalam unit-unit keuangan yang berlaku,
Seperti Dollar atau Euro. Estimasi seperti ini dapat disempurnakan
kembali selama proyek berlangsung untuk mencerminkan tambahan
informasi seiring dengan semakin jelasnya proyek tersebut. Detail-detail
pendukung mendokumentasikan bagaimana estimasi tersebut dihitung
dan setiap asumsi-asumsi yang diambil. Rencana manajemen biaya (costmanajement plan) menjelaskan bagaimana varians biaya akan dikelola.
INPUT
ALAT DAN TEKNIK
OUTPUT
Work breakdown stucture
Estimasi analisis
Estimasi biaya
Kebutuhan sumber daya
Estimasi dari bawah ke atas
Detail-detail pendukung
Tarif sumber daya
Alat-alat terkomputerisasi
Rencana manajemen biaya
Estimasi durasi aktivitas
Inforamsi historis
TIM
RENCANA ANALISIS
DESAIN
TOTAL
BIAYA PER
TOTAL
JAM
JAM
BIAYA
IMLEMENTASI PEMELIHARAAN
Gudang
80
240
160
120
160
760
$35,50
$26.980,00
Logistik
80
160
240
40
800
600
$75,00
$45.000,00
Persediaan
80
160
400
80
160
880
$75,00
$66.000,00
TOTAL
2240
$137.980,00
 Langkah 1—Melihat Perusahaan Sebagai Suatu Sistem. Anda harus dapat
memandang perusahaan Anda sebagai suatu sistem. Halini dapat terlaksana
dengan mempergunakan model sistem umum dari Bab 2 sebagai pola. Anda
seharusnya dapat melihat bagaimana perusahaan atau unit organisasi Anda
sesuai dengan model.
 Langkah 2—Mengenal Sistem Lingkungan. Hubungan antara perusahaan
dengan lingkungan merupakan suatu ha yang penting. Delapan unsur
lingkungan yang telah kita bahas di Bab 2 memberikan suatu cara yang
efektif dalam memosisikan perusahaan sebagai suatu sistem dalam
lingkungannya.
 Langkah 3—Mengidentifikasi Subsistem Perusahaan. Subsistem utama
perusahaan dapat mengambil beberapa bentuk. Bentuk termudah yang
harus dilihat manajer adalah area-area bisnis. Masing-masing area dapat
dianggap sebagai suatu sistem yang terpisah, seperti yang disajikan dalam
Figur 7.2.
Lingkungan
Figur 2.1
Standar
Keputusan
Informasi
dan data
Informasi
Manajemen
Pemrosesan
informasi
Data
Sumber
Daya fisik
Sumber
daya input
 Model
Proses
transformasi
sistem Umum perusahaan
Sumber
daya
output
Sumber
Daya fisik
Figur 2.2
Pemerinta
h
Komunitas
keuangan
Komunitas
Global
Perusahaan
Pemasok
Pelanggan
Pesaing
Serikat
pekerja
Pemegang
saham atau
pemilik
Delapan unsur Lingkungan
Direktur
Subsistem pemasaran
Subsistem produksi
Subsistem SDM
Subsistem keuangan
Subsistem
Layanan informasi
 Langkah 4—Melanjutkan Dari Tingkat Sistem ke Tingkat subsistem. Ketika
manajer mencoba untuk memahami masalah, analisis akan memulai pada
sistem yang menjadi tanggung jawab manajer tersebut. Sistem ini dapat
berupa perusahaan atau salah satu unitnya. Analisis kemudian dilanjutkan
menuju ke bawah hierarki sistem, tingkat demi tingkat.
 Langkah 5—Menganalisis Bagian-bagian Sistem Dalam Unit Urutan-urutan
Tertentu. Seiring dengan manajer yang mempelajari masing-masing tingkat
sistem, unsur-unsur sistem juga dianalisis secara berurutan. Urut-urutan ini
ditampilkan dalam Figur 7.3.
1
Standar
5
Input dan sumber dya input
3
manajemen
4
Pemroses
informasi
6
Proses
transformasi
7
Sumber
daya output
2
Outpu
t
 Langkah 6—Mengidentifikasi Solusi-solusi Alternatif. Manajer
mengidentifikasai cara-cara yang berbeda untuk memecahkan masalah
yang sama.
 Langkah 7—Mengevaluasi Solusi-solusi Alternatif. Semua alternatif
harus dievaluasi dengan menggunakan kriteria evaluasi yang sama, yang
mengukur seberapa baik satu alternatif akan memecahkan masalah.
Evaluasi akan menghasilkan keuntungan dan kerugian dari
pengimplementasian dari masing-masing alternatif.
 Langkah 8—Memilih Solusi Yang Terbaik. Tiga cara yang dilakukan
manajer dalam memilih alternatif yang terbaik menurut Henry
mintzberg:
• Analisis
• Pertimbangan
• Tawar-menawar
 Langkah 9—Mengimplementasikan Solusi. Masalah tidak akan
terpecahkan hanya dengan memilih solusi yang terbaik. Kita perlu
mengimplementasikan solusi tersebut.
 Langkah 10—Menindaklanjuti Untuk Memastikan Keefektifan
Solusi. Manajer dan para pengembang hendaknya tetap mengawasi
situasi untuk memastikan bahwa solusi yang dipilih telah mencapai
 Unsur 1—Mengevaluasi Standar. Standar kinerja bagi suatu sistem
biasanya dinyatakan dalam bentuk rencana, anggaran, dan kuota.
Manajemen menentukan standar dan harus memastikan bahwa standar
tersebut realistis, dapat dipahami, dapat diukur, dan valid.
 Unsur 2—Membandingkan Output Sistem Dengan Standar. Jika sistem
memenuhi standar, tidaklah perlu untuk meneruskan dengan
pendekatan sistem atas pemecahan masalah pada tingkat sistem
tertentu ini. Sebagai gantinya, manajer hendaknya mengevaluasi ulang
standar berdasarkan kinerja yang baik saat ini.
 Unsur 3—Mengevaluasi Manajemen. Diberikan satu penilaian kritis atas
manajemen dan struktur organisasi sistem. Apakah terdapat tim
manajemen sesuai dengan kualitas yang diminta ?
 Unsur 4—Mengevaluasi Prosesor Informasi. Ada kemungkinan terdapat
tim manajemen yang baik, namun tim tersebut tidak mendapatkan
informasi yang ia butuhkan. Jika kasusnya seperti ini, kebutuhan harus
diidentifikasi dan sistem informasi yang memadai harus dirancang dan
diimplementasikan.
 Unsur 5—Mengevaluasi Input Dan Sumber Daya Input. Ketika analisis
pada sistem di tingkat ini telah tercapai, sistem konseptual tidak lagi
menjadi masalah, dan masalah terdapat pada sistem fisik. Analisis akan
dilakukan oleh sumber daya fisikdi dalam unsur input dari sistem
(dokumen penerimaan, bagian kendali mutu, dan gudang bahan
mentah) maupun sumber daya yang mengalir dari lingkungan melalui
umsur tersebut.
 Unsur 6—Mengevaluasi Proses Transformasi. Prosedur-prosedur dan
praktik-praktik yang tidak efisien dapat menimbulkan kesulitan dalam
mengubah input menjadi output. Otomatisasi, robot, desain yang
dibantu oleh komputer, serta produksi yang diintegrasikan oleh
komputer adalah contoh dari upaya memecahkan masalah transformasi.
 Unsur 7—Mengevaluasi Sumber Daya Output. Di sini kita akan
mempertimbangkan sumber daya fisik dalam unsur output suatu sistem.
Contoh dari sumber daya seperti ini adalah gudang barang jadi, personel
dan mesin-mesin dok pengiriman, serta armada truk pengiriman.