Modul Proyek Pengembangan Sistem Informasi PDF

MODUL PERKULIAHAN
PROYEK
PENGEMBANGAN
SISTEM
INFORMASI
Modul Standar untuk
digunakan dalam Perkuliahan
di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
01
Ilmu Komputer Sistem Informasi 87007 Team Dosen
Abstract Kompetensi
Definisi Sistem, subsistem, super Memahami siklus pengembangan
sistem, dan karakteristik sistem sistem, memahami metodhologi
pengembangan sistem, mengenal UML
2014 Proyek Pengembangan Sistem Informasi Modul 01 Pusat Bahan Ajar dan eLearning
1 Team Dosen http://www.mercubuana.ac.id
Metodologi Siklus Hidup
1. SIKLUS HIDUP SISTEM
Siklus hidup sistem (system life cycle – SLC) adalah proses evolusioner yang diikuti
dalam menerapkan sistem atau subsistem informasi berbasis komputer. SLC sering disebut
dengan pendekatan air terjun (waterfall approach) bagi pengembangan dan penggunaan
sistem. Dilakukan dengan strategi Top-Down Design.
Tahapan dari siklus hidup sistem yaitu :
a. Tahap Perencanaan
b. Tahap Analisis
c. Tahap Rancangan
d. Tahap Penerapan
e. Tahap Penggunaan
Kelima tahap tersebut secara diagram nampak seperti Gambar 1
Gambar 1. Diagram Siklus Hidup Sistem
Empat tahap pertama dinamakan dengan siklus hidup pengembangan sistem (system
development life cycle – SDLC).
Siklus hidup sistem yang pertama dikelola oleh manajer unit jasa informasi, dibantu oleh
manajer dari analisis sistem, pemrograman dan operasi. Namun kecenderungan saat ini,
meletakkan tanggung jawab pada tingkat yang lebih tinggi dan lebih rendah. Ada tiga tingkatan
besar (hirarki) dari manajemen siklus hidup sistem, yaitu :
a. Tanggung Jawab Eksekutif

Ketika sistem memiliki nilai strategis atau mempengaruhi seluruh organisasi, direktur utama
atau komite eksekutif mungkin memutuskan untuk mengawasi proyek pengembangannya.
Ketika lingkup sistem menyempit dan fokusnya lebih operasional kemungkinan besar
kepemimpinan akan dipegang oleh eksekutif tingkat yang lebih rendah, seperti wakil direktur
utama, direktur bagian administrasi, dan CIO.
b. Komite Pengarah SIM (steering committee MIS – SC MIS)

Banyak perusahaan membuat suatu komite khusus, di bawah tingkat komite eksekutif, yang
bertanggung jawab atas pengawasan seluruh proyek sistem. Jika tujuan komiter tersebut
adalah memberikan petunjuk, pengarahan dan pengendalian yang berkesinambungan,
dalam rangka penggunaan sumber daya komputer perusahaan maka komite tersebut
dinamakan Komite Pengarah SIM.
Komite Pengarah SIM melaksanakan tiga fungsi utama, yaitu :
1) Menetapkan kebijakan
2) Menjadi pengendali keuangan
3) Menyelasaikan pertentangan
Keuntungan yang dicapai :
 Semakin besar kemungkinan komputer akan digunakan untuk mendukung pemakai di

seluruh perusahaan.
 Semakin besar kemungkinan proyek-proyek komputer akan mempunyai perencanaan
dan pengendalian yang baik.
c. Kepemimpinan Proyek
Komite pengarah SIM yang terlibat langsung dengan rincian pekerjaan, tanggung
jawabnya ada pada Tim Proyek. Tim proyek mencakup semua orang yang ikut serta
dalam pengembangan sistem berbasis komputer. Kegiatan tim tersebut diarahkan oleh
seorang Pemimpin Proyek yang memberikan pengarahan selama proyek berlangsung.
Tidak seperti komite pengarah SIM, tim proyek tidak berkelanjutan dan biasanya
dibubarkan ketika penerapan sistem telah selesai.
2. TAHAP PERENCANAAN
Keuntungan dari merencanakan proyek CBIS, yaitu :
 Menentukan lingkup dari proyek

Unit organisasi, kegiatan atau sistem manakah yang terlibat dan mana yang tidak ? Hal
tersebut akan memberikan perkiraan awal dari skala sumber daya yang diperlukan.
 Mengenali berbagai area permasalahan potensial

Akan menunjukkan hal-hal yang mungkin tidak berjalan dengan semestinya, sehingga hal
tersebut dapat dicegah.
 Mengatur urutan tugas

Banyak tugas-tugas terpisah yang diperlukan untuk mencapai sistem. Tugas tersebut diatur
dalam urutan logis berdasarkan prioritas informasi dan kebutuhan agar efisien.
 Memberikan dasar untuk pengendalian

Tingkat kinerja metode pengukuran tertentuharus dispesifikasikan sejak awal.
Langkah-langkahnya
a. Menyadari masalah
Kebutuhan akan proyek CBIS (Computer Based Information System) biasanya dirasakan
oleh manajer perusahaan, non manajer, dan elemen-elemen dalam lingkungan perusahaan.
b. Mendefinisikan masalah
Setelah manajer menyadari adanya masalah, ia harus memahaminya dengan baik agar
dapat mengatasi permasalah tersebut. Ia melakukan identifikasi dimana letak
permasalahannya, penyebabnya dan berusahan mengumpulkan semua informasi. Jika
perusahaan mempunyai kebijakan untuk mendukung end user computing, dan manajer ingin
memakai pendekatan tersebut untuk pengembangan sistem, maka ia bertanggung jawab
untuk membuat definisi. Selain itu, manajer memerlukan bantuan analis sistem yang saling
bekerja sama dengan manajer.
c. Menentukan tujuan sistem

Manajer dan analis sistem mengembangkan suatu daftar tujuan sistem yang harus dipenuhi
oleh sistem untuk memuaskan pemakai. Sehingga tujuan hanya dinyatakan secara umum,
yang nantinya akan dibuat lebih spesifik.
d. Mengidentifikasi kendala sistem

Sistem baru dalam pengoperasiannya tidak bebas dari kendala. Beberapa kendala mungkin
ditimbulkan oleh lingkungan, seperti laporan pajak yang diminta oleh pemerintah dan
informasi pembayaran yang dibutuhkan oleh konsumen. Kendala lainnya, seprti keharusan
menggunakan perangkat keras yang telah ada atau menyiapkan dan menjalankan sistem
pada tanggal tertentu. Kendala-kendala tersebut penting untuk diidentifikasi sebelum sistem
benar-benar mulai dikerjakan. Dengan demikian, baik rancangan sistem maupun kegiatan
proyek akan berada di antara kendala-kendala tersebut.
e. Membuat studi kelayakan

Studi kelayakan adalah suatu tinjauan seklias pada faktor-faktor utama yang akan
mempengaruhi kemampuan sistem untuk mencapai tujuan yang diinginkan. Ada enam
dimensi kelayakan, yaitu :
- Teknis; tersediakan hardware dan software untuk melaksanakan pemrosesan yang

diperlukan ?
- Pengembalian ekonomis; dapatkah sistem yang diajukan dinilai secara keuangan
dengan membandingkan kegunaan dan biayanya ?
- Pengembalian non ekonomis; dapatkah sistem yang diajukan dinilai berdasarkan
keuntungan-keuntungan yang tidak dapat diukur dengan uang?
- Hukum dan etika; akankah sistem yang diajukan beroperasi dalam batasan hukum dan
etika ?
- Operasional; apakah rancangan sistem akan didukung oleh orang-orang yang akan
menggunakannya ?
- Jadual; mungkinkah penerapan sistem dalam kendala waktu yang ditetapkan ?
Analis sistem mengumpulkan informasi yang diperlukan untuk menyawab pertanyaan-
pertanyaan tersebut dengan mewawancarai beberapa pegawai penting dalam area pemakai.
f. Menyiapkan usulan penelitian sistem

Jika suatu sistem dan proyek tampak layak, diperlukan penelitian sistem secara menyeluruh.
Penelitian sistem (sistem study) akan memberikan dasar yang terinci bagi rancangan sistem
baru mengenai apa yang harus dilakukan sistem itu dan bagaimana sistem tersebut
melakukannya. Analis akan menyiapkan usulan penelitian sistem yang memberi dasar bagi
manajer untuk menentukan perlu tidaknya pengeluaran untuk analisi. Hal penting yang harus
diingat tentang usulan tersebut adalah bahwa sebagian besar isinya didasarkan pada
perkiraan (perkiraan merupakan informasi terbaik yang tersedia) dan perkiraan jauh lebih
baik daripada tanpa informasi sama sekali. Selebihnya akan dipelajari ketika siklus hidup
mulai berjalan.
g. Menyetujui atau menolak proyek penelitian

Manajer dan komite pengarah menimbang pro dan kontra proyek dan rancangan sistem
yang diusulkan, serta menentukan apakah perlu diteruskan  keputusan teruskan /
hentikan. Pertimbangan penting yang perlu dilakukan yaitu :
- Akankah sistem yang diusulkan dapat mencapai tujuannya ?

- Apakah penelitian proyek yang diusulkan merupakan cara terbaik untuk melakukan
analisis sistem ?
- Jika keputusannya adalah teruskan maka proyek akan berlanjut ke tahap penelitian
(analisis). Namun, jika keputusannya hentikan maka semua pihak mengalihkan
perhatiannya ke masalah-masalah lain.
h. Menetapkan mekanisme pengendalian

Sebelum penelitian sistem dimulai, SC MIS menetapkan pengendalian proyek dengan
menentukan apa yang harus dikerjakan, siapa yang melakukannya, dan kapan akan
dilaksanakan. Setelah jadual ditetapkan, jadual tersebut harus didokumentasikan dalam
bentuk yang memudahkan pengendalian. (misalkan gunakan Microsoft Project).
Komite Pengarah SIM Analis Sistem
Manajer
Secara diagram tahapan perencanaan nampak pada Gambar 2
1
Menyadari
masalah
2
Mendefinisikan
masalah Konsultasi
3
Menentukan
tujuan sistem
4 5
Mengidentifikasi Membuat
kendala sistem studi kelayakan
7. Menyetujui / menolak proyek peneltitian

6
Usulan
penelitian sistem
8. Menetapkan mekanisme pengendalian
Gambar 2. Tahap Perencanaan dari SLC
Bentuk dari usulan penelitian sistem secara umum mencakup :
1) Ikhtisar eksekutif
2) Pendahuluan
3) Tujuan dan kendala sistem
4) Berbagai alternatif sistem yang mungkin
5) Proyek penelitian sistem yang disarankan
6) Tugas yang harus dilaksanakan
7) Kebutuhan sumber daya manusia
8) Jadual kerja
9) Perkiraan biaya
10) Dampak yang diharapkan dari sistem
a. Dampak pada struktur organisasi perusahaan
b. Dampak pada operasi perusahaan
c. Dampak pada sumber daya perusahaan
11) Rencana pengembangan umum (tahap analisis, rancangan dan penerapan)
12) Ikhtisar
3. TAHAP ANALISIS
Ketika perencanaan selesai dan mekanisme pengendalian telah berjalan, tim proyek
beralih pada analisis sistem yang telah ada. Analisis sistem adalah penelitian atas sistem
yang telah ada dengan tujuan untuk merancang sistem baru atau diperbarui.
Adapun tahapannya yaitu :
a. Mengumumkan Penelitian Sistem

Manajer khawatir terhadap penerapan aplikasi komputer baru yang mempengaruhi kerja
para pegawainya. Sehingga perlu dikomunikasikan kepada para pegawai tentang :
1) alasan perusahaan melaksanakan proyek

2) bagaimana sistem baru akan menguntungkan perusahaan dan pegawai.
b. Mengorganisasikan Tim Proyek
Tim proyek yang akan melakukan penelitian sistem dikumpulkan. Agar proyek berhasil,
pemakai sangat perlu berperan aktif daripada berperan pasif. Banyak perusahaan
mempunyai kebijakan menjadikan pemakai sebagai pemimpin proyek dan bukannya
spesialis informasi.
c. Mendefinisikan Kebutuhan Informasi

Analis mempelajari kebutuhan informasi pemakai dengan terlibat dalam berbagai kegiatan
pengumpulan informasi (wawancara, pemgamatan, pencarian catatan, dan survei). Dari
semua metode tersebut, wawancara perorangan lebih disukai, dengan alasan :
- Menyediakan komunikasi dua arah dan pengamatan terhadap bahasa tubuh.

- Dapat meningkatkan antusiasme pada proyek baik dari pihak spesialis maupun
pihak pemakai.
- Dapat menjalin kepercayaan antara pemakai dan spesialis informasi.
- Memberi kesempatan bagi peserta proyek untuk mengungkapan pandangan yang
berbeda bahkan bertentangan.
Dokumentasi dapat berupa flowchart, diagram aliran data (data flow diagram), dan grafik
serta penjelasan naratif dari proses dan data. Istilah kamus proyek sering digunakan untuk
menggambarkan semua dokumentasi yang menjelaskan suatu sistem.
d. Mendefinisikan Kriteria Kinerja Sistem

Langkah selanjutnya adalah menspesifikasikan secara tepat apa yang harus dicapai oleh
sistem, yaitu kriteria kinerja sistem. Misalkan,
- Laporan harus disiapkan dalam bentuk salinan kertas dan tampilan komputer;
- Laporan harus tersedia tidak lebih dari 3 hari setelah akhir bulan;
- Laporan harus membandingkan pendapatan dan biaya actual dengan anggarannya baik
untuk bulan lalu maupun sepanjang tahun hingga sekarang (year to date).
e. Menyiapkan Usulan Rancangan

Analis sistem memberikan kesempatan bagi manajer untuk membuat keputusan teruskan
atau hentikan untuk kedua kalinya. Dalam hal ini manajer harus menyetujui tahap
rancangan dan kungan bagi keputusan tersebut termasuk di dalam usulan rancangan.
f. Menerima atau Menolak Proyek Rancangan
Manajer dan komite pengarah SIM mengevaluasi usulan rancangan dan menentukan
apakah akan memberikan persetujuan atau tidak. Dalam beberapa kasus, tim mungkin
diminta melakukan analisis lain dan menyerahkannya kembali atau mungkin proyek
ditinggalkan. Jika disetujui, proyek maju ke tahap rancangan.
Secara diagram tahapan analisis tampak pada Gambar 3. sedangkan contoh format untuk
dokumen usulan rancangan, yaitu sebagai berikut :
2) Pendahuluan
3) Definisi masalah
5) Kriteria kinerja
6) Berbagai alternatif sistem yang mungkin
7) Rancangan proyek yang disarankan
7.1. Tugas-tugas yang harus dilaksanakan
7.2. Kebutuhan sumber daya manusia
7.3. Jadual kerja
7.4. Perkiraan biaya
8.1. Dampak pada struktur organisasi perusahaan
8.2. Dampak pada operasi perusahaan
8.3. Dampak pada sumber daya perusahaan
9) Rencana pengembangan umum (tahap analisis, rancangan dan penerapan)

10) Ikhtisar
Komite Pengarah SIM Analis Sistem
Manajer
1
Mengumumkan penelitian sistem
2
Mengorganisasikan tim proyek
3
Mendefinisikan kebutuhan informasi
4
Mendefinisikan kriteria kinerja sistem
5
Menyiapkan
usulan rancangan
6
2014 Menerima / menolak
Proyek Pengembangan proyek
Sistem penelitian
Informasi Modul 01 Pusat Bahan Ajar dan eLearning
Gambar.3. Diagram Tahapan Analisis dari SLC
4. TAHAP PERANCANGAN
Rancangan sistem adalah penentuan proses dan data yang diperlukan oleh sistem baru. Jika
sistem itu berbasis komputer, rancangan dapat menyertakan spesifikasi jenis peralatann yang
akan digunakan. Langkah-langkah tahapan rancangan yaitu :
a. Menyiapkan rancangan sistem yang terinci

Analis bekerja sama dengan pemakai dan mendokumentasikan rancangan sistem baru
dengan alat-alat yang dijelaskan dalam modul teknis. Beberapa alat memudahkan analis
untuk menyiapkan dokumentasi secara top-down, dimulai dengan gambaran besar dan
secara bertahap mengarah lebih rinci. Pendekatan top-down ini merupakan ciri rancangan
terstruktur (structured design), yaitu rancangan bergerak dari tingkat sistem ke tingkat
subsistem. Alat-alat dokumentasi yang popular yaitu diagram arus data (data flow diagram),
diagram hubungan entitas (entity relationship duagram), kamus data (data dictionary),
flowchart, model hubungan objek, dan spesifikasi kelas.
b. Mengidentifikasi berbagai alternatif konfigurasi sistem

Analis mengidentifikasi konfigurasi – bukan merek atau model – peralatan komputer yang
akan memberikan hasil yang terbaik bagi sistem dalam menyelesaikan pemrosesan.
Identifikasi merupakan suatu proses berurutan, dimulai dengan berbagai kombinasi yang
dapat menyelesaikan setiap tugas.
c. Mengevaluasi berbagai alternatif konfigurasi sistem

Analis bekerja sama dengan manajer mengevaluasi berbagai alternatif. Alternatif yang dipilih
adalah yang paling memungkinkan subsistem memenuhi kriteria kinerja, dengan kendala-
kendala yang ada.
d. Memilih konfigurasi terbaik
Analis mengevaluasi semua konfigurasi subsistem dan menyesuaikan kombinasi peralatan
sehingga semua subsistem menjadi satu konfigurasi tunggal. Setelah selesai, analis
membuat rekomendasi kepada manajer untuk disetujui. Bila manajer menyetujui konfigurasi
tersebut, persetujuan selanjutnya dilakukan oleh SC MIS.
e. Menyiapkan usulan penerapan

Analis menyiapkan usulan penerapan (implementation proposal) yang mengikhtisarkan
tugas-tugas penerapan yang harus dilakukan, keuntungan yang diharapkan, dan biayanya.
f. Menyetujui atau menolak penerapan sistem

Keputusan untuk terus pada tahap penerapan sangatlah penting, karena usaha ini akan
sangat meningkatkan jumlah orang yang telibat. Jika keuntungan yang diharapkan dari
sistem melebihi biayanya, maka penerapan akan disetujui.
Secara diagram tahapan analisis tampak pada Gambar 4. sedangkan contoh format untuk
dokumen usulan penerapan, yaitu sebagai berikut :
2) Pendahuluan
3) Definisi masalah
5) Kriteria kinerja
6) Rancangan sistem
- Deskripsi ringkasan
- Konfigurasi peralatan
7) Proyek penerapan yang disarankan
- Tugas-tugas yang harus dilaksanakan
- Kebutuhan sumber daya manusia
- Jadual kerja
- Perkiraan biaya
8.1. Dampak pada struktur organisasi perusahaan
8.2. Dampak pada operasi perusahaan
8.3. Dampak pada sumber daya perusahaan
9) Rencana penerapan umum

10) Ikhtisar
Komite Analis Sistem

Manajer
Pengarah
SIM
1. Menyiapkan rancangan
sistem terinci
2. Mengidentifikasi alternatif
konfigurasi sistem
3. Mengevaluasi alternatif
konfigurasi sistem
Mengatur
4. Memilih konfigurasi
terbaik
5. Menyiapkan usulan
penerapan
6. Menyetujui / menolak
penerapan sistem
Gambar 4. Diagram Tahapan Perancangan dari SLC
5. TAHAP PENERAPAN
Penerapan merupakan kegiatan memperoleh dan mengintegrasikan sumber daya fisik dan
konseptual yang menghasilkan suatu sistem yang bekerja. Adapun tahapannya yaitu :
a. Merencanakan penerapan;
Manajer dan spesialis informasi harus memahami dengan baik pekerjaan yang diperlukan
untuk menerapkan rancangan sistem dan untuk mengembangkan rencana penerapan yang
sangat rinci.
b. Mengumumkan penerapan;
Proyek penerapan diumumkan kepada para pegawai dengan cara yang sama pada
penelitian sistem. Tujuannya adalah untuk menginformasikan kepada para pegawai
mengenai keputusan untuk menerapkan sistem baru dan meminta kerjasama mereka.
c. Mendapatkan sumber daya perangkat keras;

Rancangan sistem disediakan bagi para pemasok berbagai jenis perangkat keras yang
terdapat pada konfigurasi sistem yang disetujui. Setiap pemasok diberikan request for
proposal (RFP), yang berisi antara lain :
- Surat yang ditransmisikan

- Tujuan dan kendala sistem
- Rancangan sistem : deskripsi ringkasan, kriteria kerja, konfigurasi peralatan,
dokumentasi sistem ringkasan, perkiraan volume transaksi, perkiraan ukuran file.
- Jadual pemasangan
Selanjutnya mereka membuat usulan tertulis, bagaimana peralatan yang diusulkan akan
membuat sistem mencapai kriteria kinerjanya. Ketika semua usulan telah diterima dan
dianalisis, SC MIS memilih satu pemasok atau lebih. Spesialis informasi memberi dukungan
bagi keputusan tersebut dengan mempelajari usulan dan membuat rekomendasi. Setelah
disetujui, perusahaan melakukan pemesanan.
d. Mendapatkan sumber daya perangkat lunak;

Ketika perusahaan memutuskan untuk menciptakan sendiri perangkat lunak aplikasinya,
programmer menggunakan dokumentasi yang disiapkan oleh analis sistem sebagai titik
awal. Programmer dapat menyiapkan dokumentasi yang lebih rinci seperti flowchart atau
bahasa semu (psedudo code) yang terstruktur, dilakukan pengkodean, dan pengujian
program. Hasil akhirnya adalah software library dari program aplikasi. Jika peangkat lunak
aplikasi jadi (prewritten application software) dibeli, pemilihan pemasok perangkat lunak
dapat mengikuti prosedur yang sama seperti yang digunakan untuk memilih pemasok
perangkat keras, yaitu RFP dan Usulan.
e. Menyiapkan database;
Pengelola database (database administrator – DBA) bertanggung jawab untuks emua
kegiatan ynag berhubungan dengan data, dan mencakup persiapan database. Hal tersebut
memerlukan pengumpulan data baru atau data yang telah ada perlu dibentuk kembali
sehingga sesuai dengan rancangan sistem baru dan menggunakan sistem manajemen basis
data (database management sistem – DBMS).
f. Menyiapkan fasilitas fisik;

Jika perangkat keras dan sistem baru tidak sesuai dengan fasilitas yang ada, perlu dilakukan
konstruksi baru atau perombakan. Sehingga pembangunan fasilitas tersebut merupakan
tugas berat dan harus dijadualkan sehingga sesuai dengan keseluruhan rencana proyek.
g. Mendidik peserta dan pemakai;

Sistem baru kemungkinan besar akan mempengaruhi banyak orang. Beberapa orang akan
membuat sistem bekerja. Mereka disebut dengan peserta, yang meliputi operator entry data,
pegawai coding, dan pegawai administrasi lainnya. Semuanya harus dididik tentang peran
mereka dalam sistem. Pendidikan harus dijadualkan jauh setelah siklus hidup dimulai, tepat
sebelum bahan-bahan yang dipelajari mulai diterapkan.
h. Menyiapkan usulan cutover;

Proses menghentikan penggunaan sistem lama dan memulai menggunakan sistem baru
disebut cutover. Ketika seluruh pekerjaan pengembangan hampir selesai , tim proyek
merekomendasikan kepada manajer agar dilaksanakan cutover (dalam memo atau laporan
lisan)
i. Menyetujui atau menolak masuk ke sistem baru;

Manajer dan SC MIS menelaah status proyek dan menyetujui atau menolak rekomendasi
tersebut. Bila manajemen menyetujui maka manajemen menentukan tanggal cutover.
Namun, bila manajemen menolak maka manajemen menentukan tindakan yang harus
diambil dan tugas yang harus diselesaikan sebelum cutover akan dipertimbangkan kembali,
kemudian manajemen menjadualkan tanggal baru.
j. Masuk ke sistem baru.

Ada 4 pendekatan dasar (cutover), yaitu :
1) Percontohan (pilot) yaitu suatu sistem percobaan yang diterapkan dalam satu subset
dari keseluruhan operasi.
2) Serentak (immediate) merupakan pendekatan yang paling sederhana yakni beralih dari
sistem lama ke sistem baru pada saat yang ditentukan.
3) Bertahap (phased), sistem baru digunakan berdasarkan bagian per bagian pada suatu
waktu.
4) Paralel (parallel), mengharuskan sistem lama dipertahankan sampai sistem baru telah
diperiksa secara menyeluruh. Akan memberikan pengamanan yang paling baik terhadap
kegagalan tetapi yang paling mahal, karena kedua sumber daya harus dipertahankan.
Cutover menandakan berakhirnya bagian pengembangan dari siklus hidup sistem.
Penggunaan sistem dapat dimulai sekarang.
Secara diagram tahapan penerapan dari siklus hidup sistem tersebut dapat dilihat pada
Gambar 5.
Komite Pengarah Spesialis Informasi
Manajer
SIM
1. Merencanakan Penerapan
2. Mengumumkan Penerapan
3. Mendapatkan SD -
Hardware
4. Mendapatkan SD -
Software
Mengontrol
Mengontrol
Mengontrol
5. Menyiapkan database
6. Menyiapkan Fasilitas
Fisik
7. Mendidik Peserta &

