LMS "Chamilo"

Oleh - oleh dari seminar LMS Chamilo yang diselenggarakan di Hi-Tech, walaupun telat..ada baiknya di share..he

Jika teman-teman bertanya apa itu Chamilo? Chamilo adalah salah satu Learning Management System yang bersifat Open Source, menitikberatkan pada pembangunan portal E-learning. Serperti kebanyakan Learning Management System yang ada (Moodle, Dokeos, A Tutor, eFront, dll), Chamilo memiliki fitur-fitur untuk membangun sebuah portal E-Learning dengan mudah dan cepat >> itulah intinya.. he..

ya jadi kita bisa melakukan kegiatan belajar mengajar di sebuah portal ataupun web. mulai dari pembahasan materi, latihan - latihan maupun ujian, sampai dapat mengkalkulasi hasil dari pembelajaran (nilai akhir)

Kali ini memasang Chamilo pada server CentOS.. gmn Cara nyaaa???
Pada saat pemasangan Chamilo pada server CentOS yang saya gunakan terdapat sebuah masalah, yaitu belum terpasangnya php-json pada webserver . Setelah mencari beberapa saat di internet saya menemukan dua artikel yang menjelaskan langkah-langkah memasang php-json. Namun, dua artikel tersebut menjelaskan dengan cara yang berbeda. Akhirnya saya memutuskan menggabungkan dua langkah tersebut menjadi lebih sederhana dan berhasil untuk dicoba.

Langkah-langkah:

