POST TEST RENCANA TEST PENERIMAAN

Tahap-tahap yang harus dicek pada kegiatan rencana penerimaan diantaranya adalah :

1. PERIODE PERCOBAAN ATAU PARALLEL RUN

Periode percobaan atau parallel run adalah pendekatan yang paling umum untuk penerimaan. Pada periode percobaan ini tim proyek atau pengembang membuat system baru yang diinginkan oleh user. Sedangkan pada parallel run tim proyek atau pengembang  untuk peralihan sistem lama yang sudah berjalan dengan baik sebagai perbandingan dan cadangan.

2. SOLUSI : PENERIMAAN YANG LENGKAP SEDIKIT DEMI SEDIKIT

Pendekatan adalah menemukan serangkaian tes yang mendemonstrasikan semua fungsi yang telah dijanjikan. Tes akan di lakukan kepada pelanggan secara resmi dan keberhasilan tes diakhiri satu per satu.

Pendekatan ini mempunyai manfaat sebagai berikut :

a. Anda dapat mendemonstrasikan semua fungsi yang dijanjikan.

b. Sebuah tindakan yang menyebabkan masalah selalu diketahui – anda mengetahui dengan tepat siapa yang mengetik ketika masalah terjadi.

c. User tidak merasa takut tentang semuanya.

Memerlukan banyak pekerjaan untuk menulis ATP merupakan kerugian dari pendekatan ini .

3. MEMASTIKAN BAHWA SEMUA YANG DIJANJIKAN AKAN DIUJI

Akan memastikan semua akan di uji langsung satu demi satu, dan akan dibuat daftar menu tes yang dapat dites

4. MENGGUNAKAN DISAIN

Disain ini dapat membantu mengelompokan tes ke dalam serangkain tes yang akan di uji pada fungsi utama

5. MENULIS PERCOBAAN

Pada tahap ini bagaimana anda sudah siap untuk menentukan menguji item ketika pengisian pada metoda percobaan.

6. DAFTAR RENCANA TES PENERIMAAN

Daftar pengecekan yang dilakukan pada rencana penerimaan:

    Hasilkan Fungsi vs. Tabel Percobaan dan semua FS yang dijanjikan telah dialamatkan
    Definiskan percobaan dan kumpulan percobaan
    Tetapkan tanggung jawab untuk menulis percobaan
    Klien dan Tim proyek mengetahui bahwa ATP akan ditinjau kembali, direvisi jika perlu, dan ditandatangani oleh user
    Tanggung jawab untuk percobaan data telah ditetapkan.

7. KESIMPULAN UNTUK RENCANA TES PENERIMAAN

User di anjurkan untuk menulis ATP dan tim proyek harus membangun proyek dengan melalui percobaan.

8. KESIMPULAN UNTUK TAHAP DISAIN

    Dokumen Spesifikasi Disain memuat disain akhir tingkat atas melalui disain tingkat menengah
    Tanggung jawab ATP disahkan dan dimulai
    Perlu peninjauan kembali untuk rencana proyek.

PRETEST RENCANA TEST PENERIMAAN

Tujuan dari penerimaan adalah mendapatkan pernyataan tertulis dari user bahwa produk (dalam hal ini sistem) yang dikirim sesuai dengan yang dijanjikan.

Tahap – tahap yang terdapat dalam Rencana Tes Penerimaan ::

1. PERIODE PERCOBAAN ATAU PARALLEL RUN (THE TRIAL PERIOD OR PARALLEL RUN)
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.
Beberapa kekurangan pada Periode Paralel Run diantaranya :
a. Masalah kecil dapat membuat anda menjalankan kembali selama “x” untuk jangka waktu yag tidak terbatas.
b. Sulit untuk mencari penyebab dari suatu masalah.
c. Tidak ada jaminan bahwa semua kelebihan sistem akan dicoba.
d. biarkan end user masuk ke sistem pada hari pertama yang penerapannya tidak selalu bermanfaat.

2. PENERIMAAN YANG LENGKAP SEDIKIT DEMI SEDIKIT (A THOROUGH BUT PIECEMEAL ACCEPTANCE)
Manfaat dari pendekatan ini adalah :
Dapat mendemonstrasikan semua fungsi yang dijanjikan.
Semua tindakan yang menyebabkan masalah selalu diketahui dengan tepat siapa yang mengetik ketika masalah terjadi.
User tidak merasa takut tentang semuanya.
3. MEMASTIKAN BAHWA SEMUA YANG DIJANJIKAN AKAN DIUJI (ENSURING THAT ALL THE PROMISES ARE TESTED)
Untuk memastikan semua yang dijanjikan akan di tes langsung melalui spesifikasi fungsi halaman demi halaman, paragraf demi paragraf dan buat daftar semua fungsi yang dapat di tes.