Users
8. Menyiapkan Usulan
Ganti Sistem
9. Menyetujui atau Menolak
Penggantian Sistem Baru
10. Ganti Sistem Baru
Gambar 5. Diagram Tahapan Penerapan (Implementasi) dari SLC
6. TAHAP PENGGUNAAN
Tahap penggunaan terdiri dari 5 langkah, yaitu :
1. Menggunakan sistem
Pemakai menggunakan sistem untuk mencapai tujuan yang diidentifikasikan pada tahap
perencanaan.
2. Audit sistem
Setelah sistem baru mapan, penelitian formal dilakukan untuk menentukan seberapa baik
sistem baru itu memenuhi kriteria kinerja. Studi tersebut dikenal dengan istilah penelaahan
setelah penerapan (post implementation review). Hasil audit dilaporkan kepada CIO, SC MIS
dan pemakai. Proses tersebut diulangi, mungkin setahun sekali, selama penggunaan sistem
berlanjut.
3. Memelihara sistem
Selama manajer menggunakan sistem, berbagai modifikasi dibuat sehingga sistem terus
memberikan dukungan yang diperlukan. Modifikasinya disebut pemeliharaan sistem (sistem
maintenance). Pemeliharaan sistem dilaksakan untuk 3 alasan, yakni :
- Memperbaiki kesalahan
- Menjaga kemutakhiran sistem
- Meningkatkan system
4. Menyiapkan usulan rekayasa ulang

Ketika sudah jelas bagi para pemakai dan spesialis informasi bahwa sistem tersebut tidak
dapat lagi digunakan, diusulkan kepada SC MIS bahwa sistem itu perlu direkayasa ulang
(reengineered). Usulan itu dapat berbentuk memo atau laporan yang mencakup dukungan
untuk beralih pada suatu siklus hidup sistem baru. Dukungan tersebut mencakup penjelasan
tentang kelemahan inheren sistem, statistik mengenai biaya perawatan, dan lain-lain.
5. Menyetujui atau menolak rekayasa ulang sistem

Manajer dan komite pengarah SIM mengevaluasi usulan rekayasa ulang sistem dan
menentukan apakah akan memberikan persetujuan atau tidak.
Komite Pengarah Spesialis Informasi
Manajer
SIM
1.
Mengatur Menggunakan
Sistem 2. Pengaudit Sistem
3. Memelihara
Sistem
4. Mempersiapkan
Usulan Rekayasa
Ulang
5. Menyetujui / menolak
rekayasa ulang sistem
Gambar 6. Diagram Tahapan Penggunaan dari SLC
Guna memberi respon yang lebih baik bagi kebutuhan pemakai, spesialis informasi telah
membuat modifikasi pada SLC, sehingga waktu yang diperlukan untuk menerapkan sistem
dapat dikurangi. Hal tersebut yang banyak mendapat perhatian yaitu protipe (prototyping) dan
pengembangan aplikasi cepat (Rapid Application Development – RAD).
a. Prototipe (Prototyping).
Prototype memberikan ide bagi pembuat dan pemakai potensial tentang cara sistem
berfungsi dalam bentuk lengkapnya. Proses akan menghasilkan prototype (prototyping).
Adapun jenis-jenis Prototipe, yaitu :
Prototype jenis I, sesungguhnya akan menjadi sistem operasional. Langkah-langkah

pengembangannya adalah sebagai berikut :
Mengidentifikasi
Kebutuhan Pemakai
Mengembangkan
Prototipe
Prototipe Tidak
dapat
diterima ?
Ya
Menggunakan
Prototipe
Gambar 7. Pengembangan Prototipe Jenis I
Prototype jenis II, merupakan suatu model yang berfungsi sebagai cetak biru bagi sistem
operasional. Langkah-langkah pengembangannya adalah sebagai berikut :
Mengidentifikasi
Kebutuhan Pemakai
Mengembangkan
Prototipe
Prototipe
Tidak
dapat
diterima ?
Ya
Mengkodekan Sistem
Operasional
Menguji Sistem
Operasional
Sistem
Tidak
dapat
diterima ?
Ya
Menggunakan Sistem
operasional
Gambar 8. Pengembangan Prototipe Jenis II
Daya tarik prototype, yaitu :
1) Komunikasi antar analis sistem dengan pemakai membaik.

2) Analis dapat bekerja dengan lebih baik dalam menentukan kebutuhan pemakai.
3) Pemakai berperan lebih aktif dalam pengembangan sistem.
4) Lebih efisien dan dapat menghemat biaya pengembangan.
5) Penerapan lebih mudah.
Potensi kegagalan prototype, yaitu :
1) Bersifat tergesa-gesa.
2) Berharap sesuatu yang tidak realistis dari sistem operasionalnya.
3) Prorotipe I tidak efisien terhadap sistem yang dikodekan dengan bahasa
pemrograman.
4) User interface tidak mencerminkan teknik perancangan yang baik.
Penerapannya mempunyai prospek yang baik, dengan karakteristik sebagai berikut :
1) Risiko tinggi
2) Pertimbangan interaksi pemakai
3) Jumlah pemakai banyak
4) Dibutuhkan penyelesaian yang cepat
5) Perkiraan tahap penggunaan sistem yang pendek
6) Sistem yang inovatif
7) Perilaku pemakai yang sukar ditebak.
b. Pengembangan Aplikasi Cepat (rapid application development – RAD)

RAD merupakan seperangkat strategi, metodologi dan peralatan yang terintegrasi dalam
satu kerangka kerja menyeluruh (information engineering – IE).
Metodologi RAD akan memberi respon yang cepat terhadap kebutuhan pemakai,
tetapi dengan lingkup yang lebih luas.
Unsur-unsur penting RAD, yaitu :
1) Manajemen, harus mendukung RAD sepenuhnya dan menyediakan lingkungan
kerja yang membuat kegiatan tersebut sangat menyenangkan.
2) Manusia, dibentuk beberapa Tim yang terspesialisasi yang dikenal dengan istilah
SWAT (Skilled with advanced tools).
3) Metodologi, yaitu siklus hidup RAD yang terdiri dari perencanaan kebutuhan,
rancangan pemakai, konstruksi, dan cutover.
4) Peralatan, terdiri dari bahasa pemrograman generasi ke-4 dan peralatan CASE
(computer aided software engineering)
7. IKHTISAR
Evolusi sistem berbasis komputer mengikuti suatu pola yang disebut siklus hidup sistem, yang
terdiri dari tahap perencanaan, analisis, rancangan, dan penerapan serta penggunaan. Manajer
dari area pemakai terlibat dalam perencanaan dengan maksud agar proyek akan memperoleh
manfaat. Analis sistem membantu manajer dalam pendefinisian masalah, menetapkan tujuan
dan mengenai kendala-kendala serta studi kelayakan.
Tahap analisis dimulai dengan pengumuman kepada para pegawai dan dibentuknya tim proyek.
Kegiatan yang dilakukan yaitu pemakai mendefinisikan kebutuhan informasi, menentukan
kriteria kinerja, menyiapkan usulan rancangan untuk merancang sistem baru.
Tahap rancangan mulai saat analis terlibat dalam rancangan sistem yang terinci, dengan
menggunakan teknik-teknik dan peralatan terstruktur yang mendokumentasikan proses dan
data. Dilakukan pula identifikasi konfigurasi sistem alternatif dan dievaluasi, dan yang terbaik
dipilih. Diajukan usulan penerapan yang akan memberi dasar untuk menciptakan suatu sistem
kerja dari dokumentasi rancangan.
Tahap penerapan melibatkan para spesialis informasi lainnya, pemakai tambahan dan mungkin
orang luar seperti konsultan dan kontraktor. Setelah perancangan yang terinci diperoleh
perangkat keras dan perangkat lunak serta dibuat database. Ketika fasilitas fisik telah siap dan
pendidikan yang diperlukan telah dilaksanakan, manajemen menentukan apakah cutover ke
sistem baru perlu dilaksanakan. Apabila sistem tersebut dianggap tidak bisa digunakan lagi,
pihak manajemen dapat mengotorisasi proyek rekayasa ulang, yang mengulang siklus hidup
sistem.
Setelah tahap penggunaan dimulai, analis sistem dan auditor internal melaksanakan
penelaahan pasca penerapan, yang diulang secara berkala sepanjang umur hidup sistem.
Spesialis informasi juga melakukan pemeliharaan sistem.
Meskipun siklus hidup sistem mewakili bentuk dasar dari kerja sistem, siklus hidup sistem
terpengaruh perubahan metodologi lain yang menekankan penggunaan peralatan
pengembangan berbasis komputer. Salah satunya yaitu rapid application development – RAD
yang menyatukan baik CASE maupun prototyping.
PERTANYAAN / DISKUSI :
1. Apakah perbedaan antara SLC dan SDLC ?

2. Sebutkan fungsi dari SC MIS ?
3. Apakah perbedaan antara studi kelayakan dan penelitian sistem ?
4. Bagaimana cara yang paling efektif bagi analis sistem untuk menentukan kebutuhan
pemakai informasi ?
5. Apakah hubungan antara rancangan terstruktur dengan tingkatan sistem ?
6. Apa yang dimaksud dengan cutover dalam penerapan sistem ?
7. Sebutkan dan jelaskan jenis-jenis cutover !
8. Apakah hubungan antara SPIR dan IE ?
9. Pada tahap SLC mana yang menyertakan kegiatan pengumuman kepada karyawan ? Apa
tujuan kegiatan tersebut ?
10. Sebutkan dan jelaskan unsur-unsur inti dari RAD !
Daftar Pustaka
1. Martin, Merle P., Analysis And Design of Business Information Sytems, Mac
Millan Publishing Company, New York, 1991.
2. HM., Yogiyanto, Analisis dan Disain Sistem Informasi : Pendekatan Terstruktur,
Penerbit Andi Offset, Yogyakarta, 1995.
3. Martin, Merle P., Analysis And Design of Business Information Sytems, Mac
Millan Publishing Company, New York, 1991.
4. McLeod, Raymond, Management Information System, 7th ed., Prentice Hall, New
Jersey, 1998.
5. McNurlin, Barbara C,; Sparague, Ralph H Jr., Information Systems Management in
Practice, 4th ed., Prentice Hall, New Jersey, 1998.
MODUL PERKULIAHAN
PROYEK
PENGEMBANGAN
SISTEM
INFORMASI
Modul Standar untuk
02
Abstract Kompetensi
Requierment Determination
SDLC adalah proses pembuatan systems yang memindahkan keadaan sistem yang sekarang ke sistem
yang diharapkan. Output dari perencanaan adalah system request yang berisi penjelasan umum
mengenai sistem yang akan datang, cakupan project, dan menyediakan rencana kerja. Tahapan analisis
mengolah system request menjadi requirements definition, functional models, structural models, and
behavioral models yang akan menjadi bagian dari system proposal. System proposal berisi project
management deliverables seperti feasibility analysis dan rencana kerja.
System proposal akan diserahkan kepada komite yang akan menilainya. Komite akan menentukan
apakah proposal akan diteruskan atau tidak. Walkthrough terhadap proposal dilakukan secara
terperinci, yang tujuannya adalh para pengguna, manajer, dan pengambil keputusan utama dapat
memahaminya secara jelas, dapat mengidentifikasi perbaikan, dan dapat membuat keputusan apakah
project harus dilanjutkan atau tidak. Jika disetujui, system proposal akan bergerak kedalam tahapan
design, dan requirements definition, functional models, structural models, and behavioral models akan
menjadi dasar/sebagai input didalam tahapan perancangan.
Garis antara perancangan dan analisis bersifat remang-remang. Karena deliverables yang dibuat pada
saat analysis merupakan tahap awal dari perancangan sistem yang baru. Banyak pengambilan keputusan
yang berhubungan dengan dengan perancangan ditemukan pada saat analysis. Yang harus diingat
adalah ada sebagian kecil tahapan sudah dilakukan pada tahap ini.
Requirement determination adalah langkah yang paling kritis dari SDLC, karena element dasar dari
sistem harus ditentukan pada tahapan ini. Banyak penelitian yang menyebutkan bahwa kegagalan
terjadi karena penentuan requirements. Karena itu salah satu bagian dari pendekatan dari pendekatan
OO adalah iterative.
Selanjutnya akan dijelasakan apakah yang dimaksud dengan requirement determination yang menjadi
tahapan dari analisa sistem.
Requirement Determination
Tujuan dari requirement determination adalah untuk merubah very hight level explanation of the
business requirement menjadi daftar yang lebih jelas dari requirement yang dapat digunakan
sebagai input untuk analysis (membuat , functional models, structural models, and behavioral
models)
Pengertian Requirement
Requirement adalah pernyataan apa yang harus dilakukan oleh sistem atau karakteristik apa yang
harus dimiliki :
1. Didalam tahapan analisis requirement ditulis dari sudut pandang business, atau apa yang
dilakukan oleh sistem. Fokusnya ada pada "WHAT". Fokusnya ada pada user needs,
sehingga biasanya disebut business requirements.
2. Selanjutnya didalam tahapan design, business requirement bergerak menjadi lebih teknis,
dan akan menjelaskan bagaimana (HOW) sistem akan diimplementasikan. Requirement
pada saat design dilihat dari sudut pandang pembuat sistem (developer).
Yang harus diperhatikan bahwa pembatas antara analisis dan perancangan remang-remang.
Beberapa pihak menggunakan istilah tersebut secara bolak-balik. Yang harus diperhatikan adalah
requirement adalah pernyataan apa yang harus dilakukan oleh sistem dan selalu da kemungkinan
untuk berubah. Secara umum requirement terbagi dua yaitu :
1. Functional requirement. Requirement ini berelasi langsung dengan dengan proses yang
harus dilakukan oleh sistem yang akan dibuat sehingga dapat menyediakan informasi
yang diperlukan. Functional requirement mengalir langsung kedalam tahapan analisis
selanjutnya, karena mendefinisikan fungsi-fungsi yang harus dimiliki oleh sistem.
Perhatikanlah Gambar 1 mengenai Functional Requirements
2. Nonfunctional requirement. Requirement ini berhubungan dengan behavioral properties

yang harus dimiliki oleh sistem, seperti performance and usability. menjelaskan
bermacam-macam karakteristik sistem : operational, performance, secutiry, cultural and
political. Karakteristik tersebut tidak menjelaskan business process ataupun informasi
yang diperlukannya, tetapi sangat penting untuk dpat memahami apa yang harus dimiliki
oleh sistem final. Perhatikanlah Gambar 2 mengenai Nonfunctinal Requirements
Gambar 1. Contoh Functional Requirement
Gambar 2 Contoh Non Functional Requirement
Requirement Definition
Requirement definition report biasanya hanya disebut requirement definition adalah text report
yang berisi daftar functional dan nonfunctinal requirement. dalam bentuk outline. Daftarnya
dibuat secara berurut dan diberi nomer supaya jelas, Sebagaimana digambarkan pada gambar 1
dan gambar 2 requirement dibuat daftarnya. Selanjutnya dibuatkan prioritasnya. Tujuan
terpenting dari requirement determination adalah menentukan tahapan dari sistem. Kalau ada
kebingunan dokumen bertindak sebagai alat klarifikasi.
Determining Requirements
Didalam menentukanUntuk menentukan requirement diperlukan pemahaman business dan IT.
Hal ini bisa dianalogikan seperti membuat bangunan. Jika kita pemilik tumah, maka kita tahu apa
yang kita inginkan dari rumah kita, tetapi kita tidak akan dapat membuatrancangan rumah.
Demikan juga dengan seorang ahli bangunan sipil atau arsitek tidak akan dapat menentukan
bentuk bangunan dengan baik meskipun memiliki kemampuan teknis untuk dapat
menggambarkannya jika tidak berkomunikasi dengan orang yang akan menggunakan bangunan
tersebut. Karena pendekatan terbaik adalah mempekerjakan ahli business dan IT bersama-sama
untuk membuat analisa sistem. Kadang kala pengguna tidak tahu secara tepat apa yang
diinginkannya maka analis akan membantunya dengan teknik/perangkat/notasi dan pemahaman
yang dimilikinya. Teknik yang populer untuk melakukan analisis adalah :
 Business process Automation.
 Business Process Improvement.
 Business Process Reengineering.
Ketiga teknik yang disebutkan di atas memiliki cara kerja yang sama yaitu :
 Membantu user untuk menjelaskan sistem dan proses yang sekarang (as-is).
 Identifikasi apa yang akan dirubah.
 Membuat konsep untuk sistem yang baru.
Membuat Reqirement Definition

