pemeliharaan perangkat lunak

 Pendahuluan
 Istilah pemeliharaan perangkat lunak digunakan untuk menjabarkan aktivitas dari analis sistem (software engineering) yang terjadi pada saat hasil produk perangkat lunak sudah dipergunakan oleh pemakai (user).
 Biasanya pengembangan produk perangkat lunak memerlukan waktu antara 1 sampai dengan 2 tahun, tetapi pada pase pemeliharaan perangkat lunak menghabiskan 5 sampai dengan 10 tahun
 Aktivitas yang terjadi pada pase pemeliharaan antara lain:

 Penambahan atau peningkatan atau juga perbaikan untuk produk perangkat lunak
 Adaptasi produk dengan lingkungan mesin yang baru
 Pembetulan permasalahan yang timbul

 Aktivitas pada penambahan atau perbaikan produk perangkat lunak :


 Penambahan fungsi-fungsi baru
 Perbaikan tampilan dan modus interaktif
 Perbaharui dokumen ekstemal
 Perbaharui dokumentasi internal
 Perbaharui karakteristik perfomansi dari system

 Adaptasi terhadap lingkungan yang baru mencakup aktivitas:

 Pemindahan perangkat lunak ke mesin yang berlainan
 Modifikasi untuk dapat mempergunakan protokol atau disk drive tambahan


 Sedangkan pada pembetulan mencakup aktivitas:

 Pembenaran kesalahan yang timbul setelah produk perangkat lunak dipergunakan oleh user (pemakai)

 Aktivitas pemeliharaan
 Pemeliharaan PL menghabiskan biaya terbesar dari seluruh anggaran pengembangan atau pembuatan perangkat lunak.
 Pemeliharaan menghabiskan 70% dari seluruh biaya pengembangan perangkat lunak.
 Pase pemeliharaan sekitar 60% digunakan untuk anggaran penambahan atau perhaikan perangkat lunak, sisanya untuk adaptasi atau pembetulan.

 Atribut utama dari perangkat lunak yang mudah dalam pemeliharaan
 Perangkat lunak dikerjakan per modul
 Perangkat lunak mempunyai kejelasan
 Dokumentasi internal yang baik dan jelas
 Dokumen-dokumen pendukung lainnya

 Pemeliharaan perangkat lunak dapat dibedakan menjadi:
 Corrective Maintenance
Corrective maintenance terjadi pada saat produk dipakai dan hasil yang didapat oleh pamakai baik berupa kesalahan yang timbul maupun kesalahan dalam bentuk keluaran yang tidak sesuai.
 Adaptive maintenance
Aktivitas yang kedua ini terjadi karena pertumbuhan atau perkembangan perangkat lunak atau perangkat keras sehingga memerlukan modifikasi dari perangkat lunak yang telah dibuat.
 Perfective maintenance
Aktivitas ini terjadi pada saat perangkat lunak yang telah dibuat dan dilakukan uji cobs kemudian dipergunakan oleh user. Setelah dipergunakan oleh user mungkin timbul permintaan tambahan fungsi sesuai dengan keinginan pemakai.
 Preventive maintenance
Pemeliharaan yang terakhir dilakukan untuk menghadapi kemajuan perangkat lunak atau perangkat keras di masa mendatang, umpamanya penambahan fungsi­fungsi atau melengkapi fungsi-fungsi yang telah ada.

 Karakteristik Pemeliharaan
 Pemeliharaan terstruktur dan tidak terstruktur
 Biaya pemeliharaan

 Aliran tindakan permintaan pemeliharaan
 1.a. Pemeliharaan terstruktur
 Pada gambar di atas terlihat pemeliharaan terstruktur dimulai dari permintaan akan pemeliharaan dan menentukan konfigurasi dari perangkat lunak yang akan diadakan pemeliharaan. Jika merupakan seluruh perangkat lunak maka tindakan yang diambil adalah evaluasi perancangan dan menentukan rencana pendekatan yang akan digunakan untuk melakukan pemeliharaan. Kemudian dilanjutkan dengan melaku­kan modifikasi+perancangan dan penulisan ulang program (rekode). Langkah terakhir adalah me-review program yang telah ditulis. Jika diterima maka berarti tugas pemeliharaan telah selesai. Sedangkan jika konfigurasi merupakan program per modul maka kegiatan yang dilakukan adalah evaluasi program. Jika diperlukan modifikasi yang cukup besar maka tindakan yang diambil adalah pembuatan ulang yang dilanjutkan dengan review hasil. Jika hasil akhir memenuhi kriteria maka berarti perangkat lunak siap.
 1.b. Pemeliharaan tidak terstruktur
 Tidak mempunyai dokumentasi yang baik
 Tidak menggunakan metodologi perancangan
 Tidak mengikuti langkah-langkah di atas

 2. Biaya pemeliharaan

 Biaya pemeliharaan perangkat lunak yang dikeluarkan dalam pase pemeliharaan meningkat dengan cepat, hal ini dapat dilihat pada gambar herikut:

Selain biaya yang umum dalam pase pengembangan Bering timbul biaya-biaya tak berwujud (intangible cost). Biaya-biaya ini ditimbulkan karena:
 Ketidakpuasan pemakai (user) akibat tidak selesainya perangkat lunak sesuai dengan waktu yang telah ditentukan pada pase pemeliharaan
 Pengurangan kualitas perangkat lunak
 Penambahan tenaga kerja baru

 Maintainability

Maintainability dapat didefinisikan kemudahan dalam mengerti perangkat lunak, pcmbenaran, adaptasi dan atau perbaikan. Faktor-faktor yang mempengaruhi maintanability:
 Control
 Ukuran kuantitatif

 1. Kontrol
 Pokok-pokok maintainability dari perangkat lunak dipengaruhi oleh perancangan, pengkodean dan uji coba yang jelas mempunyai pengaruh jelek pada kemampuan pemeliharaan dari perangkat lunak yang dihasilkan, begitu juga konfigurasi perangkat lunak yang jelek menghasilkan pengaruh yang buruk.

Sejumlah fak'tor yang mempunyai hubungan dengan lingkungan pengembangan dan kontrol adalah:
 Staf yang memenuhi syarat
 Kemudahan dalam mengerti sistem
 Mudah dalam menangani sistem
 Mudah dalam standarisasi bahasa pemrograman
 Mudah dalam standarisasi sistem operasi
 Tersedianya test case
 Perangkat keras yang tepat untuk pengerjaan pemeliharaan

 2. Ukuran kuantitatif

Ukuran kuantitatif dari suatu maintainability perangkat lunak secara tidak langsung berpengaruh pada aktivitas pemeliharaan. Berikut akan dijabarkan sejumlah metrik (ukuran) maintainability yang mempunyai pengaruh dalam aktivitas pemeliharaan:
 Waktu pengenalan masalah
 Waktu delay (tunda) administrasi
 Alat bantu pemeliharaan
 Waktu analisis permasalahan
 Waktu perubahan spesifikasi
 Waktu modifikasi (pembenaran)
 Waktu uji coba
 Waktu total


 Perbaikan Maintainability Selama Pengembangan

• Aktivitas analisis
• Aktivitas perancangan artsitektural
• Aktivitas perancangan terinci
• Aktivitas penerapan
• Aktivitas lainnya

 Aktivitas analisis:

 Mengembangkan standarisasi petunjuk
 Menentukan kendala untuk dokumen pendukung
 Menentukan prosedur yang menjamin kualitas
 Menentukan perbaikan produk
 Menentukan sumber daya yang diperlukan untuk pemeliharaan
 Memperkirakan biaya pemeliharaan

 Aktivitas perancangan artsitektural:

 Menekankan kejelasan dan modularity sebagai kriteria perancangan
 Merancang kemudahan-kemudahan dalam perbaikan
 Menggunakan notasi standard untuk dokumentasi jari aliran data, fungi, struktur, dan lain-lain
 Menggunakan prinsip informasi hiding, data abstraction, dan dekomposisi hirarki top down (atas bawah)

 Aktivitas perancangan terinci:

 Menggunakan notasi standar untuk algoritma, struktur data, prosedur
 Menentukan pengaruh yang ditimbulkan dan penangan hal-hal yang ditimbulkan

 Aktivitas penerapan:
 Menggunakan prinsip penyusunan sate masukan dan satu keluaran
 Menggunakan standar penyusunan
 Menggunakan gaya pengkodean yang jelas dan simpel
 Menyediakan dokumentasi singkat untuk setiap modul
 Mengikuti petunjuk pada dokumentasi standar


 Aktivitas lainnya:

 Mengembangan petunjuk pemeliharaan
 Mengembangkan uji coba yang cocok
 Menyediakan dokumentasi uji coba

 Tugas Pemeliharaan
Tugas yang ada pada pemeliharaan sebetulnya telah dipersiapkan sebelum terjadinya permintaan pemeliharaan. Tugas ini diawali dengan pembentukan: organisasi pemeliharaan (baik secara informal atau secara formal), prosedur pelaporan dan evaluasi harus dijabarkan dan urutan tindakan ditentukan untuk masing-masing permintaan pemeliharaan. Selain itu sistem pencatatan untuk aktivitas pemeliharaan juga harus ditentukan, review dan kriteria evaluasi didefinisikan.


 Bentuk tanggung jawab organisasi pemeliharaan
 Pelaporan

 Seluruh permintaan akan pemeliharaan seharusnya dibuat dalam satu bentuk formulir standar. Umumnya pembuat atau pengembangan perangkat lunak membuat satu bentuk formulir atau dokumentasi standar untuk permintaan pemeliharaan yang dikenal dengan nama Maintenance Request Form (MRF atau formulir permintaan pemeliharaan) atau Software Problem Request (laporan permasalahan perangkat lunak).

Jika diketemukan kesalahan oleh pemakai pada perangkat lunak, maka deskrip~i dari keadaan yang menimbulkan kesalahan dijabarkan secara lengkap (meliputi pemasukan data, uji coba, dan lain-lain) MRF adalah dokumen yang digunakan sebagai dasar untuk perencanaan tugas pemeliharaan. Biasanya organisasi pembu;at atau pengembangan perangkat lunak mengembangkan Software Change Report (SCR atau laporan perubahan perangkat lunak) yang berisikan:
 Usaha yang dilakukan untuk memenuhi MRF
 Modifikasi yang diperlukan
 Priortitas permintaan
 Perkiraan hasil modifikasi

SCR ini nantinya akan diajukan ke hak kontrol perubahan &belum perencanaan pemeliharaan dimulai.

 Aliran tindakan
 Pencatatan

