UML Activity Diagram

Langkah pertama yang HARUS dilakukan untuk memodelkan perangkat lunak adalah dengan membuat model proses bisnis. Proses bisnis yang dimaksudkan disini adalah proses yang terkait dengan urutan langkah, cara kerja atau bagaimana kita melakukan pekerjaan tertentu. Urutan langkah atau cara kerja inilah yang akan dibangun pada perangkat lunak.

Pemodelan proses bisnis dapat dibagai menjadi dua bagian. Bagian pertama disebut identifikasi problem domain. Pada bagian ini, tim pengembang bekerja sama dengan stakeholders berusaha untuk menemukan setiap permasalahan yang ada dalam proses bisnis. Proses ini dapat dilakukan dengan melalui wawancara, menyebarkan kuesioner ataupun melakukan diskusi. Setelah dilakukan identifikasi problem domain, maka dilanjutkan dengan menyimpulkan kebutuhan user/stakeholders terkait dengan perangkat lunak yang akan dibangun. Pada tahap ini, penting sekali untuk disepakati bersama kebutuhan-kebutuhan apa yang akan diselesaikan oleh perangkat lunak.

Bagian kedua pemodelan proses bisnis adalah identifikasi solution domain. Solution domain dimulai dengan mengidentifikasi features (berdasarkan needs yang ada) yang harus dibangun pada perangkat lunak. Berdasarkan features ini kemudian ditentukanlah software specification requirements yang akan dibangun.

Jika akan menggunakan UML maka kakas pemodelan yang bisa digunakan dalam pemodelan proses bisnis ini adalah Activity Diagram, Business Use-case Model, Business Object Model (BOM) dan Use-case Diagram. 

Pada bagian tulisan ini, saya akan menuliskan tentang memodelkan proses bisnis dengan Activity Diagram. Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang: awal proses, decision, akhir proses, proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu

Notasi dalam Activity Diagram

Cara menggambarkan activity diagram:

1. Menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. 

2. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.

3. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

4. Untuk dapat menggambarkan activity diagram dengan baik, disarankan agar membuat daftar sejumlah aktivitas beserta dengan kondisinya. Tools FDD dapat menjadi sangat berguna untuk mengecek proses-proses serta jalur aktivitas, baik dari level atas maupun level rincinya.

Tentang Activity Diagram:

Sebuah Activity diagram dalam business use-case menggambarkan workflow (aliran kerja) sebuah business use-case. Workflow dari sebuah business use-case menggambarkan apa yang harus dikerjakan bisnis tersebut untuk menghasilkan nilai tertentu untuk business actor yang bersangkutan. Activity diagram di bawah ini memodelkan alur kerja (workflow) sebuah proses bisnis dan urutan aktivitas dalam suatu proses.

Contoh pada Studi Kasus:

Pada sebuah Foodcourt. Pembeli datang ke foodcourt, menuju stand penjual makanan yang dinginkan. Pembeli memesan makanan, jika makanan tersebut ada, maka pesanan disiapkan, jika makanan tersebut tidak ada maka pembeli tidak jadi memesan makanan. Setelah memesan, petugas stand menyiapkan bon dua rangkap dan memberikan bon tersebut kepada pembeli.

Pembeli kemudian membayar makanan yang dibeli di kasir stand dengan menyerahkan bon pembelian. Kasir menghitung jumlah yang harus dibayar pembeli dan menginformasikannya ke pembeli. Pembeli menyiapkan uang dan memberikan kepada kasir. Jika ada kembalian, kasir menghitung kembalian tersebut dan memberikan kembalian beserta bukti pembayaran (struk) serta bon yang sudah ditandai lunas.

Pembeli mencari tempat duduk, penjual stand makanan memberikan makanan kepada pembeli dengan mengambil bon yang sudah ditandai lunas tersebut.

Activity Diagram Pembayaran

Activity Diagram Pemesanan

Sebuah Video Tutorial tentang Activity Diagram dapat dilihat disini:
http://www.youtube.com/watch?v=yAihwmczqsk&feature=related

UML dan Pemodelan Software

Pemodelan pada dasarnya merupakan kegiatan untuk menyederhanakan. Seperti misalnya kita ingin memahami tentang bentuk bumi yang seperti bola. Alih-alih kita melihat bumi dari luar angkasa, maka kita mengambil benda yang “menyerupai” bola, dan kemudian mulai memodelkan bumi yang sebenarnya.

Kegiatan pemodelan perangkat lunak berorientasi obyek adalah kegiatan untuk mencoba menyederhanakan perangkat lunak yang akan kita kembangkan dengan terlebih dahulu membuat model visualisasi (penggambaran model) perangkat lunak yang akan dikembangkan. Pembuatan model visualisasi perangkat lunak dilakukan dengan menggunakan kakas yang disebut Unified Modelling Language atau disingkat UML. 

Jadi, sebenarnya UML adalah:

1. sebuah "bahasa" pemodelan perangkat lunak standar yang dapat digunakan untuk melakukan spesifikasi, visualisasi, konstruksi, dan dokumentasi dari komponen-komponen perangkat lunak.
2. bahasa pemodelan visual yang notasi grafis yang ekspresif dalam arti lengkap dan mudah dipahami, baik oleh pengembang maupun user.
3. menggunakan class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa berorientasi obyek seperti C++, Java, C# atau VB.NET.

Tiga hal yang harus diperhatikan agar dapat menguasai UML dengan baik, yaitu:

1. Memahami maksud dan tujuan digunakannya UML
2. Memahami apa yang akan dimodelkan dalam UML
3. Menguasai langkah-langkah pembuatan diagram UML

Ada beberapa notasi grafis dalam UML yang dapat digunakan untuk memodelkan aplikasi perangkat lunak berorientasi obyek. Notasi grafis atau disebut juga diagram tersebut memiliki bermacam-macam sudut-pandang (atau disebut perspektif) untuk menunjukkan model perangkat lunak. Diagram-diagram tersebut juga menunjukkan tingkat abstraksi pemodelan berorientasi obyek yang berbeda-beda. Berikut adalah Ringkasan Diagram UML ver 2.0 yang diambil dari buku System Analysis and Design with UML version 2; An Object-Oriented Approach,2nd Ed. By Allan Dennis, Barbara Wixon, David Tegarden. © John Wiley&Sons, 2010

Bagaimana memodelkan perangkat lunak dengan UML?

Terdapat banyak variasi dalam memodelkan perangkat lunak dengan menggunakan UML. Dibawah ini saya memberikan saran untuk memodelkan perangkat lunak dengan menggunakan UML. Tidak berarti bahwa saran saya ini adalah yang paling tepat, penyesuaian terhadap langkah-langkah pemodelan itu sangat terbuka. Masing-masing pengembang dapat menemukan "best practices"-nya sendiri. Urutan langkah yang disarankan untuk memodelkan perangkat lunak dengan menggunakan UML adalah:

1. Buatlah daftar proses business dari level tertinggi untuk mendefinisikan aktivitas dan proses yang mungkin muncul. Langkah ini dapat dilakukan dengan membuat FDD (functional decomposition diagram) ataupun dengan membuat Business Use Case Model dan Business Object Model (BOM).
2. Petakan use case untuk tiap proses business 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. Definisikan requirement lain (non-fungsional, security dan sebagainya) yang juga harus disediakan oleh sistem dengan mengisi use case table.
4. Berdasarkan use case table, highlight semua potensial obyek dan dari situ pilihlah obyek yang dapat dijadikan sebuah kelas. Kemudian, gambarkan high-level class digram dan detailed class diagram.
5. Setelah class diagram dibuat, kita dapat melihat kemungkinan pengelompokan class menjadi komponen-komponen. Oleh karena itu buatlah component diagram pada tahap ini. Juga, definisikan tes integrasi untuk setiap komponen meyakinkan ia berinteraksi dengan baik.
6. Berdasarkan use case diagram, mulailah membuat activity diagram.
7. Setelah activity diagram selesai dibuat, maka langkah selanjutnya yaitu mendefinisikan objek-objek level atas (package atau domain). Lalu 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.
8. Buatlah rancangan user interface model yang menyediakan antarmuka bagi pengguna untuk menjalankan skenario use case.
9. Perhalus deployment diagram yang sudah dibuat. Detilkan kemampuan dan requirement piranti lunak, sistem operasi, jaringan, dan sebagainya. Petakan komponen ke dalam node.
10. Mulailah membangun sistem. Ada dua pendekatan yang dapat digunakan:
11. Pendekatan use case, dengan meng-assign setiap use case kepada tim pengembang tertentu untuk mengembangkan unit code yang lengkap dengan tes.
12. Pendekatan komponen, yaitu meng-assign setiap komponen kepada tim pengembang tertentu.
13. Lakukan uji modul dan uji integrasi serta perbaiki model berserta codenya. Model harus selalu sesuai dengan code yang aktual.
14. Piranti lunak siap dirilis.

