MODUL PERKULIAHAN PROYEK PENGEMBANGAN SISTEM …fasilkom.mercubuana.ac.id/wp-content/...Pengembangan-Sistem-Infor… · 2014 3 Proyek Pengembangan Sistem Informasi Modul 01 Pusat

2014 1

Proyek Pengembangan Sistem Informasi Modul 01 Pusat Bahan Ajar dan eLearning

Team Dosen http://www.mercubuana.ac.id

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

Ilmu Komputer Sistem Informasi

01 87007 Team Dosen

Abstract Kompetensi

Definisi Sistem, subsistem, super sistem, dan karakteristik sistem

Memahami siklus pengembangan sistem, memahami metodhologi pengembangan sistem, mengenal UML

2014 2



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

2014 3



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.

2014 4



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

2014 5



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 ?

2014 6



- 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).

2014 7



Secara diagram tahapan perencanaan nampak pada Gambar 2

Komite Pengarah SIM Manajer

Analis Sistem

2014 8



Gambar 2. Tahap Perencanaan dari SLC

1 Menyadari

masalah

2 Mendefinisikan

masalah

3 Menentukan tujuan sistem

4 Mengidentifikasi kendala sistem

Konsultasi

5 Membuat

studi kelayakan

6 Usulan

penelitian sistem

7. Menyetujui / menolak proyek peneltitian

8. Menetapkan mekanisme pengendalian

2014 9



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

2014 10



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

2014 11



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

2014 12



Komite Pengarah SIM Manajer

Analis Sistem

1 Mengumumkan penelitian sistem

2 Mengorganisasikan tim proyek

3 Mendefinisikan kebutuhan informasi

4 Mendefinisikan kriteria kinerja sistem

5 Menyiapkan

usulan rancangan

6 Menerima / menolak proyek penelitian

2014 13



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.

2014 14



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

2014 15




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

Pengarah

SIM

Manajer Analis Sistem

2014 16



Gambar 4. Diagram Tahapan Perancangan dari SLC

5. TAHAP PENERAPAN

1. Menyiapkan rancangan sistem terinci

2. Mengidentifikasi alternatif

konfigurasi sistem

3. Mengevaluasi alternatif

konfigurasi sistem

4. Memilih konfigurasi

terbaik

5. Menyiapkan usulan

penerapan

6. Menyetujui / menolak

penerapan sistem

Mengatur

2014 17



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

2014 18



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 :

2014 19



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.

2014 20



Komite Pengarah

SIM Manajer

Spesialis Informasi

3. Mendapatkan SD -

Hardware

4. Mendapatkan SD -

Software

10. Ganti Sistem Baru

Mengontro

l

Me

ngo

ntro

l

Mengontro

l

1. Merencanakan Penerapan

2. Mengumumkan Penerapan

5. Menyiapkan database

6. Menyiapkan Fasilitas

Fisik

7. Mendidik Peserta &

Users

8. Menyiapkan Usulan

Ganti Sistem

9. Menyetujui atau Menolak

Penggantian Sistem Baru

2014 21



Gambar 5. Diagram Tahapan Penerapan (Implementasi) dari SLC

2014 22



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.

2014 23



Komite Pengarah

SIM Manajer

Spesialis Informasi

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

2. Pengaudit Sistem

3. Memelihara

Sistem

4. Mempersiapkan

Usulan Rekayasa

Ulang

5. Menyetujui / menolak

rekayasa ulang sistem

1.

Menggunakan Sistem

Mengatur

2014 24



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 :

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

Menggunakan

Prototipe

Prototipe

dapat

diterima ?

Ya

Tidak

2014 25



Gambar 8. Pengembangan Prototipe Jenis II

Mengidentifikasi

Kebutuhan Pemakai

Mengembangkan

Prototipe

Prototipe

dapat

diterima ?

Ya

Tidak

Mengkodekan Sistem

Operasional

Menguji Sistem

Operasional

Menggunakan Sistem

operasional

Sistem

dapat

diterima ?

Tidak

Ya

2014 26



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 :

2014 27



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

2014 28



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.

2014 29



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 !

2014 30



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.

2014 1



MODUL PERKULIAHAN





