UAS RPLL - PERMASALAHAN & STUDI KASUS 2

Dalam suatu proyek yang berhubungan dengan sistem informasi, pasti melibatkan suatu proses pengambilan keputusan, dimana ada seorang manajer yang harus membuat keputusan yang paling sesuai dengan kondisi proyeknya saat itu. Studi kasus ini mengangkat topik mengenai lima proses pengambilan keputusan beserta dengan permodelan yang dapat digunakan untuk proses pengambilan keputusan mana yang terbaik untuk kasus yang sedang dialami oleh seorang manajer. Untuk lebih memperjelas mengenai permodelan proses pengambilan keputusan ini, studi kasus ini memberikan suatu contoh kasus :

” Mr.X selaku manajer sebuah software project yang mengalami masalah dengan deadline project-nya, dan masalah-masalah lain, untuk itu manajer tersebut harus mengambil suatu keputusan agar dapat menyelesaikan software projectnya dengan baik dan sesuai jadwal.

Mr.X sedang mengalami berbagai permasalahan, yaitu project’s budget dipotong 10%, top programmer dalam project akan dipindahkan dan diganti dengan orang lain, dan permasalahan yang terakhir adalah laporan tahap pertama tidak sesuai dengan keinginan user (manajer marketing). ”

Jika dianalisa, permasalahan pertama dan kedua merupakan masalah yang berhubungan dengan orang (people problem), yang menyebabkan pembagian tugas dalam project tersebut harus ditata ulang dan seluruh pekerja dalam tim harus ekstra kerja keras agar project dapat selesai tepat waktu dengan anggaran kecil. Sedangkan untuk menyelesaikan permasalahan yang ketiga, Mr.X harus lebih melibatkan manajer marketing dalam proses pembuatan software.

Proses Pengambilan Keputusan
Menurut Vroom & Yetton ada lima cara proses pengambilan keputusan:

1. Authorian-I (A I)
menyelesaikan masalah yang terjadi dengan sendiri tanpa melakukan diskusi dengan anggota kelompok lain.

2. Authorian-II (A II)
mencari informasi untuk menyelesaikan masalah.

3. Consultative-I (C I)
konsultasi dengan orang lain untuk menyelesaikan masalah

4. Consultative-II (C II)
konsultasi dengan kelompok, hal ini lebih ditekankan pada diskusi dengan kelompok.

5. Group Participation (GP)
diselesaikan dengan melibatkan seluruh anggota proyek dan ditekankan pada diskusi besar dengan seluruh anggota proyek.

Dalam tahap pengambilan keputusan dengan menggunakan model Vroom-Yetton ini, langkah pertama yang harus dilakukan seorang manajer proyek adalah menjawab sejumlah pertanyaan sebagai berikut:
1. Apakah terdapat requirement khusus
2. Apakah informasi yang saya miliki sudah cukup untuk membuat keputusan
3. Apakah problem yang ada sudah terstruktur
4. Apakah keputusan tersebut akan diterima secara kritis oleh tim proyek
5. Apakah keputusan saya akan diterima oleh tim proyek
6. Apakah anggota tim proyek saling berbagi tujuan organisasi
7. Apakah konflik yang ada dapat diselesikan dengan keputusan tsb
8. Apakah anggota tim proyek memiliki cukup informasi untuk membuat keputusan
9. Proses keputusan yang memungkinkan
10. Pilihan (kriteria untuk pilihan)

Semua pertanyaan-pertanyaan diatas kemudian dipetakan pada sebuah tree sebagai berikut:

Keterangan huruf abjad A sampai dengan H menunjukkan pertanyaan-pertanyaan yang sebelumnya telah dijelaskan. Ketika seorang manajer proyek menjawab pertanyaan-pertanyaan tersebut, pada akhirnya ia akan bertemu dengan node akhir (pada gambar diatas node terakhir ditandai dengan angka 1 sampai dengan 17). Node akhir ini menunjukkan kandidat keputusan yang dapat diambil seorang manajer proyek. Penjelasan dari tiap node tersebut adalah sebagai berikut:

1. A I, A II, C I, C II
2. GP

3. A I, A II, C I, C II, GP

4. A I, A II, C I, C II, GP

5. A I, A II, C I, C II

6. GP

7. GP

8. C II
9. C I, C II

10. A II, C I, C II

11. A II, C I, C II, GP