Sebuah Video Tutorial tentang Introduction to UML, bisa dilihat disini:
http://www.youtube.com/watch?v=FkRwbVUVFvE&feature=fvwrel

ERD dan Normalisasi

ERD merupakan alat bantu untuk visualisasi pemodelan data. ERD berperan penting dalam melakukan pemodelan data logis. Seperti kita kita bersama, pemodelan data logis sangat penting dalam proses perancangan basis data. ERD juga sangat membantu dalam melakukan normalisasi data.

Pemodelan logic data dikembangkan dalam beberapa tahapan sebagai berikut:

1) Context ERD atau Model Data Konteks

Model data ini digunakan untuk menentukan lingkup proyek yang tidak terlalu detail dalam membahas entitas dan aturan bisnis. Banyak hubungan  tersebut mungkin non- spesifik.

Berikut adalah sebuah contoh Context ERD yang menjelaskan mengenai sebuah proses bisnis yang melibatkan entitas-entitas seperti customer, customer order, customer transaction, product dan product_type.

2) Model Data Key-Based

Pada model data key-based, kita telah mulai menyertakan attribute data yang memiliki primary key, foreign key dan entitas asosiatif yang ada. 

Apabila terdapat 2 buah tabel yang mempunyai hubungan many-to-many, maka kedua tabel ini harus dipisahkan dengan cara menambah sebuah tabel diantaranya. Kemudian berikan relevan key di setiap tabelnya dan jangan lupa untuk mengganti notasi kardinalitas pada ketiga tabel tersebut.

Lihat pada contoh gambar diatas. 

Tabel ‘member_order’ and ‘product’ mempunyai hubungan many-to-many. Kedua tabel ini harus dipisahkan dengan menambahkan sebuah tabel dan namakan tabel tersebut ‘member_ordered_product’. Tabel baru ini berisi 2 primary keys yaitu  member_order_id (table member_order) dan product_id (table product). 

Jika ingin memudahkan pengkodean, anda dapat menambahkan sebuah primary key lainnya dan namakan key tersebut ‘member_ordered_product_id (pk)’ di mana key ini mempunyai fungsi yang sama dengan member_order_id (pk) and product_id (pk). Akan tetapi, bila hal ini dilakukan, anda harus mengganti ‘member_ordered_product_id (pk)’ menjadi ‘member_ordered_product_id (fk) dan ‘product_id (pk)’ menjadi ‘product_id (fk)’.

3) Model Data Fully-Attributed

Model data fully-attributed adalah model data logic yang menyertakan semua atribut deskriptif secara menyeluruh.

Lihat pada Gambar dibawah

4) Normalized Data Model

Normalised data model adalah model data logis yang telah melalui proses normalisasi. Pada dasarnya normalisasi adalah suatu teknik pengorganisasian data ke dalam tabel-tabel untuk memenuhi kebutuhan pengguna. Tujuannya untuk mernghilangkan kerangkapan data, mengurangi kompleksitas data dan mempermudah modifikasi data.

Secara singkat tahapan Normalisasi adalah sebagai berikut:

1. Bentuk Normal Tahap Pertama (1st Normal Form)

Pada bentuk ini, semua elemen yang berulang pada suatu entitas      dihapuskan. Dalam 1st Normal Form tidak ada elemen data yang muncul beberapa kali untuk satu entitas tertentu.

2. Bentuk Normal Tahap Kedua (2nd Normal Form)

Dalam bentuk ini pastikan bahwa atribut descriptor bergantung pada seluruh composite key untuk identifikasi.

3. Bentuk Normal Tahap Ketiga (3rd Normal Form)

Dipastikan bahwa nilai atribut tidak bergantung pada nilai atribut lain dalam entitas yang sama.

Pada contoh gambar kita sebelumnya, semua atribut yang ada pada table-tabel di atas sudah normal, maka dari itu tidak perlu dilakukan normalisasi. Jika dalam situasi yang berbeda di mana harus dilakukan normalisasi terhadap tabel-tabel tertentu, pergunakanlah aturan normalisasi dengan benar. Setelah dilakukan normalisasi, maka gabungkan kembali tabel yang sudah dinormalisasi dengan tabel lainnya. 

5) Physical Database Schema

Untuk menggambarkan bagian ini, maka harus mengambil gabungan tabel yang sudah dinormalisasi sebelumnya. Kemudian tambahkan data type dan data length pada setiap atribut yang ada pada tabel-tabel tersebut. Apabila ada batasan-batasan yang harus diketahui, maka hal ini harus dideskripsikan secara singkat pada skema basis.
Lihat contohnya pada Gambar dibawah ini:

Semua Gambar diambil dari buku teks System Analysis and Design for the Global Enterprise - Bentley & Whitten, 7th ed, 2007

Data Flow Diagram

Pemodelan sistem informasi sering dilakukan dengan menggunakan DFD (Data Flow Diagram). Sebelum berkembang pemodelan berorientasi obyek yang menggunakan UML, maka tools DFD sangat sering digunakan. Dalam hubungan dengan metodologi pengembangan sistem informasi maka DFD sering digunakan pada metode Waterfall.
O’brien (1999) menjelaskan bahwa DFD merupakan diagram yang mendemonstrasikan cara data diproses oleh system . Bocij, Chaffey, Greasley, dan Hickie (2003) menjelaskan  diagram konteks merupakan pola penggambaran yang berfungsi untuk memperlihatkan interaksi sistem informasi tersebut dan lingkungan di mana sistem tersebut ditempatkan.
Simbol-simbol yang digunakan dalam DFD menurut DeMarco dan Yourdon, adalah sebagai berikut:

Gambar Simbol-Simbol DFD

Sumber:  Bentley & Whitten, System Analysis and Design for the Global Enterprise 7th ed, 2007

Penjelasan simbol-simbol tersebut dikutip dari McLeod (2001):
1) Arus Data (Data Flow) merupakan kumpulan elemen-elemn data, yang berhubungan secara logis yang bergerak dari satu titik atau process ke titik atau proses lain. Tanda panah menyatakan arah hubungan antar elemen data tersebut
2) Entitas Eksternal (External Entity(, yakni entitas yang berada diluar sistem, tetapi bisa memberikan masukan bagi sistem dan menerima keluaran dari sistem.
3) Proses (Process), adalah sesuatu yang mengubah masukan menjadi keluaran. Tiap proses memiliki satu atau lebih data masukan dan menghasilkan satu atau lebih data keluaran.
4) Penyimpanan Data (Data Storage). Dalam istilah DFD, data store adalah merupakan suatu tempat penyimpanan data.

Berikut adalah aturan mengenai penggambaran Diagram Konteks dan DFD level-n:
Aturan Diagram Konteks:
1. Gunakan satu simbol proses
2. Berikan nama atau label pada simbol proses tersebut untuk menggambarkan seluruh sistem.
3. Tidak menomori simbol proses tersebut.
4. Menyertakan semua extenal entity dari sistem.
5. Menunujukkan semua data flow antara teminator dan sistem.

Aturan Diagram Gambar-n
Diagram gambar-n mendokumentasikan satu proses DFD secara lebih tinggi. Huruf n menggambarkan jumlah proses pada tingkat selanjutnya yang lebih tinggi yang sedang didokumentasikan.
Tahapan Pembuatan DFD
1. Beri label tiap arus data (data flow) dengan nama yang unik.
2. Jaga agar nama arus data tetap dari satu tingkat ke tingkat lain.
3. Tunjukkan penempatan yang tepat bagi catatan-catatan yang dihapuskan dari penyimpanan data.
4. Saat mendokumentasikan program komputer jangan menyertakan proses membaca dan menulis.
5. Hindari proses membaca saja (read-only process).
6. Proses membaca saja diijinkan jika waktu berfungsi sebagai pemicu

Aturan Penggambaran DFD

Berikut saya berikan contoh langkah-langkah untuk menggambar DFD:
1) Menggambar Functional decomposition diagram (FDD)
2) Menggambar Context DFD (Level 0)
3) Menggambar DFD Level 1
4) Menggambar DFD Level 2 … Level n (Event diagrams)
Contoh kasus adalah sebuh Proses Sales Processing!

Gambar FDD

Gambar Context Diagram

Gambar DFD Level 1

Gambar DFD Level 2

Sebuah contoh lainnya tentag Pemodelan menggunakan DFD dapat dilihat disini ....

Eliminasi Gauss