02 87007 Team Dosen

Abstract Kompetensi


Memahami siklus pengembangan sistem, memahami metodhologi

2014 2



pengembangan sistem, mengenal UML

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

2014 3



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

2014 4



Gambar 1. Contoh Functional Requirement

2014 5



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.

2014 6



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

2014 7



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

2014 8



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

2014 9



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

2014 10



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.

2014 11



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.

2014 12



Gambar 3 Karakteristik dari Stategi Analisa Proses.

2014 13



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

2014 1



MODUL PERKULIAHAN





03 87007 Team Dosen

Abstract Kompetensi



2014 2




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

2014 3



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

2014 4



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

2014 5



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

2014 6



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.

2014 7



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.

2014 8



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

2014 9



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 :

2014 10



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 :

2014 11



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

2014 12



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

2014 13



:

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

2014 14



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



2014 15



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


2014 16



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.

2014 17



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).

2014 18



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

2014 19



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

2014 20



Per kode karyawan

Laporan Data Penerima


Laporan Data Pengirim


Laporan Data Tagihan

2014 21



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.

2014 22



Daftar Pustaka



Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4 th,

McGraw Hill, 1992






2014 1



MODUL PERKULIAHAN





04 87007 Team Dosen

Abstract Kompetensi



2014 2




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

2014 3



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.

2014 4



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

2014 5



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

2014 6



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

2014 7



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++.

2014 8



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

2014 9



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

2014 10



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

2014 11



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

2014 12



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

2014 13



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 )

2014 14



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

2014 15



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.

2014 16



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

2014 17



Daftar Pustaka




McGraw Hill, 1992






2014 1



MODUL PERKULIAHAN

PROYEK

PENGEMBANGAN SISTEM INFORMASI




06 87007 Team Dosen

Abstract Kompetensi

Memahami kebutuhan sistem Menentukan kebutuhan teknik dan menganalisa kebutuhan

2014 2



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)

2014 3



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

2014 4



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.

2014 5



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.

2014 6



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.

2014 7



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.

2014 8



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

2014 9



Gambar 3. Notasi Use Case

2014 10



Gambar 4. Use Case Diagram

Gambar 5. Extend dan Include Relationship.

2014 11



Gambar 6. Cara Identifikasi Use Case

Daftar Pustaka




McGraw Hill, 1992






2014 1



MODUL PERKULIAHAN

PROYEK





07 87007 Team dosen

Abstract Kompetensi


2014 2



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.

2014 3



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

2014 4



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

2014 5



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

2014 6



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

2014 7



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 :

2014 8



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

2014 9



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 :

2014 10



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.

2014 11



&&&&&&&

Daftar Pustaka




McGraw Hill, 1992






2014 1



MODUL PERKULIAHAN

Proyek Pengembangan Sistem Informasi




08 87007 Team Dosen

Abstract Kompetensi


2014 2



2014 3



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

2014 4



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 :

2014 5



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.

Actor Actor

Gambar 5 Use case model

Sistem

Use Case

2014 6



Penjaga Toko

Buat Laporan

Petugas Stok

Hitung Stok Barang

Petugas Keuangan

Hitung Penjualan

EntrY Permintaan

View Permintaan

<<extend>>

<<include>>

<<include>>

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.

2014 7



Nama Class

Attibute

Operasi

Gambar 7 Sebuah class dalam UML

Gambar 8 Contoh class diagram penjualan VCD

Activity Diagram

Activity diagram menggambarkan berbagai alir aktifitas dalam sebuah sistem yang sedang

Class

1. Attribut : tipe

2. Operasi : tipe

Cabang

Nama Cabang

Pelanggan

Nama Pelanggan

Pembayaran

Jumlah

Tunai

JmlKembalian

Order

No

Tgl

status

Order Detail

Jumlah

Kartu Kredit

No

expDate

Item Barang

Nama Barang

Harga

2014 8



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

Tidak membeli VCD

Datang ke

gallery

VCD

Memilih

VCD yang

dibeli

Petugas

Keuangan

Bayar VCD

yang dibeli

2014 9



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

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

Name 1 Name 2

2014 10



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.

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.

Nama

State Variable

Activities