Pencatatan merupakan aktivitas yang tidak dapat ditinggalkan pada pemeliharaan, karena pada pencatatan akan digunakan untuk mengukur kualitas dari program yang telah dimodifikasi.
 Data yang dicatat antara lain:
 Identifikas program
 Jumlah ban perintah dari program cumber
 Jumlah instruksi yang berorientasi ke bahasa mesin
 Bahasa pemrograman yang digunakan
 Tanggal pemasangan program
 Jumlah program yang dapat di-run (dijalankan) semenjak dipasang (diinstall)
 Jumlah proses yang gagal digabungkan dengan nomor 6
 Tingkat perubahan program dan identifikasi
 Jumlah penambahan perintah pada program yang diuhah
 Jumlah penghapusan perintah pada program yang diubah
 Jumlah jam kerja yang dihabiskan pada perubahan
 Tanggal perubahan program
 Identifikasi dari software engineering
 Identifikasi dari MRF
 Tipe pemeliharaan
 Tanggal awal dan berakhir pemeliharaan
 Jumlah total jam kerja pada aktivitas pemeliharaan
 Manfaat yang didapat dari aktivitas pemeliharaan

 Evaluasi
Eavluasi biasanya jarang dilakukan karena kurangnya data yang dicatat, apabila pencatatan dilakukan dengan benar, maka dapat dilakukan evaluasi. Evaluasi dilakukan terhadap:
 Jumlah rata-rata kegagalan proses per program pada saat dipasang
 Jumlah total waktu yang dihabiskan untuk masing-masing kategori pemeliharaan
 Jumlah rata-rata perubahan program yang dilakukan per bahasa program atau per tipe pemeliharaan
 Jumlah rata-rata yang dilukiskan untuk penambahan atau penghapusan baris perintah dari program yang diubah
 Jumlah rata-rata yang dihabiskan per bahasa
 Persentase permintaan pemeliharaan per tipe (lihat aliran tindakan)

 Any Questions?
End of Session

strategi pengujian perangkat (9)

 Strategi Pengujian Perangkat Lunak
 By
 Kustanto

 Pendekatan Strategis ke pengujian perangkat lunak
 Pengujian Unit
 Pengujian Integrasi
 Pengujian Validasi
 Pengujian Sistem
 Debugging
 Pengujian Unit
 Berfokus pada inti terkecil dari desain perangkat lunak yaitu modul
 Biasanya berorientasi pada white box

 Pengujian Unit
 Checklist untuk pengujian interface
 Apakah jumlah parameter input sama dengan jumlah argumen?
 Apakah antara atribut dan parameter argumen sudah cocok?
 Apakah antara sistem satuan parameter dan argumen sudah cocok?
 Apakah jumlah argumen yang ditransmisikan ke modul yang dipanggil sama dengan atribut parameter?
 Pengujian Unit
 Apakah atribut dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan atribut parameter?
 Apakah sistem unit dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan sistem satuan parameter?
 Apakah jumlah atribut dan urutan argumen ke fungsi-fungsi built-in sudah benar?
 Adakah referensi ke parameter yang tidak sesuai dengan poin entri yang ada?
 Apakah argumen input only diubah?

 Pengujian Unit
 Apakah definisi variabel global konsisten dengan modul ?
 Apakah batasan yang dilalui merupakan argumen?
 Debugging
 Trace message
 Output designed to record the path of execution and display strategic values
 Stack trace
 Output showing sequence of method calls awaiting return relative to current statement
 new Throwable().printStackTrace();
 Logger
 An object used to control the output of debugging messages
 Display messages at strategic locations:
 Logger.global.info("message");
 Turn logging off and on using the setLevel method
 Logger.global.setLevel(Level.OFF);
 Debugging
 Pernyataan (Assertions)
 A condition that will cause an error if false
 Often used to verify pre- and post-conditions
 Use a debugger
 Breakpoints
 Single-stepping
 Inspection of variables
 JGrasp Debugger
 Compile with Debug support
 Set a breakpoint
 Run under debugger

 JGrasp Debugger
 Execution halts at breakpoint
 JGrasp Debugger
 Executing next statement instantiates an object
 JGrasp Debugger
 Step into reveals details of method calls
 Summary
 Testing is an important part of the software cycle
 Unit testing means testing classes in isolation
 Test Suites should be developed to make testing readily repeatable
 Java provides several language features useful in debugging
 A debugger is an essential tool to facilitate debugging tasks
 Any Questions
 End of Session

Teknik pengujian perangkat

 TEKNIK PENGUJIAN PERANGKAT LUNAK
(Software Testing Techniques)
 By
 Kustanto, S.T.,M.Eng
 Overview
 Berhubungan dengan berfungsinya
komponen-komponen yang teridentifikasi
dengan jelas.

 Komponen-komponen dapat berupa fungsi
atau sekumpulan metode yang digabungkan menjadi modul atau objek


 KENAPA HARUS DIUJI ?
 Kita bukan seorang programmer yg cukup baik
 Kita mungkin tidak dapat cukup berkonsentrasi untuk menghindari kesalahan
 Kita kadang2 lupa menggunakan pemrograman terstruktur secara penuh, perancangan atas-bawah utk mendapatkan solusi
 Kita kadang buruk dalam mengerjakan sesuatu
 Kita seharusnya dapat membedakan apa yg dikatakan programmer lain atau pelanggan dan apa yg sebenarnya mereka pikirkan
 Kita seharusnya merasa bersalah apabila seseorang harus menguji koding kita
 Pengujian merupakan suatu perizinan terhadap kesalahan

 Tujuan Pengujian
 Menjalankan program untuk menemukan error.
 Test case (uji kasus) yang bagus adalah yang memiliki kemungkinan terbesar untuk menemukan error yang tersembunyi.
 Pengujian yang sukses adalah yang berhasil menemukan error yang tersembunyi.
 Hasil dari tahap pengujian ini nantinya akan dimanfaatkan untuk fase pengembangan lebih lanjut, yaitu fase perawatan atau maintenance perangkat lunak

 Fase Pengujian
 Point of Interest
 Hal-hal yang perlu diperhatikan sebelum
melakukan pengujian :

 Component Testing

 Seringkali disebut sebagai pengujian cacat
atau defect testing.
 Pengujian cacat yang berhasil adalah perlakuan uji yang menyebabkan sistem berjalan tidak benar


 Component Testing
 Component Testing
 Ada tiga langkah :
– Pengujian Kotak Hitam (Black-Box Testing)
– Pengujian Struktural (Structural Testing)
– Pengujian Jalur (Path Testing)

 Black-Box Testing

 Pengujian ini diturunkan dari spesifikasi
program atau komponen.
 Perilaku yang diperhatikan hanyalah
INPUT dan OUTPUT.
 Seringkali disebut juga sebagai pengujian
fungsional, karena penguji hanya berkepentingan dengan fungsionalitas
bukan implementasinya



 Black-Box Testing

 Structural Testing

 Pendekatan yang diturunkan dari
pengetahuan struktur dan implementasi
perangkat lunak.
 Seringkali disebut sebagai pengujian kotak
putih atau White-Box Testing.
 Pengujian ini biasanya diterapkan untuk
unit program yang relatif kecil.
 Penguji dapat melakukan analisis terhadap kode program dan menggunakan pengetahuan mengenai struktur komponen untuk menurunkan data uji.




 Structural Testing

 Path Testing

 Strategi pengujian struktural yang bertujuan untuk melatih setiap jalur eksekusi independen melalui komponen atau program.
 Jika setiap jalur independen dieksekusi,
maka semua statement pada komponen
harus dieksekusi minimal satu kali


 Path Testing
 Pada sistem berorientasi objek, pengujian
jalur ini digunakan pada saat menguji
methods yang terkait dengan objek.
 Jika dimodelkan, maka pengujian ini dapat
digambarkan sebagai diagram alir
(flowchart) dari struktur program


 Path Testing
 Jumlah jalur independen pada program
dapat dihitung dari kompleksitas siklomatik
dari diagram alir program



 DASAR2 PENGUJIAN PERANGKAT LUNAK
 Objektifitas Pengujian
◦ Test case yg baik adalah yg mempunyai probabilitas yg tinggi untuk menemukan error yg tak diketemukan
◦ Pengujian merupakan suatu proses eksekusi program yang ditujukan untuk menemukan error
◦ Uji yg sukses adalah yg dapat ‘membuka’ error yang tak diketemukan
 Dua klas input yg disediakan untuk proses uji
1. konfigurasi software, termasuk Software Requirement Specification, Design Specification dan Source code
2. konfigurasi uji, termasuk Test Plan & Procedure, perangkat testing yg akan digunakan, test case dan hasil yg diharapkan
 PERANCANGAN TEST CASE
 Test case yg dirancang harus mempunyai probabilitas yg tinggi untuk menemukan sebuah error dalam waktu & effort yg minimum.

 Dua metode pendekatan perancangan test case
1. White Box Testing (pada sesuatu yg kecil (modul)) berfokus pada struktur kontrol program.
 Dijamin semua independent path (jalur bebas) telah dijalankan setidaknya satu kali
 Menjalankan semua keputusan logis pada sisi true & false
 Menjalankan semua looping
 Melakukan struktur data internal untuk menjamin validitas

 PERANCANGAN TEST CASE (lanj.)

2. Black Box Testing (yang besar) berfokus pada kebutuhan fungsional software, memungkinkan perancang untuk memperoleh kondisi2 input yg secara penuh menguji semua kebutuhan fungsional suatu program
 Prinsip Pengujian
 Harus bisa dilacak hingga sampai ke kebutuhan customer.
 Harus direncanakan sejak model dibuat.
 Prinsip Pareto: 80% error uncovered.
 Dari lingkup kecil menuju yang besar.
 Tidak bisa semua kemungkinan diuji.
 Dilakukan oleh pihak ketiga yang independen.
 Testability
 Kemudahan untuk diuji.
 Karakteristiknya:
◦ Operability: mudah digunakan.
◦ Observability: mudah diamati.
◦ Controlability: mudah dikendalikan.
◦ Decomposability: mudah diuraikan.
◦ Simplicity: lingkup kecil, semakin mudah diuji.
◦ Stability: jarang berubah.
◦ Understandability: mudah dipahami.
 Desain Kasus Pengujian
 Black box testing
◦ Memastikan fungsional P/L berjalan.
◦ Kesesuaian input dengan output.
◦ Tidak memperhatikan proses logic internal.
 White box testing
◦ Pengamatan detail prosedur.
◦ Mengamati sampai level percabangan kondisi dan perulangan.
 WHITE BOX TESTING : Basis Path Testing
 Metode pertama yg diusulkan oleh Tom McCabe (1976). Metode ini memungkinkan perancangan memperoleh pengukuran yang kompleksitas dari perancangan prosedural dan menggunakan pengukuran ini sebagai pedoman pendefinisian sekumpulan basis dari jalur eksekusi
 Perangkat yang digunakan
