DATA FLOW DIAGRAM (DFD)

Tentang DFD

• DFD bukan flowchart
• Proses dalam DFD bisa berjalan secara paralel
• DFD menggambarkan aliran data dalam sebuah
sistem
• DFD adalahData yang tersimpan dan proses
dengan proses yang terhubung dengan data
tersebut
• Tidak ada loop ataupun cabang dalam DFD
• DFD menggambarkan semua proses, meskipun
proses tersebut terjadi dalam waktu yang berbeda.

Simbol DFD



Entity

• Digambarkan dengan simbol bujur sangkar
• Merupakan sumber atau tujuan dari dari
aliran data.
• Merupakan lingkungan luar dari sistem.
• Bisa menggambarkan secara phisik,
seseorang atau seelompok orang atau
system lain.
• Kadang-kadang perlu untuk
menduplikasinya untuk menghindari
anak panah yang simpang siur.
• Ditandai dengan garis diagonal disudut
kanan bawah yang menyatakan kalau
entitti tersebut lebih dari satu.

Aliran Data
• Menggambarkan aliran data dari suatu
proses ke proses lainnya.
• Merepresentasikan dengan menggunakan
anak panah.
• Nama proses ditulis untuk menjelaskan arti
dalam aliran tersebut dan ditulis untuk
mengidentifikasi aliran tersebut.
• Aliran data dapat menyebar atau menyatu

Proses
• Adalah fungsi yang
mentransformasikan data secara
umum.
• Karena proses adalah suatu pekerjaan,
maka untuk menamai sebuah proses
mulailah dengan kata kerja dan diikuti
objek.

Storage/ Penyimpan
• Komponen yang berfungsi untuk
menyimpan data/ file adalah fungsi yang
mentransformasikan data secara umum.

Peraturan penting dalam DFD

Pemodelan Dalam Rekayasa Perangkat Lunak

Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang dilakukan di tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih memungkinkan tanpa melakukan suatu pemodelan. Hal itu tidak dapat lagi dilakukan dalam suatu industri perangkat lunak. Pemodelan delam perangkat lunak merupakan suatu yang harus dikerjakan di bagian awal dari rekayasa, dan pemodelan ini akan mempengaruhi perkerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut.

Proses
Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang berbeda untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan.
Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas ini.
Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak. Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara. Pembuatan perangkat lunak untuk suata perubahan adalah penting. Proses perangkat lunak komplek dan melibatkan banyak aktivitas.
Seperti produk, proses juga memiliki atribut dan karakteristik seperti :
• Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti.
• Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas
• Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE
• Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak
• Reliability, apakah proses didesain sedikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk.
• Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga
• Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan
• Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi.

Model

Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Contohnya, jika pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. Ini akan memperlambat proses.
Model proses perangkat lunak masih menjadi object penelitian, tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain:
• Pendekatan Waterfall
Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam proses yang terpisah, seperti spesifikasi kebutuhan, implementasi desain perangkat lunak, uji coba dst. Setelah setiap langkah didefinisikan, langkah tersebut di sign off dan pengembangan dilanjutkan pada langkah berikutnya.
• Pengembangan secara evolusioner
Pendekatan ini interleaves aktivitas spesifikasi, pengembangan dan validasi. Sistem awal dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang memenuhi kebutuhan kastamer. Kemudian sistem disampaikan. Sistem itu mungkin diimplementasikan kembali dengan pendekatan yang lebih terstruktur untuk menghasilkan sistem yang kuat dan maintable.
• Transformasi formal
Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu program. Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat yakin program yang dikembangkan sesuai dengan spesifikasi.
• Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan kembali.
Teknik ini menganggap bagian-bagian dari sistem sudah ada. Proses pengembangan sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap bagian.
Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner, saat ini banyak digunakan dalam pengembangan sistem. Beberapa sistem sudah dibuat dengan menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian.
Metode penggunaan kembali (reuse) umum di jepang. Metode ini sekiranya akan diakui oleh Eropa dan Amerika Utara. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars. Bagaimanapun juga reuse masih suatu penelitian, terlalu cepat untuk berkomentar tentang keefektifannya.

Waterfall

Model ini telah diperoleh dari proses engineering lainnya. Model ini menawarkan cara pembuatan perangkat lunak secara lebih nyata.
Langkah-langkah yang penting dalam model ini adalah
• Penentuan dan analisis spesifikasi
Jasa, kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Kemudian semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.
• Desain sistem dan perangkat lunak
Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat dijalankan.
• Implementasi dan ujicoba unit
Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi.
• Integrasi dan ujicoba sistem
Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah ujicoba, sistem disampaikan ke kastamer
• Operasi dan pemeliharaan
Normalnya, ini adalah phase yang terpanjang. Sistem dipasang dan digunakan.
Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan.


Gambar 1. Pemodelan Waterfall

Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari aktivitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.
Sayangnya, model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan atau diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.
Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang nyata/jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan kastamer. Namun demikian model waterfall mencerminkan kepraktisan engineering. Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.

Pengembangan Evolusioner

Model ini berdasarkan pada ide pengembangan pada implementasi awal yang akan menghasilkan komentar pemakai sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang mencukupi dapat dikembangan. Selain memiliki aktivitas-aktivitas yang terpisah model ini memberikan feedback dengan cepat dan serentak
Terdapat 2 tipe pada model ini
1. Pemprograman evolusioner
Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer. Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer.
2. Pemodelan
Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhan-kebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk sistem. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang kurang dimengerti.
Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun, pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial intelligence) yang berusaha untuk menyamai kemampuan manusia.
Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka.
Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer. Namun, dari segi teknik dan manajemen, model ini memiliki masalah mendasar yaitu:
• Proses tidak visibel.
Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan. Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem.
• Sistem-sistem biasanya kurang terstruktur
Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat lunak. Evolusi perangkat lunak terlihat sulit dan mahal.
• Ketrampilan khusus jarang dimiliki
Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang mungkin dapat digunakan secara efektif dalam model pengembangan ini. Kebanyakan sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil yang memiliki ketrampilan yang tinggi dan motivasi yang kuat.
Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem. Contoh ini digunakan untuk mengerti dan mevalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas. ( seperti model waterfall ).
Karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. Pengembangan evolusioner lebih tepat untuk
Pengembangan sistem yang relatif kecil.
Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika pemodelan digunakan, tidak terlalu mahal.
Pengembangan sistem yang memiliki masa hidup yang relatif singkat.
Disini, sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu. Contohnya, sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk baru.
Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan untuk menyatakan spesifikasi secara rinci. Contohnya, sistem AI dan interfaces pemakai.

Spiral Boehm

Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi, tidak mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua model umum seperti yang telah kita bicarakan sebelumnya. Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Pendekatan alternatif diusulkan oleh Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum.
Model Boehm bebrbentuk spiral. Setiap loop mewakili sebuah tahap dari proses perangkat lunak.
Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan bagaimana membentuk proyek kedalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan selama pembuatan proyek.
Setiap loop dibagi dalam 4 sektor
1. Pembuatan tujuan
Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan. Rencan rinci manajemen juga ditulis lengkap. Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada.
2. Perkiraan dan pengurangan resiko
Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian diambil langkah-langkah untuk mengurangi resiko. contohnya, jika ada resiko bahwa persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat dikembangkan.
3. Pengembangan dan validasi
Setelah evaluasi resiko, sebuah model pengembangan untuk sistem dipilih. Misalnya, jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan model contoh (prototipe)
Jika resiko keselamatan yang diutamakan, model pengembangan yang sesuai adalah transformasi formal dan seterusnya. Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem.
4. Perencanaan
Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya.
Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sisten perangkat lunak. Model spiral encompasses model lainnya. Pemodelan digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Kemudian dapat diikuti oleh model konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan bagian-bagian sistem yang memiliki persyaratan keselamatan yang tinggi dan pendekatan reuse digunakan untuk pengimplementasian bagian-bagian lain dari sistem data manajemen.
Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.