1. Buka terminal anda dalam mode root(#)
2. Update semua paket php yang ada

yum update "*php*"

3. Install php, php-perl, dan php-devel

yum install php php-pear php-devel

4. Install Json melalui PCEL

pecl install json

5. Masuk ke direktori /etc/php.d

cd /etc/php.d/

6. Buat berkas json.ini

echo "extension=json.so" >> json.ini

7. Restart service httpd

service httpd restart

sumber : http://benlancaster.wordpress.com/2009/09/15/installing-php-json-centos-rhel-5/

[ Read More ]

Resume Perancangan Sistem Informasi Terstruktur Sebelum UTS

Desain Sistem

Desain Sistem terbagi menjadi 2 , yaitu :

           1.       Sistem  secara umum atau conceptual design.

           2.       Sistem terinci atau physical design.

Arti desain :

           1.       Merupakan tahap setelah analisis dari siklus pengembangan system.

           2.       Pendefinisian kebutuhan fungsional.

Adapun SDLC :

Survey > kajian pustaka > analisis > requirements > coding > testing > implementasi > dokumentasi.

Elemen – elemen dari desain :

           1.       Proses

           2.       Entitas

           3.       Penyimpanan data

Tujuan desain adalah sebagai berikut :

           Memenuhi kebutuhan user dan Memberikan gambaran yang jelas dan rancang bangun yang lengkap kepada pemrogram computer dan ahli – ahli lain.

Agar tujuan tercapai, analisis harus mencapai sasaran :

           1.       Desain system harus berguna, dipahami, mudah digunakan.

           2.       Desain system harus dapat mendukung tujuan utama perusahaan.

       3.   Desain system harus efisien dan efektif untuk mendukung pengolahan transaksi, pelaporan manajemen dan mendukung keputusan yang dilakukan manajemen.

          4.      Harus dapat mempersiapkan rancang bangun yang terinci : data informasi, file – file, metode-metode, prosedur, Sumber daya manusia, hardware dan software.

Personil yang terlibat dalam desain system adalah :

           1.       Desain system = analis system

           2.       Pengendali system

           3.       Penjamin kualitas

           4.       Komunikasi data

           5.       User

Data Flow Diagram

Membuatnya setelah membuat System Flow. Merupakan analisis perancangan yang terstruktur dan memahami system dan subsistem secara visual.

KOMPONEN DFD
1. Menurut Yourdan dan Demarco

2. Menurut Gene dan Serson

Entitas eksternal dapat mengirim data atau menerima data dari system, ditulis dengan kata benda.

Aliran data merupakan perpindahan dari satu titik ke titik lainnya, ditulis dengan kata benda.

Proses yaitu adanya proses transformasi, label dibedakan antara data masukan dan keluaran, ditulis dengan kata kerja.

Penyimpanan data ditulis dengan kata benda, penyimpanan data sementara tidak dimasukkan ke dalam DFD.

Membuat diagram konteks :

1.      Mencakup masukan – masukan dasar, system umum dan keluaran.

2.      Tingkatan tertinggi dalam DFD, hanya memuat 1 proses.

3.      Diberi no.0

4.      Tidak membuat penyimpanan data.

Diagram level 0

1.      Masukkan dan keluaran yang ditetapkan dalam diagram yang pertama tetap konstan.

2.      Mencakup sampai 9 proses.

3.      Penyimpanan data utama dari system dan semua entitas eksternal dimasukkan ke dalam diagram 0.

Kesalahan pada diagram, yaitu  :

1.      Proses mempunyai input, tetapi tidak menghasilkan output, proses output tetapi tidak menerima input,

2.      Keseimbangan vertical.

3.      Aliran data pemberian label yang tidak tepat.

4.      Memasukkan lebih dari 9 proses.

5.      Mengabaikan aliran data.

6.      Menciptakan analisis yang tidak seimbang.

Arus data sebaiknya diberikan nama yang jelas dan mempunyai arti. Adapun konsep dalam DFD, yaitu :

1.      Konsep paket data

2.      Konsep arus data menyebar

3.      Konsep arus data mengumpul

4.      Konsep sumber dan tujuan arus data : semua arus data harus dihasilkan dari suatu proses.

Pedoman dalam menggambar DFD

1.      Cari eksternal entity yang terlibat pada system.

2.      Identifikasi I/O yang terlibat dengan eksternal entity.

3.      Gambar top level / context diagram.

4.      Gambar diagram jenjang.

5.      Gambar dekomposisinya.

Pustaka :
Kendall, K.E., and Kendall, J.E. 2002. System Analysis and Design 5th Edition, New Jersey: Prentice-Hall International
Whitten, Jeffrey L. 2002. System Analysis And Design Methods, 5th, Edition. Singapore: The McGraw-Hill Companies, Inc

[ Read More ]

Resume Testing & Implementasi Sistem Pert 6

Unit Testing

  berfokus pada usaha verifikasi pada unit terkecil dari disain software, komponen atau modul software.

Hal - hal yang diperhatikan unit testing adalah :

• Memastikan aliran informasi berjalan dengan baik
• Memastikan penyimpanan data telah terawat secara temporal
• Memastikan modul beroperasi dengan benar pada batasan yang tela ditentukan
• Semua jalur independen diperiksa untuk memeriksa semua pernyataan modul
• Semua jalur penanganan di testing

Test case harus mencakup kesalahan :

• Komparasi tipe data berbeda
• Operator logika dan prioritas yang tak benar
• Kemungkinan persamaan jika kesalahan presisi
• Kesalahan komparasi antar variable
• Terinasi loop yang tidak konsisten
• Kegagalan keluar bilamana konflik literasi terjadi
• Modifikasi variable loop yang tidak semestinya

Kesalahan potensial pada saat evaluasi penanganan kesalahan

• Deskripsi kesalahan tidak jelas
• Catatan kesalahan tidak berfungsi
• Kondisi kesalahan menyebabkan interfensi sistem terhadap kesalahan tertentu
• Pemrosesan kondisi perkecualian tidak benar
• Deskripsi kesalah tidak menyediakan informasi yang cakup untuk mengarahkan penyebab kesalahan

Prosedur-prosedur Unit Test

• Kode dikembangkan –> Diverifikasi tingkat disain komponen bersangkutan –> Disain test case dari unit test dimulai
• Drivers –> program utama yg menerima data test case, memasukkan data ke komponen yg dites dan mencetak hasil yg bersangkutan.
• Stubs –> untuk menggantikan modul-modul yg merupakan subordinat (dipanggil oleh) komponen yg dites.

• Drivers & stubs menimbulkan biaya overhead.
• Testing dapat ditunda penyelesaiannya (kondisi komplit) samapi tahap integration test.
• Unit testing disederhanakan bila suatu komponen didisain dengan kohesi tinggi.
• Bila hanya satu fungsi yg dialamatkan oleh suatu komponen, jumlah test case dapat dikurangi & errors dapat lebih mudah untuk diperiksa & dicakup.
• Perlu pemilihan modul-modul yg kritis & yg mempunyai cyclomatic compexity tinggi, untuk unti testing.

Penerapan dari driver dan stubs dapat dilihat pada gambar dibawah ini:

kunjungi juga  :

http://www.stikom.edu/

http://blog.stikom.edu/kjatmika/

[ Read More ]

Resume Testing & Implementasi Pert 5

State Transition Testing

Adalah suatu test cases didisain untuk memeriksa validitas transisi antar status. Test cases tambahan juga akan didisain untuk testing terhadap transisi-transisi yang tidak termasuk dan tidak dispesifikasikan. Dengan kata lain, testing ini fokus terhadap perpindahan antar kondisi. Tedapat beberapa hal penting tentang teknik testing ini, yaitu.

Ciri - ciri model yang digunakan State Transition Testing adalah ;

• Status program yang berjalan
• Transisi antar status
• Kejadian yang merupakan sebab dari transisi
• Aksi - aksi yang dihasilkan

Keterangan Gambar: 

• Status, seperti displaying time (S1). 
• Transisi, seperti antara S1 dan S3. 
• Kejadian yang menyebabkan transisi, seperti “reset” selama status S1 akan menyebabkan transisi ke S3. 
• Aksi yang merupakan hasil dari transisi, seperti selama transisi dari S1 ke S3 sebagai hasil dari kejadian “reset”, aksi “display time” akan terjadi.

test case dari gambar di atas seperti pada table di bawah ini :

kunjungi juga  :

http://www.stikom.edu/

http://blog.stikom.edu/kjatmika/

[ Read More ]

Use case system

Use case System

Adalah suatu objek bisnis / “sesuatu ” yang mempunyai status akan/harus dibuatkan statechart diagram.

Terdiri dari :

      1.       System

      2.       Fungsi

      3.       Fitur

Tujuannya bisa berupa memeriksa proses bisnis yang ada.

Component – component pada use case system

      1.       Actor

Semua yang berada di luar lingkup system dan berinteraksi dengan system.

Menurut Boogs ada 3 tipe actors, yaitu:

a.       Pengguna system

b.      System line

c.       Waktu

Penamaan actors harus sesuai dengan fungsinya / perannya pada system tersebut.

Sysmbol actors:

     2.       Use case

a.       Sebagai fungsi – fungsi / fitur – fitur yang dijalankan oleh system

b.      Identik dengan end user / pengguna langsung

c.       Biasanya dipegang oleh penguji system.

Penamaannya = kata kerja + kata benda

Symbol use case:

      

     3.       Relationship

Dibagi menjadi 3, yaitu :

a.       Actor to use case

Disebut dengan asosiasi

Symbol:

b.      Use case to use case

Terbagi menjadi 2, yaitu :

·         Include

Symbol :

·         Exclude

Symbol:

c.       Actor to actor

Contoh:

Cara membuat use case system

     1.       Tentukan user

     2.       Temukan use case

     3.       Buat relasi yang sesuai

     4.       Buat deskripsi flow of event untuk setiap use case

Flow of events

Adalah alur logika dalam sebuah use case. Sering juga disebut dengan suatu scenario yang bersifat primary.

[ Read More ]

Resume Testing & Implementasi Pert 4

Lines of Code

Line of Code (LOC) adalah suatu teknik pengukuran besar software dengan cara menghitung jumlah baris kode program yang ada. Metode LOC salah satu metode tradisional yang paling mudah dalam mengukur kualitas sebuah software, Walaupun mudah metode LOC cukup rumit bila dipelajari.

LOC adalah suatu bukti real dari apa yang dilakukan oleh perekayasa perangkat lunak (dalam konteks ini membuktikan berapa banyak baris program yang ditulis oleh seorang programmer comment yang ada).

System boleh dibilang memiliki kompleksitas kecil jika dalam system tersebut memiliki error rata-rata 1,3% - 1,8%, sedangkan system yang boleh dikatakan memiliki tingkat kompleksitas besar adalah system yang memiliki peluang error 2,7% - 3,2%.

Halsteads Matrix adalah pengukuran yang berdasarkan operator-operator yang digunakan(misal:  keyword) dan operan-operan(misal: variable, objek database) yang ada dalam suatu program.

N1 = Perhitungan keseluruhan operator program.

n1 = jumlah operator yang unik.

N2 = Perhitungan keseluruhan operan program.

n2 = jumlah operan-operan yang unik.

H = n1 Log₂  n1 + n2 Log₂  n2

Prediksi Bug = (N1+N2) Log₂ (n1+n2)/3000

Kekurangan metode Line of Code yang paling fatal adalah :

        1.Relatif terhadap bahasa pemprograman dan gaya pengkodean programmer
    2.Line of Code tidak bisa ditentukan sebelum proyek pengembangan menyelesaikan tahapan implementasi (pengkodean).

Dengan berkembangnya bahasa pemrograman Object-Oriented, dimana membuat suatu program yang terdiri dari berbagai object yang saling berinteraksi metode Line of Code jelas sulit untuk diterapkan.

Metode Line of Code dibagi beberapa cara, yaitu :

1.         Physical lines

2.         Physical lines of code

3.         Logical lines

4.         Logical lines of code

5.         Statements

  

Dua macam pendekatan test yaitu :

      1.      Black Box Testing

Test case ini bertujuan untuk menunjukkan fungsi PL tentang cara
beroperasinya, apakah pemasukan data keluaran telah berjalan
sebagaimana yang diharapkan dan apakah informasi yang disimpan
secara eksternal selalu dijaga kemutakhirannya.

       2.      White Box Testing

Adalah meramalkan cara kerja perangkat lunak secara rinci, karenanya
logikal path (jalur logika) perangkat lunak akan ditest dengan menyediakan test case yang akan mengerjakan kumpulan kondisi dan atau pengulangan secara spesifik. Secara sekilas dapat diambil kesimpulan white box testing merupakan petunjuk untuk mendapatkan program yang benar secara 100%. UJI COBA WHITE BOX
Uji coba white box adalah metode perancangan test case yang menggunakan struktur kontrol dari perancangan prosedural untuk mendapatkan test case. Dengan rnenggunakan metode white box, analis sistem akan dapat memperoleh test case yang:
a. menjamin seluruh independent path di dalam modul yang dikerjakan sekurang-kurangnya sekali

b. mengerjakan seluruh keputusan logical

c. mengerjakan seluruh loop yang sesuai dengan batasannya

d. mengerjakan seluruh struktur data internal yang menjamin validitas

1.      UJI COBA BASIS PATH

Uji coba basis path adalah teknik uji coba white box yg diusulkan
Tom McCabe. Metode ini memungkinkan perancang test case mendapatkan
ukuran kekompleksan logical dari perancangan prosedural dan menggunkan
ukuran ini sbg petunjuk untuk mendefinisikan basis set dari jalur
pengerjaan. Test case yg didapat digunakan untuk mengerjakan basis set
yg menjamin pengerjaan setiap perintah minimal satu kali selama uji coba.

PENGUJIAN BLACK-BOX

Pengujian black-box berfokus pada persyaratan fungsional PL. Pengujian
ini memungkinkan analis system memperoleh kumpulan kondisi input yg akan mengerjakan seluruh keperluan fungsional program.

Tujuan metode ini mencari kesalaman pada:

a.       Fungsi yg salah atau hilang

b.      Kesalahan pada interface

c.       Kesalahan pada struktur data atau akses database

d.      Kesalahan performansi

e.       Kesalahan inisialisasi dan tujuan akhir

Metode ini tidak terfokus pada struktur kontrol seperti pengujian whitebox
tetapi pada domain informasi.

Pengujian dirancang untuk menjawab pertanyaan sbb:

a.       Bagaimana validitas fungsional diuji?

b.      Apa kelas input yg terbaik untuk uji coba yg baik?

c.       Apakah sistem sangat peka terhadap nilai input tertentu?

d.      Bagaimana jika kelas data yang terbatas dipisahkan?

e.       Bagaimana volume data yg dapat ditoleransi oleh sistem?

f.       Bagaimana pengaruh kombinasi data terhadap pengoperasian system?

1.      EQUIVALENCE PARTITIONIN

Equivalence partitioning adalah metode pengujian black-box yg memecah
atau membagi domain input dari program ke dalam kelas-kelas data
sehingga test case dapat diperoleh. Perancangan test case equivalence partitioning berdasarkan evaluasi kelas equivalence untuk kondisi input yg menggambarkan kumpulan keadaan yg valid atau tidak. Kondisi input dapat berupa nilai numeric, range nilai, kumpulan nilai yg berhubungan atau kondisi Boolean.
Contoh :

Pemeliharaan data untuk aplikasi bank yg sudah diotomatisasikan. Pemakai
dapat memutar nomor telepon bank dengan menggunakan mikro komputer
yg terhubung dengan password yg telah ditentukan dan diikuti dengan perintah-perintah.

Data yg diterima adalah : Kode area : kosong atau 3 digit Prefix : 3 digit atau tidak diawali 0 atau 1 Suffix : 4 digit Password : 6 digit alfanumerik Perintah : check, deposit, dll Selanjutnya kondisi input digabungkan dengan masing-masing data elemen dapat ditentukan sbb : Kode area : kondisi input, Boolean – kode area mungkin ada atau tidak kondisi input, range – nilai ditentukan antara 200 dan 999
Prefix : kondisi input range > 200 atau tidak diawali 0 atau 1 Suffix : kondisi input nilai 4 digit Password : kondisi input boolean – pw mungkin diperlukan atau tidak kondisi input nilai dengan 6 karakter string Perintah : kondisi input set berisi perintah-perintah yang telah didefinisikan.
contoh: 

2.      Boundary value analysis : pemilihan kasus uji dengan mencari batas-batas ekstrim dari kelas data. Suatu teknik disain test cases yang berguna untuk melakukan pengujian terhadap nilai sekitar dari pusat domain masukan. Lebih mudahnya dikatakan sebagai suatu teknik yang hampir sama dengan Equivalance tetapi lebih spesifik karena yang diperiksa adalah nilai setiap batas dalam setiap pastisi.

kunjungi juga  :

http://www.stikom.edu/

http://blog.stikom.edu/kjatmika/

[ Read More ]