MANAJEMEN PROYEK SISTEM INFORMASI Politeknik Piksi Ganesha By HendraNet By HendraNet

http://www.hendra-jatnika.web.id

MANAJEMEN PROYEK SISTEM INFORMASI Politeknik Piksi Ganesha

t e N

a r d

By

By HendraNet

n e H


Pengelolaan Proyek Sistem Informasi

BAB 1 TERMINOLOGI ° Project Management : Aplikasi pengetahuan, keahlian, alat bantu dan teknik untuk mengelola aktivitas proyek dalam menghadapi kebutuhan dasar stakeholders - client dan memprediksi berbagai hal yang berkaitan dengan proyek. ° Project

Manager

:

Individu

yang

menjaga

jalannya

manajemen proyek dan semua sumber dayanya (biaya, staff, waktu, kualitas)

a r d jika dikerjakan secara kumpulan aktifitas nyang Heakan dapat mencapai sukses secara berkesinambungan By keseluruhan.

° Project : °

t e N

° Sesuatu hal yang biasa diminta oleh client ° Dibuat untuk memperbaiki suatu masalah dan atau sesuatu yang baru yang berbeda ° Harus unik dari proyek-proyek yang lain.

Yang menentukan keberhasilan atau kegagalan Proyek, meliputi dua hal : 1. Keterbatasan lingkup proyek 2. Fase proyek

BAB 1

1



1. Keterbatasan Lingkup Proyek (Project Contraint) : Sesuatu yang secara potensial membatasi proses-proses dalam proyek, yang meliputi 3 hal : ¾ Time : waktu yang dibutuhkan dalam menyelesaikan proyek. Ada beberapa even yang ‘memaksa’ dalam Timeline proyek, yaitu opportunity (kesempatan), limitations (Keterbatasan), competition (kompetensi). ¾ Cost : Semua biaya yang dibutuhkan dalam proyek. Semua sumber daya yang dibutuhkan untuk menyelesaikan proyek tergantung pada biaya, pentingnya manajer proyek disini adalah melakukan estimasi. Setelah itu adalah memonitor semua limitasi ini, supaya proyek ’aman’

t e N

¾ Quality

: Semua hal yang dikerjakan dalam proyek harus

a r d

menghasilkan sistem pada waktu dan dalam budget yang

n e H

ditentukan namun tetap dalam kualitas terbaik yang dapat

By

dicapai.

2. Fase Proyek (Project Phase) : 1. Persiapan

(Initiating)

–

mengenali

kebutuhan

yang

berhubungan dengan proyek untuk menangani masalahmasalah. 2. Perencanaan (Planning) – ketika mendefinisikan rencana yang akan

digunakan

untuk

menyelesaikan

tujuan

akhir

(requirements gathering).

BAB 1

2



3. Pelaksanaan

(Executing)

–

Mengkoordinasi

staff

dan

sumberdaya penting lainnya, seperti yang sudah ditetapkan dalam perencanaan. 4. Pengawasan

(Controlling)

–

Monitoring

secara

konstan

terhadap overall progress dalam proyek dan menjaga integritas tujuannya. 5. Sosialiasasi (Close Out) – Formalisasi penerimaan kesuksesan suatu proyek dari stakeholders (client).

Keberhasilan Suatu proyek

Dokumentasi =

fase proyek yang baik

t e N

a r d

Dokumentasi ° Dokumen Konsep

By

n e proyek H (Project

Concept Document) –

ikhtisar dari apa yang diucapkan client pada meeting pendahuluan (preliminary meetings) ° Dokumen Kebutuhan Proyek (Project Requirement Document) – hasil dari analisa kebutuhan. ° Dokumen Persetujuan / Validasi (Project Charter) – dokumen yang berisi pengesahan manajemen dari client (acknowledges), bahwa proyek diizinkan untuk mengalokasikan sumberdaya. ° Dokumen lingkup proyek (Project Scope Document ) – kandungan proyek (yang berhubungan dengan proyek seperti : project members, project sponsor, dsb).

BAB 1

3



° Dokumen Perencanaan Proyek (Project Plan) – detil yang menunjukkan strategi untuk dapat menyelesaikan proyek. Outline-nya bisa berupa tahapan-tahapan fase dan langkah demi langkah kerja. ° Dokumen sosialisasi (Closing Document) – metode sosialisasi, training, serah terima dengan stakeholders dan komitmen akhir seperti garansi dsb.

TUJUH FASE PROYEK SOFTWARE Ada 7 fase dari proyek software, yaitu : 1. DEFINITION

t e N

2. ANALYSIS

a r d

3. DESIGN 4. PROGRAMMING

y B 6. ACCEPTANCE 5. SYSTEM TEST

n e H

7. OPERATION

Proyek software sama dengan membangun sebuah rumah

DEFINITION

DEFINISIKAN RUMAH YANG AKAN DIBANGUN

ANALYISIS

SPESIFIKASI RUMAH

DESIGN

ARSITEK

PROGRAMMING

KONSTRUKSI RUMAH

SYSTEM TEST

BASEMENT, LANTAI 1, 2, ….

ACCEPTANCE

RUMAH SUDAH SELESAI

OPERATION

BAB 1

RUMAH SUDAH DAPAT DITEMPATI 4



BAB 2 FASE DEFINISI Memahami Masalah User 2.1. PENDAHULUAN Tujuan dari fase definisi adalah untuk memahami dengan baik masalah-masalah yang dihadapi oleh user dalam memperkirakan biaya dan waktu penyelesaian proyek. Ada 3 aktifitas utama yang harus dilakukan dalam Fase Definisi : Pertama Anda harus memahami dengan baik masalah-masalah yang dihadapi oleh user dan apa saja yang dibutuhkan untuk menyelesaikan masalah tersebut (KEBUTUHAN). Kedua Anda harus memutuskan proyek akan dilaksanakan atau tidak.

t e N

a r d

Jika keputusannnya adalah melaksanakan proyek tersebut, Anda harus dapat menganalisis semua risiko-risiko yang mungkin terjadi yang dapat menggagalkan proyek tersebut. Analisis ini sangat membantu dalam penulisan PROPOSAL yang berisi rincian menganai proyek apa yang akan ditawarkan, kapan, dan berapa biayanya (termasuk biaya untuk risiko-risiko yang mungkin terjadi).

By

n e H

Tulislah beberapa dokumen dan temukan beberapa kejadian penting pada akhir fase ini. Pertama, menulis Requirement Document (RD), yaitu dokumen yang berisi rincian kebutuhan user. Dokumen RD harus jelas dan lengkap, sehingga Tim Proyek (Project Tem (PT)) dapat memahami seluruh masalah-masalah yang dihadapi oleh user dan dapat memperkirakan biaya penyelesaian proyek tersebut.. Kejadian penting pertama yang akan Anda hadapi berupa persetujuan atau penandatanganan dokumen RD oleh User dan Tim Proyek.

BAB 2

Halaman 1 dari 8



Selanjutnya, menulis Pendahuluan Perencanaan Proyek (Preliminary Project Plan (PPP)). PPP merupakan langkah pertama dalam merencanakan langkah-langkah berikutnya yang harus diambil untuk mengembangkan produk dan sumber-sumber apa saja yang dibutuhkan untuk setiap langkahnya. Rencana tersebut menggambarkan berapa lama sumber-sumber tersebut akan diperlukan dan berapa banyak biaya yang akan dikeluarkan. Ketiga Anda harus memberikan perkiraan-perkiraan ini kepada user dalam bentuk PROPOSAL. Seberapa jauh perkiraan-perkiraan tersebut dapat dipertanggung jawabkan ? Ada dua alasan dalam hal ini. Pertama, kita tidak begitu ahli dalam memperkirakan sesuatu. Kedua, perkiraanperkiraan tersebut dibuat pada saat masih dalam tahap pendefinisian masalah, dimana pada saat itu baru sebagian kecil informasi yang kita peroleh dari masalah yang sedemikian luas.

t e Jika anda tidak yakin dengan kebutuhan-kebutuhan yang telah N a digambarkan secara akurat dalam dokumen RD, disarankan untuk r d membagi proyek tersebut menjadi 2 tahap : Fase Analisis sebagai n e proyek pertama diikuti dengan fase sebelumnya sebagai proyek H kedua. By

Pada saat pendefinisian, proposal anda hanya akan menjadi analisis saja, dan ini disebut PROPOSAL ANALISIS. Setelah analisis akan ada PROPOSAL PENGEMBANGAN (Lihat bab 3). Kedua hal ini disebut dengan dua fase proposal. Kejadian penting yang terdapat disini adalah pembelian proposal oleh user.

2.2. DOKUMEN KEBUTUHAN (REQUIREMENT DOCUMENT / RD) RD menyatakan masalah-masalah yang dihadapi user dan solusi umum yang dibutuhkan. Bahasanya berorientasi pada bahasa yang digunakan oleh user sehari-hari, dan jauh dari bahasa komputer. Kadangkala dokumen RD digunakan sebagai permohonan untuk sebuah proposal (Request for a proposal (RFP)) ketika user menawarkan proyeknya kepada kontraktor luar. BAB 2

Halaman 2 dari 8



Tanya jawab dengan User Proses tanya jawab dilakukan untuk mendapatkan informasi yang tepat dari user untuk memperoleh RD yang baik. User akan memberikan semua informasi yang anda butuhkan dan tidak lebih. Tim proyek interviewer berkewajiban untuk mempelajari semua bisnis user, memahami teknologi user, dan mengajukan pertanyaanpertanyaan. Masalah terbesar berkaitan dengan pemakai akhir (end-user) yang sesungguhnya petugas pemasukan data atau petugas pengirim barang yang berada di gudang. Seringkali manajer atau supervisor mengatakan bahwa pemakai akhir sangat sibuk dan tidak mampu untuk memberikan informasi yang dapat dipercaya. Terkadang manajer merasa dilangkahi atau diremehkan jika anda berhubungan langsung dengan pemakai akhir yang berada di departemen mereka. Solusi dari masalah ini adalah mendidik para wakil tim proyek tersebut bagaimana pentingnya komunikasi dengan para pemakai akhir yang sebenarnya. Jika masukkan yang mereka kemukakan tidak mendapat tanggapan pada awal pendefinisian, akan sangat mungkin terjadi perubahan-perubahan di kemudian hari dan hal ini berarti akan membutuhkan biaya yang cukup mahal untuk memperbaikinya. Mintalah izin dari manajer yang berwenang pada saat akan mewawancarai orang-orang mereka.

t e N

a r d

By

n e H

Siapkan rencana untuk melakukan wawancara. Pelajari tentang bisnis yang mereka lakukan, dan tulislah pertanyaan-pertanyaan yang akan diajukan. Berikut ini pertanyaan yang berhubungan dengan wawancara yang akan dilakukan : Pertama, cari tahu tentang aliran informasi yang ada dalam perusahaan tersebut. Mulailah dengan pertanyaan-pertanyaan seperti : informasi apa saja yang dibutuhkan untuk menjalankan kegiatan bisnis perusahaan ? Seberapa penting aliran data, baik antara departemen maupun antar individual ? Tentukan frekuensi, waktu dan keakuratannya.

BAB 2

Halaman 3 dari 8



Kedua, masukkan-masukkan yang diterima diikuti dengan pertanyaan-pertanyaan sebagai berikut : Informasi apa saja yang dibutuhkan untuk menghasilkan masing-masing barang? Informasi apa yang tersedia, kapan, dimana ? Informasi-informasi baru apa saja yang harus dikumpulkan ? Ingat tentang 5 W (Who, What, Where, When, Why). Sediakan waktu untuk pertanyaanpertanyaan di atas selama membuat.

Hal-hal yang terdapat dalam RD Berikut ini adalah bagian-bagian dari RD : 1. Pendahuluan. Identifikasi perusahaan (user) dan juga penjual dimana RD tersebut ditujukan. Tentukan masalah yang perlu diselesaikan, latar belakang, contoh situasi yang sedang dihadapi, motivasi-motivasi untuk menanggulanginya, dll. Bagian ini digunakan untuk memperkenalkan potensi penjual kepada perusahaan user atau departemen jika diperlukan, jelaskan kultur, lingkungungan, dan bagaimana jalannya bisnis yang dilakukan. Berikan pengertian kepada Tim Proyek tentang masalah yang dihadapi user.

t e N

a r d

n e 2. Tujuan Proyek. Sebuah pernyataan singkat mengapa kita H mengajukan proposal untuk pengembangan proyek. Batasany B batasan utama dalam penggunaan waktu dan keuangan dapat juga disebutkan. 3. Fungsi-fungsi Utama. Pernyataan singkat mengenai bagaimana sistem berfungsi berdasarkan tujuan proyek yang telah ditetapkan. 4. Keluaran Umum. Penjelasan secara singkat tentang informasi yang dibutuhkan dari sistem. 5. Informasi Input secara Umum. Input data apa yang diperlukan untuk menghasilkan output. Ini adalah waktu yang tepat untuk memastikan bahwa seluruh data yang dibutuhkan dapat tersedia pada waktu yang tepat pula.

BAB 2

Halaman 4 dari 8



6. Kinerja (Performance). Berapa banyak transaksi yang akan diproses, berapa banyak data yang akan disimpan, kapan laporan harus dihasilkan, dsb. Jelaskan waktu rata-rata dan waktu maksimal proses (dalam hari atau jam). 7. Perkembangan (Growth). Hal ini mungkin sulit untuk diramalkan, tetapi cobalah untuk menghitung kemajuan bisnis dan menetapkan berapa tahun lagi sistem masih dapat diharapkan untuk berfungsi. Kemukakan dalam bentuk persentase atau angka sebenarnya. 8. Pengoperasian dan Lingkungan. Dimana komputer akan ditempatkan, dimana terminal-terminal yang interaktif ditempatkan, dan siapa yang akan menggunakannya. 9. Kompatibilitas, Pengantarmukaan. Jelaskan jika fasilitas antar komputer dibutuhkan, adakah alat-alat yang harus disatukan, atau jika pengiriman akses dibutuhkan. Jika sistem hanya dapat berjalan dengan komputer yang ada, atau harus dapat diprogram dengan bahasa yang spesifik, semua dokumen dinyatakan di dalam bagian ini.

t e N

a r d

n e 10. Reliabilitas, Ketersediaan. Tulis penggambaran waktu H diantara kegagalan-kegagalan (Meantime between Failures / y B MTBF), waktu untuk perbaikan (Meantime to Repair / MTTR) dan persentase tambahan yang diperlukan. Semua manufaktur menyatakan penggambaran ini untuk hardware mereka. 11. Pengantarmukaan dengan Pemakai. Rincikan pengalamanpengalaman yang dibutuhkan user dalam menggunakan komputer, jelaskan bagaimana menangani sistem kapada user yang baru. 12. Pengaruh Organisasi. Departemen-departemen apa yang akan sangat berpengaruh dan seberapa jauh cara kerja mereka harus berubah. Bagaimana sistem yang baru dapat berkomunikasi dengan sistem manual yang ada. 13. Pemeliharaan dan Dukungan. Jaminan-jaminan yang dibutuhkan : berapa lama, sampai kapan, bagaimana pengiriman. BAB 2

Halaman 5 dari 8



14. Dokumentasi dan Pelatihan. Rincikan semua dokumendokumen umum dan / atau pelatihan yang dibutuhkan. 15. Keuntungan (hanya RFP). Jika RD adalah RFP dalam situasi yang kompetitif, mintalah data dari penjual yang menjelaskan mengapa dokumen tersebut harus dipilih. Minta data yang relevan dari penjual yang berpengalaman, komitmen, metodologi proyek, contoh-contoh proyek yang sukses, dan referensi dimana anda dapat menghubungi penjual tersebut. 16. Persyaratan dan Kondisi. Menyatakan syarat untuk seleksi, kapan dan bagaimana akan dilakukan.

2.3. TANGGUNG JAWAB USER Meskipun user tidak menulis RD, dia bertanggung jawab untuk menyediakan pewawancara tim proyek yang dapat dipercaya, dan informasi tepat pada waktunya. User harus dapat mengajukan orang yang mengetahui tentang semua sistem yang ada dan apa saja yang dibutuhkan untuk sistem baru.

t e N

a r d

By

n e H

2.4. KEPUTUSAN MELAKSANAKAN / TIDAK MELAKSANAKAN PROYEK Setelah kebutuhan-kebutuhan ditetapkan, langkah berikutnya adalah memutuskan apakah proyek bernilai untuk dikerjakan atau tidak. Untuk membantu membuat keputusan itu, suatu studi kelayakan dilakukan untuk menjawab pertanyaan : “Dapatkah sistem ini dibangun secara teknik ? Sayangnya, tidak semuanya mungkin secara teknik, sehingga pertanyaan-pertanyaan untuk dijawab diubah menjadi, “Dengan biaya berapa sistem dapat dibangun, dan apa keuntungannya ?

BAB 2

Halaman 6 dari 8



Dalam suatu studi kelayakan kita mempertimbangkan semua penyelesaian masalah teknis yang mungkin, dan coba untuk memperkirakan biaya dari masing-masing penyelesaian masalah. Untuk suatu proyek yang berukuran besar, kita mempertimbangkan keputusan utama mengenai hardware apa yang digunakan, dan apakah akan membuat atau membeli software. Untuk proyek berukuran kecil sampai menengah studi kelayakan yang formal tidak perlu ditulis. Biasanya cukup dengan mengangkat seseorang untuk mempelajari penyelesaian masalah yang mungkin dan menilai keuntungan-keuntungan. Perkiraan keuntungan ini mungkin saja mudah, tetapi seharusnya tidak dipergunakan. Manajer proyek tidak hanya harus menjawab “Apakah proyek ini secara teknik dapat dikerjakan ?” tetapi juga menjawab pertanyaan yang lebih penting : “Apakah proyek ini dapat dikerjakan oleh saya sekarang ?” Manajer proyek harus bertanya pada diri sendiri apakah proyek yang ada memiliki peluang untuk sukses, atau proyek tersebut akan mengalami kegagalan disebabkan oleh terbatasnya sumber-sumber, pengetahuan, atau risiko di luar kekuasaannya. Tidak terkira proyekproyek telah gagal secara keseluruhan maupun sebagian, karena orang mengabaikan tanda-tanda penting dan nyata yang menunjukan kegagalan. Setiap rencana dipengaruhi oleh risiko.

t e N

a r d

By

n e H

2.5. MANAJEMEN RISIKO Menurut sejarah, industri pemrosesan data telah membuat reputasi yang buruk sekali karena meremehkan proyek-proyek yang ada. Ketika ditanya tentang alasannya, para ahli pemrosesan data membela diri dengan meberikan pernyataan seperti : “Saya menilai dengan benar berdasarkan fakta-fakta yang diberikan kepada saya. Alasan yang menumpuk adalah bahwa : (Pilih satu atau lebih : Si pemakai mengubah pikirannya ….. tidak pernah memberitahukan saya tentang… dan departemendepartemen yang lain menjanjikan ….. dan manajemen tingkat atas mendikte penilaian ….. dengan kata lain, itu bukan kesalahan saya !) BAB 2

Halaman 7 dari 8



Solusi standar industri untuk semua masalah-masalah ini adalah : SOLUSI 1. Selidiki masalah-masalah yang ada SOLUSI 2. Hukum yang tidak bersalah SOLUSI 3. Promosikan yang tidak terlibat SOLUSI 4. Kembali ke solusi 1 dan berputar sampai membosankan

2.6. EMPAT LANGKAH MANAJEMEN RISIKO Setiap proyek akan tepat waktu dan sesuai anggaran jika tidak ada yang salah. Penting sekali untuk berkosentrasi pada hal-hal yang akan menyebabkan salah dan coba untuk menghindari kesalahankesalahan tersebut. Hal ini disebut Manajemen Risiko. Manajemen risiko terdiri dari empat langkah : Langkah 1. Antisipasi risiko Langkah 2. Singkirkan risiko yang mungkin terjadi Langkah 3. Kurangi dampak risiko Langkah 4. Tetap tenang ketika terjadi kesalahan

t e N

a r d

By

BAB 2

n e H

Halaman 8 dari 8



BAB 3 PERENCANAAN PROYEK 3.1. PENDAHULUAN Sekarang anda sudah mengevaluasi proyek dan memutuskan untuk melanjutkannya. Pertama, anda harus meyakinkan rekan-rekan lain bahwa proyek sebaiknya dilaksanakan. Hal ini dilakukan dengan membuat proposal. Untuk sebuah proyek eksternal, proposal ditulis untuk meyakinkan klien agar membeli proyek dari tim proyek anda. Untuk proyek internal, manajemen sebaiknya meminta untuk membuat sebuah proposal. Hal ini untuk mendukung tim proyek untuk membuat rencana yang sederhana. Sebuah proposal adalah dokumen yang merinci biaya dan jadwal proyek, serta menjelaskan langkah-langkah yang akan diambil oleh tim proyek untuk menghasilkan produk yang diinginkan.

t e Nberulang-ulang : rencana Perencanaan adalah sebuah proses yang a rsesuai dengan perkembangan akan ditinjau secara terus menerus d nbertambahnya pengetahuan dan proyek dan sesuai dengan e pemahaman yang lebih H baik dari anggota tim. Perencanaan y memang merupakan pekerjaan yang sangat sulit, tetapi harus B dilaksanakan sebagaimana mestinya. Banyak proyek menjadi kacau dikarenakan tidak adanya perencanaan.

3.2. PENDAHULUAN PERENCANAAN PROYEK (THE PRELIMINARY PROJECT PLAN / PPP) Pendahuluan Perencanaan Proyek adalah langkah awal, sumber daya, biaya dan jadwal yang dibutuhkan untuk menyelesaikan proyek. PPP adalah dokumen internal, tidak perlu ditunjukkan ke user, terutama user luar.

BAB 3

Halaman 1 dari 15



3.3. RINCIAN STRUKTUR KERJA (WORK BREAKDOWN STRUCTURES / WBS) Kunci berbagai rencana adalah memecah kegiatan yang diperlukan ke dalam sebuah bagian yang lebih kecil lagi. Rincian struktur kerja (WBS) diawali dengan menyusun komponen-komponen utama proyek. Hal ini merupakan Level 1 dari WBS (Level 0 adalah judul proyek). Untuk proyek software, metode terbaik untuk pemecahan proyek menjadi bagian-bagian utama adalah diawali dengan 7 fase pengembangan software. Lihat Gambar 3.1. Rincian Struktur Kerja / WBS Lihat Gambar 3.2. WBS untuk analisis

Sistem Penomoran WBS

