About iisariska

Nama : Iis Ariska R NIM : 1333376120 Jurusan : Teknik Informatika Konsentrasi : Artificial Informatics

Notulen Testing OJRS+ 04 Desember 2015

Simulasi OJRS+
Ada 3 tahap
– Menyaksikan video yang telah di buat
– Training OJRS+
– Simulasi OJRS+

Selama training :
– Semua berperan sebagai kajur
– Semua berperan sebagai RPU
– Semua berperan sebagai keuangan

Ada 4 video yang akan disaksikan :
– Video pertama bagian OJRS+ keuangan
Keuangan -> input registrasi -> ubah status jadi “sudah bayar”. Jika sudah bayar status akan berwarna hijau. FAQ keuangan sudah ada didalam iRan.

– Batal tambah OJRS+
Klik create ticket OJRS+, untuk tiket ada 3 tampilan. Tampilan OJRS+ pada SiS+ tidak berbeda dengan tampilan yang di Box SiS. Tampilan tetap userfriendly, ada fasilitas edit dan hapus.

– OJRS+ kajur
Kajur bisa cari NIM atau nama untuk melakukan validasi. Untuk validasi KKP yang melakukan konfirm adalah kajur. Jika kajur mengklik “OK” maka KKP akan tampil pada KST.

– OJRS+ RPU Untuk buka kelas
klik tambah kelas, perbedaan buka tutup kelas, jika buka kelas klik “On” Untuk Tutup kelas statusnya hanya tinggal diganti “off”.

– Tutup kelas
Cari kode kelas, klik update, ubah status menjadi “off”

Saat ini ada 3 bagian :
– Simulasi keuangan diikuti oleh semua peserta
Keuangan klik “bayar” maka status akan berubah menjadi hijau. Mahasiswa juga akan mendapatkan email notifikasi.

– Simulasi kajur diikuti oleh semua peserta
Untuk mahasiswa yang ingin KKP akan dilakukan untuk validasi KKP, search nama atau NIM, kajur periksa data-data mahasiswa kemudian kajur klik “konfirm”. Maka status KKP akan berubah menjadi “OK”.

Untuk mahasiswa yang ingin skripsi, klik batal tambah, kemudian search NIM atau nama, tampilan akan kosong karna mahasiswa akan melakukan skripsi sudah tidak ada matakuliah. Untuk skripsi kajur yang menambahkan. Search skripsi, klik kodenya, kemudian klik “pilih” kemudian otomatis akan nambah pada jadwal mahasiswa. Skripsi hanya bisa dihapus karna skripsi bukan dikelas.

– Simulasi RPU dilakukan oleh semua peserta
RPU untuk buka tutup kelas. Prosedur buka tutup kelas diserahkan ke bagian RPU. RPU juga bisa merubah status yang tadinya cuti untuk kembali menjadi aktif.
Masuk ke “status mahasiswa” kemudian search nim mahasiswa, klik aktif dan masukkan tanggal klik “OK”.

1. Simulasi skenario pertama
Pimpinan (Pak Sugeng) memberikan kebijakan dimulainya batal tambah sesuai “Agenda Kalender Mahasiswa”
Admin akan membalas email dari pimpinan untuk melakukan instruksi.

Setiap mahasiswa yang ingin bertanya silahkan hubungi iDuhelp!

2. Skenario kedua
Julipah dan Ridwan mendatangi keuangan untuk registrasi. Kemudian untuk simulasi selanjutnya di kelas sudah ada 4 mahasiswa yang sudah registrasi dan belum registrasi. Yang sudah registrasi Julipah dan Ridwan. Mahasiswa yang belum registrasi akan keluar otomatis dan akan digantikan oleh mahasiwa yang telah registrasi.

Jika D3 ingin melakukan batal tambah tetapi bukan jadwalnya maka akan keluar contdown waktu kapan mahasiswa tersebut dapat melakukan batal tambah.
Ridwan dapat melakukan batal tambah jika waktu D3 untuk batal tambah telah dibuka dan akhirnya Ridwan bisa melakukan batal tambah ketika waktunya telah tiba.

Simi mahasiswa yang cuti ingin aktif berkuliah kembali. Setelah bayar registrasi dan akan menyerahkan data-data ke RPU untuk aktif berkuliah kembali.

Ridwan akan ke kajur untuk validasi KKP.
Untuk mahasiswa yang mempunyai IPK diatas 3 dapat langsung menambahkan SKS. Untuk mahasiswa yang mempunyai IPK dibawah 3 tidak dapat menambah SKS karna button + tidak tersedia.