Requirement definition haruslah dibuat mutakhir karena akan digunakan untuk referensi dan
pemahaman sistem yang akan dibuat. Membuat Requirement Definition sifatnya itterative dan
berkesinambungan yang meliputi :
1. Mengumpulkan informasi dengan teknik yang diperlukan (interviews, document analysis,

dan lain-lain
2. Melakukan informasi untuk mengidentifikasi business requirement untuk sistem yang

akan dibuat.
3. Menambahakan requirements kedalam requirement definition reportyang akan digunakan

untuk menentukan pekerjaan.
Untuk membuat requirement definition, project team harus menentukan jenis -jenis dari
functional dan nonfunctional requirement dari sistem yang akan dibuat. Penentuan requirements
tersebut menjadi bagian utama dari dokumen yang akan dibuat. Selanjutnya analis akan
menggunakan bermacam-macam teknik untuk menentukan requirement seperti interview dan
observation untuk untuk mengumpulkan informasi, dan membuat daftar business requirement
yang teridentifikasi dari informasi diatas. Dan akhirnya bersama-sama dengan dengan seluruh
tim dan user akan melakukan :
1. Verifikasi
2. Perubahan
3. Melengkapi
4. Menentukan prioritas dari requirement.
Process akan berkesinambungan , dan requirement akan berevolusi jika requirement sudah
teridentifikasi dengan baik maka pekerjaan akan bergerak ke tahapan selanjutnya dari SDLC.
EVOLUTION OF REQUIREMENT harus secara hati-hati dikelola karena jika tidak akan ada
proliferasi requirment yang tak terkendali. Sehingga akan menyebabkan sistem tidak pernah
selesai dan selalu tumbuh diluar cakupan sistem. Ketika requirement mencerminkan kebuatuhan
business di dunia nyata dan bukan didalam sistem yang sekarang dibuat maka dimasukkan
kedalam requirement dimasa yang akan datang dan diberi nomor prioritas yang lebih rendem.
Pengelolaan requirement (dan cakupan dari sistem yang akan dibuat) merupakan bagian yang
paling berat dari pembuatan sistem.
Requirements Analysis Techniques.

Sebelum project team dapat menentukan requirement apa yang tepat untuk sistem yang akan
dibuat, mereka harus memiliki visi yang jelas sistem apa yang akan dibuat, dan tingkat
perubahan apa yang akan terjadi pada organisasi. Proses dasar analisis terbagi menjadi tiga
tahapan :
1. Mamahami sistem yang sekarang
2. Mengidentifikasi peningkatan
3. Membuat/mengumpulkan requirement untuk sistem yang akan dibuat.
Kadang-kadang langkah yang pertama dilewati jika tidak ada sistem yang ada atau hanya
dilakukan sepintas pada methodology seperti RAD dan Agile. Sedangkan pada metodologi
seperti waterfamm dan pararel development menggunakan waktu yang cukup panjang untuk
menganalisa sistem yang sudah ada dan mengidentifikasi perbaikan yang mungkin dilakukan
sebelum mealukan requirement gathering. Sementara itu metodologi yang berfokus pada
peningkatan dan requirement system yang akan dibuat akan melakukan investigasi terhadap
sistem yang sekarang berjalan secara sepintas saja. Metodologi tersebut adalah :
1. Generasi baru RAD
2. Agile
3. OO methodologies
4. phased development
5. prototyping
6. throwaway prototyping
7. XP
Ada tiga tehnik yang digunakan sebagaimana disebutkan diatas yaitu Business process
Automation, Business Process Improvement, dan Business Process Reengineering. Ketiga tehnik
tersebut membantu analis melakukan analisa sehingga visi dari sistem dapat dikembangkan
dengan baik. Tehnik Requirement analysis yang disebutkan diatas akan digunakan bersama-sama
dengan requirement-gathering techniques yang meliputi :
1. Interviews
2. JAD Session
3. questionaires
4. document analysis
5. observation.
Requirement analysis techniques akan menentukan jenis informasi apa yang akan dikumpulkan
dan bagaimana analisanya. Kedua jenis tehnik tersebut bersifat komplementer. Pilihan tehniknya
akan menentukan bentuk perubahan yang akan terjadi di dalam organisasi :
1. BPA digunakan untuk menangani perubahan kecil yang berhubungan dengan otomasi
proses.
2. BPI digunakan untuk melakukan perbaikan proses untuk memperbaiki efektifitas dan
efisiensi kerja
3. BPR merubah bagaimana cara organisasi bekerja sehingga yang terjadi adalah
transformasi organisasi ke bentuk yang lebih baik.
Untuk menggerakkan pengguna menggunakan sistem yang baru analis harus memiliki
kemampuan berpikir kritis yang tingi. Kemampuan berpikir kritis adalah kemampuan untuk
memahami strengths dan weaknesses dan membentuk kembali idea yang sudah ada menjadi
bentuk yang lebih baik sehingga. Idea tersebut digunakan untuk memahami issues dan
mengembangkan business process yang baru. Kemampuan ini diperlukan untuk mempelajari :
1. Hasil dari requirements gathering
2. Identifikasi business requirement
3. menterjemahkan requirements menjadi sistem yang baru.
Business Process Automation
BPA artinya tetap menggunakan cara bagaimana organisasi bekerja, tetapi menggunakan
teknologi komputasi untuk mengerjakan beberapa pekerjaan yang harus dilakukan. BPA dapat
membuat organisasi bekerja lebih effisien tetapi mempunya pengaruh yang lebih kecil
dibandingkan dengan ketiga tehnik tersebut diatas. BPA akan mempelajari sistem yang sedang
berjalan dengan seksama dan pada akhirnya akan memperbaiki system requirements yang dibuat.
Problem analysis dan Root Cause Analysis adalah 2 cara BPA yang cukup ngetop :
1. Problem Analysis. Adalah cara langsung requirment analysis. Problem analysis artinya
bertanya kepada user dan managers untuk melakukan identifikasi problem dengan sistem
yang sekarang sudah ada dan menjelaskan penyelesaian permasalahan yang terjadi
didalam sistem. Hampir semua pengguna sistem memiliki ide bagaimana perbaikan
dilakukan. Perbaikan proses dari problem analysis biasanya sedikit dan bersifat
incremental. Jenis pebaikan ini biasanya efektif untuk memperbaiki efisiensi sistem.
Tetapi basanya monetary benefits yang diperoleh tidak besar. Yang jelas adalah perbaikan
dari sistem yang sudah ada.
2. Root Cause Analys. Problem analysis bekerja berdasarkan asumsi yang bisa saja valid
3. atau tidak valid. Umumnya orang selalu membuat kesimpulan sebelum melakukan
pemikiran mengenai sebab dan akibat . Biasanya kesimpulan atau tindakan yang akan
dilakukan adalah mengobati gejala bukan akar permasalahannya. Didalam dunia nyata
permasalahn untuk perbaikan proses adalah dengan menggunakan root cause. Pemecahan
bisa jadi mengobati gejala, bisa juga akar permasalahan. , tetapi yang jelas tanpa analisa
yang mendalam akan sulit untuk memecahkan permasalahan dan menentukan mana yang
gejala dan mana yang akar permasalahan. Root cause analysis berfokus pada masalah
bukan pada pemecahan masalah.
Business Process Improvement

BPI artinya membuat perubahan moderat dari cara bagaimana organisasi beroperasi, dengan melihat
bagaimana organisasi beroperasi untuk memanfaatkan teknologi yang baru atau apa yang dilakukan
oleh kompetitor. Tujuan dati BPI adalah meningkatkan efisiensi (doing thighs right) dan meningkatkan
efektifitas (doing the right things). Focus BPI adalah meningkatkan business process, sehingga
mempelajari business process yang ada sangat diperlukan untuk perbaikan proses dan membuat sistem
requirement yang baru. BPI menggunakan Duration analysis, activity based-costing, dan information
benchmarking.
1. Duration Analysis memerlukan pembelajaran secara detail proses yang dilakukan didalam sistem
yang sekarang berjalan. Analisis dimulai dengan melihat waktu yang diperlukan secara rata-rata
untuk melakukan business process guna menghasilkan output tertentu. Lalu menghitung waktu
yang diperlukan untuk menyelesaikan setiap pekerjaan/bagian proses didalam business sehari-
hari. Waktu yang diperlukan untuk mengerjakan suatu bagian pekerjaan kemudian ditotal.
Selanjutnya akan diketahui persentase dari pekerjaan tersebut secara keseluruhan. Dari
perbandingan akan dapat dicari permasalahannya dimana. Karena total dari masing-masing
subproses bisa jadi lebih kecil dari waktu yang diperlukan untuk menyelesaikan pekerjaan.
Permasalahan ini terjadi karena :
1. Fragmentasi sub-process tidak baik.
2. Process integration/parrarelization.
2. Activity-Based Costing sama dengan analisa biaya dari setiap sub aktifitas. Jika ternyata biaya
untuk menyelesaikan pekerjaan lebih besar dari biaya untuk melaksanakan seluruh sub proses
maka proses tidak dikelola dengan baik.
3. Informal Benchmarking. Benchmarking artinya membandingkan bagaimana organisasi lain
melakukan business process agar organisasi dapat bekerja dengan lebih baik. Benchmarking
tujuannya adalah agar dapat memperkenalkan idea bahwa karyawan dapat bekerja dengan
lebih baik dengan cara yang baru yang sebelumnya tidak pernah terbayangkan. Informal
Benchmarking adalah istilah dimana karyawan perusahaan berkunjung sebagai customer untuk
perusahaan lain. Misalkan membuat web site untuk universitas, maka team akan melihat web
site bermacam-macam universitas untuk membandingkan apa yang dilakukan.
Business Process Reengineering

Business Process Reenginering (BPR) artinya merubah cara bagaimana organisasi beroperasi,
yaitu merubah cara bagaimana menjalankan business dan membuat perubahan besar karena
danya ide dan teknologi yang baru. Adapun tehnik yang digunakan didalam BPR adalah :
1. Outcome Analysis yang berfocus pada pemahaman dari produk yang memberikan nilai
yang lebih baik kepada customer.
2. Technology Analysis yang tujuannya adalah untuk menerapkan bagaimana analis dan
manager untuk membuat list/daftar teknologi apa saja yang akan dibuat atau
dimanfaatkan, untuk selanjutnya menentukan apa yang akan diterapkan didalam business
process.
3. Activity Elimination. Activity elimination adalah menghilangkan aktifitas yang kurang

produktif dan menggantikannya dengan aktifitas yang produktif.
Pemilihan Teknik yang Tepat
Untuk dapat melakukan pemilihan teknik atau mencampur teknik yang tepat perlu diperhatikan
strength dan weakness dari :
1. Potential Business Value. Nilai tambah yang dihasilkan oleh tehnik yang dipilih.
2. Project Cost. Biaya yang ditimbulkan dari tehnik yang dipilih.
3. Breadth of Analysis. Cakupan analisis yang apakah analisis meliputi :
1. business process dalam satu fungsi business
2. process yang menjangkau seluruh organisasi
3. process yang berinteraksi dengan seluruh customer dan organisasi.
4. RiskResiko kegagalan, yang diakibatkan oleh rancangan yang tidak baik, kebutuhan yang
tidak terpenuhi atau perubahan radikal yang tidak dapat ditangani oleh organisasi,
sehinga resikonya menjadi semakin besar.
Selanjutnya perhatikanlah matriks pemilihan tehnik pada gambar 3 mengenai Strategi dari
analisa proses bisnis.
Gambar 3 Karakteristik dari Stategi Analisa Proses.
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and Design
Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002
MODUL PERKULIAHAN
PROYEK
PENGEMBANGAN
SISTEM
INFORMASI
Modul Standar untuk
03
Abstract Kompetensi
Input Output Analysis

Perancangan Struktur Menu Tampilan
Struktur Menu Program Keseluruhan
Gambar 1. Perancangan struktur menu program keseluruhan
Struktur Menu Utama
Gambar 2. Perancangan struktur menu utama
Struktur Menu File
Gambar 3. Perancangan struktur menu file
Struktur Menu Record
Gambar 4. Perancangan struktur menu record
Struktur Menu Proccess
Gambar 5. Perancangan struktur menu proccess
Struktur Menu Report
Gambar 6. Perancangan struktur menu report
Struktur Menu Help
Gambar 7. Perancangan struktur menu help
Struktur Menu Utility
Gambar 8. Perancangan struktur menu utility
Perancangan Input Output

Form Login
Pada rancangan layar Login, User harus measukkan Username dan
Password untuk dapat memasuki layar menu utama. Apabila user salah
measukkan password, maka akan muncul pesan “invalid user ID or password”.
Berikut rancangan layar login pada Gambar 11
Gambar 9. Tampilan form login
Keterangan gambar :
 Username
Admin harus memasukkan usernamenya dengan benar
 Password
Admin harus memasukkan password dengan benar.
 Login
Untuk memasuki layar menu admin apabila username dan password sesuai.
Layar Menu Utama

Setelah login berhasil operator dapat melakukan transaksi pembayaran
atau input data baru dengan menggunakan fasilitas yang tersedia pada form menu,
dalam bentuk menubar yang ter diri atas:
 File
Pada menubar File berisi menu item Loogoff dan Exit. Data Operator
digunakan untuk melakukan login untuk operator baru, dan untuk mengakhiri
program dari menu file.
 Record
Pada menubar Record menyediakan fasilitas bagi operator data entry untuk
melakukan penambahan dan pengeditan beberapa data antra lai : data
pengirim, data penerima, data karyawan dan data parameter.
 Proceess
Pada menubar process ini digunakan untuk memproses suatu transaksi yang
berlangsung, proses konfirmasi penerimaan dan proses penagihan atas
beberapa transaksi.
 Report
Pada menubar report ini operator data entry dapat melihat bebrapa data
diantranya adalah data pengirim, data penerima, data tagihan dan data tagihan
yang kemudian dapat dicetak sebagai dibuat laporan.
 Help
Apabila didalam pengoperasian aplikasi ini menemui sebuah masalah maka
menu ini mungkin bisa membantu para pengguna untuk menyelesaikan
masalah yang didapatkan dalam aplikasi ini.
 BussinessSetup
Pada menubar ini bila seorang user berstatus admin maka ia dapat
menggunakan menubar ini untuk menambah user, dan mengedit data
rekening perusahaan tersebut.
Gambar 10. Tampilan Form Utama (mainform).
Tampilan Form Data Pengirim

Form ini digunakan untuk melihat data dan menginput data pengirim serta
untuk menanipulasi dan menghapus data pengirim, pada form ini berisi beberapa data
sebagai berikut :
4. Kode Pengirim, berisi kode dari pengirim.
5. Nama Pengirim, menjelaskan nama pengirim dengan jelas.
6. Alamat, untuk mengetahui data alamat pengirim dengan benar.
7. Telpon, untuk alat komunikasi dengan pengirim.
Form ini juga menyediakan tabel untuk kita dapat melihat dan merubah input
data juga hasil data yang sudah masuk. Form ini juga menyediakan tombol simpan,
buat baru dan hapus untuk mengkoreksi atau menghilangkan data yang sudah ada.
Gambar 11. Tampilan form data pengirim
3. Tampilan Form Tambah Data Pengirim

Selain dengan menggunakan form transaksi untuk menambah data pengirim
form ini juga dapat digunakan untuk menambahkan data pengirim diantaranya :
Gambar 12. Tampilan form tambah data pengirim
Tampilan Form Data Penerima

Form ini digunakan untuk melihat data dan menginput data penerima serta
untuk menanipulasi dan menghapus data penerima, pada form ini berisi beberapa data
sebagai berikut :
5. Kode Penerima, berisi kode dari penerima.
6. Nama Penerima, menjelaskan nama penerima dengan jelas.
7. Alamat, untuk mengetahui data alamat penerima dengan benar.
8. Telpon, untuk alat komunikasi dengan penerima.
Gambar 15. Tampilan form data penerima
Tampilan Form Tambah Data Penerima

form ini juga dapat digunakan untuk menambahkan data penerima diantaranya :
Gambar 13. Tampilan form tambah data penerima
Tampilan Form Data Karyawan
Form ini digunakan untuk melihat data dan menginput data karyawan serta
untuk menanipulasi dan menghapus data karyawan, pada form ini berisi beberapa
data sebagai berikut :
4. Kode Karyawan, berisi kode dari karyawan.
5. Nama Karyawan, menjelaskan nama karyawan dengan jelas.
6. Alamat, untuk mengetahui data alamat karyawan dengan benar.
7. Telpon, untuk alat komunikasi dengan karyawan.
Gambar 14. Tampilan form data karyawan
Tampilan Form Tambah Data Karyawan

form ini juga dapat digunakan untuk menambahkan data karyawan diantaranya :
Gambar 15. Tampilan form tambah data karyawan
Tampilan Form Data Transaksi Pengiriman

data juga hasil data yang sudah masuk dari sebuah proses transaksi pengiriman.
Form ini juga menyediakan tombol simpan, buat baru dan hapus untuk mengkoreksi
atau menghilangkan data yang sudah ada
Gambar 16. Tampilan form data transaksi
4. Tampilan Form Tambah Transaksi Pengiriman

Setelah kita menampilkan form utama proses transaksi pengiriman dan untuk
menambahkan data transaksi yang baru dengan mengklik tombol tambah (add),
maka form yang selanjutnya ditampilkan adalah form berikut ini :
Gambar 17. Tampilan form tambah transaksi
Tampilan Form Konfirmasi Transksi Pengiriman

Form ini adalah digunakan untuk memproses konfirmasi atas transaksi-
trasaksi yang dikirim
Gambar 18. Tampilan form konfirmasi pengiriman
Tampilan Form Proses Penagihan

Pada form poses penagihan ini digunakan oleh operator untuk membuat atau
memproses tagihan kepengirim atas transaksi-transaksi yang telah dilakukan dan
dianggap benar, operator dapat melakukan proses penagihan berdasarkan tanggal dan
kode pengirim :
Gambar 19. Tampilan form proses penagihan
Tampilan Form Proses Penagihan untuk Melihat Detail Tagihan

Setelah melakukan proses penagihan dan kita ingin melihat detail dari nomor
tagihan tersebut, maka kita dapat mengklik tabpane yang berada disebelah kanannya.
Form ini berisi data-data tagihan.
Gambar 20. Tampilan form detail tagihan

Pada form proses penagihan
Tampilan Form Parameter untuk Kota Pengiriman

Karena pada pada proses pengiriman barang atau paket itu oleh beberapa
kriteria, akan tetapi hal yang paling menentukan banyak atau sedikitnya biaya yang
dibutuhkan yaitu kota tujuan atau jarak jauh dekatnya tujuan dari penerima barang
tersebut. Oleh karena itu dibutuhkan sebuah ukuran untuk menentukan biaya yang
dibuhkan, dan untuk keperluan tersebut maka dapat di lakukan pada form berikut ini
:
Gambar 21. Tampilan form parameter kota
Tampilan Form Parameter untuk Sifat Pengiriman

Pada form ini berguna untuk memberikan informasi sifat dari pengiriman dan
dapat dijadikan acuan untuk menghitung biaya yang dibutuhkan, sehingga kita dapat
membrikan pilhan kepada pelanggan (pengirim) untuk apat memilih sifat pengiriman
yang dipilih sesuai dengan kebutuhan.
Gambar 23. Tampilan form parameter sifat
Tampilan Form Parameter untuk Jenis Pengiriman

Pada form ini berguna untuk memberikan informasi jenis dari pengiriman
dan dapat dijadikan sebagai sebuah data tambahan didalam proses transaksi
pengiriman.
Gambar 24. Tampilan form parameter jenis
Tampilan Form Laporan Data Penerima

Form laporan data penerima ini untuk mncetak data yang berfungsi untuk
laporan dari operator ke manager. Operator hanya mengimput kode penerima lewat
menu drop down yang telah disediakan. Dan bila data yang dipilih telah sesuai maka
data tersebut akan ditampilkan di tabel tersebut.
Gambar 25. Tampilan form laporan data penerima
Tampilan Form Laporan Data Pengirim

Form laporan data pengirim ini untuk mncetak data yang berfungsi untuk
laporan dari operator ke manager. Operator hanya mengimput kode pengirim lewat
Gambar 26. Tampilan form laporan data pengirim
Tampilan Form Laporan Data Transaksi

Form laporan data transaksi ini untuk mncetak data yang berfungsi untuk
laporan dari operator ke manager. Operator hanya mengimput kode pengirim dan
tanggal pengiriman lewat menu drop down yang telah disediakan. Dan bila data yang
dipilih telah sesuai maka data tersebut akan ditampilkan di tabel tersebut.
Gambar 27. Tampilan form laporan data transaksi
Tampilan Form Laporan Data Tagihan

Form laporan data tagihan ini untuk mncetak data yang berfungsi untuk
laporan dari operator ke manager. Operator hanya mengimput nomor tagihan lewat
data-data transaksi yang telah berlangsung selama satu periode tersebut akan
ditampilkan di tabel tersebut.
Gambar 28. Tampilan form laporan data tagihan
Tampilan Form Data Rekening

Apabila yang login adalah seorang admin maka ia dapat membuka form ini.
Form ini digunakan untuk mengisi data rekening dari perusahaan yang bersangkutan.
Gambar 29. Tampilan form laporan data rekening
Tampilan Form Tambah Data User

Form ini digunakan untuk menambah, menghapus serta mengedit data user yang
berhak untuk mngoperasikan aplikasi tersebut.
Gambar 30. Tampilan form tambah user
Tampilan Form Bantuan (Help)

Pada form bantuan ini, untuk dapat mejadi fasilitas tambahan bagi seorang
operator baru yang ingin mengetahui cara penggunaan aplikasi yang dibuat.
8. About
Merupakan menu bantuan yang memberikan informasi tentang penjelasan
pemanfaatan aplikasi tersebut.
Gambar 31. Tampilan Form Bantuan (Help) untuk About
9. Content
beberapa hal.
6. Tata cara konfigurasi dan install
7. Tentang Aplikasi Delivery Sistem version 1.1
8. Tentang pembuat aplikasi (Programer).
9. Sedikit penjelasan tentang bahasa pemrograman Java
Gambar 32. Tampilan form bantuan (help) untuk content
5. Perancangan layar Output

6. Laporan Data Transaksi
Gambar 33. Rancangan output data transaksi
7. Hasil Cetak Data Pengirim Per Kode Pengirim
Gambar 34. Rancangan output data pengirim

Per kode pengirim
Hasil Cetak Data Pengirim Per Kode Penerima
Gambar 35. Rancangan output data penerima

Per kode penerima
Hasil Cetak Data Karyawan
Gambar 36. Rancangan output data karyawan

Per kode karyawan
Laporan Data Penerima
Laporan Data Pengirim
Laporan Data Tagihan
Gambar 39. Rancangan output data tagihan
Implementasi Sistem
Tahap perancangan diikuti oleh tahap implementasi. Menterjemahkan perancangan ke
kode program adalah proses yang relative sederhana dan bersifat mekanis sebab
perancangan yang baik sudah mengambarkan dengan baik apa yang harus dilakukan
dengan bahasa-bahasa pemrograman. Asalkan kita telah melakukan pemodelan dengan
baik (misalnya dengan menggunakan UML yang penulis telah gunakan ) dan
mempergunakan banyak perangakat-perangkat lunak berjenis CASE (Computer Aided
Software Engineering) yang baik, misalnya Rational Rose dan Visual Paradigm yang
penulis gunakan yang akan dengan mudah menterjemahkan model-model kita tadi
kedalam sintak beberapa bahasa pemrograman.
Daftar Pustaka
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4 th,
McGraw Hill, 1992
MODUL PERKULIAHAN
PROYEK
PENGEMBANGAN
SISTEM
INFORMASI
Modul Standar untuk
04
Abstract Kompetensi
Design Database For New System

1. Data dan Informasi
Menurut Turban, Aronson, and Liang (2005) data dan informasi didefinisikan sebagai berikut:
• Data, merupakan sesuatu yang menyangkut barang, kejadian, aktivitas, dan transaksi
yang telah tercatat, diklasifikasikan, dan disimpan namun belum memiliki makna. Data
dapat berupa nilai numerik, alphanumerik, gambar, dan suara.
• Informasi, adalah data yang telah dikelola dalam bentuk tertentu untuk memberikan
makna atau arti bagi penerimanya.
2. Siklus Informasi
• Data dan informasi akan saling berkesinambungan sehingga membentuk suatu siklus
yang disebut information cycle (siklus informasi).
• Data ditangkap oleh indera kemudian menjadi inputan dalam sebuah model untuk
diubah menjadi informasi bagi penerimanya yang nantinya akan membantu
pengambilan keputusan dan menjadi sebuah hasil tindakan.
Gambar 0-1 Siklus informasi
3. Pentingnya data dan informasi
 Data dan informasi sebagai sebuah aset penting perusahaan/organisasi.
 Informasi yang benar dapat menjadikan suatu perusahaan/organisasi memperoleh
margin untuk melakukan aksi.
 Data dan informasi sebagai salah satu parameter kemajuan perusahaan/organisasi
(maturity level).
4. Sistem Basis Data dan Sistem File
Pada sebuah institusi, data merupakan salah satu hal yang sangat penting. Setiap
bagian/divisi dari institusi memiliki data sendiri-sendiri. Tapi setiap bagian pun membutuhkan
sebagian data dari bagian yang lain. Hal ini yang biasa dikenal sebagai “shared data”. Setiap
divisi memiliki aplikasi sendiri-sendiri dalam melakukan manipulasi dan pengambilan data
tersebut. Setiap aplikasi memiliki file-file dalam sistem operasi yang digunakan untuk
menyimpan data-data. Seiring dengan berkembangnya institusi, bertambahnya bagian/divisi,
bertambah pula data dan aplikasi yang digunakan. Bertambahnya aplikasi, bertambah pula file-
file yang dibuat.
Gaya sistem pemrosesan-file tersebut menyebabkan setiap data disimpan dalam bentuk
record dalam berbagai macam file, dan diperlukan aplikasi yang berbeda dalam melakukan
pengambilan record dari, dan penambahan record ke dalam file. Hal ini berlaku pada masa
sebelum adanya Sistem Basis Data (DBMS).
Menyimpan data dalam bentuk file yang berbeda-beda, memiliki kekurangan-kekurangan:

 Data redundancy dan inconsistency.
Dikarenakan programer yang berbeda membuat file dan aplikasi masing-masing,
menyebabkan beragam format dan aplikasi yang dibuat. Bahkan, aplikasi pun dibuat
menggunakan bahasa pemrograman yang berbeda-beda. Lebih jauh lagi, data atau
informasi yang sama bisa terdapat dalam beberapa file yang berbeda. Ini yang disebut
dengan redundancy. Redundancy data ini lama kelamaan akan menyebabkan
inconsystency dari data.
 Kesulitan dalam pengaksesan data.
Dikarenakan setiap aplikasi memiliki file tersendiri untuk penyimpanan dan pengambilan
data, maka jika suatu bagian dari institusi membutuhkan data dari bagian lain, akan
menemui kesulitan. Hal ini dikarenakan aplikasi yang dimiliki bagian tersebut, tidak dapat
membaca file yang terdapat di bagian lain.
 Isolasi data.
Dikarenakan data tersebar dalam berbagai macam file, dan file tersebut dalam beragam
format, pembuatan aplikasi baru akan terasa sulit ketika harus membaca format dari
masing-masing file tersebut.
 Masalah integritas.
Data yang disimpan harus memenuhi hal yang dinamakan dengan consistency constraint.
Jika sebuah constraint berubah, maka seluruh aplikasi yang digunakan harus
mengakomodasinya. Masalah akan muncul, jika constraint melibatkan beberapa data dari
file yang berbeda-beda.
 Masalah keamanan.
Tidak semua pengguna dari basis data dapat mengakses semua data. Hal ini akan sulit
dilakukan jika menggunakan gaya penyimpanan data dalam file.
Gambar 0-2 Perkembangan Database

5. Definisi Basis Data dan Sistem Basis Data (DBMS)
Basis data adalah penyimpanan kumpulan informasi secara sistematik dalam sebuah
komputer sehingga dapat diperiksa menggunakan suatu program komputer untuk memperoleh
informasi dari basis data tersebut. Perangkat Lunak yang digunakan untuk mengelola dan
memanggil query basis data disebut Sistem Manajemen Basis Data (Database Management
System, DBMS). DBMS memiliki karakteristik sebagai berikut:
• Software program
• Supplements operating sistem
• Manages data
• Queries data and generates reports
• Data security
Sedangkan sistem adalah sebuah tatanan yang terdiri atas sejumlah komponen fungsional yang
saling berhubungan dan secara bersama-sama bertujuan untuk memenuhi suatu proses pekerjaan.
Sehingga bisa dikatakan bahwa sistem basis data adalah sistem yang terdiri atas kumpulan file-file yang
saling berhubungan dan dikelola oleh program (DBMS) yang memungkinkan beberapa pemakai dan atau
program lain yang memiliki otoritas untuk mengakses dan memanipulasi data tersebut. Kelebihan
pemakaian DBMS adalah:
• Data berdiri sendiri (Data Independence)

• Pengaksesan data efisien (Efficient data access)
• Integritas data dan keamanan terjamin (Data integrity and security)
• Administrasi data (Data administration)
• Dapat diakses bersamaan (Concurrent access )
• Recovery saat terjadi kegagalan (Crash recovery)
• Mengurangi waktu pembangunan aplikasi (Reduced application development time)
6. Komponen Sistem Basis Data

Komponen-komponen pada sebuah sistem basis data antara lain:
 Perangkat keras
 Sistem operasi
 Basis data
 DBMS (Database Management System)
 Pemakai
 Aplikasi lain
Gambar 0-3 Komponen DBMS
7. Abstraksi Data
Tujuan utama dari sistem basis data adalah untuk menyediakan fasilitas untuk view data
secara abstrak bagi penggunanya. Namun bagaimana sistem menyimpan dan mengelola data
tersebut, hanya diketahui oleh sistem itu sendiri. Abstraksi data merupakan level dalam
bagaimana melihat data dalam sebuah sistem basis data. Berikut ini tiga level abstraksi data:
1. Level fisik
Merupakan level terendah pada abstraksi data yang menunjukkan bagaimana
sesungguhnya data disimpan. Pada level ini pemakai melihat data sebagai gabungan dari
struktur dan datanya sendiri.
2. Level lojik
Merupakan level berikutnya pada abstraksi data, menggambarkan data apa yang
disimpan pada basis data dan hubungan apa saja yang ada di antara data tersebut.
3. Level view
Merupakan level tertinggi dari abstraksi data yang hanya menunjukkan sebagian dari
basis data. Banyak user dalam sistem basis data tidak akan terlibat dengan semua data
atau informasi yang ada atau yang disimpan. Para user umumnya hanya membutuhkan
sebagian data atau informasi dalam basis data yang kemunculannya di mata user diatur
oleh aplikasi end user.
Gambar 0-4 Abstraksi Data.
8. Model Basis Data

 Hierarchical
Memiliki struktur pohon dimana field hanya memiliki satu buah induk (parent), masing-
masing parent memiliki banyak child (anak). Model ini memiliki kecepatan yang baik.
 Network
Relationship dibuat menggunakan linked list (pointer). Berbeda dengan model
hierarchical satu anak dapat memiliki beberapa induk. Model ini memiliki fleksibilitas
yang tinggi.
 Relational
Model ini direpresentasikan dalam tabel dua dimensi, tabel-tabel tersebut memiliki
hubungan yang disebut dengan relasi. Model ini memiliki fleksibilitas dan kecepatan
yang tinggi.
 Object oriented
Object Oriented Database adalah sebuah sistem database yang menggabungkan
semua konsep object oriented seperti pewarisan, abstraksi, enkapsulasi, dll. Model ini
dapat berinteraksi dengan baik dengan bahasa pemrograman berorientasi objek seperti
java dan C++.
9. Perancangan Database
Di dalam suatu organisasi yang besar, sistem database merupakan bagian penting pada sistem
informasi, karena di perlukan untuk mengelola sumber informasi pada organisasi tersebut.
Untuk mengelola sumber informasi tersebut yang pertama kali di lakukan adalah merancang
suatu sistem database agar informasi yang ada pada organisasi tersebut dapat digunakan
secara maksimal.
Tujuan Perancangan Database
 Untuk memenuhi kebutuhan akan informasi dari pengguna dan aplikasi

 Menyediakan struktur informasi yang natural dan mudah di mengerti oleh pengguna
 Mendukung kebutuhan pemrosesan dan beberapa obyek kinerja dari suatu sistem
database
Berikut ini siklus kehidupan sistem informasi di mana terdapat siklus kehidupan sistem
database.
a. Siklus Kehidupan Sistem Informasi (Macro Life Cycle )

Tahapan–tahapan yang ada pada siklus kehidupan sistem informasi yaitu :
1) Analisa Kelayakan
Tahapan ini memfokuskan pada penganalisaan areal aplikasi yang unggul ,
mengidentifikasi pengumpulan informasi dan penyebarannya, mempelajari
keuntungan dan kerugian , penentuan kompleksitas data dan proses, dan
menentukan prioritas aplikasi yang akan digunakan.
2) Analisa dan Pengumpulan Kebutuhan Pengguna
Kebutuhan–kebutuhan yang detail dikumpulkan dengan berinteraksi pada
sekelompok pemakai atau pemakai individu. Mengidentifikasikan masalah yang ada
dan kebutuhan-butuhan, ketergantungan antar aplikasi, komunikasi dan prosedur
laporan.
3) Perancangan
Perancangan terbagi menjadi dua yaitu : perancangan sistem database dan sistem
aplikasi
4) Implementasi
Mengimplementasikan sistem informasi dengan database yang ada
5) Pengujian dan Validasi
Pengujian dan validasi sistem database dengan kriteria kinerja yang diinginkan oleh
pengguna.
6) Pengoperasian dan Perawatan

Pengoperasian sistem setelah di validasi disertai dengan pengawasan dan perawatan
sistem
b. Siklus Kehidupan Aplikasi Database ( Micro Life Cycle )
Tahapan yang ada pada siklus kehidupan aplikasi database yaitu :
1. Pendefinisian Sistem
Pendefinisian ruang lingkup dari sistem database, pengguna dan aplikasinya.
2. Perancangan Database
Perancangan database secara logika dan fisik pada suatu sistem database sesuai
dengan sistem manajemen database yang diinginkan.
3. Implementasi Database
Pendefinisian database secara konseptual, eksternal dan internal, pembuatan filefile
database yang kosong serta implementasi aplikasi software.
4. Pengambilan dan Konversi Data

Database ditempatkan dengan baik, sehingga jika ingin memanggil data secara
langsung ataupun merubah file–file yang ada dapat di tempatkan kembali sesuai
dengan format sistem databasenya.
5. Konversi Aplikasi
Software-software aplikasi dari sistem database sebelumnya di konversikan ke
dalam sistem database yang baru
6. Pengujian dan Validasi