Manajemen Resiko

Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada. Resiko adalah konsep yang sulit didefinisikan secara tepat. Secara informal resiko adalah sesuatu yang sederhana yang dapat menyebabkan kesalahan. Contohnya, jika bertujuan menggunakan pemprograman bahasa baru (new programming language), resiko yang mungkin adalah alat pengumpul yang digunakan tidak reliabel dan tidak menghasilkan code objek yang efesien.
Resiko adalah sebagai hasil ketidakcukupan informasi. Resiko tersebut dapat dipecahkan dengan pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Dalam contoh diatas, resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Jika sistem ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah.
Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance, kegunaan, dan seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaik-baiknya kemudian diperhitungkan. Setiap alternatif diperhitungan bertentangan dengan tujuan. Ini biasanya menghasilkan identifikasi sumber resiko proyek. Langkah selanjutnya adalah mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail, pembuatan model/contoh, simulasi dan seterusnya. Untuk menggunakan model spiral, Boehm menyarankan sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Bentuk ini mungkin dilengkapi pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk.

Use Case Diagram

a. Use Case Model
- Teknik pemodelan untuk mendapatkan functional requirement dari sebuah sistem
- Menggambarkan interaksi antara pengguna dan sistem
- Menjelaskan secara naratif bagaimana sistem akan digunakan
- Menggunakan skenario untuk menjelaskan setiap aktivitas yang mungkin terjadi
- Kadangkala notasi kurang detail, terutama untuk beberapa aktivitas tertentu


b. Kapan Menggunakan Use Case?
- Use case sederhana digunakan pada saat proses requirement analysis,Tidak semua pengguna paham bahasa teknis
- Versi yang lebih detail dibuat sebelum implementasi rancangan. Dibuat khusus untuk mempermudah desain sistem oleh para developer
c. Level Use Case Model
- Use Case memiliki dua istilah :
• System use case : interaksi dengan sistem
• Business use case : interaksi bisnis dengan konsumen atau kejadian nyata
- Cookburn menyarankan adanya pembedaan level
• Sea level : interaksi sistem dengan aktor utama
• Fish level : use case yang ada karena include dari use case sea-level
• Kite level : menggambarkan sea-level use case untuk interaksi bisnis yang lebih luas
d. Use Case Diagram
- Nama use case
• Simple name
− Biasanya berupa kata kerja
• Path name
− nama di bagian depan menyatakan paket (package) dimana use case tersebut berada.

Use Case

1. Pendekatan Rational View
● Ada empat view yang masing-masing ditujukan
untuk tujuan dan pemakai yang berbeda
– Use Case view
– Logical View
– Component View
– Deployment View



a. Use Case View
● Use Case view : fokus pada gambaran level tinggi dari apa yang akan sistem kerjakan, tanpa peduli tentang bagaimana sistem akan melakukannya secara detil.
● Ketika proyek dimulai, tim menghasilkan model bisnis dalam Use Case view (optional).
● Jika dikerjakan, anggota tim yang dibutuhkan: pelanggan, manajer proyek, dan analis yang berpusatpada proses bisnis
● Sekali model bisnis diselesaikan, tim pindah ke model use case. Pelanggan, analis, dan manager proyek akan bekerja dengan Use Case Diagram, dan menggunakan dokumentasi use case untuk menyetujui definisi level tinggi dari sistem.

b. Logical View
● Fokus pada bagaimana sistem akan menerapkan perilaku dalam use cases.
● Menyediakan gambaran detil dari sebagian sistem, dan menjelaskan bagaimana antar bagian sistem tersebut berhubungan.
● Logical view berisi penentuan class yang akan digunakan, Class diagram, dan Statechart diagram.

Logical View
● Tim menempuh pendekatan dua langkah ke Logical View.
– Pertama, menganalisa class-class. Analisa class tidak tergantung pada bahasa yang digunakan. Analisa class mungkin juga muncul pada Interaction diagram dalam Use Case view.


– Kedua, merancang class-class. Perancangan classsudah merupakan detil yang tergantung pada bahasa yang akan digunakan

● Entity Class
– Suatu class yang diperlukan ole sistem untuk memenuhi beberapa tanggung jawab
– Kata benda yang digunakan untuk menjelaskan tanggungjawab, mungkin sebagai awal yang baik
● Boundary Class
– Class yang menangani komunikasi antara lingkungan diluar sistem dan di dalam sistem
● Control Class
– Mempresentasikan use case secara dinamis (menjalankan use case)
– Pada fase awal, control class bertanggung jawab untuk aliran kejadian dalam use case

● Pemakai utama dari Logical view adalah pengembang dan arsitek sistem.
– Pengembang berkepentingan terhadap class apa saja yang akan dibuat, atribut dan perilaku setiap class, dan hubungan antar class
– Arsitek sistem, yang memperhatikan struktur system keseluruhan, bertanggung jawab untuk memastikan bahwa sistem memiliki arsitektur yang stabil
● Analis mengamai Class diagram untuk memastikan bahwa kebutuhan bisnis akan diterapkan dalam program.
● Staf penjamin kualitas (QA) akan melihat class, package dan Class diagram untuk mengetahui bagian sistem yang ada dan perlu diuji.
– Diagram Statechart juga dilihat untuk mengetahui bagaimana seharusnya suatu class.
● Manajer proyek akan melihat Class diagram untuk memperkirakan seberapa komplek sistem.
c. Component View
● Sebuah komponen adalah modul fisik dari kode
● Component view berisi informasi tentang pustaka kode program, pustaka run-time, executable file, dan komponen lain dalam model.
● Component view memperlihatkan hubungan antar modul program
d. Deployment View
● Fokus dengan sistem deployment, yang mungkin berbeda dari arsitektur logika sistem.
– Contoh: sistem secara logika memiliki arsitektur three-tier. Sisi antarmuka ditempatkan pada satu mesin, sedangkan lapisan logika bisnis dan database ditempatkan di mesin lain.

Langkah-Langkah Penggunaan UML

Berikut ini adalah tips pengembangan piranti lunak dengan menggunakan UML:

1. Buatlah daftar business process dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul.

2. Petakan use case untuk tiap business process untuk mendefinisikan dengan tepat fungsionalitas yang harus disediakan oleh sistem. Kemudian perhalus use case diagram dan lengkapi dengan requirement, constraints dan catatan-catatan lain.

3. Buatlah deployment diagram secara kasar untuk mendefinisikan arsitektur fisik sistem.

4. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem.

5. Berdasarkan use case diagram, mulailah membuat activity diagram.

6. Definisikan objek-objek level atas (package atau domain) dan buatlah sequence dan/atau collaboration diagram untuk tiap alir pekerjaan. Jika sebuah use case memiliki kemungkinan alir normal dan error, buatlah satu diagram untuk masing-masing alir.

7. Buarlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.

8. Berdasarkan model-model yang sudah ada, buatlah class diagram. Setiap package atau domain dipecah menjadi hirarki class lengkap dengan atribut dan metodanya. Akan lebih baik jika untuk setiap class dibuat unit test untuk menguji fungsionalitas class dan interaksi dengan class lain.

9. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class menjadi komponen-komponen. Karena itu buatlah component diagram pada tahap ini. Juga, definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.

10. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.

11. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan :
• Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.
• Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim pengembang tertentu.

12. Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus selalu sesuai dengan code yang aktual.

13. Piranti lunak siap dirilis.

Deployment Diagram

Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal

Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini

Contoh deployment diagram :

Component Diagram

Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya.

Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time. Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil.
Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.

Contoh component diagram:

Collaboration Diagram

Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message.
Setiap message memiliki sequence number, di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.

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 atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait).

Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.

Masing-masing objek, termasuk aktor, memiliki lifeline vertikal.
Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metoda dari class.
Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya sebuah message.
Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk objek boundary, controller dan persistent entity.

Contoh sequence diagram :

Statechart Diagram

Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram).

Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan diawali garis miring.

Titik awal dan akhir digambarkan berbentuk lingkaran berwarna penuh dan berwarna setengah.

Contoh statechart diagram :


Activity Diagram

Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi.

Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum.

Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas.
Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.
Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

Contoh activity diagram tanpa swimlane:

Class Diagram

Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi).

Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.

Class memiliki tiga area pokok :
1. Nama (dan stereotype)
2. Atribut
3. Metoda

Atribut dan metoda dapat memiliki salah satu sifat berikut :
• Private, tidak dapat dipanggil dari luar class yang bersangkutan
• Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya
• Public, dapat dipanggil oleh siapa saja

Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki metoda. Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time.

Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi package. Kita juga dapat membuat diagram yang terdiri atas package.

Hubungan Antar Class

1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class.

2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).

3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.

4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di-passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.

Contoh class diagram :

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 merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya.
Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu.

Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem.

Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use case yang meng-include dieksekusi secara normal.
Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common.

Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri.
Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain.
Contoh use case diagram :

Pengenalan "Unified Modeling Language/UML"

Dalam suatu proses pengembangan software, analisa dan rancangan telah merupakan terminologi yang sangat tua. Pada saat masalah ditelusuri dan spesifikasi dinegoisasikan, dapat dikatakan kita berada pada tahap rancangan. Merancang adalah menemukan suatu cara untuk menyelesaikan masalah, salah satu tool / model untuk merancang pengembangan software yang berbasis object oriented adalah UML.
Konsep Objek
Obyek dalam ‘software analysis & design’ adalah sesuatu berupa konsep (concept), benda (thing), dan sesuatu yang membedakannya dengan lingkungannya. Secara sederhana obyek adalah mobil, manusia, alarm dan lain- lainnya. Tapi obyek dapat pula merupakan sesuatu yang abstrak yang hidup didalam sistem seperti tabel, database, event, system messages.