t e Ngambar 3.2 : Sistem penomoran dalam WBS seperti pada a r 0.0. - Untuk Level 0 atau judul proyek adalah d n diberi nomor N.0. - Pada Level 1 masing-masing item e Contoh : 1.0, 2.0, dst. H y item pada Level 2 dibawah item N.0 - Kemudian masing-masing B pada Level 1 diberi nomor N.1, N.2, dst. Contoh : di bawah Level 1 item Analysis yang bernomor 2.0, kita mempunyai item 2.1, 2.2, dst. - Sedangkan untuk Level 3, kita tambahkan titik dan digit dari nomor di Level 2. Sebagai contoh, dibawah 2.1 kita harus menuliskan 2.1.1, 2.1.2, dst. Kapan Anda Berhenti ?

Pemasukkan nomor pada level terendah menunjukkan tugas atau kegiatan dalam proyek. Anda dapat berhenti merinci sebuah kegiatan jika mengikuti langkah-langkah berikut dengan benar : 1. Beberapa orang (atau grup dari sebuah proyek besar) dapat diberikan tanggung jawab untuk melakukan tugas atau menyelesaikan kegiatan-kegiatan yang dilibatkan.

BAB 3

Halaman 2 dari 15



2. Anda dapat memperoleh perkiraan (berupa orang atau hari) secara garis besar sebagai upaya yang dibutuhkan untuk melaksanakan kegiatan-kegiatan yang terlibat. Hal ini dapat dilakukan dengan memberi tanggung jawab pada setiap orang. 3. Anda dapat menjadwalkan tugas. 4. Tugas-tugas tersebut harus singkat dan dapat diselesaikan. Sebagai seorang ahli kita dapat menetapkan sebuah tugas kepada Programmer, Analis, atau bahkan Manajer Proyek. Tergantung pada pengalaman dan keahlian dalam membuat perkiraan, analis mungkin hanya memerlukan level 1 dari WBS. Beberapa analis dapat dengan mudah membaca RD untuk proyek ABC (Appendix A) secara keseluruhan. Analis lain untuk merinci membutuhkan sampai Level 2. Seperti pada gambar 3.2, analis lainnya memerlukan sampai Level 3 sebelum mereka dapat memperkirakan secara keseluruhan. Sebagai contoh Level 3 WBS untuk kotak INTERVIEW dan ANALYZE EXISTING SYSTEMS dapat dilihat pada gambar 3.3.

t e Lihat Gambar 3.3. WBS N Level 3 a r d n level terendah sampai ia dapat Para ahli merinci setiap kotakepada H yang diperlukan. Perkiraan-perkiraan memperkirakan berapa upaya y WBS seperti pada gambar 3.4. Sebagai ini dapat dipakai pada B catatan bahwa perkiraan total adalah jumlah dari masing-masing waktu. Hal ini disebut DIRECT time, yaitu jumlah hari yang sesungguhnya dibutuhkan untuk melakukan kegiatan . Lihat Gambar 3.4. Analysis Level 3 Para ahli tersebut dengan cara yang sama dapat merinci kotak yang lain (DEFINE NEW SYSTEM FUNCTIONS, WRITE FUNCTIONAL SPEC. dan NEGOTIATE FUNCTIONAL SPEC.) dan menambahkan total waktu untuk semua analisis. Kemudian ahli tersebut mengajukan perkiraan dan daftar kegiatan sebelumnya yang dibutuhkan untuk seluruh analisis bagi Manajer Proyek. Orang tersebut bertanggung jawab terhadap perencanaan (mungkin Manajer Proyek untuk proyek berukuran kecil - menengah) kemudian menggabungkan seluruh perkiraan dan daftar kegiatan terdahulu. Ia mungkin mengakhirnya dengan daftar seperti berikut ini : BAB 3

Halaman 3 dari 15



ACTIFITY

EFFORT

PRECEDENTS

Definition Analysis Design Program A (Control) Program B (Registration) Program C (Warehouse) System test Documentation Acceptance

20 35 25 20 30 25 10 20 5

Training Operation

10 10

----------------Definition Analysis Design Design Design Program A, B, C Design System Test, Documentation Documentation Acceptance

TOTAL

210 person-days

t e N

3.4. DIAGRAM JARINGAN (THE NETWORK DIAGRAM)

a r d

Langkah kedua dari perencaan adalah menggambarkan diagram jaringan yang menunjukkan urutan kejadian. Tipe diagram yang paling baik untuk masalah ini adalah bagan PERT. Gambar 3.5. adalah sebuah bagan PERT untuk proyek di atas. Urutan kejadian hanya didasarkan pada contoh setiap kegiatan.

By

n e H

Lihat Gambar 3.5. Bagan PERT Bentuk dari bagan PERT ini disebut Precedence Network (jaringan yang diutamakan). Setiap kotak menunjukkan sebuah kegiatan. Pada setiap kotak ditulis nama kegiatan dan waktu yang diperlukan.

Jalur Kritis & Lamanya Proyek Bagan PERT dan jalur kritis adalah jumlah jalur, atau serangkaian kegiatan yang dapat ditelusuri pada PERT sederhana di atas, dengan mengikuti petunjuk garis panah. Lamanya waktu yang dibutuhkan untuk menelusuri setiap jalur dapat dijumlahkan dengan menambahkan lamanya waktu dari jalur masing-masing kegiatan. BAB 3

Halaman 4 dari 15



Jalur kritis (CP / Critical Path) adalah jalur terpanjang dan didefinisikan waktu minimal yang dibutuhkan untuk mengerjakan proyek. PERT pada gambar 3.5. mempunyai jalur kritis yang terdiri dari kegiatan : START, DEFINITION, ANALYSIS, DESIGN, PROGRAM B, SYSTEM TEST, ACCEPTANCE, OPERATION, dan END. Proyek tersebut membutuhkan total waktu : 135 hari.

3.5. MENGHITUNG BIAYA PROYEK (CALCULATING PROJECT COST) Jika kontrak proyek telah mempunyai harga tetap, Manajer Proyek dapat menghitung biaya kasar untuk tenaga kerja, dengan cara mengalikan jumlah tenaga kerja per-hari dengan rata-rata biaya perhari.

t e N

Biaya pekerja perhari disebut ‘biaya penuh’ : yang harus mencakup biaya operasi, sewa, administrasi pekerja, dan keuntungan. Untuk itu anda harus menambahkan biaya tetap, seperti computer time, sewa peralatan khusus, biaya tak terduga, dan sebaginya. Biaya tetap harus dirinci oleh setiap estimator untuk kegiatan utamanya.

a r d

n e H

y B Lihat Gambar 3.6. SUPERPROJECT

Rata-rata Pgr 75 pd @ $1000 per pd 75,000 Keuntungan 25% 18,750 Faktor risiko : User berubah pikiran terhadap 10% format Biaya = 10% tambahan waktu pemrograman 7,500 Total pemrograman

BAB 3

$ 101,250

Halaman 5 dari 15



3.6. PENJADWALAN PROYEK (PROJECT SCHEDULE) Langkah selanjutnya adalah menghitung jadwal proyek. Untuk melakukan hal ini, perencana (mungkin Manajer Proyek) harus mengaplikasikan jadwal yang sebenarnya dari perkiraan ke CALENDAR DAYS (jadwal harian) atau lamanya pekerjaan. Salah satu kesulitan tugas ini adalah mengalokasikan sumber daya manusia yang akan bekerja pada kegiatan yang akan dilaksanakan, terutama ketika pekerjaan berlangsung secara serentak. Kesulitan lain adalah memutuskan bagaimana mempersingkat pekerjaan yang dilakukan dengan menggunakan sumber daya yang ada. Kemudian Manajer Proyek menjadwalkan semua proyek pada kelender atau jadwal yang nyata. Metode terbaik untuk melakukan hal ini adalah dengan menggambarkan ke dalam sebuah Gantt Chart atau Bar Chart seperti pada gambar 3.7. Lihat Gambar 3.7. SUPERPROJECT project schedule

t e N

a r d

3.7. OUTLINE PENDAHULUAN PERENCANAAN PROYEK (PRELIMINARY PROJECT PLAN OUTLINE)

By

n e H

Dilengkapi dengan semua pengetahuan ini, Manajer Proyek dapat menuliskan dokumen penting ini. Berikut ini adalah outline yang disarankan untuk PPP. 1. Tim Proyek (The Project Team) Menggambarkan struktur, siapa yang memberikan laporan, siapa yang menerima laporan, kepada siapa berkomunikasi, dst. Lihat Gambar 3.8. Typical Project Team Structure Programmer (tidak lebih dari 5 orang). Bertanggung jawab terhadap pemrograman.

BAB 3

Halaman 6 dari 15



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). 2. Biaya Proyek (Projects Cost) Termasuk WBS, membuat perkiraan dan perhitungan yang digunakan untuk menaksir biaya dalam pembuatan produk.

t e 3. Penjadwal Proyek (Project Schedule) N a Merupakan bagian terpentingdr dalam proyek, dan dapat n menggunakan metode Gantt. e H y(Reviews) 4. Pemeriksaan Ulang B Pada bagian ini anda dapat menghubungkan antara pertemuan dari manajemen utama dengan peninjau teknik (jadwal proyek akan memberikan informasi ini), tujuan dari masing-masing peninjau, dan siapa yang akan mengerjakannya. Buatlah daftar tanggung jawab dari orang-orang yang terlibat. 5. Laporan (Reports) Bentuk dan isi dari laporan keadaan, laporan milestone dan dokumen proyek lain dapat dirinci di dalam laporan tersebut. 6. Dokumentasi (Documentation) Ada 2 jenis dokumen di dalam proyek, yaitu user dan manajemen proyek.

BAB 3

Halaman 7 dari 15



7. Asumsi (Assumptions) Disini anda dapat menentapkan harga berdasarkan asumsi : dimana sebagian besar adalah fakta yang diberikan oleh user. 3.8. KESIMPULAN UNTUK PERENCANAAN Perencanaan itu seperti menunggang kuda : kelihatannya sulit sebelum anda mencobanya. Tetapi begitu anda mencobanya, maka segalanya akan menjadi mudah.

t e N

a r d

By

BAB 3

n e H

Halaman 8 dari 15



BAB 4 PROPOSAL 4.1. PENDAHULUAN Sebuah proposal mempunyai 3 kegunaan, yaitu : 1. Berisi perkiraan tim proyek, mulai dari biaya proyek sampai dengan tanggal pengiriman proyek. 2. Untuk proyek eksternal, dokumen hukum formal menunjukkan outline tim proyek untuk memberikan pelayanan yang diperlukan. 3. Sebagai alat penjualan. Proposal yang berisi usulan proyek akan dijual untuk mendapatkan keuntungan. Kesalahan utama pada proposal dapat disebabkan 2 hal : 1. Tidak menawar, yang mana seharusnya bisa ditawar. 2. Ada tawaran, tetapi hilang dalam kompetisi.

t e N

a r 4.2. DUA FASE PROPOSAL PROYEK d SOFTWARE n e H Ada 2 fase proses proposal, yaitu : y kecil proyek, usulkan untuk dikerjakan 1. Buat fase analisisBsebagian dalam Proposal Analisis (Analysis Porposal). 2. Setelah analisis dikerjakan, usulkan sisanya dibangun dalam Proposal Pengembangan (Development Proposal).

4.3. MENULIS PROPOSAL Menulis proposal itu sulit. Harus dilakukan dengan benar, selain dapat merusak reputasi anda dan mengubah masa depan bisnis anda dengan klien. Menulis proposal juga mahal, dibuat dengan mengumpulkan banyak sumber dan banyak hal, serta terkadang anda membayar orang untuk membuatnya. Jika anda menulis proposal gunakan word processor dan gunakan huruf-huruf unik untuk setiap proposal, tetapi pastikan penulisan tersebut dibenarkan untuk setiap klien. Kerjakan dengan BAB 4

Halaman 1 dari 6



Requirement Document (RD), khususnya Request For a Proposal (RFP). Format proposal harus mengikuti RFP dan RD. Garis besar Proposal (Proposal Outline) : 1. Cakupan Surat (Cover Letter) Sebuah surat yang ditujukan kepada pengambil keputusan, ditandatangani oleh Manajer Proyek (jika diwakili oleh seorang Akuntan, maka Akuntan tersebut dapat menandatangani surat ini bersama klien yang lain). ♦ Bentuk dimulai dengan teks pendahuluan, seperti : “Thank you for giving XYZ Software Co. the opportunity to propose ……. For your computer system.” ♦ Paragraf berikutnya memberikan penjelasan yang mudah dari sistem, seperti “ …….hardware anda software to handle ABC’S registration, finance and management information needs for the next three years.”

t e N

a r d

n e H

♦ Paragraf berikutnya, jelaskan yang merupakan proposal analisis atau proposal pengembangan

y B ♦ Penutup, akhiri surat dengan pernyataan yang menunjukkan kecepatan anda membuat keputusan di surat. Bagian penutup disertai batas akhir penentuan harga (biasanya 30 hari), atau pernyataan seperti , “If we are given a go-ahead in 14 days we can start January 1, otherwise we must do another project, and we can only start yours on June 1.” Penutup surat ini dibuat sebagus mungkin.

2. Halam Judul (Tittle Page) Halaman ini berisi “Proposal”, judul dari sistem, pembuat, tanggal, nomor revisi, logo perusahaan, dan sebagainya. 3. Daftar Isi (Table of Contens) Bila klien anda tidak terbiasa dengan format proposal anda, beri penjelasan dari kegunaan setiap bagian.

BAB 4

Halaman 2 dari 6



Berikut ini contoh formatnya : Section 1 : TUJUAN Menggambarkan masalah bisnis yang disertai penyelesaian XYZ, ukuran, tingkat dan batasan yang disarankan untuk sistem penyelesaiannya …………………………… halaman 3 Section 2 : Keuntungan ………………………………….. halaman 4 4. Ruang Lingkup (Scope) Lihat paragraf yang menjelaskan hal tersebut pada bagian ini langsung dari Requirement Documents. 5. Keuntungan (Advantages) Jual proyek anda. Buktikan bagaimana perencanaan anda, kontrol dan 7 fase metodologi.

t e N

6. Keuangan (Financial) Buat harga total dan tanggal pengiriman. Bila termasuk hardware, rinci harga hardware dan sistem operasinya. Buat daftar non material, seperti job satisfaction, good will, customer happiness, management happiness, etc.

a r d

By

n e H

7. Rencana (Plan) Gambarkan langkah-langkah rencana anda untuk membangun proyek. Jika proposal analisis, rinci alasan-alasan untuk penggunaan metode 2 langkah. Jelaskan fase analisis yang dihasilkan tidak terhingga nilainya, dokumen Functional Specification yang akan digunakan oleh Klien dan Tim proyek untuk spesifikasi yang tepat mengenai apa yang dilakukan sistem. 8. Kemampuan dalam penyampaian (Deliverablless) Daftar user yang akan merinci : ♦ Hardware, sistem operasi, paket software: buat daftar secara rinci. Keadaan bagaimana yang anda pilih salah satu fungsi, kapasitas dan tanggal pengiriman. ♦ Custom software : sama seperti di atas. BAB 4

Halaman 3 dari 6



♦ Jaminan : berapa lama setelah pengiriman dan bagaimana anda akan memberikan dukungan. ♦ Dokumen : daftar manual (user, operator, manajer, maintenance) dengan penjelasan singkat dari pembaca. ♦ Pelatihan : daftar bagian (user, operator, manajer, maintenance) dengan penjelasan laporan singkat dari peserta. ♦ Gambarkan metode pengiriman : kapan anda akan mengirim, dimana akan dikirimnya dan bagaimana itu dilakukan. 9. Penerimaan (Acceptance) Salah satu masalah yang sering terjadi dalam industri komputer adalah sistem yang ditolak. User menolak untuk menerima sistem (dan untuk membayarnya), karena dia merasa tidak seperti apa yang disetujui Tim proyek pada awal pengiriman.

t e N

a r d

10. Alternatif (Alternatives) Kadang-kadang kita menentukan RFP ditulis langsung oleh penjual (hardware / software) dalam pikiran kita. Ini baik, jika anda adalah penjual, tetapi apa yang anda lakukan bila anda bukan penjual ?. Anda harus merinci solusi penjual-penjual lain, seperti ALTERNATIVE SOLUTION dan buktikan mengapa solusinya berbeda.

By

n e H

11.

Istilah, Kondisi dan Pendapat (Terms, Conditions and Assumptions) Daftar yang ada disini adalah semua kondisi yang diinginkan untuk bekerja di dalam proyek internal. Daftarkan semua asumsi, jika asumsinya mempengaruhi biaya proyek, anda harus memproteksinya. Daftar semua asumsi selalu ada pertanyaan dimana user tidak dapat menjawab dengan tepat, dan hanya dapat menjawab yang bersifat sementara jika asumsi tersebut mempunyai pengaruh yang bernilai pada proyek. User harus melaksanakan sendiri pendapatnya.

BAB 4

Halaman 4 dari 6



12. Istilah khusus (Terminologi) Setiap proposal harus ditulis dengan menggunakan bahasa user yang mungkin, beberapa istilah komputer mungkin berbeda. Jika anda merasa bahwa istilah khusus ini tidak lazim bagi user, buat definisinya.

4.4. PROPOSAL INFORMAL Proposal tidak harus dibuat di ruang rapat. Proposal tersebut dapat dibuat menjadi informal melalui telepon, tempat latihan golf, bahkan di bar. Presentasi proposal secara formal yang dilakukan di ruang rapat akan selalu membutuhkan tempat, tetapi user sudah siap mengetahui hal-hal utama apa yang akan dikemukakan.

t e N

a r d

4.5. PERSETUJUAN PROPOSAL INTERNAL

n e H

Ada aturan di DEC Software Service yang menyatakan bahwa proposal tidak dapat keluar sebelum mendapat persetujuan dari manajemen tingkat tinggi. Persetujuan manajemen tingkat tinggi berhubungan dengan sejumlah hal yang diusulkan. Peraturan ini untuk menghindari hal-hal yang tidak diinginkan.

By

4.6. PRESENTASI PROPOSAL Selalu siapkan presentasi. Siapkan dan buatlah jadwal semua peralatan yang dibutuhkan, seperti transparansi, proyektor, layar, sebuah terminal dan modem untuk berhubungan ke dalam sistem yang mirip dengan yang anda usulkan. Buatlah presentasi di dalam ruangan yang tepat menurut anda, dimana menurut pandangan user akan lebih dapat diterima.

BAB 4

Halaman 5 dari 6



Langkah-langkah presentasi : ¾ Buatlah ucapan pembuka. Perkenalkan tiap peserta, dan nyatakan tujuan pertemuan tersebut. ¾ Perkenalkan proposal anda secara garis besar. ¾ Bagikan proposal anda. ¾ Beri waktu pada tiap peserta untuk membaca proposal. ¾ Kemudian beri penekanan utama di setiap bagian yang penting. ¾ Terakhir, tutup – sarankan user untuk membeli dan membeli secepatnya.

4.7. KESIMPULAN UNTUK PROPOSAL Penulisan proposal dan mempresentasikannya merupakan sebuah seni. Anda mungkin beruntung dan tidak harus membuat proposal. Jangan membuat proposal asal jadi. Utamakan kualitas bukan kuantitas. Jangan janjikan sesuatu yang tidak diminta oleh klien : Siapa yang anda pikir akan membayar ini ? Rencanakan memberi solusi untuk semua masalah. Dan akhirnya, untuk sebuah proyek eksternal, sebuah proposal adalah kumpulan dokumen yang sah. Hal ini seharusnya dibuat sebaik mungkin seperti untuk proyek di dalam yang dengan resmi dibuat seperti jika melakukan kontrak eksternal.

t e N

a r d

By

BAB 4

n e H

Halaman 6 dari 6



KASUS Tidak menawar Sebuah perusahaan minuman ringan mengundang seorang Analis dari Famous Minicomputer Manufacturing Company (FMMC), untuk mempelajari suatu kemungkinan pada suatu hal, jika ada sesuatu yang bermanfaat dari sistem komputerisasi pada pabrik minuman ringan tersebut. Si Analisis mempelajarinya, tetapi selama belajar dia menemui sedikit kesulitan dengan masalah akuntansi di perusahaan tersebut. Akuntan yang ada pada perusahaan tersebut takut kehilangan pekerjaan dengan adanya komputer, sehingga ia mempersulit Analis dengan menolak menjawab pertanyaan yang diajukan kepadanya. Hasil dari yang dipelajari : Analis menyarankan bahwa beberapa penggunaan sistem komputerisasi akan membantu pekerjaan. Sehingga Analis menyarankan agar sistem komputer yang ada dapat digunakan untuk menjalankan pekerjaan bagian keuangan yang meliputi : piutang, hutang, kontrol persediaan, dll. Analis juga menyarankan untuk mengimplementasikan sistem tersebut untuk menangani masalah gaji, pajak, dan sejenisnya, serta menangani masalah produksi minuman yang meliputi proses produksi pembuatan minuman dan pengawasan barang-barang di gudang secara ototmatis. Ketika ditanya mengenai perincian harga untuk sistem tersebut, berdasarkan konsentrasi waktu, Analis menjelaskan bahwa hanya untuk sistem keuangan diperlukan biaya $150.000.

t e N

a r d

By

n e H

Reaksi dari user terlihat kasar. Singkatnya dia mengatakan bahwa $150.000 terlalu mahal untuk sistem komputer yang terlihat begitu sedikit kegunaannya. Dia mengatakan tidak akan membayar lebih dari $50.000 untuk sistem keuangan. Kesalahan fatal dilakukan oleh Manajer si Analis tersebut. Berdasarkan reaksi user (dan mungkin untuk alasan pribadi), Analis menyarankan kepada manajernya agar FMMC menarik kembali penawarannya. Analis merasa bahwa user akan sulit untuk ditangani, dan user tidak akan menjawab pertanyaan-pertanyaan dengan benar. Dan bahwa FMMC dan perusahaan minuman ringan tersebut tidak akan pernah mencapai kesepakatan. Sayangnya Manajer tersebut menyetujuinya dan membatalkan penawaran. BAB 4

Halaman 7 dari 6



Komentar : Semua user merasa bahwa harga sistem yang ditawarkan terlalu mahal. Mungkin user dapat saja menang dengan pendekatan lain yang berbeda. Analis dapat mengusulkan pembuatan sistem tersebut secara bertahap yaitu dengan membuat sistem dalam ukuran-ukuran yang lebih kecil, sehingga user tertarik. Mungin user memiliki uang, dan dia perlu bernegosiasi. Jangan pernah menyerah untuk menawar dalam pertemuan pertama. Mungkin saja ada masalah pribadi antara Akuntan yang takut kehilangan kedudukannya dengan Analis. Manajer harus mengetahui hal ini dan datang untuk membantu bernegosiasi. Situasi di atas dapat terjadi pada proyek internal dimana seorang user dan klien berada pada dua departemen dalam satu perusahaan. Usahakan reaksi pertama untuk mengurangi harga. Rencanakan negosiasi. Kadang-kadang lawan anda hanya menguji untuk mengetahui seberapa yakin anda pada proposal anda. Bila anda menarik kembali penawaran haga dengan tergesa-gesa, dia akan mengetahui bahwa anda tidak percaya diri.