Praktikum Metode Numerik
Modul 5 Metode Eliminasu Gauss
BAB I
TUJUAN DAN DASAR TEORI

I.1. Tujuan
1) Menguasai metode eliminasi gauss yang digunakan dalam komputasi numerik
2) Memahami algoritma pemrograman untuk merancang program metode eliminasi gauss yang ada dalam komputasi numerik
3) Menerapkan algoritma untuk perancangan dan pembuatan program metode eliminasi gauss.

II.2. Dasar Teori
Berikut ini dipaparkan metode 2 langkah dalam menyelesaikan persamaan dengan Gaussian Eliminasi.

Langkah ke-1:
Melakukan proses triangulasi = mengubah matriks A menjadi matriks segitiga (hal ini akan mengubah matriks B)

Langkah ke-2:
Melakukan substitusi mundur, yaitu: menghitung x mengikuti urutan terbalik, dari yang terakhir (Xn ) sampai yang pertama (X1 )

Modul selengkapnya dapat diunduh disini

Metodologi RAD - Rapid Application Development

Metodologi RAD merupakan salah satu metodologi pengembangan perangkat lunak yang "cepat". RAD merupakan hasil adaptasi dari Waterfall yang dirasakan cukup lama. Saya pernah membimbing seorang mahasiswa KP/TA dengan menggunakan metodologi RAD dalam mengembangkan aplikasi berbasis web. 

Berikut adalah catatan saya mengenali langkah-langkah metodologi RAD. Dalam metode RAD terdapat langkah-langkah yang dibagi dalam empat fase. Langkah-langkah metode RAD adalah sebagai berikut:
 

3.1 Fase Analisis Persyaratan
Fase ini memiliki tujuan untuk mengidentifikasi layanan, batasan, dan obyektifitas dari sistem dari pengumpulan data yang dilakukan terhadap stakeholders. Selain itu analisis persyaratan juga bertujuan untuk mendefinisikan persyaratan user dan sistem. Hasil akhir dari analisis persyaratan yaitu spesifikasi awal dari persyaratan user dan sistem. Adapun Fase 1 ini terdiri dari 5 langkah  yaitu sebagai berikut:
a.    Langkah 1.1:  Komunikasi dan Perencanaan Proyek
Tujuan dari langkah komunikasi dan perencanaan proyek adalah untuk mengidentifikasi kegiatan, patokan, dan apa yang harus dihasilkan oleh proyek. Langkah 1.1 ini menghasilkan perencanaan proyek, manajemen perubahan persyaratan dan manajemen resiko.
b.    Langkah 1.2:  Studi kelayakan
Tujuan dari studi kelayakan adalah untuk menentukan apakah proyek dapat dilanjutkan. Jika proyek dapat diteruskan, studi kelayakan akan menghasilkan rencana proyek dan estimasi biaya untuk tahap pengembangan selanjutnya. 

Ada 4 macam studi kelayakan yang dapat dilakukan yaitu:

i.  Teknis: Kelayakan teknis digunakan untuk menentukan penggunaan solusi teknis tertentu dalam sistem/proyek, dan ketersediaan sumber daya dan keahlian teknis.

ii.  Operasional: Kelayakan operasional adalah ukuran seberapa baik solusi akan berhasil dalam organisasi. Studi kelayakan ini juga mengukur persepsi orang akan sistem/proyek.

iii.  Ekonomi: Kelayakan ekonomi digunakan untuk mengukur biaya yang mempengaruhi proyek/solusi. 

iv.  Penjadwalan: Kelayakan penjadwalan digunakan untuk mengukur timeline proyek. 

c.   Langkah 1.3:  Spesifikasi pengguna

Tujuan dari spesifikasi pengguna yaitu untuk mengidentifikasi dan menetapkan kebutuhan user mengenai apa yang akan dicapai oleh proyek ini. Hasil dari daftar pengguna beserta tugas dan tanggung jawabnya, problem statement matrix, dan daftar prioritas kebutuhan pengguna.
d.    Langkah 1.4:  Spesifikasi sistem

Tujuan dari spesifikasi sistem adalah menjelaskan kebutuhan dan keinginan akan adanya sistem informasi. Dapat memberikan deskripsi mengenai fungsi-fungsi, fitur-fitur (atribut) dan batasan-batasan yang dibutuhkan sistem. Langkah ini menghasilkan pernyataan yang jelas mengenai tujuan dibangunnya sistem, fitur-fitur aplikasi dan batasan-batasannya.
Semua hasil dari langkah-langkah yang terdapat dalam fase 1 ada pada dokumen fase 1.
 

3.2 Fase Analisis Modeling
Tujuan dari fase analisis modeling adalah menganalisis semua kegiatan dalam arsitektur sistem secara keseluruhan dengan melibatkan identifikasi dan deskripsi abstraksi sistem perangkat lunak yang mendasar dan hubungan-hubungannya. Selain itu, analisis modeling juga bertujuan untuk meningkatkan pemahaman terhadap permasalahan tanpa mempertimbangkan solusi teknis. Hasil akhir dari analisis modeling yaitu diagram model logis dari sistem yang sedang berjalan, diantaranya use case diagrams, class diagram, dan sequence diagrams. Fase 2 ini terdiri dari:
a.    Langkah 2.1:  Mengidentifikasi pelaku bisnis
Tujuan dari langkah ini yaiut untuk mengidentifikasi user yang terlibat dalam bisnis proses beserta dengan peranan/tanggung jawab mereka dalam penggunaan sistem. Hasilnya adalah daftar aktor beserta tugas dan tanggung jawabnya.
b.    Langkah  2.2:  Menganalisis proses dan kinerja sistem

Tujuannya yaitu untuk memperoleh deskripsi secara jelas mengenai dukungan fungsional dan non-fungsional yang menjadi kebutuhan terhadap sistem yang dikembangkan dengan menggunakan model diagram use case. Hasil dari langkah ini yaitu use case diagram.
c.    Langkah 2.3: Mengidentifikasi struktur obyek dan relasinya

Tujuan dari langkah ini yaitu untuk mengidentifikasi dan pemodelan kelas objek dalam sistem yang akan dikembangkan, yang menggambarkan struktur obyek dalam sistem.
i.    Menemukan objek yang potensial

Tujuannya yaitu untuk menemukan kata benda yang berhubungan dengan entitas bisnis. Hasilnya yaitu daftar objek yang berpotensi.
ii.    Mendokumentasikan bisnis obyek dan relasinya
Tujuannya untuk mengatur obyek-obyek yang telah diidentifikasi dan mendokumentasikan hubungan konseptual utama antara obyek-obyek tersebut. Hasilnya adalah class diagram (yang dikenal juga sebagai object association diagrams).
iii.    Analisis perubahan keadaan obyek
Tujuannya adalah untuk mengidentifikasi dan memodelkan obyek yang mengalami perubahan keadaan. Hasil dari analisis perubahan keadaan obyek yaitu activity diagrams.
 

3.3 Fase Desain Modeling
Tujuan dari fase desain modeling yaitu melakukan perancangan sistem berdasarkan analisis yang telah dilakukan sebelumnya. Tahap analisis dan desain mengalami perulangan hingga diperoleh rancangan sistem yang benar-benar memenuhi kebutuhan. Selain itu, fase 3 ini juga bertujuan untuk memberikan spesifikasi yang jelas dan lengkap kepada programmer dan teknisi. Hasil akhir dari fase ini yaitu basis data, antarmuka, dan spesifikasi desain. Fase 3 ini terdiri dari:
a.    Langkah 3.1:  Memodelkan kembali diagram use case untuk  merefleksikan  lingkungan  implementasi
Tujuanya adalah untuk memperlihatkan perubahan dari analisis use case menjadi desain use case dan memperbaharui model diagram use case dengan menambahkan lebih banyak fakta dari proses pengembangan dan dokumentasi untuk memperlihatkan use case yang baru. Hasil dari langkah 3.1 adalah design use cases (physical.)
b.    Langkah 3.2:  Memodelkan interaksi obyek dan behaviours
Tujuannya adalah untk mengidentifikasi dan mengelompokkan perancangan obyek dan atribut-atribut yang dibutuhkan secara fungsional yang telah dispesifikkan sebelumnya lewat setiap use case dan mengidentifikasi object interactions. Hasilnya yaitu daftar interface, control, dan entity untuk setiap obyek., use case diagram, activity diagram, sequence diagram.
c.    Langkah 3.3:  Desain antarmuka
Tujuannya adalah untuk menyediakan detail elemen multimedia yang akan digunakan, message yang akan disampaikan, presentasi isi, map navigasi, contoh halaman, dan storyboard. Hasil dari tahap 3.3 yaitu storyboard.
d.    Langkah 3.4:  Membuat algoritma
Tujuannya yaitu untuk merepresentasikan prosedur logic dari fungsi yang dibuat dalam aplikasi. Hasilnya adalah flowchart.
 