Arahan dari pak Abas :
Merasa terpanggil karena pribadi raharja kalo ada yg ngomong nyeleneh “mana keunggulannya masa masih gini-gini aja masih ngantri”.
Uji coba masih dianggap belum sempurna harus ditambah lagi uji cobanya. Kalo ada manfaat ini seperti penelitian
Satu temuan dapat dimanfaatkan kasih operasional akan diajukan surat keputusan Pak Abas akan bertanggung jawab asalakan ada manfaatnya. Terus melihat perkembangan ini, jadi akan dibuat keputusan ada masa uji coba nanti jangan dummy lagi langsung jalan. Tiap devisi melihat problemnya Untuk hal tertentu jangan terbuka untuk ka novi bagian RPU. Hal ini dianggap perlu sekali lagi presentasenya. Nanti tiap devisi harus demo sendiri seperti keuangan oleh bu Tuti

Setelah diberikan penghargaan kasih dana penghargaan, pencipta tidak boleh mengambil project yang telah dibuat untuk kampus karena akan dimiliki untuk kampus. Lanjutkan sampai sempurna, akan dibuatkan surat keputusan
Untuk hal yang baik akan didukung oleh Pak Abas akan disediakan penghargaan sertifikat jika telah berhasil

Pa UR:
Terimakasih atas supportnya yang telah dilalui OJRS+ project thesis Ka Khanna. Perhatikan apa yang masih kurang.

Mengucapakkan apresiasi bagian RPU : “OJRS+ Wah gampang Kan”
Mengucapakkan apresiasi bagian Kajur : “OJRS+ Wah gampang Kan”
Mengucapakkan apresiasi bagian Keuangan : “OJRS+ Wah gampang Kan”
Mengucapakkan apresiasi bagian REC : “OJRS+ Wah gampang Kan”
Mengucapakkan apresiasi bagian Mahasiswa : “OJRS+ Wah gampang Kan”
Mengucapakkan apresiasi bagian Pembimbing : “OJRS+ Wah gampang Kan”

Foto bareng 🙂

Izin Edit iMe Widuri

Haiiii… Iis mau cerita sedikit nih 😀
Awalnya Iis sedang memeriksa iMe Widuri yang tampilannya seperti gambar di bawah ini

Lalu tiba-tiba Iis kepikiran untuk mengubah tampilan Widuri agar terlihat lebih rapih. Yang awalnya seperti ini

Membuat Blue Print OJRS+ Prosedur Kemahasiswaan

Haiiii kawan-kawan, Iis mau cerita nih kalo kemarin hari Sabtu, Tanggal 31 Oktober 2015 4G dan tim IS Ka Khanna mendapat tugas untuk membuat Blue Print. Saya, Ka Nursam, dan Ajeng di jadikan satu kelompok membuat Blue Print Prosedur OJRS+ Kemahasiswaan. Sedangkan Dwiki, Alfons dan Julipah dijadikan satu kelompok untuk membuat Blue Print Prosedur OJRS+ Laporan Keuangan. Setelah Blue Print selesai kemudian kami membuat video 😀 Alhamdulillah semuanya selesai pada hari sabtu 🙂

Berikut ini gambar halaman depan Blue Print OJRS+ Kemahasiswaan

Dan ini adalah videonya, jangan lupa view, like, dan comment 😀

Final Script 3MT

Assalamualaikum Warahmatullahi Wabarakatuh

Pada video kali ini Team Widuri akan mempresentasikan tentang projectnya yaitu Widuri. Pasti ingin tahu kan Apa yang dimaksud dengan Widuri? Widuri adalah singkatan dari Wiki iDu Raharja iLearning, yang merupakan sebuah media pembelajaran khususnya untuk Pribadi Raharja di Perguruan Tinggi Raharja. Disini Pribadi Raharja bisa menulis berbagai macam artikel ilmiah seperti jurnal, hibah, tugas kuliah, KKP, TA maupun skripsi.