2014 11



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.

2014 12



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

2014 13



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

2014 14



Daftar Pustaka




McGraw Hill, 1992






2014 1



MODUL PERKULIAHAN





09 87007 Team Dosen

Abstract Kompetensi


2014 2



2014 3



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.

2014 4



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

2014 5



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

2014 6



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 verif ikasi.

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

2014 7



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

2014 8



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

2014 9



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

yang dikerjakan

perusahaan.

Mendeskripsikan sistem

yang akan/sedang

dikembangkan dalam

perusahaan.

Aktor Bersifat eksternal

terhadap perusaan

Bersifat eksternal terhadap

sistem yang akan/sedang

dikembangkan

Pekerja Bisnis Bersifat internal dalam

perusahaan

Tidak digunakan

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

verifikasi user untuk menggunakan

sistem

Operator Data

Entry

Proses Login

(verifikasi user)

2 Operator Data Entry melakukan input

proses transaksi pengiriman yang

berisi data pengirim dan tujuan

penerima

Operator Data

Entry

Transaksi

pengiriman,

Input Data

Pengirim, Input

Data Penerima

2014 10



3. Sesudah data dan informasi dengan

benar maka operator data entry

membuat nota pembayaran dari suatu

transaksi terebut

Operator Data

Entry

Pembayaran,

Tagihan

4 Dengan sudah masuknya semua data

ke database computer, proses

selanjutnya adalah membuat laporan

berkala yang diperlukan untuk

keperluan-keperluan lain yang

berhubungan dengan proses yang

berlangsung di perusahaan tersebut.

Operator Data

Entry

Buat Laporan,

Laporan Data

Pengirim ,

Laporan Data

Penerima,

Laporan Data

Transaksi,

Laporan Data

Tagihan

5. Untuk melakukan tugas lainnya maka

diperlukan pegawai lainnnya, oleh

karena itu diperluka pendataan

pegawai dengan benar.

Data Pegawai

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 :

2014 11



Gambar 6 Diagram use case diagram

&&&&&&&&&

2014 12



Daftar Pustaka




McGraw Hill, 1992






2014 1



MODUL PERKULIAHAN





10 87007 Team Dosen

Abstract Kompetensi


2014 2



2014 3



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

Description

Use case ini merupakan awal dari semua kegiatan

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.

2014 4



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

Description

Use case ini merupakan tempat untuk melakukan

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

2014 5



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

Description

Walaupun sebenarnya data pengirim secara tidak

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



2014 6





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

Description

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 .

2014 7








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

Description

Use case ini memungkin operator data entri untuk

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 .


2014 8







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


Brief

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 .



2014 9



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


Brief

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

2014 10



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


Brief

Description



dari proses transaksi yang telah terjadi. Kemudian

data tersebut akan dibuat sebuah tagihan secara

berkala

2014 11



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

2014 12




Brief

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.






2014 13




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


Brief

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

2014 14



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

2014 15



Tabel 13 Kandidat class entity pada aplikasi pengiriman barang pada PT. X

No Requirement Class Entity

1. Operator Data Entry ingin Login terhadap sistem

dengan menginputkan data user name dan

password, maka sistem akan memvalidasi user

name dan password tersebut

Operator Data Entry

(Data User).

2. Transaksi terjadi saat pelanggan ingin melakukan

pengiriman dokumen atau paket menggunakan jasa

perusahaan tersebut kebeberapa kota tujuan dengan

berbagai bentuk pilihan jenis dan sifat pengiriman.

Transaksi, Jenis

Pengiriman dan Sifat

Pengiriman

3. Saat melakukan transaksi tentu saja dibutuhan

beberapa data, untuk itu diperlukan data pengirim

dan data penerima. Sehingga barang yang dikirim

terdapat keterangan siapa pengirimnya dan

keterangan penerimanya

Data Pengirim, Data

Penerima

4. Setelah proses memasukan data yang dibutuhkan

saat transaksi tersebut, maka akan diproses

pembayaran yang berlangsung saat itu apakah

secara tunai atau dibuat tagihan.

Pembayaran

5. Pada saat proses pembayaran yang dilakukan tidak

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

Tagihan