Obyek dikenali dari keadaannya dan juga operasinya. Sebagai contoh sebuah mobil dikenali dari warnanya, bentuknya, sedangkan manusia dari suaranya. Ciri- ciri ini yang akan membedakan obyek tersebut dari obyek lainnya.
Alasan mengapa saat ini pendekatan dalam pengembangan software dengan object-oriented, pertama adalah scalability dimana obyek lebih mudah dipakai untuk menggambarkan sistem yang besar dan komplek. Kedua dynamic modeling, adalah dapat dipakai untuk permodelan sistem dinamis dan real time.
Teknik Dasar OOA/D (Object-Oriented Analysis/Design)
Dalam dunia pemodelan, metodologi implementasi obyek walaupun terikat kaidah-kaidah standar, namun teknik pemilihan obyek tidak terlepas pada subyektifitas software analyst & designer. Beberapa obyek akan diabaikan dan beberapa obyek menjadi perhatian untuk diimplementasikan di dalam sistem. Hal ini sah-sah saja karena kenyataan bahwa suatu permasalahan sudah tentu memiliki lebih dari satu solusi. Ada 3 (tiga) teknik/konsep dasar dalam OOA/D, yaitu pemodulan (encapsulation), penurunan (inheritance) dan polymorphism.
a. Pemodulan (Encapsulation)
Pada dunia nyata, seorang ibu rumah tangga menanak nasi dengan menggunakan rice cooker, ibu tersebut menggunakannya hanya dengan menekan tombol. Tanpa harus tahu bagaimana proses itu sebenarnya terjadi. Disini terdapat penyembunyian informasi milik rice cooker, sehingga tidak perlu diketahui seorang ibu. Dengan demikian menanak nasi oleh si ibu menjadi sesuatu yang menjadi dasar bagi konsep information hiding.
b. Penurunan (Inheritance)
Obyek-obyek memiliki banyak persamaan, namun ada sedikit perbedan. Contoh dengan beberapa buah mobil yang mempunyai kegunaan yang berbeda-beda. Ada mobil bak terbuka seperti truk, bak tertutup seperti sedan dan minibus. Walaupun demikian obyek-obyek ini memiliki kesamaan yaitu teridentifikasi sebagai obyek mobil, obyek ini dapat dikatakan sebagai obyek induk (parent). Sedangkan minibus dikatakan sebagai obyek anak (child), hal ini juga berarti semua operasi yang berlaku pada mobil berlaku juga pada minibus. 2/10
c. Polymorphism
Pada obyek mobil, walaupun minibus dan truk merupakan jenis obyek mobil yang sama, namun memiliki juga perbedaan. Misalnya suara truk lebih keras dari pada minibus, hal ini juga berlaku pada obyek anak (child) melakukan metoda yang sama dengan algoritma berbeda dari obyek induknya. Hal ini yang disebut polymorphism, teknik atau konsep dasar lainnya adalah ruang lingkup / pembatasan. Artinya setiap obyek mempunyai ruang lingkup kelas, atribut, dan metoda yang dibatasi.
Sejarah Singkat UML
UML (Unified Modeling Language) adalah sebuah bahasa yang berdasarkan grafik/gambar untuk memvisualisasi, menspesifikasikan, membangun, dan pendokumentasian dari sebuah sistem pengembangan software berbasis OO (Object-Oriented). UML sendiri juga memberikan standar penulisan sebuah sistem blue print, yang meliputi konsep bisnis proses, penulisan kelas-kelas dalam bahasa program yang spesifik, skema database, dan komponen-komponen yang diperlukan dalam sistem software (http://www.omg.org). Pendekatan analisa & rancangan dengan menggunakan model OO mulai diperkenalkan sekitar pertengahan 1970 hingga akhir 1980 dikarenakan pada saat itu aplikasi software sudah meningkat dan mulai komplek. Jumlah yang menggunakaan metoda OO mulai diuji cobakandan diaplikasikan antara 1989 hingga 1994, seperti halnya oleh Grady Booch dari Rational Software Co., dikenal dengan OOSE (Object-Oriented Software Engineering), serta James Rumbaugh dari General Electric, dikenal dengan OMT (Object Modelling Technique). Kelemahan saat itu disadari oleh Booch maupun Rumbaugh adalah tidak adanya standar penggunaan model yang berbasis OO, ketika mereka bertemu ditemani rekan lainnya Ivar Jacobson dari Objectory mulai mendiskusikan untuk mengadopsi masing-masing pendekatan metoda OO untuk membuat suatu model bahasa yang uniform / seragam yang disebut UML (Unified Modeling Language) dan dapat digunakan oleh seluruh dunia. Secara resmi bahasa UML dimulai pada bulan oktober 1994, ketika Rumbaugh bergabung Booch untuk membuat sebuah project pendekatan metoda yang uniform/seragam dari masing-masing metoda mereka. Saat itu baru dikembangkan draft metoda UML version 0.8 dan diselesaikan serta di release pada bulan oktober 1995. Bersamaan dengan saat itu, Jacobson bergabung dan UML tersebut diperkaya ruang lingkupnya dengan metoda OOSE sehingga muncul release version 0.9 pada bulan Juni 1996. Hingga saat ini sejak Juni 1998 UML version 1.3 telah diperkaya dan direspons oleh OMG (Object Management Group), Anderson Consulting, Ericsson, Platinum Technology, ObjectTime Limited, dll serta di pelihara oleh OMG yang dipimpin oleh Cris Kobryn. UML adalah standar dunia yang dibuat oleh Object Management Group (OMG), sebuah badan yang bertugas mengeluarkan standar-standar teknologi object- oriented dan software component.
3. Pengenalan UML
UML sebagai sebuah bahasa yang memberikan vocabulary dan tatanan penulisan kata-kata dalam ‘MS Word’ untuk kegunaan komunikasi. Sebuah bahasa model adalah sebuah bahasa yang mempunyai vocabulary dan konsep tatanan / aturan penulisan serta secara fisik mempresentasikan dari sebuah sistem. Seperti halnya UML adalah sebuah bahasa standard untuk pengembangan sebuah software yang dapat menyampaikan bagaimana membuat dan membentuk model-model, tetapi tidak menyampaikan apa dan kapan model yang seharusnya dibuat yang merupakan salah satu proses implementasi pengembangan software. UML tidak hanya merupakan sebuah bahasa pemograman visual saja, namun juga dapat secara langsung dihubungkan ke berbagai bahasa pemograman, seperti JAVA, C++, Visual Basic, atau bahkan dihubungkan secara langsung ke dalam sebuah object-oriented database. Begitu juga mengenai pendokumentasian dapat dilakukan seperti; requirements, arsitektur, design, source code, project plan, tests, dan prototypes. Untuk dapat memahami UML membutuhkan bentuk konsep dari sebuah bahasa model, dan mempelajari 3 (tiga) elemen utama dari UML seperti building block, aturan-aturan yang menyatakan bagaimana building block diletakkan secara bersamaan, dan beberapa mekanisme umum (common).

Use Case Diagram VCD

BAB I
DESKRIPSI DAN PERSYARATAN SISTEM

Salah satu kunci pengembangan sistem komputer yang baik adalah memahami sistem yang ada / sudah berjalan serta memahami bagaimana keterkaitan antar komponen serta fungsi yang ada. Sehingga dalam pengembangan sistem komputer dapat terarah tujuannya serta terukur hasilnya dengan cara membandingkan sistem sebelumnya dengan sistem setelah ada komputerisasi.
Komponen sistem informasi adalah sumber daya yang meliputi suatu sistem informasi, antara lain :
1. manusia,
2. data,
3. informasi,
4. software,
5. hardware.

Suatu informasi sistem memiliki fungsi-fungsi mendasar, baik itu sistem informasi yang sederhana sampai sistem yang kompleks, yaitu :
 input,
 proses,
 output,
 storage (media penyimpanan),
 kontrol.
Data dimasukkan dalam sistem, diproses. Sistem mengeluarkan hasil proses berupa data baru atau informasi. Sistem juga dapat menyimpan data dan informasi untuk penggunaan berikutnya dimana semua operasi tersebut dapat dikontrol.


1.1 Deskripsi Sistem Yang Ada

Rental film merupakan suatu usaha jasa, berupa kegiatan peminjaman film. Adapun fungsi / komponen sistem yang ada saat ini dapat diuraikan dalam matriks berikut ini :
Input Proses Output Storage Kontrol
Manusia data entry
operator Operator menghitung total transaksi
Data Pelanggan
Film Transaksi pinjam / kembali Buku besar
Buku transaksi
Informasi Pelanggan
Film
Transaksi
Keuangan
Software - - - - -
Hardware - - - - -

Sistem yang ada masih bersifat manual dimana pelanggan datang ke rental dengan pelayanan yang diberikan oleh pihak rental masih dilakukan secara manual. Secara blok diagram dapat digambarkan sebagai berikut :
















Gambar 1.1 Diagram Sistem Manual



Gambar 1.2 Use Case Diagram Sistem Manual

Dari Gambar 1.2 terlihat bahwa terdapat proses pencarian film, kalau film ditemukan maka dilakukan transaksi sewa film. Dalam hal ini transaksi sewa film dilakukan secara manual, dimana ada beberapa kelemahan yang teridentifikasi meliputi :
 tidak adanya kontrol terhadap jumlah film yang keluar,
 tidak adanya kontrol terhadap transaksi yang berlangsung,
 proses pelayanan terhadap peminjam / pelanggan lambat karena harus mencari secara fisik film yang dimaksud ada atau tidak.
Demikian pula untuk transaksi pengembalian film akan menghadapi kendala yang kurang lebih sama. Adapun gambaran activity diagram dari sistem konvensional dapat dilihat sebagai berikut ini.

Gambar 1.3 Activity Diagram Sistem Manual Sewa Film




Gambar 1.4 Activity Diagram Sistem Manual Pengembalian Film


1.2 Deskripsi Umum Sistem Yang Akan Dibangun
Sistem yang akan dibangun disini adalah sebuah rental film yang modern, artinya dalam hal transaksi dan penyimpanan datanya dilakukan menggunakan bantuan software komputer. Perbedaan sistem ini dengan yang sebelumnya adalah adanya penambahan seperangkat komputer sekaligus softwarenya yang nantinya diharapkan dapat membantu peminjam dalam hal mencari film, pembagian petugas berdasarkan fungsinya : peminjaman dan pengembalian, administrator serta pemeliharaan; Sistem rental film yang akan dibangun ini secara blok diagram dapat digambarkan berikut ini.










Gambar 1.5 Activity Diagram Sistem Manual Pengembalian Film

Berdasarkan gambar 1.5 terlihat adanya penambahan database dimana semua proses transaksi datanya tersimpan dalam database. Untuk itu maka sistem dilengkapi dengan (minimal) satu unit komputer yang mendukung operasional sistem rental film. Masing-masing entitas diatas mempunyai class tersendiri. Dengan demikian minimal terdapat empat class yaitu : peminjam, petugas, film, database dan adanya fungsi transaksi yang menunjang empat class tersebut.
Adapun penambahan fungsi / komponen sistem digunakan dapat diuraikan dalam matriks berikut ini :


Input Proses Output Storage Kontrol
Manusia data entry
operator Operator menghitung total transaksi
Data Pelanggan
Film Transaksi pinjam / kembali Buku besar
Buku transaksi
Informasi Pelanggan
Film
Transaksi
Keuangan
Software Inventaris film
Transaksi sewa
Transaksi kembali
Nota transaksi
keuangan - MySQL database Inventaris film
Keuangan
Hardware workstation server Printer Magnetic disk -

Dari tabel diatas terlihat penambahan class database akan berakibat bertambahnya komponen software dan hardware. Hal ini merupakan konsekuensi logis atas digunakannya sistem komputerisasi.


Gambar 1.6 Use Case Diagram Sistem Baru

Pada Gambar 1.6 diatas dijelaskan use case diagram secara global untuk pencarian film, peminjaman film dan pengembalian film.
Pada gambar yang paling atas ditunjukkan hubungan antar actor peminjam, petugas peminjaman, use case cari film, use case transaksi peminjaman dan pengembalian film, use case Login dan use case Logout.
Pada gambar tengah ditunjukkan actor petugas pemeliharaan, use case manajemen petugas, use case Login dan use case Logout.
Pada gambar paling bawah ditunjukkan sebuah actor administrator, use case manajemen sistem, use case Login dan use case Logout. Masing-masing use case pada setiap blok diatas akan saling berinteraksi dengan dunia luar dan menunjukkan fungsionalitas suatu sistem atau kelas.


1.3 Persyaratan Sistem

Ruang lingkup pengerjaan program meliputi proses sewa film dan inventarisasinya, rekaman transaksi, dengan melibatkan komponen berupa pelanggan (peminjam), petugas, dan database film itu sendiri.

1.3.1 INPUT
Perintah :
1) lihat daftar film, dapat dilakukan dalam berbagai kategori,
2) lihat daftar anggota / peminjam dalam kategori utama sbb : usia, alamat / wilayah pemukiman, status (kuliah, pekerja, anak-anak, ibu rumah tangga, lain-lain),
3) lihat daftar anggota beserta daftar film yang :
 saat ini dipinjam
 pernah dipinjam
 akan dipinjam (waiting list pemesan film tertentu yg sedang keluar)