Lalu Bagaimana team Widuri melakukan pekerjaannya? Jika ada Pribadi Raharja yang telah membuat artikel atau laporan hibah, jurnal serta laporan KKP maupun Skripsi dan tidak ingin ada orang lain yang mengeditnya silahkan hubungi iDuhelp! untuk meminta team Widuri agar melakukan penguncian (lock) laporan tersebut agar tidak ada yang bisa merubah atau mengedit selain penulis. Team Widuri juga berhak sepenuhnya untuk menghapus artikel yang tidak sesuai dengan ketentuan yang berlaku pada Widuri atau berisi sampah yaitu artikel yang tidak berguna dan membahayakan pembaca serta membahayakan sistem yang ada pada Widuri tanpa melakukan konfirmasi terlebih dahulu kepada penulis. Jika Pribadi Raharja ingin mengakses widuri untuk membuat artikel ataupun membuat laporan jurnal, hibah, KKP, atau TA/Skripsi silahkan kunjungi link widuri.raharja.info. Jika Pribadi Raharja mengalami kesulitan silahkan kunjungi halaman FAQ di link http://widuri.raharja.info/index.php?title=Bantuan:FAQ. Atau jika Pribadi Raharja ingin mengajukan pertanyaan seputar Widuri Pribadi Raharja dapat bertanya melalui iDuhelp! yang Online pada hari Senin sampai Jum’at pukul 08:00 WIB sampai pukul 21:00 WIB. Pribadi Raharja juga dapat bertanya secara offline yang bisa di akses secara 24 jam oleh customer.

Waterfall Raharja

Mind Mapping
Merupakan cara dalam berinovasi atau mengembangkan keterampilan berfikir dalam menganalisa ide kreatif secara detail sehingga masalah dapat terselesaikan dengan cepat dengan pemikiran dan konsep yang dapat saling berkomunikasi dalam sebuah media dalam bentuk diagram yang menggunakan gambar, kata-kata, dan warna dalam menciptakan ide-ide yang potensial dalam memecahkan suatu masalah dan membuat perencanaan secara strategis.

Analisis
Pada metode analisa sistem ini merupakan penjabaran atau realita dari metode analisa yang anda pilih pada BAB I yang sudah disesuaikan berdasarkan kebutuhan penelitian yang anda lakukan. Pada metode analisa ini, anda juga harus memperhatikan metode pengumpulan data yang sebelumnya sudah anda lakukan yaitu pada saat melakukan observasi dan wawancara untuk mendapatkan data yang akan anda analisa.

Elisitasi
Merupakan rancangan yang dibuat berdasarkan sistem yang baru yang diinginkan oleh pihak manajemen terkait dan disanggupi oleh penulis untuk dieksekusi. Elisitasi didapat melalui metode wawancara dan dilakukan melalui tiga tahap, yaitu sebagai berikut (Hidayati, 2007) :

Elisitasi tahap I
yaitu berisi seluruh rancangan sistem baru yang diusulkan oleh pihak manajemen terkait melalui proses wawancara.

Elisitasi tahap II
merupakan hasil pengklasifikasian dari elisitasi tahap I berdasarkan metode MDI. Metode MDI ini bertujuan untuk memisahkan antara rancangan sistem yang penting dan harus ada pada sistem baru dengan rancangan yang disanggupi oleh penulis untuk dieksekusi. Berikut penjelasan mengenai Metode MDI :

1. M pada MDI itu artinya Mandatory (Penting). Maksudnya requirement tersebut harus ada dan tidak boleh dihilangkan pada saat membuat sistem baru.
2. D pada MDI itu artinya Desirable. Maksudnya requirement tersebut tidak terlalu penting dan boleh dihilangkan. Tetapi jika requirement tersebut digunakan dalam pembentukan sistem, akan membuat sistem tersebut lebih perfect.
3. I pada MDI itu artinya Inessential. Maksudnya bahwa requirement tersebut bukanlah bagian dari sistem yang dibahas dan merupakan bagian dari luar sistem.

Elisitasi tahap III
merupakan hasil penyusutan dari elisitasi tahap II dengan cara mengeliminasi semua requirement yang optionnya I pada metode MDI. Selanjutnya semua requirement yang tersisa diklasifikasikan kembali melalui metode TOE, yaitu sebagai berikut :

1. T artinya Tehnikal, maksudnya bagaimana tata cara / tehnik pembuatan requirement tersebut dalam sistem yang diusulkan?
2. O artinya Operasional, maksudnya bagaimana tata cara penggunaan requirement tersebut dalam sistem yang akan dikembangkan ?
3. E artinya Ekonomi, maksudnya berapakah biaya yang diperlukan guna membangun requirement tersebut didalam sistem?

Metode TOE tersebut dibagi kembali menjadi beberapa option, yaitu :
1. High (H) : Sulit untuk dikerjakan, karena tehnik pembuatan dan pemakaiannya sulit serta biayanya mahal. Sehingga requirement tersebut harus dieliminasi.
2. Middle (M) : Mampu untuk dikerjakan
3. Low (L) : Mudah untuk dikerjakan