1. Notasi Flow Graph atau Program Graph
Contoh :
- sequence - if



- until
 White Box Testing
 Metode: basis path testing.
 Memakai notasi flow graph.
 BASIS PATH TESTING
 Cyclomatic Complexity, merupakan pengukuran per.lunak yang menyediakan pengukuran kuantitatif dari kompleksitas logis suatu program. Nilai cyclomatic complexity mendefinisikan jumlah jalur bebas pada basis program.
 Independent path (jalur bebas) merupakan jalur pada program yg menunjukkan setidaknya satu kumpulan pernyataan pemrosesan baru atau kondisi baru.

Langkah2 Basis Path Testing
- gunakan rancangan atau kode sebagai pondasi, lalu gambarkan flow graph
- tentukan cyclomatic complexity, dinyatakan V(G) dari flow graph
- tentukan sekumpulan basis secara linear jalur bebas
- persiapkan test case yg akan memperkuat eksekusi setiap jalur pada sekumpulan basis program
 Kompleksitas Cyclomatic
 Menunjukkan jumlah skenario pengujian yang harus dilakukan untuk menjamin cakupan seluruh program.
 BLACK BOX TESTING
 Merupakan metode pelengkap White Box Testing. Berfokus pada kebutuhan fungsional dari per.lunak.
 Memungkinkan perancang untuk memperoleh sekumpulan kondisi2 input yg secara penuh menguji semua kebutuhan fungsional suatu program
 Metode ini berusaha menemukan kesalahan yg termasuk kategori di bawah ini
- fungsi2 yg hilang atau tidak benar
- kesalahan pada antarmuka
- kesalahan pada struktur data atau pengaksesan database ekternal
- kesalahan pada performance
- kesalahan pada inisialisasi dan terminasi
 Contoh White Box Testing
 Black Box Testing – Graph Based

 Black Box Testing – Equivalence Partitioning





 Contoh: Input NPM dalam SIAMIK
◦ Jika dikosongi?
◦ Jika diisi dengan format yang salah?
◦ Jika diisi dengan NPM yang benar?
 Black Box Testing – Analisa Nilai Batas
 Menguji untuk input di sekitar batas atas maupun bawah sebuah range nilai yang valid.
 Menguji nilai maksimal dan minimal.
 Menerapkan (1 & 2) untuk output.
 Menguji batas struktur data yang dipakai. Misal ukuran array.
 Black Box Testing – Perbandingan
 Spesifikasi kebutuhan yang sama dimungkinkan menghasilkan aplikasi/ perangkat lunak yang berbeda.
 Skenario pengujian pada aplikasi yang demikian bisa digunakan untuk skenario pengujian aplikasi serupa yang lain.
 Skenario Pengujian Khusus
 Pengujian GUI.
 Pengujian arsitektur client/ server.
 Pengujian dokumentasi dan fasilitas bantuan.
 Pengujian sistem waktu nyata.
 CONTOH LAIN
 Contoh lain White Box Testing atau Control Structure Testing adalah
1. Condition Testing, menjalankan kondisi logis yang terdapat pada modul program
2. Data Flow Testing, metode yg menyeleksi jalur test program menurut lokasi pendefinisian & menggunakan variabel2 program
3. Loop Testing, berfokus pada validitas dari bentuk loop (simple loop, concatenated loop, nested loop, unstructured loop)


 CONTOH LAIN

 Contoh lain Black Box Testing adalah
1. Equivalence Partitioning, membagi domain input dari program ke dalam klas2 data
2. Boundary Value Analysis (BVA) melengkapi Equivalence Partitioning, dengan melakukannya dari domain output
3. Cause-effect Graphing, memvalidasi aksi2 & kondisi yg kompleks

 CHAPTER 18
STRATEGI PENGUJIAN P/L

 STRATEGI PENGUJIAN P/L
 Membahas langkah-langkah yang harus dikerjakan sebagai bagian dari pengujian.
 Kapan dilaksanakan? Berapa usaha, waktu dan sumber daya yang digunakan?
 Meliputi: perencanaan, desain test case, pelaksanaan, koleksi data dan evaluasi.
 Kaidah Umum Pengujian
 Dimulai dari pengujian tingkat komponen menuju integrasi.
 Titik yang berbeda dimungkinkan memakai teknik pengujian yang berbeda.
 Pengujian dilakukan oleh developer dan (untuk proyek yang besar) tim independen.
 Testing dan debugging adalah berbeda. Namun debugging pasti berkaitan dengan strategi testing apapun.
 Strategi Pengujian
 Dimulai dari unit testing terhadap source code hingga system testing terhadap spesifikasi kebutuhan.
 Langkah Pengujian

 Unit Testing

 Integration Testing
 Top – down integration
 Integration Testing
 Bottom – up integration
 Integration Testing
 Regression testing: dilakukan pengujian setiap kali ada modul baru yang diintegrasikan atau ada modul yang berubah.
 Smoke testing: test daily, untuk proyek jenis kritis-waktu.
 Validation Testing
 Disebut sukses jika fungsi P/L dapat diterima oleh customer (berdasarkan dokumen SKPL).
 Alpha test: dilakukan di tempat developer oleh customer pada lingkungan yang terkendali.
 Beta test: dilakukan di tempat customer tanpa melibatkan developer pada lingkungan yang tak terkendali.
 System Testing
 Meguji sistem berbasis komputer secara menyeluruh, termasuk juga hubungannya dengan sistem yang lain.
 Diantaranya:
◦ Recovery testing, jika system failure.
◦ Security testing, jika terjadi serangan.
◦ Stress testing, terhadap jumlah, frekuensi dan volume pekerjaan.
◦ Performance testing, untuk mengukur pemakaian sumber daya.
 Debugging
 Memperbaiki error yang ditemukan pada saat testing (yang sukses).
 Kaidah dasar sebelum debug:
◦ Apakah penyebab bug dihasilkan kembali oleh bagian program yang lain?
◦ Apakah bug selanjutnya yang mungkin muncul jika bug diperbaiki?
◦ Apa yang bisa dilakukan untuk mencegah bug terjadi untuk pertama kalinya?
 Any Questions?
End of Session