semuanya meliputi : jumlah, tgl pinjam, tgl harus kembali, denda jika ada,
4) lihat daftar jenis film yang banyak diminati anggota + grafiknya
5) pencatatan transaksi sewa film beserta operator yang menanganinya

1.3.2 OUTPUT
Daftar film berdasar :
6) Jenis (drama, komedi, kartun, horor, silat, dll),
7) pemeran utama,
8) sutradara,
9) kategori (film dewasa, anak-anak, segala usia),
10) daerah asal film (Barat, India, Indonesia, Mandarin, dll)
11) banyaknya film : dgn asumsi 1 judul film dapat terdiri lebih dari 1 keping VCD
12) status (dipinjam + kapan kembalinya, ada / rusak )

Daftar anggota berdasar :
1) no anggota
2) nama
3) Alamat
4) bukti identitas diri
5) siapa yang pinjam film tertentu ?
6) status (mahasiswa, anak-anak, pekerja, ibu rumah tangga, lain-lain)
7) usia

1.3.3 Proses
Proses merupakan cara pengolahan data dari input menjadi output yang diinginkan. Pada kasus rental film ini, proses yang dilakukan antara lain :
 Proses pendaftaran menjadi anggota peminjaman.
 Proses pencarian film oleh sistem.
 Proses peminjaman film ( simpan data peminjaman dalam database ).
 Proses pengembalian film ( simpan data pengembalian dalam database ).
 Proses penambahan data film oleh sistem.
 Proses edit data film oleh sistem.
 Proses hapus data film oleh sistem.
 Proses penambahan data anggota oleh sistem.
 Proses edit data anggota oleh sistem.
 Proses hapus data anggota oleh sistem.
 Proses penambahan data petugas oleh sistem.
 Proses edit data petugas oleh sistem.
 Proses hapus data petugas oleh sistem.
 Proses transaksi pembayaran / keuangan


1.3.4. Kinerja Sistem

1) Multi user, dimana terdiri atas 3 kategori:
 Administrator (read, write, user management)
 Petugas (read, write)
 Peminjam (read only)
Catatan : administrator dan petugas memiliki fasilitas authentifikasi.
2) Fasilitas search engine dalam beberapa kategori yang mendukung SQL command (artinya : memiliki opsi perintah SQL yang dapat ketikkan sendiri secara manual selain yang sudah disediakan oleh sistem) sehingga dapat digunakan untuk melakukan “WHAT IF ANALYSIS”
3) Semua fungsi dalam sistem secara standar memiliki fasilitas cetak data / transaksi,
4) Memiliki fasilitas konfigurasi / seting program yang meliputi :
 Mengatur harga sewa film per judul / keping
 Batas lama pinjam film perjudul (dalam hari)
 Tata cara penomoran film dan anggota
 Mengatur operator yang sedang aktif
 Batas maksimum jumlah film yang dapat dipinjam
catatan : semuanya dapat diatur dalam periode waktu tertentu sesusai kebutuhan.
5) Program harus didesain untuk mengantisipasi perkembangan struktur organisasi rental / persewaan. Artinya masih dapat digunakan dalam minimal 5 tahun kedepan, serta struktur program dan database dapat dikembangkan tanpa harus membuat dari awal lagi.
6) Yang lebih penting program dapat digabungkan dengan modul-modul lain yang dibangun secara terpisah / dalam waktu mendatang, misal : modul keuangan, modul inventaris gudang, modul sistem informasi manajemen, dll.



1.3.5. Kendala Yang Dihadapi

Dengan adanya sistem rental film yang baru ini maka diperlukan adanya infrastruktur dan sumber daya manusia yang memadai. Minimal diperlukan seperangkat komputer, software aplikasi rental film, serta SDM yang dapat mengoperasikan software film tersebut.

Analisa berikut ini, berupa matriks yang menggambarkan hubungan antara tujuan, kendala dan aksi yang harus dilakukan uttuk mengatasi kendala tersebut
Tujuan Kendala Aksi
Fungsionalitas
Meliputi : keandalan, kejelasan, efisiensi, dan fleksibelitas  Sistem harus cepat dan mudah dioperasikan
 Sistem harus user friendly

 Sistem harus efisien sehingga semua kegiatan menjadi cepat dan akurat
 Sistem harus punya hak akses dan kemampuan mengambil dan mengupdate informasi sesuai haknya
 Buat aplikasi berbasis GUI
 Desain form yang sederhana dan minimal penggunaan mouse
 Desain input data berdasarkan kesesuaian data yang dibutuhkan
 Gunakan password untuk mengatur hak akses

Pemeliharaan Sistem  Belum ada SDM yang menguasai teknologi Informasi pada rental film  Buat program aplikasi dengan fasilitas help dan usahakan proses sederhana
 Buat dokumentasi dan buku manual
 Berikan pelatihan cara menjalankan program aplikasi yang dibuat
Komitmen  Perlunya komitmen dari pengguna dan user yang terlibat dalam operasional sistem untuk konsisten pada sistem yang dibuat.  Buat sesi orientasi sistem baru dan sesi umpan balik terhadap penerapan sistem yang baru

ANALISIS STP