3.4 Fase 4: Konstruksi
Tujuan dari fase konstruksi adalah untuk menunjukkan platform, hardware dan software yang digunakan serta batasan dalam implementasi, serta menguji performansi prototipe perangkat lunak yang telah dibangun agar dapat diketahui apakah prototipe tersebut telah sesuai dengan spesifikasi analisis dan perancangan yang telah diidentifikasi sebelumnya. Hasil akhir dari fase konstruksi adalah platform, hardware dan software yang digunakan, serta daftar batasan implementasi, dan rencana pengujian. Fase 4 ini terdiri dari:
a.    Langkah 4.1: Lingkungan implementasi
Tujuannya yaitu menfasilitasi pengembangan sistem dengan menggunakan perangkat keras dan perangkat lunak yang sudah disediakan. Hasilnya adalah daftar perangkat keras dan perangkat lunak.
b.    Langkah 4.2: Implementasi basis data
Tujuannya yaitu membangun basis data berdasarkan pemodelan kelas objek. Hasilnya adalah basis data sistem.
c.    Langkah 4.3: Melakukan pemrograman
Tujuannya yaitu membuat pengkodean sistem berdasarkan model algoritma dan diagram objek yang telah dirancang.Hasilnya adalah kode program.
d.    Langkah 4.4: Implementasi antarmuka
Tujuannya adalah untuk membangun antarmuka pengguna. Hasilnya adalah kode program lengkap dengan antarmuka pengguna.
e.    Langkah 4.5: Pengujian
i. Identifikasi tujuan pengujian sistem.
Tujuannya untuk emperoleh tujuan pengujian sistem agar dapat digunakan sesuai dengan kebutuhan. Hasilnya daftar tujuan pengujian sistem.
ii. Buat kriteria pengujian sistem
Tujuannya untuk mengidentifikasi kriteria pengujian sistem sehingga menjadi tolak ukur dalam analisis hasil pengujian. Hasilnya daftar kriteria pengujian sistem pakar.
iii. Buat kasus untuk pengujian
Tujuannya untuk menentukan skenario yang akan dilaksanakan dalam pengujian sehinga pengujian dapat dilakukan secara terarah. Hasilnya daftar kasus untuk pengujian.
iv. Lakukan Pengujian Sistem
Tujuannya melaksanakan serangkaian kegiatan pengujian berdasarkan tujuan dan kasus uji. Hasilnya test plan.   

Metodologi AUP

Metodologi AUP atau Agile - Unified Process merupakan suatu metodologi pengembangan perangkat lunak yang mulai marak digunakan. Menurut hemat saya, metodologi ini paling cocok digunakan oleh mahasiswa dalam menyelesaikan tugas proyek mata kuliah ataupun mengerjakan laporan Kerja Praktek (dan Tugas Akhir)

Gambar 1 menunjukkan menunjukkan Tahapan Proses dan Aktivitas Metodologi AUP

Gambar 2 menunjukkan urutan akvitas pada masing-masing fase AUP

Tahapan pemecahan masalah dengan metodologi AUP, mengikuti langkah-langkah yang dikeluarkan oleh Pusilkom Universitas Indonesia. Panduan Agile UP ini mengacu pada metodologi yang dibuat oleh Ambysoft Inc (lihat Gambar 1 dan Gambar 2). Garis besar tahapan analisa dan perancangan yang dilakukan adalah sebagai berikut:
1)    Inception, 

dengan aktivitas mendefinisikan project scope, mengestimasi biaya dan penjadwalan, mendefinisikan resiko, membuat kelayakan proyek dan mempersiapkan lingkungan pengerjaan proyek (tim, tempat kerja, instalasi, dan sebagainya). Proses iterasi dilakukan satu kali. Artifak yang dihasilkan diantaranya adalah dokumen Vision, dokumen Supplementary Specification, dokumen Glossary, Gantt Chart dan Iteration Plan.

2) Elaboration, 

dengan aktivitas mengidentifikasi dan validasi arsitektur aplikasi. Proses iterasi dapat dilakukan satu sampai dua kali. Artifak yang dihasilkan adalah UML Use Case, Model Arsitektur (update dan snapshot), Architecture Prototype Code, Scenario Test Plan, dokumen Business Rule, dokumen Supplementary dan Glossary yang telah diupdate.
 

3) Construction, 

dengan aktivitas memodelkan, membangun dan menguji sistem aplikasi (unit testing) serta membuat dokumentasi pendukung. Proses iterasi dapat dilakukan dua hingga delapan kali. Artifak yang dihasilkan adalah Use Case (yang telah diupdate), dokumen Supplementary dan Glossary (yang telah diupdate), Domain Model (snapshot), UML Activity Diagram (snapshot), UML Class Diagram (snapshot), CRC Card, UML Sequence Diagram (snapshot), Source Code, Code Documentation, Regression Test Suite, Acceptance Test dan Bugs Report.

4) Transition, 

dengan aktivitas menguji sistem (integration sistem dan user testing), mereview kembali sistem aplikasi dan menginstalasi sistem aplikasi. Proses iterasi dapat dilakukan satu hingga dua kali. Artifak yang dihasilkan adalah Dokumen System Requirement Specification, Dokumen System Technical Specification, Panduan Instalasi dan Panduan Pengguna, Dokumen Pelatihan, Regression Test Suite, User Acceptance Test dan Bugs Report (yang sudah final). 

Panduan Agile UP dari Pusilkom UI juga memberikan best practice dalam melakukan setiap aktivitas di setiap fase. Panduan ini juga membedakan artifak dokumen yang dihasilkan, sebagai artifak utama, artifak pendukung dan artifak input dan artifak output. Panduan ini juga memberikan LCO (Lifecycle Obejctive) berupa dokumen dan presentasi dari setiap fase, sebagai target yang harus dicapai sebelum melanjutkan ke fase yang selanjutnya. Untuk kepentingan penulisan paper ini, maka penulis akan membatasi artifak yang akan ditampilkan.

Web Engineering Methodology

Salah satu metodologi pengembangan aplikasi Web adalah dengan menggunakan metode Web Engineering (disingkat WebE). Saya pernah menggunakan metode ini untuk mengembangkan aplikasi berbasis web Official Website Kantor Sinode GMIM.

Berikut cuplikan laporan hasil pengembangan aplikasi ....
Untuk mengembangkan Aplikasi Web Sinode GMIM, akan menggunakan pendekatan RAD dan WebE. Kombinasi kedua pendekatan ini, menghasilkan langkah-langkah pemecahan masalah yang lebih komprehensif.

Langkah-langkah pemecahan masalah tersebut adalah:
1. Fase Analisis Persyaratan
Fase ini memiliki tujuan untuk mengidentifikasi layanan, batasan, dan obyektifitas dari sistem dari pengumpulan data yang dilakukan terhadap stakeholders. Selain itu analisis persyaratan juga bertujuan untuk mendefinisikan persyaratan user dan sistem. Hasil akhir dari analisis persyaratan yaitu spesifikasi awal dari persyaratan user dan sistem. Adapun Fase 1 ini terdiri dari 5 akitivitas  yaitu sebagai berikut:
a. Melakukan Komunikasi dan Perencanaan Proyek
b. Melakukan Studi kelayakan (Teknis, Operasional dan Ekonomi)
c. Melakukan Penjadwalan
d. Menentukan Spesifikasi Pengguna
e. Menentukan Spesifikasi Sistem

2. Fase Analisis Modeling
Tujuan dari fase analisis modeling adalah menganalisis semua kegiatan dalam arsitektur sistem secara keseluruhan dengan melibatkan identifikasi dan deskripsi abstraksi sistem perangkat lunak yang mendasar dan hubungan-hubungannya. Selain itu, analisis modeling juga bertujuan untuk meningkatkan pemahaman terhadap permasalahan tanpa mempertimbangkan solusi teknis. Hasil akhir dari analisis modeling yaitu diagram model logis dari sistem yang sedang berjalan, diantaranya use case diagrams, class diagram, dan sequence diagrams. Aktivitas di fase Analisis Modelling adalah:
a. Mengidentifikasi pelaku bisnis
b. Menganalisis proses dan kinerja sistem
c. Mengidentifikasi struktur obyek dan relasinya