WebQual: Sebuah Eksplorasi Web-site Kualitas
Stuart Barnes & Richard Vidgen
School of Management, University of Bath, Bath BA2 7AY, Britania Raya
mnssjb@management.bath.ac.uk, mnsrtv@management.bath.ac.uk
Abstrak - Masalah situs web berkualitas ditangani dari
perspektif 'suara pelanggan'. Kualitas fungsi
penyebaran (QFD) adalah diadopsi sebagai kerangka untuk mengidentifikasi
web-situs kualitas yang dituntut oleh pengguna, yang berkumpul
melalui lokakarya kualitas. Dari lokakarya instrumen
untuk menilai kualitas situs web dikembangkan (WebQual) dan
diuji dalam domain sekolah bisnis Inggris. Hasil
WebQual survei disajikan dan dianalisis, yang mengarah ke
generasi Indeks WebQual web-situs berkualitas. Bekerja di bawah
cara untuk memperluas dan menyempurnakan instrumen WebQual termasuk
perdagangan elektronik evaluasi, di mana situs web kualitas pelayanan
diusulkan sebagai isu kunci.
I. PENDAHULUAN
Dalam waktu yang relatif singkat sejak Internet masuk
kegiatan komersial utama web di seluruh dunia (WWW)
telah menjadi area fokus bisnis utama. Perusahaan dari semua
bentuk dan ukuran dalam berbagai industri yang mengeksplorasi
cara untuk memulai perdagangan Internet. Dengan milenium (2000) itu
Diperkirakan bahwa perdagangan elektronik akan bernilai $ 160.000.000.000
(Http://www.forrester.com). Selain itu, selain diprediksi
WWW pertumbuhan akan memungkinkan perusahaan untuk menjangkau baru
pasar yang tidak bisa sebaliknya dieksplorasi [29].
Di Internet pengguna lingkungan yang baik penyedia dan
konsumen informasi dan layanan. Kemudahan yang
halaman web dapat dipublikasikan telah menciptakan banyak masalah,
seperti informasi yang salah atau ketinggalan zaman, membingungkan
navigasi, dan link yang rusak. Informasi dan kualitas layanan
sekarang faktor signifikan mempengaruhi efektivitas situs
dan ini adalah masalah yang akan menentukan kemampuan
bisnis untuk menuai keuntungan dari e-commerce. Namun,
meskipun teknologi web mungkin relatif baru,
isu-isu kualitas sistem informasi adalah topik lama
IS penelitian.
Dalam makalah ini kami melaporkan pada penelitian empiris mengeksplorasi
beberapa dimensi kualitas situs web. Pada bagian 2 kita
tempat penelitian ini dalam konteks yang lebih luas dengan mempertimbangkan
literatur yang berkaitan dengan kualitas informasi. Hal ini diikuti oleh
penjelasan tentang metodologi penelitian yang digunakan dalam penelitian ini -
Kualitas fungsi penyebaran (QFD), yang menggunakan
kuesioner untuk mencerminkan 'suara pengguna web-situs'. Para
Bagian keempat laporan tentang proses pengumpulan data dan dalam
bagian kelima hasil analisis data yang dilaporkan,
termasuk eksplorasi awal dari validitas dan reliabilitas.
Akhirnya, beberapa kesimpulan disediakan bersama dengan rencana untuk
perkembangan masa depan penelitian.
II. KUALITAS INFORMASI
Ada tubuh lama dari IS literatur memeriksa
aspek informasi dan kualitas informasi. Sebagian besar dari ini
literatur mendahului ledakan di Web Niaga (misalnya, lihat
[10]). Pencetus banyak upaya penelitian
Shannon dan Weaver [26], yang memelopori bekerja mani pada
komunikasi. Kritis, mereka memeriksa "informasi" sebagai
pesan dalam sistem komunikasi, dari pengirim (S), melalui
saluran komunikasi, ke penerima (R). Hal ini dapat diukur
di sejumlah tingkatan: teknis, mengacu pada akurasi dan
efisiensi sistem produksi informasi; semantik,
mengacu pada keberhasilan sistem dalam menyampaikan dimaksudkan
makna, dan, efektivitas, mengacu pada efek atau pengaruh
[19] informasi pada penerima. Seperti konsepsi adalah
paling pedih, bahkan ke Web Commerce, di mana organisasi
bertujuan untuk mengirimkan data secara efisien dan akurat atas
Internet, mis penawaran produk, yang menyampaikan diinginkan
artinya, mis karakteristik produk, dan memiliki yang diinginkan
efek, mis penjualan.
Akibatnya, teori komunikasi menunjukkan
seri sifat informasi (sebagai bentuk komunikasi); yang
sistem, seperti Web, menciptakan informasi yang
dikomunikasikan kepada penerima, yang kemudian dipengaruhi (atau tidak)
oleh informasi. Belakangan, di samping akses pihak pertama
informasi, di mana pengguna langsung mencari atau "menarik"
informasi dari teknologi, Web juga tersedia yang
memungkinkan informasi yang akan "mendorong" atau "siaran", yaitu
disediakan oleh pihak ketiga, sesuai dengan profil
persyaratan. Sebuah aspek fundamental dari proses ini adalah
kualitas informasi yang dihasilkan dan dikirim ke
penerima. Sebagaimana akan kita lihat, ini juga, sampai batas tertentu,
terkendali. Namun, sangat terkait dengan ini, salah satu dari
aspek paling sulit dari proses ini adalah menentukan
pengaruh informasi tersebut pada pengguna akhir, terutama dengan
hal kompleksitas dan keragaman penerima pada
WWW. Dalam makalah ini, pembahasan dibatasi pada
mantan: memeriksa kualitas informasi yang dihasilkan dan
ditransmisikan oleh pengirim. Yang terakhir ini tidak berada dalam domain
kertas ini, meskipun upaya saat ini sedang bekerja di
daerah ini.
Berikut dari pekerjaan pada teori komunikasi,
Sejumlah penulis telah berusaha untuk mendefinisikan dan mengukur
karakteristik berkontribusi terhadap kualitas informasi
diproduksi dan ditransmisikan dalam IS. Pekerjaan tersebut telah muncul
dari penelitian lapangan, laboratorium, teoritis dan taksonomi (misalnya
[2], [3], [10], [16], [18], [20], [21], [28]).
Salah satu bagian yang paling terkenal dari bekerja di daerah ini adalah bahwa
Bailey dan Pearson [2], yang mengembangkan alat untuk mengukur IS
kepuasan pengguna dari lapangan dengan 32 manajer di 8
organisasi. Dari ini, DeLone dan McLean [10] dalam mereka
taksonomi dari IS variabel keberhasilan mengidentifikasi 9 item yang berkaitan dengan
kualitas informasi: akurasi, presisi, mata uang, ketepatan waktu,
keandalan, kelengkapan, volume, format dan relevansi.
Namun, dan mungkin terkait dengan aplikasi longgar mereka dari
konsep "sistem" dan "informasi" kualitas, seperti
klasifikasi ini tidak sepenuhnya tepat. Memang, seperti orang lain
telah menyarankan, beberapa kualitas yang melekat dari sistem
berkontribusi secara langsung terhadap kualitas informasi [22].
Selanjutnya, mengambil sikap holistik, kita ragu-ragu mungkin
termasuk item mengacu pada kepercayaan / keamanan data,
kemudahan akses, bahasa, pemahaman utilitas, dan
integrasi. Dalam mendukung, beberapa penelitian lain memeriksa kualitas
juga mengidentifikasi langkah-langkah tambahan (misalnya [8], [18], [22]).
Secara keseluruhan, kita dapat mengidentifikasi 15 item dari Bailey dan Pearson
39-item instrumen yang berhubungan dengan kualitas informasi. Ini
item memberikan penilaian bulat dan komprehensif
kualitas informasi; di sinilah letak kekuatan dari tindakan,
dan ini adalah salah satu alasan mengapa pekerjaan Bailey dan Pearson
telah terbukti bertahan selama dua dekade terakhir. Kita bisa
melihat banyak rekan lain yang terkait bekerja untuk mencoba dan mengembangkan
dan memperluas pilihan ini, tapi cerita menyeluruh akan
sangat mirip: literatur memberikan dukungan yang kuat untuk ini
tindakan (mis. [3], [12], [20], [21], [28]).
Memiliki kualitas informasi dieksplorasi di IS secara umum,
ini menimbulkan pertanyaan tentang bagaimana isu-isu terkait secara khusus kepada
WWW. Ada beberapa studi akademis dan ukuran
Kualitas informasi web, meskipun tak diragukan lagi banyak di
proses pembangunan. Penelitian terbaru (dalam proses)
memeriksa kualitas situs Web (misalnya, [1], [4], [24], [25])
cenderung menaikkan sejumlah isu penting dalam mengukur
kualitas informasi. Secara khusus, beberapa cenderung
fokus pada "keras" karakteristik atau fungsi dari Web-situs,
dengan mengorbankan isu-isu seputar lembut kualitas sebagai
didukung oleh pengguna [4]. Isu-isu lunak seperti ini sangat penting jika
Web-situs yang menjadi demand-driven (dengan kebutuhan pengguna)
bukan supply driven (dengan kemampuan teknologi).
Memang, ada bukti yang menunjukkan bahwa itu adalah sederhana
aksesibilitas dan kegunaan dari situs yang adalah mengambil diutamakan
atas "sihir teknis" [11]; kemampuan teknologi harus
digunakan tepat untuk mendukung pengembangan situs
berfokus pada pengguna. Pergi satu langkah lebih lanjut, penelitian di
area umum pendukung kualitas produk yang menguraikan
konsep demand-driven, karakteristik lembut, dari hard
karakteristik dan fungsi [17]; pendekatan membuat
ini eksplisit entitas dan peta hubungan antara mereka.
Namun, dalam beberapa penelitian penilaian Web daerah ini
gabungan, yang cenderung untuk membingungkan masalah ini, membuatnya lebih
sulit untuk menilai nilai tambah situs untuk pengguna [24].
Akibat wajar dari hal ini adalah penekanan pada pentingnya
teknik yang digunakan dalam menilai kualitas-situs Web.
Mengambil onboard pentingnya menyediakan berorientasi pengguna
penawaran untuk pelanggan, bagaimana seharusnya kita pergi tentang mendefinisikan
kebutuhan mereka? Hanya kemudian dapat kita realistis pergi tentang
menciptakan fungsionalitas yang relevan dan konten teknologi. Pada
pertama, ini bukan pertanyaan yang mudah dijawab. Namun, kami
percaya bahwa ada teknik tertentu yang dapat membuktikan
pencerahan di daerah ini penting - fungsi kualitas
penyebaran (QFD). Bagian selanjutnya menjelaskan teknik
dan penggunaannya dalam konteks penelitian ini.
III. PENDEKATAN PENELITIAN
Pendekatan penelitian yang diadopsi adalah menggunakan fungsi kualitas
penyebaran (QFD) sebagai kerangka kerja untuk menjelajahi situs web
kualitas. QFD adalah proses "terstruktur dan disiplin yang
menyediakan sarana untuk mengidentifikasi dan membawa suara
pelanggan melalui setiap tahap layanan produk dan atau
pengembangan dan implementasi "[27]. Pendekatan ini juga
tercermin dalam karya Kuat et al., yang menggarisbawahi
pentingnya melampaui kualitas data intrinsik: "kualitas
data tidak dapat dinilai independen dari orang-orang yang
menggunakan data - data konsumen "[28]. Didasarkan pada pembedaan
'Apa' dan 'bagaimana', serangkaian matriks yang digunakan untuk menyebarkan
pelanggan menuntut kualitas melalui persyaratan desain,
fungsi produk, karakteristik bagian, dan manufaktur
operasi ke persyaratan produksi ([15], [17]). QFD telah
akar dalam industri manufaktur tetapi sudah ada
aplikasi untuk pengembangan perangkat lunak (misalnya, terutama dengan
[5], [9], [14], [31], [32]).
menuntut
kualitas
(Situs web pengguna)
kualitas
karakteristik
(Web-site
penyedia)
Web-site
Perangkat Lunak
(Implementasi
dan operasi)
biaya penyebaran
(Kebutuhan pelanggan
dan kompetitif
analisis)
pengguna berbasis
kualitas
produk berbasis
kualitas
manufaktur berbasis
kualitas
berbasis nilai
kualitas
Web-site
produk
(Dan fungsi
bagian)
kendala
kesesuaian dengan
spesifikasi
Gambar. 1. QFD dan Web-site Pengembangan
Kami telah diadaptasi QFD untuk web-situs pengembangan dan
dimasukkan Garvin itu [13] yang berbeda pandangan dari kualitas ke kami
kerangka kerja konseptual (Gambar 1). Pandangan kualitas mengakui
bahwa meskipun pelanggan mungkin kualitas drive ada juga yang
tempat untuk produk berbasis kualitas (perspektif pemasok),
kesesuaian dengan spesifikasi, dan pengakuan umum
kendala biaya dan tekanan kompetitif sebagai dunia nyata
faktor yang harus diperhitungkan. Misalnya, dalam konteks
situs web, salah satu kualitas pengguna web-site kami diidentifikasi dalam
penelitian adalah "mudah untuk menemukan". Sebuah karakteristik kualitas
relevan dengan kebutuhan pengguna mungkin "persen yang benar
menebak URL situs web oleh pengguna dalam tes panel "bersama-sama
dengan beberapa target, seperti pengakuan 90%. Lain
karakteristik berkaitan dengan kualitas ini mungkin peringkat dalam pencarian
mesin, di mana fungsi web-situs yang terkait dengan
mungkin karakteristik kapasitas untuk pengiriman otomatis
situs untuk mesin pencari.
IV. DATA COLLECTION
Untuk membangun sebuah daftar awal kualitas kami berlari kualitas
lokakarya. Bossert [6] merekomendasikan proses tiga tahap untuk
lokakarya: mendirikan sebuah isu tunggal untuk diskusi; mengumpulkan
persyaratan mutu dan fungsi menggunakan post-it notes, dan,
menggunakan pengelompokan afinitas untuk mengumpulkan persyaratan ke kategori
yang masuk akal bagi pelanggan. Para delegasi di
lokakarya enam siswa Master belajar untuk gelar sarjana di
Manajemen dan Sistem Informasi Strategis. Single
masalah untuk diskusi adalah: "Apa kualitas dari suatu
bagus web-situs "Delegasi? bekerja secara individual menulis
ide-ide mereka ke post-it notes dan didorong untuk menempatkan
menyusuri frase singkat bersama-sama dengan hukuman lebih lama untuk menjelaskan
alasan untuk kualitas yang diusulkan. Para delegasi
kemudian dialokasikan ke dua tim dan meminta untuk menggabungkan mereka
kualitas ke dalam kelompok afinitas (daftar pohon terstruktur), awalnya
bekerja dalam keheningan untuk memindahkan pos-nya sekitar dan menciptakan
judul yang dirasakan sesuai. Akhirnya, dua tim
dibawa kembali bersama-sama untuk menghasilkan daftar konsolidasi tunggal
menuntut kualitas. Pada akhir sesi kami
mengumpulkan lima puluh empat baku kualitas yang terstruktur
hierarkis ke dalam kelompok afinitas.
A. Refining Suara Nasabah
Dari kuesioner baku kualitas pilot dengan tiga puluh lima
pertanyaan dikembangkan. Hal ini diselesaikan oleh enam
peserta lokakarya dan digunakan untuk memperbaiki pertanyaan.
Salah satu hasil dari pilot adalah pengakuan bahwa
kuesioner terlalu panjang - untuk menjawab tiga puluh lima pertanyaan
untuk setiap situs web empat mengarah ke 140 penilaian, ditambah
lanjut 35 penilaian pentingnya kualitas masing-masing.
Menggunakan literatur pada kualitas informasi dan mencari
hati-hati untuk tumpang tindih kualitas kuesioner itu
direduksi menjadi 24 pertanyaan lebih mudah dikelola. Di manapun
mungkin, kita menghapus pertanyaan yang dimaksud terlalu langsung ke
karakteristik, fungsi, atau bagian dari situs web, karena ini
mewakili perspektif pemasok dan dibahas dalam
matriks QFD berikutnya. Dalam hubungannya dengan mendefinisikan
kualitas kamus dikembangkan untuk memberikan tekstual singkat
deskripsi kualitas masing-masing untuk menyediakan pengguna dengan lebih
rinci kontekstual saat menyelesaikan kuesioner. Hal ini
mirip dengan cadangan tekstual diberikan dengan masyarakat untuk
informasi manajemen (SIM) survei isu-isu kunci dalam
sistem informasi [7]. Misalnya, kualitas "Memiliki
gaya yang sesuai untuk tipe desain situs "telah di kualitas
kamus: "Tata letak dan tampilan situs yang di
karakter dengan jenis situs. Sebagai contoh, sebuah situs hiburan
mungkin memiliki desain radikal dan inovatif yang tidak akan
sesuai untuk sebuah badan pemerintah. "
B. Instrumen WebQual
Daftar direvisi kualitas dikembangkan menjadi Internetbased
kuesioner untuk mengevaluasi kualitas dari empat Inggris
sekolah bisnis situs web: Bath, London (LBS), Manchester
(MBS), dan Warwick (WBS). Desain adalah untuk menetap di
memiliki halaman pembuka instruksi yang kemudian akan membuka
Web terpisah jendela browser yang berisi kualitas akan
dinilai (Gambar 2). Panel kontrol memungkinkan pengguna untuk beralih
isi dari jendela sasaran antara instruksi
halaman, target situs web untuk dievaluasi, dan kualitas
kamus. Hal ini memungkinkan pengguna untuk memutuskan urutan
evaluasi tapak. Sebagai contoh, pengguna dapat memutuskan untuk menjawab
semua 24 pertanyaan untuk satu situs dan kemudian beralih ke situs berikutnya,
menjawab pertanyaan yang sama untuk semua empat lokasi, atau mengadopsi campuran
dari dua pendekatan. Memiliki kualitas kamus online
dan terkait dengan pertanyaan nomor membuatnya mudah untuk mendapatkan lebih
rincian kualitas tertentu. Menggunakan kuesioner internet
dengan dua jendela itu jauh lebih baik untuk menggunakan paperbased
kuesioner - itu juga memungkinkan untuk otomatis
koleksi hasil.
WebQual
panel kontrol
Pertanyaan 1
Pertanyaan 2
Menyerahkan
Target WebQual jendela
• Instruksi untuk menyelesaikan kuesioner
• Web-situs yang akan dievaluasi
Mandi
London (LBS)
Manchester (MBS)
Warwick (WBS)
• Kualitas kamus
Gambar. 2. Berbasis internet online Kuesioner
V. ANALISIS DAN PEMBAHASAN HASIL
Data yang dikumpulkan adalah diringkas dalam Tabel 1. Perhatikan bahwa pada
tahap ini, kami belum disajikan setiap kelompok dari
pertanyaan untuk menyediakan kategori terkait (ini dibahas
di bawah). Ada 46 kuesioner yang digunakan untuk bagian utama dari
analisis, yang dikumpulkan dari dua sampel independen
responden. Ada 32 tanggapan dari 40 tahun terakhir
MAMPU 1 T
RINGKASAN RATA-RATA UNTUK DATA TERTIMBANG DAN unweighted Sets
bisnis administrasi mahasiswa, pada empat tahun
'Sandwich' saja, dan 14 tanggapan dari total 33 M.Sc.
mahasiswa yang belajar Manajemen dan Strategis IS, satu tahun
diajarkan dalam kursus konversi untuk lulusan. Kuesioner
tanggapan diterima melalui e-mail dan dikonversi ke dalam bentuk
dapat digunakan dalam SPSS, paket statistik.
A. Membandingkan Sampel Kuesioner
Dalam rangka untuk melakukan analisis dengan tingkat yang lebih tinggi
signifikansi, itu diinginkan untuk menggabungkan dua kuesioner
set menjadi hanya satu set data. Ini masuk akal intuitif, karena
keduanya set siswa mempelajari topik-topik yang serupa pada saat yang sama
Universitas. Demografi juga cukup serupa dalam hal
proporsi siswa internasional dan usia. Namun,
ada beberapa perbedaan, seperti panjang kuliah di
Universitas dan keakraban dengan Internet. Jadi, dalam rangka
untuk mengkonfirmasi bahwa dua set kuesioner dapat nyenyak
digabungkan, adalah penting untuk membandingkan distribusi dari
dua sampel untuk membangun kesamaan.
Untuk membandingkan set kuesioner, dua tes utama adalah
dilakukan. Sebuah t-test digunakan untuk menguji perbedaan berarti.
Uji Levene ini digunakan untuk membandingkan varians untuk kesetaraan.
Tes ini dilakukan pada respons tertimbang
masing-masing situs web dinilai: Bath, LBS, MBS dan WBS.
Uji Levene menegaskan bahwa, selama 23 pertanyaan,
varians adalah sama untuk sampel yang dikumpulkan dari kedua
kelompok siswa, dengan keyakinan 95%. Pengecualian adalah
18 pertanyaan, yang gagal tes untuk tiga dari empat bisnis
sekolah data set; pertanyaan ini kemudian dihapus dari
analisis. Alasan untuk hasil ini mungkin karena bias dari
arsitektur jaringan untuk situs lokal, dalam hal ini harus
dihapus.
T-test untuk perbandingan berarti menunjukkan bahwa dengan beberapa
pengecualian, berarti juga sama, lagi dengan
95% percaya diri. Pengecualian beberapa panggilan akrab untuk
tiga pertanyaan dalam set data tunggal, yang dalam keseluruhan
konteks set lengkap data, tidak dianggap
penting.
B. Pembahasan Ringkasan Data
Tabel 1 menunjukkan jumlah item untuk diskusi. Pertama,
Impor. memberikan skor peringkat rata-rata pentingnya
setiap pertanyaan, berdasarkan 46 tanggapan. Kedua, per
Pertanyaan rata-rata skor untuk masing-masing data sekolah bisnis
set diberikan. Hal ini ditampilkan dalam dua mode: Skor adalah
rata-rata untuk mentah, peringkat unweighted (dengan kisaran teoritis
1 sampai 5) WGT, dan. Skor adalah rata-rata tertimbang untuk rating
(Secara teoritis mulai dari 1 sampai 25). Yang terakhir ini mengacu pada
mengalikan skor tertimbang oleh pentingnya untuk setiap
responden, dan kemudian menghitung rata-rata.
Mengacu pada Tabel 1, kita melihat beberapa pola yang menarik di
data. Dalam hal pentingnya peringkat tertentu
pertanyaan, ada beberapa pengelompokan berguna untuk dicatat. Mereka
pertanyaan dianggap paling penting, misalnya atas atas
kuartil dari 4.16, adalah semua tentang mendapatkan akses cepat dan mudah untuk
relevan dan dapat diandalkan informasi. Di sini kita menemukan, dalam rangka
Uraian Impor. Bath data LBS MBS data data data WBS
Skor WGT. Skor Skor WGT. Skor Skor WGT. Skor Skor WGT. Skor
1 adalah mudah digunakan 4,35 3,76 16,43 3,37 14,65 3,15 13,85 3,50 15,24
2 memiliki hal-hal di mana Anda berharap untuk menemukan mereka 4,11 3,67 15,43 3,50 14,59 3,28 13,70 3,63 14,96
3 adalah mudah untuk menemukan jalan sekitar Anda 4,35 3,67 16,35 3,33 14,46 3,30 14,57 3,70 16,04
4 memiliki navigasi cepat ke halaman 4,11 4,30 17,63 3,87 15,93 4,02 16,57 3,83 15,67
5 memiliki link ke situs lain yang berguna 3,02 2,72 8,78 3,04 9,65 2,67 8,41 2,76 8,61
6 adalah mudah untuk menemukan 4,11 3,72 15,41 3,74 15,57 3,76 15,63 3,37 13,96
7 memfasilitasi kunjungan kembali 3,39 3,39 12,07 3,50 12,57 3,30 11,61 3,20 11,46
8 memiliki tampilan yang menarik 3,76 3,59 13,63 4,02 15,46 2,35 8,67 3,17 11,78
9 memiliki gaya sesuai desain untuk jenis situs 3,56 3,72 13,36 3,49 12,69 2,78 9,71 3,52 12,41
10 menyediakan akses cepat dan mudah untuk mencari informasi 4,54 3,72 17,17 3,43 15,61 3,35 15,17 3,76 17,09
11 menyediakan informasi yang relevan 4,41 3,72 16,57 3,46 15,30 3,50 15,50 3,63 16,11
12 memberikan informasi pada tingkat yang sesuai detail 3,96 3,67 14,67 3,33 13,07 3,20 12,61 3,50 13,96
13 menyediakan konten informasi yang mudah dibaca 4,11 3,98 16,72 3,52 14,65 3,22 13,37 3,59 15,02
14 mengkomunikasikan informasi dalam format yang sesuai 3,83 3,74 14,48 3,26 12,59 3,07 11,83 3,43 13,24
15 menyediakan konten informasi yang mudah untuk memahami 4,04 4,02 16,52 3,57 14,46 3,54 14,50 3,80 15,57
16 memiliki informasi yang diperbarui secara teratur 4,11 3,24 13,52 3,78 15,72 3,37 13,89 3,30 13,76
17 memiliki informasi yang dapat diandalkan 4,43 3,72 16,70 3,67 16,50 3,63 16,30 3,59 16,09
18 memiliki waktu pembukaan yang wajar 4,33 4,26 18,59 3,87 16,85 4,00 17,37 3,91 17,13
19 menciptakan sebuah pengalaman 3,07 2,98 9,13 3,48 11,09 2,52 7,67 3,00 9,30
20 menyampaikan rasa komunitas 2,72 3,17 8,76 3,24 9,04 2,93 8,22 3,02 8,22
21 menjaga perhatian pengguna 3,96 3,22 13,07 3,57 14,39 2,43 9,80 2,98 11,96
22 adalah sebuah situs yang merasa aman 3,43 3,52 12,80 3,37 12,02 3,28 11,87 3,33 12,04
23 membuatnya mudah untuk memberikan umpan balik 3,43 3,22 11,37 3,09 10,89 3,20 11,26 3,22 11,13
24 membuatnya mudah untuk menghubungi organisasi 4,11 3,96 16,74 3,78 15,98 3,91 16,48 3,74 15,65
JUMLAH: 86,67 345,90 84,27 333,71 77,78 308,56 82,48 326,39
penting, pertanyaan 10, 17, 11, 3 dan 1 (pertanyaan 18 adalah
dihapus dari analisis - lihat di atas). Pada ujung lain dari
spektrum, pertanyaan-pertanyaan yang dianggap paling tidak penting, misalnya
kuartil bawah 3,53 lebih rendah, didasarkan sekitar pengalaman,
keamanan, link, umpan balik dan kunjungan kembali. Secara khusus,
pertanyaan 20, 5, 19, 7, 22 dan 23 berada dalam urutan dari
penting. Pertanyaan lain adalah di antara, dan median adalah
4,08.
Hasil penelitian menunjukkan bahwa ada prioritas khusus dalam
kualitas yang dituntut dari sekolah bisnis situs web oleh pengguna.
Mendapatkan akses mudah ke informasi 'yang baik' muncul penting,
sementara aspek-aspek tertentu lainnya yang mungkin penting bagi beberapa
situs komersial, seperti keamanan dan membangun jaringan
komunitas pengalaman bagi pengguna untuk kembali ke, tidak begitu
penting. Secara intuitif, tren seperti masuk akal, terutama
ketika kita mempertimbangkan bahwa fokus utama tampaknya berada di
informasi-orientasi daripada transaksi bisnis,
mencapai massa kritis atau loyalitas merek.
Tentu saja, peringkat pentingnya menyaring hingga
hasil tertimbang dari data set sekolah bisnis.
Hasil unweighted untuk pertanyaan individu menunjukkan beberapa
hasil yang bervariasi untuk pertanyaan individu, dengan masing-masing institusi
mencapai skor tertinggi untuk satu atau lebih pertanyaan. Tertimbang
Hasil berfungsi untuk menonjolkan perbedaan-perbedaan dalam arah
prioritas pengguna.
Salah satu tujuan utama dari pendekatan ini adalah untuk mencapai beberapa keseluruhan
kualitas rating untuk setiap situs web dinilai. Untuk ini total, akhir
skor disediakan untuk data set tertimbang dan unweighted. Dalam
kasus ini, peringkat skor total untuk situs adalah
yang sama, meskipun ukuran relatif berbeda melalui
skema pembobotan.
Sayangnya, nilai total membuat sulit untuk memberikan
patokan untuk situs. Salah satu cara untuk mencapai ini adalah untuk indeks
skor total tertimbang setiap situs melawan kemungkinan jumlah
skor (yaitu pentingnya total untuk semua pertanyaan dikalikan dengan 5,
nilai maksimum untuk sebuah situs). Sebuah ringkasan ini
perhitungan dan total yang diberikan dalam Tabel 2 (disesuaikan untuk
penghapusan pertanyaan 18). Secara keseluruhan, tampak bahwa kualitas
peringkat, dalam urutan: Bath, LBS, WBS dan MBS.
TABEL 2
PERBANDINGAN SKOR T OTAL UNTUK SITUS
Situs WGT. Skor Maks. WQ Indeks
Bath 327,31 444,52 0,74
LBS 316,86 444,52 0,71
WBS 309,26 444,52 0,70
MBS 291,19 444,52 0,66
Namun, mungkin lebih menarik adalah beberapa penilaian
bagaimana situs web berbeda dalam kualitas. Sebuah diskusi tentang nilai untuk
setiap pertanyaan dan setiap akan rumit pada saat ini.
Sebaliknya, itu akan berguna untuk menilai peringkat situs dalam sebuah
jumlah yang berarti, dapat diandalkan pertanyaan sub-kelompok. Untuk
tujuan ini, bagian berikutnya berasal sejumlah sub-kelompok
dan berlaku mereka untuk analisis.
C. Skala Keandalan dan Pengelompokan Pertanyaan
Dalam rangka untuk memverifikasi keandalan instrumen WebQual,
analisis reliabilitas dilakukan dengan menggunakan statistik
A. Cronbach Ini digunakan pada masing-masing sekolah bisnis
Data set. Tes menghasilkan skor antara 0,91 dan 0,93
untuk semua 23 pertanyaan (termasuk pertanyaan 18), menunjukkan bahwa
skala sebenarnya cukup handal.
TABEL 3
RINGKASAN ANALISIS KEANDALAN UNTUK KATEGORI KUESIONER
Asli Grup Qn.s No sebuah Grup Akhir Qn.s No suatu
Navigasi 0,73 1-7 1-3 Kemudahan Penggunaan 0,83
- Navigasi 1-5 - 2-3 navigasi
- Menemukan situs 6-7 - umum kemudahan penggunaan 1
Presentasi Pengalaman 8-9 0,79 0,87 8-9,19-21
- Estetika 8-9 - 8-9 dampak visual yang
Informasi 10-17 0,86 - dampak individu 19-21
- Mencari informasi 10 Informasi 10-17 0,86
- Informasi konten 11-17 - mencari informasi 10
Pengalaman 19-22 0,76 - informasi konten 11-17
- Situs pengalaman 19-21 Comm. & Integrasi 4-7,22-24 0,71
- Keamanan 22 - integrasi eksternal 5-7
Interaksi 22-23 0,57 - komunikasi 4,22-24
- Komunikasi 22-23
Selanjutnya, untuk lebih menganalisis perbedaan userderived
kualitas dari situs, analisis reliabilitas diperpanjang
sejumlah pertanyaan sub-kelompok. Awal dan
hasil akhir dari analisis ini dirangkum dalam Tabel 3, yang
menampilkan pengelompokan dan nilai rata-rata Alpha dicapai
empat set data sekolah bisnis. Awalnya, sejumlah
tentatif, intuitif sub-kelompok yang diusulkan, dan ini
digunakan untuk tahap pertama analisis reliabilitas. Seperti yang bisa kita
lihat, beberapa kelompok-kelompok ini didukung oleh Cronbach
rata-rata nilai, khususnya kategori Informasi
(A = 0,86). Namun, beberapa dari nilai rata-rata Alpha
relatif rendah (misalnya untuk Interaksi mana a = 0,57), menunjukkan
bahwa timbangan kurang dapat diandalkan, dan bahwa pertanyaan
pengelompokan yang kurang optimal.
Iteratif penghapusan dan penggantian pertanyaan di berbagai
pengelompokan menunjukkan bahwa, dalam hal keandalan statistik, mereka
dapat ditingkatkan. Jadi, kita berpindah dari lima
kategori di sebelah kiri Tabel 3, dengan empat di sebelah kanan. Para
nilai untuk kategori baru yang tinggi, menunjukkan ini
pengelompokan yang cukup handal. Secara intuitif, kelompok-kelompok ini muncul
valid dan bermakna. Secara singkat, mereka dapat dijelaskan sebagai berikut:
· Kemudahan Penggunaan. Mampu mendapatkan sekitar situs dan menemukan
hal. Aspek penting termasuk sederhana, intuitif dan
konsisten navigasi.
· Pengalaman. Pengalaman visual dan pribadi
mengunjungi situs. Isu meliputi desain, penggunaan warna dan
gaya, serta kepentingan membangun dan rasa
komunitas.
· Informasi. Akses ke konten informasi yang berkualitas baik.
Informasi tersebut sesuai untuk konsumsi oleh
pengguna. Biasanya, informasi harus mudah dibaca
dan memahami, relevan, mutakhir, dapat diandalkan dan memberikan
melalui tingkat yang sesuai detail dan format.
· Komunikasi dan Integrasi. Cara situs ini
terintegrasi dengan lingkungan eksternal dan
komunikasi dengan pengguna. Ini termasuk mampu
menemukan dan kembali ke situs, integrasi atau hubungan dengan lainnya
situs, kecepatan dan keamanan komunikasi, dan
ketentuan untuk umpan balik dan kontak lainnya.
Kategori-kategori di atas memberikan beberapa kriteria yang berguna yang digunakan untuk
menilai situs web dari empat sekolah bisnis. Hal ini
dibahas pada subseksi berikutnya.
D. Analisis Menggunakan Situs Subkategori Pertanyaan
Menggunakan pengelompokan pertanyaan, kita dapat membangun sebuah profil dari suatu
individu-situs web yang mudah dibandingkan dengan yang
sezaman. Kita sekarang dalam posisi untuk memeriksa mengapa
beberapa situs bernasib lebih baik daripada yang lain pada indeks WebQual, sebagai
diberikan dalam Tabel 2. Gambar. 3 memberikan contoh bagaimana hal ini dapat
dicapai.
Sebagai titik awal, data tersebut diringkas sekitar
kuesioner subkategori. Kemudian, dan juga ke
WebQual Indeks pada Tabel 2, total skor untuk setiap kategori
adalah diindeks terhadap skor maksimum (berdasarkan
Pentingnya peringkat untuk pertanyaan dikalikan dengan 5). Gambar. 3 adalah
Hasilnya, yang tingkat masing-masing dari empat situs web menggunakan
kriteria. Perhatikan bahwa skala telah disesuaikan dengan antara 0,4
sampai 0,8 untuk memungkinkan perbandingan yang lebih jelas.
Gambar. 3 menunjukkan bahwa situs masing-masing memiliki kekuatan sendiri
dan kelemahan, yang diukur melalui suara pengguna atau
pelanggan. Sebagai contoh, situs web LBS menciptakan terbesar
dampak estetika dan dampak pada individu, dan nyenyak
terintegrasi secara eksternal, yang mudah ditemukan oleh pengguna, dan dengan
ekstensif link ke situs lain. Sebaliknya, situs Bath
mudah digunakan dan navigasi, menempatkan penekanan pada kualitas
informasi dan link komunikasi. Situs WBS tidak jauh
di belakang nilai tersebut. Namun, situs MBS jelas
kurang di sejumlah daerah, yang paling terasa dalam hal
estetika, dampak individu, navigasi dan kemudahan
digunakan, dengan subkategori informasi juga diberikan peringkat rendah.
E. Memperluas Model
Serta menyediakan informasi, situs web dapat
dianggap sebagai menyediakan layanan, terutama situs diarahkan
arah perdagangan elektronik. Ini adalah aspek aktif dari
situs web yang melampaui penyampaian informasi, pindah ke
interaktivitas seperti menempatkan perintah, melakukan pembayaran, dan
pelacakan status transaksi online. Oleh karena itu kami
menunjukkan bahwa literatur tentang kualitas pelayanan adalah relevan untuk
situs web karena kualitas informasi akan disertai dengan
persepsi kualitas layanan. Instrumen SERVQUAL [30]
adalah model mapan kualitas pelayanan dan telah
diterapkan di banyak domain, termasuk sistem informasi
efektifitas [23]. Tujuan kami adalah untuk menyesuaikan SERVQUAL
instrumen untuk menilai kualitas situs web layanan daripada IS
departemen kualitas layanan. Instrumen SERVQUAL
menggabungkan 5 dimensi kualitas pelayanan: tangibles,
keandalan, ketanggapan, jaminan, dan empati.
Tangibles, misalnya, prihatin dengan munculnya
fasilitas, karyawan, bahan, sedangkan reliabilitas adalah kemampuan untuk
melakukan layanan yang dijanjikan dependably dan akurat, dan
jaminan dicapai ketika karyawan menanamkan keyakinan dan
pelanggan merasa aman di tangan perusahaan. A pertama
perbandingan menunjukkan WebQual dan SERVQUAL bahwa banyak dari
0.40
0.50
0.60
0.70
0.80
Navigasi
Kemudahan Penggunaan Umum
Dampak Visual
Dampak individu
Mencari Info.
Info. Konten
Ext. Integrasi
Komunikasi
Mandi
LBS
MBS
WBS
Gambar. 3: Diagram Radar Subkategori WebQual untuk data Empat Set
karakteristik SERVQUAL tercakup dalam WebQual
(Misalnya, situs web tangibles) tetapi beberapa dimensi yang ditangani
kurang baik (misalnya, empati). Kami percaya bahwa dimensi-dimensi
akan sangat relevan dengan situs e-commerce di mana situs web
kualitas informasi akan perlu seimbang dengan situs web
kualitas layanan. Untuk tujuan ini perbandingan rinci WebQual
dengan SERVQUAL sedang dilakukan.
VI. RINGKASAN DAN PEKERJAAN MASA DEPAN
Instrumen WebQual dikembangkan dari kualitas
lokakarya dan diuji dalam domain website sekolah bisnis.
Analisis hasil menunjukkan bahwa WebQual
instrumen memiliki validitas, meskipun jelas pengujian lebih lanjut dengan
sampel yang lebih besar dan beragam diperlukan. Meskipun tujuan utama
dari penelitian ini adalah untuk mengembangkan instrumen WebQual, sebuah
Output yang diperlukan dari penelitian ini adalah peringkat dari bisnis
situs web sekolah. Untuk memeriksa untuk bias itu akan diinginkan untuk
melakukan survei WebQual sama menggunakan siswa dari masing-masing
sekolah bisnis untuk melihat sejauh mana penggunaan Bath
siswa dapat memiliki bias hasilnya.
Pembangunan masa depan instrumen jatuh ke dalam tiga utama
daerah. Pertama, kami akan mengembangkan instrumen melalui
aplikasi untuk domain yang berbeda dan populasi dan melakukan
lanjut statistik validitas tes untuk memastikan dan generalisasi
di seluruh domain (misalnya, pemesanan perjalanan). Kedua, kita akan
meningkatkan kuesioner melalui perbandingan dengan yang ada
instrumen - terutama Bailey dan Pearson untuk informasi
kualitas dan SERVQUAL untuk web-situs kualitas layanan - untuk
meningkatkan validitas internal dan untuk memeriksa validitas eksternal.
Ketiga, kami bertujuan untuk menyebarkan kualitas WebQual ke web-site
karakteristik dan fungsi situs web untuk memberikan instrumen
kemampuan prediksi. Sejalan dengan ini akan ada tes di mana
WebQual diberikan sebelum dan sesudah situs web desain ulang untuk
menilai oleh berapa banyak pengguna persepsi kualitas telah
ditingkatkan. Lebih umum, kita juga akan mencakup pembandingan
terhadap situs teladan atau terkenal, seperti Amazon
buku, sehingga organisasi dapat mengukur bagaimana mereka WebQual
Indeks membandingkan dengan para pemimpin industri dan industri
rata-rata.
REFERENSI
[1] E. Habel, M. Putih, dan K. Hahn, "Mengidentifikasi pengguna berbasis kriteria
untuk halaman Web ", internet Penelitian: Aplikasi Jaringan Elektronik
dan Kebijakan, 7 (4), 1997, hal 252 -262.
[2] J. E. Bailey, dan S.W. Pearson, "Pengembangan Alat untuk
Mengukur dan Menganalisa Kepuasan Pengguna ", Manajemen Sains,
29 (5), 1983, hlm 530-545.
[3] L. Berry, dan Parasuraman A., "Mendengarkan Pelanggan - The
Konsep Sistem Informasi Layanan-Kualitas ", Sloan
Management Review, Vol. 38 (3), 1997, hlm 65 -76.
[4] C. Bauer, dan A. Scharl, "Sebuah Kerangka Klasifikasi dan
Model Penilaian Otomatis Web-site Evaluasi ",
Prosiding Konferensi Eropa Ketujuh pada Sistem Informasi,
1999, hal 758-65
[5] M. Betts, "QFD Integr diciptakan dengan Rekayasa Perangkat Lunak",
Transaksi dari Simposium Kedua tentang Quality Function Deployment,
Novi, Michigan, 18-19 Juni, 1990.
[6] JL Bossert, Quality Function Deployment, pendekatan seorang praktisi,
Kualitas ASQC Tekan, Wisconsin, 1991.
[7] J. Brancheau, B. Janz, dan C. Wetherbe, "Kunci masalah dalam
sistem informasi manajemen: 1994 -95 SIM Delphi Hasil ",
MIS Quarterly, 20 (2), 1996, hlm 225-242.
[8] BPR Clements, Membuat dan Menjamin Kualitas, Kualitas Tekan ASQC,
Wisconsin, 1990.
[9] L. Cohen, Quality Function Deployment, Addison-Wesley, Reading,
MA, 1995.
[10] W.H. DeLone, dan ER McLean, "Sistem Informasi Sukses:
Quest untuk Variabel Dependent ", Sistem Informasi Riset,
3 (1), 1992, hlm 60-95.
[11] S. Dutta, dan A. Segev, "Transformasi Bisnis pada
Internet ", Eropa Jurnal Manajemen, 17 (5), 1999, hlm 466 -76.
[12] C. Firth, Ketika Apakah Permasalahan Data Kualitas Terjadi?, Tersedia [Online]
di: http://sunflower.singnet.com.sg/ ~ cfirth/dq1.htm, 1997.
[13] D. Garvin, "Apa Kualitas Produk Mean?", Sloan Management
Review, No 4, 1984, hlm 25 -43.
[14] S. Haag, M. Raja, dan L. Schkade, "Quality Function Deployment
Penggunaan dalam Pengembangan Perangkat Lunak ", Komunikasi ACM,
39 (1), 1996, hlm 39 -49.
[15] JR Hauser, dan D. Clausing, "Rumah Kualitas", Harvard
Business Review, 3 (Mei-Juni), 1988, hlm 63-73.
[16] B. Ives, M.H. Olson, dan J. Barouldi, "Pengukuran Pengguna
Kepuasan ", Komunikasi ACM, 26 (10), 1983, hlm 785 -
793.
[17] R. Raja, Desain Lebih Baik di Half Time: implementasi QFD,
TUJUAN / QPC, Methuen, Massachusetts, 1989.
[18] WR Raja, dan Epstein BJ, "Sistem Informasi Menilai
Nilai ", Decision Sciences, 14 (1), 1983, hlm 34-45.
[19] R.O. Mason, "Mengukur output Informasi: Sebuah Komunikasi
Pendekatan Sistem ", Pengolahan Informasi dan Manajemen, 1 (5),
1978, hlm 219-234.
[20] H. Miller, "Beberapa Dimensi Kualitas Informasi",
Sistem Informasi Manajemen, 13 (2), 1996, hlm 79 -82.
[21] J. Miller, dan B.A. Doyle, "Mengukur Efektivitas
Sistem Informasi Berbasis Komputer dalam Jasa Keuangan
Sektor ", MIS Quarterly, 11 (1), 1987, hlm 107 -117.
[22] V. Ribière, A.J. LaSalle, R. Khorramshahgol dan Y. Gousty,
"Rumah Sakit Sistem Informasi Kualitas: Sebuah Kepuasan Pelanggan
Alat Penilaian ", Prosiding Internasional Hawaii 32
Konferensi tentang Sistem Ilmu Pengetahuan, 1999.
[23] L. Pitt, R. Watson, dan C. Kavan, "Service Quality: suatu Mengukur
efektivitas sistem informasi ", MIS Quarterly, Juni, 1995, hlm
173-187.
[24] P. Schubert, dan D. Selz, "Web-Mengukur Penilaian
Efektivitas Situs Electronic Commerce Pergi luar
Paradigma Pemasaran Tradisional ", Prosiding Hawaii 32
Konferensi Internasional tentang Sistem Ilmu Pengetahuan, 1999.
[25] P. Schubert, dan D. Selz, "Web Penilaian - Model untuk
Evaluasi dan Penilaian Electronic Commerce Sukses
Aplikasi ", International Journal of Pasar Elektronik, 7 (3), 1997,
hal 46 -48.
[26] C. Shannon, dan W. Weaver, matematika Teori Komunikasi,
University of Illinois Press, Urbana, 1949.
[27] R. Slabey, "QFD: J Primer Dasar Kutipan dari.
implementasi manual untuk lokakarya QFD tiga hari ",
Transaksi dari Simposium Kedua tentang Quality Function Deployment,
Novi, Michigan, 18-19 Juni, 1990.
[28] D.M. Yang kuat, Y.W. Lee, dan R.Y. Wang, "Data kualitas dalam
konteks ", Komunikasi ACM, 40 (5),, 1997 hlm 103 -110.
[29] G. Yan, dan JC Paradi, Kriteria Sukses "untuk Lembaga Keuangan
dalam Electronic Commerce ", Prosiding Internasional Hawaii 32
Konferensi tentang Sistem Ilmu Pengetahuan, 1999.
[30] V. Zeithaml, A. Parasuram, dan L. Berry Kualitas, Menyampaikan
Layanan: persepsi pelanggan menyeimbangkan dan harapan, The Free Press,
New York, 1990.
[31] R. Zultner, "Kualitas Perangkat Lunak [Fungsi] Deployment: menerapkan
QFD untuk perangkat lunak ", Transaksi dari Simposium Kedua pada Kualitas
Fungsi Deployment, Novi, Michigan 18-19 Juni, 1990.
[32] R. Zultner, "TQM untuk Tim Teknis", Komunikasi dari
ACM, 36 (10), 1993, hlm 79 -91.

KW

-----------
Seorang pengusaha harus mampu bergaul dengan sebanyak mungkin teman. Keberhasilan sering kali karena mempertemukan banyak kepentingan satu orang dengan orang lain. Kemampuan seorang pengusaha dalam bergaul dengan orang lain harus di atas rata-rata. Oleh sebab itu, keterampilan membangun jaringan sangat diperlukan. Ada beberapa cara yang dapat dilakukan dalam membangun jaringan, yaitu:
&
Kadang usaha akan lebih bagus jika didirikan dan di kelola bersama-sama. Misalnya Anda pintar pemrograman komputer, tapi anda memiliki sedikit teman, sementara teman anda memiliki banyak teman dan punya relasi yang luas dan membutuhkan jasa pemrograman, anda bisa saja membuka usaha jasa pemrograman (software house). Anda yang mengerjakan pekerjaannya, sedangkan teman anda yang mencari order. Dari kelebihan masing-masing inilah bisa memperkuat suatu usaha baru sekaligus membesarkannya.
---------
Pengusaha yang berhasil adalah seseorang yang mampu mengenali peluang dengan baik. Tirto Utomo, perintis pertama air kemasan "Aqua" dan Pak Sosro, pencetus ide minuman "Teh Botol Sosro" merupakan contoh orang yang mampu mengenal peluang dengan baik dan akhirnya menjadi pengusaha sukses. Oleh sebab itu, mengenali peluang merupakan hal yang sangat penting. Peluang tersebut tidak harus menjadi hal yang pertama, karena yang kedua bisa menjadi lebih baik, atau yang ketiga justru tampil beda. Beberapa hal yang dapat dilakukan untuk meningkatkan keterampilan naluri mengenali peluang usaha adalah:

1) Menentukan arah usaha dan minat
Menentukan arah usaha dan minat dapat membuat kita berfokus pada pendalaman informasi tentang usaha.