Pemasaran Segmentasi
Pemasaran segmentasi dapat menciptakan penawaran atau layanan yang sesuai dengan kebutuhan atau keinginan konsumen dengan harga yang tepat bagi segmen sasaran, selain itu juga pemasaran segmen memiliki manfaat untuk pemilihan saluran distribusi (distribution channel) dan komunikasi yang lebih jelas serta mengerti lebih dalam tentang siapa saja pesaing yang juga bermain pada segmen yang sama. Terdapat dua segmen masyarakat di Taiwan yang menjadi tujuan pemasaran Carrefour, yaitu segmen masyarakat Taiwanese urban residence dan masyarakat rural residence. Dari kedua segmen masyarakat iitu, yang menjadi segmen utama dari Carrefour adalah masyarakat Taiwanese urban residence. Mengapa Taiwanese urban residence yang menjadi segmen utama? Hal ini disebabkan karena urban residence memiliki lokasi yang sangat strategis untuk usaha, dimana kepadatan penduduk di urban area menjadi salah satu pertimbangan utamanya, dimana di daerah yang padat penduduk, Carrefour mempertimbangkan kedekatan dengan konsumen, kemudahan jangkauan konsumen, jarak dengan pemasok yang dapat mempengaruhi kontinuitas pengiriman barang penjualan, serta lain sebagainya. Hal-hal tersebut merupakan faktor-faktor penting yang mendukung meningkatkan keberhasilan bisnis Carrefour di Taiwan.
Pemasaran Targeting
Setelah segmen pasar ditetapkan, maka perusahaan dapat memasuki fase penetapan pasar sasaran (targeting marketing) yang terdiri dari evaluasi setiap daya tarik segmen pasar dan melakukan pemilihan satu atau lebih segmen untuk dimasuki. Siapa yang menjadi target Carrefour pada kehadirannya di pasar Taiwan? karena Konsep awal pembangunan Carrefour adalah Konsep hypermarket yaitu sebuah supermarket besar yang mengombinasikan department store (toko serba ada), yang menjual segala jenis keperluan masyarakat. Ketika memasuki pasar Taiwan, target pasar Carrefour adalah penduduk Taiwan yang selama ini berbelanja di pasar-pasar tradisional, dimana tujuannya adalah untuk menciptakan suatu nuansa berbelanja yang lebih moderen serta suasana berbelanja yang lebih nyaman dan teratur.
Pemasaran Positioning
Positioning mengarahkan bagaimana customer’s berpikir tentang usulan dan atau merek-merek terbaru dalam suatu pasar. Seorang manajer pemasaran perlu realistis melihat bagaimana para pelanggan berpikir tentang penawaran yang ada di pasar, karena tanpa itu akan sulit bagi manajer pemasaran untuk membedakan. Persoalan positioning secara khusus penting ketika para pesaing dalam pasar muncul atau berkembang dengan cara yang sama. Pasar Carrefour memiliki beberapa pesaing di Taiwan seperti Makro’s hypermarket yang juga berkembang dengan cara yang sama dengan Carrefour. Namun demikian Carrefour memiliki beberapa keunggulan yang dapat menjadi positioning-nya sehingga kehadirannya dapat terus diterima dan terus berkembang. Carrefour menempatkan beberapa kunci suksesnya sebagai positioning dari perusahaan diantaranya adalah one-stop shopping, extremely low prices, full range of choice, self service and free parking. Dari beberapa positioning tersebut, yang menjadi positioning utama dari Carrefour adalah one-stop shopping dan extremely low prices. Bagi Carrefour, harga bukan berarti sama dengan competitive advantage namun lebih dimaksudkan agar Carrefour tetap survival.
ANALISIS SWOT
Strenghts
Kekuatan Carrefour berada pada positioning-nya harga murah dan barang lengkap, lalu Carrefour selalu berada di tempat yang strategis sehingga mudah dijangkau, tempatnya luas, nyaman dan free parking. Sehingga konsumen datang tanpa membeli pun jadi senang karena tidak perlu membayar parkir.
Weakness
Masalah komunikasi. Taiwan adalah satu-satunya negara di mana bahasa dalam bekerja dan bahasa lokal tidak sama dan semua dokumen harus ditulis dalam dua bahasa yaitu bahasa China dan Inggris; setiap menit dalam rapat, laporan performa, seluruh dokumen lainnya (termasuk kebijakan perusahaan) adalah bilingual. Manajer asing tidak dapat mempelajar bahasa China secepat bahasa Portugis, Spanyol ataupun Inggris. Masalah komunikasi antara manajer asing dan karyawan lokal memiliki konsekuensi yang penting, pimpinan departemen yang kompeten tidak berkomunikasi dalam Inggris dasar dengan manajer toko ekspatriat akan susah dipromosikan sebagai kepala seksi. Selain itu, susah juga untuk mengkomunikasikan kebijakan perusahaan dan kultur perusahaan. Mass retailing adalah konsep baru di Taiwan dan hambatan bahasa membuat susah untuk mengkomunikasikan tujuan, strategi, visi dan misi Carrefour. Masalah kedua adalah cultural gap. Prioritas orang China yang utama adalah emosi, yang kedua alasan dan yang terakhir adalah hukum. Sedangkan prioritas orang Perancis yang utama adalah hukum (mengimpikasikan bahwa kebijakan Carrefour adalah peraturan emas), kedua alasan dan yang terakhir adalah emosi. Benar-benar bertolak belakang. Masalah ketiga adalah hubungan dengan pemegang saham baru, lingkungan sekitar (sejak hampir seluruh toko Carrefour berada di urban area) dan mafia local. Proteksi harus dinegosiasikan dan sirkulasi klien ketat dan menjadwalkan pengiriman diorganisasikan untuk setiap toko dalam kooperasinya dengan suplier.
• Sumber daya manusia di Taiwan merupakan masalah besar. Tingkat pengangguran sangat rendah (1993: 1.15%) dan anak muda tanpa keahlian lebih tertarik bekerja di clean service seperti bar karaoke, kedai kopi dan restoran. Turnover rata-rata staf Carrefour adalah 65% per tahun, 40% staf berusia di bawah 18 tahun, kebanyakan bekerja paruh waktu. Sehingga rasa memiliki dalam organisasi sangat terbatas dan usaha training, teknikal dan pengembangan personal terpusat pada kebijakan manajemen toko.
• Suplier kekurangan data dasar (jumlah dan nilai), tingkat sediaan dan akuntansi sederhana atau informasi penagihan. Daftar harga tidak didasarkan pada biaya tapi pada harga jual ideal. Beberapa supplier kehilangan uang.
• Equipment bermasalah. Hanya 10% supplier mengirimkan barang dalam pallet dan ukuran pallet tidak terstandarisasi. Meskipun Taiwan merupakan produser plastik terbesar, tapi blister-pack sangat sukar ditemukan.
• Salespeople mendatangi Carrefour tanpa katalog, tanpa nomor referensi produk dan kadang-kadang tanpa formulir pemesanan.
• Suplier lokal tidak agresif. Peritel seringkali memohon minta produk. Inovasi terbatas tapi bisa diprakasai oleh Carrefour.
Opportunities
Wanita memegang peranan penting, karena 80% dari 20 juta pelanggan yang datang dan berbelanja di Carrefour adalah wanita (Carrefour, 2007). Namun menurut Lu, Carrefour di Taiwan memiliki lebih banyak konsumen pria daripada wanita (Taiwan Review, 2007). Karena pria itu praktis, maka pria dapat dipengaruhi dengan produk-produk yang dikemas dengan praktis seperti buah dan daging yang sudah dipotong. Selain itu, pria biasanya adalah tulang punggung keluarga, yang bertugas mencari nafkah, oleh karena itu waktu yang mereka miliki sangat terbatas dan mereka sensitif terhadap harga. Sehingga ini menjadi kesempatan bagi Carrefour yang memiliki positioning murah dan lengkap.
Taiwan adalah Negara berkembang, dengan pendapatan disposable yang meningkat dan accumulated wealth. Belanja adalah pengalaman paling mengasyikan bagi penduduk kota Taiwan, buktinya setiap akhir pekan seluruh pasar sangat sibuk. Menurut survei oleh consumer research consulting institution, sekitar 52.7% shoppers berorientasi pada harga dan 51.3% berorientasi pada rasa atau kualitas. 32.1% campuran perilaku belanja yang concern pada harga dan rasa serta kualitas.
Pemerintah secara aktif memperkenalkan lingkungan perdagangan untuk menarik investmen dan merencanakan untuk mendirikan institut penelitian perdagangan untuk membangun platform untuk mengembangkan perdagangan. Dalam menghadapi pasar globalisasi dan liberisasi, pemerintah secara progresif menghilangkan regulasi dalam mengimpor barang-barang, seperti granulated gula dan susu, di mana mungkin menarik perusahaan asing yang berpikir untuk melakukan ekspansi pada pasar Taiwan.
Threaths
Perusahaan ritel sekarang menghadapi isu yang kritikal, termasuk tantangan lingkungan, perubahan perilaku konsumen, persaingan dan kondisi ekonomi yang tidak menentu. Juga, karena pasar di Taiwan semakin matang dan kompetitif, meningkatnya jumlah peritel yang pindah ke China daratan. Begitu pula dengan ketidakpastian politik dan kebijakan investasi harus dipertimbangkan dengan hati-hati ketika membuka toko atau perusahaan di China
Pasar ritel matang dan bersaing di Taiwan. Kesamaan produk dan saluran distribusi adalah faktor utama untuk menjadi pemimpin pasar. Untuk menjawab kebutuhan konsumen membeli barang dalam satu toko, peritel harus mempertimbangkan bagaimana membangun platform untuk mengintegrasikan saluran nonfisik dan fisik. Hal ini membutuhkan investasi yang tidak sedikit dalam pengadaan perangkat keras atau lunak serta membangun supply chain yang kuat. Penekanan sistem pemasaran yang efektif sangat bermanfaat untuk mengapai tujuan, padahal supplier Taiwan kekurangan data, pengiriman sering bermasalah dan tidak agresif.
Carrefour yang sangat memprioritas hukum (prioritas utama orang Perancis). Kepatuhan pada pembayaran pajak pertambahan nilai merupakan hal yang penting di Perancis. Padahal Carrefour mempunyai produk yang banyak sekali jenisnya, maka kemungkinan salah mengaplikasikan pengenaan pajak sangat besar. Terutama di Taiwan, ada pajak bisnis dan pajak pertambahan nilai tapi juga ada zero tax. Maka perlu ada konsultan pajak.