3. Fase Desain Modeling
Tujuan dari fase desain modeling yaitu melakukan perancangan sistem berdasarkan analisis yang telah dilakukan sebelumnya. Tahap analisis dan desain mengalami perulangan hingga diperoleh rancangan sistem yang benar-benar memenuhi kebutuhan. Selain itu, fase 3 ini juga bertujuan untuk memberikan spesifikasi yang jelas dan lengkap kepada programmer dan teknisi. Hasil akhir dari fase ini yaitu basis data, antarmuka, dan spesifikasi desain. Aktivitas Desain Modelling ini adalah:
a. Memodelkan kembali diagram use case untuk  merefleksikan  lingkungan  implementasi
b. Memodelkan interaksi obyek dan behaviours
c. Desain antarmuka
d. Membuat algoritma

4. Fase Konstruksi
Tujuan dari fase konstruksi adalah untuk menunjukkan platform, hardware dan software yang digunakan serta batasan dalam implementasi, serta menguji performansi prototipe perangkat lunak yang telah dibangun agar dapat diketahui apakah prototipe tersebut telah sesuai dengan spesifikasi analisis dan perancangan yang telah diidentifikasi sebelumnya. Hasil akhir dari fase konstruksi adalah platform, hardware dan software yang digunakan, serta daftar batasan implementasi, dan rencana pengujian. Aktivitas pada fase Konstruksi adalah:
a. Mendeskripsikan Lingkungan implementasi
b. Implementasi basis data
c. Melakukan pemrograman
d. Implementasi antarmuka
e. Pengujian; yakni identifikasi tujuan pengujian system, membuat kriteria pengujian system, membuat kasus untuk pengujian, melakukan Pengujian Sistem

Twitter untuk produktivitas pendidikan

Twitter merupakan aplikasi sosial media berbasis Web 2.0. Untuk memahami apa itu Web 2.0, silahkan klik disini. yang mulai "naik daun". Indonesia termasuk negara dengan pengguna twitter cukup banyak. Yang menjadi pertanyaan disini adalah: apakah twitter bisa digunakan dalam dunia pendidikan?

Faktanya sekarang di Indonesia, penetrasi Internet cukup tinggi. Pengguna aplikasi Web 2.0 pun makin banyak. Namun menurut Prof Zaenal Hasibuan, Ph.D, penggunaan TIIK di Indonesia belum mampu meningkatkan produktivitas bangsa. Baca disini datanya!

Ini berarti menjadi tantangan bagi setiap akademisi untuk memulai gerakan pemanfaatan TIK untuk meningkatkan produktivitas. Salah satunya adalah dengan menggunakan twitter sebagai media belajar-mengajar, guna meningkatkan efisiensi dan efektivitas pendidikan, baik di jenjang pendidikan dasar, menengah terlebih pendidikan tinggi!

Jadi, apakah bisa menggunakan twitter untuk meningkatkan produktivitas dalam dunia pendidikan tinggi? Ternyata bisa! Pada kenyataannya, makin banyak komunitas pendidikan yang menggunakan twitter sebagai sarana pembelajaran di kelas. Bahkan untuk kepentingan riset pun, twitter mulai digunakan. 

Untuk panduan menggunakan twitter untuk dunia pendidikan bisa diunduh disini

Berikut adalah panduan Membuat Akun Twitter:
1.    Buka browser internet anda, lalu ketikkan www.twitter.com pada address bar

2.    kalau anda tidak salah dalam menuliskan url halaman twitter maka akan keluar gambar seperti di bawah ini,
 

 3.    Klik pada icon sign up now dan tunggu beberapa saat untuk bisa membuat twitter. jika koneksi internet anda cepat maka tidak akan lama akan keluar halaman seperti gambar di sebelah

 4.    Di bagian full name silahkan isi nama lengkap anda, kemudian di bagian username silahkan isi nama atau apa saja yang di gunakan ketika nanti anda akan login ke twitter. Isi saja misalkan simon_petrus atau maria_magdalena kemudian di bagian password silakan isi dengan kata kunci yang anda inginkan (anda harus selalu ingat) bagian email silahkan isi email anda selanjutnya isi form type the word above silahkan isi sesuai dengan kata yang tampil disitu.

5.    Langkah terakhir yaitu tekan enter atau klik create account

Ta daaa.. anda telah berhasil dalam menjalankan langkah membuat twitter. silahkan cek email anda untuk mengetahui bahwa anda sudah benar-benar sukses mengikuti tutorial membuat twitter ini. Kalau di kotak inbox anda ada email dari twitter berarti anda sudah berhasil mempunyai account twitter. Selamat menikmati berselancar di dunia twitter. Selamat ber-twit yaaaa ...

pengantar UML ...

UML adalah singkatan dari Unified Modeling Language, yaitu suatu notasi pemodelan aplikasi perangkat lunak. Schach[1] menegaskan bahwa UML merupakan bahasa bukan metode. Sebagai bahasa, UML digunakan untuk mendeskripsikan perangkat lunak yang dikembangkan dengan berbagai pradigma pengembangan perangkat lunak dan metodologi. Pendapat Schach[1] didukung oleh Sommerville[2] dan Pressman[3].  

Dennis, Wixom dan Tegarden[4] mendukung pendapat bahwa UML merupakan kumpulan standar pemodelan dengan menggunakan diagram, dimana UML bertujuan untuk menyediakan kosa-kata dari paradigma pengembangan sistem berorientasi obyek guna memodelkan semua tahapan dari daur hidup pengembangan perangkat lunak. Bentley dan Whitten[5], mendukung pemahaman bahwa UML merupakan kumpulan alat pemodelan yang disepakati bersama untuk menjelaskan sistem perangkat lunak. Hal serupa dikemukakan oleh Kendall dan Kendall[6].

Fowler[8] memberikan definisi yang sederhana bahwa UML merupakan kumpulan notasi grafis, yang didukung oleh meta-model tunggal, yang membantu pendeskripsian dan desain sistem perangkat lunak, khususnya sistem yang dibangun menggunakan pemrograman berorientasi obyek. UML merupakan standar yang relatif terbuka yang diatur oleh Object Management Group (OMG), sebuah konsorsium terbuka. OMG berfungsi untuk membuat standar-standar yang mendukung interoperabilitas sistem yang berorientasi objek. Versi terakhir dari UML adalah UML ver 2.0[9].

Menurut Kruchten[10], UML adalah bahasa grafis untuk visualizing, specifying, constructing and documenting setiap artifak dari sistem perangkat lunak.

UML mendukung The 4+1 View Model of Architecture, yakni 

1) The Logical View, 

2) The Implementation View, 

3) The Process View dan 

4) The Deployment View ditambah dengan 

5) The Use Case View.

Lihat Gambar dibawah ini tentang pemetaan UML pada Architecture Model Perangkat Lunak:

Model merupakan representasi lengkap dari sistem perangkat lunak, sedangkan arsitektur merupakan fokus pandangan pada bagian-bagian tertentu dari sistem perangkat lunak. Atau dapat dikatakan arsitektur sistem merupakan cetak-biru aplikasi. Keterhubungan model dan arsitektur sistem perangkat lunak, digambarkan oleh UML.

Tool Yang Mendukung UML
Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool komersial maupun opensource. Beberapa diantaranya adalah:
Rational Rose (www.rational.com)
Together (www.togethersoft.com)
Object Domain (www.objectdomain.com)
Jvision (www.object-insight.com)
Objecteering (www.objecteering.com)
MagicDraw (www.nomagic.com/magicdrawuml)
Visual Object Modeller (www.visualobject.com)
Data seluruh tool yang mendukung UML, lengkap beserta harganya (dalam US dolar) bisa anda pelajari di situs http://www.objectsbydesign.com/tools/umltools_byCompany.html .
Disamping itu, daftar tool UML berikut fungsi dan perbangingan kemampuannya juga dapat dilihat di
http://www.jeckle.de/umltools.htm.


Referensi Site UML
Sebagai referensi dalam mempelajari dan menggunakan UML, situs-situs yang merupakan pointer
penting adalah:
http://www.cetus-links.org/oo_uml.html
http://www.omg.org
http://www.omg.org/technology/uml/
http://www.rational.com/uml
http://www.uml.org/

Tulisan lainnya tentang UML dapat ditemukan disini

Sumber Acuan

[1] Schach, Object Oriented Software Engineering, 8th Ed, McGrawHill, 2008. 

[2] Sommerville, Software Engineering, 8th ed, Pearson Education Limited, 2007

[3] Pressman, Software Engineering, A Practitioner’s Approach, 6th ed, McGrawHill, Singapura, 2005.

[4] Dennis, Wixom and Tegarden, System Analysis and Design with UML, An Object-Oriented Approach, 3dh ed, John Wiley & Sons, International Student Edition, 2010.