Langkah selanjutnya adalah membuat class diagram. Dengan mengacu pada ilustrasi tabel diatas

maka kita bisa melakukan pemodelan diagram class tersebut.

2014 16



Gambar 7 Class Diagram

2014 17



Daftar Pustaka




McGraw Hill, 1992






2014 1



MODUL PERKULIAHAN

PROYEK





11 87007 Team Dosen

Abstract Kompetensi


2014 2



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

2014 3



:

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

Description

Operator Data Entry ingin Login terhadap sistem

dengan menginputkan data user name dan

2014 4



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


2014 5



Brief

Description

Use case ini memungkinkan seseorang operator data

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

2014 6



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

Description

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.


2014 7







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

Description

Walaupun sebenarnya data penerima secara tidak



keterangan yang lebih terperinci data penerima



atau mengedit data penerima.

Exception Data untuk keterangan yang dibutuhkan untuk data

2014 8



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.



2014 9



berubah.

Tabel 5 Spesifikasi naratif untuk use case input data karyawan tingkat perancangan

Use case name Input Data Karyawan


Brief

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


2014 10







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


Brief

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.


2014 11



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


Brief

Description



2014 12



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

2014 13



Use case name Laporan Data Tagihan


Brief

Description



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.

2014 14




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


Brief

Description




akan dibuat laporan berdasarkan kode pengirim .




bertujuan untuk mengetahui data-data

pengirim yang menggunkan jasa perusahaan

tersebut.




Laporan.




memproses data.



berlaku.



2014 15







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


Brief

Description




akan dibuat laporan berdasarkan kode penerima.




bertujuan untuk mengetahui data-data

pengirim yang menggunkan jasa perusahaan

tersebut.




Laporan.




2014 16



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

2014 17



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,

password).

Data_User

2014 18



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.

2014 19



Data_UserProsesLogin

KoneksiDatabase

FormLogin

MainForm

FormDataPenerima

FormLaporanPenerima

FormDataPengirim

FormLaporanPengirim

FormProsesTagihan

FormLaporanTagihan

FormDataKaryawan

FormTransaksiPengiriman

FormLaporanTransaksi

AddEditDataPenerima

ProsesLaporanPeneri

ma

AddEditDataPengirim

ProsesLaporanPengiri

m

ProsesTagihan

ProsesLaporanTagihan

AddEditDataKaryawan

AddTransaksiPengirim

an

ProsesLaporanTransak

si

Penerima

Pengirim

Tagihan

Karyawan

Sifat

Transaksi

Jenis

Gambar 4 Class diagram tingkat desain

Tabel 12 Daftar attribut dan operasi pada class tingkat perancangan

Class Attribut Operasi

MainForm <<Komponen

Tampilan Form>>

Tampilkan Form(frame :

JFrame)

KoneksiDatabase()

BelumLogin()

LoginSukses()

UnLoadWindow()

KonneksiDatabase koneksi_database()

load_DriverJDBC()

Connection koneksiDatabase()

getData()

2014 20



getResourceBundle()

FormLogin <<Komponen

Tampilan Form>>

FormLogin()

Close Form()

ProsesLogin dataUser

dataPassword

Status

CheckUserPassword()

Check Status()

KoneksiDatabase()

ValidasiUserdanPassword()

Data_User NamaUser

Password

Status

ValidasiUserPassword()

FormDataPengirim <<Komponen

Tampilan Form>>

FormDataPengirim(frame :

JFrame)

CreateTable()

reloadRecord(scrSQL : string)

reloadRecord()

KoneksiDatabase()

Close()

AddEditDataPengirim <<Komponen

Tampilan Form>>

Add_Edit_Data_Pengirim(fra

me : JFrame)

listener_tombol()

tampilKode()

clearFields()

KoneksiDatabase()

dispose()

Pengirim KodePengirim

NamaPengirim

Alamat

Kota

NoTelpon

KodePos

Simpan()

Update()

SelectData()

Cetak()

FormDataPenerima <<Komponen FormDataPenerima(frame :

2014 21



Tampilan Form>> JFrame)

CreateTable()


reloadRecord()

KoneksiDatabase()

Close()

AddEditDataPenerima <<Komponen