MIKROTIK

Sekilas Mikrotik
Mikrotik sekarang ini banyak digunakan oleh ISP, provider hotspot, ataupun oleh pemilik warnet. Mikrotik OS menjadikan computer menjadi router network yang handal yang dilengkapi dengan berbagai fitur dan tool, baik untuk jaringan kabel maupun wireless.
Dalam tutorial kali ini penulis menyajikan pembahasan dan petunjuk sederhana dan simple dalam mengkonfigurasi mikrotik untuk keperluan-keperluan tertentu dan umum yang biasa dibutuhkan untuk server/router warnet maupun jaringan lainya, konfirugasi tersebut misalnya, untuk NAT server, Bridging, BW manajemen, dan MRTG.
Versi mikrotik yang penulis gunakan untuk tutorial ini adalah MikroTik routeros 2.9.27
Akses mirotik:
1. via console
Mikrotik router board ataupun PC dapat diakses langsung via console/ shell maupun remote akses menggunakan putty (www.putty.nl)
2. via winbox
Mikrotik bisa juga diakses/remote menggunakan software tool winbox
3. via web
Mikrotik juga dapat diakses via web/port 80 dengan menggunakan browser
Mikrotik sebagai Transparent web proxy

Salah satu fungsi proxy adalah untuk menyimpan cache. Apabila sebuah LAN menggunakan proxy untuk berhubungan dengan Internet, maka yang dilakukan oleh browser ketika user mengakses sebuah url web server adalah mengambil request tersebut di proxy server. Sedangkan jika data belum terdapat di proxy server maka proxy mengambilkan langsung dari web server. Kemudian request tersebut disimpan di cache proxy. Selanjutnya jika ada client yang melakukan request ke url yang sama, akan diambilkan dari cache tersebut. Ini akan membuat akses ke Internet lebih cepat.

Bagaimana agar setiap pengguna dipastikan mengakses Internet melalu web proxy yang telah kita aktifkan? Untuk ini kita dapat menerapkan transparent proxy. Dengan transparent proxy, setiap Browser pada komputer yang menggunakan gateway ini secara otomatis melewati proxy.

STRATEGI PENGEMBANGAN PERANGKAT LUNAK

STRATEGI PENGEMBANGAN PERANGKAT LUNAK

TAHAPAN DESAIN
Setelah selesai dalam pengembangan proses dan model (tahapan desain logis) maka tahapan selanjutnya adalah tahap coding. Tapi sebelum menuju ke tahapan coding maka ada beberapa strategi pengembangan perangkat lunak. Bab ini menjelaskan tentang strategi pengembangan perangkat lunak
1. DESAIN
• Fase ini adalah detail dari deskripsi teknis tentang bagaimana membangun sistem yg didefinisikan.
• Biasanya bagian ini disebut spesifikasi sistem yaitu produk akhir dari fase desain yg menjelaskan dengan tepat perancangan sistem seperti apa yg akaN diimplementasikaoleh tim desain selama fase implementasi.
LANGKAH DESAIN
Adapun dalam tahap fase desain adalah :
1. Menyajikan alternatif desain ( membuat
sendiri, membeli atau outsourcing)
2. Merancang arsitektur sistem
3. Membuat pemilihan perangkat keras dan perangkat lunak.
4. Merancang bagaimana data disimpan
5. Mendesain program
6. Membuat desain spesifikasi sistem
Dalam fase desain sebaiknya hindari kesalahan berikut :
1. Pengurangan waktu rancangan
2. Penambahan fitur dari apa yg sudah ditentukan dalam fase analisis
3. Mengganti tool dan dan teknologi pada pertengahan proyek
2. STRATEGI CODING
Ada 3 strategi coding dlm pengembangan program :
1. Custom development : membangun sistem dari nol dalam rumah produksi sendiri
2. Membeli paket software dan melakukan beberapa kostumisasi
3. Melakukan outsourcing ke pihak ketiga
CUSTOM DEVELOPMENT
Strategi desain ini memiliki keunggulan utama yaitu biaya pengembanganny dapat kita kendalikan sendiri dan relatif mudah.
 Kelebihan :