t e N

a r d

Penutup : Perusahaan minuman ringan tersebut menggunakan sistem komputerisasi dengan harga ditetapkan oleh Analis pertama, tetapi tidak oleh perusahaan FMMC.

By

n e H

Kehilangan Penawaran Seorang pengarang buku terkenal “Software Project Management” (untuk proyek berukuran kecil) memulai karirnya memberi nasehat sebagai guru mikrokomputer. Dia berjalan-jalan di sekitar toko-toko mikrokomputer di kotanya dan memberi informasi pada pemilik toko bahwa ia dapat mengajar apapun pada siapapun. Sungguh meyakinkan, suatu hari ia mendapat panggilan dari departemen pemerintahan bagian pemeliharaan pesawat terbang. Tugas mereka adalah mengetahui siapa saja di negara tersebut yang sudah mendapat pelatihan mengenai jenis-jenis pesawat terbang. Enam bulan yang lalu seorang anggota departemen telah membeli sebuah mikrokomputer kuno, lengkap dengan program data base yang tidak terdokumentasikan (dengan harga yang luar biasa), tetapi ia telah meninggalkan departemen tersebut sebelum data base BAB 4

Halaman 8 dari 6



diimplementasikan. Tidak seorangpun dari pegawai di departemen itu memiliki pengalaman komputer. Maka guru itu dipekerjakan untuk melatih pegawai di departemen itu dengan cukup baik, untuk menjalankan program data base pada komputer. Guru tersebut memperoleh informasi yang tepat dan berhasil mengajak orangorang bagaimana menggunakan komputer dan program data base. Sekitar satu bulan kemudian, guru itu menerima panggilan dari kepala departemen, yang menanyakan jika ia dapat mengajukan harga yang sebenarnya untuk menjalankan data base mereka. Guru tersebut mewawancarai pemakai data base yang berpotensi : ada 25 pemakai yang berpotensi dengan 50 pendapat yang berbeda tentang bagaimana menggunakan data base tersebut. Dengan catatan program data base tidak akan mengatasi semua kebutuhan mereka – program-program yang lainnya akan ditulis. Guru memperkirakan ini akan memakan waktu selama 3 bulan.

t e N

Kesempatan pertama si guru harus mengajukan proposal pada rapat komisi tingkat manajer dari 8 manajer departemen. Semua berjalan lancar sampai pada waktu ia mengemukakan harganya : 3 bulan untuk membuat program dengan biaya $400 per-hari, totalnya $20.000. Para manajer terkejut. Selama ini mereka hanya menghabiskan $1000 untuk hardware dan paket software, dan sekarang seorang yang dungu memberitahukan mereka bahwa ia akan menghabiskan $20.000 lagi untuk menjalankannya.

a r d

By

n e H

Komentar : Terkadang para pemakai tidak sadar akan harga software, khususnya pada mikrokomputer dimana harga hardware hanya sebagian kecil dari harga keseluruhannya. Pada kasus ini harapan para Manajer tidak ditetapkan dengan tepat untuk batasan harga tersebut. Penutup : Mikrokomputer ini tetap ada di sana bersama dengan debu.

BAB 4

Halaman 9 dari 6



BAB 5 NEGOSIASI DAN KONTRAK 5.1. NEGOSIASI Mengapa bila orang pergi ke tempat perdagangan di Mexico, mereka akan melakukan negosiasi walaupun hanya untuk beberapa dolar saja, tetapi bila mereka melakukan transasksi dengan sebuah produk berharga ribuan dolar, mereka enggan untuk “tawar-menawar”. Tidak ada kata malu untuk melakukan negosiasi. Belajar dari bagaimana semua itu dilakukan dengan benar dan anda dapat menggunakan keahlian pada saat situasi tawar-menawar dalam lingkungan proyek software. Ilmu Pengetahuan dan Seni Bernegosiasi Kunci sukses dari negosiasi adalah mengetahui fakta yang sebenarnya. Hal pertama dan yang terpenting, mengetahui produk yang akan dijual atau dibeli.

t e N

a r d

n e H

Sebelum anda memulai negosiasi, tentukan dua hal : 1. Apa yang sepenuhnya anda inginkan untuk perjanjian 2. Apa yang akan anda berikan

By

Bila anda penjual software, hal yang akan dinegosiasikan adalah harga, ketahui harga minimum yang akan diminta. Jika anda pembeli, ketahui harga maksimum yang akan dibayarkan. Hal ini juga membantu jika anda mengetahui kebutuhan lawan anda, ini dikatakan dengan fleksibilitas. Tiga hal yang dinegosiasikan dalam proyek software Hal yang paling sering dinegosiasikan adalah harga, tetapi lamanya proyek dan fungsi proyek dapat juga dinegosiasikan. Seperti kata pepatah, “Anda akan mendapatkan yang murah, cepat atau bagus : pilih dua hal”. Anda dapat menghemat uang dengan mengambil waktu yang lebih lama. Atau apabila harga terlalu mahal, perhitungkan menawar dengan kelengkapan yang lebih sedikit.

BAB 5

Halaman 1 dari 5



Anda memperoleh apa yang anda bayar Jika anda membeli produk, berhati-hatilah dengan tawar-menawar Tim proyek yang terlalu rendah, atau menerima tawaran murah yang tidak biasanya. Contoh kasus : Perusahaan ABC menawarkan tender keluar untuk kebutuhan software. Mereka menerima 2 tawaran : Pertama dari Smart Software Co. (SSC). SSC mempunyai perkiraan akurat dan menawarkan harga $200 untuk dilaksanakan dalam 12 bulan. Kedua, tawaran dari Unscrupulous Software Co. (USC). Mereka menawarkan $100 untuk jangka waktu 6 bulan. Mencoba menghemat biaya, perusahaan ABC tentu saja menerima USC. Enam bulan kemudian setelah pembayaran $100 kepada USC, kejadian berikut ini terjadi : ABC USC ABC USC

t e N

: Benarkah sistem akan diantar hari ini ? : Kami mempunyai kabar buruk. : Kabar buruk apa ? : Sayang sekali, kami telah menghabiskan $100, tetapi kami baru menyelesaikan hanya setengah dari sistem yang tertulis. Anda punya dua pilihan : berikan kami $100 lagi (atau mungkin lebih), atau ambil saja setengah sistem anda. ABC : Tetapi kita mempunyai kontrak ! USC : Saya harus menggaji programmer saya, jika tidak mereka akan berhenti. Jika anda tidak membayar saya, saya akan dinyatakan bangkrut. Silakan kirim surat ke Brazil.

a r d

By

n e H

5.2. KONTRAK Kontrak untuk produk software mengharuskan tim proyek untuk menyediakan pengirim khusus, seperti tanggal yang pasti, untuk berbagai macam pemberian upah. Kecuali proyek ini dilaksanakan pada dasar formal dalam organisasi eksternal, khususnya dalam dokumen “kontrak” yang tidak ingin dituliskan.

BAB 5

Halaman 2 dari 5



Bagian-bagian Kontrak (Items To Be Contracted) Dalam tambahan untuk harga, tanggal pengiriman dan pengiriman, kontrak ini dapat termasuk dalam hal-hal dan kondisi lain seperti reproduksi, harga bertahan (price holding), lisensi atau garansi. Bila kerusakan dari software dapat menyebabkan tidak hidup atau situasi kritis lain, pertanggung jawaban dari pemulis harus diklarifikasikan. Jika perkiraan didasarkan pada input verbal dari user, “escape clause” harus diikutsertakan. Anjuran tim proyek ini berguna untuk keluar dari kesalahan informasi. Tanggung jawab user, seperti menyediakan informasi yang akurat dan tepat waktu, atau melakukan beberapa pekerjaan seperti dokumentasi, juga harus ditulis. Kontrak Harga Tetap (The Fixed Price (FP) Contract) Ini merupakan tipe umum dari kontrak. Di dalam kontrak FP, tim proyek mengajukan harga total pada awal proyek. Bagaimanapun juga tim proyek harus memperkirakan risiko di dalam kontrak FP. Gunakan kontrak FP hanya jika anda dapat memperhitungkan risiko dan harganya.

t e N

a r d

Kontrak FP sangat tepat bila : 1. Anda yakin bahwa tidak akan terjadi pergantian utama. 2. Anda akan bekerja dengan software dan produk hardware yang anda ketahui. 3. Anda memiliki komunikasi yang baik dengan user.

By

n e H

Kontrak Harga Tambahan (The Cost Plus (CP) Contract) Apabila risiko terlalu tinggi dalam menentukan harga tetap, tim proyek harus memilih kontrak CP. Pada kontrak CP, tim proyek menerima gaji dalam jumlah tetap per-hari atau per-jam ditambah ongkos-ongkos. Biasanya perusahaan tidak membuat janji untuk berapa lama mereka membuat kontrak. Kontrak CP sangat tepat bila : 1. Anda merasa bahwa pergantian utama akan terjadi (RD tidak ada atau kebutuhan lain tidak jelas). 2. Anda bekerja dengan tidak mengetahui sistem operasi, paket software atau hardware, atau anda mempunyai peralatan pengembangan khusus untuk menulis, seperti simulator, tes dasar, dsb. BAB 5

Halaman 3 dari 5



3. Komunikasi yang kurang baik antara anda dan user. 4. Aktifitas utamanya berorientasi pada manusia, interview.

contohnya

Kondisi dan Syarat (Terms and Conditions) Jika anda menjalani kontrak CP, yakinkan bahwa kondisi dan persyaratan jelas. Masukkan semua syarat dan kondisi – aspek hukum dari cara yang anda inginkan untuk bekerja dengan klien. Ini akan memeberikan perlindungan bagi anda dan klien, dan menghindari kesulitan yang akan datang. Hal-hal yang berkaitan dengan hukum harus diklarifikasi seawal mungkin yang dapat meliputi isu-isu pembayaran, hak cipta untuk sumber daya dan dokumentasi, hutang, jaminan, dan masalah-masalah yang berhubungan dengan hardware dan software yang disediakan oleh pabrik.

t e N

Kontrak Di luar Organisasi dan Di dalam Organisasi Kontrak akan diterima secara luas jika organisasi eksternal atau perusahaan menyediakan layanan proyek. Mengapa ini bukan bagian dari proyek ? Walaupun hubungan antara tim proyek dan user sangat dekat harus ada sesuatu yang bersifat resmi, pernyataan tertulis menjelaskan layanan yang akan disediakan oleh tim proyek . Ini dapat dijadikan surat perjanjian (letter of intent) atau proposal resmi. Garis bawahi ini dan anda akan terhindar dari percekcokan yang tidak pernah berakhir.

a r d

By

n e H

5.3. PENINJAUAN PROPOSAL YANG DIKEMBALIKAN User dapat mengembalikan proposal yang telah diterima dengan “sedikit” perubahan-perubahan. Waktu yang dijadwalkan untuk anggota teknis dari tim proyek untuk meninjau sedikit perubahan susunan kata dapat berarti upaya utama. Masalah harga dapat dinegosiasikan kembali.

BAB 5

Halaman 4 dari 5



Berhati-hati untuk tidak setuju pada kondisi dan persyaratan. Biarkan manajemen tingkat tinggi atau departemen yang sah menangani masalah ini. Jangan memulai pekerjaan sampai seluruh persetujuan selesai. Akan lebih menguntungkan anda untuk membiarkan user mengetahui kondisi-kondisi dan persyaratan sebelum menulis proposal.

5.4. KESIMPULAN UNTUK FASE DEFINISI Ini akan membawa kita pada akhir fase definisi. Mari kita mengulang kejadian penting yang pernah dicapai. Ingat kembali kejadian penting yang digunakan untuk merencanakan proyek dan mengontrol kemajuan proyek. 1. Dokumen Kebutuhan (RD) yang lengkap dan telah disetujui oleh kedua belah pihak yaitu Tim proyek dan user. 2. Dokumen proposal dapat digunakan untuk analisis atau seluruh pengembangan, yang dilengkapi dan dibeli oleh user. Tulis persetujuan yang diinginkan. 3. Walaupun tidak mempertimbangkan kejadian penting, izin dari PPP itu dengan menyediakan sumber daya yang diperlukan.

t e N

a r d

By

BAB 5

n e H

Halaman 5 dari 5



BAB 6 FASE ANALISIS 6.1. PENDAHULUAN Tujuan dari fase analisis adalah mendefinisikan secara tepat apa yang dapat dilakukan sistem untuk user, dan bagaimana sistem tersebut menyesuaikan dengan lingkungan user. Aktivitas utama (kejadian penting) dari fase ini adalah untuk menghasilkan dokumen yang menjelaskan arti lingkungan sistem, disebut Functional Specifications (FS) / Spesifikasi Fungsi. Setelah mengerjakan FS, anda kini memiliki pengetahuan yang lebih dibandingkan pada Fase Definisi, sehingga anda harus meninjau ulang rencana permulaan proyek dan perkiraan awal.

t e N proposal / proposal Aktivitas ketiga, menuliskan development a r pengembangan, dan akan dikerjakan jika dua metode proposal akan d n dilakukan. Hal tersebut akan e ditulis setelah FS. Isi dan garis besar H proposal pengembangan sama dengan proposal analisis, kecuali y bahwa proposal pengembangan dikerjakan dengan menggunakan B lima tahap dari pengembangan. Dalam fase analisis “Anda harus menghadapi apa yang akan dilakukan, bukan mengenai bagaimana hal tersebut akan dilakukan, karena fase disain akan membahasnya”. 6.2. ALIRAN DATA YOURDON / METODE ANALISIS BUBBLE CHART (THE YOURDON DATA-FLOW/BUBBLE CHART METHOD OF ANALYSIS) Edward Yourdon menemukan sebuah metode grafik untuk mendokumentasikan dan mengendalikan proses analisis yang menjadi sangat populer (Referensi 11). Berikut ini (gambar 6.1) adalah sebuah aplikasi dari metode tersebut untuk proyek ABC.

BAB 6

Halaman 1 dari 14



t e N

a r d

By

n e H

Gambar 6.1. Analisis Yourdon

BAB 6

Halaman 2 dari 14



Pendefinisian User Analis bersama-sama dengan user mengembangkan diagram seperti pada gambar 6.1. Mereka mulai dengan membuat daftar semua user yang akan memiliki hubungan dengan sistem. Termasuk user tidak langsung seperti STUDENT. Kemudian mereka menggambar garis panah untuk semua input dari dan output untuk masing-masing user, garis diberi nama dengan informasi atau data yang melewatinya. Garis panah tersebut mewakili aliran informasi (STUDENT → REGISTRAR melalui telepon), aliran data (REGISTRAR → COMPUTER lewat terminal) atau kejadian perpindahan secara fisik dari bagian-bagian (WAREHOUSE → CLASSROOM ships material). Inilah sebabnya mengapa diagram ini disebut diagaram ‘aliran data’. Kemudian analis dan user mengidentifikasi informasi umum yang disimpan oleh sistem (informasi kursus, informasi murid, informasi material) dan menuliskannnya ke dalam lingkaran.

t e N

a r d

n e Pendefinisian Antarmuka H User y B User dan Analis menjelaskan setiap bagian yang diwakili oleh garis

panah, yang merupakan aliran data antara user dan sistem. Hal ini akan mengontrol penjelasan mengenai semua menu, formulir, laporan, perintah-perintah dan pesan-pesan – dengan kata lain merupakan ‘tampilan antarmuka user’ pada sistem. Tujuan dari proses ini adalah : • Pertama untuk menjelaskan tampilan antarmuka pada komputer. • Kedua untuk memperoleh pemahaman yang umum dari bisnis user. Seringkali user belajar mengenai bisnisnya sendiri dari tipe analisis ini.

Sebagai contoh, analisis dari aliran data STUDENT ke REGISTRAR akan dihasilkan sebagai berikut :

BAB 6

Halaman 3 dari 14



STUDENT → REGISTRAR and REGISTRAR → STUDENT Method : Verbal over phone, or mailed in Inquiries Location, dates of courses Number enrolled/maximums Cost ………. Responses Course locations, dates (next 6 months) Number enrolled (next 6 months); maximum allowed Cost ………. Changes Update name, address, payment information of student Cancel a student from a course Register a student Obtain and enter name, address, course (by number) Payment information Performance Must handle up to 3 calls per minute

t e N

a r d

By

n e H

Analisis terhadap REGISTRAR → ABC akan menghasilkan : REGISTRAR → ABC Method : Terminal input Automatic registrar menu When registrar logs in with specific account number, menu of The format in the Functional Specification Figure 3.9. is presented. To make a choice on this menu, the registrar can use either the UP and DOWN arrows keys followed by RETURN, or move the mouse up or down, followed by press on mouse button. If student wishes information on course Registrar chooses 1. Menu of format FS Fig. 3.10 appears. If student wishes to enroll…..

BAB 6

Halaman 4 dari 14



Langkah berikutnya adalah merinci seluruh menu, formulir, laporan dan perintah yang tepat. Semua menu seperti REGISTRAR dan pertanyaan mengenai kursus harus dijelaskan.

6.3. SPESIFIKASI FUNGSI (THE FUNCTIONAL SPECIFICATIONS / FS) FS menjelaskan semua tingkah laku sistem dalam bentuk cerita dan gambar. Definisikan antarmuka user seperti di atas, menu-menu, perintah-perintah, respon, laporan dan pesan-pesan dijelaskan sebanyak mungkin. Setiap perubahan di dalam lingkungan user karena sistem baru akan dijelaskan. Semua pengiriman, termasuk hardware, software, pelatihan, dokumentasi dan garansi dirinci. Sebagai tambahan pada proposal, FS juga merupakan kontrak antara User dengan Tim Proyek (PT). Sejumlah uang yang besar mungkin dipertaruhkan, dan user membutuhkan lebih rinci tantang apa yang dapat diberikan dibandingkan apa yang ada di proposal. FS mungkin akan dinegosiasikan dan ditinjau kembali, dan ketika persetujuan dicapai proposal harus ditanda tangani oleh kedua belah pihak.

t e N

a r d

By

n e H

Garis Besar FS (Outline of the FS) (Lihat Appendix A untuk contoh keseluruhan) 1. Judul Halaman (Title Page) Judul fungsi spesifikasi, nama sistem, pembuat, dan tanggal Jangan lupa nomor versi : dokumen ini akan direvisi ! 2. Daftar Isi (Table of Contens) Nama bagian, berikut nomor halaman 3. Gambaran Sistem / Ikhtisar Sistem (System Overview) Menjelaskan sistem yang akan dibuat. Ingatlah bahwa FS adalah dokumen teknik yang ditujukan untuk pembaca non teknis (user). Cara terbaik untuk menjelaskannya dengan menggunakan gambar.

BAB 6

Halaman 5 dari 14



Marilah kita ambil contoh sistem Amalgamated Basketweaving Course (ABC) yang dijelaskan di awal. Sistem berdasarkan data mengenai kursus (Course) dan murid (Student). User membutuhkan keterangan yang pasti mengenai data pendaftaran, kursus yang masih dibuka/tersedia, jadwal, rincian akuntansi, dsb. User juga membutuhkan kemampuan untuk merubah data. User membutuhkan laporan yang dihasilkan, seperti faktur, konfirmasi, jumlah murid yang mendaftar. Semua bagian ini harus ada antarmukanya dengan user, sehingga sebaiknya dibuatkan sistem menu menggunakan mouse. Untuk menjelaskan semua ini, anda sebaiknya mulai dengan diagram seperti pada gambar 6.2.

t e N

a r d

By

n e H

Gambar. 6.2. Major functions of the system. BAB 6

Halaman 6 dari 14



4. Tujuan Utama (Major Objectives) Buatlah daftar tujuan sistem, hubungkan masing-masing ke modul utama. Contoh INQUIRY akan menjawab pertanyaan seperti “Berapa banyak murid yang mendaftar kursus”. Menjelaskan bagaimana sistem yang baru akan mempengaruhi lingkungan user, yaitu dimana terminal akan ditempatkan, siapa yang menggunakannya, laporan apa yang akan dibuat, kapan dan bagaimana hal ini akan mengubah pekerjaan setiap orang. Anda harus memperingatkan user apabila sistem ini akan mempengaruhi berbagai aspek kehidupannya. 5. Kebutuhan Khusus Sistem (Special System Requirements) Bagian ini menunjukkan kebutuhan-kebutuhan sistem seperti jaringan, kesesuaian, keamanan, ketahanan, dan kemudahan dalam menggunakan sistem.

t e N

Persoalan yang rumit seperti respon (jumlah waktu dalam detik yang dibutuhkan komputer untuk menjawab), throughput (jumlah total pekerjaan yang diselesaikan komputer dalam jangka waktu tertentu) dan growth / perkembangan (kebutuhan sistem untuk beberapa tahun ke depan) dapat ditunjukkan disini.

a r d

By

n e H

Sebagai contoh bagaimana jika RD berisi pertanyaan seperti : “Sistem harus memberikan respon untuk setiap input dalam 5 detik”. Sebuah komputer tercepat yang pernah dibuat sekalipun membutuhkan waktu lebih dari 5 detik untuk merespon berbagai permintaan. Demikian pula jangan menjanjikan dengan pasti mengenai throughput atau growth. Janji-janji yang pasti dapat diberikan pada sejumlah hal, seperti jumlah user, ukuran file, transaksi per-menit, atau pengembangan hardware, akan tetapi hal-hal tersebut mungkin sulit dipenuhi pada waktu penerimaan. 6. Deskripsi Komponen (Component Descriptions) Bagian ini menjelaskan secara detail masing-masing isi kotak, atau fungsi yang terdapat pada gambar 6.2.

BAB 6

Halaman 7 dari 14



Jangan menjelaskan file yang berorientasi informasi seperti organisasi file, record dan field – semua itu sudah ada dalam disain. Lakukan pernyataan yang menunjukkan batasan, seperti jumlah maksimum kursus yang dapat ditangani oleh sistem. 7. Pengiriman yang lain (Other Deliverables) Dokumentasi. Menyatakan jumlah dokumen yang dihasilkan, pembaca yang diharapkan, dan kegunaannya. User’s Guide sebaiknya menyediakan 2 tujuan : • Pertama, sebagai alat pembelajaran • Kedua, sebagai referensi dengan petunjuk seluruh perintah dan pesan yang akan disajikan secara alphabet. Pelatihan. Buatlah daftar modul-modul atau topik-topik yang menjadi cover pada masing-masing kursus, dan materi pelatihan yang digunakan.

t e N