Sistem yang baru telah di test dan di uji kinerja nya
7. Pengoperasian
Pengoperasian database sistem dan aplikasinya
8. Pengawasan dan Pemeliharaan
Pengawasan dan pemeliharaan sistem database dan aplikasi software
10. Proses Perancangan Database
Ada 6 tahap untuk proses perancangan suatu database :
1. Pengumpulan data dan analisis
2. Perancangan database secara konseptual
3. Pemilihan sistem manajemen database
4. Perancangan database secara logika
5. Perancangan database secara fisik
6. Implementasi sistem database
Keterangan :
Secara khusus proses perancangan berisikan 2 aktifitas paralel. Aktifitas yang pertama
melibatkan perancangan dari isi data dan struktur database, sedangkan aktifitas kedua
mengenai perancangan pemrosesan database dan aplikasi–aplikasi perangkat lunak.
Dua aktifitas ini saling berkaitan , misalnya mengidentifikasi data item yang akan disimpan
dalam database dengan cara menganalisa aplikasi–aplikasi database. Dua aktifitas ini juga
saling mempengaruhi satu sama lain. Contohnya tahap perancangan database secara fisik,
pada saat memilih struktur penyimpanan dan jalur akses dari file suatu database dimana
bergantung dengan aplikasi–aplikasi yang akan menggunakan file tersebut.
Penentuan perancangan aplikasi–aplikasi database yang mengarah ke konstruksi skema

database telah ditentukan selama aktifitas pertama.
Ke-enam tahap yang telah disebutkan sebelumnya dapat di proses secara tidak berurutan .
Dalam beberapa hal, dapat dilakukan modifikasi perancangan kembali ke tahap yang pertama
(feedback loop) setelah melakukan tahap selanjutnya.
a. Tahap 1 : Pengumpulan data dan analisis

Sebelum merancang suatu database, yang harus dilakukan adalah mengetahui dan
menganalisis apa yang diinginkan dari pengguna aplikasi, sehingga proses ini disebut
pengumpulan data dan analisis. Untuk menspesifikasikan kebutuhan yang pertama kali
dilakukan adalah mengidentifikasi bagian lain di dalam sistem informasi yang berinteraksi
dengan sistem database. Termasuk pengguna yang baru atau yang sudah lama juga
aplikasinya, kebutuhan–kebutuhan tersebut dikumpulkan dan di analisa.
Kegiatan pengumpulan data dan analisis :
 Menentukan kelompok pemakai dan areal bidang aplikasinya.

Pengguna yang menguasai aplikasi yang lama dari setiap bagian dipilih untuk
menyampaikan kebutuhan-kebutuhan dan menspesifikasikannya.
 Peninjauan dokumentasi yang ada.

Dokumen yang berhubungan dengan aplikasi yang akan dibuat dipelajari dan
dianalisa, sedangkan dokumen lainnya seprti kebijakan manual, form, laporan–laporan
dan bagan-bagan organisasi diuji dan ditinjau kembali untuk mengetahui apakah
dokumen tersebut berpengaruh terhadap pengumpulan data dan proses spesifikasi
 Analisa lingkungan operasi dan kebutuhan pemrosesan.
Lingkungan operasional yang sekarang dan informasi yang direncanakan akan di
gunakan dipelajari, termasuk menganalisa jenis–jenis dari transaksi dan frekuensi
transaksinya seperti halnya alur informasi dengan sistem. Input dan output data untuk
transaksi tersebut harus diperinci.
 Pengumpulan respon terhadap daftar pertanyaan dan angket yang telah dibuat
sebelumnya.
Pengumpulan respon dari angket dan daftar pertanyaan berisikan prioritas para
pengguna dan penempatan mereka di dalam berbagai aplikasi. Ketua kelompok
mungkin akan ditanya untuk membantu para pengguna dalam memberikan informasi
yang penting dan menentukan prioritas.
Teknik yang digunakan dalam penspesifikasian kebutuhan secara formal :
 OOA ( Object Oriented Analysis )

 DFD ( Data Flow Diagram )
 HIPO ( Hierarchical Input Process Output )
 SADT ( Structured Analysis & Design )
b. Tahap 2 : Perancangan database secara konseptual

Tujuan dari tahap ini adalah untuk menghasilkan skema konseptual untuk databse yang
tidak tergantung pada sistem manajemen database yang spesifik. Penggunaan model
data tingkat tinggi seperti ER/EER sering digunakan didalam tahap ini. Di dalam skema
konseptual dilakukan perincian aplikasi–aplikasi database dan transaksi–transaksi yang
diketahui .
Ada dua kegiatan di dalam perancangan database secara konseptual :
 Perancangan skema konseptual :

Pada tahap ini kegiatan yang dilakukan mengecek tentang kebutuhan– kebutuhan
pemakai terhadap data yang dihasilkan dari tahap 1, dimana
tujuan dari proses perancangan skema konseptual adalah menyatukan pemahaman

dalam struktur database, pengertian semantik, keterhubungan dan batasan-
batasannya, dengan membuat sebuah skema database konseptual dengan
menggunakan model data ER/EER tanpa tergantung dengan sistem manajemen
database
Ada dua pendekatan perancangan skema konseptual :
 Terpusat
Kebutuhan–kebutuhan dari aplikasi atau kelompok–kelompok pemakai yang
berbeda digabungkan menjadi satu set kebutuhan pemakai kemudian dirancang
menjadi satu skema konseptual.
 Integrasi view–view yang ada

Untuk masing–masing aplikasi atau kelompok–kelompok pemakai yang berbeda
dirancang sebuah skema eksternal ( view ) kemudian view – view tersebut
disatukan ke dalam sebuah skema konseptual.
Ada 4 strategi dalam perancangan skema konseptual :
 Top down
 Bottom Up
 Inside Out
 Mixed
 Transaksi
Merancangan karakteristik dari transaksi–transaksi yang akan di implementasikan tanpa
tergantung dengan DBMS yang telah dipilih. Transaksi–transaksi ini digunakan untuk
memanipulasi database sewaktu diimplementasikan . Pada tahap ini diidentifikasikan input,
output dan fungsional . Transaksi ini antara lain : retrieval, update dan delete, select dll.
c. Tahap 3 : Pemilihan Sistem Manajemen Database

Pemilihan sistem manajemen database ditentukan oleh beberapa faktor a.l : Teknik,
Ekonomi, dan Politik Organisasi
Faktor Teknik :
 Tipe model data ( hirarki, jaringan atau relasional )
 Struktur penyimpanan dan jalur pengaksesan yang didukung sistem manajemen
database
 Tipe interface dan programmer
 Tipe bahasa queri
Faktor Ekonomi :
 Biaya penyiadaan hardware dan software

 Biaya konversi pembuatan database
 Biaya personalia
 Biaya pelatihan
 Biaya pengoperasian
 Biaya pemeliharaan
Faktor Organisasi :
 Struktur data
Jika data yang disimpan dalam database mengikuti struktur hirarki, maka suatu jenis
hirarki dari sistem manajemen database harus dipikirkan.
 Personal yang terbiasa dengan sistem yang terdahulu

Jika staff programmer dalam suatu organisasi sudah terbiasa dengan sautu sistem
manajemen database maka hal ini dapat mengurangi biaya latihan dan waktu belajar.
 Ketersediaan dari service vendor

Keberadaan fasilitas pelayanan penjual sangat dibutuhkan untuk membantu
memecahkan masalah sistem.
d. Tahap 4 : Perancangan database secara logika ( Transformasi model data )

Transformasi dari skema konseptual dan eksternal ( Tahap 2 ) ke model data sistem
manajemen database yang terpilih, ada dua proses yaitu :
 Transformasi yang tidak tergantung pada sistem, pada tahap ini transformasi tidak
mempertimbangkan karakteristik yang spesifik atau hal– hal khusus yang akan
diaplikasikan pada sistem manajemen database
 Penyesuaian skema ke sistem manajemen database yang spesifik, di lakukan suatu
penyesuaian skema yang dihasilkan dari tahap 1 untuk dikonfirmasikan pada bentuk
implementasi yang spesifik dari suatu model data seperti yang digunakan oleh sistem
manajemen database yang terpilih
Hasil dari tahap ini dituliskan dengan perintah DDL ke dalam bahasa sistem manajemen
database terpilih. Tapi jika perintah DDL tersebut termasuk dalam parameter–parameter
perancangan fisik , maka perintah DDL yang lengkap harus menunggu sampai tahap
perancangan database secara fisik telah lengkap.
e. Tahap 5 : Perancangan Database Secara Fisik

Proses pemilihan struktur penyimpanan yang spesifik dan pengaksesan file– file database
untuk mencapai kinerja yang terbaik di bermacam–macam aplikasi
Kriteria pemilihan perancangan fisik :
 Waktu respon
Waktu transaksi database selama eksekusi untuk menerima respon
 Penggunaan ruang penyimpanan

Jumlah ruang penyimpanan yang digunakan oleh database file dan struktur jalur
pengaksesannya
 Terobosan yang dilakukan file transaksi

(Transaction troughput )
Merupakan nilai rata–rata transaksi yang dapat di proses permenit oleh sistem
database dan merupakan parameter kritis dari sistem transaksi
Apabila waktu respon dari database tidak mencapai optimalisasi, maka pada tahap
perancangan fisik ini dapat dilakukan denormalisasi.
Denormalisasi
Denormalisasi merupakan proses yang dilakukan pada database yang sudah

dinormalisasi, dengan cara memodifikasi struktur tabel dan mengabaikan kerangkapan
data (yang terkontrol) untuk meningkatkan kinerja database.
Proses denormalisasi termasuk :
 Mengkombinasikan tabel-tabel yang terpisah dengan join

 Mereplikasi/menduplikat data pada tabel
f. Tahap 6 : Implementasi
Implementasi skema database logik dan fisik ke dalam penyataan DDL dan SDL dari
sistem manajemen database yang telah dipilih, untuk digunakan dalam pembuatan file–
file database yang masih kosong
Daftar Pustaka
McGraw Hill, 1992
MODUL PERKULIAHAN
PROYEK
PENGEMBANGAN
SISTEM INFORMASI
Modul Standar untuk

06
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan
menganalisa kebutuhan
Functional Modelling
Functional model menjelaskan business process dan interaksi dari sistem informasi dengan
lingkungannya. Didalam OOAD ada dua buah model yang digunakan didalam analisis dan
disain :
2. Activity diagram. Menjelaskan pemodelan logical dari proses bisnis dan workflow
pekerjaan didalam bisnis. Notasi ini digunakan untuk menjelaskan apa yang telah
berlaku sekarang dan yang akan berlangsung pada sistem yang baru. Sebuah activity
diagram dapat digunakan untuk menjelaskan bermacam pemodelan aktifitas yang
berlangsung didalam sebuah sistem informasi yang berjalan pada sebuah business
sistem.
3. Use Case. Use case digunakan untuk menjelaskan fungsi dasar sistem informasi. Notasi
ini digunakan untuk menjelaskan apa yang telah berlaku sekarang dan yang akan
berlangsung pada sistem yang baru. Sebuah use case adalah cara formal untuk
menjelaskan bagaimana sebuah business system berinteraksi dengan lingkungannya.
Sebuah use case menjelaskan aktifitas yang dilakukan oleh pengguna didalam sebuah
sistem informasi. Use case dapat dilihat sebagai gambaran eksternal atau gambaran
functional sebuah proses business dimana didalamnya diperlihatakan bagaimana
pandangan pengguna terhadap sistem
4. Activity diagram dan use case merupakan logical models yaitu model yang menjelaskan
aktifitas-aktifitas yang terjadi didalam sebuah business domain tanpa menjelaskan
secara terinci bagaimana mereka harus dilakukan. Logical models disebut juga sebagai
problem domains models.
5. Disamping itu Activity diagram dan use case juga merupakan physical model yang
menggambarkan aktifitas fisik terinci yang memungkinkan sistem berjalan dengan baik.
6. Dengan memfokuskan diri pada logical modelling analyst dapat melihat business
process tanpa harus memperhatikan implementation details terlebih dahulu.
Tujuan dari requirement determination adalah untuk merubah very high level explanation of the
business requirement menjadi daftar yang lebih jelas dari requirement yang dapat digunakan
sebagai input untuk analysis (membuat , functional models, structural models, and behavioral
models)
Pengertian Requirement
Requirement adalah pernyataan apa yang harus dilakukan oleh sistem atau karakteristik apa
yang harus dimiliki :
7. Didalam tahapan analisis requirement ditulis dari sudut pandang business, atau apa
yang dilakukan oleh sistem. Fokusnya ada pada "WHAT". Fokusnya ada pada user
needs, sehingga biasanya disebut business requirements.
8. Selanjutnya didalam tahapan design, business requirement bergerak menjadi lebih

teknis, dan akan menjelaskan bagaimana (HOW) sistem akan diimplementasikan.
Requirement pada saat design dilihat dari sudut pandang pembuat sistem (developer).
Use haruslah dapat menggambarkan user requirement. Yang harus diperhatikan bahwa
pembatas antara analisis dan perancangan remang-remang. Beberapa pihak menggunakan
istilah tersebut secara bolak-balik. Yang harus diperhatikan adalah requirement adalah
pernyataan apa yang harus dilakukan oleh sistem dan selalu da kemungkinan untuk berubah.
Secara umum requirement terbagi dua yaitu :
3. Functional requirement. Requirement ini berelasi langsung dengan dengan proses yang
harus dilakukan oleh sistem yang akan dibuat sehingga dapat menyediakan informasi
yang diperlukan. Functional requirement mengalir langsung kedalam tahapan analisis
selanjutnya, karena mendefinisikan fungsi-fungsi yang harus dimiliki oleh sistem.
Perhatikanlah Gambar 1 mengenai Functional Requirements
4. Nonfunctional requirement. Requirement ini berhubungan dengan behavioral properties

yang harus dimiliki oleh sistem, seperti performance and usability. menjelaskan
bermacam-macam karakteristik sistem : operational, performance, secutiry, cultural and
political. Karakteristik tersebut tidak menjelaskan business process ataupun informasi
yang diperlukannya, tetapi sangat penting untuk dpat memahami apa yang harus dimiliki
oleh sistem final.
Didalam menentukanUntuk menentukan requirement diperlukan pemahaman business dan IT.

Hal ini bisa dianalogikan seperti membuat bangunan. Jika kita pemilik tumah, maka kita tahu
apa yang kita inginkan dari rumah kita, tetapi kita tidak akan dapat membuatrancangan rumah.
Demikan juga dengan seorang ahli bangunan sipil atau arsitek tidak akan dapat menentukan
bentuk bangunan dengan baik meskipun memiliki kemampuan teknis untuk dapat
menggambarkannya jika tidak berkomunikasi dengan orang yang akan menggunakan
bangunan tersebut. Karena pendekatan terbaik adalah mempekerjakan ahli business dan IT
bersama-sama untuk membuat analisa sistem. Kadang kala pengguna tidak tahu secara tepat
apa yang diinginkannya maka analis akan membantunya dengan teknik/perangkat/notasi dan
pemahaman yang dimilikinya. Teknik yang populer untuk melakukan analisis adalah :
 Business process Automation.
 Business Process Improvement.
 Business Process Reengineering.
1. Business Process Modelling dengan Activity Diagrams

Business process model menjelaskan bermacam-macam aktifitas yang menjadi pendukung dari
proses buiness yang dilakukan sehari-hari. Business process biasanya memotong beberapa
departemen fungsional sehingga melibatkan fungsionalitas beberapa department.
1.1 Elemen dari activity diagram

Activity diagram merupakan gambaran sebuah data flow yang lebih mutakhir dibandingkan
dengan flow chart maupun DFD didalamnya dapat menggambarkan pararel process dan
aktifitas yang lebih rumit. Berikut ini adalah contoh dari Activity diagram.
Gambar 1 Contoh Activity Diagram untuk Pendaftaran Pasien
Elemen-elemen dari activy diagram adalah :
1. Action :
a. Behaviour sederhana yang tidak bisa dipecah lagi (secara conceptual).
b. Diberi label dengan nama
2. Activity :
a. Digunakan untuk menggambarkan sehimpunan Action
b. Diberi label dengan nama
3. Control flow : Memperlihatkan urut-urutan eksekusi.
4. Object flow :Memperlihatkan aliran object adi sebuah action atau activity ke action atau
activity lain.
5. Initial node : Memperlihatkan titik awal.
6. Final Activity node : Akhir dari sebuah activity diagram
7. Final flow node : Digunakan untuk menghentikan sebuah control flow atau object flow
yang spesific.
8. Decision node :
a. Digunakan untuk menggambarkan test condition untuk memastikan bahwa control
flow atau object flow mengalir ke lebih dari satu jalur.
9. Merge node : digunakan untuk menggabungkan kembali decision path.
10. Fork Node : Digunakan untuk memecah sebuah behaviour menjadi activity atau action
pararel yang pararel.
11. Join node : digunakan untuk menggabungkan kembali activity atau action yang pararel.
12. Swimlane :
a. digunakan untuk memecah activity diagram kedalam baris dan kolom untuk
membagi tanggung jawab kepada object-object yang melakukan aktifitas tersebut.
b. Diberi label dengan nama object yang bertanggung jawab untuk menjalankan activity
atau action.
Adapun garis besar yang harus diikuti untuk membuat activity diagram, adalah :
 Since an activity diagram can be used to model any kind of process, you should set the
context or scope of the activity being modeled. Once you have determined the
scope, you should give the diagram an appropriate title.
 You must identify the activities, control flows, and object flows that occur between the
activities.
 You should identify any decisions that are part of the process being modeled.
 You should attempt to identify any prospects for parallelism in the process.
 You should draw the activity diagram.
2. Use Case
Use case adalah penjelasan dari fungsi sistem dilihat dari kaca mata penggunanya. Use case
diagram merupakan sebuah functional diagram yang menggambarkan fungsi dasar dari sistem.
Yaitu apa yang dapat digunakan oleh user dan bagaimana sistem harus merespon terhadap
user action. Tahapan yang harus dialui adalah :
 Membuat text base description.
 Menterjemahkan use case menjadi use case diagram.
Use case menjelaskan sebuah fungsi didalam organisasi tetatpi terdiri dari bermacam-macam
action dan aktifitas.
Use case dikembangkan dengan cara bersama-sama dengan user. Use case diagram
menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang
ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case
merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah
pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan
sebagainya.
Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan
sistem untuk melakukan pekerjaan-pekerjaan tertentu.
Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah
sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua
feature yang ada pada sistem.
Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses
dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil
setiap kali use case yang meng-include dieksekusi secara normal.
Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi
fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common.
Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri.
Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu
merupakan spesialisasi dari yang lain.
2.1. Jenis jenis use case

Use case merupakan :
use case capture a contract ….[that] describes the system’s behaviour under various
conditions as the system respons to request from one of its stakeholders
Pada dasarnya use case adalah ceritera lengkap dengan sebuah form tertentu tentang
bagaimana pengguna system berinteraksi dengan system didalam suatu keadaan tertentu.
Tahapan pertama dalam menulis use case adalah menentukan actor yang diikutkan didalam
ceritera. Actor adalah orang atau perangkat yang menggunakan system atau product didalam
context system atau behaviour yang dilakukan.
Actor dan end-user belum tentu orang yang sama . User boleh jadi melakukan peran yang
berbeda sehingga user dan actor belum tentu sama. Yang harus diperhatikan adalah
pembuatan use case merupakan aktifitas yang berulang dimana tidak seluruh actor dapat
ditemukan pada iterasi yang pertama. Sesudah actor dapat diidentifikasi use case dapat
dikembangkan. Ivar Jacobson menyarankan beberapa pertanyaan untuk dapat memahami use
case apa yang ada didalam sebuah object analisis dan disain :
Ada dua jenis use case yaitu :
8. Overview vs detail. Overview use case digunakan untuk memungkinkan analis dan user
setuju atas requirement secara umum. Jika sudah dipahami bersama-sama maka
requirement tadi akan dikonversi menjadi detail use case :
1. Presents an important business process.
2. The use case supports revenue generation or cost reduction.
3. Technology needed to support the use case is new or risky and therefore will require
considerable research.
9. Essential versus real. Pada essential use case yang dijelaskan adalah minimal essential
issues untuk memahami required functinality, sedangkan pada real use case yang harus
dijelaskan adalah lengkah-langkah terinci dari sistem informasi.
Untuk membuat use case petunjuk yang diberikan adalah :

9. Write each step in “SVDPI (Subject – Verb – Direct Object or Preposition – Indirect
Object)" form. Setiap langkah didalam Use case dituliskan secara lengkap dengan
aturan tata bahasa yang baik
10. Clarify initiator and receivers of action. Siapa yang memulai action harus jelas, dan siapa
yang menjawab tindakan tersebut juga harus dijelaskan dengan terinci. (System
Response harus jelas)r
11. Write from independent observer perspective. Ditulis secara independent tidak secara
judgemental.
12. Write at same level of abstraction. Tingkat abstraksi harus sama dengan responden
yang ditanya.
13. Ensure a sensible set of steps. Urut-urutan langkah harus masuk akal. Secara logis urut-
urutan harus benar berurut
14. Apply KISS principle liberally. Use case harus dibuat sederhana, dan mudah dipahami
(Keep it simple stupid).
15. Write repeating instructions after the set of steps to be repeated. Tulislah instruksi
untuk mengulang sesudah langkah penjelasan langkah yang harus dilakukan.
Adapun notasi notasi yang digunakan adalah sebagaimana diperlihatkan pada Gambar 3 yang
meliputi :
8. Actor/Role.
9. Use Case.
10. System
11. Association yang dapat berjenis :
12. Association Relationship
13. Include Relationship
14. Extend Relationship
Gambar 3. Notasi Use Case
Gambar 4. Use Case Diagram
Gambar 5. Extend dan Include Relationship.
Gambar 6. Cara Identifikasi Use Case
Daftar Pustaka
McGraw Hill, 1992
MODUL PERKULIAHAN
PROYEK
PENGEMBANGAN
SISTEM INFORMASI
Modul Standar untuk

07
Ilmu Komputer Sistem Informasi 87007 Team dosen
Abstract Kompetensi
Structural Modelling
7.1 Pendahuluan
Structural modelling adalah:
9. A structural or conceptual model describes the structure of the data that supports the
business processes in an organization. Model terstruktur atau konseptual yang
menjelaskan struktur data yang digunakan didalam business proses didalam organisasi.
10. The structure of data used in the system is represented through CRC cards, class
diagrams, and object diagrams.
Tujuan dari pemodelan tersebut adalah :

5. Reduce the “semantic gap” between the real world and the world of software.
6. Create a vocabulary for analysts and users
7. Represent things, ideas, and concepts of importance in the application domain
7.1.1 CLASS dan OBJECT

CLASS adalah template/cetakan yang digunakan untuk mendefinisikan suatu instance/contoh
kejadian yang disebut object. Object adalah contoh kejadian dari class. setiap object pasti akan
berasosiasi tepat dengan satu class.
Setiap object memiliki attributes yang berisikan informasi mengenai object tersebut. State dari
sebuah object ditentukan oleh nilai dari attributes dan relationshipnya pada suatu waktu
tertentu.
Setiap object juga memiliki behaviour yang menspesifikasikan apa yang bisan dilakukan sebuah
object.
7.1.2 Methods dan Messages
Method merupakan implementasi dari behaviour(kelakukan) sebuah object. Method adalan
sebuah action(tindakan) yang dapat dilakukan oleh object. Method dapat dianalogikan dengan
fungsi sebagaimana terdapat didalam bahasa C. Message merupakan informasi yang
dikirimkan ke Object yang akan menjadi pemicu dari dilakukannya sebuah tindakan.
7.1.3 Encapsulation dan Information Hiding