[5] Bentley and Whitten, System Analysis and Design for the Global Enterprise, 7th ed, McGrawHill International Edition, 2007.

[6] Kendall and Kendall, System Analysis and Design, 7th ed, Pearson Prentice Hall, 2007.

[7] CMMI Product Team, CMMI® for Development, Version 1.3, Improving processes for developing better products and services, November 2010, TECHNICAL REPORT CMU/SEI-2010-TR-033 , ESC-TR-2010-033, Software Engineering Process Management Program, Unlimited distribution subject to the copyright. http://www.sei.cmu.edu.

[8] Martin Fowler, UML Distilled, A Brief Guide to the Standard Object Modelling Language, 3th ed, Pearson Education, 2004.

[9] www.uml.org., Unified Modelling Language: Superstructure Version 2.0, ptc/03-08-02.

[10] Philippe Kruchten, The Rational Unified Process An Introduction, 3rd ed, Pearson Education, 2004.

draft Analisa dan Perancangan Sistem Informasi e-Direktori Pariwisata

RANCANGAN ANALISA SISTEM

e-Direktori Pariwisata Sulawesi Utara

Perancangan analisa sistem merupakan suatu kegiatan yang berisi proses analisis dan perancangan aplikasi. Tujuan aktivitas ini adalah untuk mengimplementasikan semua objek dan proses dalam tahap analisis menjadi karakteristik yang dikenali computer:

1. Tujuan Sistem

Tujuan utama pembuatan sistem ini adalah sebagai alat bantu bagi wisatawan, dan khususnya pengelola hotel atau kuliner, baik perorangan maupun organisasi.

2. Analisa Kebutuhan Sistem

e-Direktori Pariwisata Sulawesi Utara (SIP) diharapkan dapat memenuhi beberapa kebutuhan yang terkait dengan pemanfaatan potensi pariwisata provinsi Sulawesi Utara. Kemampuan yang dapat diberikan oleh SIP ini berupa:

1. Sebaran lokasi hotel dan kuliner.

2. Informasi atribut hotel dan kuliner

3. Informasi jalur angkot yang melewati lokasi hotel dan kuliner

4. Informasi terkait lainnya

2.1 Analisa Perangkat Lunak

Pada perancangan sistem informasi Posisi ini, perangkat lunak yang digunakan adalah Macromedia DreamWeaver, PHP dan mySQL. Pemilihan perangkat lunak dan bahasa pemrograman ini didasarkan pada kemampuan perangkat lunak tersebut yang dapat mengolah data berupa peta dan menampilkan informasi dan tampilan yang lebih bagus dibanding dengan perangkat lunak lainnya.

2.2 Analisa Perangkat Keras

Agar dapat berjalan dengan baik maka dibutuhkan harddisk yang berkapasitas minimal 5 GB, processor minimal 800MHZ (Intel maupun AMD), memory minimal 64 MB dan VGA minimal 32 MB. Implementasi SIP ini sangat membutuhkan perangkat keras yang cukup tinggi, dengan kata lain dibutuhkan spesifikasi computer yang cukup tinggi. Hal ini dikarenakan data yang diakses dan yang disimpan tidak hanya dalam bentuk data tabular melainkan adanya data Posisi yang memiliki kapasitas data yang besar untuk menampilkan informasi dan tampilan secara interaktif. Jika spesifikasi perangkat keras yang digunakan tidak memenuhi persyaratan minimal, proses masih dapat berjalan namun dengan kinerja yang cukup lambat.

2.3 Spesifikasi Masukan Sistem

Masukan sistem terdiri dari data – data:

1. Data spasial hotel.

2. Data spasial kuliner.

3. Data angkutan

4. Informasi hotel, kuliner dan angkutan

5. Pencarian.

2.4 Spesifikasi Keluaran Sistem

Hasil sistem berupa:

1. Visualisasi lokasi hotel

2. Visualisasi lokasi kuliner

3. Visualisasi angkutan.

4. Analisa Bersyarat (query).

3. Analisa Pengolahan Data

Proses analisis pengolahan data terdiri dari: visualisasi, pengolahan data (input, edit, update dan delete), cari informasi dan tampilkan informasi.

3.1 Analisa Data Spasial

Analisis menggunakan data spasial yang tediri dari peta jalan, peta hotel, peta kuliner. Skala peta yang digunakan adalah 1:20.000, dengan kedalaman inforamsi pada indentifikasi jalan, luas area kecamatan dan jumlah hotel dan kuliner. Data spasial digunakan sebagai alat bantu pengambilan keputusan melalui hasil visualisasi.

3.2 Analisa Data Non Spasial

Data non spasial disebut juga sebagai atribut dari data spasial. Fungsinya adalah membangun database untuk analisa atau pengolahan data, sehingga dapat memberikan informasi yang dibutuhkan. Data non spasial yang dibutuhkan untuk analisa adalah masing – masing atribut pada data spasial, misalnya atribut jalan, atribut hotel dan atribut kuliner.

3.3 Proses Manage Data

Merupakan proses manage data – data teknis dari gambaran tentang perhotelan dan kuliner provinsi Sulawesi Utara yanga da. Manage data dilakukan untuk menjaga keakuratan data, terutama untuk data yng terus berubah. Proses manage data hanya bisa dilakukan oleh administrator (user tidak diberikan fasilitas ini) atau dengan membuat table dan field baru apabila ada jenis informasi yang diinginkan.

3.4 Penentuan Sebaran Hotel dan Kuliner

Penentuan sebaran hotel dan kuliner dengan cara memilih hotel atau kuliner tertentu yang berbeda dalam suatu theme untuk ditampilkan informasinya secara sendiri.

3.5 Pencarian Hotel dan Kuliner

Proses pencarian hotel dan kuliner dengan cara memilih layer tertentu dan mengaktifkan theme lain yang kemudian dikoneksikan dengan area berdasarkan atribut yang dipilih.

3.6 Analisa Bersyarat

Analisa bersyarat merupakan proses pencarian informasi berdasarkan field – field atribut pada suatu theme. Proses ini dilakukan dengan memilih informasi yang ditampilkan berdasarkan field yang diinginkan.

3.7 Visualisasi

Proses visualisasi ini merupakan ciri khas yang membedakan sistem informasi Posisi dengan sistem informasi lainnya. Dalam visualisasi ini, tampilan yang disajikan dapat dipilih layer mana saja yang diinginkan untuk divisualisasikan, yaitu dengan fasilitas layer control.

3.8 Cari Informasi

Proses ini dilakukan melalui fasilitas query yang terdiri dari find. Didalamnya diinputkan informasi apa yang akan dicari. Tabel beserta fieldnya. Khususnya untuk find, hasilnya dapat langsung ditunjukan di map-nya dalam bentuk symbol. 

3.9 Tampilkan Informasi

Proses menampilkan informasi ini dilakukan dalam bentuk tampilan legend, info tool dan grafik.

4. Kekuatan dan Kelemahan Sistem

4.1 Kekuatan Sistem

Kekuatan sistem yang dihasilkan dapat dilihat dari berbagai aspek, yaitu implementasi, user interface, tampilan, aplikasi, program dan buku petunjuk pengguna.

1) Implementasi

a. Perangkat lunak yang digunakan dapat bertukar data dengan basis data yang dimiliki sehingga memudahkan dalam implementasi sistem.

b. Memiliki banyak fasilitas yang dapat digunakan.

c. Memudahkan dalam analisa untuk perancangan.

2) User Interface

a. Tersedia informasi langsung dalam tiap proses, sehingga mudah dalam memahami proses

b. Tersedianya button, tools dan menu yang lengkap dan praktis untuk pengolahan data membuat aplikasi lebih mudah.

3) Tampilan

a. Penampilan symbol dan warna pada setiap layer peta membuat tampilan lebih menarik dan interaktif.

b. Tool dan button yang disediakan dengan tampilan yang unik, sederhana sehingga mudah dipahami.

c. Dilengkapi dengan design yang menarik.

d. Terlihat info tool, legenda yang terpisah membuat tampilan penyajian data lebih mudah untuk dilihat dan tidak membingungkan.

4.2 Kelemahan Sistem

Menu – menu yang ada sangatlah terbatas karena memang dirancang agar menunya praktis dan mudah dipahami oleh user/pengguna.

5. Analisa Orientasi Pemakai

Pemakai sistem dibagi ke dalam dua kelompok, yaitu:

1. Pemakai umum (atau user)

Pemakai umum dapat mengakses fungsi – fungsi analisa Posisi (aplikasi).

2. Administrator (admin) aplikasi

Administrator SIP berhak mengakses semua fungsi di dalam sistem, termasuk pengelolaan data dan penggunaan password.