8. Perubahan Spesifikasi (Specification Changes) Perubahan FS mungkin menyebabkan perubahan ke seluruh itemitem yang lain, yang menyebabkan biaya menjadi mahal dan penundaan waktu pengiriman. Perubahan harus diminimalkan.

a r d

n e H

y B 9. Penerimaan (Acceptance)

Salah satu masalah terbesar dalam dunia software adalah user kadang-kadang enggan untuk menerima dan membayar sistem tersebut. Oleh karena itu dalam FS kita rinci metode penerimaan, dan mengakhirinya dengan baik. 10.User dan Interface Tim Proyek (User and Project Team Interface) User dan Tim proyek harus saling berkomunikasi pada level teknik maupun manajemen. Kebutuhan secara teknik dari User diperlukan saat Tim proyek memerlukan jawaban yang cepat dan akurat berbagai pertanyaan yang bersifat teknik. Berbagai pertanyaan ini tidak selesai hanya pada fase analisis, tetapi akan semakin kompleks saat proyek dilaksanakan. Sebaiknya user menunjuk paling sedikit satu orang yang dapat menjawab pertanyaan-pertanyaan tersebut. BAB 6

Halaman 8 dari 14



User dan Tim proyek harus berkomunikasi pada level manajemen dengan baik. Hal ini harus dilakukan paling tidak oleh Proyek Koordinator User dan Manajer proyek. Mereka akan mendiskusikan berbagai isu seperti pendanaan, jadwal, perubahan-perubahan, dan masalah-masalah sumber daya manusia. 11.Tanggung Jawab User (User’s Responsibilities) Untuk menghemat uang dan waktu, atau jika user berharap dilibatkan lebih banyak, Tim proyek mungkin meminta kepada user untuk mengerjakan tugas-tugas proyek, seperti menyediakan data test, menulis User’s Guide, atau bahkan merencanakan acceptance test. Buatlah daftar seluruh kegiatan dan batas waktunya. Ingatkan user untuk menandatangani dokumen ini. 12.Istilah, Kondisi dan Asumsi (Terms, Condition anda Assumptions) Buatlah daftar aturan baru dan kebijaksanaan yang harus dipatuhi semua orang.

t e N

a r d

n e H

6.4. TEKNIK PENULISAN UNTUK PEMBACA NON TEKNIS (TECHNICAL WRITING FOR THE NON-TECHNICAL READER)

By

Untuk menulis FS yang baik memang sulit sekali. Jika FS menjelaskan sebuah sistem teknis, maka disebut dokumen teknis, tetapi FS ini ditulis untuk pembaca non teknis. Tulislah dari sudut pandang user – gunakan terminologinya. Untuk itu anda harus mempelajari bisnis user dan bahasanya. Alasan terbesar yang menyebabkan kesalah pengertian dokumen adalah kata-kata yang memiliki dua arti. Hal yang sama, hindari janjijanji yang sulit untuk dilakukan.

BAB 6

Halaman 9 dari 14



6.5. KEGUNAAN LAIN UNTUK SPESIFIKASI FUNGSI (OTHER USES FOR THE FUNCTIONAL SPECIFICATION) FS yang baik dapat digunakan untuk memperkenalkan proyek kepada anggota Tim proyek yang baru. User dapat menggunakannya untuk memperkenalkan sistem yang baru ke pihak manajemen, atau ke bagian-bagian lain. Tetapi yang paling penting adalah bagianbagian yang menjelaskan menu, form, query, dan report dapat digunakan dalam User’s Guide.

6.6. CASE SOFTWARE TOOLS UNTUK ANALISIS (CASE SOFTWARE TOOLS FOR ANALYSIS) Computer Aided Software Engineering (CASE) digunakan sebagai suatu paket software tools pada masing-masing fase dari daur hidup sistem. Terdapat beberapa produk software yang mutunya bagus yang membantu anda untuk melakukan analisis. Contohnya Excelarator. Excelarator dapat digunakan untuk menggambarkan Data Flow Diagram (DFD) tingkat tinggi, seperti pada gambar 6.2., kemudian memecah DFD ke level-level berikutnya yang lebih rendah.

t e N

a r d

By

n e H

Peralatan analis menyediakan menu, layar, dan fasilitas laporan dari gambar untuk membantu menjelaskan kepada user. Input dan output pada layar dapat digambarkan dengan menggunakan mouse input. Laporan query dapat secara cepat ditampilkan.

BAB 6

Halaman 10 dari 14



t e N

Gambar 6.3. Excelarator report mock-up

a r dDECDESIGN mendukung fase Pada mini komputer, alat seperti n e DFD atau Entity Relationship analisis dengan menggambarkan H Diagram (ERD), seperti pada saat menggambar Structure Chart dan y B Diagram State Transition.

BAB 6

Halaman 11 dari 14



t e N

a r d

By

n e H

Gambar 6.4. DECDESIGN Entity Relationship Diagram 6.7. MENINJAU KEMBALI PERENCANAAN (REVISING THE PLAN) Perencanaan adalah proses pengulangan. Lakukan perbaikan PPP segera setelah analisis dilakukan. Apakah tugas-tugas masih dapat diperkirakan, ditentukan, dijadwalkan, dan diselesaikan ? Yang paling penting adalah tanyakan apakah sumber daya yang diperlukan untuk masing-masing tugas masih tersedia ketika dibutuhkan ? Berikut ini adalah daftar pendek dari masalah-masalah yang dapat terjadi dalam tiga fase berikutnya (Design, Programming, System Test), selama pelaksanaan rencana berikutnya : • Programmer kunci atau perancang mengundurkan diri. • Komputer pengembangan tidak tersedia. • Peralatan hardware yang khusus tidak ada / terwujud tepat pada waktu dibutuhkan. BAB 6

Halaman 12 dari 14



• Paket software dengan release terbaru (atau hardware) tidak bekerja. • Sumber daya yang disediakan oleh pihak ketiga tidak terwujud. Rencana Pelatihan Untuk Anggota Proyek (Training Plans For The Project Members) Ketika akhirnya staf telah diputuskan, lakukan pemeriksaan untuk melihat siapa-siapa saja yang membutuhkan pelatihan. Programmer anda merupakan calon yang paling memungkinkan. Jadwalkan semua pelatihan yang akan dilakukan pada akhir disain. 6.8. KESIMPULAN DARI FASE ANALISIS Diharapkan FS dinegosiasikan atau ditinjau kembali; jadwalkan waktu untuk persetujuan dan perbaikan. Atur batas akhir penyelesaian. Jika tidak disetujui diantara individu-individu atau departemen-departemen menyebabkan ‘analysis paralysis’, ambil satu orang dari tiap departemen dan kumpulkan dalam satu ruang dan tekankan untuk tidak menunda pertemuan sampai masalah terpecahkan.

t e N

a r d

n e Dan yang terakhir, kita tinjau kembali kejadian-kejadian utama dalam H fase analisis : By

1. Spesifikasi Fungsi (FS) yang disetujui dan ditandatangani oleh kedua belah pihak. 2. Jika kedua langkah proposal digunakan, Development Proposal telah ditulis dan dibeli oleh user. 3. PPP diperbaiki untuk memasukkan perhitungan-perhitungan baru dan jadwal-jadwal; sumber-sumber masih dijalankan untuk seluruh kegiatan. 4. Disain tingkat atas (The Top Level design / TLD) telah dilakukan. Hal ini mungkin tidak jelas, tetapi anda harus mengerjakan TLD ketika anda menemukan gagasan dan menggambarkan gambar 6.1. Ini mungkin bukan TLD terbaik, meskipun pada akhirnya akan digunakan juga, tetapi itu merupakan terobosan pertama bagaimana sistem akan bekerja dan bagian utama yang akan diproduksi.

BAB 6

Halaman 13 dari 14



BAB 7 FASE DISAIN 7.1. PENDAHULUAN Aktivitas utama dalam Fase Disain adalah membuat top dan medium level dari disain sistem dan mendokumentasikannya dalam Spesifikasi Disain. Aktivitas kedua dimulai dengan melakukan Rencana Test Penerimaan (Acceptance Test Plan / ATP). ATP adalah sebuah dokumen tes yang akan digunakan untuk mendemonstrasikan seluruh fungsi sistem kepada user pada fase penerimaan. Terdapat dua langkah dalam mendisain sistem software, yaitu : • Pertama, bagilah sistem menjadi beberapa komponen secara fungsional. • Kedua, hubungkanlah komponen-komponen tersebut.

t e N

a r 7.2. DISAIN YANG TERSTRUKTUR d(STRUCTURED DESIGN) n e H Tujuan utama dari disain yang terstruktur adalah memecah sistem y kecil, teratur dan mudah untuk dibangun. menjadi bagian yang Blebih Disain Top Down (Top Down Design) Disain Top Down dimulai dengan Top Level Design (TLD).

BAB 7

Halaman 1 dari 22



Masing-masing komponen utama atau kotak dalam TLD dipecah menjadi sub-bagian dimulai dengan level teratas, kemudian turun ke level berikutnya, dst.

t e N

Dalam kasus ini, dimulai dengan MENU dan mendisainnya sebelum turun ke INQUIRY, UPDATE, dan REPORT GENERATION, yang akan diikuti dengan tingkat selanjutnya, jika ada.

a r d

By

n e H

Disain Bottom Up (Bottom Up Design) Pada kasus tertentu mungkin akan lebih mudah mendisain dengan menggunakan pendekatan dari level bawah / rendah ke level atas. Hal ini sering ditemui pada kasus sistem pengontrolan proses dimana perlatan pengontrolan hardware pada level terbawah menentukan bagaimana sistem tersebut disatukan (integrasi sistem). Contoh : Kita akan mendisain sebuah sistem pengujian mesin kendaraan. Kita harus mulai dengan menentukan hardware dasar atau komponen dasar yang terlibat – sensor mesin.

BAB 7

Halaman 2 dari 22



Sensor umumnya dipasang pada alat digital atau analog, yang terpasang pada modul software pengendali (drivers) alat yang unik.

t e N

a r d

By

n e H

Software yang digunakan untuk mengontrol alat pengendali / drivers kemudian didisain di atas pengendali-pengendali tersebut.

BAB 7

Halaman 3 dari 22



Demikianlah sistem software didisain dari level bawah ke atas. Disain Bottom Up juga sangat cocok digunakan pada kasus dimana komponen software yang ada digabungkan dan disatukan dengan modul baru untuk membangun sebuah sistem.

t e N

a r d

n e H

7.3. PERTUKARAN DISAIN TINGKAT ATAS (TOP LEVEL DESIGN TRADE – OFFS)

y B Umumnya banyak disain tingkat atas yang dapat mencapai atau memperoleh hasil yang sama dalam sebuah sistem software. Contohnya, disain tingkat atas (top level) pada gambar 7.1. hanya salah satu cara untuk memecahkan sistem ABC kedalam komponenkomponen utama. Keputusan untuk membangun sendiri atau membeli merupakan keputusan yang khusus. Ada keuntungan dan kerugian pada setiap kombinasi dari item yang dibangun maupun yang dibeli. Semakin banyak paket program yang anda beli, semakin berkurang pemrograman yang harus anda lakukan. Keputusan untuk membeli paket program lebih mudah dibandingkan harus membuat sendiri,

BAB 7

Halaman 4 dari 22



akan tetapi lebih mahal, dan umumnya kurang efisien dibandingkan dengan program tertulis biasa yang sama. Disain tingkat atas yang lain ada juga yang cocok. Salah satu masukkan mungkin adalah menghilangkan INQUIRY, UPDATE dan REPORT GENERATION dan menggunakan rutin FILE HANDLER yang umum untuk melakukan semua kegiatan akses file. TLD akses tersebut seperti pada gambar 7.3.

t e N

a r d

By

n e H

Disini ada lima program yang harus dibuat dan sedikit penurunan kinerja akan terlihat oleh karena pemanggilan yang sering pada FILE HANDLER, tetapi sistem akan menjadi lebih kecil. Setiap pilihan TLD memilki keuntungan dan kerugian dan melibatkan pertukaran dan kompromi. Prioritas Disain (Design Priorites) Pilihan TLD anda akan mempengaruhi hal-hal berikut ini : • Biaya Sistem (System Cost) • Waktu yang diperlukan untuk membangun sistem (Time to Build The System) • Sifat mudah dipakai (User Friendliness) • Kinerja (Performance) BAB 7

Halaman 5 dari 22



• Ukuran Sistem (System Size) • Kehandalan (Reliability) • Kemampuan modifikasi (Modifiability) Item-item ini harus menjadi prioritas, bersama dengan user pada waktu perencanaan sistem, pada saat pendefinisian dan analisis. Ini akan membuat pilihan TLD jauh lebih mudah. 7.5. DISAIN TINGKAT MENENGAH (MEDIUM LEVEL DESIGN) Setelah TLD terpilih, kita harus membagi masing-masing fungsi atau komponen utama menjadi beberapa sub fungsi atau komponen. Kita akan lihat bagaimana hal tersebut dilakukan untuk menggabungkan sistem perusahaan Basketweaving. Diawali dengan memberi nomor setiap komponen utama pada TLD.

t e N

a r d

By

n e H

Disain top down ini dimulai dengan kotak menu. Diasumsikan bahwa komponen ini dipanggil ketika seluruh sistem dimulai dan menampilkan menu utama ke bagian register.

BAB 7

Halaman 6 dari 22



Menu Utama Kemudian program menunggu user untuk memindahkan mouse.

t e N

Sub fungsi utama komponen MENU adalah : 1. Memulai sistem dan menampilkan main menu 2. Menangani perpindahan mouse 3. Menangani tombol pada mouse 4. Pindah ke Menu INQUIRY, UPDATE, WAREHOUSE atau REPORT ketika dipilih 5. Menangani kesalahan-kesalahan seperti pada on line help messages untuk seluruh sistem 6. Mematikan sistem jika QUIT dipilih

a r d

By

n e H

Struktur diagram tingkat selanjutnya atau diagram rinci untuk komponen MENU akan tampak seperti berikut ini.

BAB 7

Halaman 7 dari 22



Level terendah dari suatu menu menggambarkan modul. Sebuah modul adalah bagian terkecil yang dapat ditest dan dicompile. Aturan Penamaan (Naming Conventions) Modul diberi nama untuk menunjukkan sistem, fungsi atau subfungsi yang diperlukan. Aturan Penomoran (Numbering Conventions) Nomor pada setiap kotak disusun dengan aturan sebagai berikut : Pada tiap-tiap tingkat terendah tambahkan sebuah titik dan angka bulat untuk nomor yang terletak di atas kotak. Angka bulat tersebut diurutkan dari kiri ke kanan.

7.6. KAMUS DISAIN (DESIGN DICTIONARIES)

t e N

Modul Kamus (Module Dictionaries)

a r d

Dictionary 1 Berdasarkan urutan angka sesuai dengan nomor komponen, berikan nama yang tetap, dan penjelasan singkat untuk setiap modul. Contoh : 0.0 1.0 1.1

By

A0000000 AM000000 AMST0000

n e H

Amalgamated Basketweaving System Menu System Startup, disp first menu, shutdown, etc.

Dictionary 2 Berdasarkan urutan alphabet dengan nama komponen, berikan nomor yang tetap, dan penjelasan singkat untuk setiap modul. Contoh : A0000000 AM000000 AMST0000

BAB 7

0.0 1.0 1.1

Amalgamated Basketweaving System Menu System Startup, disp first menu, shutdown

Halaman 8 dari 22



Dictionary 3 Berdasarakan urutan alphabet dengan penjelasan singkat, berikan nomor komponen dan nama yang tetap. Contoh : Amalgamated Basketweaving System 0.0 A0000000 Menu System 1.0 AM000000 Startup, disp first menu, shutdown 1.1 AMST0000 Kamus Data Umum (The Common Data Dictionary / CDD) Daftar alphabet menyusun semua parameter yang ditunjukkan pada tanda panah aliran data. Untuk setiap item menjelaskan tipe, panjang, batasan, dan modul yang digunakan. CDD ini kemudian akan berisi semua parameter lainnya yang didefinisikan pada level terendah dari pemrograman dan disain, sebagaimana field didefinisikan dalam sebuah file. CDD menjamin bahwa parameter akan konsisten berlaku dlam seluruh sistem.

t e N

a r d

7.7. MODUL TERSTRUKTUR, ATAU SEJAUH MANA ANDA DAPAT MERINCINYA ? (Structured Modules, Or How Far Do You Break It Up ?)

By

n e H

Sebuah modul terstruktur memiliki ciri-ciri sebagai berikut : 1. Berfungsi sepenuhnya sebagai fungsi tunggal. Misalnya dapat diterima, diedit, diformat ulang dan melewati parameter tunggal. 2. Ukurannya kecil. Ukuran yang ditetapkan berkisar antara 50 – 100 baris yang dapat dieksekusi atau paling banyak 2 halaman. 3. Dapat diprediksi. Semua ciri dapat terlihat dengan membaca kode program. Hal ini tidak dipengaruhi oleh kode tersembunyi dalam modul lain atau dalam sistem operasi. 4. Tidak tergantung (Independent) Perubahan dalam modul atau parameter tidak mempengaruhi sistem.

BAB 7

Halaman 9 dari 22



5. Meskipun hal ini tidak didefinisikan secara jelas dalam modul terstruktur, lihatlah kegunaannya kembali – suatu modul yang cukup lengkap dan umum mengakibatkan anda dapat menggunakannya pada aplikasi lain dengan memodifikasi sedikit mungkin. 7.8. DISAIN FILE (FILE DESIGN) Dapatkan kinerja yang sesungguhnya (Getting Real Performance) Anda mulai mendisain file dengan melihat hasil dari fase analisis, kebutuhan-kebutuhan dan disain level atas yang sejauh ini dihasilkan. Hasilnya akan tampak seperti item-item kotak pada gambar 7.6.

t e N

a r d

By

n e H

Sebagai contoh, persyaratan “Pendaftaran seorang siswa pada kursus tertentu” akan menghasilkan penambahan dalam daftar field disamping masing-masing kotak pada gambar 7.6. Jika STUDENT INFO dan COURSE INFO adalah file yang terpisah, mereka akan dihubungkan dengan sebuah key. Tambahkan key STUD_NO dan CRS_NO dan logika akses dapat digambarkan dengan tanda panah, seperti pada gambar 7.7.

BAB 7

Halaman 10 dari 22



Sekarang kita dapat menangani pendaftaran siswa sebaik-baiknya, seperti : “Memberikan nama siswa, mencari kursus apa saja yang ia ikuti” (akses file STUDENT FILE dengan nama, kemudian CRS_NO, lihat COURSE FILE dengan CRS_NO tersebut). Diagram dilanjutkan sampai semua pernyataan terpenuhi. Hasilnya dapat digambarkan pada gambar 7.8.

t e N

a r d

By

BAB 7

n e H

Halaman 11 dari 22



Mengoptimalkan File (Optimizing Files) Langkah selanjutnya adalah mengoptimalkan penyimpanan disk dengan mengurangi kerangkapan field-field dan file-file. Pada STUDENT FILE, jika banyak siswa mempunyai alamat yang sama, seperti perusahaan yang sama, field alamat akan terulang. File ADDRESS dengan satu record setiap perusahaannya dan COMPANY_NO di record siswa menunjukkan hal itu. File ini juga dapat berisi alamat faktur yang dibutuhkan oleh FINANCE FILE. Pada COURSE FILE item seperti DESCRIPTION, INSTRUCTOR, dan MATERIAL NO akan selalu terulang setiap mereka kursus di tempat yang sama. Kemudian file ini dipecah menjadi file baru yang bernama SCHEDULE FILE yang mempunyai item unik untuk setiap kursus yang dimulai, dan membiarkan COURSE FILE hanya sebagi informasi.

t e N

FINANCE FILE hanya dapat ditandai dengan STUD_NO atau COURSE_NO. Sudah ada beberapa file yang menggunakan key tersebut, yang biasanya menunjukkan field tersebut dalam file ini dapat digabungkan ke dalam file lain, jika informasi pembayaran dan tagihan akan digabungkan dengan siswa. FINANCE FILE tidak diperlukan. Hasil disain file dapat dilihat pada gambar 7.9.

a r d

By

BAB 7

n e H

Halaman 12 dari 22



t e N

a r d

n e H

Mengoptimalkan Sejumlah Variabel Item-item (Optimizing a Variable Number of Items)

y B Dalam STUDENT FILE terdapat 2 field, informasi CRS_NO dan PYMNT, yang diulang untuk masing-masing kursus dari siswa yang mendaftar. Dengan cara yang sama akan diulang field-field dalam file SCHEDULE dan COURSE. Hal ini dapat diatasi dengan membuat program yang menggunakan file yang mempunyai ukuran yang berubah-ubah. Panjang dari sebuah record berubah sesuai dengan penambahan maupun penghapusan sebuah item. Metode ini dapat menghemat ruang penyimpanan. Dalam hal lain, jika jumlah maksimum dari suatu variabel diketahui, maka dapat digunakan record yang memiliki panjang yang tetap. Sebagai contoh, jika suatu bidang kursus tidak akan pernah diambil oleh lebih dari 30 siswa, maka jumlah record di file SCHEDULE disediakan untuk 30 siswa. Metode ini menggunakan ruang penyimpanan yang lebih besar dari metode pertama, namun metode BAB 7

Halaman 13 dari 22



ini membutuhkan waktu proses yang lebih singkat. Selain itu record dengan ukuran tetap lebih mudah untuk didisain, dimengerti, dan dalam hal pemeliharaannya dibandingkan dengan record yang memiliki panjang yang berubah-ubah. Karena harga media penyimpanan yang semakin murah saat ini, maka disarankan untuk menggunakan record yang memiliki ukuran tetap jika memungkinkan. Sebuah masalah dapat muncul jika batasan tidak dapat ditentukan. Sebagai contoh, Mengapa jumlah siswa di setiap bidang kursus tidak dapat dibatasi dengan jumlah yang sama ? Untuk mengatasi hal ini dapat dibuat suatu file lain yang hanya digunakan untuk menyimpan informasi yang tidak tetap. File ENROLLMENT dapat dibuat untuk setiap bidang kursus, dan setiap file akan berisi satu record per satu siswa yang mendaftar per kursus, seperti pada gambar 7.10. Hal ini mungkin membutuhkan biaya yang besar, baik dalam hal media penyimpanan maupun pemeliharaan file.

t e N

a r d

By

n e H

Cara sederhana untuk menangani masalah tersebut adalah dengan membuat sebuah file yang disebut ENROLLMENT yang akan berisi record untuk setiap siswa yang mendaftar per kursus. Field-field yang digunakan hanya STUDENT_NO dan COURSE_NO. File Histori (History Files) Apa yang kita lakukan tentang data pada siswa-siswa yang telah mengambil sebuah kursus ? Pemecahan masalah ini dengan mendefinisikan sebuah file STUDENT_HISTORY dan setelah seorang siswa mengambil sebuah kursus, recordnya dipindahkan dari file STUDENT ke File Histori.