12. A II, C I, CII, GP

13. C II
14. C II, GP
15. C II, GP
16. GP
17. GP
18. C II

Pada kasus Mr. X untuk menanggulangi penyusunan ulang pembagian tugas kerja, Mr.X memperoleh alternatif nomor 15 yaitu model pengambilan keputusan CII atau GP, dimana Mr.X harus memilih keputusan mana yang lebih cocok untuk diterapkan dalam menaggulangi masalah yang ada. Pada akhirnya Mr. X memilih pengambilan keputusan dengan cara CII dimana pengambilan keputusan dilakukan dengan cara mengkonsultasikan masalah yang ada dengan kelompok. Alasan mengapa CII dipilih adalah karena penerapan CII membutuhkan waktu yang lebih singkat daripada GP.

Kesimpulan dari studi kasus ini menyatakan bahwa seorang manajer harus memiliki kemampuan untuk memilah isu yang ada dalam proyeknya dan membuat keputusan yang sesuai dengan keadaan serta efektiv untuk diimplementasikan pada isu yang bersesuaian. Model Vroom-Yetton menyediakan sistematik yang cocok digunakan oleh manajer untuk memperkirakan masalah yang dihadapi serta keputusan apa yang paling efektif untuk mengatasinya. Model ini juga lebih menekankan manajer untuk lebih konsentrasi pada masalah yang ada dan membatu manajer untuk memilih keputusan yang terbaik.

UAS RPLL - PERMASALAHAN & STUDI KASUS 1

PERMASALAHAN & STUDI KASUS 1 - TESTING

Permasalahan yang sering timbul dalam suatu proses pengembangan adalah :
* perilaku dari programmer yang bisa jadi cukup menjengkelkan manajemen, yaitu programmer tidak melakukan pengujian dengan baik dan benar. Terkadang programmer hanya memperbaiki program, kemudian melakukan kompilasi. Jika kompilasi sudah tanpa kesalahan, programmer menganggap bahwa program telah benar.

* spesifikasi program dari perancang aplikasi tidak selalu disertai dengan kasus uji, sehingga sering kali pengujian dilakukan oleh programmer tidak seperti yang diharapkan. Jadi ala kadarnya.


SOLUSI

Persiapan Pengujian Software
Pengujian software (software testing) membutuhkan persiapan, sebelum pengujian dilakukan. Mengapa? Karena proses testing harus dilakukan secara sistematis, tidak bisa secara sembarang, karena software yang dihasilkan harus bebas dari error, untuk mengurangi resiko kerugian yang akan diderita oleh penggunanya. Produk software harus menguntungkan penggunanya pada saat digunakan.

Berikut persiapan yang dapat dilakukan untuk dapat melakukan proses testing:
1. membuat checklist
a. list yang akan ditest
b. list requirement
c. list rancangan
d. list spesifikasi
e. list manual, jika sudah ada - biasanya diperlukan untuk pengujian oleh user

2. pembuatan test case
a. merupakan elemen dasar yang harus ditesting
b. merupakan list yang independent

3. pembuatan grup test case
a. kumpulan dari beberapa test case
b. merupakan list yang akan memiliki status hasil test

4. pembuatan modul test
a. pembuatan skenario testing
b. terdiri atas beberapa grup test case
c. diasosiasikan dengan fungsionalitas modul
d. mengacu kepada dokumen requirement dan desain/spec program
5. pembuatan package testing
6. pembuatan produk test

Dengan dimilikinya checklist, kita akan dapat mengetahui progress dari kegiatan testing itu sendiri. Mana yang sudah selesai dilakukan test, mana yang belum. Mana yang sudah dilakukan test pun, bisa diketahui mana yang benar modulnya sudah selesai, dan mana yang belum selesai. Jadi tidak sekedar mengetahui mana yang sudah dan mana yang belum.
Pekerjaan persiapan juga membutuhkan software yang dapat membantu proses persiapan testing ini. Yang paling sederhana adalah dengan menggunakan Excel, jika memungkin menggunakan aplikasi yang dirancang khusus. Produk yang open source adalah TestLink.

Software Tester
Profesi software tester (penguji software ) merupakan kelompok profesi yang dapat dikatakan masih baru di dalam dunia software; walaupun sebenarnya dalam dunia nyata pengembangan software, pekerjaannya ada dan sudah dilakukan, tetapi masih belum dipisahkan secara khusus. Umumnya melekat kepada pemrogram untuk melakukan pengujian software.