2) Menumbuhkan kepekaan lingkungan dan kondisi di sekitar
Banyak usaha baru yang sebelumnya tidak terpikirkan untuk dilakukan ternyata berhasil karena besarnya faktor kebutuhan pelanggan. Contoh usaha tersebut adalah bisnis penitipan bayi di perkantoran yang timbul karena besarnya kebutuhan ibu-ibu aktif atau wanita karier yang memiliki anak kecil namun di sisi lain harus bekerja sehingga membutuhkan penitipan bayi yang dekat dengan lokasi kerja.

3) Menerapkan manajemen informasi
Tindakan ini dilakukan dengan mencari informasi sebanyak-banyaknya tentang usaha, kemudian diklasifikasi dan dapat dijadikan dasar pengambilan keputusan yang tepat. Informasi dapat diperoleh dari melihat, mendengar, dan mengalami. Saat ini, dunia Internet menyediakan informasi yang tidak terbatas. Oleh sebab itu, pemanfaatan Internet akan sangat membantu dalam memperoleh informasi, bahkan untuk memasarkan produk.
---------------
Siklus hidup produk adalah suatu konsep penting yang memberikan pemahaman tentang dinamika kompetitif suatu produk. Seperti halnya dengan manusia, suatu produk juga memiliki siklus atau daur hidup. Siklus Hidup Produk (Product Life Cycle) ini yaitu suatu grafik yang menggambarkan riwayat produk sejak diperkenalkan ke pasar sampai dengan ditarik dari pasar . Siklus Hidup Produk (Product Life Cycle) ini merupakan konsep yang penting dalam pemasaran karena memberikan pemahaman yang mendalam mengenai dinamika bersaing suatu produk. Konsep ini dipopulerkan oleh levitt (1978) yang kemudian penggunaannya dikembangkan dan diperluas oleh para ahli lainnya.

