Posttest - Pengelolaan Proyek Sistem Informasi

Pimpinan Proyek (Project Leader)

Mengawasi programmer.

Bertanggung jawab terhadap kegiatan-kegiatan yang bersifat teknis, seperti analisis, disain dan tugas-tugas pemrograman keseluruhan.

Tujuan utama : kualitas produk yang dihasilkan secara teknik.

Manajer Proyek (Project Manager)

Manajer dalam tim (pimpinan, motivator, dll).

Bertanggung jawab terhadap semua komunikasi yang datangnya dari luar (laporan, pertemuan-pertemuan, penghubung antara manajemen tingkat atas dengan user).

Tujuan utama : keberhasilan proyek (perencanaan, pengontrolan, komunikasi)

Pretest - Pengelolaan Proyek Sistem Informasi

Keuntungan membangun sistem menggunakan metode prototipe dan langkah-langkah dalam pembuatan Sistem Informasi menggunakan metode tersebut.

Keuntungan dari prototipe

·        Menghasilkan syarat yang lebih baik dari produksi yang dihasilkan oleh metode ‘spesifikasi tulisan’.

·        User dapat mempertimbangkan sedikit perubahan selama masih bentuk prototipe.

·        Memberikan hasil yang lebih akurat dari pada perkiraan sebelumnya, karena fungsi yang diinginkan dan kerumitannya sudah dapat diketahui dengan baik.

·        User merasa puas. Pertama, user dapat mengenal melalui komputer. Dengan melakukan prototipe (dengan analisis yang sudah ada), user belajar mengenai komputer dan aplikasi yang akan dibuatkan untuknya. Kedua, user terlibat langsung dari awal dan memotivasi semangat untuk mendukung analisis selama proyek berlangsung.

15.3. METODE PROTOTIPE (THE PROTOTYPING METHOD)

Langkah-langkah pembuatan prototipe :

Langkah Pertama    

Permintaan bermula dari kebutuhan user.

Langkah Kedua       

Bangunlah sistem prototipe untuk menemukan kebutuhan awal yang diminta.

Langkah Ketiga       

Biarkan user menggunakan prototipe. Analis harus memberikan pelatihan, membantu dan duduk bersama-sama dengan user, khususnya untuk pertama kali. Anjurkan perubahan. User harus melihat fungsi-fungsi dan sifat dari prototipe, lihat bagaimana ia memecahkan masalah bisnis dan mengusulkan perbaikan.

Langkah Keempat   

Implementasikan saran-saran perubahan.

Langkah Kelima      

Ulangi langkah ketiga sampai user merasa puas.

Langkah Keenam    

Merancang dan membangun suatu sistem akhir seperti sebelumnya.

Pre Test Estimasi

Apa yang dimaksud dengan ‘estimasi’?

Estimasi merupakan sebuah proses pengulangan. Pemanggilan ulang estimasi yang

pertama dilakukan selama fase definisi, yaitu ketika Anda menulis rencana proyek awal. Hal ini

perlu dilakukan, karena Anda membutuhkan sebuah 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 dari rencana proyek awal menjadi rencana

proyek akhir. Pada tahap ini keakuratan estimasi Anda menjadi berkurang, yaitu sekitar 25%-

50%. Setelah dikerjakan sampai pada 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 dari ‘estimasi’:

Estimasi Harga Dua Proporsi (P₁-P₂)

Jika P1 dan P2 tidak terlalu kecil dan tidak selalu besar, maka harga distribusi sampling harga statistik akan didistribusikan mendekati distribusi normal dengan harga mean = ( p1 – p2) dan standard deviasi adalah :

 

Interval Konfidensi untuk Dua Proporsi   ( P1 – P2) adalah sbb :

 

Dimana : jika tidak diketahui a1 atau a2 dapat diganti

             dengan P1 atau P2

Post Test 'Estimasi'

Sebutkan teknik-teknik estimasi pada Proyek Sistem Informasi.
Teknik-teknik Estimasi

Ada 3 (tiga) teknik yang digunakan untuk melakukan estimasi, yaitu : keputusan

profesional, sejarah dan rumus-rumus.

Ø Keputusan Profesional

Katakanlah, bahwa Anda merupakan orang yang memiliki pengalaman yang luas dalam

memprogram “report generation modules”. Anda melakukannya dengan pendekatan design report

tersebut dan memperkirakan berapa lama waktu yang dibutuhkan untuk membuat program

tersebut. Setelah mempelajari desaign program selama 5 menit, programer 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 seseorang sudah ahli dalam teknik ini, maka

estimasinya pasti akan lebih akurat. Sedangkan kerugian dari teknik ini yaitu bahwa Anda

membutuhkan seorang ahli yang berpengalaman dalam bidang ini dan biasanya beberapa 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 mempercayakannya kepada seseorang yang

memiliki sedikit pengetahuan dalam bidang ini.

Ø Sejarah

Jalan keluar dari ketergantungan pada orang dan untuk membuat estimasi lebih khusus yaitu

Anda harrus 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 (referensi 15). COCOMO dapat digunakan untuk memperkirakan

biaya proyek, usaha (person months), jadwal (months) dan staf (number of staff) untuk masingmasing

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

Tugas Softskill 3 - Profesi IT

Software architect