BAB 7

Halaman 14 dari 22



Pengujian Disain File (Testing The File Design) Pada disain ini, setiap permintaan kebutuhan yang melibatkan pengaksesan data harus “diproses” dengan disain file. Hal ini menandai perkembangan selanjutnya. Contoh : “Tampilkan semua peristiwa pada tempat pelatihan XYZ, lokasi dan biayanya”. Mari kita mengikuti logika pengaksesannya. Register mengubah nama bidang kursus menjadi CRS_NO. Record-record pada file SCHEDULE diakses oleh CRS_NO untuk mendapatkan biaya. Dalam permintaan yang umum seperti ini, mungkin nama bidang kursus dapat dijadikan “key” pada file SCHEDULE. Mungkin harga dapat ditambahkan ke file SCHEDULE untuk mengurangi pengaksesan file COURSE setiap waktu. Untuk menghemat ruang penyimpanan, kode biaya dapat digunakan.

t e N

7.9. SISTEM MANAJEMEN DATA BASE RELATIONAL (RELATIONAL DATA BASE MANAGEMENT SYSTEM / RDBMS)

a r d bahwa anda mendapatkan Pada bagian 7.8. kita mengasumsikan n efile yang mengandung sebuah kunci. sebuah record dari sebuah H Dalam kenyataannya, y B harus terdapat DBMS untuk memenuhi hal ini. Gambar 7.11 adalah contoh dari suatu relasi (tabel) yang dapat didefinisikan pada sistem ABC. Student Relations : Stud-No Stud-Name 1 John Blake 2 Jane Smith

Company-No 999 999

Run of a Course Relations : Course-No Course-Date 123 1/1/90 123 1/2/90

BAB 7

Location Instructor Cost Ottawa Rakos 1000 New York Rakos 1500

Halaman 15 dari 22



Enrollment Relations : Stud-No Course-No 123 1

Pymnt 0

Course Relations : Course-No Crs-Name 123 Weaving

Desc Intro

Mat-No 001

Company Relations : Comp-No Addr Ship-To 999 First ST. X Y

Bill-To AB

Tot-Owing 10000

Material Relations : Desc Mat-No 001 Straw

Source X Co

Cost 1.00

Whse 1-1

Gambar 7.11 Relasi pada Data Base Relational ABC

t e N

Bentuk untuk jenis database query khusus ini sudah distandarisasi, dan ini disebut Structured Query Language (SQL). Sebagai contoh, berikut ini adalah instruksi SQL untuk menampilkan kursus apa saja yang diikuti oleh “Smith”.

a r d

By

n e H

SELECT CRS-NAME FROM COURSE WHERE COURSE-NO IN SELECT COURSE-NO FROM ENROLLMENT WHERE STUD-NO IN SELECT STUD-NO FROM STUDENT WHERE STUD-NAME = ‘Smith”

Sayangnya SQL yang dibuat oleh IBM memiliki banyak kekurangan sehingga produk-produk baru mempunyai perluasan bahasa untuk menyediakan keistimewaan tambahan. Anda dapat melihat banyak bahasa 4GL yang baru (yang mendukung Query By Example [QBE]) untuk mengisi formulir di bawah ini :

BAB 7

Halaman 16 dari 22



STUD_NAME CRS_NAME

= =

Smith --------------------------------------------------------“ “

Kelebihan utama dari RDBMS adalah fleksibilitasnya. Sebagai contoh : jika kita ingin mengakses data yang sejenis secara berlainan dari berbagai aplikasi, maka sistem ini akan dapat menampungnya. Kekurangan RDBMS hanya pada performance. Membutuhkan banyak memori dan waktu untuk menyimpan, menjalankan dan merinci seluruh bagian tabel.

t e N

a r d oleh pemakaian yang mudah Penghematan waktu yang diakibatkan n e dan fleksibilitas dari sistem, membuat RDBMS yang terdapat pada H sebuah komputer (CPU) By yang baik sebagai investasi yang berharga. 7.10. KEUNTUNGAN DARI ANALISIS & DISAIN YANG TERSTRUKTUR (BENEFITS OF STRUCTURED ANALYSIS AND DESIGN) Mengurangi Jumlah Kesalahan (Reducing the Number Of Initial Errors) Tabel statistik berikut ini diambil dari hasil survei oleh TRW untuk proyek besar, dan DEC’s Customer Services Systems Engineering (yaitu departemen yang bertanggung jawab untuk memastikan bahwa produk-produk DEC baik software maupun hardwarenya benar-benar bebas dari virus).

BAB 7

Halaman 17 dari 22



Menggunakan metode tidak terstruktur :

Effort Spent : Problem Introduced : Problems Found : Dollars Spent (AVG) (Total = 250 K)

Analysis and Design

Remaining Phase

After Operation

10 % 64 % 19 % 25 K

23 % 36 % 27 % 57.5K

67 %

Analysis and Design

Remaining Phase

After Operation

20 % 32 % 30 % 40 K

50 % 68 % 33 % 50 K

54 % 167.5 K

Menggunakan metode terstruktur :

Effort Spent : Problem Introduced : Problems Found : Dollars Spent (AVG) (Total = 190 K)

By

N

a r d

n e H

et

30 % 37 % 100 K

(1) Bagan di atas adalah setengah dari biaya sebelumnya Gambar 7.12. Causes and costs of problems Gambar 7.12 menunjukkan bahwa meskipun biaya dimuka mengalami kenaikan, metode terstruktur tetap mengurangi biaya sistem secara keseluruhan.

7.11. PROSES DISAIN (THE DESIGN PROCESS) Tim Disain (The Design Team) Pilihlah orang-orang terbaik untuk tim disain. Tim disain yang baik tidak perlu orang yang menguasai bahasa pemrograman. Mereka haruslah orang yang dapat mengkonsep semuanya. Hindari orang-

BAB 7

Halaman 18 dari 22



orang yang selalu menginginkan kesempurnaan (perfectionis) dalam tim disain. Pertemuan Disain (The Design Meeting) Merancang sesuatu mirip dengan urun remuk (brainstorming) : beberapa orang berkumpul dalam suatu ruangan yang tenang dan tidak terganggu. Setiap orang diharapkan untuk mengeluarkan semua ide mereka agar semua elemen yang berfungsi dapat digunakan dan juga memikirkan bagaimana cara menguasainya. Tulis semua ide yang ada, dan kemudian akhirnya ide-ide yang ada disusun ke dalam modul-modul yang unik.

7.12. DOKUMENTASI TEKNIK (TECHNICAL DOCUMENTATION) Pertimbangkan hal-hal berikut ketika menulis dokumentasi teknik : 1. Gunakan bahasa yang formal dan tepat. 2. Gunakan gambar, diagram yang terstruktur dan yang sejenisnya. 3. Buatlah agar maksud dari disain menjadi jelas pada beberapa halaman pertama. Kemudian uraikan. 4. Cobalah untuk konsisten pada grafik-grafik dan struktur kalimat.

t e N

a r d

By

n e H

7.13. STANDAR KETENTUAN PADA WAKTU DISAIN (STANDARDS ‘DICTATED’ AT DESIGN TIME) Buatlah aturan yang standar seperti berikut : 1. Beberapa ketentuan disain. Format struktur diagram, modul dan kaidah penamaan variabel ini digunakan untuk semua tingkatan yang rendah. 2. Parameter yang mendahului. Rincian perintah, panjang, format / tipe. 3. Penanganan kesalahan. Setiap modul melewati keadaan dimana kesalahan muncul dan nomor kesalahan untuk ditangani. 4. Standar pemrograman. Standar pemrograman terstruktur seperti pemunculan kode (white space, memasukkan, komentar-komentar), konsep yang BAB 7

Halaman 19 dari 22



diperbolehkan, organisasi, ukuran modul, dan ketergantungan secara rinci. Membuat ‘template’ yang berisi komentar seperti : - judul - parameter-parameter (penerima, pengirim) - masukkan (hanya satu) - variabel yang digunakan - memanggil subroutine - penanganan kesalahan - exit (hanya satu) 5. Programmer memulai dengan template ini dan mengisikan kode proses. Lihat bagian 9.4 untuk alat pemrograman yang membantu format program secara tetap. 7.14. GARIS BESAR SPESIFIKASI DISAIN (OUTLINE OF THE DESIGN SPECIFICATION)

t e N

Spesifikasi disain terdiri atas : 1. Judul halaman dan daftar isi 2. Gambaran umum (Overview) 3. Daftar hardware / software yang akan dipakai 4. Daftar urutan prioritas disain 5. Diagram disain dan beberapa modul dictionary yang umum 6. Beberapa kebiasaan penamaan modul yang umum 7. Parameter yang dipakai dan Data Dictionaries 8. Penanganan kesalahan. Jelaskan bagaimana kesalahan akan ditangani 9. Standar pemrograman terstruktur 10.Alat pemrograman terstruktur 11.Top Level Design. Termasuk struktur diagram TLD 12.Medium Level Design. Termasuk struktur diagram MLD 13.Modul dan kamus data 14. File dan Tabel

a r d

By

n e H

7.15. MENGUJI DISAIN (TESTING THE DESIGN) Ketika disain telah diselesaikan, semuanya harus berjalan dengan benar. Maksudnya adalah untuk menjamin hal-hal berikut ini : 1. Semua keperluan Spesifikasi Fungsi sudah ketemu. BAB 7

Halaman 20 dari 22



2. Disain mudah diprogram dan dipelihara. 3. Dapat diimplementasikan sesuai dengan waktu dan anggaran. 7.16. MERUBAH PERMINTAAN SESUAI DENGAN DISAIN (CHANGES TO REQUIREMENTS DUE TO DESIGN) Beberapa disain yang rinci akan selalu membawa pada perubahan permintaan. Anda harus kembali kepada user sekarang dan meyakinkan user bahwa dia sebenarnya tidak menginginkan apa yang dia minta sebelumnya. 7.17. PERENCANAAN PENERIMAAN (PLANNING THE ACCEPTANCE) Meskipun penerimaan adalah tahapan pada bab tersendiri nantinya, perencanaan penerimaan dapat dimulai setelah disain level menengah dikerjakan.

t e 7.4. DISAIN SIAP PAKAI (DESIGN WALK-THROUGHS) aN r d diantara beberapa pendekatan Ketika hendak mengambil keputusan n e lebih mudah mengambil keputusan teknis terhadap suatu masalah, H dengan meminta pendapat By orang lain. Adakan pertemuan dengan beberapa ahli untuk melakukan TLD siap pakai. Tujuan dari pertemuan itu adalah memilih TLD yang terbaik.

BAB 7

Halaman 21 dari 22



Kisah Tentang Perang Disain Cerita ini melibatkan dua orang pemuda yang menjadi sahabat karib ketika mereka mengikuti kuliah Ilmu Komputer pada sebuah universitas terkemuka di Ontario, Kanada. Setelah lulus yang satu menjadi menjadi seorang Manajer Pemrosesan Data pada sebuah perusahaan penerbitan terkenal, dan yang satu menjadi seorang perancang sistem pada Famous Minicomputer Manufacturing Company (FMMC). Beberapa tahun kemudian perusahaan penerbit memutuskan untuk memasang komputer baru untuk sistem pengolahan. Manajer Pemrosesan Data tidak mamapu menangani beban pekerjaan itu sendiri, maka ia menyewa temannya dari FMMC untuk mengerjaka desain dan program. Setelah mereka mengerjakan top level desain bersama-sama, mereka membagi modul utama, yang masing-masing mengerjakan desain medium level dari modul-modul yang spesifik. Perancang dari FMMC mendesain modul yang pertama. Untuk menunjukkan kehebatan desainnya pada temannya, ia membuat rancangan itu dengan sangat “bagus” untuk menghemat sedikit byte dari media penyimpanan atau beberapa nanodetik dari waktu CPU. Ia bahkan menambahkan sedikit “keistimewaan” tersendiri : sesuatu yang tidak seorangpun meminta atau mengerti atau pernah menggunakannya.

t e N

Si Manajer Pemrosesan Data menanggapinya dengan mendesain modul yang kedua. Ketika dia melihat rancangan hebat milik temanya, ia mengatakan “saya dapat membuat yang lebih bagus dari itu”. Lalu ia membuat modulnya sedikit lebih bagus dari modul temannya, dan menambahkan sedikit “suara bel dan melodi-melodi” pada modulnya. Ia mengerjakan lebih lama dari jadwal yang ditentukan dan modulnya menjadi lebih besar dari rencana. Si perancang tertantang untuk membuat modul yang ketiga yang lebih “sempurna” dengan menambah lebih banyak lagi suara bel-bel dan melodi sampai modul menjadi dua kali lebih besar dari seharusnya. Dan perlombaan terus berlanjut sampai mendesain sebagus mungkin tahap pemrograman.

a r d

By

n e H

Sistem tersebut dibuat untuk 16 orang user. Ketika sistem akhirnya berjalan (50% terlambat) sistem bekerja baik sampai 4 orang user. Ketika 6 orang user bekerja, sistem menjadi sangat lambat, dengan 8 orang user sistem crash – program menjadi sangat besar untuk dapat ditangani oleh sistem. Komentar : Orang teknis dapat terbawa dengan tantangan teknis. Selalu banyak jalan yang baik untuk menyelesaikan masalah, tapi tantangan harus menghasilkan tujuan, yaitu waktu dan biaya. Penutup : FMMC memberikan CPU yang besar kepada perusahaan penerbit tanpa biaya.

BAB 7

Halaman 22 dari 22



BAB 8 RENCANA TES PENERIMAAN 8.1. PENDAHULUAN 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 ?

t e N RUN 8.2. PERIODE PERCOBAAN ATAU PARALLEL a r (THE TRIAL PERIOD OR PARALLEL d RUN) n e H Periode percobaan atau parallel run adalah pendekatan yang paling y Menggunakan pendekatan ‘Periode umum untuk penerimaan. B 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.

BAB 8

Halaman 1 dari 8



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.

t e N

a r d

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

By

n e H

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. Jika sebuah tes gagal, Tim proyek dengan penuh harapan memperbaiki masalah langsung di tempat pengujian. Jika itu masalah utama maka tes ditunda sampai masalah dapat diperbaiki. Dalam teori hanya tes yang gagal yang diulang, walaupun user memiliki hak untuk menjalankan kembali tes yang diterimanya sesudah perbaikan. Serangkaian tes dan perintah yang dijalankan sistem disebut Rencana Tes Penerimaan (Acceptance Test Plan / ATP).

BAB 8

Halaman 2 dari 8



Pendekatan ini mempunyai manfaat sebagai berikut : 1. Anda dapat mendemonstrasikan semua fungsi yang dijanjikan. 2. Sebuah tindakan yang menyebabkan masalah selalu diketahui – anda mengetahui dengan tepat siapa yang mengetik ketika masalah terjadi. 3. User tidak merasa takut tentang semuanya. Kerugian utama dari pendekatan ini adalah memerlukan banyak pekerjaan untuk menulis ATP. Dan lagi user mungkin tidak lazim dengan pendekatan ini. Tetapi anda dapat membiasakan mereka dengan metode baru sebelumnya. Cantumkan laporan singkat dalam proposal, yang merupakan sebuah dokumen yang ditandatangani. Selengkapnya ada dalam Spesifikasi Fungsi, dokumen lainnya yang ditandatangani. Dia akan selalu melihat dan menyetujui ATP sebelum penerimaan. Seharusnya tidak ada keengganan untuk menerima dan membayar jika metode ini digunakan.

t e N

a r d

n e H

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

By

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. Perhatikan tabel seperti gambar 8.1 berikut ini :

BAB 8

Halaman 3 dari 8



FS FUNCTION TO BE TESTED REF SEC/PAR 3.1 3.2 3.3 7.7 10.2

TEST METHOD

Main menu appears at start-up Registrar menu appears when… Manager menu appears when… Store 10.000 student records Students by course by city report

TEST NUMBER

T T T I T,A

1.0 2.1 2.2 7.8 4.5

T – test I – inspection A – Analysis (Hand calc,or use another pgm) N/A – not applicable Gambar 8.1. Functions vs tests table

t e N

Catatan : ada beberapa hal dalam daftar tersebut tidak dites (N/A).

a r d

n e H

8.5. MENGGUNAKAN DISAIN (USING THE DESIGN)

By

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. Anda dapat menjalankan tes pada perintah atas bawah yang sama seperti TLD, yang dapat dimengerti dengan baik oleh user anda. Pendekatan sistem ABC seperti dalam TLD (gambar 7.1), anda dapat mendemonstrasikan semua menu, kemudian seluruh keterangan yang diminta, diikuti dengan semua update, dsb. Cara lain untuk mengelompokkan kumpulan tes adalah dengan fungsi. Melalui semua fungsi Registrasi, diikuti oleh fungsi Administrator, dsb.

BAB 8

Halaman 4 dari 8



8.6. MENULIS PERCOBAAN (WRITING TEST) Anda sudah siap menentukan bagaimana anda akan menguji item ketika pengisian pada METODE PERCOBAAN seperti pada gambar 8.1. di atas. Berikut ini (gambar 8.2) adalah contoh percobaan nomor 4.5., laporan ‘Students by Course by City ‘. [Catatan dalam tanda kurung siku-siku tidak ditampilkan – ini adalah keterangan].

t e N

a r d

By

BAB 8

n e H

Halaman 5 dari 8



TEST NO: 4.5 TEST PURPOSE: F.S. REFERENCE (SEC/PAR): SETUP:

INPUT:

OUTPUT:

INPUT:

Demonstrate the production of the Students by Course by City report. 10.2, 12.8, 11.3 [Note how one test can demonstrate several functions.] Ensure files STUDENT.DAT and COURSE.DAT contain data.Star system. Choose Selection 1. From Main Menu using mouse click and drag method. “CHOOSE REPORT TYPE’ menu (format per FS pg 17, Figure 8.15) appears. [Refer to the Functional Spec. whenever possible.] Choose Selection 5. (Students by Course by CIty report) by UP/DOWN arrow anda RETURN method. Message ‘Report being prepared.’ Appears. No longer than 60 seconds later, message ‘Report being printed’ appears and printer starts printing. The terminal can be used to enter any other command. User will try up to 3 commands of his choice. [There is danger in stating, “User may type any number of commands.”He just may!] When the report is complete (printer stops,) inspect it to ensure it is of format FS pg.23,Figure 12.12. Total columns will be checked by hand calculated addition of the attendance figures printed.

t e N

OUTPUT:

a r d

By

n e H

USER SIGNATURE PROJECT TEAM SIGNATURE DATE COMMENTS

Gambar 8.2. Typical test

BAB 8

Halaman 6 dari 8



8.7. DAFTAR RENCANA TES PENERIMAAN (THE ACCEPTANCE TEST PLAN CHECKLIST) Gunakan hal berikut sebagai daftar pengecekkan untuk semua kegiatan yang diperlukan untuk 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. Klien mengetahui bahwa keberhasilan penyelesaian dari percobaan akan mempengaruhi penerimaan sistem. Lihat bentuk contoh ATP pada bagian 10 di Appendix A. • Tanggung jawab untuk percobaan data telah ditetapkan. Data untuk percobaan seharusnya disediakan oleh tim proyek dan juga user. Jika user dapat menyediakan data yang sesuai dengan keadaan yang sebenarnya, percobaan terhadap sistem akan berjalan dengan baik, ditambah user akan merasa nyaman dengan keakuratan percobaannya.

t e N

a r d

By

n e H

8.8. KESIMPULAN UNTUK RENCANA TES PENERIMAAN (CONCLUSION TO THE ACCEPTANCE TEST PLAN) Anjurkan user untuk menulis ATP jika dia mampu. Hal ini akan memberikan dia perasaan mengawasi – tim proyek harus membangun sistem melalui percobaan. Anda dapat melakukan tes penerimaan secara berlebihan. Membandingkan biaya tes dengan biaya risiko itu adalah suatu masalah. Anda dapat tidak melakukan semua percobaan, khususnya dalam sistem multi-user yang interaktif.

BAB 8

Halaman 7 dari 8



8.9. KESIMPULAN UNTUK TAHAP DISAIN (CONCLUSION TO THE DESIGN PHASE) Pada akhir tahap disain kita menempuh beberapa kejadian penting sebagai berikut : 1. Dokumen Spesifikasi Disain memuat disain akhir tingkat atas melalui disain tingkat menengah. 2. Tanggung jawab ATP disahkan dan dimulai. Ini tidak perlu diselesaikan sampai tahap penerimaan. 3. Rencana proyek, khususnya perkiraan perlu ditinjau kembali. Walaupun anda sedang memperkirakan hanya 4 tahap yang telah disebutkan, tahap pemrograman mungkin akan menjadi tahap yang sangat mahal dan membutuhkan waktu yang sangat banyak dalam keseluruhan kerja proyek. Disain memberikan anda perkiraan perhitungan jumlah modul-modul dan kerumitannya. Sekarang anda mungkin tahu siapa programmer-programmer yang dapat diandalkan, sehingga anda dapat mempertimbangkan faktor produktivitas mereka. Dengan informasi ini waktu pemrograman yang diperlukan dapat dengan mudah diperkirakan (lihat BAB 13). Statistik menunjukkan bahwa pada akhir tahap disain diperkirakan seharusnya tidak lebih dari 10%.

t e N

a r d

By

BAB 8

n e H

Halaman 8 dari 8



BAB 9 FASE PEMROGRAMAN 9.1. PENDAHULUAN Pemrograman adalah merupakan bagian yang paling mudah – itulah yang kita sangat kenal sebagai tipe-tipe teknik. Pada kenyataannya, sebagai Manajer Proyek anda mungkin menemukan cara sendiri untuk mengendalikan staf anda dari memulai program yang terlalu cepat. Selalu ada tekanan untuk melakukan sesuatu dengan benar, tidak hanya dari tim proyek, tetapi dari manajemen tingkat tinggi. Aktifitas-aktifitas pada fase ini adalah menulis program. Kejadian pentingnya adalah menguji program, Rencana Tes Sistem, dan paling tidak mulai pada Dokumentasi User.

t e N

a r 9.2. DAFTAR PEMERIKSAAN PEMROGRAMAN d n (PRE-PROGRAMMING e H CHECKLIST) Sebelum anda memulai Bypemrograman, jawablah pertanyaan berikut : • Apakah pemeriksaan disain memerlukan pengerjaan kembali ? Jika ya, jadwalkan waktu mulai dan penundaan pemrograman. • Apakah sumber daya yang direncanakan dan programmer masih tersedia ? Jangan terlalu optimis dengan proyek orang lain yang selesai tepat waktu. Jika ada pergantian staf, apakah anda akan menguji kembali produktifitas mereka ? • Apakah orang-orang ini telah dilatih ? Programmer harus mengetahui tentang sistem operasi, bahasa pemrograman, program paket, dan alat-alat pemrograman yang akan digunakan. Mereka juga harus mengenal dengan baik aplikasi user dan masalah bisnis. Pastikan bahwa mereka telah membaca Requirement Document dan Functional Specification. BAB 9