4. MENGGUNAKAN DESIGN (USING THE DESIGN)
Design membantu untuk mengelompokkan tes ke dalam serangkaian tes yang mendemonstrasikan fungsi utama.

5. MENULIS PERCOBAAN (WRITING TEST)
Hal ini dilakukan pada saat anda sudah siap menetukan bagaimana anda akan menguji item ketika pengisian pada metode percobaan.

6. DAFTAR RENCANA TES PENERIMAAN (THE ACCEPTANCE TEST PLAN CHECKLIST)
Definisikan percobaan dan kumpulkan percobaan.
Tetapkan tanggung jawab untuk menulis percobaan.
Klien dan tim proyek mengetahui bahwa ATP akan ditinjau kembali, direvisi jika perludan ditandatangani user.
Hasilkan fungsi vs rabel percobaan.
Tanggung jawab untuk percobaan data telah dtetapkan.

7. KESIMPULAN UNTUK RENCANA TES PENERIMAAN (CONCLUSION TO THE ACCEPTANCE TEST PLAN)
Anda dapat melakukan tes penerimaan secara berlebihan. Anjurkan user untuk menulis ATP jika dia mampu. Hal ini akan memberikan dia perasaan mengawasi tim proyek harus membangun sistem melalui percobaan.

8. KESIMPULAN UNTUK TAHAP DESIGN (CONCLUSION TO THE DESIGN PHASE)
Dokumen spesifikasi design memuat design akhir tingkat atas melalui design tingkat menengah.
Tanggung jawab ATP disahkan dan dimulai.
Rencana proyek.

PRETEST SUSUNAN STAF

Secara spesifik, membangun sebuah tim artinya harus mengembangkan semangat, saling percaya, kedekatan, komunikasi, dan produktivitas.
•Semangat : Muncul karena masing-masing anggota percaya bahwa mereka memiliki kemampuan untuk menyelesaikan tugas. Makin tinggi tingkat kepercayaan mereka atas kemampuannya, makin besar pula motivasi mereka untuk menyelesaikan tugas dengan baik
•Saling percaya : Rasa saling percaya antar sesama anggota merupakan syarat mutlak yang harus dimiliki oleh setiap anggota tim, agar tim mampu bekerja secara efektif.
•Kedekatan : Kedekatan antar anggota merupakan perasaan yang mampu menyatukan anggota secara sukarela. Suatu kelompok yang kohesif adalah kelompok yang dimiliki oleh setiap anggotanya. Mereka mempunyai tingkat loyalitas yang tinggi terhadap kelompoknya. Umumnya kelompok yang kohesif akan lebih produktif.
•Komunikasi : Agar tim bisa berfungsi dengan baik, semua anggota harus mempunyai kemampuan untuk mengembangkan hubungan antar pribadi secara baik, bicara secara terbuka satu sama lain, memecahkan konflik yang ada, dan secara bersama menghadapi masalah.
•Produktivitas : Tim seyogianya dapat menyelesaikan tugas yang tidak mungkin dilaksanakan perorangan. Melalui saling berbagi sumber daya, ketrampilan, pengetahuan, kepemimpinan, maka tim berpotensi sangat lebih efektif daripada perorangan.

POST TEST SUSUNAN STAFF

Tugas tim proyek

- Manajer Proyek (Project Manager)
  PM adalah posisi pertama yang harus diisi. Pekerjaan ini diisi ketika
proyek masih sekilas di mata orang, karena PM yang pertama
menentukan apakah sebuah proyek dapat dikerjakan atau tidak.

- Pimpinan Proyek (Project Leader)
  Pimpinan Proyek adalah posisi kedua yang harus diisi. Sangatlah baik
jika PM memilih orang ini. Pertama, PM harus bernegosiasi dengan
Manajer Fungsional untuk tugas-tugas PL, kemudian yakinkan PL
untuk bergabung dalam tim. PL terdaftar pada proposal karena
banyak detail proposal dikerjakan oleh PL. Pekerjaan ini sangat
bersifat teknis, karenanya pilihlah ahli yang terbaik.

- Programmer
  PM dan PL akan mulai berpikir tantang siapa yang dapat membentuk
tim pemrograman dan bertanya pada Manajemen Fungsional (jika
diperlukan) tentang kemampuan orang-orang ini (Programmer).
Kemudian, ketika kontrak ditandatangani, mulailah mengumpulkan
tim programmer Anda.
Pertama pilihlah Programmer dengan kemampuan pemrogramannya.
Sebagai tambahan carilah keterangan tentang pengalaman mereka,
tetapi bukan seseorang yang sudah melakukan hal yang sama
selama 5 kali berturut-turut – orang ini akan bosan.