1. Tingkat fleksibilitas dan kreativitas lebih tinggi
2. Cocok dan konsisten dengan teknologi dan standar yg ada
3. Mampu membangun kemampuan dan pengetahuan fungsional dari tenaga kerja yg kita miliki
Kekurangan :
1. Membutuhkan waktu dan usaha yg signifikan
2. Mungkin membutuhkan keahlian atau pengetahuan fungsional yg belum
3. Berpotensi terjadi pembengkakan biaya
PEMBELIAN PAKET PL
Saat ini telah tersedia berbagai paket PL dan paket tersebut pasti telah diuji serta terbukti mampu menghemat waktu dan biaya pengembangan namun paket PL sangat jarang 100% sesuai dengan kebutuhan bisnis
Kelemahan utamanya adalah paket PL bisa jadi tidak bisa diintegrasikan dg sistem yg sudah ada jika dikembangkan.
OUTSOURCING
Adalah menyewa vendor luar, pengembang atau penyedia layanan untuk menyelesaikan tahapan desain. Keuntungan utamanya adalah mengurangi waktu produksi dan nilai tambah antara lain bisa menerima lebih banyak proyek dalam periode yg sama dan melakukan outsourcing pada pihak-pihak ketiga.
Kelemahan :
1. Kehilangan informasi penting
2. Kehilangan kendali akan pengembagan di masa depan
Beberapa pedoman yg diperlukan untuk
melakukan outsourcing adalah
1. Pelihara jalur komunikasi tetap terbuka dengan pihak ketiga
2. Definisikan dan stabilisasi kebutuhan sebelum menandatangani kontrak
3. Pilihlah vendor dengan hati-hati
4. Tugaskan seseorang untuk memelihara kerjasama
MEMILIH STRATEGI DESAIN
Dalam memilih strategi desain pertimbangkan hal berikut
a. Kebutuhan bisnis
b. Pengalaman sendiri
c. Kemampuan proyek
d. Manajemen proyek
e. Frame waktu yg tersedia
3. DESAIN ARSITEKTUR
Perencanaan bagaimana sistem akan didistribusikan di antara komputer-komputer yg ada dan PL dan perangkat keras apa yg digunakan untuk masing-masing komputer.Dalam desain arsitektur perlu diperhatikan hal berikut :
1. Spesifikasi PL dan PK
2. Deskripsi detail komponen PL/PK untuk mempermudah pihak yg akan membeli PL/PK tersebut
ELEMEN DESAIN ARSITEKTUR
Komponen arsitektural dapat dibagi menjadi :
1. Data storage merupakan komponen yg digunakan untuk menyimpan data
2. Data access logic merupakan prosedur yg digunakan untuk akases data yg disimpan dalam data storage
3. Application logic merupakan bagian logika pemrosesan dlm lapis aplikasi
4. Presentation logic merupakan komponen pemrosesan rampilan dan perintah dari pengguna
TUJUAN DESAIN ARSITEKTUR
Tujuan dr desain arsitektur adalah untuk menentukan komponen PL mana yg akan diinstal ke PK yg tersedia. Adapun pilihan PKyg tersedia adalah :
1. Klien adl input/output device yg dioperasikan oleh user, seperti PC, laptop,
Hp
Pilihan untuk klien :
a. Terminal
b. Microcomputer
c. Minicomputer
2. Server
komputer yg lebih canggih untuk menyimpan PL yg bisa diakses oleh bnyk pengguna
Pilihan untuk server :
a. Mainframe
b. Microcomputer (PC)
c. Terminal khusus
PILIHAN ARSITEKTUR
SERVER BASED ARSITEKTUR
Client-Server
Pada arsitektur jenis ini empat komponen perangkat lunak (PL) diletakan pada bagian yang sama yaitu server. Terminal yg tersedia hanya digunakan sebagai perpanjangan dari server saja. Pada arsitektur ini data relatif aman tetapi beban kerja server sangat berat krn semua komponen dijalankan di server
CLIENT BASED ARSITEKTUR
Client microcomputer
Server(microcomputer)
Pada arsitektur ini data dan prosedur pengaksesan data dilayani oleh server dan masalah tampilan dan logika aplikasi dilayani oleh pengguna. Arsitektur ini cukup menjamin keamanan data karena prosedur mengakses data oleh client ditangani server
CLIENT SERVER ARSITEKTUR (TWO TIERED)
Client microcomputer
Server(microcomputer)
Pada arsitektur ini server hanya berperan sebagai data storage. Komputer klien lah yg digunakan untuk mengolah data yg dikirim oleh server. Beban kerja server sangat ringan, tetapi keamanan data sangat tergantumg kinerja dr klien.

SISTEM INFORMASI MANAJEMEN

SISTEM INFORMASI MANAJEMEN
Suatu alat untuk menyajikan informasi dengan cara sedemikian rupa sehingga bermanfaat bagi penerimanya (Kertahadi, 1995)
Tujuannya adalah untuk menyajikan informasi guna pengambilan keputuan pada perencanaan, pemrakarsaan, pengorganisasian, pengendalian keputusan pada operasi sub sistem suatu perusahaan (Murdick dan Ross,1993)

KOMPONEN SISTEM INFORMASI
Stair (1992) menjelaskan bahwa sistem informasi berbasis komputer terdiri dari komponen-komponen berikut :
• Perangkat keras yaitu perangkat keras untuk komponen memasukan data memproses data dan keluaran data
• Perangkat lunak yaitu program dan instruksi yang diberikan ke komputer
• Database yaitu kumpulan data dan informasi yang diorganisasikan sedemikian rupa sehingga mudah diakses
• Telekomunikasi yaitu komunikasi yang menghubungkan antara pengguna sistem dengan sistem komputer secara bersama-sama ke dalam suatu jaringan kerja yang efektif
• Manusia adalah suatu personel dari sistem informasi, meliputi manajer, analis, programer dan operator serta bertanggung jawab terhadap perawatan sistem

PROSEDUR
Prosedur yakni tata cara yang meliputi strategi, kebijakan, metode dan peraturan- peraturan dalam menggunakan sistem informasi berbasis komputer .

TIPE SISTEM INFORMASI
CBIS mengacu pada sistem informasi yang ikembangkan berbasis komputer
CBIS = hardware, software, people, rocedures, informasi
CBIS biasanya dibedakan menjadi beberapa tipe aplikasi :
• Transaction Processing System (TPS) sistem informasi terkomputerisasi yang dikembangkan untk memproses sejumlah besar data untuk transaksi bisnis rutin.
• Sistem Informasi Manajemen (SIM) sebuah sistem informasi pada level manajemen yang berfungsi untuk membantu perencanaan, pengendalian, dan pengambilan keputusan.
• Decision Support System sebuah sistem informasi pada level manajemen yang mengombinasikan data dan model analisis canggih atau peralatan data analisis untuk mendukung pengambilan semi terstruktur dan tidak terstruktur .
• Expert Sistem merupkan representasi pengetahuan yang menggambarkan cara seorang ahli dalam mendekati suatu masalah.

ANALISIS DAN PERANCANGAN SISTEM

ANALISIS DAN PERANCANGAN SISTEM

PENGERTIAN ANALISI SISTEM
• Analisis sistem didefinisikan sebagai bagaimana memahami dan menspesifikasi dengan detail yang harus dilakukan oleh sistem
• Sistem desain diartikan sebagai menjelaskan dengan detail bagaimana bagian-bagian dari sistem informasi diimplementasikan.

ANALISIS DAN DESAIN SI (ANSI)
• Analisis : mendefinisikan masalah From requirments to spesification
• Design : memecahkan masalah From spesification to implementation

METODE PNGEMBANGAN SISTEM
• Ada beberapa macam metode atau model proses pengembangan sistem
• Proses pengembangan sistem merupakan aktifitas yang saling terkait koheren ) untuk menspesifikasikan , merancang , implementasi dan pengujian sistem perangkat lunak (koheren) menspesifikasikan, merancang sistem

KONSEP DASAR INFORMASI

KONSEP DASAR INFORMASI

PENGERTIAN SISTEM INFORMASI
Menurut Davis (1995) :
1) Sistem informasi adalah keterkaitan antara data dengan informasi.
2) Data merupakan nilai, keadaan, atau sifat yang berdiri sendiri lepas dari konteks apapun.
3) Informasi adalah data yang telah diolah menjadi suatu bentuk yang berarti bagi penerimanya dan bermanfaat dalam pengambilan keputusan saat ini atau mendatang.

SISTEM INFORMASI MANAJEMEN
1) Suatu alat untuk menyajikan informasi dengan cara sedemikian rupa sehingga bermanfaat bagi penerimanya (Kertahadi, 1995)
2) Tujuannya adalah untuk menyajikan informasi guna pengambilan keputuan pada perencanaan, pemrakarsaan, pengorganisasian, pengendalian keputusan pada operasi sub sistem suatu perusahaan (Murdick dan Ross,1993)

PENGERTIAN DATA
• Data adalah penggambaran dari sesuatu dan kejadian yang kita hadapi.
• Data adalah kenyataan yang menggambarkan suatu kejadian dan kesatuan yang nyata.

KUALITAS INFORMASI
Akurat : Informasi yang dihasilkan tidak menyesatkan bagi orang yang menerima informasi tersebut.
Tepat waktu : Informasi harus tepat pada waktu sebab jika terlambat tidak berguna lagi Relevan : Informasi harus mempunyai manfaat bagi si penerima sebab informasi ini akan digunakan untuk pengambilan suatu keputusan untuk pemecahan masalah.