Halaman 1 dari 17



• Apakah lingkungan pemrograman cukup baik ? Anda membutuhkan kemudahan untuk menggunakan software pengembangan dan alat-alat pemrograman. (Lihat bagian 9.4). Komputer pengembangan harus mempunyai respon yang cepat, harus tersedia ketika diperlukan, dan harus dapat diandalkan.

9.3. LANGKAH-LANGKAH PEMROGRAMAN (THE PROGRAMMING STEPS) 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. Bab 9 ini merinci beberapa metode untuk menggabungkan bagian-bagian tersebut, tetapi anda harus merencanakan urutan penggabungan ini sekarang, karena anda harus menulis program supaya dapat digabungkan. Ini disebut Rencana Tes Sistem (System Test Plan).

t e N

a r d

n e H

y B 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. Level disain modul tingkat menengah dapat dilihat pada gambar 9.1.

BAB 9

Halaman 2 dari 17



t e N

a r Lihat Gambar 9.1. Medium d level desin (3 level) n He modul dari perancang Programmer menerima penjelasan berikut ini. By rd

BAB 9

seperti

Halaman 3 dari 17



Programmer pertama-tama menggambarkan diagram struktur dari modul. Terlihat seperti pada gambar 9.2.

Lihat Gambar 9.2. Fourth level module breakout

t e N

Disain modul adalah pendekatan top-down dimulai dengan kotak paling atas, AMST000 dan dipecah ke dalam sub-komponen yang tepat, seperti pada gambar 9.3.

a r d

By

n e H

Lihat Gambar 9.3. Fifth level module breakout

BAB 9

Halaman 4 dari 17



Kemudian setiap sub-komponen dapat dibagi lagi, seperti pada gambar 9.4.

Lihat Gambar 9.4. Sixth level module breakout Dan kemudian modul tersebut dipecah lagi sampai tercapai sebuah tingkatan dimana mulai dapat diprogram.

t e N

a r Pertanyaan yang bisa diajukan adalah d : “Pada tingkatan mana disain n sistem berhenti dan disain modul e dimulai ?”. Jawabannya adalah H “Disain sistem dipecah sampai pada tingkat dimana programmer ByTingkatan ini dapat bermacam-macam dari dapat memulainya”. proyek ke proyek dan bahkan dari satu bagian sistem ke bagian lainnya – tergantung pada programmer yang menerima bagian tersebut. Adapun pertimbangan lainnya adalah : • Jika pemecahan modul yang dihasilkan adalah sangat penting yang memerlukan prioritas seperti adanya respon, user-friendly atau konsistensi, perancang bisa melanjutkan ke tingkat yang lebih rendah. • Tingkat pemecahan dari disain dinyatakan dengan kontrak.

BAB 9

Halaman 5 dari 17



• Jika programmer tidak mengetahui pada waktu disain, pengetahuan programmer tingkat menengah dapat diasumsikan, dan disain dapat diambil alih oleh programmer tingkat menengah yang dapat mengatasinya. Tetapi perlu diingat bahwa programmer tidak senang menerima disain yang terlalu rinci, yang programnya adalah menerjemahkan bahasa Inggris yang sederhana, seperti pernyataan-pernyataan secara harafiah ke dalam bahasa pemrograman.

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.

t e N

a r d

By

n e H

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.

BAB 9

Halaman 6 dari 17



Langkah 5. Kode Setiap Modul (Code Each Module) Standar pengkodean akan ditetapkan pada saat disain sistem (lihat bagian 7.12). 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).

t e N

Langkah 6. Menguji Modul (Test The Module)

a r d menetapkan lingkungan yang Programmer menguji modul dengan n einput, membiarkan modul langsung tepat, menyediakan beberapa H memproses secara logik dan mendapatkan hasilnya. Beberapa input y B 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.

BAB 9

Halaman 7 dari 17



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

t e N

8. Menyimpan Semua Hasil Pengujian; Penggabungan Modul-modul Yang Telah Diuji (Save The Results Of All Tests; Submit Finished Modules To Integration)

a r d

n e H

y Bdigunakan

Hasil pengujian 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 (lihat bagian 9.4).

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. BAB 9

Halaman 8 dari 17



Dokumen-dokumen berikut mungkin harus ditulis : Tuntunan Pemakai (User’s Guide) Dokumen ini dapat ditulis oleh programmer, penulis teknis atau bahkan user sendiri. Tampilkan kembali FS yang mempunyai bagian rinci mengenai menu, layar, form, dan user interface lainnya. USER’S GUIDE yang baik adalah terbagi dalam bagian-bagian yang menunjukkan tingkatan user yang berbeda-beda. Sebagai contoh, dalam USER’S GUIDE sistem ABC, harus ada bagian yang disebut “Registrar’s Functions” atau “Warehouse Functions” atau lainnya. Materinya harus disesuaikan agar user dapat menggunakan secara normal. Hal ini membuat USER’S GUIDE berguna untuk mempelajari sistem.

t e N

Urutan popular lainnya untuk USER’S GUIDE adalah menelusuri menu-menu perintah secara logika. Pada akhir dari USER’S GUIDE ini disediakan referensi dari setiap perintah, menu, form dan pesan yang ditampilkan secara alphabet.

a r d

By

n e H

Tuntunan Pemeliharaan (Maintenance Guide) Bagaimana anda menemukan programmer untuk merinci dokumen dari program mereka untuk pemeliharaan berikutnya ? Kebanyakan Manajer proyek mengalami kesulitan dalam hal berikut : programmer enggan untuk melakukan dokumentasi sebelum program ditulis; dan beruntunglah menemukannya setelah semuanya selesai dikerjakan. Programmer berpikir bahwa pemeliharaan memerlukan penjelasan secara rinci dari logika pemrograman. Sangat membosankan untuk menulisnya dan sebenarnya tidak perlu. Berikut ini adalah solusi sederhana tentang hal tersebut : lebih baik merinci spesifikasi disain tingkat modul secara struktur, mendokumentasikan sendiri kode, dirasa cukup untuk pemeliharaan sistem.

BAB 9

Halaman 9 dari 17



MAINTENANCE GUIDE akan berisi spesifikasi disain, listing program dan penjelasan bagaimana semuanya disesuaikan, bagaimana mengubah pendekatan, dan bagaimana menghubungkan dan menguji semuanya. Tuntunan Operator / Tuntunan Manajer Sistem (Operator’s Guide / System Manager’s Guide) Sama seperti USER’S GUIDE untuk orang-orang yang menghidupkan sistem di pagi hari, mematikannya, melakukan backup, menangani permasalahan utama, melakukan perhitungan, dsb. Dokumentasi yang disediakan oleh perusahaan hardware dan sistem operasi mungkin cukup – hanya prosedur untuk software tertentu yang harus ditulis ulang. Dokumentasi Pelatihan (Training Documentation)

t e N

Jika anda akan memberikan kursus bagaimana menggunakan sistem, rencanakan apakah materi pelatihan akan diperlukan. USER’S GUIDE yang baik harusnya menambahkan hal ini. Anda mungkin harus membuat bantuan pelatihan, seperti transaparansi, buku latihan, pengujian, dsb.

a r d

By

n e H

9.4. PERALATAN PROGRAM (PROGRAMMING CASE TOOLS) Berikut ini adalah produk software yang membantu programmer untuk melakukan pekerjaanya dengan lebih baik. Software ini disebut CASE (Computer Aided Software Engineering), karena membantu proses pemrograman secara otomatis. Lihar Referensi 2.1. untuk produk tersebut. Bahasa Pemrograman (The Programming Language) Bahasa pemrograman dan compiler adalah alat yang sangat penting. Jika bahasa pemrograman itu sederhana dan sesuai dengan aplikasinya programmer akan dapat mempelajarinya dengan cepat, gunakan jenis yang diperlukan secara tetap, dan lakukan BAB 9

Halaman 10 dari 17



pemrograman tanpa canggung. Compiler harus cepat dan jelas dalam menuliskan pesan kesalahan. Language Sensitive Editor (LSE) LSE menyediakan template untuk setiap pernyataan dalam bahasa pemrograman. Sebagai contoh, dalam bahasa PASCAL, user dapat mengetikkan ‘FOR’ dan LSE menghasilkan : FOR % {ctrl-var}% := %{exp}% %{TO | DOWNTO}% %{exp}% DO %{statemnets}% END;

Programmer mengisikan variabelnya dan LSE memastikan sintaksnya benar. LSE juga dapat memanggil compiler. Jika ada kesalahan yang ditemukan oleh compiler, LSE dapat mengontrol kembali, dan programmer dapat kembali ke posisi edit – pada pesan dan baris kesalahan tersebut. LSE dapat membuat program header dari template. LSE membantu dalam pemeriksaan sintaks, kompilasi program dan memastikan source format yang konsisten pada sistem.

t e N

a r d

By

Pendeteksi (Debugger)

n e H

Debugger membantu memeriksa dan memperbaiki kesalahan program. Debugger dapat memberhentikan program, menelusuri kesalahan dan memeriksa kesalahan berikutnya. Debugger yang baik dapat menyesuaikan dan menampilkan variabel pada semua titik, seperti pada pengeksekusian bagian spesifik dari program. Code Management System (CMS) Seringkali disebut manajer konfigurasi, CMS tidak tersedia untuk semua bahasa pemrograman. CMS adalah ‘perpustakaan’ yang memiliki sendiri semua sumbernya. CMS menertibkan orang–orang yang melakukan update dan memastikan tidak terjadi konflik, jika dua orang meng-update modul yang sama pada saat yang bersamaan. CMS menyimpan segala perubahan yang terjadi pada modul, sehingga segala perubahan pada modul dapat mudah dilihat. BAB 9

Halaman 11 dari 17



CMS menunjukkan adanya perbaikan atau penambahan yang mudah dengan versi-versi sebelumnya. CMS dapat menangani semua file ASCII. Oleh karena itu CMS berguna tidak hanya untuk menelusuri file-file sumber, tapi juga untuk menyimpan file dokumentasi, file pengujian, dan file-file untuk membangun sistem. Module Management System (MMS) MMS digunakan untuk proses compile dan link secara otomatis atau membangun sebuah sistem. MMS hanya dapat membangun kembali semua komponen tersebut yang diubah sejak pembangunan yang terakhir. MMS dapat digunakan untuk menjalankan secara otomatis sekumpulan pengujian modul. MMS sangat berguna ketika anda membangun sebuah ‘release’ sistem : menyatukan sumber-sumber yang benar dan meng-eksekusi image, seperti seluruh dokumen yang terdapat dalam satu paket. MMS bekerja hand-in-hand dengan CMS dimana semua sumber, file-file dokumen dan file-file perintah yang diproses MMS dapat disimpan.

t e N

a r d

By

Test Manager (TM)

n e H

TM digunakan untuk menguji sebuah modul secara otomatis. Untuk menggunakan TM, anda harus mendefinisikan serangkaian pengujian terhadap modul. TM akan menjalankan pengujian, dan memberitahukan programmer jika hasilnya bebeda dengan yang diharapkan.

9.5. HAK CIPTA (COPYRIGHTS) Subyek dari hak cipta software adalah tetap pada pengadilan, tetapi terdapat peraturan pemerintah yang tidak hanya merupakan bagian dari software yang memiliki hak cipta, tetapi juga berkenaan dengan hal-hal lain yang berhubungan dengan software (apapun tujuan dan artinya). Jika anda ingin melindungi kode anda, tambahkan BAB 9

Halaman 12 dari 17



pemberitahuan hak cipta pada masing-masing modul dan dokumen asli. “Copyright © 20nn, Company Name” yang biasanya diperlukan.

9.6. KESIMPULAN DARI FASE PEMROGRAMAN Berikut ini beberapa pemikiran tentang pemrograman : Pemrograman telah menjadi sebuah karya seni. Programmer diperbolehkan untuk “mengerjakan segala sesuatunya sendiri”. Hal tersebut sangat cepat ditemukan dan sangat mahal untuk melaksanakan proses tersebut. Pemrograman haruslah dipertimbangkan sebagai sebuah ilmu pengetahuan. Pemrograman adalah kesenangan tetapi debugging bukanlah kesenangan. Perhatikan pernyataan seperti “Pengkodean telah dilakukan, semua yang debug dihilangkan, sehingga 90% telah dikerjakan”. Data statistik menunjukkan bahwa programmer hanya 50% berhasil setelah pengkodean.

t e N

a r d

By

n e H

Berikut ini beberapa pemikiran tentang programmer : Programmer selalu meremehkan tugas. Mengajari mereka pesimis merupakan hal yang salah. Programmer akan menikmati pekerjaan mereka jika anda memotivasi mereka dengan sebuah tantangan. Setiap tugas harusnya lebih sulit atau berbeda dari sebelumnya. Jika anda ingin belajar bagaimana memotivasi programmer, bacalah buku G.Weinberg, “The Psychology of Computer Programming” (Referensi 14). Programmer sangat mudah tertekan, mereka akan bekerja lembur jika diperlukan. Tetapi hati-hati terhadap lembur yang tetap. Sewaktu-waktu tidak ada lagi produktifitas ekstra yang diperoleh dan programmer akan kehabisan tenaga.

BAB 9

Halaman 13 dari 17



Pada akhir fase pemrograman, lihatlah hal utama berikut ini : 1. Disain modul sudah dijalankan dan diselesaikan. 2. Program-program individual sudah selesai di-kodekan, diuji dan diselesaikan oleh pimpinan proyek. 3. Susunan dari penggabungan telah ditentukan, ditulis dalam Rencana Pengujian Sistem (dan pemrograman telah dijalankan pada saat itu). 4. Tanggung jawab terhadap dokumentasi user telah diberikan, dan jika anda beruntung hal tersebut telah dilakukan.

t e N

a r d

By

BAB 9

n e H

Halaman 14 dari 17



BAB 1O ESTIMASI (PERKIRAAN) 1O.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 dan merubah rencana pendahuluan proyek menjadi rencana akhir proyek. 1O.2. TEKNIK–TEKNIK ESTIMASI

t e N

Ada tiga teknik yang digunakan untuk melakukan estimasi, yaitu : 1. Keputusan Profesional

a r d

n e H

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.

By

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 adalah bahwa anda membutuhkan seorang ahli yang berpengalaman dalam bidang ini, dan beberapa ahli tersebut akan bekerja keras untuk mendapatkan estimasi yang tepat. 2. Sejarah

BAB 13

Halaman 1 dari 17



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. 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 :

t e N

a r d

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

By

n e H

Ada 3 tipe penginputan dengan COCOMO

VERY CMPLX

BAB 13

Halaman 2 dari 17



13.5. 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 berpengalaman untuk melakukan estimasi.

•

Lakukan estimasi secara berkelompok, menyediakan sumber daya manusianya.

•

Jangan memaksa melakukan 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. Lihat bagian 2.4. manajemen risiko.

•

jika

estimasi

yang

anda

pada

tidak

mampu

seseorang

t e N

a r d

y B jangka

Selalu berikan manajer atau klien.

n e H

waktu ketika melakukan estimasi bagi

• Gunakan naluri anda.

BAB 13

Halaman 3 dari 17



BAB 11 PENJADWALAN 11.1. PENDAHULUAN Perkiraan yang sudah diperhitungkan di dalam Bab 13 adalah banyaknya orang per-hari dari usaha yang akan diperlukan untuk membuat proyek. Hal ini disebut waktu sebenarnya (direct time). Dalam bab 13 kita lihat bahwa langkah-langkah sebenarnya dalam perencanaan sebuah proyek adalah : 1. Perencana (biasanya PM dan PL dalam suatu proyek kecil dan menengah) menjelaskan rincian struktur kerja (WBS). Seseorang atau kelompok diberi tanggung jawab untuk setiap kegiatan pada tingkat rendah. 2. Tanggung jawab kelompok memperkirakan kegiatan-kegiatan di tingkat rendah pada seseorang atau penggunaan hari yang berjalan. 3. Tanggung jawab kelompok juga menunjukkan kegiatan sebelumnya yang diperlukan untuk setiap tugas, dan menyarankan sumber yang diperlukan untuk tugas tersebut. 4. Perencana menggambarkan aktifitas jaringan kerja, biasanya dalam bentuk diagram PERT. 5. PM mengoptimalkan jaringan kerja dengan menyediakan sumber untuk setiap kegiatan. 6. PM menghasilkan jadwal kegiatan-kegiatan.

t e aN r d n e

By

H

Bab ini merinci langkah 4, 5 dan 6, jaringan kerja dan jadwal.

11.2. DIAGRAM PERT (THE PERT CHART) Pada awalnya PERT (Program Evaluation and Review Technique) yang sederhana digunakan untuk menjelaskan kegiatan yang berurutan dengan menggunakan serangkaian anak panah, seperti gambar 14.1.

BAB 14

Halaman 1 dari 23



Gambar 14.1 A PERT chart Masing-masing anak panah mewakili satu kegiatan dan diberi label dengan nama kegiatan tersebut, contohnya A, B, dan seterusnya. Jika suatu kegiatan tidak dapat dimulai sebelum aktifitas sebelumnya selesai, buntut dari anak panah kegiatan kedua (pengganti) diletakan pada kepala dari yang sebelumnya. Pada gambar 14.1, sebagai contoh, E tidak dapat dimulai sebelum D selesai, G tidak dapat dimulai sebelum C dan F keduanya selesai. Titik awal dan akhir disebut node dan diberi angka. Diagram dalam gambar 14.1 kelihatan tidak punya arti, tetapi berguna untuk menggambarkan suatu PERT untuk ukuran proyek apapun, karena hal itu memaksa anda untuk menganalisis sederetan kegiatan.

t e N

a r d

n e H

y B PERT juga menunjukkan kegiatan yang berjalan secara serentak.

Sederetan kegiatan seperti A – B – C – G disebut suatu jalur (path). Jika ada jalur atau bagian jalur yang berjalan secara paralel, seperti jalur B – C dan jalur D – E – F, maka kegiatan B dan C dapat dikerjakan secara serentak dengan kegiatan D, E dan F.

Jalur Kritis (The Critical Path) Suatu pembuktian yang luas dari diagram PERT di atas dapat dicapai dengan mencantumkan lamanya tugas masing–masing pada PERT, seperti pada gambar 14.2.

BAB 14

Halaman 2 dari 23



Gambar 14.2. A Pert chart with duration in day Jalur terpanjang dalam jaringan kerja, dihitung dengan menambahkan lamanya waktu sepanjang jalur. Sebagai contoh, pada gambar 14.2 jalur paling atas (A-B-C-G) adalah 26 hari, dan jalur bawah (A-D-E-F-G) adalah 25 hari, menjadikan jalur paling atas itu jalur kritis (CP).

t e N

Garis ganda menunjukkan CP lengkap. Mengetahui jalur kritis merupakan hal penting bagi PM. Jika suatu kegiatan pada CP meleset (membutuhkan waktu lebih lama dari yang direncanakan) maka tanggal pengiriman proyek akan meleset.

a r d

y B Float atau Slack

n e H

Suatu periode waktu dimana kegiatan dapat meleset tetapi tidak mempengaruhi CP dan tanggal pengiriman. Sebagai contoh, pada gambar 14.2, kegiatan-kegiatan D, E, dan F diantara mereka terdapat 1 hari float (Perhitungan : kegiatankegiatan CP pada B dan C membutuhkan waktu 11 hari; secara bersamaan kegiatan-kegiatan di luar CP pada D, E, dan F membutuhkan waktu 10 hari, 11 – 10 = 1 hari untuk float). Setiap kegiatan pada D, E, atau F, atau ketiganya secara bersamaan akan memakan waktu sehari lebih lama dan tetap tidak berpengaruh pada CP.

BAB 14

Halaman 3 dari 23



Float Bebas dan Float Total (Free Float & Total Float) Diagram PERT pada gambar 14.3 menunjukkan kegiatan CP dari modul program A dan modul tes A dikerjakan oleh Programmer 1. Kegiatan pada jalur utama, modul program B dan modul tes B, dikerjakan oleh Programmer 2 memakan waktu 5 hari float. Kegiatan – kegiatan pada jalur bawah, modul program C, modul tes C dan penggabungan dikerjakan oleh Programmer 3 dan Pimpinan Proyek. Jalur bawah membutuhkan waktu 5 hari float.

t e N

a r d

By

n e H

Gambar 14.3. Free float and total float Total Float adalah waktu total float dimana kegiatan sebelumnya berpengaruh pada CP.

Free Float adalah waktu float dimana kegiatan sebelumnya tidak berpengaruh pada kegiatan lainnya.

Project float (beberapa float pada beberapa kegiatan) adalah hal yang dimiliki Manajer proyek untuk digunakan sebagai kebijaksanaannya. Beberapa Manajer proyek kadang melangkah terlalu jauh dengan tidak memberikan informasi tentang kegiatankegiatan floatnya.

BAB 14

Halaman 4 dari 23



Kegiatan Dummy (Dummy Activities) Sejauh ini diagram PERT digambarkan sebagai kegiatan dalam format anak panah. Penarikan mundur yang utama pada bentuk PERT ini adalah dibutuhkan untuk kegiatan dummy. Sebagai contoh, pada gambar 14.4A kita mempunyai kegiatan B, C dan D – F yang semuanya dimulai pada titik yang sama dan berakhir pada titik yang sama.

t e N

Gambar 14.4A A PERT chart

a r d

Akan lebih baik untuk mempunyai titik awal dan/atau titik akhir yang unik untuk masing-masing kegiatan. Sebagai contoh, jika seseorang menunjuk kegiatan diantara titik 2 dan 3, hal ini tidak jelas kegiatan mana yang dimaksud. Kegiatan ini akan membingungkan ketika jaringan kerjanya adalah komputer. Gambar 14.4A biasanya digambarkan kembali seperti gambar 14.4B. Disini semua kegiatan digambarkan dengan pasangan titik awal – akhir yang unik. Kegiatan diantara titik 3 dan 4 tidak ada atau dummy (kegiatan fiktif) dengan waktunya nol dan digambarkan sebagai garis terputus.

By

n e H

Gambar 14.4B A PERT chart with dummy

BAB 14

Halaman 5 dari 23



Kegiatan pada Titik atau Jaringan kerja yang diutamakan (Activity on Node or Precedence Network) Aktivitas pada titik atau jaringan kerja yang diutamakan adalah bentuk lain dari diagram PERT. Gambar 14.5 mempunyai proyeksi yang sama dengan gambar 14.4, digambar seperti kegiatan pada titik PERT.