Pretest Estimasi- Pengelolaan Proyek Sistem Informasi

Pretest Estimasi

Apa yang dimaksud dengan “Estimasi” ? Carilah satu contoh yang berhubungan dengan estimasi, tuliskan pada blog Anda yang terkoneksi dengan Studentsite.

Jawaban :

Pengertian Estimasi

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. Tetapi berdasarkan statistik dari DEC, NASA, TRW, dan lembaga yang lainnya, menunjukkan bahwa keakuratan estimasi yang dilakukan memiliki point sebesar 50% - 100%. Setelah fase analisis direncanakan ulang. Anda harus memeriksa estimasi dan merubah rencana pendahuluan proyek menjadi rencana akhir proyek. Pada tahap ini keakuratan estimasi Anda menjadi berkurang, yaitu sekitar 25% - 50%. Setelah dikerjakan sampai tingkat menengah, Anda periksa kembali estimasi tersebut. Dengan menggunakan pengetahuan yang didapat seiring dengan waktu, keakuratan estimasi tersebut hanya mencapai 10%. Meskipun tidak bisa dikatakan sebagai aktivitas eksplisit dalam fase yang lain, rencana untuk memperbaiki estimasi setiap waktu, memerlukan pengetahuan yang baru.

Contoh Sistem Estimasi Biaya Dan Usaha Proyek Pengembangan Software Sistem Informasi Bisnis

Estimasi ukuran software merupakan suatu akrifitas yang komplek dan sukar berdasarkan pada beberapa alasan seperti kemampuan programmer, faktor lingkungan dan sebagainya. Tetapi karena tindakan ini harus dilakukan dan untuk mendapatkannya dengan menggunakan ukuran seperti jumlah baris program (Source lines of code/SLOC) dan function Points.

Pembuatan Model Estimasi

Untuk pembuatan model estimasi biaya dan usaha proyek pengembangan software pertama-tama dilakukan analisa parameter yang berpengaruh terhadap kedua vaiabel tersebut. Untuk menguji keterkaitan atau pengaruh dari variabel, digunakan perhitungan nilai kolerasi dari setiap variabel yang di analisa. Adapun tabel kolerasi dari semua variabel hasil observasi adalah

Tabel Nilai Kolerasi Antar Variable Model Estimasi

Dari tabel di atas terlihat bahwa nilai kolerasi antara effort dan function point bernilai 0,12, sedangkan kolerasi antara effort dengan total faktor kompleksitas bernilai 0,22. Dari nilai kolerasi ini dapat disimpulkan bahwa nilai usaha (effort) proyek pengembangan software dipengaruhi oleh nilai besaran function point dan tingkat kompleksitas proyek software. Artinya semakin tinggi nilai function point dan tingkat kompleksitas proyek software akan membutuhkan effort yang semakin tinggi pula. Hal yang sama juga dapat dilihat tingkat keterkaitan antara variabel biaya dengan function point yang mempunyai nilai korelasi sebesar 0,38. artinya besaran function point dari suatu proyek pengembangan software akan sangat berpengaruh terhadap besaran biaya yang digunakan. Adapun hasil pemodelan data biaya (cost) yang dikaitan dengan function point (FP) adalah seperti gambar berikut:

Grafik Model Biaya (Cost) dengan Function Points

Dari gambar di atas terlihat bahwa hubungan antar biaya (cost) dapat dimodelkan dengan grafik eksponensial. Artinya nilai peningkatan biaya yang dibutuhkan proyek pengembangan software bertambah secara eksponensial terhadap penambahan besaran function point dari proyek software yang akan dikembangkan. Adapun model eksponential yang diperoleh dari analisa data hasil observasi adalah :

Biaya (cost) = 8,0757*exp(0,0087*FP)

Dimana FP adalah function point dari proyek software yang akan dikembangkan.

Grafik Model Usaha (Effort) dengan FP secara linier

Secara linier regresi dapat direpresentasikan keterhubungan tersebut sebagai rumus :

Biaya (cost) = 3,7076 + 0,4138*FP

Sedangkan keterhubungan antara usaha (effort) dengan function point dapat diperlihatkan dengan beberapa model berikut:

Grafik Model Usaha (Effort) dengan FP secara Logaritmik

SUMBER :

http://iwayan.info/Lecture/PengelProySI_S1/BukuAjar/PPSI_BAB13.pdf

http://km.ristek.go.id/assets/files/NEW/Prosiding/PDF%20final-2006/Suharjito.pdf