Pemikiran mengenai encapsulation dan Information hiding sudah ada sejak jaman dahulu kala.
Encapsulation adalah kombinasi dari proses dan data yang diletakkan didalam sebuah class.
Didalam OOSAD yang dimaksudkan dengan
Encapsulation adalah meletakkan attribute dan behaviour kedalam sebuah object yang
dispesifikasikan didalam class. didalam notasi yang digunakan UML 2.0 attribute diletakkan
pada bagian atas sedangkan behaviour diletakkan pada bagian bawah dari kotak.
Information hiding adalah sebuah cara berpikir dimana informasi yang diperlukan oleh
penggunalah yang akan ditampilkan sedangkan yang tidak diperlukan tidak usah
ditampilkan/diberikan. Konsekuensinya yang dapat diakses adalah bagian dari object yang
digunakan untuk menerima perintah dan memberikan informasi kepada pengguna object
tersebut. Sehingga object diperlakukan seperti sebuah kotak hitam.
The only information that an object needs to know is the set of operations, or methods,
that other objects can perform and what messages need to be sent to trigger them.
7.1.4 Inheritance
Inheritance atau pewarisan digunakan untuk mengidentifikasi object/class yang memiliki tingkat
yang lebih tinggi dan lebih general. Atributes dan methods yang sama dikelompokkan menjadi
sebuah superclass. Biasanya superclass diletakkan diatas dan turunannya diletakkan dibawah.
Hubungan inheritance yang terjadi adalah A KIND OF.
Subclass akan mewarisi attributes dan methods dari class yang berada diatasnya. Artinya
subclass berisi attributes dan methods dari superclass yang berada diatasnya.
Class yang berada didalam rantai hierarchy pasti akan ada yang memiliki instance/contoh
kejadian. Class yang memiliki contoh kejadian disebut concrete class. Ada juga class yang
menjadi superclass yang menjadi template bagi sebagian dari class yang berada dibawahnya.
Class tersebut merupakan abstract class.
Pada contoh Person adalah abstract class sedangkan Doctor dan Patient merupakan concrete
class
7.1.5 Polymorphism dan Dynamic Binding
Polymorphism artinya message yang sama diinterpretasikan/memiliki arti/bentuk yang berbeda.
Sebagai contoh jika kita beri perintah draw kepada object segi empat, segi tiga, dan lingkaran
akan menjalankan perintah yang berbeda. Dibawah ini adalah contoh polymorphism :
int kali(int a, int b);
int kali(int a, int b, int c);
maka fungsi mana yang akan dijalankan tergantung kepada argumen yang disertakan.
Polymorphism dapat terlaksanya karena adanya dynamic binding. Dynamic, atau, late binding
adalah teknik/cara penundaan penentuan jenis object sampai pada saat run-time. Artinya
method mana yang akan dijalankan ditunda sampai system/program berjalan. Kontrasnya
adalah static binding dimana setiap methods sudah ditentukan pada saat kompilasi.
Attributes :
 Units of Information relevant to the description of class (attribute berisi informasi yang
menjelaskan class
 Hanya attribute yang relevan yang disertakan dalam class diagram
Operations/Methods :
 Aksi yang dilakukan oleh objects.
 Berfokus pada operasi yang spesific untu sbh problem domain
Relationship :
10. Generalization Enables inheritance of attributes and operations
11. Aggregation Relates parts to wholes
12. Association Miscellaneous relationships between classes
7.2 Class Responsibilities and Collaboration

Menunjukkan kerjasama dari classes untuk melakukan pemenuhan kebutuhan dari client :
16. Responsibilites adalah :

1. Knowing. Mengetahui apa yang harus dikerjakan untuk melayani permintaan client
2. Doing. Melakukan apa yang diminta client
17. Collaboration Objects working together to service a request
Gambar 7-1 CRC
Jenis-jenis attribute :
15. Derived atau attribute turunan yang diturunkan dari attribute primitive. Contoh tanggal
lahir adalah primitive. Umur adalah derived attributes
16. Visibility
17. Public bisa dilihat siapa saja
18. Protected hanya bisa dihubungi oleh class yang menjadi friend/teman
19. Private hanya bisa dilihat oleh class itu sendiri
Jenis-jenis operasi selain fungsi methods yang biasa :

10. Constructor. :
11. Secara otomatis akan dijalankan pada saat oject dibuat
12. Biasanya juga membuat object yang lain
13. Query : Menanyakan state dari object
14. Update : Merubah nilai dari beberapa atau seluruh attribute.
Relationship adalah hubungan antar object/class. Jenis hubungannya bermacam-macam :

10. Sebuah class dapat berhubungan denga dirinya sendiri atau disebut recursive
11. Multiplicity :
12. One to one
13. Zero to many
14. One to many
15. Zero to one
16. Specified Range
17. Multiple disjoint range
Association
Gambar 7-2 Class Diagram
Class diagram dapat disederhanakan dengan hanya memperlihatkan bagian yang ingin dilihat
saja, tetapi paling tidak harus memiliki nama class. Disamping class digram terdapat object
diagram yang membantu memperlihatkan hubungan antar object atau contoh kejadian dari
sebuah class. Object diagram menggambarkan hubungan structural pada saat run time. Contoh
object diagram dapat dilihat pada gambar berikut
7.3 Membuat CRC dan Class Diagram

Yang pertama tama harus dilakukan adalah melakukan identifikasi object. Identifikasi object
dilakukan dengan cara membaca use case untuk kemudian dilakukan parsing dari setiap
kalimat yang terdapat didalam Use case scenario. Aktivitasnya meliputi :
4. Analisis tekstual dari use case (Textual analysis of use-case information) :
1. Nouns suggest classes
2. Verbs suggest operations
5. Membuat gambaran secara kasar (Creates a rough first cut)
6. Membuat daftar object (Common object list)
7. Membuat daftar contoh kejadian
8. Membuat daftar peranan (Roles)
Setelah melakukan identifikasi class lalu membuat identifikasi pola :
4. hubungan antar class yang dapat dikelompokkan berdasarkan :
5. Transactions
1. Transaction class
2. Transaction line item class
3. Item class
4. Location class
5. Participant class
Adapun tahapan tahapan pembuatan model struktural adalah :
4. Create CRC cards.
5. Examine common object lists.
6. Role-play the CRC cards.
7. Create the class diagram.
8. Review the class diagram.
9. Incorporate patterns.
10.Review the model.

&&&&&&&
Daftar Pustaka
McGraw Hill, 1992
MODUL PERKULIAHAN
Proyek
Pengembangan
Sistem Informasi
Modul Standar untuk
08
Abstract Kompetensi
Unified Modeling Language
Unified Modeling Language (UML) adalah notasi yang lengkap untuk membuat visualisasi
model suatu sistem. Sistem berisi informasi dan fungsi, tetapi secara normal digunakan untuk
memodelkan sistem komputer. Di dalam pemodelan obyek guna menyajikan sistem yang
berorientasi pada objek pada orang lain, akan sangat sulit dilakukan jika pemodelan tersebut
dilakukan dalam bentuk kode bahasa pemrograman. Kesulitan yang muncul adalah timbulnya
ketidak jelasan dan salah interpretasi di dalam pembacaan kode pemrograman untuk pemodelan
objek tersebut.
Dimulai tahun 1994, Booch, Runbaugh dan Jacobson merupakan tiga tokoh yang metodelogi-
nya paling banyak dipakai mempelopori organisasi yang bertujuan menyatukan metodelogi-
metodelogi berorientasi objek, organisasi tersebut dinamakan OMG (Object Modelling Group).
Pada tahun 1995 OMG merealisasi draf pertama dari UML (versi 0.8) dan pada tahun 1997 UML
versi 1.1 muncul dan sekarang versi terbaru dari UML adalah versi 2.0. Pada tahun 1997 Booch,
Runbaugh dan Jacobson menyusun tiga buku tentang UML. Sejak saat itulah UML telah
menjelma menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek.
Notasi Dasar UML

Actor
Actor adalah segala sesuatu yang berinteraksi langsung dengan sistem aplikasi komputer, seperti
orang, benda atau lainnya. Tugas actor adalah memberikan informasi kepada sistem dan dapat
memerintahkan sistem agar melakukan sesuatu tugas. Lihat Gambar 1 di bawah.
Gambar 1 Notasi actor pada UML
Class
Notasi utama dan yang paling mendasar pada diagram UML adalah notasi untuk
mempresentasikan suatu class beserta dengan atribut dan operasinya. Class adalah pembentuk
utama dari sistem berorientasi objek. Gambar 2 menunjukkan notasi dari class UML.
Nama Class
Atribut
Operasi
Gambar 2 Notasi class pada UML
Use Case
Use case adalah deskripsi fungsi dari sebuah sistem dari perspektif pengguna. Use case bekerja
dengan cara mendeskripsikan tipikal interaksi antara user (pengguna) sebuah sistem dengan
sistemnya sendiri melalui sebuah cerita bagaimana sebuah sistem dipakai. Urutan langkah-
langkah yang menerangkan antara pengguna dan sistem disebut scenario. Notasi use case dapat
di perlihatkan pada gambar dibawah berikut ini.
Gambar 3 Notasi use case pada UML
Diagram UML
UML merupakan sintak umum untuk membuat model logika dari suatu sistem dan digunakan
untuk menggambarkan sistem agar dapat dipahami selama fase analisis dan desain. UML
biasanya disajikan dalam bentuk diagram/gambar yang meliputi class beserta atribut dan
operasinya, serta hubungan antar class yang meliputi inheritance, association dan komposisi.
UML tediri dari banyak diagram, secara garis besar diagram yang terdapat pada UML dapat
diperlihatkan pada gambar dibawah ini :
Gambar 4 Diagram-diagram pada UML versi 2.0 (www.uml.org)
Use Case Diagram

Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem, yang
ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case
mempresentasikan sebuah interaksi antara actor dengan sistem. Use case menggambarkan kata
kerja seperti Login ke sistem, maintenance user dan sebagainya. Model use case seperti pada
Gambar 5 dan contoh use case diagram ditunjukkan pada Gambar 6 di bawah.
Sistem
Actor Actor
Gambar 5 Use case model
Use Case
Petugas Stok
EntrY Permintaan
Hitung Stok Barang
<<extend>>
Penjaga Toko
<<include>>
View Permintaan
<<include>>
Hitung Penjualan
Petugas
Buat Laporan Keuangan
Gambar 6 Use case diagram pada penjualan VCD

Actor : penjaga toko dan petugas keuangan
Use case : entry permintaan, view permintaan, hitung penjualan dan buat
laporan.
Class Diagram
Class adalah sebuah spesifikasi yang jika di-instansiasi akan menghasilkan sebuah objek dan
merupakan inti dari pengembangan berorientasi objek. Class menggambarkan keadaan
(attribute/property) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan
tersebut (metode/fungsi). Class diagram menggambarkan struktur dan deskripsi class, packed
dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi dan lainnya.
Lihat Gambar 7 dan Gambar 8 contoh class diagram di bawah.
Class
Nama Class
Attibute
1. Attribut : tipe
Operasi
2. Operasi : tipe
Gambar 7 Sebuah class dalam UML
Cabang
Nama Cabang
Pelanggan Order Pembayaran

Nama Pelanggan No Jumlah
Tgl
status
Tunai Kartu Kredit
JmlKembalian No
Order Detail
expDate
Jumlah
Item Barang
Nama Barang
Harga
Gambar 8 Contoh class diagram penjualan VCD
Activity Diagram
Activity diagram menggambarkan berbagai alir aktifitas dalam sebuah sistem yang sedang
dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi dan
bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang
mungkin terjadi pada beberapa eksekusi. Activity diagram tidak menggambarkan sifat internal
dari sebuah sistem dan interaksi antara beberapa sub sistem secara eksak, tetapi lebih
menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum. Pada UML
2.X aktivitas tidak lagi disebut sebagai activity, akan tetapi cukup disebut dengan action saja.
Activity adalah struktur yang lebih tinggi yang terdiri atas action-action yang berurutan. Oleh
karenanya activity diagram menunjukkan action-action yang membangun sebuah aktivitas.
Berikut adalah simbol-simbol yang digunakan pada activity diagram.
Tabel 1 Tabel Simbol Activity Diagram
Simbol Keterangan
Titik Awal
Titik Akhir
Activity
Pilihan untuk pengambilan keputusan
Fork; Untuk menunjukkan kegiatan yang dilakukan secara paralel
Rake; menunjukkan adanya dekomposisi
Tanda Waktu
Tanda Penerimaan
Aliran Akhir (Flow Final)
Start
Datang ke Memilih
Petugas
gallery VCD yang
Keuangan
VCD dibeli
Tidak membeli VCD
Bayar VCD
yang dibeli
End
Gambar 9 Contoh activity diagram penjualan VCD
Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem
(termasuk pengguna, display dan sebagainya) berupa message yang digambarkan terhadap
waktu. Sequence diagram terdiri atas waktu dan obyek-obyek yang terkait. Sequence diagram
biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan
sebagai respons dari sebuah event untuk menghasilkan output tertentu, proses dan perubahan apa
saja yang terjadi secara internal dan output apa yang dihasilkan.Gambar 10 menunjukkan esensi
simbol dari sequence diagram dan simbol kerjanya secara bersama-sama.
Actor Name 1 Name 2
Objek
Message Lifeline
Gambar 10 Simbol-simbol yang ada pada sequence diagram
State Machine Diagram

Interaction diagram dan state chart menampilkan dua pandangan yang saling melengkapi
tentang perilaku dinamis sebuah sistem. Interaction diagram menunjukan pesan-pesan yang
dilewatkan diantara obyek-obyek didalam sistem selama periode waktu yang pendek. Sedangkan
state chart diagram menelusuri individu-individu obyek melalui keseluruhan daur hidupnya,
menspesifikasikan semua urutan yang mungki dari pesan-pesan yang akan di terima objek
tersebut bersama-sama dengan tanggapan atas pesan-pesan tersebut.
Simbol UML untuk state transition diagram adalah segiempat yang setiap pojoknya dibuat
rounded. Titik awalnya menggunakan lingkaran solid yang diasir dn diakhiri dangan mata.
Berikut adlah symbol UML untuk statechart.
Gambar 11 Simbol Statechart Diagram
UML juga memberi pilihan untuk menambahkan detail ke dalam simbol tersebut dengan
membagi menjadi 3 area yaitu nama state, state variable dan activity.
Nama
State Variable
Activities
Gambar 12 Penambahan detail ke state

State variable seperti timer dan counter kadangkala sangat membantu. Activity terdiri atas events
dan action. Tiga hal yang sering dipakai disini adalah entry ( apa yang terjadi ketika sistem
masuk ke state), exit ( apa yang terjadi ketika sistem meninggalkan state) dan do ( apa yang
terjadi ketika sistem ada di state). Hal-hal lain bisa ditambahkan jika perlu.
Collaboration Diagram
Informasi yang disampaikan sama dengan sequencial diagram namun beda dalam pengambaran
dan kegunaan saja. Dalam diagram ini digambarkan hubungan antar objek dan actor dengan
tidak memperhatikan waktu/urutan.
Gambar 13 Colaboration diagram
Component Diagram
Component diagram mengandung componet, interface dan relationship. Notasi component bisa
dilihat pada gambar dibawah ini.
Gambar 14 Contoh notasi component

Hal penting pada component adalah component mewakili potongan-potongan yang independent
yang bisa dipesan dan diperbaharui sewaktu-waktu. Dengan demikian, pembagian sistem
kedalam component-component lebih banyak didorong oleh kepentingan marketing dari pada
kepentingan teknis. Meskipun demikian harus juga diingat bahwa terlalu banyak component juga
kurang bagus, karena susah mengatur dan memeliharanya khususnya menyangkut masalah
versioning.
Component digunakan untuk menunujukan struktur fisik seperti DAN LAIN-LAIN. Hal tersebut
tidak terlalu benar sekarang, karena struktur fisik ditunjukan dengan artifact. Artifact adalah
manifestasi fisik dari software, biasanya file. File-file ini biasanya bisa dieksekusi/executable
(seperti: . EXE file, biner, DAN LAIN-LAIN, file JAR, Assembly atau Script), atau file-file data,
file-file konfigurasi, dokumen HTML dan lain-lain.
Component dihubungkan melalui interface yang diimplementasikan. Biasanya menggunakan
notasi ball-and-socket seperti class diagram. Component juga bisa dikompose dengan
menggunakan composite struktur diagram.
Gambar 16 menunjukan contoh component diagram. Pada contoh ini, seorang sales mesin dapat
berhubungan dengan component server sales, dengan menggunakan interface sales message.
Karena networknya tidak dapat dipercaya, component antrian pesan (queue) dipasang sehingga
masih tetap dapat berhubungan dengan server ketika server sedang hidup dan berhubungan
dengan queue ketika network mati. Selanjutnya queue berhubungan dengan server ketika
network sudah berfungsi kembali. Hasilnya queue message hasus bisa mendukung interface sales
message untuk berhubungan dengan component mesin dan membutuhkan interface tersebut
untuk berhubungan dengan server. Server dibagi menjadi 2 component utama. Prosesor transaksi
untuk merealisasikan interface sales message dan accounting driver untuk berhubungan dengan
system akutansi.
Gambar 17 Contoh component diagram
Deployment Diagram
Deployment diagram menunjukan tata letak sebuah system secara fisik, menampakkan bagian-
bagian software yang berjalan pada bagian-bagian hardware. Bagian utama hardware/perangkat
keras adalah node; yaitu nama umum untuk semuah jenis sumber komputasi. Ada 2 tipe node
yang mungkin. Processor adalah node yang bisa mengeksekusi sebuah component, sedangakan
device tidak. Device adalah perangkat keras (seperti printer atau monitor) tipikalnya menjadi
interface dengan dunia luar.
Node mengandung artifact, dimana artifact adalah manifestasi fisik dari software; biasanya file.
File-file ini biasanya bisa dieksekusi/executable (seperti: .EXE file, biner, DAN LAIN-LAIN,
file JAR, Assembly atau script), atau file-file data, file-file konfigurasi, dokumen HTML dan
lain-lain. Daftar artifact di dalam sebuah node menunjukan bahwa artifact tersebut di deploy ke
node tersebut pada saat system sedang dijalankan. Di UML, kubus menunjukan node. Node bisa
diberi nama & ditambahkan stereotype untuk mengidentifikasikan tipe resource yang ada
sebelumnya. Jika node adalah bagian dari package, namanya bisa mengandung nama package
tersebut. Kubus bisa juga ditambahkan kompartemen yang berisi informasi seperti component
yang dideploy di node tersebut. Jalur komunikasi diantara node menunjukan bagaimana
mereka berkomunikasi. Jalur tersebut bisa ditambahkan label yang menginformasikan protocol
komunikasi apa yang dipakai
Daftar Pustaka
McGraw Hill, 1992
MODUL PERKULIAHAN
Proyek
Pengembangan
Sistem Informasi
Modul Standar untuk
09
Abstract Kompetensi
Penggunaan Notasi UML
Modul ini akan membahas contoh penggunaan notasi-notasi UML didalam kasus operasional
perusahaan yang memerlukan data dan informasi yang cukup bagi pihak perusahaan sebagai
dasar pengambilan keputusan strategis dan operasional dalam rangka memenangkan
persaingan dan untuk meningkatkan omzet pendapatan perusahaan tersebut.
Pada bab tiga ini diuraikan tentang tahap pengembangan sistem diantaranya adalah
pemodelan bisnis, analisis, perancangan, pengujian dan implementasi sistem, sistem
pengiriman (delivery) pada PT X
Bahan dan Alat
Bahan penelitian yang digunakan adalah data paket atau dokumen yang akan dikirim, data
pengirim dan alamat tujuan barang akan dikirim serta bukti atau nota pengiriman. Peralatan
diperlukan untuk mendukung penelitian dan mengoperasikan aplikasi antaralain digolongkan
menjadi :
Perangkat Keras.
Perangkat keras adalah seperangkat alat atau komponen yang akan digunakan untuk
membentuk suatu sistem komputer :
11. CPU (Central Processing Unit).
CPU merupakan pusat pengolahan dan juga pusat pengontrolan dari
sebuah sistem komputer yang saling melaksanakan kegiatan.
12. Floppy Disk.
Floppy Disk adalah alat penggerak untuk membaca atau untuk merekam
data dari atau ke media penyimpanan disket.
13. Harddisk.
Hard Disk adalah media penyimpanan data yang terbuat dari piringan keras
yang dilapisi dengan zat magnetik. Harddisk dapat menyimpan data lebih
banyak dan mempunyai kecepatan yang tinggi dalam pengambilan dan
penyimpanan data.
14. Keyboard.
Keyboard adalah alat input yang biasanya didampingi dengan alat tampilan
(display) di layar yang menampilkan apa yang ditekan di keyboard.
15. Video Display Unit (VDU)
VDU adalah alat yang digunakan untuk komunikasi interaktif antara manusia
dengan komputer yang berupa tampilan visual.
16. Mouse
Mouse adalah alat input komputer yang digunakan oleh berbagai program
aplikasi GUI ( Graphcal User Interface ) dengan petunjuk posisi yang
ditampilkan melalui monitor.
17. Printer
Printer adalah alat yang digunakan untuk mencetak keluaran baik berupa
tulisan, grafik atau gambar pada media kertas.
Perangkat Lunak
Perangkat lunak merupakan bagian dari suatu sistem pengolahan data yang digunakan untuk
mengaktifkan fungsi dari perangkat keras komputer. Perangkat lunak yang dibutuhkan pada
sistem usulan adalah sebagai berikut :
8. Sistem Operasi
Sistem operasi yang disarankan minimal Windows 98.
9. Program Aplikasi.
Merupakan perangkat lunak yang akan digunakan dalam pembuatan
program sistem usulan diantaranya adalah aplikasi databases MySQL,
aplikasi Java jdk-1_5_0_02-windows-i586-p.exe dan aplikasi penghubung
(connection) antara aplikasi database dan aplikasi compiler java yaitu mysql-
connector-java-5.0.3-bin.jar.
Kasus menggunakan pendekatan pemodelan bisnis dan objek, model ini berkosentrasi pada
lingkup bisnis di perusahaan yang akan kita rancang sistemnya. Terlebih dahulu kita harus
melakukan pemeriksaan-pemeriksaan pada bisnis itu sendiri: entitas-entitas yang berinteraksi
dengan bisnis serta aliran-aliran kerja dalamnya. Metode pengembangan sistem penulis
menggunakan metodologi Berorientasi Objek dan menggunakan perkakas utama dalam
analisis dan perancangannya menggunakan notasi Unified Modeling Language (UML).
Pemodelan Bisnis
Pengembangan sistem/perangkat lunak bisnis menuntut kita melakukan pemodelan bisnis yang
berkosentrasi pada lingkup bisnis diperusahaan yang akan kita rancang sistemnya. Terlebih
dahulu kita harus melakukan pemeriksaan-pemeriksaan pada bisnis itu sendiri: entits-entitas
yang berinteraksi dengan bisnis serta aliran-aliran kerja di dalamnya. Sangat penting untuk
memahami bisnis itu sendiri. Kita seharusnya melakukan penelahan sistem secara seksama
dengan cara melakukan pencarian data dengan pihak yang terlibat serta ditambah dengan
melakukan studi-studi literature.
Fungsi Pemodelan Bisnis
Pemodelan bisnis adalah studi tentang organisasi/perusahaan. Selama proses pemodelan

bisnis, kita melakukan pemeriksaan struktur organisasi/perusahaan dan mencari peran-peran
penting dalam organisasi/perusahaan dan bagaimana mereka saling berhubungan. Ada
beberapa alasan untuk melakukan pemodelan bisnis. Alasan utama adalah untuk memahami
organisasi, sistem yang saat ini bekerja di organisasi yang bersangkutan, serta perangakat
lunak yang saat ini dimilikinya. Tahapan yang terdapat pada tahap ini antara lain terdiri dari
beberapa penentuaan kosep-konsep dasar pemodelan bisnis.
Identifikasi Aktor Bisnis
Sesungguhnya, sebelum kita memulai segala sesuatunya menyangkut pengembangan

sistem/perangkat lunak, pertama kali kita harus menentukan aktor-aktor bisnis, kita seharusnya
melihat pada lingkup proyek dimana sistem kita akan dikembangkan serta berusaha
menentukan apa yang ada diluar linkup-lingkup proyek kita. Dalam hal ini penulis
mendefiniskan bahwa yang dapat menjadi sebagai aktor bisnis adalah pelanggan (pengirim)
yang menggunakan jasa pengiriman tersebut. Dalam UML, aktor bisnis digambarkan sebagai
berikut :
Gambar 1 Pelanggan (Pengirim)
Identifikasi Pekerja Bisnis

Untuk mengidentifikasi pekerja-pekerja Bisnis, sekali lagi kita harus melihat pada lingkup proyek
kita. Jika kita berusaha memodelkan bisnis secara terbatas, suatu diagram struktur organisasi
mungkin merupakan suatu awal untuk memulai. Pertimbangan setiap peran dalam struktur
organisasi itu alih-alih posisinya. Pertimbangkan bahwa seseorang mungkin memiliki peran-
peran yang berbeda dalam bisnis tersebut. Dalam hal ini penulis mendefiniskan bahwa yang
dapat menjadi model pekerja bisnis antara lain : petugas entri, dan kurir (pengantar barang).
Dalam UML, pekerja bisnis digambarkan sebagai berikut :
Gambar 2. Petugas entry Gambar 3. Kurir (pengantar

barang)
Identifikasi Use Case Bisnis
Untuk mengidentifikasi use case bisnis, kita bias memulainya dari pernyataan visi dan misi
organisasi, yang merupakan peringkat tertinggi dari sasaran bisnis dalam menciptakan nilai-nilai
tertentu bagi lingkungannya. Misalnya dalam perusahan yang menjadi tempat riset bagi penulis,
perusahaan tersebut bergerak dibidang pengiriman barang. kita kemudian berusaha
memikirkan apa yang dibutuhkan dalam upaya perusahaan itu mengantarkan barang ketujuan.
Pertama kali, perusahaan tersebut harus memiliki mekanisme yang memungkinkan pengirim
untuk melakukan transaksi, mekanisme selanjutnya adalah pembuatan nota pembayaran.
Kemudian mekanisme selanjutnya adalah pengiriman panagantaran barang yang akan dikirim,
setelah itu barang yang telah di kirim dilakukan verifikasi lebih lanjut. Dari apa yang kita
definsikan dari problem yang terdapat pada perusahaan, kita mungkin dapat menemukan
beberapa use case bisnis, yaitu : transasksi, pembayaran, pengiriman dan verifikasi.
Diagram Use Case Bisnis
Setelah kita dapat menentukan aktor-aktor bisnis, pekerja-pekerja bisnis, serta use case bisnis,
maka langkah selanjutnya adalah menggambarkan diagram use case bisnis yang
memperlihatkan interaksi-interaksi yang terjadi di antara mereka. Suatu tanda panah yang
berarah dari pekerja bisnis ke use case bisnis mengambarkan bahwa pekerja bisnis memulai
proses tertentu yang dilakukan dengan use case. UML, pekerja bisnis digambarkan sebagai
berikut :
Gambar 3.4. Diagram use case bisnis
Analisis
Definisi analisis sistem menurut DeMarco [De Marco, 1978], “ The study of a problem, prior to
taking some action”. Analisis sistem adalah mempelajari suatu masalah dan mempunyai tujuan
utama untuk melakukan tindakan. Analisis sistem merupakan proses menentukan kebutuhan
sistem – apa yang harus silakukan sistem untuk memenuhi kebutuhan klien, bukanlah
bagaimana sistem tersebut diimplementasikan.
Identifikasi Masalah
Sebuah perusahaan yang bergerak dibidang pengiriman barang, memberikan sebuah

pelayanan jasa berupa jasa pengiriman barang berupa dokumen dan paket. Didalam proses
bisnisnya, dimulai saat seorang pelanggan (pengirim) melakukan pengiriman sebuah dokumen
atau paket keperusahaan tersebut. Oleh petugas yang bertugas memasukan (entry) data,
transaksi itu dicatatat. Dengan ketentuaan yang telah ditetapkan sebelumnya data-data dicatat
dan disimpan sesuai keterangan dan informasi yang didapat.
Kemudian petugas melakukan perhitungan pembayaran, saat pembayaran dilakukan petugas
akan memproses apakah tagihan langsung dibuat atau akan ditagihkan pada suatu periode
tertentu. Dengan ketentuan sebelumnya bahwa pelanggan yang sudah menjadi member,
proses pembayarannya dapat dilakukan dengan membuat nota tagihan untuk pembayaran
suatu periode tertentu, data yang terdapat pada tagihan tersebut merupakan kumpulan dari
beberapa transaksi yang dilakukan dalam satu periode.
Setelah selesai melakukan proses transaksi tersebut, document atau paket tersebut mulai
dilakukan proses pengiriman ketujuan. Dokumen atau paket tersebut akan dikirim ketujuan
sesuai dengan keterangan informasi yang terdapat pada nota transaksi.
Untuk memberikan pelayanan lebih kepada pelanggan, pelanggan diperbolehkan melakukan
klaim bila didapatkan suatu problem yang menyangkut tentang proses pengiriman dokumen
atau paket yang dikirimkan. Proses klaim dapat dilakukan dan dapat dikatakan sah apabila
transaksi tersebut belum dibuat tagihan dan memenuhi beberapa kententuan atau perjanjian
yang telah disepakati sebelumnya.
Diagram Konteks
Gambar 3.5. Diagram konteks
Identifikasi Use Case dan Aktor
Pada bagian ini kita mulai melakukan proses pencarian atau penentuan beberapa kebutuhan
dasar didalam membentuk use case. Aktor dan use case ditentukan atas dasar kenutuhan
fungsi-fungsi. Kebutuhan fungsi ini diakomodir di use case. Selanjutnya use case menyediakan
nilai hasil kepada aktor. Atas dasar spesifikasi diatas paling tidak kita dapat menemukan aktor.
Use case, seperti kita ketahui sebelumnya, mencakup aliran-aliran kerja (workflow) dalam
sistem (bersifat internal) sedangkan aktor-aktor mencakup segala sesuatu yang ada diluar
sistem (bersifat eksternal). Tentu saja ada perbedaan antara use case dan aktor yang sedang
kita bahas saat ini dengan use case bisnis dan aktor bisnis (juga pekerja bisnis) yang telah kita
bahas sebelumnya. Perbedaan-perbedaan itu akan kita bahas sekilas pada tabel di bawah ini
(Tabel 3.1).
Table 1 Perbedaan objek-objek dalam model bisnis dan model sistem.
Nama Objek Model Bisnis Model Sistem
Use Case Mendeskripsikan apa Mendeskripsikan sistem
yang dikerjakan yang akan/sedang
perusahaan. dikembangkan dalam
perusahaan.
Aktor Bersifat eksternal Bersifat eksternal terhadap
terhadap perusaan sistem yang akan/sedang
dikembangkan
Pekerja Bisnis Bersifat internal dalam Tidak digunakan
perusahaan
Untuk mendeskripsikan use case apa saja dan aktor yang akan terlibat dalam use case
tersebut, biasanya digunakan tabel seperti tabel 3.1 Untuk itu bisa dilihat kembali spesifikasi
sistem diatas.
Tabel 2 Requirement aktor dan use case

No Requirement Aktor Use Case
1 Operator Data Entry melakukan Operator Data Proses Login
verifikasi user untuk menggunakan Entry (verifikasi user)
sistem
2 Operator Data Entry melakukan input Operator Data Transaksi
proses transaksi pengiriman yang Entry pengiriman,
berisi data pengirim dan tujuan Input Data
penerima Pengirim, Input
Data Penerima
3. Sesudah data dan informasi dengan Operator Data Pembayaran,
benar maka operator data entry Entry Tagihan
membuat nota pembayaran dari suatu
transaksi terebut
4 Dengan sudah masuknya semua data Operator Data Buat Laporan,
ke database computer, proses Entry Laporan Data
selanjutnya adalah membuat laporan Pengirim ,
berkala yang diperlukan untuk Laporan Data
keperluan-keperluan lain yang Penerima,
berhubungan dengan proses yang Laporan Data
berlangsung di perusahaan tersebut. Transaksi,
Laporan Data
Tagihan
5. Untuk melakukan tugas lainnya maka Data Pegawai
diperlukan pegawai lainnnya, oleh
karena itu diperluka pendataan
pegawai dengan benar.
Selanjutnya atas dasar tabel diatas dibuat use case diagram. Sebagai catatan
bahwa suatu proses penambahan data pengirim dan peneriman dapat dilakukan secara
langsung pada form data pengirim atau form data penerima, selain itu dapat dilakukan
pada saat proses transaksi terjadi. Untuk keterangan dan penjelasan lebih lengkap
dapat dilihat pada gambar diagram use case berikut ini :
Gambar 6 Diagram use case diagram
&&&&&&&&&
Daftar Pustaka
McGraw Hill, 1992
MODUL PERKULIAHAN
Proyek
Pengembangan
Sistem Informasi
Modul Standar untuk
10
Abstract Kompetensi
Diskripsi Use Case
Setiap use case di atas harus dideskripsikan dalam dokumen yang disebut dengan dokumen flow
of event. Dokumentasi ini mendefisikan apa yang harus dilakukan oleh sistem ketika aktor
mengaktipkan use case. Struktur dari dokumen use case ini bisa bermacam-macam, tetapi
umumnya deskripsi ini paling tidak harus mengandung : (sumber Quantrani, 2000).
18. Brief Description (deskripsi singkat).
19. Aktor yang terlibat.
20. Precondition yang penting bagi use case untuk memulai.
21. Deskripsi rinci dari aliran kejadian yang mencakup :
10. Main Flow dari kejadian yang bisa dirinci lagi menjadi
22. SubFlow dari kejadian (Sub flow bisa di bagi lagi lebih jauh menjadi sub
flow yang lebih kecil agar dokumen lebih mudah dibaca dan dimengerti).
 Alternative Flow untuk mendefinisikan situasi perkecualian
23. Postcondition yang menjelaskan state dari sistem setelah use case
berakhir.
Selain hal diatas kita juga boleh memakai beberapa deskripsi tambahan untuk
melengkapi pendeskripsian use case yang kita buat. Setelah pembuatan use case pada sub
bab sebelumnya kini kita akan menjelaskan spesifikasi use case yang telah kita tentukan.
Tabel 3 Spesifikasi naratif untuk use case login tingkat analisis

Use case name Login
Aktor Operator Data Entry
Brief Use case ini merupakan awal dari semua kegiatan
Description yang terjadi. Operator Data Entry ingin Login
terhadap sistem dengan menginputkan data user
name dan password, maka sistem akan memvalidasi
user name dan password tersebut.
Exception Jika dalam verifikasi user tidak ditemukan berati
tidak berhak untuk menggunakan sistem.
Basic Flow  Operator Data Entry meninputkan User
name.
 Operator Data Entry menginputkan
Password
 Sistem memvalidasi User name dan
Password tersebut.
 Sistem akan merespon dari proses tersebut
untuk memberikan keterangan
Alternatif flow Jika dalam menginputkan User name dan Password
tidak sesuai maka user harus mengisi kembali
Pre condition Operator Data Entry harus mengetahui User name
dan Password
Post condition Akan masuk ke dalam sistem
Tabel 4 Spesifikasi naratif untuk use case transaksi pengiriman tingkat analisis
Use case name Transaksi Pengiriman
Brief Use case ini merupakan tempat untuk melakukan
Description transaksi. Transaksi terjadi saat pelanggan ingin
melakukan pengiriman dokumen atau paket
menggunakan jasa perusahaan tersebut.
Exception Data pengiriman yang akan dimasukan sudah
tersedia dan sudah sesuai dengan ketentuan.
Basic Flow 13. Pengirim ingin melakukan pengiriman
dokumen atau paket.
14. Operator Data Entry mulai melakukan input
data yang dibutuhkan sebagai bahan
informasi berikutnya.
15. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
16. Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
yang dibutuhkan untuk proses nantinya.
Alternatif flow Jika data yang dibutuhkan tidak sesuai atau kurang
lengkap maka perlu dilakukan verifikasi lebih lanjut
kepada pengirim.
Pre condition 18. Operator data entry harus login terlebih
dahulu.
19. Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data transaksi telah tersimpan
Tabel 5 Spesifikasi naratif untuk use case input data pengirim tingkat analisis
Use case name Input Data Pengirim
Brief Walaupun sebenarnya data pengirim secara tidak
Description langsung telah diimputkan dan disimpan saat
melakukan transaksi. Tetapi untuk mendapatkan
keterangan yang lebih terperinci data pengirim
maka diperlukan use case ini. Use case ini
merupakan tempat untuk melakukan penambahan
atau mengedit data pengirim.
Exception Data pengirim yang akan dimasukan sudah tersedia
dan sudah sesuai dengan ketentuan.
Basic Flow 20. Operator data entry dapat menambahkan
atau mengedit data yang telah tersimpan
untuk menambahkan rincian informasi .
21. Operator data entry mulai melakukan input
berlaku.
Alternatif flow Jika data pengirim sebelumnya sudah ada maka
sistem akan otomastis akan menampilkan data
tersebut, akan tetapi bila tidak maka operator data
entry harus mengimputkan data baru tersebut.
dahulu.
sesuai.
Post condition Data Pengirim telah tersimpan
Tabel 6 Spesifikasi naratif untuk use case input data penerima tingkat analisis
Use case name Input Data Penerima
Brief Walaupun sebenarnya data penerima secara tidak
keterangan yang lebih terperinci data penerima
atau mengedit data penerima.
Exception Data karyawan yang akan dimasukan berisi biodata
para pegawai yang bekerja di perusahaan tersebut.
atau mengedit biodata karyawan yang
bekerja di peerusahaan .
berlaku.
Alternatif flow Jika data penerima sebelumnya sudah ada maka
dahulu.
sesuai.
Post condition Data Penerima telah tersimpan
Tabel 7 Spesifikasi naratif untuk use case input data karyawan tingkat analisis
Use case name Input Data Karyawan
Brief Use case ini memungkin operator data entri untuk
Description melakukan entry data karyawan yang bekerja di
perusahaan tersebut
Exception Data karyawan yang akan dimasukan sudah tersedia
atau mengedit data yang telah tersimpan
untuk menambahkan rincian informasi .
berlaku.
Alternatif flow Jika data pegawai sebelumnya sudah ada maka
dahulu.
sesuai.
Post condition Data karyawan telah tersimpan
Tabel 8 Spesifikasi naratif untuk use case proses tagihan tingkat analisis
Use case name Proses Tagihan
Description melakukan proses pembayaran dari suatu transaksi
yang berlangsung atau dibuatkan tagihan untuk
beberapa transaksi dalam satu periode.
Exception Data transaksi yang dilakukan sudah terjadi.
Basic Flow 9. Proses pembayaran atas transaksi yang
dilakukan diproses secara berkala (per
periode) atau secara langsung .
pemrosesan tagihan.
11. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
memproses data.
berlaku.
Alternatif flow Jika penerima tersebut merupakan member maka
proses pembayaran akan dibuat tagihan untuk satu
periode, dan bila bukan maka pembayaran dapat
langsung dilakukan.
dahulu.
sesuai.
Post condition Data Tagihan telah tersimpan
Tabel 9 Spesifikasi naratif untuk use case laporan data transaksi tingkat analisis
Use case name Laporan Data Transaksi
Description melakukan pembuatan laporan, data yang didapat
dari proses transaksi yang terjadi.
Exception Data transaksi yang akan dimasukan sudah tersedia
Basic Flow 4. Proses pembuatan laporan dilakukan
bertujuan untuk mengetahui seberapa
banyak proses terjadinya transaksi dan
pendapatan yang di hasilkan
pemrosesan pembuatan laporan
memproses data.
berlaku.
Alternatif flow Jika data pada saat memasukan data parameter tak
sesuai, maka proses harus diulang .
dahulu.
sesuai.
Post condition Data Laporan telah tersimpan
Tabel 10 Spesifikasi naratif untuk use case laporan data tagihan tingkat analisis
Use case name Laporan Data Tagihan
dari proses transaksi yang telah terjadi. Kemudian
data tersebut akan dibuat sebuah tagihan secara
berkala
Exception Data tagihan didapat dari data transaksi yang akan
dimasukan sudah tersedia dan sudah sesuai dengan
ketentuan.
Basic Flow 6. Proses pembuatan laporan tagihan
dilakukan bertujuan untuk mengetahui
seberapa banyak tagihan yang didapat dari
beberapa transaksi dalam satu periode
tertentu.
memproses data.
berlaku.
dahulu.
sesuai.
Post condition Data Laporan Tagihan telah siap cetak
Tabel 11 Spesifikasi naratif untuk use case laporan data pengirim tingkat analisis
Use case name Laporan Data Pengirim
Description melakukan pembuatan laporan data pengirim, data
yang didapat dari proses transaksi yang telah terjadi
atau secara langsung hasil inputan. Kemudian data
dapat dibuat laporannya untuk mengetahui data
yang telah diimputkan dan tersimpan di dalam
database.
Exception Data laporan didapat dari data transaksi yang akan
ketentuan atau dimputkan secara langsung pada
sistem.
Basic Flow 11. Proses pembuatan laporan pengirim
dilakukan bertujuan untuk mengetahui
seberapa banyak data pengirim yang telah
tesimpan didalam sistem tersebut
memproses data.
berlaku.
dahulu.
sesuai.
Post condition Data Laporan pengirim siap cetak
Tabel 12 Spesifikasi naratif untuk use case laporan data penerima tingkat analisis
Use case name Laporan Data Penerima
Description melakukan pembuatan laporan data penerima, data
yang didapat dari proses transaksi yang telah terjadi
atau secara langsung hasil inputan. Kemudian data
dapat dibuat laporannya untuk mengetahui data
yang telah diimputkan dan tersimpan di dalam
database.
Exception Data laporan didapat dari data transaksi yang akan
ketentuan atau dimputkan secara langsung pada
sistem.
Basic Flow Proses pembuatan laporan penerima dilakukan
bertujuan untuk mengetahui seberapa banyak data
pengirim yang telah tesimpan didalam sistem
tersebut
Operator data entry mulai melakukan input data
yang dibutuhkan sebagai bahan pemrosesan
pembuatan laporan
Sistem akan meminta kepada operator data entry
untuk memasukan ketentuan atau parameter yang
akan menjadi batasan untuk memproses data.
Sistem akan memproses data yang telah diinputkan
sesuai dengan ketentuan yang berlaku.
Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi yang
dibutuhkan untuk proses nantinya.
dahulu.
sesuai.
Post condition Data laporan penerima siap cetak
Identifikasi Kelas pada Use Case

Meskipun dalam pembahasan ini pemodelan class dilakukan setelah pemodelan use case,
sebenarnya pada faktanya kedua aktivitas tersebut dilakukan secara parale. Kedua model tersebut
sebenarnya saling mendukung dalam pemberian informasi. Use case memfasilitasi dalam hal
penggalian class dan sebaliknya pemodelan class dapat membantu menemukan use case yang
terlupakan.
Class biasanya digunakan untuk mendefinisikan objek-objek bisnis. Class-class seperti ini
biasanya mendefinisikan model database dari suatu aplikasi. Atas dasar itulah class seperti ini
sering disebut dengan class entity karena mewakili objek database.
Class entity ini menjelaskan esensi sistem informasi apapun. Biasanya analisis kebutuhan
digunakan untuk menemukan class entity ini. Akan tetapi, untuk bisa menjalankan sistem secara
benar, sistem membutuhkan class-class yang mendefinisikan objek-objek GUI (seperti form
layer) yang disebut dengan class boundary. Sistem juga membutuhkan class-class yang
mengontrol logika program yang disebut dengan class control. Namun biasanya pemodelan
kedua class yang terakhir ini dilakukan saat memasuki fase perancangan, bukan fase analisis.
Tabel berikut menjelaskan cara pencarian kandidat class entity pada Aplikasi Pengiriman Barang
pada PT. X
Tabel 13 Kandidat class entity pada aplikasi pengiriman barang pada PT. X
No Requirement Class Entity
1. Operator Data Entry ingin Login terhadap sistem Operator Data Entry
dengan menginputkan data user name dan (Data User).
password, maka sistem akan memvalidasi user
name dan password tersebut
2. Transaksi terjadi saat pelanggan ingin melakukan Transaksi, Jenis
pengiriman dokumen atau paket menggunakan jasa Pengiriman dan Sifat
perusahaan tersebut kebeberapa kota tujuan dengan Pengiriman
berbagai bentuk pilihan jenis dan sifat pengiriman.
3. Saat melakukan transaksi tentu saja dibutuhan Data Pengirim, Data
beberapa data, untuk itu diperlukan data pengirim Penerima
dan data penerima. Sehingga barang yang dikirim
terdapat keterangan siapa pengirimnya dan
keterangan penerimanya
4. Setelah proses memasukan data yang dibutuhkan Pembayaran
saat transaksi tersebut, maka akan diproses
pembayaran yang berlangsung saat itu apakah
secara tunai atau dibuat tagihan.
5. Pada saat proses pembayaran yang dilakukan tidak Tagihan
secara langsung (dibuatkan tagihan) bila pelanggan
tersebut sudah menjadi member dari perusahaan
tersebut. Tagihan akan ditagihkan menurut
periodenya dan berisi data trasaksi selama periode
tersebut
Langkah selanjutnya adalah membuat class diagram. Dengan mengacu pada ilustrasi tabel diatas
maka kita bisa melakukan pemodelan diagram class tersebut.
Gambar 7 Class Diagram
Daftar Pustaka
McGraw Hill, 1992
MODUL PERKULIAHAN
PROYEK
PENGEMBANGAN
SISTEM INFORMASI
Modul Standar untuk

11
Abstract Kompetensi
Perancangan Sistem
Setelah membahas analisis sistem, maka tiba saatnya untuk membahas desain (perancangan)
sistem. Pada perancangan aplikasi penulis akan menggunakan tool UML dengan membangun
diagram-diagram yang akan digunakan pada sistem. Pada perancangan ini penulis hanya
membangun beberapa diagram saja. Proses perancangan bertujuan untuk :
 Menggambarkan secara detail komunikasi antar objek
 Menentukan objek-objek pendukung lain selain objek-objek domain persoalan.
 Menentukan pemilahan sistem.
 Menentukan ciri objek secara detail.
 Menetapkan penggunaan objek-objek pustaka yang telah tersedia.
Selain itu untuk mengembangkan model perancangan, kita harus mengidentifikasi dan
menyelidiki konsekuensi pada lingkungan implementasi akibat langkah-langkah perancangan.
Semua keputusan-keputusan strategis perancangan, misalnya bagaimana DBMS akan digunakan,
bagaimana komunikasi proses dan penaganan kesalahan (error handler) akan dicapai, pustaka
komponen apa yang akan digunakan ulang (reusable component) harus dibuat. Kemudian, kita
menggunakan keputusan-keputusan itu untuk beradaptasi dengan lingkungan implementasi.
Shlaer dan Mellor membuat pendefinisan yang membedakan antara problem dan solusi, apa dan
bagaimana atau analisa dan desain [Coad, 1991]. Desain berorientasi objek mempunyai tiga
dasar ,yaitu :
17. Notasi. Notasi digunakan untuk memberikan gambaran tentang gagasan sistem
kepada anggota team yang lain dan pihak lain yagn memerlukan.
18. Strategi. Setiap proyek tidak harus dimulai dari awal seperti pada saat memikirkan
untuk memecahkan persoalan. Desain untuk problem domain yang biasa ditemui
dapat digunakan untuk pemecahan masala.
19. Kriteria yang baik. Evaluasi suatu desain dapat dilakukan secra obyektif dengan
melihat apakah diterima, ditolak atau direvisi.
Pada tahap perancangan objek, kita mendefinisikan bagaimana analisis berorientasi
aplikasi akan direalisasikan pada lingkungan implementasi. Jacobson(1992) (dikutip dari buku
Modern Database Management, tulisan Fred McFadden, dkk) menyebutkan 3 alasan utama
mengapa kita menggunakan pendekatan perancangan berorientasi objek. Alasan-alasan itu adalah
:
36. Model analisis pada analisis dengan metoda terstruktur tidak cukup formal untuk
diimplementsikan secara langsung ke bahasa pemrogrman. Untuk menterjemahkan
ke kode computer, kita perlu melakukan langkah-langkah penghalusan (refinement)
dengan membuat keputusan-keputusan pada operasi apa yang objek akan lakukan,
bagaimana seharusnya komunikasi antara objek-objek dalam suatu sistem dilakukan,
pesan apa yang harus dilewatkan, dan apa sebagainya.
37. Sistem nyata harus diadaptasi ke lingkungan dimana sistem kelak akan
diimplementasi. Dalam hal ini, perlu dilakukan modifikasi-modifikasi model analisis
ke beberapa faktor yang berbeda seperti kebutuhan kinerja, perangkat keras target
dan perangkat lunak sistem, DBMS (Database Management Sistem), bahasa
pemrograman yang akan digunakan, dan sebagainya.
38. Hasil analisis dapat divalidasi menggunakan perancangan berorientasi objek pada
tahap ini, kita daapat memverifikasi apakah hasil dari analisis sesuai untuk
membangun sistem dan kemudian, jika tidak sesuai, kita kembali secara iterative ke
tahap analisis, serta membuat perubahan yang perlu pada model analisis.
Untuk mengembangkan model perancangan, kita harus mengidentifikasi dan menyelidiki
konsekuensi pada lingkungan implementasi akibat langka-langkah perancangan. Semua
keputusan strategis perancangan, misalnya bagaimana DBMS akan digunakan, bagaiman
komunikasi proses dan penanganan kesalahan (error handler) akan dicapai, pustaka komponen
apa yang harus dibuat. Kemudian. Kita menggunakan keputusan-keputusan itu untuk
mendeskripsikan bagaimana objek-objek berinteraksi satu sama lain lewat suatu sknario (use
case) yang telah kita kembangkan sebelumnya.
Deskripsi Use Case Tingkat Perancangan

Tabel 1 Spesifikasi naratif untuk use case login tingkat perancangan
Use case name Login
Brief Operator Data Entry ingin Login terhadap sistem
Description dengan menginputkan data user name dan
password, maka sistem akan memvalidasi user
name dan password tersebut.
Exception Jika salah dalam mengimputkan user dan password
maka sistem tidak akan menampilkan menu utama
(main form).
Basic Flow 24. Tampilkan Form Login
25. Operator Data Entry meninputkan User
name.
26. Operator Data Entry menginputkan
Password
27. Operator Data Entry mengirimkan User
name dan Password dengan memilih tombol
Login agar sistem memvalidasi User name
dan Password tersebut.
28. Sistem memvalidasi User name dan
Password tersebut.
29. Sistem menampilkan informasi, jika User
name dan Password yang diinputkan benar
maka sistem akan menampilkan Form menu
utama, tetapi jika salah maka sistem akan
menampilkan pesan error.
Alternatif flow Jika dalam menginputkan User name dan Password
salah maka sistem akan menampilkan pesan error
dan memintanya untuk mengisi kembali
Pre condition Operator Data Entry harus mengetahui User name
dan Password
Post condition Tampil form Menu Utama
Tabel 2 Spesifikasi naratif untuk use case transaksi pengiriman tingkat perancangan
Use case name Transaksi Pengiriman
Brief Use case ini memungkinkan seseorang operator data
Description entry untuk melakukan transaksi pengiriman
dokument atau paket.
Exception Data untuk keterangan yang dibutuhkan untuk
transaksi telah ditentukan.
Basic Flow 19. Operator Data Entry menampilkan data
transaksi dengan memilih menu proses

Transaksi
20. Sistem secara otomatis akan menampilkan
form tesebut yang berisi data nomor
transaksi .
21. Operator Data Entry menginputkan data-data
pada space yang telah ditentukan dengan
benar.
22. Sistem akan mengontrol setiap entri yang
masuk apakah sesuai dengan ketentuan.
23. Bila semua data yang dimasukan telah benar
maka Operator Data Entry dapat menyimpan
data tersebut dengan menekan tombol save.
24. Sistem akan menyimpan data transaksi
tersebut.
Alternatif flow Jika dalam pengisian data transaksi tidak lengkap
maka sistem akan menampilkan pesan kesalahan
dan meminta kepada Operator Data Entri untuk
mengisi informasi yang dibuthkan terlebih dahulu.
Operator Data Entry bisa memilih Reset(atau nama
lain yang sejenis) untuk mengosongkan form
transaksi.
Pre condition Operator Data Entry harus login terlebih dahulu.
Data transaksi yang akan dimasukan sudah tersedia
dan sesuai.
Post condition Jika use case sukses dijalankan, maka data akan
dicatat di database sistem. Jika tidak status tidak
berubah.
Tabel 3 Spesifikasi naratif untuk use case input data pengirim tingkat perancangan
Use case name Input Data Pengirim
Brief Walaupun sebenarnya data pengirim secara tidak
keterangan yang lebih terperinci data pengirim
atau mengedit data pengirim.
Exception Data untuk keterangan yang dibutuhkan untuk data
pengirim telah ditentukan.
Basic Flow 22. Untuk menambahakan, menghapus dan
mengedit data pengirim maka dapat
dilakukan pada form ini dengan memilih
menu Record Data Pengirim.

form tesebut yang berisi data pengirim yang
sebelumnya telah tersimpan.
benar.
27. Sistem akan menyimpan data pengirim
tersebut.
Alternatif flow Jika dalam pengisian data transaksi tidak lengkap
lain yang sejenis) untuk mengosongkan form data
penerima.
Data pengirim yang akan dimasukan sudah tersedia
dan sesuai.
berubah.
Tabel 4 Spesifikasi naratif untuk use case input data penerima tingkat perancangan
Use case name Input Data Penerima
Brief Walaupun sebenarnya data penerima secara tidak
keterangan yang lebih terperinci data penerima
atau mengedit data penerima.
Exception Data untuk keterangan yang dibutuhkan untuk data
penerima telah ditentukan.
Basic Flow 14. Untuk menambahkan, menghapus dan
mengedit data penerima maka dapat
menu Record Data Penerima.