Tampilan Form>>

Add_Edit_Data_Penerima(fra

me : JFrame)

listener_tombol()

tampilKode()

clearFields()

KoneksiDatabase()

Dispose()

Penerima Kode Penerima

Nama Penerima

Alamat

Kota

NoTelpon

KodePos

Simpan()

Update()

SelectData()

Cetak()

FormDataKaryawan <<Komponen

Tampilan Form>>

FormDataKaryawan(frame :

JFrame)

CreateTable()


reloadRecord()

KoneksiDatabase()

Close()

AddEditDataKaryawan <<Komponen

Tampilan Form>>

Add_Edit_Data_Karyawan(fra

me : JFrame)

listener_tombol()

tampilKode()

clearFields()

2014 22



KoneksiDatabase()

Dispose()

Karyawan KodeKaryawan

NamaKaryawan

TglLahir

Alamat

Kota

NoTelpon

KontakPerson

Simpan()

Update()

SelectData()

Cetak()

FormTransaksiPengiriman <<Komponen

Tampilan Form>>

FormTransaksiPengiriman(fra

me : JFrame)

CreateTable()


reloadRecord()

KoneksiDatabase()

Close()

AddTransaksiPengiriman <<Komponen

Tampilan Form>>

AddTransaksiPengiriman(fram

e : JFrame)

listener_tombol()

ambilNoTran()

inputdataPenerima()

inputDataPengirim()

biaya()

KoneksiDatabase()

Dispose()

Transaksi TglTransaksi

NoTransaksi

KodePengirim

KodePenerima

JenisPengiriman

SifatPengiriman

SelectData()

Cetak()

2014 23



Biaya

NamaKurir

FormProsesTagihan <<Komponen

Tampilan Form>>

FormProsesPenagihan(frame :

JFrame)

tambahListener()

tampilNoTagihan()

tampilDataKeTabel()

Close()

KoneksiDatabase()

ProsesTagihan Update Data()

Proses()

Input Kriteria()

ProsesInputan()

Dispose()

KoneksiDatabase()

getData()

Cetak()

Tagihan NoTagihan

TglTagihan

Jumlah

SelectData

FormLaporanPenerima <<Komponen

Tampilan Form>>

FormLapPenerima()

KoneksiDatabase()

TampilkankeTabel()

Close()

ProsesLaporanPenerima InputKriteria()

KoneksiDatabase()

TambahListerner()

ProsesSelect()

Cetak()

getData()

FormLaporanPengirim <<Komponen FormLapPengirim()

2014 24



Tampilan Form>> KoneksiDatabase()

TampilkankeTabel()

Close()

ProsesLaporanPengirim InputKriteria()

KoneksiDatabase()

TambahListerner()

ProsesSelect()

Cetak()

getData()

FormLaporanTransaksi <<Komponen

Tampilan Form>>

FormLapTransaksi()

KoneksiDatabase()

TampilkankeTabel()

Close()

ProsesLaporanTransaksi InputKriteria()

KoneksiDatabasev

TambahListerner()

ProsesSelect()

Cetak()

getData()

FormLaporanTagihan <<Komponen

Tampilan Form>>

FormLapTagihan()

KoneksiDatabase()

TampilkankeTabel

Close()

ProsesLaporanTagihan InputKriteria()

KoneksiDatabase()

TambahListerner()

ProsesSelect()

Cetak()

getData()

2014 25



Daftar Pustaka




McGraw Hill, 1992






2014 1



MODUL PERKULIAHAN

PROYEK





12 87007 Team Dosen

Abstract Kompetensi


2014 2



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

2014 3



Sequence Diagram untuk Use Case Transaksi Pengiriman

Gambar 3. Sequence diagram use case transaksi pengiriman

2014 4



Sequence Diagram untuk Use Case Input Data Pengirim

Gambar 4. Sequence diagram use case input data pengirim

2014 5



Sequence Diagram untuk Use Case Input Data Penerima

Gambar 5. Sequence diagram use case input data penerima

2014 6



Sequence Diagram untuk Use Case Input Data Karyawan

Gambar 6. Sequence diagram use case input data karyawan

2014 7