Software tester dalam pengertian umum adalah orang yang melakukan proses pengujian software. Software yang diuji, bisa software yang sedang dikembangkan, bisa juga software yang sudah jadi, yang dijual di toko (pasar).

Profesi ini dulu masih dipandang sebelah mata, sering diabaikan, bahkan tidak pernah dilakukan oleh pengembang software.

Tetapi dengan semakin meningkatnya kompleksitas sistem yang dikembangkan, dan tuntutan akan mutu dan layanan, maka profesi ini menjadi sangat penting dan harus ada. Software tester dapat dipandang sebagai pengguna software; yang akan melakukan pengujian software secara menyeluruh, dari proses instalasi sampai dengan penggunaannya, dengan semua menu/fasilitas software dicoba semua.

Sangatlah ironi, saat ini, jika suatu perusahaan pengembang software belum memiliki orang atau tim khusus untuk menjadi software tester. Perusahaan pengembang software tidak boleh mengandalkan pemrogramnya untuk melakukan pengujian software yang dikembangkan oleh pemrogram itu sendiri. Mengapa? Karena hasil pengujian oleh pemrogram itu sendiri, bisa jadi tidak akan objektif. Sudut pandang pengujian pemrogram dalam menguji software akan berbeda dengan sudut pandang penguji sebagai pengguna.

Software tester, jika memungkinkan, per orangan atau tim yang berposisi sebagai pihak ketiga. Mengapa? Pihak ketiga diharapkan lebih netral, tidak memiliki konflik of interest, sehingga bisa lebih objektif.

Siapa saja yang bisa software tester?
Tidak ada ketentuan baku, tentang siapa yang bisa menjadi software tester, karena berhubungan dengan tahap pengembangan dari software yang sedang dikembangkan. Jika software masih dalam tahap pengembangan, maka tester haruslah orang yang memahami proses bisnis yang akan dibantu proses kerjanya dan orang yang memiliki penguasaan terhadap teknologinya. Jika sudah selesai dan akan dioperasionalkan, maka tester bisa penggunanya.

Pelatihan formal tentang proses pengujian sebaiknya harus dibekalkan kepada setiap software tester. Mengapa? Tentu saja agar tester memiliki pengetahuan dasar tentang bagaimana melakukan proses pengujian software yang benar.

Proses pengujian haruslah sistematis, dan jika mungkin dibantu dengan menggunakan software, yang bisa membantu dalam proses pengujian. Proses pengujian tidak harus dilakukan secara manual, tetapi juga harus bisa dilakukan dengan diotomatisasi.
Proses pengujian software dapat dibedakan menjadi:
1. pengujian manual (manual testing)
2. pengujian diotomatisasi (automated testing)
3. gabungan manual dan otomatis

Pengujian manual merupakan pengujian yang umum dilakukan oleh banyak tester. Proses pengujian manual membutuhkan suatu prosedur baku, ketekunan, dan ketelitian dari orang yang berperan sebagai penguji (tester). Mengapa? Karena proses pengujian merupakan proses yang berulang, dan bisa jadi sangat menjemukan.

Pengujian yang diotomatisasi merupakan proses pengujian yang menggunakan alat bantu, dalam hal ini software untuk pengujian (testing software). Proses pengujian dirancang agar dapat dilakukan oleh software. Kita bisa membuat program dengan software untuk pengujian, agar proses pengujian dapat dilakukan secara otomatis. Software pengujian sangat diperlukan untuk membantu proses pengujian yang sifatnya berulang dan banyak sekali.

Gabungan antara manual dan otomatis, merupakan proses pengujian yang ideal, karena tetap saja bahwa proses pengujian membutuhkan keputusan manusia sebagai penguji. Banyak pertimbangan dalam proses pengujian tidak bisa dimasukkan ke dalam software untuk pengujian yang diotomatisasi.

Perekaman Proses Pengujian Software
Suatu proses pengujian software (software testing process) memerlukan software yang bisa membantu proses pengujian.

Proses pengujian yang umum dilakukan adalah dengan menjalankan software aplikasi yang telah selesai dibuat oleh pemrogram. Kemudian aplikasi dicoba dari awal sampai dengan akhir dengan menggunakan langkah (skenario) dan data yang telah disiapkan.