konsep dan prinsip design

Data Object Description
Menyimpan semua atribut entitas dan relasi yang muncul pada ERD
Data Dictionary
Menyimpan semua obyek data yang dibutuhkan & dihasilkan PL. Obyek data yang muncul seperti: ERD, DFD dan STD
Proses Specification
Berisi diskripsi setiap fungsi yang muncul pada DFD (sbagai tool mentransformasikan data)
C-SPEC
berisi diskripsi dari setiap status yang dapat muncul pada sistem


software requerment
Data design
 mengubah model informasi (entity relationship diagram dan data dictionary) menjadi struktur data
Architectural design
 berisi hubungan antar elemen dalam program
Interface design
 menjelaskan bagaimana bagaimana komunikasi di dalam perangkat lunak, dengan sistem, dan dengan manusia yang menggunakannya.
 Sebuah interface mengandung maksud sebuah aliran informasi.

Procedural design
 mengubah elemen struktural dari arsitektur program menjadi deskripsi prosedural dari komponen perangkat lunak



kualitas desan dan s.ware
Sebuah desain harus menunjukkan organisasi secara hirarkis
Sebuah desain harus bersifat modular; jadi, sebuah perangkat lunak seharusnya dapat dibagi-bagi secara lojik menjadi beberapa elemen yang melakukan fungsi atau subfungsi secara spesifik
Sebuah desain harus mengandung abstraksi data dan prosedural
Sebuah desain harus mengarah pada modul-modul (prosedur atau subrutin) yang menunjukkan karakteristik fungsional