Sequence Diagram untuk Use Case Proses Tagihan

Gambar 7. Sequence diagram use case proses tagihan

2014 8



Sequence Diagram untuk Use Case Laporan Transaksi

Gambar 8. Sequence diagram use case laporan transaksi

2014 9



Sequence Diagram untuk Use Case Laporan Pengirim

2014 10



Gambar 9. Sequence diagram use case laporan pengirim

Sequence Diagram untuk Use Case Laporan Penerima

2014 11



Gambar 9. Sequence diagram use case laporan penerima

2014 12



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

2014 13



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

2014 14



State Machine Diagram Tagihan

Gambar 12. State machine diagram tagihan

2014 15



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,

2014 16



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

2014 17



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.

Secara umum, business rule services mengandung class-class bisnis dari interface-

interface yang dipakai diaplikasi. Sedangkan class data translation akan menjdi interface

CRUD(Create, Read, Update, Delete). Adapun DASVC.DLL akan menjalankan beberapa

Mengandung class-class bisnis seperti

pelangga, pengirim, penerima, transaksi dll.

Menangani aliran kerja dan

menyiapkan user interface yang gampang

dioperasikan.

Mengkomunikasikan class di layer in

i dengan layer DTS.

Mengandung class-class translasi

Membuat statement sql untuk mengakses layer

Data Access

Mengandung SQL umum untuk akses data

seperti DARetrieve (Select) dan DAQuery

Busi

ness

Rul

e

Sevi

ce

BRS

VC.

DL

L

Data

Tran

slati

on

Serv

ice

DTS

VC.

DLL

Data

Acce

ss

Serv

ice

DAS

VC.

DLL

2014 18



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

2014 19



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

&&&&&&

2014 20



Daftar Pustaka




McGraw Hill, 1992






2014 21



2014 1



MODUL PERKULIAHAN

PROYEK





13 87007 Team Dosen

Abstract Kompetensi


2014 2



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.

2014 3



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

2014 4



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

2014 5



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

2014 6



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.

2014 7



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 :

2014 8



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 :

2014 9



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,

2014 10



11. Identity,

12. Robustness,

13. Navigability,

14. Visual Appeal,

15. Compatibility.

&&&&&&&&

2014 11



Daftar Pustaka




McGraw Hill, 1992






2014 1



1.

MODUL PERKULIAHAN

PROYEK





14 87007 Team Dosen

Abstract Kompetensi


2014 2



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

2014 3



ER Conceptual Data Model (CDM)

Pengirim Transaksi1,1

1,n

KaryawanCatatTransaksi1,1

0,n

TagihanTransaksi

1,1

1,n

PenerimaTransaksi

0,1

0,n

JenisTransaksi

1,1

1,n

SifatTransaksi1,1

1,n

KotaTransaksi

1,1

0,n

KotaPenerima

0,n

1,1

KotaKaryawan

0,n

1,1

KotaPengirim

0,n

1,1

TagihanPengirim

1,1

1,n

Transaksi

NoTransaksi

TglTransaksi

BeratTransaksi

<pi> A9

D

VA20

<M>

Pengirim

KdPengirim

NamaPengirim

AlamatPengirim

KdPosPengirim

TlpPengirim

FaksPengirim

KPPengirim

<pi> VA20

VA50

VA100

VA10

VA20

VA20

VA20

<M>

Karyawan

Kdkaryawan

NamaKaryawan

TglLahirKaryawan

Sex

Status

Alamat

KPKaryawan

<pi> A9

VA20

D

VA9

VA20

VA50

VA20

<M>

Tagihan

NoTagihan

TglTagihan

<pi> A9

D

<M>

Kota

KdKota

NamaKota

<pi> A9

VA20

<M>

Jenis

KdJenis

NamaJenis

<pi> A9

VA20

<M>

Sifat

KdSifat

NamaSifat

BiayaSifat

<pi> A9

VA20

DC12,2

<M>

Penerima

KdPenerima

NamaPenerima

AlamatPenerima

KdPosPenerima

TlpPenerima

FaksPenerima

KPPenerima

<pi> A9

VA30

VA100

VA9

VA9

VA9

VA20

<M>