Secara mudah dan sederhana, suatu aplikasi akan dianggap telah lulus pengujian, apabila setelah dicoba, aplikasi dapat merekam dan memproses data yang dimasukkan, kemudian menghasilakan keluaran sesuai dengan yang diharapkan, tanpa ada kesalahan sedikitpun.

Pengujian software tidak dilakukan oleh pemrogram saja, tetapi juga harus melibatkan pihak ketiga, pihak yang independent, yang akan memberikan justifikasi bahwa software aplikasi yang dibuat telah lulus dari pengujian.

Permasalahan yang sering timbul apabila hasil dari proses pengujian yang masih bermasalah, dalam artian bahwa software aplikasi belum lulus uji, adalah bagaimana menunjukkan di mana letak kesalahan yang menyebabkan software belum lulus uji.

Pada proses pengujian yang masih konvensional, manual, tanpa ada bantuan software pendukung untuk pengujian, penguji melaporkan hasil pengujiannya dengan menggunakan laporan secara lisan. Akibatnya adalah bahwa seringkali laporan kesalahan tersebut tidak dapat tersampaikan dengan baik, atau bahkan sering kali terlewatkan atau terlupakan sebagai bagian pekerjaan programmer yang harus memperbaikinya.

Pada tingkatan berikutnya, tester telah melakukan pengujian dengan memberikan laporan secara tertulis deskriptif. Pemrogram dapat menggunakan laporan ini untuk bekerja memperbaiki program, sehingga pemrogram bisa memiliki daftar modul yang harus diperbaiki. Pemrogram bisa memeriksa mana saja yang sudah dan mana yang belum diperbaiki. Masalh masih timbul, karena secara deskriptif, kesalahan yang ada tidak dapat dibayangkan di mana letaknya.

Pada tingkatan berikutnya, penguji harus menggunakan software yang dapat merekam gambar dari kesalahan yang terjadi. Penguji dapat melakukan capture (menangkap dan menyimpan) screen yang menunjukkan program yang diuji pada saat ‘error’. Dengan adanya gambar yang menunjukkan kesalahan, pemrogram dapat langsung mengetahui di mana letak kesalahannya. Proses capture screen dapat menggunakan fasilitas dari sistem operasi, jika pengguna menggunakan Windows, maka pengguna dapat dengan mudah melakukan penekanan tombol keyboard PrtSc (PrintScreen).

Akan tetapi seringkali terjadi, timbulnya kesalahan sewaktu-waktu. Pada kasus seperti ini, maka penguji harus dapat melakukan pengujian dengan melakukan proses pengujian secara lengkap terekam. Setiap langkah dari skenario diikuti dan direkam. Penguji dapat melaporkan kesalahan yang terjadi secara lebih lengkap. Pemrogram dapat mempelajari kejadian kesalahan dengan lebih teliti.
Jika kita lihat permasalahan di atas, maka kita membutuhkan suatu software yang bisa merekam proses pengujian dari awal sampai dengan akhir. Software untuk pengujian harus dapat membantu dari proses pembuatan skenario, pelaksanaan skenario, dan proses pelaporan hasil pengujian.
Untuk membantu mengelola skenario sampai dengan merekam proses dan hasil pengujian, maka kita dapat menggunakan software:

1. Testlink (http://testlink.org/)Software berbasis web yang digunakan untuk membuat membuat suatu daftar kasus uji yang akan didaftarkan pada setiap skenario dari komponen/modul dari suatu produk. Daftar kasus uji untuk setiap skenario untuk pengujian. Dari data inilah tester akan melakukan pengujian, dan menuliskan setiap pengujian yang dilakukan ke dalam daftar.

2. Bugzilla (http://www.bugzilla.org/) (Mantis - http://www.mantisbt.org/)Software ini harus dihubungkan dengan Testlink, digunakan untuk melakukan perekaman data modul yang belum lulus uji, yang harus diperiksa dan diperbaiki oleh pemrogram. Pemrogram harus bekerja memperbaiki dan melaporkan hasil uji ini. Tester akan melihat data hasil uji dan perbaikan dari programmer, jika masih belum benar, tester akan menuliskan bahwa program masih tetap harus diperbaiki.

3. screen capture atau yang lebih baik adalah video capture - avi recorder (http://www.bobyte.com/AviScreen/index.asp)Software ini sangat dibutuhkan untuk menyimpan bukti proses pengujian dilakukan. Apabila terjadi kesalahan, maka bagaimana terjadinya kesalahan untuk rekonstruksi akan dapat dilihat oleh pemrogram. Penggunaan video capture akan sangat bermanfaat, karena pemrogram dapat dengan mudah menjalankan video ini untuk melakukan rekonstruksi bagaimana kesalahan bisa terjadi, di mana dan kapan terjadi errornya.

Konsekuensi dari proses pengujian ini adalah kita harus memiliki space harddisk yang cukup memadai, untuk dapat merekam semua proses yang dilakukan selama proses pengujian. Jika pengujian telah selesai, maka rekaman hasil pengujian dapat dihapus, tetapi sebaiknya, sebelumnya dihapus terlebih dahulu

UAS RPLL - INTRO

FASE PENGEMBANGAN DAN DESAIN PERANGKAT LUNAK

Fase pengembangan terdiri dari 3 langkah :
1. Design
2. Code Generation (manual or automatic)
3. Testing
Setiap langkah melakukan transformasi informasi dalam suatu cara yang akhirnya menghasilkan software komputer yang valid.

Gambar 1. Development Phase

Software requirements
Dijelaskan dengan “Information Domain”, “Functional and performance requirements”, “Feed the design step”

Menggunakan metodelogi :
1. Data Design : difokuskan pada definisi dari struktur data
2.Architectural Design : mendefinisikan hubungan antara elemen struktur utama dari program
3. Procedural Design : mengubah struktur elemen ke dalam prosedur software

Gambar 2. Pentingnya Desain

PROSES DESAIN
Software design adalah suatu proses yang melawati serangkaian kebutuhan yang membentuk sebuah perangkat lunak

Software design dibagi dalam 2 tahap :
1. Preliminary Design
Pada tahap ini difokuskan dengan transformasi dari keperluan / kebutuhan ke dalam data dan arsitektur software
2. Detail Design
Difokuskan pada penghalusan representasi arsitektur yang berisi struktur data detail dan algoritma untuk software

Gambar 3. Hubungan antara aspek teknik dan management pada desain

KUALITAS DESAIN DAN SOFTWARE
Beberapa tuntunan dalam melakukan agar dihasilkan desain dengan kriteria yang baik, yaitu suatu desain haruslah :
1. Memperlihatkan organisasi hirarki yang mengontrol elemen-elemen software
2. Berkenaan dengan modul. Software secara logika terbagi dalam elemenelemen yang membentuk fungsi dan sub fungsi
3. Berisi representasi yang berbeda dan terpisah dari data dan prosedur
4. Membentuk modul ( contoh subroutine dan procedure ) yang memperlihatkan karakteristik fungsi yang tidak saling bergantung
5. Diturunkan dengan menggunakan metode perulangan yang didukung oleh informasi yang ada selama analisa kebutuhan software

EVOLUSI DESAIN SOFTWARE
Evolusi dari desain software merupakan proses yang berkelanjutan terus selama 3 dekade. Beberapa metodologi telah tumbuh, dan secara umum memiliki karakteristik sebagai berikut :
1. Sebuah mekanisme untuk menterjemahkan representasi domain informasi ke dalam representasi desain
2. Notasi untuk merepresentasikan fungsi komponen-komponen dan interfaces-nya
3. Heuristics bagi penyaringan dan partisi
4. Petunjuk untuk penaksiran kualitas

DASAR-DASAR DESAIN
Membantu software engineer untuk menjawab pertanyaan-pertanyaan berikut :
* Apakah kriteria yang dapat dipakai untuk mempartisi software menjadi sejumlah komponen ?
* Bagaimana fungsi atau struktur data dipisahkan dari suatu representasi konseptual software ?
* Apakah ada kriteria yang seragam yang menetapkan kualitas tehnik dari suatu software desain ?

ARSITEKTUR SOFTWARE
Arsitektur perangkat lunak menyinggung 2 karakteristik penting dari sebuah program komputer :
1. Hirarki struktur dari komponen-komponen prosedural ( modul )
2. Struktur data

Gambar 4. Evolution of structure

Gambar 5. Different strucuture

PROGRAM STRUCTURE
* Program structure menampilkan / menyajikan organisasi ( seringkali organisasi hirarki ) dari komponen-komponen program ( modul-modul ) dan mengandung arti hirarki dari kontrol program.
* Notasi yang digunakan adalah diagram tree. Biasanya dinamakan structure chart

Gambar 6. Terminologi structure

DATA STRUCTURE
Menggambarkan relasi logikal antara sejumlah elemen dari . Contoh :
type G = array [1..100] of integer;
...
...
Procedure S ( var T : G ; n : integer ; sum : integer );
Var
I : integer;
begin
sum := 0;
for I:=1 to n do
sum := sum + t[i];
end;

SOFTWARE PROCEDURE
Difokuskan pada detail pemrosesan dari setiap modul secara individu. Prosedur harus mengandung spesifikasi yang benar / tepat dari pemrosesan, termasuk : sequence of events, decision points, repetitive operations, dan struktur data.

Gambar 7. Procedure dengan sebuah modul

MODULARITAS
Software dibagi kedalam nama-nama yang terpisah dan elemen-elemen yang dapat dipanggil, yang disebut dengan modul, yang termasuk kedalam memenuhi syarat-syarat permasalahan

Misalkan :
C(x) = fungsi kompleksitas dari suatu masalah
E(x) = fungsi usaha/waktu yang diperlukan untuk memecahkan suatu masalah
P1 ,P2 = masalah 1, masalah 2
Jika : C(P1) > C(P2) maka : E(P1) > E(P2)

Berdasarkan penelitian :
C ( P1 + P2 ) > C ( P1 ) + C ( P2 )
E ( P1 + P2 ) > E ( P1 ) + E ( P2 )

Konklusi :
Kompleksitas suatu masalah gabungan P1 dan P2 akan berkurang jika masalah tersebut dipisahkan
Akan lebih mudah menyelesaikan suatu masalah jika dipecah / dipartisi

ABSTRAKSI
Jika kita menggunakan suatu solusi modular untuk beberapa masalah, maka beberapa level / tingkat abstrasi dapat ditampilakn / diperlihatkan.
Pada level tertinggi, suatu solusi berada pada term yang umum dengan menggunakan bahasa natural
Level yang lebih rendah lebih berorientasi pada prosedur-prosedur

Contoh :
Abstraksi 1
The software will incorporate a computer graphics interface
that will enable visual communication with the drafts person
and a digitizer interface that replace the drafting board and
square. All line and curve drawing, all geometric computation,
and all sectioning and auxiliary views will be performed by
the CAD Comp.

Abstraksi 2
CAD Software tasks :
user interaction task ;
2-D drawing creation task ;
graphics display task ;
drawing file management task ;
end.

Abstraksi 3
procedure : 2-D drawing creation ;
repeat until (drawing creation task terminates)
do while (digitizer interaction occurs)
digitizer interface task ;
determine drawing request case ;
line : line drawing task ;
circle : circle drawing task ;
...
...
end ;
do while (keyboard interaction occurs)
keyboard interaction task ;
process analysis / computation case ;
view : auxiliary view task ;
section : cross sectioning task ;
...
...
end
...
...
end repetition ;
end procedure.

PENYEMBUNYIAN INFORMASI
Contoh :

Gambar 8. Penyembunyian Informasi

* Black Box : input, output, & proses dike-tahui tetapi proses detail tidak diketahui.
* Bagi Modul B, Modul C adalah Black Box

Keuntungan :
* Jika diperlukan modifikasi selama testing dan maintenance 􀃖 data & prosedur disembunyikan dari bagian lain, dari program / software secara keseluruhan.
* Kesalahan-kesalahan yang terjadi selama modifikasi tidak merambat pada bagian lain.

DESAIN MODULAR EFEKTIF
Modular design :: mereduksi komplesitas masalah, menyediakan fasilitas untuk melakukan perubahan ( dalam hal pemeliharaan ), dan memudahkan implementasi dengan pengembangan paralel dari bagian-bagian yang berbeda dalam suatu sistem

MODULE TYPES
Abstraksi dan penyembunyian informasi dipakai untuk mendefinisikan modul-modul di dalam lingkungan software architecture. Di dalam structure software, suatu modul mungkin dikategorikan sebagai berikut :
1. Sequential module :: dieksekusi tanpa interupsi yang dilakukan software aplikasi
2. Incremental module :: dapat diinterupsi oleh program aplikasi dan kemudian kembali ke titik semula setelah interupsi selesai
3. Parallel module :: dieksekusi secara simultan dengan modul lain dalam lingkungan Concurrent multiprocessor

INDEPENDENSI FUNGSIONAL
Konsep functional independence berkembang dari modularitas dan konsep bstraksi serta information hiding. Independence diukur dengan menggunakan 2 kriteria kualitatif, yaitu
1. Cohesion
2. Coupling

Cohesion ( keterpautan )
* Perluasan / kelanjutan dari information hiding
* Suatu modul kohesif membentuk sebuah tugas tunggal di dalam suatu software prosedur dan memerlukan sedikit interaksi dengan prosedur yang dibuat dalam bagian lain dari suatu program

Gambar 9. Cohesion

Coincidental cohesion :
sebuah modul yang membentuk sejumlah tugas yang berhubungan satu sama lain dengan longgar

Logically cohesion :
sebuah modul yang membentuk tugas-tugas yang dihubungkan secara logical

Temporal cohesion :
jika sebuah modul berisi sejumlah tugas yang dihubungkan dengan segala yang harus dieksekusi di dalam waktu yang bersamaan.

Procedural cohesion :
jika pemrosesan elemen-elemen dari suatu modul dihubungkan dan harus dieksekusi dalam urutan spesifik

Communication cohesion :
jika pemrosesan elemen-elemen dikonsentrasikan pada satu area dari suatu struktur data

Coupling ( bergandengan )
Merupakan suatu pengukuran dari keterkaitan / keterhubungan antara sejumlah modul dalam struktur program. Coupling tergantung pada kompleksitas interface antar modul

Gambar 10. Coupling

Gambar 11. Low Coupling dan High Coupling

MODEL DESAIN
Prinsip dan konsep desain yang dibicarakan pada bab ini membangun sebuah fondasi untuk pembuatan model desain yang mencakup representasi data, arsitektur, interface dan prosedur.

DOKUMENTASI DESAIN
Outline spesifikasi desain :
I. Ruang Lingkup
A. Sasaran Sistem
B. Persyaratan utama software
C. Batasan-batasan dan pembatasan desain
II. Desain Data
A. Obyek data dan struktur data resultan
B. Struktur file dan database
1. Struktur file eksternal
a. struktur logis
b. deskripsi record logis
c. metode akses
2. data global
3. file dan referensi lintas data
III. Desain Arsitektural
A. Kajian data dan aliran control
B. Struktur program yang diperoleh
IV. Desain Interface
A. Spesifikasi interface manusia-mesin
B. Aturan desain interface manusia-mesin
C. Desain interface eksternal
1. Interface untuk data eksternal
2. Interface untuk sistem atau peralatan eksternal
V. Desain Prosedural
Untuk masing-masing modul :
A. Naratif pemrosesan
B. Deskripsi Interface
C. Deskripsi bahasa (atau lainnya) desain
D. Modul-modul yang digunakan
E. Struktur data internal
F. Keterangan/larangan/pembatasan
VI. Persyaratan Lintas-Referensi
VII. Ketetentuan pengujian
1. Panduan pengujian
2. Strategi integrasi
3. Pertimbangan Khusus
VIII. Catatan Khusus
IX. Lampiran


PENGUJIAN
Pengujian program harus dilakukan pertama kali oleh pemrogram itu sendiri, setelah itu baru diserahkan dan dilakukan pengujian oleh penguji (tester) program.

Bahan untuk pengujian harus disiapkan oleh perancang aplikasi atau pengguna. Bahan untuk pengujian suatu modul program akan terdiri atas banyak data dan prosedur. Setiap data dan prosedur disebut sebagai kasus uji (test case).Satu modul akan memiliki banyak kasus uji. Mengapa? Karena di dalam suatu program atau modul, pada umumnya, di dalamnya akan terdapat lebih dari satu prosedur atau fungsi. Setiap prosedur dan fungsi akan memiliki kegunaan sendiri, maka sudah seharusnya setiap fungsi atau prosedur harus diuji. Pengujian pada level prosedur atau fungsi disebut sebagai pengujian pada level unit.

ICT untuk Pendidikan Beragama

Pada dasarnya Indonesia sangat kompleks, baik dari segi agama, suku, dan lain sebagainya. Dari banyaknya kompleksitas yang ada di indoensia, maka akan memiliki resiko terjadinya konflik dalam masyarakat sangat memungkinkan. Ini terlihat pada beberapa saat yang lalu terjadi konflik antara 2 kubu agama yang terjadi di POSO. Ini adalah sekelumit cerita dari konflik yang ada pada indonesia. Sebenarnya apakah yang mendasari terjadinya konflik? Mungkin salah satu faktornya adalah komunikasi. Jangankan kehidupan beragama, terkadang antara saudara jika tidak terjadi komunikasi yang baik maka akan timbul konflik. Bagaimana dengan orang indonesia yang beraneka ragam serta berjumlah lebih dari 200 juta jiwa? Tentulah ini akan menjadi persoalan yang penting untuk ditindak lanjuti.

Dengan kemajuan teknologi sekarang dan akan datang, maka faktor miskomunikasi dapat direduksi. Di internet telah banyak situs-situs yang mengenalkan ataupun menjelaskan kegiatan yang dilakukan dalam agama tersebut. Sehingga orang yang beragama lainnya dapat mengetahui apa yang dilakukan orang lain. Dengan adanya komunikasi antar agama dapat mereduksi konflik yang ada indonesia. Indonesia memang majemuk, dan itu patut disyukuri.

ICT ( Information Communication Technology) dapat menjadi salah satu pemecahan kebuntuan komunikasi. Faktor jarak, waktu, dan lain sebagainya yang menyebabkan komunikasi tidak berjalan secara perlahan dapat dikikis. Seperti halnya ICT untuk pendidikan Formal, ICT dapat pula dimanfaatkan untuk pendidikan beragama. Pemanfaatannya dapat berupa makin memperdalam agama yang dianut seseorang atau terjadi sharing antar umat beragama.

Komponen utama untuk mengimplementasikan ICT dalam Pendidikan Agama :

1. Media komunikasi ( televisi, radio, internet )
2. Mesin Informasi ( Komputer, Handphone )
3. Teknologi dan Peralatan Komunikasi ( Fiber Optik, Satelit )
4. Pakar pada tiap bidang masing-masing agama ( Islam : Tafsir, Ekonomi Syariah, dll , Kristen, Katolik, Hindu, Budha, Aliran Kepercayaan )

Dengan adanya pakar, maka akan meminimalkan kesalahan pehaman sesorang kepada orang lain. Terkadang seseorang kurang mengetahui atau mendalami sebuah agama yang dianutnya. Sehingga ketika orang lain ingin mengetahui, maka akan terjadi konflik yang sangat fatal jika salah menjelaskan. Sehingga diharapan bahwa kehidupan berbangsa dan bernegara dapat berlandaskan Agama yang dianut.

Langkah yang perlu dibangun adalah :

1. Membangun jaringan di tingkat Institusi Pendidikan :
1. Negeri : SDN, SMPN, SMUN, Perguruan Tinggi
2. Swasta : TK, SD, SMP, SMU, Perguruan Tinggi
2. Membangun jaringan pendidikan informal di tingkat masyarakat
1. Tempat Peribadatan
2. Komunitas Beragama
3. Seminar, Training
3. Pada poin 1 dan 2 terintegrasi dalam setiap wilayah ( kota ) dan masing-masing kota memiliki Pusat Seagama, Pusat Komunikasi Antar Agama.
4. Dari masing-masing pusat diantar kota terintegrasi Pusat Tingkat Propinsi yang terdiri dari Pusat Seagama Tingkat Propinsi, dan Pusat Komunikasi Antar Negara Tingkat Propinsi.
5. Terdapat sebuah Pusat Keagamaan Seluruh Indonesia.

Setelah jaringan telah terbentuk, maka yang sangat penting di bangun andalah Moralitas dari bangsa itu sendiri. Untuk membangun Moralitas, maka manusianyalah yang perlu dibangun mentalitasnya. Untuk membangun mentalisatas tersebut perlu dibentuk baik di dalam Institusi Pendidikan ataupun Pendidikan informal.

Pembangunan mentalitas :

1. Pada Institusi Pendidikan
1. Kurikulum
2. E-Learning
3. Praktik
4. Klinik ICT
2. Pada Pendidikan informal
1. Seminar
2. Pelatihan/Training
3. Acara Keagamaan yang rutin, baik tiap hari, tiap minggu, tiap bulan, tiap tahun.
4. Ceramah Pemuka agama secara rutin

To be continue .........