Monitoring dan Evaluasi

Ingin sebernarnya berbagi dan kebersamaan dalam pengetahuan.
Sistem dan mekanisme Akademik menetukan hasil pembelajaran.

Pengikut

Rabu, 15 Desember 2010

Kebijakan mutu dan Sasaran Mutu

Menetukan Kebijakan mutu dalam pengelolaan perguruan tinggi memang bukan hal mudah,

menjadikan Sebagai pusat studi terbaikbiasanya perguruan tinggi/penyelenggara pendidikan bertekad menciptakan lulusan yang unggul di bidangnya, dukungan SDM pun menadi kunci, infrastruktur, konten, dan proses akademik juga harus bermutu.

Menetukan sasaran mutu juga tidak mudah kita harus identifikasi pilar-pilanya terlebih dahulu, sehingga kita dapat tentukan target sasaran setiap tahunnya,peserta didik/mahasiswa, dosen/guru dan tenaga kependidikan juga idealnya harus tumbuh.

membuka prodi baru atau membuka konsentrasi baru sesuai dengan kebutuhan pasar sepertinya menjadi salah satu solusi agar penyelenggara pendidikan dapat berthan.


Objek dan elisitasi

Menggunakan OOP?

Mengapa OOP dibangun dalam sebuah paradigma yang luas untuk menyelesaikan masalah bisnis? Bahasa prosedural mengatur program dalam mode barisan linier yang bekerja dari atas ke bawah. Dengan kata lain, program adalah kumpulan dari tahapan yang dijalankan setelah yang lain berjalan. Programming tipe ini bekerja dengan baik untuk program kecil yang berisi code relative sedikit, tetapi pada saat program menjadi besar, mereka cenderung susah untuk di-manage dan di-debug. Dalam usaha untuk me-manage program, struktur programming diperkenalkan cara untuk mem-break down code-code tersebut melalui functions dan procedures.


Analisis

Sebutan lengkap analisis adalah analisis kebutuhan perangkat lunak (sofiware requirement analysis). Analisis kebutuhan adalah mendaftarkan apa-apa yang harus dipenuhi oleh sistem perangkat lunak, bukan mengenai bagaimana sistem perangkat lunak melakukannya. Hasil kegiatan ini didokumentasikan pada dokumen SRS (Software Requirement Specification). Contoh formal dokumen SRS adalah IEEE STD 830 1993/1999. Pada,dokumen IEEE STD 830, terdapat dua bagian yang menyatakan kebutuhan secara berbeda:

1 . Deskripsi keseluruhan adalah deskripsi nienggunakan bahasa alami, sangat menghindari notasi-notasi teknis

2. Kebutuhan spesifik adalah deskripsi menggunakan model-model analisis yang sering melibatkan notasi-notasi teknis. Model-model analisis ini merupakan inti dari SRS karena bagian 1 haruslah mengacu ke model-model analisis di kebutuhan spesifik yang lebih tidak ambigu.

Dampak kesalahan-kesalahan di spesifikasi kebutuhan perangkat lunak:

1 . Perangkat lunak yapg dihasilkan mungkin tidak memenuhi kebutuhan-kebutuan pemakai

2. Banyak interpretasi dari kebutuhan-kebutuhan dapat menyebutkan ketidaksepakatan­ketidaksepakatan di antara pembeli-pembeli dan pengembang-pengembang, waktu yang tersisa, dan dollar-dollar dan mungkin yang dihaslian secara hukum.

3. Dapat tidak mungkin menguji perangkat lunak memenuhi kebutuhan-kebutuhan yang diperuntukkan.

4. Waktu dan uang dihabiskan untuk membangun sistem yang salah.

Elisitasi Tahap I

Berisi seluruh rancangan sistem baru yang diusulkan oleh pihak manajemen terkait melalui proses wawancara untuk menterjemahkan kebutuhan pemakai sistem baru.

Functional

Analisa Kebutuhan

Saya ingin sistem dapat:

1.

Menampilkan Profil Klinik

2.

Menampilkan Form Login

3.

Menampikan Form Halaman Utama

4.

Menampilkan Laporan Data Pasien Rawat Jalan

5.

Menampilkan Laporan Data Dokter

6.

Menampilkan Laporan Data Pelayanan

7.

Menampilkan Laporan Data Tindakan

8.

Menampilkan Laporan Data Diagnosa

9.

Menampilkan Laporan Data Wilayah

10.

Menampilkan Input, Hapus dan Daftar Data Pengguna

11.

Menampilkan Input, Hapus, Ubah dan Daftar Data Dokter

12.

Menampilkan Input, Hapus, Ubah, Cari dan Daftar DataPasien Rawat Jalan

13.

Menampilkan Input, Hapus, Ubah dan Daftar Data Obat

14.

Menampilkan Input, Hapus, Ubah dan Daftar Data Laboratorium

15.

Menampilkan Input, Hapus, Ubah dan Daftar Data Tindakan

16.

Menampilkan Input, Hapus, Ubah dan Daftar Data Pelayanan

17.

Mencetak Laporan Pendapatan Dokter

18.

Mencetak Laporan Rekap Pendapatan Klinik

19.

Menu Logout atau Keluar


Level Analisis Berorientasi Oblek

Presman [PREOI] menyatakan bahwa analisis berorientasi objek dapat diterapkan pada beberapa abstraksi. Analisis sistem berorientasi objek dapat terjadi di banyak level abstraksi yang berbeda, yaitu:

1. Level abstraksi enterprise. Level ini merupakan level tertinggi, analisis ini mencakup seluruh enterprise sebagai satu sistem utuh.

2. Level abstraksi bisnis, analisis berusaha mendefinisikan kelas-kelas, objek­-objek, keterhubungan-keterhubungan, dan perilaku-perilaku yang memodelkan seluruh bisnis. Pada level enterprise dan bisnis dapat digabungkan dengan pendekatan rekayasa proses bisnis (BPE - Bussiness Process Engineering).

3. Level abstraksi area bisnis, analisis mendeskripasikan model analisis di suatu area bisnis tertentu.

4. Level abstraksi aplikasi, pemodelan berfokus pada kebutuhan pemesan yang spesifik yang berpengaruh pada aplikasi yang dibangun.

Pressman menyatakan untuk abstraksi menengah disebut analisis domain (domain analysis) dilakukan ketika organisasi ingin menciptakan pustaka dari kelas-kelas (komponen-komponen) yang dapat digunakan ulang yang secara luas dapat diaplikasikan ke seluruh kategori aplikasi.