form tesebut yang berisi data penerima yang
sebelumnya telah tersimpan.
benar.
19. Sistem akan menyimpan data penerima
tersebut.
Alternatif flow Jika dalam pengisian data penerima tidak lengkap
penerima.
Data penerima yang akan dimasukan sudah tersedia
dan sesuai.
berubah.
Tabel 5 Spesifikasi naratif untuk use case input data karyawan tingkat perancangan
Use case name Input Data Karyawan
Description melakukan entry data karyawan yang bekerja di
perusahaan tersebut
Exception Data karyawan yang akan dimasukan sudah tersedia
dan sudah sesuai dengan ketentuan dan karyawan
tersebut merupakan pekerja di perusahan tersebut.
mengedit data Karyawan maka dapat
menu Record Data Karyawan.

form tesebut.
benar.
data tersebut dengan menekan tombol save
(atau nama lain yang sejenis) .
11. Sistem akan menyimpan data Karyawan
tersebut.
Alternatif flow Jika dalam pengisian data karyawan tidak lengkap
penerima.
dahulu.
sesuai.
Post condition Data karyawan telah tersimpan
Tabel 6 Spesifikasi Naratif untuk Use Case Proses Tagihan (Pembayaran) Tingkat Perancangan
Use case name Proses Tagihan
Description melakukan pembayaran dari sebuah transaksi.
Proses pembayaran diproses secara langsung atau
dibuat tagihannya untuk beberapa transaksi dalam
satu periode tertentu bagi pengirim yang sudah
menjadi member.
Exception Proses transaksi telah berlangsung sudah sesuai
dengan ketentuan.
mengedit data pembayaran (tagihan) maka
dapat dilakukan pada form ini dengan
memilih menu proses Tagihan.