t e N PERT Gambar 14.5. Activity ona node r d n Titik-titik diberi nama denganenama tugas, dan bebas menentukan H lamanya tugas. By 11.3. PENEMPATAN SUMBER (RESOURCE ALLOCATION)

Jika anda mengerjakan rencana secara manual, diagram PERT merupakan diagram yang paling baik digunakan untuk menggambarkan lokasi sumber. Diagram untuk sebuah proyek software seperti pada gambar 14.6.

BAB 14

Halaman 6 dari 23



t e N

a r d

By

n e H

Gambar 14.6. PERT ignoring resources Langkah selanjutnya adalah menggambar ulang diagram PERT dengan mengambil sumber dan memasukkannya ke dalam perhitungan. Penempatan Sumber Daya Manusia (Allocating Human Resources) Jaringan pada gambar 14.6 mempunyai 10 kegiatan yang dikerjakan serentak pada satu waktu, yang mungkin menjadi pilihan jika anda mempunyai 10 programmer yang handal (atau satu programmer yang dapat menyelesaikan 1/10 dari waktunya untuk setiap orang). BAB 14

Halaman 7 dari 23



Penempatan sumber daya manusia sangat subyektif dan tergantung pada kemampuan mereka, tetapi ada beberapa hal yang harus dipertimbangkan : • Penentuan tugas kepada seseorang disesuaikan dengan tingkat kemampuan individualnya. Jangan memberikan tugas yang mudah kepada para ahli, jangan memberikan tugas yang rumit kepada para pemula. • Berikan tugas yang hampir sama pada orang yang sama. Hal ini akan mengurangi waktu untuk mempelajarinya. • Berikan tugas penting pada orang yang anda percaya. Yang disebut orang kepercayaan bukan hanya orang yang bisa menyelesaikan suatu tugas dalam waktu 3 hari, namun pada kenyataannya penyelesaiannya membutuhkan waktu sekitar 5 sampai 10 hari. Orang yang dapat dipercaya itu adalah orang yang bila berkata dapat menyelesaikan suatu tugas selama 3 hari, maka selama itu jugalah tugas tersebut selesai.

t e N

a r d

•

n e H komunikasi pada satu orang yang Berikan tugas yang memerlukan sama untuk menekan By interaksi antar manusia.

• Jangan lupa bahwa pimpinan proyek membutuhkan waktu untuk mengawasi, khususnya pada saat awal proyek.

Tingkatkan sumber daya yang ada sebanyak mungkin. Lebih baik tetap mempertahankan 3 programmer dalam kesibukan selama 5 minggu berjalan, daripada mempekerjakan 5 programmer selama seminggu, tidak satupun orang untuk minggu berikutnya, 3 orang untuk minggu berikutnya, dan 7 orang untuk minggu selanjutnya. Diagram PERT pada gambar 14.7 adalah pengulangan gambar 14.6 dengan penentuan sumber daya. Waktu yang dicapai untuk setiap tugas akan lebih singkat jika lebih dari satu sumber daya yang ditugaskan. BAB 14

Halaman 8 dari 23



Gambar 14.7. Resources allocated

t e N

Keputusan penempatan staf dapat ditetapkan berdasarkan hal berikut : P1 (Programmer 1) mempunyai kemampuan menangani proyek, tetapi P2 dan P3 hanya dapat menangani proyek dalam waktu yang lebih pendek. Modul A, B dan C merupakan modul yang paling sulit namun mempunyai kesamaan, sehingga Pimpinan Proyek (PL) dapat membantu P2 untuk membuat semua kode. Dengan adanya PL dalam CP akan mengurangi stres PM. P1 merupakan seorang senior yang mampu bekerja sendiri dengan serius, P3 adalah pemula yang diserahi menangani dokumentasi (sesuatu yang tidak adil). Catatan bahwa setiap orang bekerja pada jangka waktu yang berdekatan.

a r d

By

n e H

Mengurangi (?) Lamanya Tugas dengan Menambah Tenaga Kerja (Reducing (?) Task Duration by Adding Manpower) Menambah tenaga kerja dalam suatu tim tidak perlu mengurangi lamanya tugas-tugas. Peraturan suatu industri yang sangat menonjol yang pengarang temui sangat berguna, yaitu “Tambahkan

sekurang-kurangnya 10% dari perkiraan waktu sebenarnya untuk setiap tambahan anggota dalam suatu tim yang profesional” . BAB 14

Halaman 9 dari 23



Hal ini menunjukkan bahwa jika satu orang membutuhkan 10 hari untuk mengerjakan tugas, dengan 2 orang dibutuhkan waktu 11 hari, atau paling baik 5½ dalam 24 jam. Tambahkan 10% untuk setiap penambahan kumulatif anggota. Lamanya tugas dapat diterjemahkan dari gambar 14.6 menjadi gambar 14.7. dengan memasukkan peraturan di atas ke dalam perhitungan, ditambahkan beberapa keputusan profesional berdasarkan seberapa baik tugas-tugas itu dapat dibagi, seberapa baik komunikasi setiap individu, dll. Penempatan Sumber Daya ‘Non Manusia’ (Allocating ‘Non-Human’ Resources) Sumber daya non manusia diperlukan untuk proyek software seperti hardware komputer, paket software, sistem operasi, informasi, manual, pelatihan, jaminan komputer, layanan cetakan, dsb.

t e N a r 11.4. TIGA BATASAN (THE TRIPLE CONSTRAINT) d n e Seperti yang kita lihat yangH lalu, “Anda bisa mendapatkan yang baik, y dua !”. Menambah beberapa sumber daya murah atau cepat B : Pilih akan mengurangi lamanya tugas, tetapi biaya meningkat. Memindahkan orang yang dipercaya dari kegiatan yang rumit tetapi kegiatannya pendek ke dalam kegiatan yang lama mungkin mengurangi waktu secara keseluruhan, tetapi ini akan membahayakan seluruh proyek jika kualitas pada tugas yang pendek dikurangi. Banyak pilihan yang mungkin dilakukan ketika anda menentukan sumber daya. Selalu coba beberapa pendekatan, lihat efek dari penggunaan sumber daya dan biaya, panjang CP dan kesederhanaan dari PERT. PM harus dapat membuat tiga batasan dan memberikan keseimbangan yang baik berdasarkan prioritas tempat pada tiga batasan untuk user atau manajemen tingkat atas.

BAB 14

Halaman 10 dari 23



Kegagalan Proyek (Crashing a Project) Salah satu situasi yang paling sulit adalah ketika waktu menjadi prioritas utama diantara tiga batasan. Ambil contoh skenario ketika manajer anda menanyakan kepada anda untuk memperkiraan proyek dan hasil yang anda sajikan : YOU : Jika semuanya berjalan lancar, kita dapat menyerahkan proyek ini pada tanggal 15 April. MGR : Tidak mungkin ! Bagian Marketing telah menjanjikan proyek ini pada tanggal 1 April. Kita bisa dikenakan denda $1000 perhari setelah tanggal 1 April. Bisakah anda mengerjakannya lebih cepat ? YOU : Ya, tapi saya membutuhkan waktu lebih banyak di depan komputer, menyewa beberapa orang dan mengerjakan pekerjaan tersebut dengan cepat (lembur). Hal itu akan membutuhkan tambahan biaya lagi. MGR : Semuanya gagal ! Tak usah hiraukan biayanya ! YOU : (Untuk anda sendiri : terdengar disini seperti ada yang memotivasi). OK.

t e N

a r d

n e H di setiap tugas? Jelas tidak, mengapa Apakah anda sungguh gagal tugas yang gagal tidak Byditempatkan pada jalur kritis ? Gambar 14.8A di bawah ini merupakan contoh perhitungan tugas itu diselesaikan beserta hasilnya.

Gambar 14.8A PERT for a project BAB 14

Halaman 11 dari 23



Gambar 14.8B Steps to crashing the project

t e N

a r d

By

n e H

Gambar 14.8C Cost vs crash graph Pertama-tama kita harus menghitung tiga hal untuk setiap tugas : Hal pertama : Lamanya waktu normal (hari). Ini adalah perkiraan yang akan anda berikan kepada Manajer pertama kali. Hal kedua : Lamanya waktu minimal (hari) dimana anda dapat menekan perubahan tugas. Hal ketiga : Biaya tambahan per-hari untuk setiap perubahan. BAB 14

Halaman 12 dari 23



Sebagai contoh, tugas B (gambar 14.8A) secara normal akan memakan waktu 5 hari. Jika programmer bekerja lembur, tugas B dapat selesai dalam 3 hari (minimum), tapi hal itu akan memerlukan tambahan biaya $200 per-hari. Mari kita coba untuk menyelesaikan proyek ini. Algoritma yang digunakan pada proyek tersebut adalah : Ubah tugas pada CP,

jika selama tidak ada jalur lain yang menjadi kritis. Jika jalur lain menjadi kritis, ubah tugas tersebut dengan baik. Langkah satu

Langkah dua

: (Lihat gambar 14.8B) Ubah tugas A dari 3 hari menjadi 2 hari. Ada keuntungan 1 hari dengan biaya $500. Jalur lain tidak padat karena tidak ada kegiatan lain yang paralel. Tugas A tidak dapat diselesaikan lebih lama (3 hari adalah waktu minimum).

t e : Ubah tugas B dari 5N hari menjadi 4 hari, a dengan biaya $200.rE adalah sebuah jalur paralel, ndtersebut, jika jalur ini menjadi jadi periksa e jalur H E dilakukan secara simultan dengan B kritis. Tugas dan ByC. Dengan mengubah tugas B menjadi 4 hari, maka B dan C bersama-sama membutuhkan waktu 11 hari. Tugas E dilakukan selama 11 hari dengan demikian berubah menjadi kritis, tetapi belum perlu diubah.

Langkah tiga

: Ubah tugas B menjadi 3 hari dengan biaya $200. Karena E adalah paralel dan kritis, maka E memerlukan tambahan hari, E harus diubah menjadi 10 hari dengan biaya $1500, dan biaya totalnya adalah $1700.

Langkah empat : Langkah 4 dan 5 sama, jadi penjelasannya tergantung kepada pembaca.

BAB 14

Halaman 13 dari 23



Lima hari adalah yang terlama dari proyek tersebut dapat diselesaikan, sehingga perlu diubah. Perhatikan bahwa tidak semua tugas perlu diubah, atau tidak semua tugas yang diubah ditekan menjadi minimum. Terakhir, gambar 14.8C adalah graph yang sangat berguna bagi manajemen. Graph tersebut menunjukkan tanggal pengiriman proyek (sumbu X), serta biaya tambahan yang diperlukan selama tanggal tersebut (sumbu Y). Kesimpulan untuk Penyelesaian Proyek (Conclusions to Crashing a Project) Beberapa asumsi dapat dibuat disini : • Pertama : tugas dapat diselesaikan. Menambah tenaga kerja dan waktu lembur belum tentu mempercepat penyelesaian proyek. • Kedua : tugas dapat diselesaikan sesuai pesanan. • Ketiga : tugas-tugas dapat diselesaikan secara terpisah. Penyelesaian satu tugas akan mempengaruhi tugas lain. Paket komputer terbaik akan membantu semua perhitungan anda.

t e N

a r d

n e H GANTT 14.5. JADWAL ATAU DIAGRAM (THE SCHEDULE By OR GANTT CHART)

Diagram GANTT adalah diagram batang yang menunjukkan waktu. Disebut GANTT karena ditemukan oleh Henry Gantt. Diagram GANTT pada gambar 14.9 merupakan jadwal proyek PERT pada gambar 14.8.

BAB 14

Halaman 14 dari 23



t e N

a r d

By

n e H

Gambar 14.9. Gantt chart of a project BAB 14

Halaman 15 dari 23



Langkah-langkah untuk menggambar GANTT adalah : Langkah 1 : Gambarlah satuan waktu di posisi atas. Pilih satuan waktu sehingga anda memerlukan tidak lebih dari 2 diagram. Anda akan melihat bahwa Gantt adalah buku penuntun bagi Manajer proyek. Semua kalender bergantung pada informasi yang dapat dimasukkan ke dalam Gantt, dan 99% kehidupan PM bergantung pada kalender ini. Tanggal mulai pada setiap minggunya harus diberi tanda jika tersedia ruangannya. Langkah 2 : Beri tanda pada kalender semua kejadian di posisi bawah. Kegiatan hari libur seperti liburan, hari raya, rapat, pelatihan, janji penting, dll, semua kejadian harus dijadwalkan di sekitarnya.

t e N

Langkah 3 : Dari PERT pada gambar 14.7, jadwalkan setiap kegiatan. Mulailah dengan kegiatan pertama, fase DEFINISI, gambarkan dalam bentuk batang sama panjangnya dengan satu hari pada PERT. Beri tanda orang yang bertanggung jawab di dalamnya, dan presentasikan waktu yang anda harapkan untuk setiap orang yang bekerja pada proyek tersebut, jika ini tidak 100%.

a r d

By

n e H

Langkah 4 : Jadwalkan kemungkinan tugas. Untuk setiap kegiatan tanya pada diri Anda sendiri, “Apakah ada pekerjaan yang akan diperpanjang waktunya untuk tugas khusus ini ?“. Langkah 5 : Ulangi kembali langkah 3 dan 4, jadwalkan semua tugas-tugas dalam PERT, dari kiri ke kanan dan dari atas ke bawah untuk tugas-tugas yang paralel. Sebuah tugas dimulai bila kemungkinan tugas yang sebelumnya telah diselesaikan. Tambahkan kemungkinan yang banyak pada tugas khusus terakhir, System Test, sebagai ukuran keamanan. BAB 14

Halaman 16 dari 23



Langkah 6 : Beri tanda semua kejadian-kejadian penting. Beri tanda kejadian penting utama yang menunjukkan penyelesaian dari kejadian penting dan produk-produk. Yakinkan bahwa kejadian penting tersebut cukup sering, jadi waktu diantara satu kejadian cukup pendek, sehingga tidak akan lepas kontrol. Lakukan setiap 2 atau 3 bulan selama 12 bulan proyek itu berjalan. Ini menunjukkan bahwa kejadian penting ‘fake’ dapat ditemukan, seperti Milestone 3, Mid-programming review pada gambar 14.10. 11.6. KESIMPULAN UNTUK PENJADWALAN Sampai pengarang menulis buku ini, biaya Personal Computer dengan software manajemen proyek yang sangat sempurna sama dengan gaji seorang manajer proyek selama 1 minggu. Biaya ini tidak dapat dihindari dalam pemakaian sebuah produk komputer untuk menggambarkan PERT dan GANTT, untuk menghitung CP, dsb.

t e aN r duntuk mengambarkan kembali n Personal Computer juga berguna He daya GANTT tersendiri untuk setiap proyek GANTT kedalam sumber ykegiatan orangnya. Jika anda tidak pernah orang, meliputi jadwal B menggambar PERT atau GANTT secara manual, pertama-tama kerjakan ini pada kertas untuk mempelajari konsepnya, kemudian gunakan Personal Computer.

Tetaplah mempertimbangkan 3 bagian dari GANTT. Bagian pertama adalah untuk diri anda sendiri dengan semua float dan kemungkinan yang terlihat. Bagian kedua adalah untuk individu-individu yang terlibat – ini merupakan sumber daya GANTT bagi mereka. Bagian ketiga adalah untuk distribusi bagi manajemen tingkat atas. Arti penting Total Float adalah menunjukkan jumlah waktu yang diperkenankan suatu kegiatan boleh ditunda, tanpa mempengaruhi jadwal penyelesaian proyek secara keseluruhan.

BAB 14

Halaman 17 dari 23



Jumlah waktu tersebut sama dengan waktu yang didapat bila semua kegiatan terdahulu dimulai seawal mungkin, sedangkan semua kegiatan berikutnya dimulai selambat mungkin.

Total Float ini dimiliki bersama oleh semua kegiatan yang ada pada jalur yang bersangkutan. Hal ini berarti bila salah satu kegiatan telah memakainya, maka total float yang tersedia untuk kegiatan-kegiatan lain yang berada pada jalur tersebut adalah sama dengan total float semua dikurangi bagian yang telah dipakai.

Free Float adalah bilamana semua kegiatan pada jalur yang bersangkutan mulai seawal mungkin. Besarnya Free Float suatu kegiatan adalah sama dengan sejumlah waktu dimana penyelesaian kegiatan tersebut dapat ditunda, tanpa mempengaruhi waktu mulai paling awal dari kegiatan berikutnya ataupun semua peristiwa yang lain pada jaringan kerja. Dengan kata lain free float dimiliki oleh suatu kegiatan tertentu, sedangkan total float dimiliki kegiatan-kegiatan yang berada di jalur yang bersangkutan.

t e N

a r d

By

BAB 14

n e H

Halaman 18 dari 23



BAB 12 PROTOTIPE Bekerja dengan Model Pertama 12.1. PENDAHULUAN Siapapun yang pernah menyelesaikan proyek software akan sependapat, bahwa masalah pertama adalah memperoleh kebutuhan dari user. Permasalahan kedua adalah berdasarkan persetujuan Spesifikasi Fungsional (FS). FS mencoba untuk menggambarkan sistem yang berbasis grafik dan narasi, tetapi gambar dan penjelasan tidak dapat menerangkan cara sistem tersebut berjalan, berlaku, dan mempengaruhi bisnis user. Sebagai tambahan, FS biasanya menimbulkan kesalah pahaman (jika dibaca semuanya).

t e aN r d n e

Kesalah pahaman antara user dan analis mengakibatkan perubahan yang berarti atau sistem tidak akan pernah sempurna dalam pelaksanaannya atau sekaligus ditolak. Prototipe dapat memecahkan masalah ini untuk tipe-tipe tertentu dalam sistem.

By

H

12.2. TEORI DI BELAKANG PROTOTIPE (THE THEORY BEHIND PROTOTYPING) Apakah anda membeli mobil dari brosur penjualan ? Seperti halnya anda tidak dapat menilai sebuah mobil tanpa mencobanya, user juga tidak dapat menilai dari Spesifikasi Fungsional, bagaimana sistem akan berlaku dan berjalan. Tetapi jika user dapat melihat, menyentuh dan menggunakan ‘mode’l atau prototipe dari tujuan sistem, ia dapat langsung menilai kegunaan sistem. Jika perubahan diperlukan prototipe dapat dimodifikasi, memungkinkan dimodifikasi beberapa kali sampai keadaaan yang ditetapkan user.

BAB 15

Halaman 1 dari 10



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.

t e aN r d n 12.3. METODE PROTOTIPE He(THE PROTOTYPING METHOD) y B 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. BAB 15

Halaman 2 dari 10



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.

12.4. SISTEM YANG BERMANFAAT DARI PROTOTIPE (SYSTEMS THAT BENEFIT FROM PROTOTYPING) Sejak kebutuhan (baca Spesifikasi Fungsi) pada umumnya berhubungan dengan pandangan user terhadap sistem, hanya dengan prototipe tampilan bagi user sudah cukup untuk memeriksa yang dibutuhkan. Menu-menu, bentuk tampilan input, tampilan keluaran, atau laporan yang dicetak, pertanyaan-pertanyaan, pesanpesan merupakan calon yang ideal untuk prototipe.

t e aN r d n e rumit, kumpulan update data dan Di lain pihak, perhitungan H yang realtime, dan sistemyyang bersifat scientific sangat sulit untuk dijadikan model. B

Sistem yang paling sesuai untuk prototipe adalah satu dari banyak hal yang bergantung pada sistem input/output dari user. Sistem dengan transaksi on-line dikendalikan melalui menu, layar, formulir, laporan, daftar dan perintah.

BAB 15

Halaman 3 dari 10



15.5. SOFTWARE UNTUK PROTOTIPE (SOFTWARE FOR PROTOTYPING) Apa yang harus disediakan dari paket software prototipe ? Produk yang baik harus menyediakan 7 bagian, yaitu :

1. Pembuatan menu yang cepat dan mudah. Pada menu harus terdapat sub menu, formulir, laporan, program protipe, dan menyediakan bantuan secara on-line untuk pemilihan menu dan prompt.

t e N

a r d

By

n e H

Gambar 15.1. Konstruksi Program Menu 2. Pembuatan tampilan input dan output. Anda harus dapat mewarnai bentuk tampilan dengan menempatkan kursor pada lokasi yang dituju (mouse merupakan alat yang terbaik untuk melakukannya), ketik nama field, spesifikasikan ketentuan untuk mengedit berdasarkan panjang field, menyertakan alfanumerik, jarak angka-angka yang diperbolehkan, kesalahan dan pesan-pesan bantuan, dll. BAB 15

Halaman 4 dari 10



Gambar 15.2. Cara kerja field program aplikasi 3. Penyelarasan.

t e N

Anda dapat menjelaskan bentuk sebuah laporan yang dicetak dengan mudah. Bagian-bagian untuk merinci pembuatan laporan adalah judul, catatan kaki, field mana yang diletakkan (yang paling baik adalah jika program menampilkan semua field yang dikenal), header kolom, pengelompokkan, pengurutan, serta sub dan grand total. Pada umumnya seseorang harus dapat melaporkan item yang dipilih saja.

a r d

By

n e H

Gambar 15.3. Penggunaan sebuah program pembuatan laporan BAB 15

Halaman 5 dari 10



4. Software harus menghasilkan sebuah Data Dictionary secara otomatis. Data Dictionary (DD) menyimpan informasi seperti layar, laporan atau formulir, tetapi yang paling penting DD menyimpan setiap informasi pada setiap field, termasuk panjang field, pengeditan dalam setiap laporan, dan format field yang digunakan. DD adalah inti dari setiap produk dan sudah seharusnya setiap alat prototipe menggunakan DD untuk mengecek apakah fieldnya digunakan secara konsisten pada setiap tampilan, dan apakah dapat menyimpan pengetikan berulang jika field muncul lebih dari 1 kali.

5. Software harus dapat menyusun database sesuai harapan. Ketentuan tampilan input seperti yang digunakan pada gambar 15.2 menjelaskan tentang peralatan daftar format. Software harus menyusun database dan selanjutnya mengijinkan user memasukkan data menggunakan formulir input. Produk-produk yang baik mengijinkan user untuk mengoptimalkan database dengan menentukan format dan kunci recordnya.

t e N

a r d

By

n e H

6. Mencari hasil dengan query on-line secara tepat ke data yang didaftar pada database. Anda harus mampu melakukan pencarian dengan mudah, penyusunan, pemilihan dan menampilkan record.