Untuk diagram Perancangan bisa diunduh disini

Model Proses Daur Hidup SOftware

Model proses daur hidup perangkat lunak, dikemukakan oleh Schach[1], merupakan tahapan pengembangan perangkat lunak ideal. Model ini menganggap perangkat lunak sebagai produk yang dihasilkan dalam urutan tahapan tertentu secara ideal. Tahapan berurutan tersebut adalah: 

1) Memulai dari scratch (yakni memulai dari tidak ada); 

2) Tahap pendefinisian requirements (atau kebutuhan); 

3) Tahap Analysis; 

4) Tahap Perancangan; 

5) Tahap Implementasi.

Ian Sommerville[2] mengemukan empat tahapan fundamental dalam model proses perangkat lunak, yakni; 

1) Software specification (proses pendefinisian kebutuhan perangkat lunak); 

2) Software design and implementation (mengembangkan perangkat lunak yang sesuai dengan persyaratan user); 

3) Software validation (perangkat lunak yang dihasilkan harus disesuaikan kembali menurut keinginan user);

4) Software evolution (perangkat lunak dikembangkan terus untuk memenuhi kebutuhan user yang bertambah).

Roger Pressman[3] mengusulkan suatu generic process framework perangkat lunak, dengan tahapan sebagai berikut: 

1) Komunikasi; 

2) Perencanaan; 

3) Pemodelan; 

4) Konstruksi; 

5) Implementasi.

Dennis, Wixom dan Tegarden[4] mengemukakan model proses yang disebut System Development Life Cycle (disingkat SDLC) dengan tahapan berikut: 

1) Perencanaan, 

2) Analisis, 

3) Perancangan, 

4) Impelementasi.

Tahapan ini serupa dengan yang dikemukakan oleh Bentley dan Whitten[5], yakni: 

1) System Initiation; 

2) System Analysis; 

3) System Design dan 

4) System Implementation.

Sedangkan Kendall dan Kendall mengusulkan 7 (tujuh) tahapan dalam SDLC, yakni: 

1) Identifikasi permasalahan, kesempatan dan tujuan; 

2) Penentuan persyaratan informasi pengguna; 

3) Analisa kebutuhan sistem; 

4) Perancangan sistem yang telah direkomendasi; 

5) Pengembangan dan dokumentasi perangkat lunak; 

6) Menguji sistem; 

7) Implementasi dan Evaluasi sistem.

Terkait dengan model proses perangkat lunak, maka Software Engineering Institute – Carnegie Mellon (SEI)[7] mengeluarkan framework Standar Ukuran Kematangan yang disebut CMMI for Development (CMMI – DEV). Model CMMI® (Capability Maturity Model® Integration) merupakan kumpulan best practices yang membantu setiap organisasi untuk mengembangkan proses pengembangan perangkat lunak. Model ini dikembangkan dari kalangan industry, pemerintahan dan akademisi pada SEI. Model proses yang disebut CMMI-DEV, menyediakan kumpulan panduan lengkap terkait pengembangan layanan dan produk perangkat lunak.

Menurut Schach[1], model daur hidup perangkat lunak, secara ideal berbeda dengan praktek dikarenakan dua hal:

1) praktisi perangkat lunak adalah manusia, sehingga cenderung untuk membuat kesalahan; 

2) kebutuhan pengguna cenderung mengalami perubahan saat perangkat lunak sementara dikembangkan.

Dari pemaparan tersebut diatas, kita dapat memgetahui bahwa proses pengembangan perangkat lunak ataupun sistem informasi itu mengikuti suatu alur yang berurutan (memiliki nilai logis tertentu). Alur berurutan ini merupakan "best practices"dari berbagai pengalaman para pengembang dalam membangun aplikasi dan sistem informasi. Tujuan utama model proses adalah untuk managing software dengan lebih baik. Managing software dengan lebih baik dipahami sebagai meminimalkan resiko pengembangan software itu sendiri.

Sumber Acuan

[1] Schach, Object Oriented Software Engineering, 8th Ed, McGrawHill, 2008. 

[2] Sommerville, Software Engineering, 8th ed, Pearson Education Limited, 2007

[3] Pressman, Software Engineering, A Practitioner’s Approach, 6th ed, McGrawHill, Singapura, 2005.

[4] Dennis, Wixom and Tegarden, System Analysis and Design with UML, An Object-Oriented Approach, 3dh ed, John Wiley & Sons, International Student Edition, 2010.

[5] Bentley and Whitten, System Analysis and Design for the Global Enterprise, 7th ed, McGrawHill International Edition, 2007.

[6] Kendall and Kendall, System Analysis and Design, 7th ed, Pearson Prentice Hall, 2007.

[7] CMMI Product Team, CMMI® for Development, Version 1.3, Improving processes for developing better products and services, November 2010, TECHNICAL REPORT CMU/SEI-2010-TR-033 , ESC-TR-2010-033, Software Engineering Process Management Program, Unlimited distribution subject to the copyright. http://www.sei.cmu.edu.

Teknik Menyaring Informasi Relevan

Information Overload adalah terminology yang semakin sering disuarakan para pakar Teknologi Informasi.Tren information overload makin menjadi jadi. Sedemikian banyaknya kuantitas informasi yang terdapat di internet menyebabkan terjadinya fenomena “information overloaded” (banjir informasi yang tak terkendali).Tengoklah bagaimana seseorang yang ingin mencari informasi dengan kata kunci “toyota” akan terlihat bingung karena hasil pencarian menunjukkan adanya jutaan situs yang berkaitan dengan kata tersebut. 

Berawal dari Aflin Toffler (www.en.wikipedia.org/wiki/Alvin_Toffler) di tahun 1970 dalam bukunya Future Shock (www.en.wikipedia.org/wiki/Future_Shock), yang menuliskan:

The dizzying disorientation brought on by the premature arrival of the future. It may well be the most important disease of tomorrow.

Toffler selanjutnya menjelaskan ... 

I think there’s a tremendous undercurrent of dissatisfaction in America; people saying I want out, it’s moving too fast, it’s moving away from me; a sense of panic; a sense that things are slipping out of control and I don’t think that there’s much we can do in our personal lives to counteract that ...

(kutipandariwww.bbc.com/future/story/20120306-information-overload-fears)

Keilmuan Teknologi Informasi sendiri biasanya membedakan apa yang dimaksud dengan “browsing”, “searching”dan“surfing”. Surfing diartikan sebagai tindakan berselancar di dunia maya, yakni berpindah (atau melompat) dari satu halaman web kehalaman web lain. Searching diartikan sebagai tindakan mencari di dunia maya, yakni mencari data/informasi dengan menggunakan mesin pencari seperti Google.Sedangkan browsing diartikan sebagai tindakan menelusuri dunia maya, yakni melakukan penelusuran data atau informasi berdasarkan “kategori” tertentu, seperti misalnya dengan menggunakan mesin pencari blekko. Klasifikasi ini sebenarnya ditujukan untuk MEMBEDAKAN setiap aktivitas dunia maya yang kita lakukan.

Tentu saja harus ada teknik yang dipergunakan untuk dapat mencari informasi yang relevan dengan yang dimaksud. Ada dua teknik dasar yang biasa dipergunakan, yaitu dengan menggunakan simbol-simbol matematika dan menggunakan symbol Boolean (yang akan diterangkan di bagian lain)

Berikut adalah beberapa teknik menyaring informasi dengan menggunakan symbol matematika.

1. Filterisasi dengan Simbol Matematika PLUS

Simbol pertama yang sangat berguna untuk dipakai adalah tanda plus (+).Tanda plus dipergunakan jika seorang user ingin mencari berbagai dokumen dengan kata kunci lebih dari satu. Contohnya adalah seorang guru yang ingin mencari informasi mengenai profil penduduk di kota Manado, maka yang bersangkutan dapat mencarinya dengan menggunakan kata kunci:

+profil +penduduk +manado

Yang dilakukan oleh mesin pencari jika menemukan format semacam ini adalah mencari berbagai sumber dokumen maupun artikel yang ada di seluruh internet dimana di dalamnya terdapat kata “profil”, “penduduk”, dan “manado”. Dari hasil pencarian melalui search engine Google terlihat bagaimana hasil pencarian terlihat lebih fokus menuju apa yang diinginkan. Cara mencari seperti ini tentu saja jauh lebih efektif dibandingkan dengan hanya menggunakan kata “manado” atau “profil” saja yang dapat menampilkan jutaan situs sebagai hasilnya. Simbol “+” ini dapat dipergunakan sebanyak-banyaknya, karena prinsip yang kerap dipergunakan dalam melakukan searching adalah bahwa semakin spesifik yang dicari (semakin banyak menggunakan tanda “+”) akan semakin baik, karena search engine akan lebih fokus melakukan pencarian.

