setelah beberapa saat aku mengenalmu
semua jelas telah berubah
duniaku terpisah antara sesudah dan sebelum mengenalmu
ketika kau bernafas angin yang hangat berhembus
ketika kau tersenyum cahaya matahari yang menyilaukan bersinar
karena kau tinggal disana
karena itu memang kau
karena terkadang kau diam-diam bersandar dibahuku
kau tau aku benar-benar sangat bahagia
aku akan mengikutimu seiring berjalan dan berhentinya waktu
kadang-kadang aku memandangimu
karena aku tidak bisa berbuat apapun kecuali,
setiap moment bersamamu
Senin, 18 Mei 2015
Rabu, 21 September 2011
Resume PRPL Kelompok
Tugas Resume Kelompok 4
[ QOS, QOI, Analisis Cost dan Benefit ]
Nama Kelompok :
1. Nanda Surya S 08410100396
2. Ade Hari K 08410100400
3. Nita Maya S 08410100401
4. Farouk K 08410100408
5. Yuyun Eka W 08410100416
6. Bia Ardi P 08410100418
QOS (Quality Of Software)
-------------------------
- IEEE
- ISO
Definisi kualitas perangkat lunak
Apa sebenarnya merupakan kualitas produk sering menjadi subyek perdebatan panas. Definisi dapat dilihat dari berbagai perspektif
• Perspektif pengguna berkaitan dengan kesesuaian produk untuk konteks tertentu digunakan. Kitchenham dan Pfleeger
• Perspektif manufaktur mewakili kualitas sebagai kesesuaian dengan persyaratan. ISO 9001 dan Capability Maturity Model (CMM)
• Perspektif menyiratkan kualitas produk yang dapat dihargai dengan mengukur karakteristik yang melekat pada produk.
• Perspektif akhir berkualitas berbasis nilai. Perspektif ini mengakui bahwa kualitas perspektif yang berbeda mungkin memiliki kepentingan yang berbeda, atau nilai, ke berbagai pemangku kepentingan (Georgiadou, 2003b).
Spesifikasi dan evaluasi kualitas
Perangkat Lunak Rekayasa Kualitas panggilan untuk manajemen kualitas formal di seluruh siklus hidup. IEEE Std 1061-1998 (IEEE, 1998) mendefinisikan ini sebagai pendekatan top-down dan bottom-up dengan kualitas:
Dari perspektif top down memfasilitasi [kualitas] kerangka:
• Pembentukan faktor persyaratan mutu, pelanggan dan manajer awal siklus hidup sistem;
• Komunikasi faktor mutu yang ditetapkan, dalam hal kualitas-faktor sub, untuk tenaga teknis;
• Identifikasi metrics1 yang terkait dengan faktor mutu yang ditetapkan dan kualitas sub-faktor.
Dari perspektif bottom-up kerangka [kualitas] memungkinkan personel manajerial dan teknis untuk mendapatkan umpan balik oleh
• Mengevaluasi produk-produk perangkat lunak dan proses di tingkat metrik;
• Menganalisis nilai-nilai metrik untuk memperkirakan dan menilai faktor kualitas.
Evaluasi model kualitas
Tiga persyaratan yang model mutu harus miliki untuk menjadi landasan untuk Software
Rekayasa Kualitas telah diidentifikasi:
• Model kualitas harus mendukung lima perspektif yang berbeda kualitas sebagaimana didefinisikan oleh Kitchenham dan Pfleeger (1996);
• Sebuah model kualitas harus dapat digunakan dari atas ke bawah siklus hidup seperti yang didefinisikan oleh IEEE Std 1061-1998 (IEEE, 1998), yaitu harus memungkinkan untuk mendefinisikan persyaratan kualitas dan dekomposisi lebih lanjut mereka ke dalam kualitas yang sesuai karakteristik, subcharacteristics dan tindakan;
• Sebuah model kualitas harus dapat digunakan dari bawah ke atas siklus hidup seperti yang didefinisikan oleh IEEE Std 1061-1998 (IEEE, 1998), yaitu harus memungkinkan untuk pengukuran yang dibutuhkan dan agregasi berikutnya dan evaluasi hasil yang diperoleh.
Empat model kualitas akan dievaluasi sehubungan dengan persyaratan ini.
McCall’s
McCall, Richards, dan Walters (1977) memperkenalkan model kualitas di tahun 1977. Setiap faktor kualitas di sisi kiri gambar merupakan aspek kualitas yang tidak langsung terukur. McCall mengusulkan skema penilaian subjektif berkisar dari 0 (rendah) sampai 10 (tinggi).
Boehm’s
Model Boehm kualitas membaik pada karya McCall dan rekan-rekannya (Boehm, Brown, Kaspar, Lipow, & MacCleod, 1978). Seperti Gambar. 2 menunjukkan, model longgar mempertahankan kualitas pengaturan properti faktor-terukur. Namun, untuk Boehm dan rekan-rekannya, karakteristik utama mutu adalah apa yang mereka definisikan sebagai utilitas umum.
Dromey’s
Model Dromey’s (1995) mengambil pendekatan yang berbeda untuk kualitas perangkat lunak dibandingkan dengan dua model sebelumnya disajikan. Untuk Dromey, model kualitas jelas harus didasarkan pada sisi produk kualitas
o kebutuhan A dapat dianggap sebagai komponen dari model persyaratan;
o Modul dapat dianggap sebagai komponen model desain;
o Dll
Menurut Dromey, komponen ini semua memiliki sifat intrinsik yang dapat diklasifikasikan ke dalam empat kategori: Ketelitian, Internal, Kontekstual, Deskriptif: Ukur descriptiveness komponen (misalnya, apakah itu memiliki nama yang berarti?).
Properti ini digunakan untuk mengevaluasi kualitas komponen. Ini diilustrasikan pada Gambar. 4 untuk hadiah komponen variabel dalam model implementasi.
ISO / IEC 9126 model kualitas
Diperkenalkan Pada tahun 1991, oleh Organisasi Internasional untuk Standardisasi. Standar ini bertujuan untuk menentukan model kualitas untuk perangkat lunak dan seperangkat pedoman untuk mengukur karakteristik yang terkait dengannya. ISO / IEC 9126 cepat menjadi terkenal dengan spesialis IT di Eropa sebagai cara terbaik untuk menafsirkan dan mengukur kualitas (Bazzana, Anderson, & Jokela, 1993). Namun, Pfleeger (2001) melaporkan beberapa masalah penting yang berhubungan dengan rilis pertama dari ISO / IEC 9126:
• Tidak ada panduan tentang bagaimana memberikan penilaian secara keseluruhan kualitas.
• Tidak ada indikasi tentang bagaimana untuk melakukan pengukuran karakteristik kualitas.
• Alih-alih memfokuskan pada pandangan pengguna perangkat lunak, karakteristik model mencerminkan pandangan seorang pengembang perangkat lunak.
ISO / IEC 14598 pertama alamat kepedulian Pfleeger sementara revisi untuk ISO / IEC 9126 bertujuan untuk menyelesaikan masalah kedua dan ketiga. ISO / IEC 9126 sekarang menjadi standar bagian empat:
• ISO / IEC 9126-1 (ISO / IEC, 2001a) mendefinisikan model kualitas diperbarui.
• ISO / IEC 9126-2 (ISO / IEC, 2003a) mendefinisikan satu set langkah-langkah eksternal.
• ISO / IEC 9126-3 (ISO / IEC, 2003b) mendefinisikan satu set langkah-langkah internal.
• ISO / IEC 9126-4 (ISO / IEC, 2001b) mendefinisikan satu set kualitas dalam langkah-langkah digunakan.
Model kualitas baru yang didefinisikan dalam ISO / IEC 9126-1 mengakui tiga aspek kualitas perangkat lunak dan mendefinisikan mereka sebagai berikut: (definisi penuh diberikan karena berhubungan dengan diskusi yang terjadi kemudian).Kualitas yang digunakan:
• Kualitas eksternal:
• Kualitas internal:
Model kualitas internal dan eksternal ini terinspirasi dari kerja McCall dan Boehm’s. Ini adalah model tiga-lapis terdiri dari karakteristik kualitas, kualitas sub-karakteristik dan ukuran kualitas.
• ISO / IEC 9126-4, yang mendefinisikan kualitas digunakan, secara langsung berhubungan dengan pengguna dan perspektif berbasis nilai.
• ISO / IEC 9126-3, yang mendefinisikan mutu internal, dan ISO / IEC 9126-2, yang mendefinisikan mutu eksternal, secara langsung terkait dengan kedua perspektif manufaktur dan produk. Keandalan, Usability, Efisiensi, rawatan dan Portabilitas semua karakteristik yang melekat pada produk dan manifestasi dari perspektif kualitas produk (Gbr. 8).
Result
ISO / IEC 9126 adalah satu-satunya model yang mendukung semua perspektif kualitas (dengan pengecualian perspektif transendental seperti dicatat). Selanjutnya, kerangka prediksi yang jelas mendukung baik top down dan pendekatan bottom up. Makalah ini difokuskan pada analisis semantik dari model yang berbeda sehubungan dengan persyaratan lain. Secara teori, ISO / IEC 9126 tampaknya cocok untuk Kualitas Software Engineering.
QOI (Quality Of Information)
----------------------------
Karena ada begitu banyak informasi di luar sana, Para Profesional di bidang pengembangannya telah mendefinisikan beberapa karakteristik yang sangat penting. Berikut adalah kriteria utama yang digunakan untuk menentukan nilai informasi :
• AKURAT - informasi harus benar, diverifikasi, dan tidak menipu. Informasi karir akurat berdasarkan data empiris dan dapat divalidasi dengan membandingkan sumber atau memeriksa konsistensi internal.
• TETAP - informasi harus diterapkan untuk saat ini. Menjaga informasi saat ini membutuhkan proses menghilangkan yang lama dan menambahkan yang baru.Sementara beberapa jenis informasi lebih rusak daripada yang lain, secara umum diterima bahwa pendudukan dan informasi pendidikan harus ditinjau ulang dan diperbarui setidaknya setiap tahun untuk saat ini.
• RELEVAN - informasi yang relevan berlaku untuk kepentingan individu-individu yang menggunakannya untuk keputusan-keputusan yang mereka hadapi. Ini harus mengurangi ketidakpastian seseorang tentang pekerjaan dan pendidikan sementara memfasilitasi pilihan dan perencanaan. Karena kita tinggal dan bekerja di pasar kerja lokal daripada dalam yang nasional, baik deskripsi kondisi lokal, lebih relevan itu adalah untuk kita. Informasi negara dan lokal biasanya lebih berharga daripada nasional.
• KHUSUS/SPESIFIK - Untuk informasi lebih spesifik, harus mengandung fakta-fakta konkrit. Pengamatan umum sering menarik dan dapat memberikan latar belakang untuk analisa lebih lanjut, tetapi fakta-fakta tertentu yang penting untuk perencanaan yang realistis dan membuat keputusan.
• DIMENGERTI - Orang yang menggunakan informasi harus mampu memahaminya sebelum mereka dapat menggunakannya. Data harus dianalisis dan diubah menjadi kata-kata. Isi pesan harus menghindari ambiguitas dan informatif bagi penonton dimaksudkan.
• KOMPREHENSIF - Informasi tersebut harus mencakup semua kategori penting dalam ruang lingkup cakupan. Dalam CIS yang mencakup berbagai kesempatan kerja, program-program terkait pendidikan mereka studi dan pelatihan, dan sekolah-sekolah yang menawarkan mereka sebagai inti. Terkait dengan itu adalah informasi tentang uang untuk sekolah, mencari pekerjaan, pengusaha dan industri, bekerja untuk diri sendiri, dan sebagainya.
SEBANDING/DAPAT DIBANDINGKAN - Informasi yang disajikan harus seragam pengumpulan, analisis, isi, dan format sehingga Anda dapat membandingkan dan kontras berbagai pekerjaan, program studi, dan sekolah.
Analisis Cost / Benefit
------------------------
Analisis Cost-Benefit adalah sebuah analisis formal yang melihat dari ukuran atau program itu sendiri, dirancang untuk menilai apakah manfaat dari ukuran atau program yang lebih besar dari biaya yang dikeluarkan. Analisis Cost-Benefit merupakan salah satu set alat formal penilaian efisiensi. Efisiensi mengacu pada penilaian analisis yang dibuat untuk tujuan mengidentifikasi bagaimana menggunakan sumber daya yang langka untuk mendapatkan manfaat yang mungkin terbesar.
Analisis Cost-Benefit adalah teknik yang didasarkan pada ekonomi. Ada banyak buku yang menjelaskan secara rinci masalah yang dihadapi dalam analisis cost-benefit .
Langkah-langkah utama dari analisis cost-benefit adalah sebagai berikut:
• Mengembangkan langkah-langkah atau program yang dimaksud untuk membantu mengurangi masalah sosial tertentu.
• Mengembangkan pilihan alternatif untuk penggunaan setiap ukuran atau program.
• Menjelaskan skenario referensi (kadang-kadang disebut sebagai bisnis biasa atau alternatif yang tidak melakukan sesuatu)
• Mengidentifikasi dampak yang relevan dari setiap ukuran atau program. Biasanya akan ada
beberapa dampak yang relevan.
• Memperkirakan dampak dari tiap ukuran atau program untuk setiap pilihan kebijakan.
• Memperoleh perkiraan biaya dari masing-masing program untuk setiap pilihan kebijakan.
• Menerapkan penilaian yang tersedia dari dampak yang ada.
• Membandingkan manfaat dan biaya untuk setiap pilihan kebijakan untuk setiap ukuran atau program
• Mengidentifikasi pilihan-pilihan di mana manfaat yang lebih besar daripada biaya.
• Melakukan analisa sensitivitas atau penilaian formal ketidakpastian manfaat dan biaya.
Analisis Cost-Benefit biasanya diterapkan untuk membantu mencari solusi untuk masalah-masalah sosial yang tidak dapat diselesaikan oleh mekanisme pasar. Karakteristik masalah meliputi :
• Mereka melibatkan belanja publik, sering investasi. Proyek kadang-kadang dibiayai
dengan pembayaran pengguna langsung, tetapi lebih sering oleh pajak umum.
• Ada beberapa tujuan kebijakan, seringkali sebagian bertentangan dan membutuhkan pengorbanan untuk dibuat. Hal ini diasumsikan bahwa para pembuat kebijakan ingin solusi yang menyadari semua kebijakan tujuan semaksimal mungkin.
REFERENSI
[1] J.A. McCall, P.K. Richards, and G.F. Walters, Factors in Software Quality, Tehnical Report RADC-TR-77-369, US Department of Commerce, 1977.
[2] T.P. Bowen, G.B Wigle, and J.T. Tsai, Specification of Software Quality Attributes: Software Quality Evaluation Guidebook, Technical Report RADC-TR-85-37, Rome Air Development Center, Griffiss Air Force Base, 1985.
[3] IEEE Standard Glossary of Software Engineering Technology, IEEE Std 610.12-1990, Institute of Electrical and Electronics Engineers, New York, 1990.
[4] Hans Van Vliet, Software Engineering – Principles and Practice, John Wiley & Sons, 2000.
[5] James F. Peters and Witold Pedrycz, Software Engineering: An Engineering Approach, John Wiley & Sons, 2000.
[6] http://romisatriawahono.net/2006/06/05/teknik-pengukuran-kualitas-perangkat-lunak/
[7] http://cahayakasih.students-blog.undip.ac.id/2010/11/07/artikel-5-software-quality/
[8] http://dimas347.wordpress.com/2009/06/28/software-quality-management/
[9] http://www.docstoc.com/docs/20597020/MUTU-PERANGKAT-LUNAK
[ QOS, QOI, Analisis Cost dan Benefit ]
Nama Kelompok :
1. Nanda Surya S 08410100396
2. Ade Hari K 08410100400
3. Nita Maya S 08410100401
4. Farouk K 08410100408
5. Yuyun Eka W 08410100416
6. Bia Ardi P 08410100418
QOS (Quality Of Software)
-------------------------
- IEEE
- ISO
Definisi kualitas perangkat lunak
Apa sebenarnya merupakan kualitas produk sering menjadi subyek perdebatan panas. Definisi dapat dilihat dari berbagai perspektif
• Perspektif pengguna berkaitan dengan kesesuaian produk untuk konteks tertentu digunakan. Kitchenham dan Pfleeger
• Perspektif manufaktur mewakili kualitas sebagai kesesuaian dengan persyaratan. ISO 9001 dan Capability Maturity Model (CMM)
• Perspektif menyiratkan kualitas produk yang dapat dihargai dengan mengukur karakteristik yang melekat pada produk.
• Perspektif akhir berkualitas berbasis nilai. Perspektif ini mengakui bahwa kualitas perspektif yang berbeda mungkin memiliki kepentingan yang berbeda, atau nilai, ke berbagai pemangku kepentingan (Georgiadou, 2003b).
Spesifikasi dan evaluasi kualitas
Perangkat Lunak Rekayasa Kualitas panggilan untuk manajemen kualitas formal di seluruh siklus hidup. IEEE Std 1061-1998 (IEEE, 1998) mendefinisikan ini sebagai pendekatan top-down dan bottom-up dengan kualitas:
Dari perspektif top down memfasilitasi [kualitas] kerangka:
• Pembentukan faktor persyaratan mutu, pelanggan dan manajer awal siklus hidup sistem;
• Komunikasi faktor mutu yang ditetapkan, dalam hal kualitas-faktor sub, untuk tenaga teknis;
• Identifikasi metrics1 yang terkait dengan faktor mutu yang ditetapkan dan kualitas sub-faktor.
Dari perspektif bottom-up kerangka [kualitas] memungkinkan personel manajerial dan teknis untuk mendapatkan umpan balik oleh
• Mengevaluasi produk-produk perangkat lunak dan proses di tingkat metrik;
• Menganalisis nilai-nilai metrik untuk memperkirakan dan menilai faktor kualitas.
Evaluasi model kualitas
Tiga persyaratan yang model mutu harus miliki untuk menjadi landasan untuk Software
Rekayasa Kualitas telah diidentifikasi:
• Model kualitas harus mendukung lima perspektif yang berbeda kualitas sebagaimana didefinisikan oleh Kitchenham dan Pfleeger (1996);
• Sebuah model kualitas harus dapat digunakan dari atas ke bawah siklus hidup seperti yang didefinisikan oleh IEEE Std 1061-1998 (IEEE, 1998), yaitu harus memungkinkan untuk mendefinisikan persyaratan kualitas dan dekomposisi lebih lanjut mereka ke dalam kualitas yang sesuai karakteristik, subcharacteristics dan tindakan;
• Sebuah model kualitas harus dapat digunakan dari bawah ke atas siklus hidup seperti yang didefinisikan oleh IEEE Std 1061-1998 (IEEE, 1998), yaitu harus memungkinkan untuk pengukuran yang dibutuhkan dan agregasi berikutnya dan evaluasi hasil yang diperoleh.
Empat model kualitas akan dievaluasi sehubungan dengan persyaratan ini.
McCall’s
McCall, Richards, dan Walters (1977) memperkenalkan model kualitas di tahun 1977. Setiap faktor kualitas di sisi kiri gambar merupakan aspek kualitas yang tidak langsung terukur. McCall mengusulkan skema penilaian subjektif berkisar dari 0 (rendah) sampai 10 (tinggi).
Boehm’s
Model Boehm kualitas membaik pada karya McCall dan rekan-rekannya (Boehm, Brown, Kaspar, Lipow, & MacCleod, 1978). Seperti Gambar. 2 menunjukkan, model longgar mempertahankan kualitas pengaturan properti faktor-terukur. Namun, untuk Boehm dan rekan-rekannya, karakteristik utama mutu adalah apa yang mereka definisikan sebagai utilitas umum.
Dromey’s
Model Dromey’s (1995) mengambil pendekatan yang berbeda untuk kualitas perangkat lunak dibandingkan dengan dua model sebelumnya disajikan. Untuk Dromey, model kualitas jelas harus didasarkan pada sisi produk kualitas
o kebutuhan A dapat dianggap sebagai komponen dari model persyaratan;
o Modul dapat dianggap sebagai komponen model desain;
o Dll
Menurut Dromey, komponen ini semua memiliki sifat intrinsik yang dapat diklasifikasikan ke dalam empat kategori: Ketelitian, Internal, Kontekstual, Deskriptif: Ukur descriptiveness komponen (misalnya, apakah itu memiliki nama yang berarti?).
Properti ini digunakan untuk mengevaluasi kualitas komponen. Ini diilustrasikan pada Gambar. 4 untuk hadiah komponen variabel dalam model implementasi.
ISO / IEC 9126 model kualitas
Diperkenalkan Pada tahun 1991, oleh Organisasi Internasional untuk Standardisasi. Standar ini bertujuan untuk menentukan model kualitas untuk perangkat lunak dan seperangkat pedoman untuk mengukur karakteristik yang terkait dengannya. ISO / IEC 9126 cepat menjadi terkenal dengan spesialis IT di Eropa sebagai cara terbaik untuk menafsirkan dan mengukur kualitas (Bazzana, Anderson, & Jokela, 1993). Namun, Pfleeger (2001) melaporkan beberapa masalah penting yang berhubungan dengan rilis pertama dari ISO / IEC 9126:
• Tidak ada panduan tentang bagaimana memberikan penilaian secara keseluruhan kualitas.
• Tidak ada indikasi tentang bagaimana untuk melakukan pengukuran karakteristik kualitas.
• Alih-alih memfokuskan pada pandangan pengguna perangkat lunak, karakteristik model mencerminkan pandangan seorang pengembang perangkat lunak.
ISO / IEC 14598 pertama alamat kepedulian Pfleeger sementara revisi untuk ISO / IEC 9126 bertujuan untuk menyelesaikan masalah kedua dan ketiga. ISO / IEC 9126 sekarang menjadi standar bagian empat:
• ISO / IEC 9126-1 (ISO / IEC, 2001a) mendefinisikan model kualitas diperbarui.
• ISO / IEC 9126-2 (ISO / IEC, 2003a) mendefinisikan satu set langkah-langkah eksternal.
• ISO / IEC 9126-3 (ISO / IEC, 2003b) mendefinisikan satu set langkah-langkah internal.
• ISO / IEC 9126-4 (ISO / IEC, 2001b) mendefinisikan satu set kualitas dalam langkah-langkah digunakan.
Model kualitas baru yang didefinisikan dalam ISO / IEC 9126-1 mengakui tiga aspek kualitas perangkat lunak dan mendefinisikan mereka sebagai berikut: (definisi penuh diberikan karena berhubungan dengan diskusi yang terjadi kemudian).Kualitas yang digunakan:
• Kualitas eksternal:
• Kualitas internal:
Model kualitas internal dan eksternal ini terinspirasi dari kerja McCall dan Boehm’s. Ini adalah model tiga-lapis terdiri dari karakteristik kualitas, kualitas sub-karakteristik dan ukuran kualitas.
• ISO / IEC 9126-4, yang mendefinisikan kualitas digunakan, secara langsung berhubungan dengan pengguna dan perspektif berbasis nilai.
• ISO / IEC 9126-3, yang mendefinisikan mutu internal, dan ISO / IEC 9126-2, yang mendefinisikan mutu eksternal, secara langsung terkait dengan kedua perspektif manufaktur dan produk. Keandalan, Usability, Efisiensi, rawatan dan Portabilitas semua karakteristik yang melekat pada produk dan manifestasi dari perspektif kualitas produk (Gbr. 8).
Result
ISO / IEC 9126 adalah satu-satunya model yang mendukung semua perspektif kualitas (dengan pengecualian perspektif transendental seperti dicatat). Selanjutnya, kerangka prediksi yang jelas mendukung baik top down dan pendekatan bottom up. Makalah ini difokuskan pada analisis semantik dari model yang berbeda sehubungan dengan persyaratan lain. Secara teori, ISO / IEC 9126 tampaknya cocok untuk Kualitas Software Engineering.
QOI (Quality Of Information)
----------------------------
Karena ada begitu banyak informasi di luar sana, Para Profesional di bidang pengembangannya telah mendefinisikan beberapa karakteristik yang sangat penting. Berikut adalah kriteria utama yang digunakan untuk menentukan nilai informasi :
• AKURAT - informasi harus benar, diverifikasi, dan tidak menipu. Informasi karir akurat berdasarkan data empiris dan dapat divalidasi dengan membandingkan sumber atau memeriksa konsistensi internal.
• TETAP - informasi harus diterapkan untuk saat ini. Menjaga informasi saat ini membutuhkan proses menghilangkan yang lama dan menambahkan yang baru.Sementara beberapa jenis informasi lebih rusak daripada yang lain, secara umum diterima bahwa pendudukan dan informasi pendidikan harus ditinjau ulang dan diperbarui setidaknya setiap tahun untuk saat ini.
• RELEVAN - informasi yang relevan berlaku untuk kepentingan individu-individu yang menggunakannya untuk keputusan-keputusan yang mereka hadapi. Ini harus mengurangi ketidakpastian seseorang tentang pekerjaan dan pendidikan sementara memfasilitasi pilihan dan perencanaan. Karena kita tinggal dan bekerja di pasar kerja lokal daripada dalam yang nasional, baik deskripsi kondisi lokal, lebih relevan itu adalah untuk kita. Informasi negara dan lokal biasanya lebih berharga daripada nasional.
• KHUSUS/SPESIFIK - Untuk informasi lebih spesifik, harus mengandung fakta-fakta konkrit. Pengamatan umum sering menarik dan dapat memberikan latar belakang untuk analisa lebih lanjut, tetapi fakta-fakta tertentu yang penting untuk perencanaan yang realistis dan membuat keputusan.
• DIMENGERTI - Orang yang menggunakan informasi harus mampu memahaminya sebelum mereka dapat menggunakannya. Data harus dianalisis dan diubah menjadi kata-kata. Isi pesan harus menghindari ambiguitas dan informatif bagi penonton dimaksudkan.
• KOMPREHENSIF - Informasi tersebut harus mencakup semua kategori penting dalam ruang lingkup cakupan. Dalam CIS yang mencakup berbagai kesempatan kerja, program-program terkait pendidikan mereka studi dan pelatihan, dan sekolah-sekolah yang menawarkan mereka sebagai inti. Terkait dengan itu adalah informasi tentang uang untuk sekolah, mencari pekerjaan, pengusaha dan industri, bekerja untuk diri sendiri, dan sebagainya.
SEBANDING/DAPAT DIBANDINGKAN - Informasi yang disajikan harus seragam pengumpulan, analisis, isi, dan format sehingga Anda dapat membandingkan dan kontras berbagai pekerjaan, program studi, dan sekolah.
Analisis Cost / Benefit
------------------------
Analisis Cost-Benefit adalah sebuah analisis formal yang melihat dari ukuran atau program itu sendiri, dirancang untuk menilai apakah manfaat dari ukuran atau program yang lebih besar dari biaya yang dikeluarkan. Analisis Cost-Benefit merupakan salah satu set alat formal penilaian efisiensi. Efisiensi mengacu pada penilaian analisis yang dibuat untuk tujuan mengidentifikasi bagaimana menggunakan sumber daya yang langka untuk mendapatkan manfaat yang mungkin terbesar.
Analisis Cost-Benefit adalah teknik yang didasarkan pada ekonomi. Ada banyak buku yang menjelaskan secara rinci masalah yang dihadapi dalam analisis cost-benefit .
Langkah-langkah utama dari analisis cost-benefit adalah sebagai berikut:
• Mengembangkan langkah-langkah atau program yang dimaksud untuk membantu mengurangi masalah sosial tertentu.
• Mengembangkan pilihan alternatif untuk penggunaan setiap ukuran atau program.
• Menjelaskan skenario referensi (kadang-kadang disebut sebagai bisnis biasa atau alternatif yang tidak melakukan sesuatu)
• Mengidentifikasi dampak yang relevan dari setiap ukuran atau program. Biasanya akan ada
beberapa dampak yang relevan.
• Memperkirakan dampak dari tiap ukuran atau program untuk setiap pilihan kebijakan.
• Memperoleh perkiraan biaya dari masing-masing program untuk setiap pilihan kebijakan.
• Menerapkan penilaian yang tersedia dari dampak yang ada.
• Membandingkan manfaat dan biaya untuk setiap pilihan kebijakan untuk setiap ukuran atau program
• Mengidentifikasi pilihan-pilihan di mana manfaat yang lebih besar daripada biaya.
• Melakukan analisa sensitivitas atau penilaian formal ketidakpastian manfaat dan biaya.
Analisis Cost-Benefit biasanya diterapkan untuk membantu mencari solusi untuk masalah-masalah sosial yang tidak dapat diselesaikan oleh mekanisme pasar. Karakteristik masalah meliputi :
• Mereka melibatkan belanja publik, sering investasi. Proyek kadang-kadang dibiayai
dengan pembayaran pengguna langsung, tetapi lebih sering oleh pajak umum.
• Ada beberapa tujuan kebijakan, seringkali sebagian bertentangan dan membutuhkan pengorbanan untuk dibuat. Hal ini diasumsikan bahwa para pembuat kebijakan ingin solusi yang menyadari semua kebijakan tujuan semaksimal mungkin.
REFERENSI
[1] J.A. McCall, P.K. Richards, and G.F. Walters, Factors in Software Quality, Tehnical Report RADC-TR-77-369, US Department of Commerce, 1977.
[2] T.P. Bowen, G.B Wigle, and J.T. Tsai, Specification of Software Quality Attributes: Software Quality Evaluation Guidebook, Technical Report RADC-TR-85-37, Rome Air Development Center, Griffiss Air Force Base, 1985.
[3] IEEE Standard Glossary of Software Engineering Technology, IEEE Std 610.12-1990, Institute of Electrical and Electronics Engineers, New York, 1990.
[4] Hans Van Vliet, Software Engineering – Principles and Practice, John Wiley & Sons, 2000.
[5] James F. Peters and Witold Pedrycz, Software Engineering: An Engineering Approach, John Wiley & Sons, 2000.
[6] http://romisatriawahono.net/2006/06/05/teknik-pengukuran-kualitas-perangkat-lunak/
[7] http://cahayakasih.students-blog.undip.ac.id/2010/11/07/artikel-5-software-quality/
[8] http://dimas347.wordpress.com/2009/06/28/software-quality-management/
[9] http://www.docstoc.com/docs/20597020/MUTU-PERANGKAT-LUNAK
Senin, 19 September 2011
Resume Sistem Pakar Pert-2
RULE BASE SYSTEM
Apakah Rule itu ?
Suatu model pola untuk representasikan science yang penting.
Bila ada pertanyaan tentang
- bagaimana selesaikan masalah
- apa sebabnya sehingga dapat gambarkan kesimpulan yang pasti.
- Jawabanya akan merespon khusus dgn sampaikan science kedalam format Rule.
Contoh :
• Saya diberitahu bahwa A, B dan C terlibat dalam masalah, dari ketiga fakta tersebut dinyatakan bahwa D adalah benar.
• Jika A, B dan C terlibat, maka kita dapat akhirinya dengan D.
• Hal alami yang ditransfer ke science akan tepat bila gunakan format ini.
• Khusus kebenaran untuk bid science dapat diakumulasi banyak waktu untuk hasilkan kedalam asosiasi empiris internal. (contoh: heuristic).
• Guna representasikan science tersebut dapat digunakan dengan format IF-THEN
Ø IF dinyatakan sebagai kondisi (juga disebut sbg perkiraan),dimana kenyataan merupakan uji nilai kebenaran
Ø Jika hal ini ditemukan kebenaran data, bagian THEN pada aturan (juga disebut action, kesimpulan atau sebagai akibat) adalah diduga sebagai kenyataan yg baru.
Ø Aturan ini dpt digunakan utk percepat penggabungan pada range yang lebar.
Ø Secara garis besar ada 3 kriteria a.l.:
- Aksi dan situasi
- Anggapan dan kesimpulan
- Prioritas dan konsekuensi
Contoh masing-masing kriteria adl :
AKSI DAN SITUASI :
• Jika awan gelap menggulung dr Barat, angin meningkat dan halilintar menerpa, maka kalian dapat mencari sudut dalam ruangan (berlindung).
• Jika kamu mengemudi mobil dan keadaan darurat mendekat, maka kamu dapat memperlambat dan minggir untuk mengijinkan darurat tersebut bebas.
• Jika memasak kue dengan disertai tusuk gigi, dan jika tusuk gigi dalam cake dipindah/dicabut ternyata tidak ada adonan pada tusuk gigi tersebut, maka cake dapat dipindahkan dari oven.
ANGGAPAN DAN KESIMPULAN
• Jika suhu sekitarmu diatas 99o, maka kamu akan menjadi kegerahan.
• Jika suhu diluar dibawah titik beku, ukuran bensin dimobilmu indiksdi penuh dan mesin tidak bisa dihidupkan, maka kemungkinan besar ada pembekuan pada pipa bensin.
PRIORITAS DAN KONSEKUENSINYA :
• Jika X adalah kucing, maka X adalah kelompok binatang
• Jika saluran kamar mandi disumbat dan air mengalir kesebelah kiri, maka lantai akan menjadi basah.
Rule Based Inference
Fakta A adalah benar
Operation A→ B adalah benar
maka Fakta B adalah didapatkan benar.
Menggunakan teknik pelacakan dan penyesuaian pola rule-based-system otomatis metode penalaran dan penyediaan progressing logic dari data awal menuju ke kesimpulan. Sebab-2 kemajuan yg baru mrpk sarana untuk selesaikan masalah.
Untuk ilustrasinya diperhatikan contoh membuat suatu knowledge-base-system pd ramalan cuaca selama 12 s/d 24 jam di Florida pd musim panas.
Rule 1 : IF suhu lingkungan diatas 90o F
THEN cuaca panas
Dari rule 1 dapat dikembangkan dg dibuat aturan yg ber rantai sehingga akan bisa mendekati kesimpulan.
Rule 2 : IF kelembaban relatif diatas 65%
THEN atmosfer lembab
Rule 3 : IF cuaca panas & atmosfer lembab
THEN hujan angin kemungkinan bertambah
Pada penanganan lain, statement ini dianggap benar dg menggunakan knowledge based system
Suhu yang ada 92oF
and
Kelembaban relatif adalah 70%
Rule 1 dan 2 melihat kenyataan dan menarik kesimpulan akan mengikuti fakta yg baru.
Udara lembab dan cuaca panas
Memenuhi perkiraan Rule 3, menyebabkan ter-dapat fakta baru :
Hujan angin kemungkinan akan berkembang
Tentunya contoh sederhana ini, sebuah rule dpt dituliskan sbb:
Rule 1 IF suhu diatas 90o F dan
udara memp kelembaban relatif > 65 %
THEN hujan angin kemungkinan akan datamg
Proses Penalaran
Proses penalaran dari rule-based-system merupakan kemajuan dari setting data untuk mencapai penyelesaian ataupun kesimpulan.
Seorg dokter melakukan diagnose pasiennya diperlukan data yang lebih banyak untuk mengambil kesimpulan tentang penyakit yang diderita.
Secara garis besar ada 2 pengertian kemajuan tentang kesimpulan yang diambil :
• Diawali dg pengumpulan seluruh data dan kemajuan alami untuk mencapai pd kesimpulan.
• Memilih kesimpulan yang memungkinkan dan mencoba untuk membuktikan validitas dengan melihat dukunngan kejadian.
Contoh : Mengidentifikasi perbedaan jenis buah-buahan dengan membuat beberapa rule dan diuji karakter fisiknya.
Keuntungan Representasi dengan Rule-Based
Bab 4.7. Buku Gonzales Hal. 108
- Modularity :
Karena setiap rule pada KBS dibagi secara jelas, maka mudah dan flexibel bagi knowledge engineer untuk menambah, memodifikasi, menghapus rule yang ada.
- Uniformity :
Semua Knowledge pada sistem mempunyai format yang sama
- Naturalness :
Rule adalah ekspresi yang natural dari Knowledge
Kerugian representasi dengan Rule-Based
- In-efficiency :
Exekusi untuk pencocokan rule dan fakta memerlukan waktu yang lama (Setiap 1 cycle, harus menguji banyak rule).
- Coverage Domain :
Berbeda permasalahan, akan beda rule dan setiap domain permasalahan akan memerlukan puluhan bahkan ratusan rule.
Langganan:
Postingan (Atom)