form tesebut.
benar.
maka Operator Data Entry dapat memproses
data tersebut dengan menekan tombol Ok
(atau nama lain yang sejenis) .
12. Sistem akan menyimpan data tagihan
tersebut.
Alternatif flow Jika dalam pengisian data tagihan tidak lengkap
mengisi informasi yang dibutuhkan terlebih dahulu.
penerima.
dahulu.
sesuai.
Post condition Data tagihan telah tersimpan
Tabel 7 Spesifikasi naratif untuk use case laporan data transaksi tingkat perancangan
Use case name Laporan Data Transaksi
dari proses transaksi yang terjadi.
Basic Flow  Proses pembuatan laporan dilakukan
bertujuan untuk mengetahui seberapa
banyak proses terjadinya transaksi dan
pendapatan yang di hasilkan
 Operator data entry mulai memproses
pembuatan laporan maka dapat dilakukan
pada form ini dengan memilih menu proses
Laporan.
 Sistem akan meminta kepada operator data
memproses data.
 Sistem akan memproses data yang telah
berlaku.
 Setelah itu data yang telah di inputkan akan
dahulu.
sesuai.
Post condition Data laporan siap cetak
Tabel 8 Spesifikasi naratif untuk use case laporan data tagihan tingkat perancangan
Use case name Laporan Data Tagihan
dari proses transaksi yang terjadi yang kemudian
akan dibuat tagihan berdasarkan kode pengirim .
bertujuan untuk mengetahui jumlah tagihan
yang dapat dibuat dari beberapa transaksi,
dan sebagai bukti kepada pengirim.
17. Operator data entry mulai memproses
Laporan.
memproses data.
berlaku.
dahulu.
sesuai.
Post condition Data laporan tagihan siap cetak
Tabel 9 Spesifikasi naratif untuk use case laporan data pengirim tingkat perancangan
Use case name Laporan Data Pengirim
akan dibuat laporan berdasarkan kode pengirim .
bertujuan untuk mengetahui data-data
pengirim yang menggunkan jasa perusahaan
tersebut.
Laporan.
memproses data.
berlaku.
dahulu.
sesuai.
Post condition Data laporan Pengirim siap cetak
Tabel 10 Spesifikasi naratif untuk use case laporan data penerima tingkat perancangan
Use case name Laporan Data Penerima
akan dibuat laporan berdasarkan kode penerima.
bertujuan untuk mengetahui data-data
pengirim yang menggunkan jasa perusahaan
tersebut.
Laporan.
memproses data.
berlaku.
dahulu.
sesuai.
Post condition Data laporan Pengirim siap cetak
Identifikasi Kelas pada Use Case

Dalam hal ini, kita memilki 3 jenis kelas dalam UML yang di gunakan yaitu : Boundary, Entity
dan Control. Kita akan membahas masing-masing stereotype di bawah ini :
a. Boundary Class
Boundary class adalah kelas-kelas yang berada pada batasan antara sistem
kita dengan lingkungan. Kelas.kelas ini mencakup form-form, laporan-laporan,
antarmuka-antarmuka (interface) ke perangkat-perangkat keras seperti printer-
perinter serta antarmuka ke sistem yang lain. Representasi UML untuk boundary
terlihat pada Gambar di bawah ini.
Gambar 1 Boundary class
b. Entity Class
Entity class memelihara informasi-informasi yang mungkin akan kita simpan
di tempat penyimpanan yang persisten (Objek persisten adalah objek yang tetap
hadir saat perangkat lunak berakhir). Representasi UML untuk entity terlihat
pada Gambar di bawah ini.
Gambar 2. Entity class
c. Control Class
Control class bertanggung jawab untuk mengkoordinasi upaya-upaya yang
dilakukan kelas-kelas lainnya. Mereka bersifat optional, tetapi jika control class
digunakan, mereka biasanya digunakan satu untuk setiap use case, yang
fungsinya adalah mengendalikan urutan-urutan event yang menglir pada use
case. Representasi UML untuk control terlihat pada gambar di bawah ini.
Gambar 3. Control class
Tabel 11 Spesifikasi strereotype class tingkat perancangan
Class Boundary Class Control Class Entity
MainForm
FormLogin ProsesLogin (verifikasi user, Data_User
password).
FormTransaksiPengiriman AddTransaksiPengiriman Transaksi
FormDataPengirim AddEditDataPengirim Pengirim
FormDataPenerima AddEdit Data Penerima Penerima
FormDataKaryawan AddEditDataKaryawan Karyawan
FormProsesTagihan ProsesTagihan Tagihan
FormLaporanPenerima ProsesLaporanPenerima Penerima
FormLaporanPengirim ProsesLaporanPengirim Pengirim
FormLaporanTransaksi ProsesLaporanTransaksi Transaksi
FormLaporanTagihan ProsesLaporanTagihan Tagihan
Langkah selanjutnya adalah membuat class diagram. Dengan mengacu pada ilustrasi tabel diatas
maka kita bisa melakukan pemodelan diagram class tersebut.
FormLogin ProsesLogin Data_User
AddEditDataPengirim
FormDataPengirim
Pengirim
ProsesLaporanPengiri
FormLaporanPengirim m
Penerima
KoneksiDatabase
AddEditDataPenerima
FormDataPenerima
Sifat
MainForm FormLaporanPenerima ProsesLaporanPeneri

ma
Transaksi
Karyawan
AddEditDataKaryawan
FormDataKaryawan
Jenis
AddTransaksiPengirim Tagihan
FormTransaksiPengiriman
an
ProsesLaporanTransak
FormLaporanTransaksi si
FormProsesTagihan ProsesTagihan
FormLaporanTagihan
ProsesLaporanTagihan
Gambar 4 Class diagram tingkat desain