7. Apakah yang dibutuhkan meliputi logika yang rumit atau perhitungan yang diperlukan prototipe ? Walaupun tidak penting, program yang baik mempunyai bentuk struktur sederhana bahasa pemrograman untuk mengijinkan anda melakukan pemrosesan khusus, waktu kejadian, prosedurprosedur otomatis, dsb.

BAB 15

Halaman 6 dari 10



Prototipe sebagai bagian dari CASE Prototipe adalah metode untuk mengotomatisasi fase definisi dan analisis, jadi merupakan bagian dari CASE (Computer Aided Software Engineering). Tetapi prototipe memberikan masukan pada tingkat pengotomatisasian selanjutnya dengan baik. Jika langkah selanjutnya adalah membangun sistem nyata dalam bahasa pemrograman generasi ketiga, produk prototipe harus dapat menyediakan pada anda sarana untuk mencetak semua item yang telah diketahui, semua menu, semua bentuk laporan dan perintahperintah. Produk yang terbaik adalah yang mengijinkan user untuk mencetak dokumen yang tersusun secara logika dengan bab dan bagian yang dapat digunakan seperti dokumen Spesifikasi Fungsional (FS). Bahkan beberapa diantaranya menyediakan pengolah kata untuk memasukkan teks keterangan di antara item-item. Produk tersebut harus pula dapat mencetak kamus data, yang dapat menghemat banyak jam kerja.

t e N

a r d

By

n e H

Jika disain dan programnya menggunakan bahasa pemgrograman generasi ke-empat atau peralatan CASE yang terintegrasi (lihat Bab 6), anda harus dapat memasukkan hasil dari prototipe secara langsung ke dalam peralatannya. Peralatan CASE yang paling baik akan secara otomatis menyusun database dan bahkan kode untuk aplikasi akhir. Seberapa cepat anda melakukan prototipe ? Software untuk melakukan prototipe harus dapat membuat anda mampu menyusun model permulaan dari suatu sistem secara cepat. Khususnya, anda dapat membangun prototipe pertama dari bentuk terkecil hingga bentuk yang sedang hanya dalam waktu 2 s/d 3 minggu !. Anda juga harus dapat mengimplementasikan perubahan dengan cepat.

BAB 15

Halaman 7 dari 10



Ini akan memakan waktu beberapa menit untuk membuat perubahan, seperti memindahkan sebuah field pada sebuah form. Ini akan memakan waktu kurang dari 1 jam untuk menentukan sebuah menu atau form baru, dan hampir beberapa jam untuk membuat sebuah file baru atau menyusun ulang sebuah file yang sudah ada untuk sebuah field, key atau akses baru. Untuk mencapai kecepatan ini perlu mempunyai sebuah user interface yang sederhana dan logis. Sebenarnya jika pembuatan prototipe software cukup sederhana, para pengembang dapat melatih user untuk menggunakannya. User kemudian akan membangun prototipe dan menghubungi pengembang ketika siap untuk berubah menjadi sistem akhir.

15.6. DIMANAKAH PROTOTIPE DITEMPATKAN DALAM 7 FASE ?

t e N

Sekarang anda mungkin merasakan bahwa metode pembuatan prototipe dapat menggantikan dengan sempurna 7 fase mendekati pembangunan proyek (dan mungkin juga merasa diganggu bahwa saya membuat anda membaca bagian I buku ini sebelum menceritakan pada anda tentang pembuatan prototipe !) Jangan takut pembuatan prototipe hanya menggantikan beberapa bagian dari Fase Definisi dan Analisis.

a r d

By

BAB 15

n e H

Halaman 8 dari 10



t e N

a r d

n e H

Gambar 15.4. Urutan kejadian di dalam 7 fase antara metode lama dengan metode baru (prototipe)

By

Fase definisi dan analisis akan memakan waktu yang lebih sedikit dari cara baru, karena sebuah deadline akan ditentukan waktunya. 12.7. BEBERAPA PRODUK YANG HARUS DILIHAT (SOME PRODUCTS TO LOOAK AT) Excelerator sebagai alat prototipe Dalam bab 6 kita telah melihat sebuah alat analisis yang baik disebut Excelerator (referensi 2.2), tetapi alat ini mempunyai bentuk yang membuat alat prototipe yang baik. Meliputi menu, form, dan fasilitas untuk membuat laporan. Yang terpenting memelihara sebuah kamus data, mengijinkan anda untuk mencetak sebuah organsasi logik yang berfungsi sebagai dokumen yang khusus, yang terdiri dari semua

BAB 15

Halaman 9 dari 10



jenis yang didefinisikan dengan proses kata yang dimasukkan dalam paragraf untuk ukuran yang baik. Bahasa Generasi Ke-empat sebagai peralatan prototipe Suatu saat kita memerlukan layar yang rumit, perhitungan khusus, prosedur otomatis, dan bentuk laporan yang unik, yang kebanyakan prototipe tidak mempunyai kemampuan untuk melakukan semua itu. Ada sebuah jenis produk yang disebut Fourth Generation Language (4GL) yang mempunyai kemampuan untuk melakukan hal tersebut. Kita akan membicarakan hal ini di bab lain sebagai alat untuk mengembangkan semua sistem, tetapi hampir semua 4GL dapat digunakan sebagai peralatan prototipe yang baik.

12.8. KESIMPULAN (CONCLUSIONS)

t e aN r d n e

Prototipe telah digunakan dengan sukses untuk diimplementasikan ke beberapa sistem software, yang meliputi user interface melalui menu, layar, laporan, dan transaksi on-line. Sistem yang berorientasi bisnis sangat cocok untuk metode ini. Sistem real-time dan scientific akan sedikit berkurang ketika menggunakan metode ini.

By

BAB 15

H

Halaman 10 dari 10



BAB 19 SUSUNAN STAF Orang yang tepat untuk tugas yang tepat 19.1. PENDAHULUAN Susunan staf adalah memilih orang yang tepat untuk pekerjaan yang tepat. Bab ini akan sangat berguna bagi Anda yang harus memilih individu-individu dari staf yang ada atau siapa yang harus ditugaskan pada tim proyek. 19.2. MEMILIH ANGGOTA TIM PROYEK

t e N

Jika Anda mengorganisasikan tim proyek seperti digambarkan pada gambar 18.1, jabatan yang harus diisi adalah Manajer Proyek, Pimpinan Proyek, dan Programmer.

a r d

By

n e H

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. Manajer tingkat atas menugaskan PM. Mereka mencari seseorang yang memiliki kemampuan berkomunikasi dengan baik. Keahliankeahlian lain yang mereka cari adalah pengetahuan tentang manajemen proyek, kemampuan mengorganisasi, dan keahlian teknik. Kadang-kadang pekerjaan PM membutuhkan aksi yang tidak umum seperti berkata “Tidak” untuk perubahan permintaan yang menyimpang, mengumumkan kesalahan, atau mendisiplinkan orangorang. PM harus mengetahui orang-orang yang terlibat sama seperti dalam politik, prosedur-prosedur pemakaian, dan proyek perusahaan. BAB 19

Halaman 1 dari 6



Keahlian yang dibutuhkan untuk pekerjaan ini adalah kepemimpinan yang luas, kemampuan bernegosiasi dan diplomasi. 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. Jangan mencari orang yang tidak mempunyai pendirian. Lebih baik mencari orang yang dapat mengingat pembuatan detail keseluruhan proyek tersebut. PL juga harus memiliki kemampuan berkomunikasi yang baik. PL akan memimpin keseluruhan wawancara dengan user dan menjadi pengawas harian bagi programmer.

t e N

a r d

Programmer

By

n e H

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. Jika kandidat tersebut tidak memiliki pengalaman yang sesuai, hal lain yang dapat dipertimbangkan adalah latar belakang tentang sistem operasi, atau hal lainnya.

BAB 19

Halaman 2 dari 6



Programmer Ahli (The Guru Programmer) Gaya hidup baru telah berevolusi sejak komputer ditemukan. Hal ini adalah Programmer Ahli atau “Hacker”. Orang ini bekerja secara misterius, pada jam-jam yang aneh; suka menentang dan tidak mau diatur, hanya ingin mengerjakan tugas sesuai dengan keinginanya. Tetapi ahli dalam bidangnya, dapat membuat program tugas-tugas yang rumit 10 kali lebih cepat dari orang lain. Disarankan jika Anda memiliki orang ini, organisasikan sebuah tim dan 1 ahli ini dikelilingi oleh para pemula. Hal ini akan sukses jika ahli tersebut senang menjelaskan sesuatu kepada orang lain (seperti yang biasa mereka lakukan) – para pemula akan belajar dari ahli ini. Programmer Pemula (The Junior Programmer) Programmer pemula biasanya memiliki bakat dan mempunyai keinginan untuk membuktikan diri mereka. Ada dua keahlian, bagaimanapun itu tidak selalu diajarkan di sekolah : komunikasi tim dan komunikasi manajemen. Selalu ada kompetisi di sekolah. Bahkan pada sebuah tim proyek, para siswa tidak membantu diantara sesama mereka. Mereka mungkin tidak diajarkan untuk berbagi pekerjaan kepada anggota tim yang lain. Dalam sebuah perusahaan seorang anggota tim hanya berhasil jika keseluruhan tim berhasil.

t e N

a r d

By

n e H

Bersamaan dengan itu, para siswa mungkin tidak diajarkan bahwa para manajer setiap saat harus selalu tahu apa yang sedang dikerjakan setiap orang dan bagaimana kemajuan tugas mereka. Ini mungkin tidak dibutuhkan untuk sebuah tugas sekolah. Tetapi jika anda mengajarkan Programmer Pemula untuk berkomunisasi, Anda akan memiliki anggota tim yang tidak terhingga nilainya. 12.3. KEPRIBADIAN Kepribadian dapat berpengaruh kuat terhadap proyek. Berikut ini sebuah daftar dari kepribadian yang diinginkan untuk staf proyek. (Hati-hati, gunakan penilaian Anda). BAB 19

Halaman 3 dari 6



1. Anda membutuhkan seseorang yang dapat berkomunikasi, yang merupakan bagian dari sebuah tim, serta dapat berbagi pengetahuan dan ide-ide dengan baik, tetapi juga harus mau menjalankan ide-ide tersebut. 2. Anda membutuhkan seorang pendengar yang baik, seseorang yang akan mendengarkan pendapat orang lain dan mau mengakui jika pendapat-pendapat tersebut lebih baik. 3. Anda membutuhkan seorang yang terorganisir. Akan banyak tugas yang harus dilakukan, setiap tugas pada waktu yang tepat. 4. Anda tidak membutuhkan seseorang yang perfeksionis. Pilihlah seorang yang dapat bekerja pada saat deadline. Selalu ada cara yang terbaik, tetapi jika hal ini berhasil sekarang, keluarkan sesuai waktu, dan simpan kemajuan ini untuk versi berikutnya.

t e N

a r d

5. Anda membutuhkan seseorang yang mempunyai kemampuan teknik terbaik, seorang analitis dan logis, dengan pengalaman yang sesuai.

By

n e H

12.4. MEMBERIKAN TUGAS KEPADA INDIVIDU-INDIVIDU Dalam bukunya “The Psychology of Computer Programming”, G. Weinberg menyatakan bahwa motivator terbesar dari seorang programmer adalah mempelajari hal baru. Selalu berikan tugas yang lebih menantang dari tugas sebelumnya. Tetapi jangan memberikan sebuah tugas yang rumit untuk Programmer Pemula – mungkin tidak akan selesai, dan tugas yang rumit ini pun juga tidak akan terselesaikan oleh para ahli. Jika ada tugas-tugas yang berhubungan, berikan pada orang yang sama. Jika ada program yang berhubungan dengan program lain, berikan program ini kepada seseorang pada posisi yang sama (atau 2 orang yang sangat dekat). BAB 19

Halaman 4 dari 6



Berikan tugas-tugas yang kritis dan tugas-tugas yang sulit kepada orang yang paling diandalkan. Orang yang dapat diandalkan bukanlah “Ahli” yang dapat menyelesaikan tugas dalam 2 hari, tetapi orang tersebut menyelesaikan dalam 4 atau 10 hari tergantung pada mood orang tersebut. Orang yang dapat diandalkan berkata “Tugas ini akan selesai 5 hari”, dan selama waktu itulah yang diperlukan. Jangan memberikan tugas yang membuat seseorang menjadi tidak disiplin. IBM telah menemukan bahwa sebuah organisasi dimana Kepala Tim Programmer / Chief Programmer Team (CPT) sangat produktif. Dengan metode CPT, seorang kepala ahli programmer melakukan semua pengkodean yang rumit (80%), dibantu oleh para pemula untuk pengkodean yang lebih mudah (20%). Tetapi jika ketua pergi, maka anak buah akan menghilang. Untuk mencegah hal ini, IBM biasanya menggunakan sebuah sistem bersahabat, dimana seorang programmer ditugaskan untuk bekerja dengan sangat dekat dengan kepala programmer, membantu dan berbagi muatan pekerjaan jika mungkin, dan mempelajari semua hal yang diketahui oleh kepala programmer.

t e N

a r d

n e H

y B 12.5. MEMOTIVASI ORANG

PM adalah pelatih dari sebuah tim; PL adalah kapten. PM memimpin, memotivasi, mengajarkan dan menggunakan sedikit ancaman untuk mendapatkan tugas tersebut diselesaikan. PL bermain dalam tim dan memotivasi dengan memberi contoh. Kepemimpinan proyek (PM dan PL) harus selalu ada dan dapat melakukan pendekatan. Gunakan pendekatan MBWA (Management By Walking Around) seperti dalam buku “In Search of Excellence”, bagian 4. Ketika seseorang mendekati Anda dengan sebuah masalah pribadi atau teknik, lakukanlah hal ini : Diam dan dengarkan. Biasanya orang itu akan menjawab masalahnya, ketika menjelaskan masalah tersebut.

BAB 19

Halaman 5 dari 6



angan lupakan 3 prinsip dasar dalam buku “The One Minute Manager” (bagian 21) : Jika pantas, berilah pujian (satu menit), Jika sangat perlu, berilah kritikan (satu menit), dan selalu menyusun sasaran-sasaran (satu menit) untuk berkomunikasi sesuai dengan apa yang diharapkan setiap orang dan bagaimana mereka akan dinilai untuk sukses. Libatkan orang-orang dalam setiap keputusan proyek yang penting dan mereka akan mematuhinya. Sebagai contoh, selalu memperhitungkan kembali setiap pekerjaan mereka dan capailah kesepakatan jika anda mempunyai perhitungan dan mereka tidak setuju. Kirim orang-orang Anda ke kursus-kursus – sangatlah mengejutkan apa yang dapat dipelajari, bahkan oleh orang-orang yang paling berpengalaman. 19.6. KESIMPULAN

t e N

a r d

n e H

Dari semua hal tentang bagaimana memilih orang yang tepat, ingatlah bahwa kemampuan dari orang tersebut akan menjadi faktor pertama yang menentukan.

By

BAB 19

Halaman 6 dari 6


PROPOSAL

t e N

PROYEK: [NAMA PROYEK] UNTUK [NAMA PEMILIK PROYEK]

a r d

By

n e H

POLITEKNIK PIKSI GANESHA BANDUNG

Juni 2010


DAFTAR ISI

BAB I

PENDAHULUAN .................................................................................... 1 1.1 Latar Belakang............................................................................... n 1.2 Maksud dan Tujuan ....................................................................... n 1.3 Ruang Lingkup Pekerjaan.............................................................. n

BAB II

NAMA SISTEM INFORMASI.................................................................. n 2.1 Latar Belakang............................................................................... n 2.2 Perspektif Produk........................................................................... n 2.3 Deskripsi Subsistem ...................................................................... n 2.4 Manfaat.......................................................................................... n

BAB III METODOLOGI KERJA .......................................................................... n 3.1 Survei dan Analisis Sistem............................................................. n 3.2 Perancangan Sistem...................................................................... n 3.2.1 Arsitektur Sistem ............................................................... n 3.2.2 Perancangan Data............................................................. n 3.2.3 Perancangan Jaringan....................................................... n 3.3 Pengujian dan Perbaikan ............................................................... n 3.4 Implementasi Sistem...................................................................... n 3.5 Pelatihan........................................................................................ n 3.6 Pemeliharaan................................................................................. n 3.7 Rencana Anggaran Biaya .............................................................. n 3.8 Rencana Pekerjaan ....................................................................... n 3.9 Jadwal Pelaksanaan ...................................................................... n

t e N

a r d

By

n e H

BAB IV PENUTUP.............................................................................................. n


BAB I PENDAHULUAN

1.1 Latar Belakang Uraikan secara deskriptif dan ringkas mengenai latar belakang pengembangan proyek sistem informasi, termasuk peluang yang bisa ditangkap.

1.2 Maksud dan Tujuan

t e N

Jelaskan secara rinci maksud dan tujuan pengembangan proyek sistem informasi.

a r d

Maksud •

1

•

2

Tujuan •

1

•

2

By

n e H


1.3 Ruang Lingkup Pekerjaan Uraikan secara rinci ruang lingkup pekerjaan yang nantinya akan ditangani, misalnya: •

Pengembangan Deskripsikan

•

Pengumpulan data Deskripsikan sampai sejauh mana tahapan pengumpulan data, misalnya entry data, sampai availability data terpenuhi

•

Pemeliharaan

•

Pelatihan

t e N

a r d

By

n e H


BAB II NAMA SISTEM INFORMASI YANG DIUSULKAN

2.1 Latar Belakang Uraikan secara deskriptif dan ringkas mengenai latar belakang sistem informasi—bukan proyek pengembangan sistem informasi seperti di Bab 1— yang akan dikembangkan.

2.2 Perspektif Produk Deskripsikan gambaran umum dari produk sistem informasi yang akan dikembangkan. Sebaiknya dilengkapi dengan gambar arsitektur global. Jika proyek ini merupakan peningkatan sistem yang ada, gambarkan juga keterhubungannya.

t e N

a r d

n e H

2.3 Deskripsi Subsistem

By

Uraikan deskripsi subsistem yang akan dikembangkan Lebih disukai jika dilengkapi dengan gambar subsistem. Contoh: • Modul penggajian Beri penjelasan yang deskriptif • Modul reporting (pelaporan) •

Modul backup dan recovery

2.4 Manfaat Bagi Perusahaan/Organisasi/Instansi* Tegaskan lagi benefit yang didapat mengimplementasikan sistem informasi ini.

* pilih salah satu (sesuaikan)

oleh

perusahaan

ketika


BAB III METODOLOGI KERJA

3.1 Survei dan Analisis Sistem Jelaskan tahapan survei dan analisis kebutuhan sistem a. Survei Kebutuhan Sistem Uraikan metode dan tahapan-tahapannya (observasi, wawancara, dll) b. Analisis Kebutuhan Sistem Uraikan tahapan-tahapan analisis Misal: 1) Analisis fungsionalitas produk 2) Analisis kebutuhan perangkat keras 3) Analisis tingkat kebutuhan operator

t e N

a r d

n e H

3.2 Perancangan Sistem

By

Deskripsikan tahapan-tahapan perancangan sistem yang akan dilakukan Misal: a. Perancangan data Uraikan b. Perancangan proses c.

Perancangan jaringan Jika perlu, buat desain topologi jaringan dengan mengacu gambar lokasi proyek yang dijelaskan dalam RFP.


3.3 Implementasi Sistem Uraikan tahapan implementasi produk Mencakup bahasa pendukung lainnya.

pemrograman,

DBMS,

dan/atau

teknologi-teknologi

3.4 Pelatihan Deskripsikan secara rinci mekanisme, sasaran (misal para operator), dan bentuk pelatihan yang akan diberikan nantinya.

3.5 Pemeliharaan Deskripsikan mekanisme pemeliharaan sistem, termasuk layanan apa saja yang disediakan terkait pemeliharaan sistem, misalnya ada tim khusus untuk troubleshooting, dsb

t e N

a r d

By

n e H


3.6 Rencana Anggaran Biaya Buat rencana anggaran biaya yang riil dan responsible. Ingat, tahapan ini juga sangat memengaruhi diterima tidaknya proposal. Jadi, buat rincian perhitungan yang tepat. Bisa dituliskan langsung di sini atau dibuat lampiran khusus (misal dalam format spreadsheet). Contoh RAB (tidak harus sama persis, sesuaikan dengan proyek yang ditangani):

I. TENAGA AHLI No.

Harga Satuan

Posisi

1

Project Manager

1

Orang

6

Bulan

2

System Analyst dan Designer

2

Orang

6

Bulan

3

Database Administrator

4

Programmer

5

Dokumentator

6

Total Biaya

t e N

7 8

a r d

9

n e H

Total Tenaga Ahli

II. PERANGKAT KERAS (HARDWARE) No. 1

By

Harga Satuan

Spesifikasi IBM Zeon 3,2 Giga

1

Total Biaya

Server

2 3 4 5 6 7 8 9 10 Total Perangkat Keras (Hardware) III. PERANGKAT LUNAK (SOFTWARE) No. 1

Harga Satuan

Spesifikasi Microsoft Window 2000 Profesional

1

NOS

Total Perangkat Lunak (Software)

Total Biaya


IV. OVERHEAD No.

1

Harga Satuan

Item

2

Orang

2

PP

2

Orang

14

Hari

1

Paket

6

Bulan

Modul Pelatihan

10

Salinan

User Guide

5

Salinan

Analisis Kebutuhan

2

Akomodasi Analisis Kebutuhan

3

Overhead Kantor Alat Tulis Kantor (ATK)

4

Total Biaya

Transportasi

Pelatihan

Total Overhead

t e N

V. MAINTENANCE No.

Item

1

Hardware

2

Software

n e H 1

By

a r d

1

Paket

12

Bulan

Paket

12

Bulan

Harga Satuan

Total Maintenance

Biaya Pengembangan Sistem Informasi Biaya PPN

10

%

Biaya PPH

1,5

%

Total Biaya Pengembangan Nama Sistem Informasi

Total Biaya


3.7 Rencana Pekerjaan Deskripsikan dengan menggunakan WBS (Work Breakdown Structure), baik dalam bentuk inverted tree maupun list format. Bisa lihat slide pretemuan 3

3.8 Jadwal Pelaksanaan Gambarkan dalam bentuk Gantt Chart #

Kegiatan

April 3

Mei 4

1

1 Pengajuan Proposal 2 Analisis & Desain 3 Implementasi 4 Debugging & Testing 5 Dokumentasi 6 Demo & Penilaian

t e N

a r d

By

n e H

2

3


BAB IV PENUTUP

Berisi harapan agar bisa diterimanya dokumen proposal ini, dan ditegaskan dengan komitmen untuk mewujudkan keinginan pemilik proyek. Ringkas dan profesional.

t e N

a r d

By

n e H

MANAJEMEN PROYEK SISTEM INFORMASI Politeknik Piksi Ganesha By HendraNet By HendraNet

Recommend Documents