2. Filterisasi dengan Simbol Matematika MINUS

Simbol lainnya yang sering dipergunakan mendampingi “+” adalah simbol minus (-). Untuk mudahnya, simbol tersebut dapat dibaca sebagai “kecuali”. Contoh penggunaannya adalah sebagai berikut. Misalnya seorang pelajar ingin mencari beasiswa untuk melanjutkan studi master di luar negeri, namun yang bersangkutan tidak mau pergi ke Singapur maupun Inggris; maka yang bersangkutan dapat melakukan pencarian dengan cara sebagai berikut:

+master +degree +scholarship +abroad –singapore–inggris

Dengan format di atas maka mesin pencari yang bersangkutan akan mencari di internet seluruh dokumen yang mengandung teks “master”, “degree”, “scholarship”, dan “abroad” namun tidak terdapat kata “Singapore” maupun “Inggris” di dalamnya.

3. Filterisasi dengan Simbol TANDA KUTIP

Satu simbol lagi yang kerap dipakai mendampingi plus dan minus adalah simbol multiplikasi yang direpresentasikan dengan tanda kutip (“). Simbol ini dapat membantu user untuk semakin memperkecil atau memfokuskan pencarian ke hal yang benar-benar diinginkan.Yang dilakukan oleh tanda kutip adalah memerintahkan mesin pencari untuk mencari dokumen atau informasi yang mengandung teks persis seperti yang ada di dalam tanda kutip terkait. Perhatikanlah contoh searching key sebagai berikut:

“sulawesi utara”

Berdasarkan perintah tersebut, mesin pencari akan mencari seluruh dokumen di internet yang mengandung frase “sulawesi utara”. Jika sebuah dokumen hanya mengandung kata “sulawesi” atau “utara” saja, maka dokumen tersebut tidak akan ditampilkan. Walaupun terlihat sederhana, tanda kutip ini sebenarnya sangat ampuh jika dipergunakan dengan benar. Contohnya adalah seorang instruktur yang ingin mengetahui definisi dari internet. Daripada menggunakan searching key:

+definisi +jaringan +komputer

yang akan menghasilkan cukup banyak temuan, maka yang bersangkutan lebih baik menggunakan simbol tanda kutip sebagai berikut:

“definisi jaringan komputer”

Tanda kutip ini sering kali membuat orang terkesima karena tanpa disangka biasanya hal-hal yang nampaknya teramat sangat spesifik ternyata dapat ditemukan di internet.

Kesimpulan:

Ketiga simbol matematika tersebut jika digabungkan akan menjadi sebuah alat pencari yang ampuh.

Pengukuran Software: Metrik berorientasi Ukuran dan berorientasi Fungsi

Pengukuran merupakan bagian dari dunia keteknikan. Kegiatan mengukur, dasarnya adalah membandingkan sesuatu dengan sesuatu yang lain yang dianggap sebagai patokan atau standard. Jadi kegiatan mengukur sebenarnya adalah untuk mendapat perbandingan, sehingga acuan perbandingan tersebut dapat dikelola. Paradigma ini sesuai dengan apa yang Lord Kelvin katakan:

what we cannot measure, we cannot manage.
 

Dalam keilmuan software engineering, kegiatan mengukur menjadi lebih sulit dari biasanya. Permasalahan yang ditemui adalah kesulitan dalam menetapkan nilai dari obyek yang diukur dan sulitnya menetapkan parameter-parameter yang bisa diukur. Karena secara praktis, mengukur perangkat lunak, adalah mengukur sesuatu yang sepertinya “tidak kelihatan”.
 

Pengukuran perangkat lunak dapat dipisahkan dalam dua kategori, yaitu pengukuran langsung dan pengukuran tidak langsung. Pengukuran langsung dalam proses rekayasa perangkat lunak berhubungan dengan biaya dan sumber daya yang diperlukan, misalnya: pengukuran jumlah baris kode, kecepatan eksekusi, ukuran memori, dan kesalahan yang ditemui dalam suatu periode waktu. Pengukuran tidak langsung dari suatu produk berhubungan dengan fungsionalitas, kualitas, kompleksitas, efisiensi, reliabilitas,  dan lain sebagainya. Pengukuran secara langsung lebih mudah dilakukan, karena hasil dapat diperoleh secara langsung, sedangkan pengukuran tidak langsung lebih sulit dilakukan, karena harus melalui proses yang lebih kompleks.
 

Berikut adalah beberapa contoh metric perangkat lunak
1) Metrik Berorientasi Ukuran
Metrik beorientasi ukuran diperoleh dengan cara melakukan normalisasi ukuran kualitas dan produktivitas dengan menghitung ukuran dari perangkat lunak yang dibuat. Ukuran yang biasanya dijadikan sebagai acuan normalisasi adalah LOC (lines of code). Dari pengukuran jumlah LOC pada suatu perangkat lunak, dapat diperoleh:
1.  Kesalahan per KLOC (ribuan LOC)
2.  Kekurangan atau cacat pada spesifikasi per KLOC
3.  Harga per LOC
4.  Jumlah halaman dokumentasi per LOC
Selain itu, beberapa metrik yang bisa dihitung adalah:
1.  Kesalahan per orang-bulan
2.  LOC per orang-bulan
3.  Harga per halaman dokumentasi
Menurut Jones [1986], metrik berorientasi ukuran tidak dapat diterima secara universal sebagai cara terbaik untuk mengukur proses rekayasa perangkat lunak. Alasan yang dikemukakan adalah kadang-kadang fungsionalitas program dapat dicapai dengan baris program yang lebih sedikit. Selain itu, untuk melakukan estimasi LOC harus digunakan analisis desain tingkat tinggi.
 

2) Metrik Berorientasi Fungsi
Metrik berorientasi fungsi menggunakan ukuran fungsionalitas yang dihasilkan oleh aplikasi sebagai nilai normalisasi. Fungsionalitas tidak dapat diukur secara langsung, sehingga untuk memperolehnya digunakan pengukuran langsung terlebih dahulu, lalu hasil pengukuran langsung tersebut digunakan sebagai masukan. Metrik berorientasi fungsi pertama kali diusulkan oleh Albrecth [1979], yang menyarankan pengukuran yang disebut  function point (FP). FP diperoleh dengan menggunakan hubungan empiris berdasarkan pengukuran langsung dan estimasi terhadap kompleksitas perangkat lunak.
Terdapat lima karakteristik yang digunakan sebagai acuan, yaitu:
1.  Jumlah masukan (user inputs)
2.  Jumlah keluaran (user outputs)
3.  Jumlah permintaan (inquiry)
4.  Jumlah berkas
5.  Jumlah antarmuka eksternal
 

Jumlah-jumlah tersebut dikalikan dengan faktor pemberat, sesuai dengan kompleksitas (sederhana, sedang, kompleks) dari tiap karakteristik acuan. Untuk mengukurnya, digunakan persamaan:
FP = jumlah total x [0.65 + 0.01 x Σ (Fi)]   
Fi (i = 1 sampai dengan 14) merupakan nilai peubah kompleksitas
 

Berdasarkan pertanyaan-pertanyaan yang  diusulkan oleh Arthur [1985], dengan
skala 0 (tidak penting) sampai dengan 5 (sangat penting):
1.  Apakah sistem memerlukan backup dan recovery?
2.  Apakah komunikasi data diperlukan?
3.  Apakah terdapat fungsi pemrosesan terdistribusi?
4.  Apakah performa sangat penting?
5.  Apakah sistem akan berjalan pada lingkungan operasional yang berat?   14
6.  Apakah sistem memerlukan data entri secara online?
7.  Apakah data entri online memerlukan transaksi masukan untuk membuat
operasi dengan ‘banyak layar’?
8.  Apakah berkas aplikasi (master) diambil secara online?
9.  Apakah masukan, keluaran, berkas, atau permintaan bersifat kompleks?
10. Apakah pemrosesan internal bersifat kompleks?
11. Apakah kode yang dibuat dapat dipakai ulang?
12. Apakah konversi dan instalasi termasuk di dalam desain?
13. Apakah sistem didesain untuk instalasi lebih dari satu dalam organisasi
yang berbeda?
14. Apakah aplikasi didesain untuk memfasilitasi perubahan dan mudah
digunakan oleh pengguna?
 

Setelah FP dihitung, dapat digunakan metode yang serupa dengan LOC untuk melakukan normalisasi ukuran pada produktivitas, kualitas, dan atribut-atribut lainnya.