Final draft elisitasi
merupakan hasil akhir yang dicapai dari suatu proses elisitasi yang dapat digunakan sebagai dasar pembuatan suatu sistem yang akan dikembangkan.

Strategi
Merupakan sebuah taktik yang digunakan dalam mencapai sebuah tujuan tertentu yang dibuat secara kuantitas dalam menentukan beberapa luas pencapaian yang akan dicapai untuk menyelesaikan sebuah permasalahan atau memecahkan sebuah permasalahan. Pembahasan strategi ini merupakan penjabaran yang dilakukan secara keseluruhan dengan menerapkan pembahasan secara satu per satu dengan detail dari final elisitasi untuk jadikan sebagai pembuktian atas pencapian yang telah dilakukan dan dapat dibuktikan kuantitasnya, yaitu sebagai berikut :

1. Strategi 1 : (yang diisikan urutannya sesuai dengan daftar pada elisitasi final nomor 1 pada bagian functional)
a. Penjelasan secara detail mengenai apa yang ingin dicapai pada strategi yang akan dibahas ini :
b. Pembuktian berupa gambar dari hasil pencapaian strategi yang sudah dijalankan.

2. Strategi 2 : (yang diisikan urutannya sesuai dengan daftar pada elisitasi final nomor 2 pada bagian non functional)
a. Penjelasan secara detail mengenai apa yang ingin dicapai pada strategi yang akan dibahas ini
b. Pembuktian berupa gambar dari hasil pencapian strategi yang sudah dijalankan

HIPO dan Prototype
HIPO (Hirarchy Plus Input Process Output) merupakan alat bantu untuk membuat spesifikasi program yang merupakan struktur yang berisi diagram dimana di dalam program ini berisi input yang diproses dan menghasilkan output. Spesifikasi program menjelaskan mengenai cara penggunaan aplikasi program yang diusulkan.

Prototype
Pada tahap ini merupakan gambar yang jelas mengenai rancangan bangun yang lengkap kepada para pengguna website, juga sebagai pemenuhan kebutuhan daripada para pengguna sistem. Rancangan prototype ini bukan berisi hasil printscreen dari sebuah program, tetapi desain layout dari program yang anda buat. Rancangan ini dalam bentuk kotak-kotak. Apabila yang anda buat merupakan pengembangan dari yang sebelumnya, maka rancangan Prototype ini berisi printscreen dari system yang berjalan.

Testing
adalah pengujian yang dilakukan terhadap keseluruhan sistem (secara lengkap) dan sistem yang telah terintegrasi untuk mengevaluasi apakah sistem yang dibuat telah sesuai dengan kebutuhan pengguna.

Implementasi
Implementasi program dilakukan dengan menggunakan metode Blackbox Testing. Metode Blackbox Testing merupakan pengujian program yang mengutamakan pengujian terhadap kebutuhan fungsi dari suatu program. Tujuan dari Metode Blackbox Testing ini adalah untuk menemukan kesalahan fungsi pada program. Pengujian dengan Metode Blackbox Testing dilakukan dengan cara memberikan sejumlah input pada program. Input tersebut kemudian di proses sesuai dengan kebutuhan fungsionalnya untuk melihat apakah program aplikasi dapat menghasilkan output yang sesuai dengan yang diinginkan dan sesuai pula dengan fungsi dasar dari program tersebut. Apabila dari input yang diberikan, proses dapat menghasilkan output yang sesuai dengan kebutuhan fungsionalnya, maka program yang dibuat sudah benar, tetapi apabila output yang dihasilkan tidak sesuai dengan kebutuhan fungsionalnya, maka masih terdapat kesalahan pada program tersebut, dan selanjutnya dilakukan penelusuran perbaikan untuk memperbaiki kesalahan yang terjadi.

Contoh Waterfall Model

Permodelan dalam suatu perangkat lunak merupakan suatu hal yang dilakukan di tahapan awal. Di dalam suatu rekayasa perangkat lunak, sebenarnya masih memungkinkan tanpa melakukan permodelan. Hal ini tidak dapat lagi dilakukan dalam suatu industri perangkat lunak. Permodelan dalam perangkat lunak merupakan suatu yang harus dikerjakan di bagian awal rekayasa, dan permodelan ini akan mempengaruhi pekerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut. Model proses perangkat lunak masih menjadi obyek penelitian, tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain: Pengembangan waterfall Pengembangan secara evolusioner Transformasi formal

Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan kembali. Waterfall model pertama kali diperkenalkan oleh Winston Royce tahun 1970. Waterfall Model merupakan model klasik yang sederhana dengan aliran sistem yang linier. Output dari setiap tahap merupakan input bagi tahap berikutnya. Model ini telah diperoleh dari proses rekayasa lainnya dan menawarkan cara pembuatan rekayasa perangkat lunak secara lebih nyata. Model ini melibatkan tim SQA (Software Quantity Assurance) dengan 5 tahapan, dimana setiap tahapan selalu dilakukan verifikasi atau testing.