prinsip desain
Prinsip Desain memungkinkan perekayasa
Perangkat lunak untuk mengendalikan proses desain
Proses desain tidak boleh mengalami “tunnel vision”
Desainer harus memperhatikan pendekatan-pendekatan alternatif, menilainya berdasarkan persyaratan masalah, sumber daya yang ada untuk melakukan pekerjaan, dan konsep desain
Desain harus dapat dilacak ke model analisis
Tidak melakukan desain pada hal yang sama berulang-ulang
Desain harus merepresentasikan masalah pada keadaan nyata
Desain harus memperlihatkan keseragaman dan integrasi


dokumentasi desain
Lingkup Sistem
Desain Data
Desain Arsitektur
Desain Antarmuka
Desain Prosedural
Catatan Khusus
Appendix

analisis modeling

definisi kebutuhan
Kebutuhan perangkat lunak adalah kondisi atau kemampuan yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang disyaratkan atau diinginkan oleh pemakai


jenis kebutuhan
Secara kategoris, ada tiga buah jenis kebutuhan perangkat lunak [IEE93]:
Kebutuhan fungsional (functional requirement)
Kebutuhan antarmuka (interface requirement)
Kebutuhan unjuk kerja (performance requirement)
Kebutuhan antarmuka dan unjuk kerja sering disebut Non-functional Requirement