Gambar 1. Conceptual data model (cdm)

2014 4



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

2014 5



25. Pengirim

26. Karyawan

27. Tagihan

28. Sifat

29. Jenis

30. Kota

3NF

Transaksi

2014 6



Tagihan

Diagram ER Physical Data Model (PDM)

FK_TRANSAKS_PENGIRIM__PENGIRIM

FK_TRANSAKS_KARYAWANC_KARYAWAN

FK_TRANSAKS_TAGIHANTR_TAGIHAN

FK_TRANSAKS_PENERIMAT_PENERIMA

FK_TRANSAKS_JENISTRAN_JENIS

FK_TRANSAKS_SIFATTRAN_SIFAT

FK_TRANSAKS_KOTATRANS_KOTA

FK_PENERIMA_KOTAPENER_KOTA

FK_KARYAWAN_KOTAKARYA_KOTA

FK_PENGIRIM_KOTAPENGI_KOTA

FK_TAGIHAN_TAGIHANPE_PENGIRIM

Transaksi

NoTransaksi

KdJenis

KdPenerima

Kdkaryawan

KdSifat

KdKota

NoTagihan

KdPengirim

TglTransaksi

BeratTransaksi

CHAR(9)

CHAR(9)

CHAR(9)

CHAR(9)

CHAR(9)

CHAR(9)

CHAR(9)

CHAR(9)

DATE

VARCHAR(20)

<pk>

<fk5>

<fk4>

<fk2>

<fk6>

<fk7>

<fk3>

<fk1>

Pengirim

KdPengirim

KdKota

NamaPengirim

AlamatPengirim

KdPosPengirim

TlpPengirim

FaksPengirim

KPPengirim

CHAR(9)

CHAR(9)

VARCHAR(30)

VARCHAR(100)

VARCHAR(9)

VARCHAR(20)

VARCHAR(20)

VARCHAR(20)

<pk>

<fk>

Karyawan

Kdkaryawan

KdKota

NamaKaryawan

TglLahirKaryawan

Sex

Status

Alamat

KPKaryawan

CHAR(9)

CHAR(9)

VARCHAR(20)

DATE

VARCHAR(9)

VARCHAR(20)

VARCHAR(50)

VARCHAR(20)

<pk>

<fk>

Tagihan

NoTagihan

KdPengirim

TglTagihan

CHAR(9)

CHAR(9)

DATE

<pk>

<fk>

Kota

KdKota

NamaKota

CHAR(9)

VARCHAR(20)

<pk>

Jenis

KdJenis

NamaJenis

CHAR(9)

VARCHAR(20)

<pk>

Sifat

KdSifat

NamaSifat

BiayaSifat

CHAR(9)

VARCHAR(20)

NUMBER(12,2)

<pk>

Penerima

KdPenerima

KdKota

NamaPenerima

AlamatPenerima

KdPosPenerima

TlpPenerima

FaksPenerima

KPPenerima

CHAR(9)

CHAR(9)

VARCHAR(30)

VARCHAR(100)

VARCHAR(9)

VARCHAR(9)

VARCHAR(9)

VARCHAR(20)

<pk>

<fk>

Gambar 2. Model er physical data model (pdm)

Perancangan Struktur Menu Tampilan

Struktur Menu Program Keseluruhan

2014 7



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

2014 8



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

2014 9



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,

2014 10



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.

2014 11



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

2014 12



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.




2014 13



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.

2014 14



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


2014 15



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

2014 16



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.

2014 17



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

2014 18



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



2014 19



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.

2014 20



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.

2014 21



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.

2014 22



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

2014 23



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

2014 24



Gambar 37. Rancangan output data karyawan

Per kode karyawan

Laporan Data Penerima


Laporan Data Pengirim

2014 25




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

2014 26



kedalam sintak beberapa bahasa pemrograman.

2014 27



Daftar Pustaka



Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,

McGraw Hill, 1992






MODUL PERKULIAHAN PROYEK PENGEMBANGAN SISTEM …fasilkom.mercubuana.ac.id/wp-content/...Pengembangan-Sistem-Infor… · 2014 3 Proyek Pengembangan Sistem Informasi Modul 01 Pusat

Documents