Posttest Estimasi- Pengelolaan Proyek Sistem Informasi

Posttest Estimasi

Sebutkan teknik-teknik estimasi pada Proyek Sistem Informasi. Tuliskan pada blog Anda yang terkoneksi pada Studentsite.

Jawaban :

Teknik-teknik estimasi yang digunakan ada 3 (tiga), yaitu : keputusan professional, sejarah, dan rumus-rumus.

 

·         Keputusan Profesional

Katakanlah, Anda adalah seorang yang memiliki pengalaman yang luas dalam memprogram “report generation modules”. Anda melakukan dengan pendekatan design report tersebut dan memperkirakan berapa lama waktu yang dibutuhkan untuk membuat program tersebut. Setelah mempelajari desain program selama 5 menit, programmer lalu menutup matanya selama 5 menit (Dia tidak tidur, tetapi berhitung), dan kemudian mengatakan “15 hari”. Inilah yang disebut dengan Keputusan Profesional Murni.

            Keuntungan dari teknik ini adalah cepat, dan jika sesorang sudah ahli, dalam teknik ini, maka estimasinya pasti akan lebih akurat. Sedangkan kerugian dari teknik ini yaitu Anda membutuhkan seorang ahli tersebut akan bekerja keras untuk mendapatkan estimasi yang tepat. Lagi pula, estimasi yang didapat adalah untuk jangka waktu yang lama dan ini harus dikerjakan oleh seorang ahli. Hal ini tidak dapat tergantung hanya pada ahli tersebut, jika yang lain ingin mengerjakannya tidak menjadi masalah. Tapi, hal ini sangat berbahaya jika hanya mempercayakan kepada seseorang yang memiliki sedikit pengetahuan dalam bidang ini.

 

·         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 tugas yang akan di estimasi 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. Untuk memprogramnya, mungkin generasi dalam bentuk formulir input, sebuah laporan, perhitungan rumus-rumus, dan lain-lain. Perusahaan atau departemen akan membuat tipe proyek yang sama. Carilah dasar untuk membangun “blocks” dan dokumen yang dibutuhkannya. Jika Anda sangat intelligent, lakukan langkah pertama dan bangunlah blocks tersebut dalam bentuk yang siap pakai. Anda dapat menduga bahwa sebuah penggunaan ulang ternyata lebih akurat jika dibandingkan dengan penulisan ulang. Dalam membandingkan satu apel dengan apel yang lainnya, Anda harus menuliskan perbedaannya. Catatan statistik dari IBM dan DEC memperlihatkan bahwa kemungkinan perbandingan antara produksi komputer yang baik dengan yang buruk adalah sebesar 8 : 1.

 

·         Rumus-rumus

Ada beberapa rumus yang digunakan dalam software estimasi. Sotfware yang baik untuk diketahui yaitu COCOMO. COCOMO dapat digunakan untuk memperkirakan biaya proyek, usaha (person months),  jadwal (months), dan staf (number of staff) untuk masing-masing fase berikut ini : Preliminary Design - our Analysis Phase Detailed Desaign (DD) - our Design Phase Code and Unit test (CUT) - same as ours System Test - our System Test and Acceptance Phase. Ada 3 tipe penginputan dengan COCOMO : pertama, pemasukan biaya bulanan dari staf. Baik staf yang berkedudukan sebagai programmer, analis, designer, test staff, administrasi dan technical writer. Gambar dibawah ini menunjukkan sebuah layar penginputan yang digunakan untuk tipe ke dua dari penginputan. Faktor-faktor ini mencirikan level keseluruhan dari kelengkapan software yang ada, ukuran dan kemampuan dari komputer yang digunakan untuk pengembangan, kemampuan menampung dan pengalaman staf, dan juga pemrograman praktis serta alat-alat yang digunakan.

Tampilan dengan menggunakan software COCOMO

Pada hal ini, Anda mungkin akan merasa bahwa COCOMO akan melakukan pendugaan yang baik, sejak software ini selalu tepat menentukan proyek yang lama. Tetapi, kesulitannya yaitu setiap akhir dari penggunaan software ini COCOMO selalu menanyakan nomor garis yang terdapat pada kode sumber (LOSC). Pada saat itu, Anda telah memiliki pengetahuan yang cukup mengenai sistem untuk memperkirakan LOSC dengan teliti, Anda tidak memerlukan beberapa rumus. Namun, Anda hanya memperkirakan keseluruhan proyek dengan teliti.

SUMBER :

 http://iwayan.info/Lecture/PengelProySI_S1/BukuAjar/PPSI_BAB13.pdf