Tahapan model Waterfall meliputi :

  • Requirment

Dalam tahapan ini jasa, kendala dan tujuandari konsultasi dengan pengguna sistem. Kemudian semuanya dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang. Dengan kata lain, dalam tahapan ini dilakukan analisa kebutuhan, kemudian diverifikasi klien dan tim SQA.

Dalam tahapan ini jasa, kendala dan tujuandari konsultasi dengan pengguna sistem. Kemudian semuanya dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang. Dengan kata lain, dalam tahapan ini dilakukan analisa kebutuhan, kemudian diverifikasi klien dan tim SQA.

  • Specification

Dokumentasi spesifikasi, kemudian diperiksa oleh tim SQA. Selanjutnya jika disetujui oleh klien, maka dokumen tersebutmerupakan kontrak kerjaantaraklien dan pengembang s0ftware. Selanjutnya merencanakan jadwal pengembangan software. Jika disetujui oleh SQA, tahap desain baru dilakukan.
Dokumentasi spesifikasi, kemudian diperiksa oleh tim SQA. Selanjutnya jika disetujui oleh klien, maka dokumen tersebutmerupakan kontrak kerjaantaraklien dan pengembang s0ftware. Selanjutnya merencanakan jadwal pengembangan software. Jika disetujui oleh SQA, tahap desain baru dilakukan.

  •  Design

Proses design sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. Proses tersebut menghasilkan sebuah arsitektur keseluruhan. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkatlunak dalam bentuk yang mungkin ditransformasi kedalam satu atau lebih program yang dapat dijalankan. Tahapan ini telah menentukan alur software hingga pada tahap algoritma detail. di akhir tahap ini, kembali diperksa tim SQA.
Proses design sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. Proses tersebut menghasilkan sebuah arsitektur keseluruhan. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkatlunak dalam bentuk yang mungkin ditransformasi kedalam satu atau lebih program yang dapat dijalankan. Tahapan ini telah menentukan alur software hingga pada tahap algoritma detail. di akhir tahap ini, kembali diperksa tim SQA.

  • Implementation

Selama tahap ini, desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. Desain yang telah disetujui, diubah dalam bentuk kode-kode program. Tahap ini, kode-kode program yang dihasilkan masih pada tahap modul-modul. Diakhir Tahap ini, tiap modul di testing tanpa diintegrasikan.Selama tahap ini, desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. Desain yang telah disetujui, diubah dalam bentuk kode-kode program. Tahap ini, kode-kode program yang dihasilkan masih pada tahap modul-modul. Diakhir Tahap ini, tiap modul di testing tanpa diintegrasikan.

  • Integration

Unit program diintegrasikan dandiuji menjadi sistem yang lengkap untuk meyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah uji coba, sistem disampaikan ke konsumen.
Unit program diintegrasikan dandiuji menjadi sistem yang lengkap untuk meyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah uji coba, sistem disampaikan ke konsumen.

  • Operation model & retirement

Normalnya, ini adalah tahap yang terpanjang. Sistem dipasang dan digunakan. Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan inmplementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan.Setiap tahap dari modelini menggunakan Document Drivent, yaitu tahap selanjutnya selalu bekerja berdasarkan dokumen yang telah diberikan sebelumnya. Tahapan pada waterfall model tidak akan selesai jika tidak disetujui SQA. Modifikasi pada tahap tertentu (tidak sesuai dengan dokumen sebelumnya), proses harus kembali pada tahap sebelumnya untuk penyesuaian dan peninjauan ulang.Dalamprakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain. Proses perangkat lunak tidak linierdan sederhana, tapi mengandung urutan iterasi dari aktifitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.Sayangnya model yang banyak mengandung iterasi, sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan atau diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user. Mungkin juga sistem terstruktur secarajelek yang sebenarnya merupakan masalah deain akan dibiarkan karenaterkalahkan olehtrik implementasi.Masalah pendekatan waterfall adalah ketidakluwaesan pembagian proyek ke dalam langkah yang jelas/nyata. Sistem yang disampaikan kadang-kadang tidak dapatdigunakan sesuai keinginan konsumen. Namun demikian, model waterfall mencerminkan kepraktisan rekayasa. Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini, digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.