METODOLOGI PENGEMBANGAN PERANGKAT LUNAK PROTOTYPE
I. PENDAHULUAN
Prototype merupakan metodologi pengembangan software yang menitik-beratkan pada pendekatan aspek desain, fungsi dan user-interface. Developer dan user fokus pada user-interface dan bersama-sama mendefinisikan spesifikasi, fungsi, desain dan bagaimana software bekerja. Developer dan user bertemu dan melakukan komunikasi dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan. Developer mengumpulkan detail dari kebutuhan dan memberikan suatu gambaran dengan cetak biru (prototype).
Dari proses tersebut akan diketahui detail-detail yang harus dikembangkan atau ditambahkan oleh developer terhadap cetak biru, atau menghapus detail-detail yang tidak diperlukan oleh user. Proses akan terjadi terus menerus sehingga produk sesuai dengan keinginan dari user.
Tujuan utama dari prototype [Thompson, Wishbow - 1992] adalah :
* Proses revisi dan pengujian terhadap produk dilakukan secara terus menerus, sehingga didapatkan produk yang sesuai dengan yang diinginkan oleh user. Proses testing dan revisi dapat dilakukan baik secara keseluruhan maupun partial pada bagian dari produk.
* Proses pengujian harus memiliki perbandingan baku (benchmark) sehingga menghasilkan produk yang secara empiris sehinga menghindari kegagalan produk atau terjadi perbedaan persepsi antara developer atau user.
* Dengan proses testing dan komunikasi yang terus menerus antara user dan developer diharapkan dihasilkan produk yang user-friendly.
II. METODOLOGI
[Purtilo, Larson, Clark-1991] mengambarkan proses-proses pada model prototype sebagai berikut:
1. Identifikasi objek, definisi dari masalah yang harus dipecahkan dinyatakan secara bersama-sama dengan memberikan ukuran-ukuran yang pasti terhadap batasan kesuksesan dari produk yang digunakan sebagai benchmark.
2. Identifikasi resiko, tidak ada pengembangan produk yang bersih dan mampu menghasilkan produk yang berstatus “Tidak ada Masalah”, selalu terdapat area abu-abu yang memberikan resiko terhadap pengembangan produk. Perjelas dan pertegas batasan dan permasalahan pada area tersebut.
3. Merumuskan hipotesa prototype, setelah resiko dinyatakan pengembang mendesain secara terperinci sebuah prototype yang menggambarkan keseluruhan sistem dan resiko-resiko yang mungkin berpengaruh pada sistem. Prototype juga memberikan potensi terhadap perbaikan-perbaikan terhadap produk.
4. Membangun perancangan prototype, perancangan prototype berdasarkan hipotesa kedalam produk prototype. Tujuan yang utama dari membangun suatu prototipe adalah untuk menjawab satu atau lebih pertanyaan mengenai karakteristik fungsional dari produk .
5. Eksperimental, prototipe harus dicoba-coba untuk menentukan perilakunya dan mengumpulkan keluaran dari instrumentasi sistem sehingga didapat produk yang sesuai dengan keinginan user.
6. Evaluasi, Hasil dari eksperimen harus dievaluasi untuk menilai kebenaran dan efisiensi prototype.
7. Proses yang berulang-ulang, proses yang keseluruhan diulangi sampai salah satu dari tiga hasil dicapai:
* Didapat informasi yang cukup dari prototype sehingga dapat dimulainya proses pengembangan produk.
* Untuk beberapa masalah yang tidak terpecahkan telah dapat ditemukan solusi yang lebih mudah atau setara dengan tetap memperhatikan cost dan manfaat.
* Didapat prototype yang memiliki mutu yang sesuai dengan spesifikasi produk yang ingin dibuat sehingga proses pembuatan produk dapat dilakukan dengan menggunakan prototype yang ada.
III. KETERGANTUNGAN TERHADAP USER
User atau pengguna merupakan bagian terpenting pada prototype. Karena user merupakan komponen yang menentukan apakah prototype telah memenuhi spesifikasi untuk dikembangkan sebagai produk.
[Harker -1993] memaparkan tentang permasalahan yang terjadi pada metodologi prototype :
* User yang tidak memiliki spesialisasi dalam pembuatan dan perancangan sistem akan memberikan input yang akan mempersulit pembuatan prototype.
* Prototype yang dikembangkan secara tim memerlukan kepastian dapat menangani keinginan user terutama dilevel manajemen.
* Perancangan prototype akan tidak relevan dan menyulitkan jika pada lever user terjadi perubahan struktur organisasi yang cenderung lebih besar pengaruhnya dinding perubahan secara teknis
IV. TIPE-TIPE PROTOTYPE
Terdapat 3 (tiga) tipe dari metodologi prototype [Sommerville, 1995]:
* Throwaway Prototypes
Model Throwaway Prototypes mengunakan prototype sebagai tool atau perangkat untuk melakukan analisa terhadap user-interface dan kebutuhan fungsional dari produk yang ingin dibuat. ketika prototype dievaluasi dan spesifikasi dibaharui, prototype dibuang dan proses pengembangan dimulai kembali.
* Evolutionary Prototypes
Evalusi prototype didasarkan pada pengembangan produk dengan melakukan peningkatan pada detail-detail yang dianggap perlu diperbaharui. Proses akan dilakukan secara terus menerus dalam satu produk dan dilakukan hingga didapat produk yang sesuai dengan keinginan dari user.
* Incremental Development
Metodologi ini masing-masing dievaluasi berdasarkan bagian-bagian secara partial jika terjadi perubahan akan dilakukan secara partial juga. Setelah didapatkan potongan-potongan produk yang sesuai, maka disatukan untuk mendapatkan produk yang sesuai dengan keinginan user.
V. KEUNTUNGAN
Keuntungan dari metodologi prototype adalah [Sommerville, 1995] :
* Kegagalan dalam mendefinisikan masalah antara user dan developer dapat dikenali dari awal.
* Kesulitan user-interface dan pemakaian dapat dikenali dari awal
* Manajemen telah melihat gambaran secara riil tentang produk yang dibuat dengan melihat prototype dari produk.
* Prototype dapat disebut juga sebagai bagian dari training penggunaan produk, sehingga user telah mengenal produk dari prototype.
* Proses testing dan perbaikan dapat dilakukan secara terus menerus sehingga mengurangi tingkat kegagalan produk.
* Prototype lebih mengedepankan pada requirement sehingga mampu menghasilkan produk yang berkualitas dan sesuai dengan keinginan dari user.
Sumber
0 Teknik Estimasi pada Suatu Proyek Sistem Informasi
Rabu, 18 Mei 2011
Label:
tugas PPSI
1. PENDAHULUAN
Estimasi merupakan sebuah proses pengulangan. Pemanggilan ulang estimasi yang pertama dilakukan selama fase definisi, yaitu ketika anda menulis rencana pendahuluan proyek. Hal ini perlu dilakukan, karena anda membutuhkan estimasi untuk proposal. Setelah fase analisis direncanakan ulang, anda harus memeriksa estimasi danmerubah rencana pendahuluan proyek menjadi rencana akhir proyek.
2. TEKNIK–TEKNIK ESTIMASI
Ada tiga teknik yang digunakan untuk melakukan estimasi, yaitu :
2.1 Keputusan Profesional
Katakanlah bahwa anda merupakan orang yang memiliki pengalaman yang luas dalam membuat program “report generation modules”. Anda melakukannya dengan pendekatan merancang report tersebut dan memperkirakan berapa lama waktu yang dibutuhkan untuk membuat program tersebut. Setelah mempelajari rancangan program selama 5 menit, programmer lalu menutup matanya selama 5 menit (dia tidak tidur, tetapi berhitung), dan kemudian mengatakan “15 hari”. Inilah yang disebut Keputusan Profesional murni. Keuntungan dari teknik ini adalah cepat , dan jika seseorang sudah ahli dalam teknik ini, maka estimasinya pasti akan lebihakurat. Sedangkan kerugian dari teknik ini adalah bahwa anda membutuhkan seorang ahli yang berpengalaman dalam bidang ini, dan beberapa ahli tersebut akan bekerja keras untuk mendapatkan estimasi yang tepat.Pengelolaan Proyek Sistem Informasi.
2.2 Sejarah
Jalan keluar dari ketergantungan pada orang dan untuk membuat estimasi lebih khusus, yaitu anda harus mengerti tentang sejarahnya. Tulislah berapa lama masing-masing tugas dapat diselesaikan dan siapa yang bertanggung jawab atas tugas tersebut. Anda dapat membandingkan tuagas yang akan diestimasik dengan tugas yang sama yang dikerjakan lebih awal, setelah itu mulailah dengan melakukan estimasi. Hal ini dimaksudkan agar anda menjabarkan suatu proyek ke dalam beberapa tugas yang biasanya diulang dan mudah untuk dibandingkan.
2.3 Rumus-rumus
Ada beberapa rumus yang digunakan dalam software estimasi.
Software yang baik untuk diketahui adalah COCOMO (Referensi 15). COCOMO dapat digunakan untuk memperkirakan biaya proyek, usaha (person months), jadwal, dan jumlah staf untuk masing-masing fase berikut ini:
- Preliminary Design - our Analysis Phase
- Detailed Design (DD) - our Design Phase
- Code and Unit Tes (CUT) - same as ours
- System Test - our System Test and Acceptance Phase
Ada 3 tipe penginputan dengan COCOMO
Pengelolaan Proyek Sistem Informasi
VERY CMPLX
3. ATURAN PERSETUJUAN ESTIMASI PADA DEC (DAN PERUSAHAAN BESAR LAINNYA)
Apakah perusahaan besar seperti DEC menggunakan pendekatanpendekatan ini ? Ya, mereka menggunakan rumus-rumus, tetapi mereka tetap mengikuti aturan berikut ini :
• Jangan pernah menanyakan pada seseorang yang tidak berpengalaman untuk melakukan estimasi.
• Lakukan estimasi secara berkelompok, jika anda mampu menyediakan sumber daya manusianya.
• Jangan memaksa melakukan estimasi pada seseorang profesional, seperti programmer.
• Jangan pernah mengambil rata-rata dari estimasi yang berbeda.
• Membagi persoalan menjadi bagian kecil secara mendetail selama satu minggu atau kurang.
• Selalu tambahkan (kalikan ?) untuk kejadian yang tidak pasti.
• Selalu berikan jangka waktu ketika melakukan estimasi bagi manajer atau klien.
• Gunakan naluri anda.
sumber : http://zhymel.blogspot.com/2011/05/teknik-estimasi-pada-suatu-proyek.html
Estimasi merupakan sebuah proses pengulangan. Pemanggilan ulang estimasi yang pertama dilakukan selama fase definisi, yaitu ketika anda menulis rencana pendahuluan proyek. Hal ini perlu dilakukan, karena anda membutuhkan estimasi untuk proposal. Setelah fase analisis direncanakan ulang, anda harus memeriksa estimasi danmerubah rencana pendahuluan proyek menjadi rencana akhir proyek.
2. TEKNIK–TEKNIK ESTIMASI
Ada tiga teknik yang digunakan untuk melakukan estimasi, yaitu :
2.1 Keputusan Profesional
Katakanlah bahwa anda merupakan orang yang memiliki pengalaman yang luas dalam membuat program “report generation modules”. Anda melakukannya dengan pendekatan merancang report tersebut dan memperkirakan berapa lama waktu yang dibutuhkan untuk membuat program tersebut. Setelah mempelajari rancangan program selama 5 menit, programmer lalu menutup matanya selama 5 menit (dia tidak tidur, tetapi berhitung), dan kemudian mengatakan “15 hari”. Inilah yang disebut Keputusan Profesional murni. Keuntungan dari teknik ini adalah cepat , dan jika seseorang sudah ahli dalam teknik ini, maka estimasinya pasti akan lebihakurat. Sedangkan kerugian dari teknik ini adalah bahwa anda membutuhkan seorang ahli yang berpengalaman dalam bidang ini, dan beberapa ahli tersebut akan bekerja keras untuk mendapatkan estimasi yang tepat.Pengelolaan Proyek Sistem Informasi.
2.2 Sejarah
Jalan keluar dari ketergantungan pada orang dan untuk membuat estimasi lebih khusus, yaitu anda harus mengerti tentang sejarahnya. Tulislah berapa lama masing-masing tugas dapat diselesaikan dan siapa yang bertanggung jawab atas tugas tersebut. Anda dapat membandingkan tuagas yang akan diestimasik dengan tugas yang sama yang dikerjakan lebih awal, setelah itu mulailah dengan melakukan estimasi. Hal ini dimaksudkan agar anda menjabarkan suatu proyek ke dalam beberapa tugas yang biasanya diulang dan mudah untuk dibandingkan.
2.3 Rumus-rumus
Ada beberapa rumus yang digunakan dalam software estimasi.
Software yang baik untuk diketahui adalah COCOMO (Referensi 15). COCOMO dapat digunakan untuk memperkirakan biaya proyek, usaha (person months), jadwal, dan jumlah staf untuk masing-masing fase berikut ini:
- Preliminary Design - our Analysis Phase
- Detailed Design (DD) - our Design Phase
- Code and Unit Tes (CUT) - same as ours
- System Test - our System Test and Acceptance Phase
Ada 3 tipe penginputan dengan COCOMO
Pengelolaan Proyek Sistem Informasi
VERY CMPLX
3. ATURAN PERSETUJUAN ESTIMASI PADA DEC (DAN PERUSAHAAN BESAR LAINNYA)
Apakah perusahaan besar seperti DEC menggunakan pendekatanpendekatan ini ? Ya, mereka menggunakan rumus-rumus, tetapi mereka tetap mengikuti aturan berikut ini :
• Jangan pernah menanyakan pada seseorang yang tidak berpengalaman untuk melakukan estimasi.
• Lakukan estimasi secara berkelompok, jika anda mampu menyediakan sumber daya manusianya.
• Jangan memaksa melakukan estimasi pada seseorang profesional, seperti programmer.
• Jangan pernah mengambil rata-rata dari estimasi yang berbeda.
• Membagi persoalan menjadi bagian kecil secara mendetail selama satu minggu atau kurang.
• Selalu tambahkan (kalikan ?) untuk kejadian yang tidak pasti.
• Selalu berikan jangka waktu ketika melakukan estimasi bagi manajer atau klien.
• Gunakan naluri anda.
sumber : http://zhymel.blogspot.com/2011/05/teknik-estimasi-pada-suatu-proyek.html
0 Langkah-Langkah Pemrograman
Senin, 11 April 2011
Label:
tugas PPSI
Langkah 1. Rencana Penggabungan (Plan The Integration)
Menurut akal sehat anda tidak akan dapat membuat semua program sekaligus dan kemudian membuang semuanya – ini memerlukan rangkaian langkah demi langkah. Rencanakan urutan dimana anda akan menggabungkannya.
Langkah 2. Mendisain Modul (Design The Module)
Programmer menerima beberapa tingkatan disain dari fase disain. Tugasnya adalah memecah modul secara rinci ke tingkat yang lebih rendah sampi mencapai keadaan programmer siap untuk melakukan pemrograman. Ini disebut disain modul.
Langkah 3. Telusuri Disain Modul(Walk Through The Module Design)
Seperti pada tingkat atas dan menengah dari disain, pertukaran harus dibuat sebaiknya pada tingkat yang paling rendah. Telusuri disain dari masing-masing modul sebelum melakukan pengkodean. Penelusuran ini sangat kecil : hanya programmer yang tepat, supervisor dan mungkin programmer lainnya yang perlu diperhatikan. Kegunaan dari penelusuran disain modul adalah untuk memastikan bahwa disain yang terbaik yang telah dilakukan, semua fungsi telah dialamatkan dan semua bagian telah ditangani.
Langkah 4. Rencana Bagaimana Menguji Modul (Plan How To Test The Module)
Programmer harus menyiapkan rencana pengujian modul dan data pengujian sebelum dikodekan. Rencana pengujian dilakukan setelah kode ditetapkan. Mereka cenderung hanya menguji bagian kode yang paling ‘sulit’. Pimpinan proyek bisa saja melakukan tuntutan pada penelusuran rencana pengujian sepanjang disain modul sedang dilaksanakan. Kerjakan penelusuran ini bersama-sama.
Langkah 5. Kode Setiap Modul (Code Each Module)
Standar pengkodean akan ditetapkan pada saat disain sistem. Kita tidak membahas bagaimana membuat program – lihat Referensi 12 (tulisan ini membahas disain sama baiknya dengan pemrograman) dan Referensi 13 untuk lebih jelasnya.
Berikut ini adalah ringkasan dari sebuah program terstruktur, yaitu :
· Jika berukuran kecil. Aturan dasarnya adalah kira-kira 100 baris kode yang dapat dieksekusi dan listingnya tidak lebih dari 2 halaman.
· Satu entry, satu exit.
· Referensi secara keseluruhan sedikit.
· Konstruksi terstruktur yang digunakan : berurutan, IF/THEN/ELSE, CASE, WHILE, UNTIL, CALL (bukan GO TO).
Langkah 6. Menguji Modul (Test The Module)
Programmer menguji modul dengan menetapkan lingkungan yang tepat, menyediakan beberapa input, membiarkan modul langsung memproses secara logik dan mendapatkan hasilnya. Beberapa input mungkin tidak sebenarnya, terutama jika modul tersebut tidak menyediakan input yang sebenarnya.
Modul seharusnya diuji dalam dua tahap, yaitu :
· Tahap Pertama disebut pengujian “White Box”. Programmer harus mengetahui isi di dalam modul dan menyediakan data pengujian, sehingga masing-masing path logical dalam program dapat dieksekusi.
· Tahap Kedua atau pengujian “Black Box” dapat dilakukan. Dalam pengujian ini, programmer mengabaikan bagian dalam dari modul – data disediakan secara berurut dan dianggap seperti pemakaian sebenarnya.
Langkah 7. Menguji Level Terendah dari Integrasi (Test The Lowest Levels Of Integration)
Jika modul utama memanggil sub-modul, programmer harus menggabungkan dan menguji semua modul secara bersama-sama. Bahkan jika programmer tidak bertanggung jawab untuk menulis sub-modul, programmer harus menguji perintah CALL dan RETURN dari seluruh modul.
Metode terbaik untuk melakukan hal ini adalah membuat sebuah “program stub” (potongan program) sebagai pengganti sub-modul. Potongan program ini dapat terdiri dari empat baris program yang menunjukkan bahwa kontrol sudah diterima dengan baik, tampilkan parameter penerima, jika perlu lakukan pengontrolan kembali dengan beberapa parameter yang tidak sebenarnya.
Langkah 8. Menyimpan Semua Hasil Pengujian; Penggabungan Modul-modul Yang Telah Diuji (Save The Results Of All Tests; Submit Finished Modules To Integration)
Hasil pengujian digunakan untuk menyusun statistik yang menunjukkan penyebab, cara perbaikan serta biaya-biaya yang dibutuhkan untuk memperbaiki kesalahan-kesalahan program. Pimpinan proyek biasanya menguasai/mengepalai penggabungan ini pada sistem berukuran kecil sampai sedang.
Software seperti CMS (Code Management System) sangat berguna untuk menajemen konfigurasi – menjamin program tetap berjalan sesuai versinya dan mengubah ke source code.
Langkah 9. Memulai Dokumentasi User (Get Started On The User Documentation)
Apakah programmer bertanggung jawab pada dokumentasi user atau tidak, tahapan ini adalah waktu terbaik untuk menjawabnya
Sumber : Link
Menurut akal sehat anda tidak akan dapat membuat semua program sekaligus dan kemudian membuang semuanya – ini memerlukan rangkaian langkah demi langkah. Rencanakan urutan dimana anda akan menggabungkannya.
Langkah 2. Mendisain Modul (Design The Module)
Programmer menerima beberapa tingkatan disain dari fase disain. Tugasnya adalah memecah modul secara rinci ke tingkat yang lebih rendah sampi mencapai keadaan programmer siap untuk melakukan pemrograman. Ini disebut disain modul.
Langkah 3. Telusuri Disain Modul(Walk Through The Module Design)
Seperti pada tingkat atas dan menengah dari disain, pertukaran harus dibuat sebaiknya pada tingkat yang paling rendah. Telusuri disain dari masing-masing modul sebelum melakukan pengkodean. Penelusuran ini sangat kecil : hanya programmer yang tepat, supervisor dan mungkin programmer lainnya yang perlu diperhatikan. Kegunaan dari penelusuran disain modul adalah untuk memastikan bahwa disain yang terbaik yang telah dilakukan, semua fungsi telah dialamatkan dan semua bagian telah ditangani.
Langkah 4. Rencana Bagaimana Menguji Modul (Plan How To Test The Module)
Programmer harus menyiapkan rencana pengujian modul dan data pengujian sebelum dikodekan. Rencana pengujian dilakukan setelah kode ditetapkan. Mereka cenderung hanya menguji bagian kode yang paling ‘sulit’. Pimpinan proyek bisa saja melakukan tuntutan pada penelusuran rencana pengujian sepanjang disain modul sedang dilaksanakan. Kerjakan penelusuran ini bersama-sama.
Langkah 5. Kode Setiap Modul (Code Each Module)
Standar pengkodean akan ditetapkan pada saat disain sistem. Kita tidak membahas bagaimana membuat program – lihat Referensi 12 (tulisan ini membahas disain sama baiknya dengan pemrograman) dan Referensi 13 untuk lebih jelasnya.
Berikut ini adalah ringkasan dari sebuah program terstruktur, yaitu :
· Jika berukuran kecil. Aturan dasarnya adalah kira-kira 100 baris kode yang dapat dieksekusi dan listingnya tidak lebih dari 2 halaman.
· Satu entry, satu exit.
· Referensi secara keseluruhan sedikit.
· Konstruksi terstruktur yang digunakan : berurutan, IF/THEN/ELSE, CASE, WHILE, UNTIL, CALL (bukan GO TO).
Langkah 6. Menguji Modul (Test The Module)
Programmer menguji modul dengan menetapkan lingkungan yang tepat, menyediakan beberapa input, membiarkan modul langsung memproses secara logik dan mendapatkan hasilnya. Beberapa input mungkin tidak sebenarnya, terutama jika modul tersebut tidak menyediakan input yang sebenarnya.
Modul seharusnya diuji dalam dua tahap, yaitu :
· Tahap Pertama disebut pengujian “White Box”. Programmer harus mengetahui isi di dalam modul dan menyediakan data pengujian, sehingga masing-masing path logical dalam program dapat dieksekusi.
· Tahap Kedua atau pengujian “Black Box” dapat dilakukan. Dalam pengujian ini, programmer mengabaikan bagian dalam dari modul – data disediakan secara berurut dan dianggap seperti pemakaian sebenarnya.
Langkah 7. Menguji Level Terendah dari Integrasi (Test The Lowest Levels Of Integration)
Jika modul utama memanggil sub-modul, programmer harus menggabungkan dan menguji semua modul secara bersama-sama. Bahkan jika programmer tidak bertanggung jawab untuk menulis sub-modul, programmer harus menguji perintah CALL dan RETURN dari seluruh modul.
Metode terbaik untuk melakukan hal ini adalah membuat sebuah “program stub” (potongan program) sebagai pengganti sub-modul. Potongan program ini dapat terdiri dari empat baris program yang menunjukkan bahwa kontrol sudah diterima dengan baik, tampilkan parameter penerima, jika perlu lakukan pengontrolan kembali dengan beberapa parameter yang tidak sebenarnya.
Langkah 8. Menyimpan Semua Hasil Pengujian; Penggabungan Modul-modul Yang Telah Diuji (Save The Results Of All Tests; Submit Finished Modules To Integration)
Hasil pengujian digunakan untuk menyusun statistik yang menunjukkan penyebab, cara perbaikan serta biaya-biaya yang dibutuhkan untuk memperbaiki kesalahan-kesalahan program. Pimpinan proyek biasanya menguasai/mengepalai penggabungan ini pada sistem berukuran kecil sampai sedang.
Software seperti CMS (Code Management System) sangat berguna untuk menajemen konfigurasi – menjamin program tetap berjalan sesuai versinya dan mengubah ke source code.
Langkah 9. Memulai Dokumentasi User (Get Started On The User Documentation)
Apakah programmer bertanggung jawab pada dokumentasi user atau tidak, tahapan ini adalah waktu terbaik untuk menjawabnya
Sumber : Link
0 parallel run (periode percobaan)
Label:
tugas PPSI
Periode percobaan atau parallel run adalah pendekatan yang paling umum untuk penerimaan. Menggunakan pendekatan ‘Periode Percobaan’ tim proyek mudah memasang sistem baru untuk dicoba oleh user. Pendekatan ‘Parallel Run’ menambahkan dimensi untuk peralihan sistem lama yang sudah berjalan dengan baik sebagai perbandingan dan cadangan.
Dalam kedua kasus ini klien menggunakan sistem baru selama ‘X’ hari. Jika tidak ada masalah maka user menerimanya, jika ada masalah maka tim proyek berusaha memperbaikinya dan melakukan kembali percobaan selama ‘X’ hari.
Pendekatan ini cukup mudah, tetapi ada beberapa kekurangan :
1. Masalah kecil dapat membuat anda menjalankan kembali selama ‘X’ hari untuk jangka waktu yang tidak terbatas. Kadang-kadang sistem software yang rumit tidak pernah 100% di-debug.
2. Mungkin sulit untuk mencari penyebab dari suatu masalah. Jika 10 user berada pada sistem yang interaktif dan sistem tersebut rusak, ini merupakan tantangan untuk menemukan dengan tepat apa yang menyebabkan sistem tersebut rusak.
3. Tidak ada jaminan bahwa semua kelebihan sistem akan dicoba dalam ‘X’ hari. Penulis pernah melihat sebuah sistem akuntansi yang diterapkan pada awal tahun fiskal baru. Sistem itu berjalan baik selama masa percobaan (6 bulan) sampai mengalami kegagalan pada akhir tahun fiskal ketika akuntan mencoba untuk melakukan tutup buku. Sayangnya garansinya telah habis dan penjual (vendor) tidak mau memperbaikinya.
4. Biarkan end user masuk ke sistem pada hari pertama yang penerapannya tidak selalu bermanfaat. Karena dalam hal ini faktor penampilan lebih berperan. Seperti dalam roman, kesan pertama sangat penting.
Untuk selengkapnya dapat diunduh disini: Sumber
Dalam kedua kasus ini klien menggunakan sistem baru selama ‘X’ hari. Jika tidak ada masalah maka user menerimanya, jika ada masalah maka tim proyek berusaha memperbaikinya dan melakukan kembali percobaan selama ‘X’ hari.
Pendekatan ini cukup mudah, tetapi ada beberapa kekurangan :
1. Masalah kecil dapat membuat anda menjalankan kembali selama ‘X’ hari untuk jangka waktu yang tidak terbatas. Kadang-kadang sistem software yang rumit tidak pernah 100% di-debug.
2. Mungkin sulit untuk mencari penyebab dari suatu masalah. Jika 10 user berada pada sistem yang interaktif dan sistem tersebut rusak, ini merupakan tantangan untuk menemukan dengan tepat apa yang menyebabkan sistem tersebut rusak.
3. Tidak ada jaminan bahwa semua kelebihan sistem akan dicoba dalam ‘X’ hari. Penulis pernah melihat sebuah sistem akuntansi yang diterapkan pada awal tahun fiskal baru. Sistem itu berjalan baik selama masa percobaan (6 bulan) sampai mengalami kegagalan pada akhir tahun fiskal ketika akuntan mencoba untuk melakukan tutup buku. Sayangnya garansinya telah habis dan penjual (vendor) tidak mau memperbaikinya.
4. Biarkan end user masuk ke sistem pada hari pertama yang penerapannya tidak selalu bermanfaat. Karena dalam hal ini faktor penampilan lebih berperan. Seperti dalam roman, kesan pertama sangat penting.
Untuk selengkapnya dapat diunduh disini: Sumber
0 etika dan profesionalisme TSI (softskill)
Selasa, 22 Maret 2011
Label:
softskill
nama kelompok :
- Achmad Fachroji (121-07-145)
- Ibrahim Adha S (101-07-854)
- Kiki Robiansyah (101-07-983)