Software architect atau kadang disebut juga sebagai Technical Architect biasanya bekerja di perusahaan software development yang memiliki produk-produk software yang cukup besar dan kompleks. software architect bertugas untuk mendesain dan merekomendasikan secara technical mengenai bagaimana dan apa yang diperlukan dalam mengembangkan produk software tersebut. Profesional di bidang ini biasanya pernah meniti karir sebagai programmer, software engineer atau system analyst.

Bila system analyst harus memiliki pengetahuan yang berimbang antara proses bisnis (problem domain) dan software technology (solution domain), seorang architect dituntut untuk menguasai software technology secara lebih mendalam. Kemampuannya dalam hal technical sangat diperlukan dalam proyek-proyek software development berskala besar dan kompleks, dimana keputusan dalam pemilihan teknologi yang paling tepat dan penguasaanya sangat menentukan kesuksesan proyek. Keahlian utama seorang software architect adalah dalam bidang software design dan software development technology.

Software Architect:
Tugas:

1.     Merekomendasikan teknologi yang paling cocok untuk mengembangkan produk software

2.     Membuat standar-standar software development yang akan digunakan oleh tim programmer / developer seperti coding standard, arsitektur, design pattern dll.

3.     Membuat rancangan/desain software dan proses pengembangannya secara keseluruhan, terutama dalam hal framework dan library yang digunakan

Keahlian yang Diperlukan:

1.     Menguasai hal-hal teknis yang dikuasai programmer, system analyst dan software engineer

2.     Menguasai secara mendalam tentang software development technology dan software design

3.     Menguasai penulisan dokumen dengan baik (dalam bahasa Inggris dan Indonesia)


Sumber :
http://en.wikipedia.org/wiki/Software_architect
http://www.sei.cmu.edu/architecture/research/previousresearch/duties.cfm

Posttest - Pengelolaan Proyek Sistem Informasi

Rencana penerimaan adalah prosedur yang digunakan dalam mengambil keputusan terhadap produk-produk yang datang atau yang sudah dihasilkan  perusahaan.

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

Tahapan – tahapan yang perlu dicek dalam Rencana Penerimaan:

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.

SOLUSI : PENERIMAAN YANG LENGKAP SEDIKIT DEMI SEDIKIT (SOLUTION : A THOROUGH BUT PIECEMEAL ACCEPTANCE)

Pendekatan yang lebih baik adalah menemukan serangkaian tes yang mendemonstrasikan semua fungsi yang dijanjikan. Penerimaan akan dilakukan secara resmi melalui seluruh tes ini kepada pelanggan. Keberhasilan tes diakhiri satu per satu.

MEMASTIKAN BAHWA SEMUA YANG DIJANJIKAN AKAN DIUJI (ENSURING THAT ALL THE PROMISES ARE TESTED)

Untuk memastikan semua yang dijanjikan akan dites langsung melalui Spesifikasi Fungsi halaman demi halaman, paragraf demi paragraf, dan buat daftar semua fungsi yang dapat dites.

MENGGUNAKAN DISAIN (USING THE DESIGN)

Anda mungkin berfikir mengapa saya menyarankan mengerjakan ATP setelah disain dikerjakan. Sesungguhnya anda hanya memerlukan Spesifikasi Fungsi untuk menghasilkan ATP. Tetapi, disain membantu untuk menggelompokkan tes ke dalam serangkaian tes yang mendemonstrasikan fungsi utama dari sistem.

MENULIS PERCOBAAN (WRITING TEST)

Anda sudah siap menentukan bagaimana anda akan menguji item ketika pengisian pada METODE PERCOBAAN

DAFTAR RENCANA TES PENERIMAAN (THE ACCEPTANCE TEST PLAN CHECKLIST)

1.      Definisikan percobaan dan kumpulkan percobaan.

2.      Tetapkan tanggung jawab untuk menulis percobaan.

3.      Klien dan tim proyek mengetahui bahwa ATP akan ditinjau kembali, direvisi jika perludan ditandatangani user.

4.      Hasilkan fungsi vs rabel percobaan.

5.      Tanggung jawab untuk percobaan data telah dtetapkan.

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.

KESIMPULAN UNTUK TAHAP DESIGN (CONCLUSION TO THE DESIGN PHASE)

1.      Dokumen spesifikasi design memuat design akhir tingkat atas melalui design tingkat menengah.

2.      Tanggung jawab ATP disahkan dan dimulai.

3.      Rencana proyek.

Pretest - Pengelolaan Proyek Sistem Informasi

Pertanyaan : Menurut Anda seberapa penting dilakukan tes penerimaan terhadap sistem yang dibuat? 

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

Mendapatkan persetujuan ini dan pembayaran jika itu adalah proyek yang dikontrak mungkin akan sulit, kecuali user yakin bahwa sistem bekerja dengan baik sesuai dengan yang dijanjikan. User mungkin merasa takut pada penerimaan : dia mengambil ahli kepemilikan dan tanggung jawab sistem. User mungkin enggan menyerahkan tanda penerimaannya – apa yang terjadi jika sesuatu salah ?

Jadi, melakukan tes penerimaan terhadap sistem yang dibuat sangat penting karena dengan melakukan hal tersebut kita bisa mengetahui apakah user puas dengan proyek yang kita buat, apakah sistem yang dibuat dapat berjalan sesuai dengan yang kita janjikan dan dengan melakukan hal tersebut kita bisa mendapatkan tanda penerimaan dari user.