jenis fungsional'
Disebut juga kebutuhan operasional, yaitu kebutuhan yang berkaitan dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh perangkat lunak.
Contoh:
Perangkat lunak harus dapat menyimpan semua rincian data pesanan pelanggan.
Perangkat lunak harus mampu mencetak laporan penjualan sesuai periode yang diinputkan.
Perangkat lunak harus mampu menyajikan informasi jalur pengiriman terpendek.


jenis antar muka
Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak, atau basis data.
Contoh:
Akses ke basis data menggunakan ODBC (Open Data Base Connectivity).
Perangkat untuk memasukkan data menggunakan keyboard, mouse, dan scanner.


kebutuhan utk kerja
Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh perangkat lunak, seperti kecepatan, ketepatan, atau frekuensi.
Contoh:
Waktu tanggap penyajian informasi maksimal selama satu menit.
Perangkat lunak harus mampu mengolah data sampai 1 juta record untuk setiap transaksi.
Perangkat lunak harus dapat digunakan secara multi user sesuai otoritas yang diberikan kepada masing-masing pemakai.


analisis kbthn
Analisis kebutuhan perangkat lunak dapat diartikan sebagai:
 Proses mempelajari kebutuhan pemakai untuk mendapatkan definisi kebutuhan sistem atau perangkat lunak [IEE93].
 Proses untuk menetapkan fungsi dan unjuk kerja perangkat lunak, menyatakan antarmuka perangkat lunak dengan elemen-elemen sistem lain, dan menentukan kendala yang harus dihadapi oleh perangkat lunak [PRE01].



ptngya analisis kbhtn
Pendefinisian kebutuhan yang baik dapat menjadi faktor sukses pelaksanaan pengembangan perangkat lunak. Sebaliknya akan menyebabkan banyak kegagalan.
Menurut hasil survey DeMarco, 56% kegagalan proyek perangkat lunak adalah karena ketidaklengkapan pendefinisian kebutuhan.


tahap analisis kebutuhan
Secara teknis pelaksanaan pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari urutan aktivitas:
Mempelajari dan memahami persoalan
Mengidentifikasi kebutuhan pemakai
Mendefinisikan kebutuhan perangkat lunak
Membuat dokumen spesifikasi kebutuhan
Mengkaji ulang (review) kebutuhan


membuat dokumen
Semua kebutuhan yang telah didefinisikan selanjutnya dibuatkan dokumentasinya, yaitu Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirements Specification (SRS).
SKPL yang dibuat harus dapat menyatakan secara lengkap apa yang dapat dilakukan oleh perangkat lunak, termasuk deskripsi lengkap dari semua antarmuka yang digunakan.
SKPL bisa terdiri dari banyak dokumentasi yang saling melengkapi.



mengkaji ulang kebutuhan
Proses untuk memeriksa (validasi) SKPL apakah sudah konsisten, lengkap, dan sesuai dengan apa yang diinginkan pemakai.
Proses ini mungkin dilakukan lebih dari satu kali.
Dan sering kali muncul kebutuhan-kebutuhan baru dari pemakai.
Untuk itu, diperlukan negosiasi antara pihak pengembang dengan pemakai sesuai prinsip “win-win solution” sampai kebutuhan tersebut dapat disepakati kedua belah pihak.