Tabel 12 Daftar attribut dan operasi pada class tingkat perancangan
Class Attribut Operasi
MainForm <<Komponen Tampilkan Form(frame :
Tampilan Form>> JFrame)
KoneksiDatabase()
BelumLogin()
LoginSukses()
UnLoadWindow()
KonneksiDatabase koneksi_database()
load_DriverJDBC()
Connection koneksiDatabase()
getData()
getResourceBundle()
FormLogin <<Komponen FormLogin()
Tampilan Form>> Close Form()
ProsesLogin dataUser CheckUserPassword()
dataPassword Check Status()
Status KoneksiDatabase()
ValidasiUserdanPassword()
Data_User NamaUser ValidasiUserPassword()
Password
Status
FormDataPengirim <<Komponen FormDataPengirim(frame :
CreateTable()
reloadRecord(scrSQL : string)
reloadRecord()
KoneksiDatabase()
Close()
AddEditDataPengirim <<Komponen Add_Edit_Data_Pengirim(fra
Tampilan Form>> me : JFrame)
listener_tombol()
tampilKode()
clearFields()
KoneksiDatabase()
dispose()
Pengirim KodePengirim Simpan()
NamaPengirim Update()
Alamat SelectData()
Kota Cetak()
NoTelpon
KodePos
FormDataPenerima <<Komponen FormDataPenerima(frame :
CreateTable()
reloadRecord()
KoneksiDatabase()
Close()
AddEditDataPenerima <<Komponen Add_Edit_Data_Penerima(fra
listener_tombol()
tampilKode()
clearFields()
KoneksiDatabase()
Dispose()
Penerima Kode Penerima Simpan()
Nama Penerima Update()
Alamat SelectData()
Kota Cetak()
NoTelpon
KodePos
FormDataKaryawan <<Komponen FormDataKaryawan(frame :
CreateTable()
reloadRecord()
KoneksiDatabase()
Close()
AddEditDataKaryawan <<Komponen Add_Edit_Data_Karyawan(fra
listener_tombol()
tampilKode()
clearFields()
KoneksiDatabase()
Dispose()
Karyawan KodeKaryawan Simpan()
NamaKaryawan Update()
TglLahir SelectData()
Alamat Cetak()
Kota
NoTelpon
KontakPerson
FormTransaksiPengiriman <<Komponen FormTransaksiPengiriman(fra
CreateTable()
reloadRecord()
KoneksiDatabase()
Close()
AddTransaksiPengiriman <<Komponen AddTransaksiPengiriman(fram
Tampilan Form>> e : JFrame)
listener_tombol()
ambilNoTran()
inputdataPenerima()
inputDataPengirim()
biaya()
KoneksiDatabase()
Dispose()
Transaksi TglTransaksi SelectData()
NoTransaksi Cetak()
KodePengirim
KodePenerima
JenisPengiriman
SifatPengiriman
Biaya
NamaKurir
FormProsesTagihan <<Komponen FormProsesPenagihan(frame :
tambahListener()
tampilNoTagihan()
tampilDataKeTabel()
Close()
KoneksiDatabase()
ProsesTagihan Update Data()
Proses()
Input Kriteria()
ProsesInputan()
Dispose()
KoneksiDatabase()
getData()
Cetak()
Tagihan NoTagihan SelectData
TglTagihan
Jumlah
FormLaporanPenerima <<Komponen FormLapPenerima()
Tampilan Form>> KoneksiDatabase()
TampilkankeTabel()
Close()
ProsesLaporanPenerima InputKriteria()
KoneksiDatabase()
TambahListerner()
ProsesSelect()
Cetak()
getData()
FormLaporanPengirim <<Komponen FormLapPengirim()
TampilkankeTabel()
Close()
ProsesLaporanPengirim InputKriteria()
KoneksiDatabase()
TambahListerner()
ProsesSelect()
Cetak()
getData()
FormLaporanTransaksi <<Komponen FormLapTransaksi()
TampilkankeTabel()
Close()
ProsesLaporanTransaksi InputKriteria()
KoneksiDatabasev
TambahListerner()
ProsesSelect()
Cetak()
getData()
FormLaporanTagihan <<Komponen FormLapTagihan()
TampilkankeTabel
Close()
ProsesLaporanTagihan InputKriteria()
KoneksiDatabase()
TambahListerner()
ProsesSelect()
Cetak()
getData()
Daftar Pustaka
McGraw Hill, 1992
MODUL PERKULIAHAN
PROYEK
PENGEMBANGAN
SISTEM INFORMASI
Modul Standar untuk

12
Abstract Kompetensi
Sequence Diagram
Sequence diagram digunakan untuk menggambarkan perilaku pada sebuah scenario. Diagram ini
menunjukan sejumlah contoh obyek dan message (pesan) yang diletakkan diantara obyek-obyek
ini di dalam use case.
Komponen utama sequence diagram terdiri dari atas obyek yang ditulisakan dengan kotak
segiempatbernama. Message diwakili oleh garis dengan tanda panah dan waktu yang ditunjukan
dengan progress vertikal dan penjelasan lebih lengkap telah dijelaskan pada bab sebelumnya.
Sequence Diagram Untuk Use Case Login
Gambar 1. Sequence diagram use case login
Sequence Diagram untuk Use Case Transaksi Pengiriman
Gambar 3. Sequence diagram use case transaksi pengiriman
Sequence Diagram untuk Use Case Input Data Pengirim
Gambar 4. Sequence diagram use case input data pengirim
Sequence Diagram untuk Use Case Input Data Penerima
Gambar 5. Sequence diagram use case input data penerima
Sequence Diagram untuk Use Case Input Data Karyawan
Gambar 6. Sequence diagram use case input data karyawan
Sequence Diagram untuk Use Case Proses Tagihan
Gambar 7. Sequence diagram use case proses tagihan
Sequence Diagram untuk Use Case Laporan Transaksi
Gambar 8. Sequence diagram use case laporan transaksi
Sequence Diagram untuk Use Case Laporan Pengirim
Gambar 9. Sequence diagram use case laporan pengirim
Sequence Diagram untuk Use Case Laporan Penerima
Gambar 9. Sequence diagram use case laporan penerima
Sequence Diagram untuk Use Case Laporan Tagihan
Gambar 10. Sequence diagram use case laporan tagihan
State Machine Diagram

State Machine diagram biasanya digunakan untuk memodelkan perilaku dinamis suatu class atau
obyek. State machine diagram memperlihatkan urutan state yang dilalui sebuah obyek, kejadian
yang menyebabkan sebuah transisi dari suatu state atau aktivitas ke state atau aktivitas yang lain,
dan aksi yang menyebabkan perubahan state atau aktivitas.
State machine diagram khususnya digunakan untuk memodelkan taraf-taraf diskrit suatu siklus
hidup obyek, sedangkan activity diagram paling cocok digunakan memodelkan urutan activitas
duatu proses. State machine diagram digunakan untuk memodelkan obyek dari semenjak dibuat
sampai selesai. Pada kondisi ini tidak semua class akan mempunyai state yang menarik untuk
dibahas.
State Machine Diagram Pengirim
Gambar 11 State machine diagram pengirim
State Machine Diagram Tagihan
Gambar 12. State machine diagram tagihan
State Machine Diagram Transaksi
Gambar 13. State machine diagram transaksi
Diagram Activity
Activity diagram memodelkan alur kerja (work flow) sebuah urutan aktivitas pada suatu proses.
Diagram ini sangat mirip dengan flow chart karena kita dapat memodelkan prosedur logika,
proses bisnis dan alur kerja. Perbedaan utamanya adalah flow chart dibuat untuk
menggambarkan alur kerja dari sebuah sistem, sedangkan activity diagram dibuat untuk
menggambarkan aktivitas aktor.
Diagram Activity untuk Aplikasi Pengiriman Barang
Gambar 13. Diagram Activity untuk Aplikasi Pengiriman Barang
Component Diagram
Component diagram menggambarkan alokasi semua class dan objek ke dalam komponen-
komponen fisik di sebuah sistem software. Diagram ini memperlihatkan pengaturan dan
kebergantungan diantara komponen-komponen software seperti dinamik library link (DLL),
executable component dan lain-lain. Manfaat dari penggunaan component in adalah penggunaan
kembali (reusable) suatu component pada proyek lain tanpa harus melakukan usaha yang berarti.
Dengan demikian akan bisa menghemat waktu dan biaya dalam pengembangannya. Pada
permasalahan ini, diasumsikan akan memanfaatkan teknologi COM (Component Objek
Modeling) atau DCOM melalui DTS (Data Translation Service). Berikut ini adalah gambaran
layer untuk DTS tersebut.
Busi
Mengandung class-class bisnis seperti ness
pelangga, pengirim, penerima, transaksi dll.Rul
e
Menangani aliran kerja dan Sevi
ce
menyiapkan user interface yang gampang
Data
dioperasikan. BRS
Tran
VC.
slati
DL
on
L
Mengkomunikasikan class di layer in Serv
ice
i dengan layer DTS. Data
Acce
DTS
VC.
ss
DLL
Serv
Secara umum,
Mengandung business
class-class translasi rule services
ice mengandung class-class bisnis dari interface-
interface
Membuat yang sql
statement dipakai
untuk diaplikasi. Sedangkan class data translation akan menjdi interface
DAS
mengakses layer
CRUD(Create,
Data Access Read, Update, Delete).
VC. Adapun DASVC.DLL akan menjalankan beberapa
2014 DLL
Proyek Pengembangan Sistem Informasi Modul 01 Pusat Bahan Ajar dan eLearning
Mengandung SQL umum untuk akses data

seperti DARetrieve (Select) dan DAQuery
operation yaitu :
36. DARetrieve akan membuat connection string dan menjalankan sebuah query Select.
37. DAQuery akan menjalanakan semua tipe query yang lain (Delete, Update dn Insert).
Diagram Component Sebuah Sistem
Gambar 14. Diagram component sebuah system
Deployment Diagram
Deployment diagram menyediakan gambaran bagaimana sistem secara fisik akan terlihat. Sistem
terdiri dari node-node dimana setiap node diwakili untuk sebuah kubus. Garis yang
menghubungkan antara 2 kubus menunjukan hubungan diantara hardware dan bisa juga
processor (yang mengeksekusi component) atau execution environment (software yang menjadi
hsost atau mengandung software lain.
Penerapan Diagram Deployment
Gambar 3.27. Penerapan Deployment Diagram pada Sistem

&&&&&&
Daftar Pustaka
McGraw Hill, 1992
MODUL PERKULIAHAN
PROYEK
PENGEMBANGAN
SISTEM INFORMASI
Modul Standar untuk

13
Abstract Kompetensi
Menggunakan Rekayasa Web
Atribut pada Aplikasi dan Sistem Berbasis Web
Menurut Pressman (2005: 502) Web application berbeda dari kategori lainnya dalam perangkat
lunak komputer. Atribut yang mengikuti sangat banyak ditemui di dalam web application adalah:
38. Network intensiveness,
39. Concurrency,
40. Unpredicable load,
41. Performance,
42. Availability,
43. Data driven,
44. Content sensitive,
45. Continuous evolution,
46. Immediacy,
47. Security,
48. Aesthetics,
Sedangkan yang termasuk ke dalam kategori aplikasi yang sering ditemui di dalam kerja
rekayasa web adalah:
13. Informational,
14. Download,
15. Customizeable,
16. Interaction,
17. User input,
18. Transaction-oriented,
19. Service-oriented,
20. Portal,
21. Database access,
22. Data warehouse.
Layer-layer WebApp Engineering
Rekayasa web dapat digambarkan ke dalam tiga layer yaitu:

 process,
 methods, dan
 tools/technology.
Web Engineering Process
Proses rekayasa web mengambil filosofi pengembangan cerdas yang menekankan pada
pendekatan teknik kecenderungan yang mudah untuk menaikan pengiriman data dari sistem yang
berkembang. Proses umum dari framework yang dapat diaplikasikan untuk rekayasa web adalah:
 Customer communication,
 web customer communication
Dalam proses rekayasa digolongkan ke dalam dua tugas besar, yaitu:

20. Business Analysis menetapkan konteks bisnis / organisasi untuk web application. Dengan
tambahan, :
1. stakeholder telah dikenali,
2. perubahan yang mungkin dalam lingkungan bisnis atau syarat yang harus dipenuhi
telah diprediksi, dan
3. integrasi antara web application dan aplikasi bisnis lainnya, database, dan fungsi telah
dikenali.
4. Formulation syarat-syarat aktivitas yang harus dipenuhi untuk semua stakeholder.
21. Planning, Rencana proyek untuk pengembangan applikasi web yang telah dibuat/telah
ada . Rencana tersebut terdiri dari :
1. task definition dan
2. jadwal kerja untuk jangka waktu relative pendek.
22. Modeling, Analisis rekayasa perangkat lunak konvensional dan tugas mendisain yang
disesuaikan untuk perkembangan web application, digabungkan, dan kemudian
dimasukkan ke dalam aktivitas modeling rekayasa web.
23. Construction, Menggunakan alat dan teknologi rekayasa web untuk membangun aplikasi
web yang telah dirancang.
24. Deployment, Pemasangan dan konfigurasi aplikasi disesuaikan dengan lingkungan
tempat dimana aplikasi akan dipasang dikirimkan kepada end-user, dan kemudian
memulai masa evaluasi.
Aktivitas dari framework ini dipilah kedalam sepasang tugas-tugas rekayasa web yang
disesuaikan menurut kebutuhan dari setiap framework rekayasa Web yang diterapkan didalam
proyek. Aktivitas dari lima akrifitas process yang meliputi :
Gambar 1 Web Engineering Process (Dari Pressman: 508)

Formulating Sistem Berbasis Web
Formulation adalah aktivitas komunikasi konsumen yang menemukan masalah yang akan
dipecahkan oleh web application :
39. Kebutuhan bisnis,
40. Tujuan dan kriteria keberhasilan proyek,
41. Kategorisasi end-user,
42. fitur dan fungsi utama, dan
43. tingkat interoperabilitas dengan aplikasi lainnya
Kelompok Web Engineering (Web Engineering Group)

30. Kelompok web engineering terdiri dari anggota kelompok yang punya spesialisasi teknis
dan non-teknis yang memungkinkan kelompok ini memiliki otoritas untuk melakukan
pengambilan keputusan.
31. Manajemen proyek dibutuhkan selama web engineering, perbedaannya adalah masa
tugas yang lebih singkat, dan boleh jadi otoritasnya tidak meliputi keseluruhan sistem
informasi organisasi.
Requirements analysis untuk WebApps

Requirements analysis untuk WebApps mencakup tiga tugas utama:
25. formulation,
26. requirements gathering, dan
27. analysis modeling.
Selama formulation, tujuan utama dan obyek untuk WebApp telah diidentifikasi, dan kategori
dari user ditemukan. Sejak requirements gathering dimulai, komunikasi diantara tim Web
ngineering dan WebApp stakeholder semakin erat. Formulation, requirement gathering, dan
analysis modeling dilakukan untuk dapat melakukan identifikasi kebutuhan user yang akan
diterapkan/dipenuhi oleh web application :
28. Hirarki User. Kategori dari end-users yang berinteraksi dengan WebApp diidentifikasi
sebagai bagian dari tugas-tugas formulation dan equirements gathering.
29. Kategorisasi user (sering disebut actors) memberikan petunjuk pada fungsionalitas untuk
diberikan oleh WebApp dan menunjukan kebutuhan user yang digambarkan dengan use-
case yang dibangun untuk setiap end-user (actor) yang ditulis secara hirarki.
30. Membangun Use-Cases. Menurut Franklin [FRA01] dalam pressman: 542, menyatakan
bahwa use-cases sebagai “bundles of functionality”. Deskripsi ini memperlihatkan esensi
dari pentingnya teknik analysis modeling. Use-case dibangun untuk setiap kategori user
yang digambarkan di dalam hirarki user. Di dalam konteks Web engineering, use-case itu
sendiri cenderung informal – paragraf narasi yang menggambarkan interaksi spesifik
diantara user dan WebApp.
31. Menemukan kembali Use-Case Model. Sebagaimana use-case Diagram dibuat untuk
setiap kategori user, use-case adalah katalisator untuk semua syarat aktivitas analisis
dan pemodelan. Use-cases diatur ke dalam package-package dan setiap package dinilai
untuk memastikan bahwa use-case:
32. Comprehensible (Lengkap), Semua stakeholder mengerti tujuan dari package.

33. Cohesive, fungsi alamat package yang berhubungan dekat satu dengan lainnya.
34. Loosely coupled, fungsi atau kelas dalam package bekerjasama satu dengan
lainnya, tetapi kerjasama ketergantungan antar package dijaga tetap minimum.
35. Hierarchically shallow, fungsional hierarki yang terdalam sulit untuk mengontrol dan
susah bagi end-user untuk mengerti; oleh karena itu, jumlah dari tingkatan dalam
hirarki use-case seharusnya diminimalkan jika dimungkinkan.
Content Model
Content model menggambarkan spectrum dari content obyek yang dimasukkan kedalam web
application. Content obyek ini harus dibangun atau diperoleh untuk penggabungan ke dalam
arsitektur web application. Pohon data dapat digunakan untuk mewakili content hirarki obyek.
Kelas analisis (berasal dari use-case) memberikan arti lain untuk mewakili kunci obyek bahwa
web application akan dimanipulasi.
Interaction Model
Interaction model disusun dengan use-cases, UML sequence diagrams, dan UML state diagrams
untuk menggambarkan percakapan diantara user dan web application. Sebagai tambahan, bentuk
dasar antar muka mungkin dibangun untuk membantu dalam pengembangan layout dan
keperluan navigasi. Sebagian besar dari web application membolehkan percakapan antara end-
user dan fungsionalitas aplikasi, isi, dan perilaku. Interaction model terdiri dari empat elemen
yaitu:
20. Use-cases, Adalah elemen yang dominan dari interaction model untuk web application.
Sudah umum menggambarkan 100 atau lebih use-cases ketika sangat besar, web
application yang kompleks yang dianalisis, didisain, dan dibangun. Bagaimanapun,
persentase yang kecil secara relative use-cases ini menggambarkan sebagian besar
interaksi antara end-user categories (aktor) dan sistem. Use-cases lainnya memperbaiki
interaksi, memperbaiki secara rinci analisis yang diperlukan untuk panduan pada disain
dan pembangunan.
21. Sequence diagrams, UML sequence diagrams memberikan gambaran singkat dari cara
yang mana aksi user (elemen dinamis dari sistem yang didefinisikan oleh use-cases)
bekerjasama dengan kelas analisis (elemen structural dari sistem yang didefinisikan oleh
kelas diagram). Kelas harus dapat dijejaki ke use case.
22. State diagrams, UML state diagrams memberikan gambaran lain dari perilaku dinamis
web application sebagai interaksi yang terjadi. Seperti kebanyakan gambaran modeling
digunakan di dalam rekayasa web (atau rekayasa perangkat lunak), state diagram dapat
digambarkan dengan perbedaan tingkatan dari abstraksi.
23. User interface prototype, Tata ruang dari user interface, isinya ditampilkan, ekanisme
interaksinya dilaksanakan, dan estetika secara keseluruhan dari hubungan user dengan
web application telah banyak dilakukan dengan kenyamanan user dan dukungan secara
keseluruhan dari web application.
Functional Model
Functional model menggambarkan user dapat mengamati fungsi dan kelas operasi menggunakan
UML activity diagram. Functional model memanggil dua proses elemen dari web application,
setiap penggambaran berbeda tingkatan dari prosedure abstraksi:
14. User dapat mengamati fungsionalitas yang dikirimkan web application kepada end-user,
15. Operation diisi dalam kelas analisis yang melaksanakan perilaku bersahabat dengan
kelas.
Configuration Model
Configuration model menggambarkan lingkungan yang web application akan digunakan pada
sistem berbasis server dan berbasis klien :
16. Relationship-Navigation Analysis Relationship–navigation analysis (RNA)
memperkenalkan hampir semua hubungan elemen isi dan fungsional ditemukan pada
analysis model dan menentukan syarat–syarat untuk menemukan link navigasi yang tepat dari
keseluruhan sistem. Rangkaian dari jawaban pertolongan untuk menentukan hubungan
dan memperkenalkan karakteristik yang akan mempengaruhi pada desain navigasi. Pendekatan
RNA diorganisir ke dalam lima tahap :
1. Stakeholder analysis = mengenali berbagai kategori user dan membuat hierarki
stakeholder yang tepat.
2. Element analysis = mengenali isi obyek dan elemen fungsional yang menarik
perhatian end-user.
3. Relationship analysis = menggambarkan hubungan kerjasama yang ada diantara
elemen web application.
4. Navigation analaysis = memeriksa bagaimana user boleh mengakses elemen
perorangan atau elemen kelompok.
5. Evaluation analysis = memutuskan pokok permasalahan secara pragmatis
dihubungkan dengan pelaksanaan hubungan kerjasama yang didefinisikan segera.
17. Desain dan Kualitas WebApp Olsina et.al [OLS99] dalam pressman: 561, telah
menyiapkan “quality requirement tree” yang mengidentifikasikan satu set atribut untuk
menilai kualitas WebApp.Kriteria yang ada pada gambar di bawah ini menjadi bagian
menarik untuk Web engineers siapa yang harus mendesain, membangun, dan merawat
WebApps melewati jangka waktu yang lama :
Gambar 2 Quality Requirement Tree (Pressman: 561)
Offut [OFF02] dalam pressman: 561, memperluas lima kualitas utama atribut yang dicatat pada
gambar di atas dengan menambah atribut yang mengikutinya, yaitu:
21. Security,
22. Availability,
23. Scalability,
24. Time-to-market.
Design Goals
Menurut Jean Kaiser [KAI02] dalam pressman: 563, untuk mencapai kualitas atribut web
application, desain web application yang baik harus menampilkan:
9. Simplicity,
10. Consistency,
11. Identity,
12. Robustness,
13. Navigability,
14. Visual Appeal,
15. Compatibility.
&&&&&&&&
Daftar Pustaka
McGraw Hill, 1992
1.
MODUL PERKULIAHAN
PROYEK
PENGEMBANGAN
SISTEM INFORMASI
Modul Standar untuk

14
Abstract Kompetensi
Perancangan Database
Di UML, class diagram mendefinisikan struktur data yang dibutuhkan oleh
sebuah aplikasi. Struktur data yang tetap di database dimodelkan sebagai class entity dan
sebagai relasi diantara class entity. Class entity ini perlu dimappingkan ke struktur data
yang dikenal oleh database. Struktur data ini dangat tergantung pada model database
dimana bisa objek oriented, objek relational maupun relational. Pemodelan class dan
package class BCED (Boundary Control Entity Databases) merefleksikan class-class
aplikasi bukan struktur penyimpanan database.
Class-class entity mewakili databases objek di aplikasi, tetapi bukan class yang
menetap di database. Class-class database menyembunyikan komunikasi diantara
aplikasi dan database, akan tetapi mereka bukan persistent class. Oleh karenanya kita
masih perlu merancang layer persistent database. Layer persistent database bisa jadi
adalah relasional
ER Conceptual Data Model (CDM)
Karyawan Penerima
Kdkaryawan <pi> A9 <M> KdPenerima <pi> A9 <M>

NamaKaryawan VA20 NamaPenerima VA30
TglLahirKaryawan D KaryawanCatatTransaksi AlamatPenerima VA100
1,1 0,1
Sex VA9 KdPosPenerima VA9
PenerimaTransaksi TlpPenerima VA9
Status VA20
Alamat VA50 FaksPenerima VA9
KPKaryawan VA20 KPPenerima VA20
0,n 0,n
0,n 0,n
Pengirim
Transaksi
KdPengirim <pi> VA20 <M> 1,1 Jenis
NamaPengirim VA50 1,1
Pengirim Transaksi NoTransaksi <pi> A9 <M>
1,n JenisTransaksi KdJenis <pi> A9 <M>
AlamatPengirim VA100 TglTransaksi D
1,n BeratTransaksi VA20 NamaJenis VA20
KdPosPengirim VA10 1,n
TlpPengirim VA20
FaksPengirim VA20 1,n 0,n
KPPengirim VA20
SifatTransaksi
1,1
0,n 1,1 KotaPenerima

TagihanTransaksi Sifat
KdSifat <pi> A9 <M>
NamaSifat VA20
1,1 BiayaSifat DC12,2
Tagihan KotaTransaksi
NoTagihan <pi> A9 <M>
TagihanPengirim TglTagihan D
1,n
1,1 1,1
KotaPengirim 1,1 Kota

KdKota <pi> A9 <M>
NamaKota VA20
KotaKaryawan 1,1
Gambar 1. Conceptual data model (cdm)
Normalisasi
1NF
Keterangan :
NoTrans = NoTransaksi Nm = Nama Brt
= Berat
NoTag = No Tagihan Alm = Alamat Biy
= Biaya
TglTrans = TglTransaksi Kta = Kota Ktr
= Keterangan
K_Pgr = KodePengirim K_Pos = Kode_Pos
K_Pnr = KodePenerima Tlp = Telepon
K_Jns = KodeJenis Faks = Faksimile
K_Sft = KodeSifat K_Prs = KontakPerson
K_Kry = Kode_Karyawan Sts = Status
Jml = Jumlah TglTrm = TglTerima
2NF
23. Transaksi
24. Penerima
25. Pengirim
26. Karyawan
27. Tagihan
28. Sifat
29. Jenis
30. Kota
3NF
Transaksi
Tagihan
Diagram ER Physical Data Model (PDM)

Karyawan
Kdkaryawan CHAR(9) <pk>
KdKota CHAR(9) <fk> Penerima
NamaKaryawan VARCHAR(20) KdPenerima CHAR(9) <pk>
TglLahirKaryawan DATE FK_TRANSAKS_KARYAWANC_KARYAWAN
KdKota CHAR(9) <fk>
Sex VARCHAR(9) NamaPenerima VARCHAR(30)
Status VARCHAR(20) AlamatPenerima VARCHAR(100)
Alamat VARCHAR(50) KdPosPenerima VARCHAR(9)
KPKaryawan VARCHAR(20) FK_TRANSAKS_PENERIMAT_PENERIMA TlpPenerima VARCHAR(9)
FaksPenerima VARCHAR(9)
KPPenerima VARCHAR(20)
Transaksi
NoTransaksi CHAR(9) <pk>
Pengirim KdJenis CHAR(9) <fk5>
KdPenerima CHAR(9) <fk4>
KdPengirim CHAR(9) <pk> Kdkaryawan CHAR(9) <fk2> FK_TRANSAKS_JENISTRAN_JENIS
KdKota CHAR(9) <fk> FK_TRANSAKS_PENGIRIM__PENGIRIM KdSifat CHAR(9) <fk6>
NamaPengirim VARCHAR(30) KdKota CHAR(9) <fk7>
AlamatPengirim VARCHAR(100) Jenis
NoTagihan CHAR(9) <fk3>
KdPosPengirim VARCHAR(9) KdPengirim CHAR(9) <fk1> KdJenis CHAR(9) <pk>
TlpPengirim VARCHAR(20) TglTransaksi DATE NamaJenis VARCHAR(20)
FaksPengirim VARCHAR(20) BeratTransaksi VARCHAR(20)
KPPengirim VARCHAR(20)
FK_TRANSAKS_SIFATTRAN_SIFAT
FK_PENERIMA_KOTAPENER_KOTA
FK_TRANSAKS_TAGIHANTR_TAGIHAN
Sifat
KdSifat CHAR(9) <pk>
Tagihan NamaSifat VARCHAR(20)
NoTagihan CHAR(9) <pk> BiayaSifat NUMBER(12,2)
FK_TAGIHAN_TAGIHANPE_PENGIRIM KdPengirim CHAR(9) <fk>
TglTagihan DATE
FK_TRANSAKS_KOTATRANS_KOTA
FK_PENGIRIM_KOTAPENGI_KOTA
Kota
KdKota CHAR(9) <pk>
NamaKota VARCHAR(20)
FK_KARYAWAN_KOTAKARYA_KOTA
Gambar 2. Model er physical data model (pdm)
Perancangan Struktur Menu Tampilan

Struktur Menu Program Keseluruhan
Gambar 3. Perancangan struktur menu program keseluruhan
Struktur Menu Utama
Gambar 4. Perancangan struktur menu utama

Struktur Menu File
Gambar 5. Perancangan struktur menu file

Struktur Menu Record
Gambar 6. Perancangan struktur menu record
Struktur Menu Proccess
Gambar 7. Perancangan struktur menu proccess

Struktur Menu Report
Gambar 8. Perancangan struktur menu report

Struktur Menu Help
Gambar 9. Perancangan struktur menu help
Struktur Menu Utility
Gambar 10. Perancangan struktur menu utility
Perancangan Input Output

Form Login
Pada rancangan layar Login, User harus measukkan Username dan
Password untuk dapat memasuki layar menu utama. Apabila user salah
measukkan password, maka akan muncul pesan “invalid user ID or password”.
Berikut rancangan layar login pada Gambar 11
Gambar 11. Tampilan form login

Keterangan gambar :
 Username
Admin harus memasukkan usernamenya dengan benar
 Password
Admin harus memasukkan password dengan benar.
 Login
Untuk memasuki layar menu admin apabila username dan password sesuai.
Layar Menu Utama

Setelah login berhasil operator dapat melakukan transaksi pembayaran
atau input data baru dengan menggunakan fasilitas yang tersedia pada form menu,
dalam bentuk menubar yang ter diri atas;
 File
Pada menubar File berisi menu item Loogoff dan Exit. Data Operator
digunakan untuk melakukan login untuk operator baru, dan untuk mengakhiri
program dari menu file.
 Record
Pada menubar Record menyediakan fasilitas bagi operator data entry untuk
melakukan penambahan dan pengeditan beberapa data antra lai : data
pengirim, data penerima, data karyawan dan data parameter.
 Proceess
Pada menubar process ini digunakan untuk memproses suatu transaksi yang
berlangsung, proses konfirmasi penerimaan dan proses penagihan atas
beberapa transaksi.
 Report
Pada menubar report ini operator data entry dapat melihat bebrapa data
diantranya adalah data pengirim, data penerima, data tagihan dan data tagihan
yang kemudian dapat dicetak sebagai dibuat laporan.
 Help
Apabila didalam pengoperasian aplikasi ini menemui sebuah masalah maka
menu ini mungkin bisa membantu para pengguna untuk menyelesaikan
masalah yang didapatkan dalam aplikasi ini.
 BussinessSetup
Pada menubar ini bila seorang user berstatus admin maka ia dapat
menggunakan menubar ini untuk menambah user, dan mengedit data
rekening perusahaan tersebut.
Gambar 12. Tampilan Form Utama (mainform).
Tampilan Form Data Pengirim

Form ini digunakan untuk melihat data dan menginput data pengirim serta
untuk menanipulasi dan menghapus data pengirim, pada form ini berisi beberapa data
sebagai berikut :
25. Kode Pengirim, berisi kode dari pengirim.
26. Nama Pengirim, menjelaskan nama pengirim dengan jelas.
27. Alamat, untuk mengetahui data alamat pengirim dengan benar.
28. Telpon, untuk alat komunikasi dengan pengirim.
Gambar 13. Tampilan form data pengirim
49. Tampilan Form Tambah Data Pengirim
form ini juga dapat digunakan untuk menambahkan data pengirim diantaranya :
Gambar 14. Tampilan form tambah data pengirim
Tampilan Form Data Penerima

Form ini digunakan untuk melihat data dan menginput data penerima serta
untuk menanipulasi dan menghapus data penerima, pada form ini berisi beberapa data
sebagai berikut :
44. Kode Penerima, berisi kode dari penerima.
45. Nama Penerima, menjelaskan nama penerima dengan jelas.
46. Alamat, untuk mengetahui data alamat penerima dengan benar.
47. Telpon, untuk alat komunikasi dengan penerima.
Gambar 15. Tampilan form data penerima
Tampilan Form Tambah Data Penerima

form ini juga dapat digunakan untuk menambahkan data penerima diantaranya :
Gambar 16. Tampilan form tambah data penerima
Tampilan Form Data Karyawan

Form ini digunakan untuk melihat data dan menginput data karyawan serta
untuk menanipulasi dan menghapus data karyawan, pada form ini berisi beberapa
data sebagai berikut :
32.Kode Karyawan, berisi kode dari karyawan.
33.Nama Karyawan, menjelaskan nama karyawan dengan jelas.
34.Alamat, untuk mengetahui data alamat karyawan dengan benar.
35.Telpon, untuk alat komunikasi dengan karyawan.
Gambar 17. Tampilan form data karyawan
Tampilan Form Tambah Data Karyawan

form ini juga dapat digunakan untuk menambahkan data karyawan diantaranya :
Gambar 18. Tampilan form tambah data karyawan
Tampilan Form Data Transaksi Pengiriman

data juga hasil data yang sudah masuk dari sebuah proses transaksi pengiriman.
Form ini juga menyediakan tombol simpan, buat baru dan hapus untuk mengkoreksi
atau menghilangkan data yang sudah ada
Gambar 19. Tampilan form data transaksi
50. Tampilan Form Tambah Transaksi Pengiriman

Setelah kita menampilkan form utama proses transaksi pengiriman dan untuk
menambahkan data transaksi yang baru dengan mengklik tombol tambah (add),
maka form yang selanjutnya ditampilkan adalah form berikut ini :
Gambar 20. Tampilan form tambah transaksi

Tampilan Form Konfirmasi Transksi Pengiriman
Form ini adalah digunakan untuk memproses konfirmasi atas transaksi-
trasaksi yang dikirim
Gambar 21. Tampilan form konfirmasi pengiriman
Tampilan Form Proses Penagihan

Pada form poses penagihan ini digunakan oleh operator untuk membuat atau
memproses tagihan kepengirim atas transaksi-transaksi yang telah dilakukan dan
dianggap benar, operator dapat melakukan proses penagihan berdasarkan tanggal dan
kode pengirim :
Gambar 22. Tampilan form proses penagihan

Tampilan Form Proses Penagihan untuk Melihat Detail Tagihan
Setelah melakukan proses penagihan dan kita ingin melihat detail dari nomor
tagihan tersebut, maka kita dapat mengklik tabpane yang berada disebelah kanannya.
Form ini berisi data-data tagihan.
Gambar 23. Tampilan form detail tagihan
Pada form proses penagihan
Tampilan Form Parameter untuk Kota Pengiriman
Karena pada pada proses pengiriman barang atau paket itu oleh beberapa
kriteria, akan tetapi hal yang paling menentukan banyak atau sedikitnya biaya yang
dibutuhkan yaitu kota tujuan atau jarak jauh dekatnya tujuan dari penerima barang
tersebut. Oleh karena itu dibutuhkan sebuah ukuran untuk menentukan biaya yang
dibuhkan, dan untuk keperluan tersebut maka dapat di lakukan pada form berikut ini
:
Gambar 24. Tampilan form parameter kota
Tampilan Form Parameter untuk Sifat Pengiriman

Pada form ini berguna untuk memberikan informasi sifat dari pengiriman dan
dapat dijadikan acuan untuk menghitung biaya yang dibutuhkan, sehingga kita dapat
membrikan pilhan kepada pelanggan (pengirim) untuk apat memilih sifat pengiriman
yang dipilih sesuai dengan kebutuhan.
Gambar 25. Tampilan form parameter sifat
Tampilan Form Parameter untuk Jenis Pengiriman

Pada form ini berguna untuk memberikan informasi jenis dari pengiriman
dan dapat dijadikan sebagai sebuah data tambahan didalam proses transaksi
pengiriman.
Gambar 26. Tampilan form parameter jenis
Tampilan Form Laporan Data Penerima

Form laporan data penerima ini untuk mncetak data yang berfungsi untuk
laporan dari operator ke manager. Operator hanya mengimput kode penerima lewat
Gambar 27. Tampilan form laporan data penerima
Tampilan Form Laporan Data Pengirim
Form laporan data pengirim ini untuk mncetak data yang berfungsi untuk
laporan dari operator ke manager. Operator hanya mengimput kode pengirim lewat
Gambar 28. Tampilan form laporan data pengirim
Tampilan Form Laporan Data Transaksi

Form laporan data transaksi ini untuk mncetak data yang berfungsi untuk
laporan dari operator ke manager. Operator hanya mengimput kode pengirim dan
tanggal pengiriman lewat menu drop down yang telah disediakan. Dan bila data yang
dipilih telah sesuai maka data tersebut akan ditampilkan di tabel tersebut.
Gambar 29. Tampilan form laporan data transaksi
Tampilan Form Laporan Data Tagihan

Form laporan data tagihan ini untuk mncetak data yang berfungsi untuk
laporan dari operator ke manager. Operator hanya mengimput nomor tagihan lewat
data-data transaksi yang telah berlangsung selama satu periode tersebut akan
ditampilkan di tabel tersebut.
Gambar 30. Tampilan form laporan data tagihan

Tampilan Form Data Rekening
Form ini digunakan untuk mengisi data rekening dari perusahaan yang bersangkutan.
Gambar 31. Tampilan form laporan data rekening
Tampilan Form Tambah Data User

Form ini digunakan untuk menambah, menghapus serta mengedit data user yang
berhak untuk mngoperasikan aplikasi tersebut.
Gambar 32. Tampilan form tambah user

Tampilan Form Bantuan (Help)
Pada form bantuan ini, untuk dapat mejadi fasilitas tambahan bagi seorang
operator baru yang ingin mengetahui cara penggunaan aplikasi yang dibuat.
28. About
pemanfaatan aplikasi tersebut.
Gambar 33. Tampilan Form Bantuan (Help) untuk About
29. Content
beberapa hal.
36. Tata cara konfigurasi dan install
37. Tentang Aplikasi Delivery Sistem version 1.1
38. Tentang pembuat aplikasi (Programer).
39. Sedikit penjelasan tentang bahasa pemrograman Java
Gambar 34. Tampilan form bantuan (help) untuk content
51. Perancangan layar Output

52. Laporan Data Transaksi
Gambar 3.62. Rancangan output data transaksi
53. Hasil Cetak Data Pengirim Per Kode Pengirim

Per kode pengirim
Hasil Cetak Data Pengirim Per Kode Penerima

Per kode penerima
Hasil Cetak Data Karyawan

Gambar 37. Rancangan output data karyawan
Per kode karyawan
Laporan Data Penerima
Laporan Data Pengirim
Laporan Data Tagihan
Gambar 40. Rancangan output data tagihan
Implementasi Sistem
Tahap perancangan diikuti oleh tahap implementasi. Menterjemahkan perancangan ke
kode program adalah proses yang relative sederhana dan bersifat mekanis sebab
perancangan yang baik sudah mengambarkan dengan baik apa yang harus dilakukan
dengan bahasa-bahasa pemrograman. Asalkan kita telah melakukan pemodelan dengan
baik (misalnya dengan menggunakan UML yang penulis telah gunakan ) dan
mempergunakan banyak perangakat-perangkat lunak berjenis CASE (Computer Aided
Software Engineering) yang baik, misalnya Rational Rose dan Visual Paradigm yang
penulis gunakan yang akan dengan mudah menterjemahkan model-model kita tadi
kedalam sintak beberapa bahasa pemrograman.
Daftar Pustaka
McGraw Hill, 1992

Modul Proyek Pengembangan Sistem Informasi PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Modul Proyek Pengembangan Sistem Informasi PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

MODUL PERKULIAHAN

Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh

Tahapan dari siklus hidup sistem yaitu :

a. Tanggung Jawab Eksekutif

b. Komite Pengarah SIM (steering committee MIS – SC MIS)

Komite Pengarah SIM melaksanakan tiga fungsi utama, yaitu :

Keuntungan yang dicapai :

 Semakin besar kemungkinan komputer akan digunakan untuk mendukung pemakai di

 Menentukan lingkup dari proyek

 Mengenali berbagai area permasalahan potensial

 Mengatur urutan tugas

 Memberikan dasar untuk pengendalian

c. Menentukan tujuan sistem

d. Mengidentifikasi kendala sistem

e. Membuat studi kelayakan

- Teknis; tersediakan hardware dan software untuk melaksanakan pemrosesan yang

f. Menyiapkan usulan penelitian sistem

g. Menyetujui atau menolak proyek penelitian

- Akankah sistem yang diusulkan dapat mencapai tujuannya ?

h. Menetapkan mekanisme pengendalian

Secara diagram tahapan perencanaan nampak pada Gambar 2

7. Menyetujui / menolak proyek peneltitian

8. Menetapkan mekanisme pengendalian

Gambar 2. Tahap Perencanaan dari SLC

Adapun tahapannya yaitu :

a. Mengumumkan Penelitian Sistem

1) alasan perusahaan melaksanakan proyek

b. Mengorganisasikan Tim Proyek

c. Mendefinisikan Kebutuhan Informasi

- Menyediakan komunikasi dua arah dan pengamatan terhadap bahasa tubuh.

d. Mendefinisikan Kriteria Kinerja Sistem

e. Menyiapkan Usulan Rancangan

f. Menerima atau Menolak Proyek Rancangan

8.2. Dampak pada operasi perusahaan

8.3. Dampak pada sumber daya perusahaan

9) Rencana pengembangan umum (tahap analisis, rancangan dan penerapan)

a. Menyiapkan rancangan sistem yang terinci

b. Mengidentifikasi berbagai alternatif konfigurasi sistem

c. Mengevaluasi berbagai alternatif konfigurasi sistem

e. Menyiapkan usulan penerapan

f. Menyetujui atau menolak penerapan sistem

8.2. Dampak pada operasi perusahaan

8.3. Dampak pada sumber daya perusahaan

9) Rencana penerapan umum

Komite Analis Sistem

Gambar 4. Diagram Tahapan Perancangan dari SLC

c. Mendapatkan sumber daya perangkat keras;

- Surat yang ditransmisikan

d. Mendapatkan sumber daya perangkat lunak;

f. Menyiapkan fasilitas fisik;

g. Mendidik peserta dan pemakai;

h. Menyiapkan usulan cutover;

i. Menyetujui atau menolak masuk ke sistem baru;

j. Masuk ke sistem baru.

7. Mendidik Peserta &

10. Ganti Sistem Baru

4. Menyiapkan usulan rekayasa ulang

5. Menyetujui atau menolak rekayasa ulang sistem

rekayasa ulang sistem

Gambar 6. Diagram Tahapan Penggunaan dari SLC

Adapun jenis-jenis Prototipe, yaitu :

Prototype jenis I, sesungguhnya akan menjadi sistem operasional. Langkah-langkah

Gambar 7. Pengembangan Prototipe Jenis I