PERENCANAAN PROYEK SISTEM INFORMASI DAN ATAU PIRANTI LUNAK

PERENCANAAN PROYEK SISTEM INFORMASI DAN PIRANTI LUNAK

oleh: Tumar

Proyek Pengembangan Sistem Informasi dan atau Piranti Lunak dapat disamakan dengan proyek pembangunan konstruksi rumah tinggal misalnya. Kemungkinan proyek-proyek langsung sukses adalah proporsional yang memerlukan kehati-hatian dalam perencanaan, perancangan, pemilihan kontraktor atau konsultan, pemantauan yang ketat pada waktu konstruksi, serta lebih dulu memeriksa ulang produk yang dihasilkan sebelum diterima.
Bagian ini memusatkan pada perencanaan proyek sistem informasi dan atau piranti lunak, ini meliputi tugas yang sulit kemungkinan teknisi proyek yang menyelesaikannya adalah staff yang diberi kuasa, kuasa yang diberikan sesuai dengan standar perusahaan proses pekerjaan diteruskan sampai selesai. Pembuatan fungsi adalah analog untuk :

1. Memustuskan apakah sebuah rumah akan mempunyai 3 atau 4 kamar tidur, garasi dobel atau tunggal, ruang keluarga atau ruang kecil dan memutuskan bagaimana besarnya rumah
2. Persiapan rancangan konsep (modern, gaya Inggris Tudor, klasik atau meniru rumah tradisionil)
3. Persiapan layout awal, termasuk didalamnya

3.1. ESTIMASI BIAYA
Keadaan kelemahan sebagain besar pada pengembangan sistem informasi dan piranti lunak adalah tidak konsisten dan spesifikasi tidak lengkap diupayakan persyaratan sistem dan persyaratan ini diterjemahkannya kurang baik dalam estimasi biaya, estimasi waktu dan perangkat keras komputer yang disyaratkan untuk pengembangan dan dukungan sistem. Masih diupayakan lebih rendah adalah seringkali patuh kepada inisial proyek apa saja yang lain dari siklus pengembangan. Sebagai hasilnya yang tak terhitung proyek sistem informasi dan atau piranti lunak mendapatkan biaya besar dan batas waktu melebihi ketentuan yang telah ditentukan, pada prinsipnya aturan yang umumnya disetujui dua kali estimasi biaya inisial piranti lunak apa saja.

Maksud pada bagian ini adalah untuk memberikan pengertian yang baik tentang proses pertimbangan biaya untuk memilih piranti lunak oleh karena biaya pengembangan piranti lunak mendapatkan taksiran yang tepat. Mengalikan / melipatgandakan berkembang biak oleh dua peraturan, bilamana aplikasi piranti lunaknya memperoleh kompetitif, itu juga kurang baik dalam proses negoisasi. Dengan dikembangkannya dengan teliti perencanaan pembiayaan aktivitas, ini adalah taksiran kasar yang akan diganti dengan cepat sesuai aturan yang berlaku. Mendatang tak pernah tepat apa lagi memberikan kredibelitas sebagai data pendukung.
Deskripsi berikutnya taksiran biaya akan pegang peran utama untuk memeriksa banyak pertimbangan itu yang berpengaruh kuat pada biaya pokok pengembangan piranti lunak. Lalu data pendukung dan peralatan itu membantu proses penaksiran yang telah didiskusikan, berikutnya ringkasan variasi model pembiayaannya dan dapat dipakai variasi tipe piranti lunak untuk menyelesaikan tugas yang sulit. Akhirnya, rangkaian estimasi biaya akan dibuat.

3.1.1 Pertimbangan Biaya
Proses estimasi biaya pengembangan piranti lunak adalah kompleks dan merupakan tugas yang sulit sebagai persyaratan rinci yang harus dimengerti faktor variasi yang berpengaruh kuat pada pembiayaan ini. Ini adalah contoh pendekatan atau alogaritma itu yang akan disediakan pada estimasi biaya sampai 10, 20 atau kegiatan 40%.
Estimasi biaya pengembangan piranti lunak termasuk problem-problem yang besar. Satu problem adalah resiko tingkat tinggi dan ketidak tentuan dalam estimasi. Suatu resiko dan ketidak tentuan adalah dasar utama atribut tabel untuk 3 faktor yaitu

1. Persyaratan adalah subyek perubahan,
2. Persyaratan inovasi selama proses pengembangan dan,
3. Resiko adalah yang melekat dalam proses pengembangan sejak terjadinya kesalahan, yang mana boleh iterasi disebabkan lebih dulu di luar aktivitas, adalah tak terelakan.

Setiap Faktor ini cenderung sampai pada kenaikan biaya pengembangan piranti lunak. Piranti lunak yang baik estimasi biayanya termasuk persyaratan pekerjaan konsultan, mengerti persyaratan yang akan dihasilkan, dan dengan hati-hati memanaj siklus pengembangan yang dipastikan sampai coding tidak dimulai lebih dulu rancangan piranti lunak sepenuhnya diluar pekerjaan verifikasi dan validasi.
Masalah utama yang kedua dalam estimasi biaya pengembangan piranti lunak adalah kekurangan akuratnya ukuran biaya pendahuluan sepenuhnya historis kuantitas biaya database. Tanpa referensi standar ini adalah hampir tidak mungkin akurasi biaya untuk proyek baru. Informasi yang tersedia biasanya tidak terorganisir atau menyebarkan pada tingkat keperluannya yang tepat untuk estimasi. Masalah ini dapat diselesaikan dengan sebaik-baiknya dengan ringkasan dokumen biaya yang disebarkan oleh manajer proyek untuk setiap upaya pengembangan. Prosedur untuk perekaman histori apa saja yang keseluruhannya tahap akhir rencana proyek. Dokumen pentahapan ini termasuk di dalamnya terdapat pembinaan sampai pada informasi penyediaan personil teridentifikasi dalam sesi 4.5
Banyak pengaruhnya faktor biaya pada proyek pengembangan piranti lunak dan setiap akan dievaluasi selama perkiraan biaya sampai pada kepastian bobot yang tepat adalah terapan estimasi biaya. Hubungan diantara beberapa faktor kunci (dibagi dalam empat kategori) dan ringkasan biaya pengembangan piranti lunak dalam gambar 3.1. paragrap selanjutnya mendefinisikan empat kategori

Faktor Persyaratan
Sebagai permulaan selekasnya, perhatian satu area dalam ketidak tentuan adalah badan perkiraan. Bagaimana piranti lunak akan mendefinisikan persyaratan ? Dua faktor itu yang dapat mempunyai pengaruh utama yang kuat dalam biaya pokok produk piranti lunak adalah :

1. Spesifikasi Kualitas dan
2. Persyaratan Stabilitas.

Spesifikasi Kualitas.
Suatu definisi persyaratan yang baik (dan dalam dokumennya Persyaratan Spefifikasi Piranti Lunak) adalah landasan yang dimengerti dengan baik apa yang akan didifinisikan. Difinisi tidak lengkap adalah penyebab utama biaya membengkak. Pengembang menterjemahkannya tak jelas/samar-samar, kurang baik penulisan persyaratan, paket harga piranti lunak dasar dalam penterjemahannya, dan prosesnya sampai dengan Tahap Rancangan Rinci atau masih lebih buruk, selama uji coba atau demonstrasinya itu diterima pelanggan atau pemakai itu menyadari bahwa piranti lunak tidak dapat dijalankan, menu interaktif diseleksi kemampuannya, kemampuan database mengalami kegagalan. Sementara kemampuannya ditolak dan kebebasan pengawas dalam berpikirnya (tak sampai menyebutkan reduksi /mengurangi ciri-ciri data, kemampuan menulis format laporan, dan perumusan basis data mendapatkan kembali ciri-ciri spesifikasi dalam persyaratan spesifikasi)
Usaha ekstra yang menghabiskan tenaga membulatkan persyaratan setelah Tahap Rancangan Rinci dimulai adalah satu kunci untuk suksesnya manajemen proyek. Ini juga merupakan satu kunci untuk keakurasian biaya piranti lunak. Mengerti tentang persyaratan adalah tahap pertama adalah proses pembiayaan piranti lunak (digambarkan dalam sesi 3.1.3). ini adalah sebagai dasar menganalisis banyak faktor tentang pembiayaan satu demi satu termasuk di dalamnya kesulitannya antara lain :

• Interface (antar muka)
• Size (ukuran)
• Tools (peralatan)
• Existing Software (Piranti Lunak yang ada) dan
• Database complexity (keruwetan basisdata)

Pembengkakan biaya setelah faktor kesalahan yang lain, betul-betul suatu kelemahan pada perkiraan ukuran piranti lunak atau keruwetan basis data. Bilamana benar-benar kesalahan yang disebabkan dari perkiraan yang tidak komplit atau spesifikasi tidak mencukupi persyaratan pada awal permulaan pembiayaan piranti lunak.
Perincian waktu sedikit sekali dalam persyaratan spesifikasi yang menimbulkan dua arti dalam interprestasinya, biasanya banyak peranan penting yang dihasilkan rinci dalam spesifikasi rancangan, agak adil dari pada fungsinya dan persyaratan yang ditunjukan. Ini tak ada gunanya memaksa peranan penting pengembang dan perubahan besar tanggung jawab rancangan sampai ke kostumer. Jika rancangan yang belakangan didapati tidak mencukupi, maka perancangan ulang tersebut harus dibayar oleh kustomer, sejak rancangan asli sebagai persyaratan spesifik.

Persyaratan Stabilitas

Terdapatnya persyaratan spesifikasi yang baik tidak menjamin suksesnya suatu proyek. Untuk proyek yang banyak persyaratan spesifikasinya baik, yang mana rancangan rinci adalah siap dirubah selama proyek berlangsung. Ini adalah istimewa betul urusan dalam perusahaan untuk proyek piranti lunak dan seringkali asal mulanya pertimbangan yang kritis organisasi piranti lunak oleh manajemen tingkat atas. Disetujuinya proyek sebagai dasar dalam perkiraan biaya dan penjadualan. Jika biaya tercapai dan jadual obyektif terpenuhi adalah direvisi bilamana persyaratannya diusulkan dirubah, ini dapat menghindari problem. Pertanggungan jawab manajer proyek adalah sampai mengerti persyaratan piranti lunak dan perubahan yang sampai di luar batas dalam perubahan persyaratan dasar. Manajer proyek waktu itu menegaskan biaya/ atau jadual berpengaruh kuat terhadap perubahan itu juga dapat memberikan evaluasi yang fair. Jika perubahan membenarkan penegasan perkiraan pada proyek, keputusan membolehkan dibuat untuk digabung. Maka perubahan yang dapat memikirkan persyaratan spesifikasi dan tergabung didalam rancangan, ini adalah penegasan yang dipikirkan dalam pembiayaan dan penjadualan proyek. Perubahan banyak hilangnya yang urgensi bilamana mereka dalam menegaskan mengenali proyek. Mekanisme ini, digunakan sebaimana mestinya, pertolongan mengurangi perubahan sampai kebutuhan persyaratan dan menghapuskan “ keinginan” individu dalam organisasi konsumen.

Dampak serupa perubahan persyaratan yang dibutuhkan tidak diperhatikan oleh estimator biaya, dan perusahaan memilih manajer proyek yang disediakan dengan pendekatan seluruhnya sebagai gambaran tersebut di atas. Bagaimanapun, estimator itu harus realistis akan adanya beberapa perubahan yang disyaratkan. Pertimbangan akan diberikan untuk level perubahan aktivitas yang diharapkan bilamana ketentuan kontrak dibatasi kebutuhannya untuk inisial proses dan perubahan dan bilamana memilih tipe kontrak (i.e. fixed price/harga tetap atau cost reimbursement/ biaya yang dikeluarkan). Estimator biaya akan mengerti biaya keseluruhan proyek dengan ketetapan perubahan kontrak, dan manajer proyek harus tahu yang mana perubahan adalah dalam lingkup kontrak dan yang lainnya tidak.

Faktor Produk
Kedua faktor kategori itu mempengaruhi pembiayaan itu termasuk memperoleh faktor dari karateristik produk piranti lunak diserahkan untuk dikembangkan, termasuk didalamnya kode dan dokumentasi. Untuk mengevaluasi faktor ini persyaratan piranti lunak harus dianalisis dan definisi fungsi piranti lunak tersedia. Dari definisi ini kebutuhan data sampai evaluasi enam faktor produk dapat diserahkan. Faktor ini adalah didiskusikan di bawah.

Ukuran Piranti Lunak (Software Size)
Satu model yang sama sebagian besar pembiayaan piranti lunak adalah sampai perkiraan jumlah instruksi sampai pengembangan dan perkalian dengan jumlah dollars per instruksi sampai diperoleh perkiraan biaya pengembangan. Ini adalah sangat tidak tepat teknik estimasinya bilamana digunakan sendirian. Tapi bersama dengan faktor yang lain ini dapat sangat berguna.
Banyak estimasi itu menyentuh ukuran piranti lunak adalah satu sumber kesalahan yang besar dalam proses perkiraan biaya. Untuk alasan ini, proposal tentang prosedur pembiayaan dalam Sesi 3.1.3 menegaskan dekomposisi piranti lunak sebagai bantuan untuk memproses estimasi ukuran. Mengurangi tugas estimasi sampai jumlah besar tepat lagi dari pada estimasi tunggal. Pertimbangan ukuran yang signifikan adalah sebagai berikut :

1. Ketelitian yang harus diberikan sampai pada isolasi untuk memberikan kewenangan pada piranti lunak yang tidak diberi kewenangan uji piranti lunak, simulasi. Dan dukungan piranti lunak yang mana akan mahal harganya sehingga produk kurang.
2. Walaupun ini adalah telah disetujui biasanya ukuran piranti lunak adalah relatip singkat sampai pembiayaan, faktor lain, seperti kompleksitas, antar muka, dan termasuk banyaknya orang, mulai berpengaruh besar dalam ukuran peningkatan pembiayaan.
3. Bilamana percobaan sampai menggunakan ukuran sebagai parameter pembiayaan, ketelitian itu harus diambil yang digunakan sebagai dasar pembiayaan adalah yang berasal dari ukuran parameter yang sama. Proyek atau perusahaan bisa mengeluarkan biaya antara lain :
   · Line of code (LOC),
   · banyaknya obyek instruksi,
   · banyaknya sumber statemen eksekusi
   · Total instruksi atau
   · Pengembangan line of code (LOC) atau
   · Penyampaian instruksi kode garis.
4. Bilamana ukuran digunakan faktor pembiayaan, juga akan memberikan pertimbangan sampai produktivitas yang berbeda diantaranya bahasa. Untuk latihan, tidak seluruh HOLs (Hight Order Language) dapat digunakan fasilitas yang sama atau untuk seluruh aplikasi.
5. Bilamana perkiraan obyek berukuran kode adalah dasar dalam piranti lunak yang ada serupa, pertimbangan yang akan diberikan sampai pada perbedaan dalam ratio perluasan dari sumbernya sampai ke obyek instruksi diantaranya perbedaan HOLs, kompiler untuk HOL sama, atau perbedaan sistem operasinya.
6. Ukuran bertambah, banyaknya individu, termasuk didalamnya pengembangan bertambah dan jumlah waktu yang dipakai dalam antar komunikasi dan koordinasi kembali signifikan, pergerakan biaya lawan ukuran persanaan satu tingkat (linear) terhadap beberapa perkalian tingkat tinggi. Dalam buku ini , Mythical Manmonth (Addison Wesley Publshing Co., 1975). Membolehkan status pertambahan adalah eqivalen ke n (n-1)/2, bilamana n adalah banyaknya tugas terpisah sampai ke koordinasi. Terlalu banyak pihak luar dalam partisipasi sistem yang besar sebab membolehkan upaya komunikasi sampai menguasai untuk tingkat pertambahan proyek staff dapat diperpanjang, tidak pendek, jadual (i.e., pertambahan biaya)

Kesulitan (Diffisultty)
Relatip sulit aplikasi piranti lunak adalah satu kepentingan lagi faktor yang mempengaruhi biaya pengembangan. Personil yang memproduksi piranti lunak bervariasi tipe sistem pengembangannya. Beberapa tipe aplikasi cenderung sampai pada kesulitan yang lain. Untuk latihan, sistem operasi cenderung sampai pada dua atau tiga sama dengan kesulitan waktu diaplikasikan atau utilitas piranti lunak.
Tipe piranti lunak berfungsi, sebagaimana real-time input/output, sekumpulan /sejumlah, atau perhitungan, juga signifikan berpengaruh pada kesulitan pengembangan. Aplikasi Real-Time biasanya dipertimbangkan biayanya sampai lima waktu sesungguhnya HOL, aplikasi Real-Time
Setelah dipertimbangkan kesulitan relatip bervariasi sistem pada piranti lunak dan fungsinya, perkiraan biaya harus mempertimbangkan kesulitan aplikasi spesifik dan ini adalah warisan sampai analisis komplit sampai faktor kesulitannya. Perusahaan mewariskan perbedaan biaya diantaranya pengembangan piranti lunak baru atau modifikasi atau beradaptasi dengan piranti lunak yang ada.

Persyaratan Tahan Uji (Reliability Requirement)
Persyaratan tahan uji dibatasi perhatiannya keperluan piranti lunak yang dapat digunakan dalam lingkungan operasi sesungguhnya. Untuk piranti lunak yang mana mengalami kesalahan dapat diterjemahkan kedalam sistem yang merupakan bencana besar kegagalan atau kerugian kehidupan manusia, banyak lagi persyaratan uji daripada penggunaan program sebagai alat belajar (untuk yang mana pengaruh yang kuat dalam kesalahan adalah kurang signifikan). Dengan cara yang sama, untuk piranti lunak yang mana mengalami kesulitan hendak diperlakukan seperti di atas atau tak mungkin dimodifikasi sejak dinstal dalam lingkungan operasi, banyak diteliti lagi persyaratan uji program. Oleh karena itu, persyaratan tahan uji adalah selalu diperlukan sekali kualitasnya, derajat kepentingan untuk kesuksesan membolehkan perubahan aplikasi piranti lunak. Ini adalah empat kriteria utama untuk pembatasan persyaratan tahan uji program piranti lunak antara lain:

1. Memberikan kelancaran / kontinyu pada pengoperasian di bawah kondisi nononminal ;
2. Utilitas rancangan seragam, teknik implementasi, dan catatan ;
3. Hasil persyaratan ketelitian kalkulasi dan keluaran dan,
4. Dalam Implementasi dapat dimengerti caranya.

Pertambahan dalam tingkat persyaratan untuk menahan kondisi nonnominal kemauan ditambah di pertengahan dalam persyaratan upaya verifikasi dan oleh karena itu biaya.

Antarmuka Eksternal
Kualitas keruwetan antar muka berpengaruh dalam pembiayaan yang diilustrasikan dalam Gambar 3.1. Pengaruh lebih lanjut adalah dibuat-buat oleh pengembang yang berpengalaman dengan antarmuka. Perangkat keras baru antarmuka atau maksud spesial perlengkapan antarmuka yang baik sebagai syarat lagi antara lain :

1. Rancangan
2. Implementasi, dan
3. Usaha penggabungan,
4. Oleh karena itu biaya bertambah

Persyaratan Bahasa (Language Requirement)
Biaya pengembangan program bahasa mesin adalah terkenal lebih dari itu programnya sama dalam HOL. Pemeliharan program bahasa mesin yang juga mahal- mahal. Digunakannya rancangan bahasanya diperlihatkan sampai pertolongan pengurangan waktu persyaratan dalam programming dan sampai menyediakan struktur yang baik dan dokumen kode.
Kegiatan gagasan suatu statement HOL dan lagi sangat kuat karena itu kompilasi lagi dari suatu instruksi bahasa assembly, pengalamannya itu diperlihatkan ini rata-rata diberikan programmer kira-kira sama jumlahnya sampai usaha penulisan sebuah line of code dalam High Order Language (HOL) dalam bahasa assembly rupanya gagasan persyaratan sampai penulisan statemen tunggal adalah hampir independen yang mana ditulis dalam bahasa statemen. Ini akan diberikan programer sangat penting sampai penulisan suatu program yang panjang dalam bahasa assembly dari pada kemauan untuk menulis program yang sama dalam HOL, sejak kekhasan HOL memberikan statemen perluasan sampai 5 – 10 statemen bahasa assembly. Ini akan dicatat selekasnya dalam sebuah proyek keakraban programmer dengan bahasa akan mempengaruhi lagi biaya per statemen dari bahasa yang digunakan.

Persyaratan Dokumentasi (Dokumentation Requirement)
Baru saja sebagai faktor ukuran piranti lunak :

• Kesulitan dan,
• Spesifikasi kualitas

Harus dievaluasi oleh cost estimator, kumpulan faktor biaya dengan persiapan dan penerimaan persyaratan dokumentasi juga harus dievaluasi. Kedua-duanya pelanggan yang menentukan persyaratan dokumentasi dan persyaratan dokumentasi oleh manajemen proyek sebagai bagian pendekatan pengembangan harus diseleksi maupun dipertimbangkan.

Faktor Proses (Process Factors)
Pembiayaan sekumpulan faktor piranti lunak dengan proses pengembangan nya, sebagaimana seperti dibawah ini :

• Struktur Management (Management Structure )
• Pengawasan Manajemen (Control Management)
• Metode Pengembangan (Development Methode)
• Perlatan (Tools)
• Piranti Lunak yang Tersedia (Available Software)
• Basis Data (Database)

Faktor Sumber (Resource Factors)

• Banyaknya Orang (Number of People)
• Orang yang Berpengalaman (Experience of People)
• Perilaku Personil
• Tersedianya Sumber Komputasi (Availability of Computing Resource)
• Sumber Komputasi yang Serasi (Suitability of Computing Resource)
• Lewat Waktu (Elapsed Time)

Struktur Manajemen (Management Structure )
Struktur Manajemen gabungan berpengaruh berbagai kebijakan perusahaan dengan respek mengalokasikan biaya tertentu non-proyek personil manajemen sebagai harga langsung untuk proyek. Untuk perusahaan dengan organisasi matriks, harga proyek ini untuk manajemen line harus dipertimbangkan bilamana tawar menawar. Harga ini adalah seringkali tergabung sebagai presentase pada perkiraan langsung biaya tenaga kerja teknisi. Standar biaya akuntan pemerintah seringkali diatur yang dapat diterima langsung praktis dalam area-nya.

Manajemen Pengendalian (Control Management)
Dengan Struktur Manajemen adalah sebagai suatu fungsi kebijakan perusahaan. Biaya ini ditutup pendukung proyek yang sedemikian area-nya sebagai pengolah manajemen sistem informasi,

• Dukungan jadual
• Dukungan administrasi,
• Dukungan clerk

Untuk banyak perusahaan beberapa atau seluruhnya ini adalah dipertimbangakan fungsi overhead dan karena itu dipisah yang selanjutnya dipilih oleh pembuat perkiraan biaya. Untuk lain perusahaan jenis ini boleh dipertimbangkan langsung biaya untuk proyek. Dalam kasus ini parameter yang digunakan untuk perkiraan biaya ini biasanya adalah pengalaman sebagai dasar dalam perusahaan dengan proyek sebelumnya. Perkiraan biasanya adalah akan memberikan dukungan organisasi. Bagaimanapun untuk pertanyaan yang tepat perkiraan biaya, perkiraan biaya piranti lunak harus disadari keperluan ini untuk masukan dan mempunyai beberapa pengertian yang besarnya relatip biaya proyek tipe ini.

Metode Pengembangan (Development Methode)
Faktor ini subyektif dan sulit untuk memasukannya karena kekhasannya perbandingan penyimpanan data. Faktor ini mencoba mengukur berbagai macam pengaruh yang kuat sebagai metode pengembangan. Ini biasanya akan membayangkan konsep yang telah diterima itu sistematis lagi, metode struktur biaya, kekuatan yang kasar metode pengembangannya. Metode pengembangan yang interes termasuk di dalamnya seperti pendekatan top-down racangan dan uji coba, struktur program, menggunakan ketua tim programer, dan menggunakan struktur siap jalan. Untuk informasi lagi dalam memanaj proyek ini digunakan metode-metode.

Peralatan (Tools)
Dengan diterima angka pertumbuhan komputer mini dan berbasiskan sistem microprocessor yang telah dikembangkan. Faktor ini pantas makin bertambah jumlahnya penting. Memperkirakan biaya harus mempertimbangkan bagaimana piranti lunak akan dikembangkan, uji coba dan pemeliharaannya dan peralatan itu akan dibutuhkan untuk menyempurnakan tugas ini. Untuk pengembangan komputer yang berskala besar seperti host kompiler, manajemen basis data, editor, paket display antarmuka (interface), paket flow chart, paket plot, utilitas routin, dan uji data sesuai dengan generasi peralatan biasanya disediakan. Biaya untuk mengembangkan peralatan adalah untuk proyek tunggal akan menjadi penghalang. Pada umumnya mereka adalah menyediakan komputer dari pemberian atau sumber lain yang biayanya minimal. Bagaimanapun juga situasi ini adalah tidak untuk pengembang piranti lunak dalam komputer kecil dan mikroprosesor. Untuk pengembangan beberapa proyek piranti lunak dan peralatan perangkat keras adalah jenis biaya utama/pokok perkiraan biaya harus dibatasi apakah kompiler dan peralatan lainnya adalah persyaratan, disediakan, untuk keperluan konversi atau keperluan pengembangan. Pengujian peralatan secara benar-benar sebagai simulator,

• pengujian data generator,
• pengurangan data program,
• pengujian driver, atau
• simulasi bahasa komputer

persyaratan membolehkan. Ini adalah tidak untuk pengembangan yang luar biasa dua atau tiga waktu banyaknya perintah line of code (LOC) sampai pada dukungan pengembang dan pengujian aktivitas. Ini cara yang spesial terhadap ketelitian yang akan diambil bilamana digunakan sebagai teknik dasar perkiraan biaya dalam dolars ($) per perintah instruksi. Faktor ini membolehkannya yang berasal dari dalam proyek yang mana sangat sedikit dukungan pengembang piranti lunak adalah persyaratan. Total banyaknya instruksi untuk seluruh kode yang timbul mungkin diperlukan untuk perkiraan lebih dulu digunakan faktor perkiraan yang disediakan dalam literatur piranti lunak saat ini.
Sekumpulan biaya dengan peralatan adalah fungsi pada keruwetan peralatan, pengguna, keistimewaan, dan batas waktu. Pengalaman memberikan dasar yang terbaik untuk menganalisis biaya yang berpengaruh kuat mendukung piranti lunak dan peralataanya pada biaya proyek keseluruhan. Perkiraan biaya yang seterusnya akan dipikirkan pengembangan persyaratan peralatan yang tahapannya sama (ringkasan dalam Bab 2 dan princiannya digambarkan dalam Bagian II) sebagai pengembang menyampaikannya produk piranti lunak atau, lebih dulu kegiatan dengan tak respon diimplementasikan.

Piranti Lunak Yang Tersedia (Available Software)
Siginifkan mengurangi biaya proyek dapat tercapai diantara penggunaan piranti lunak yang sudah ada. Untuk aplikasi komersil banyak, paket harga yang tersedia rendah dan dapat tergabung kedalam pengembangan sistem. Demikian pula, paket scientific, pemerintahan dan aplikasi ruang angkasa telah tersedia. Adaptasi piranti lunak yang ada sebagai bagian persyaratan analisis sistem pada piranti lunak dari bagian yang baru dikembangkan. Biaya modifikasi piranti lunak yang ada dapat dibatasi subyektifnya. Pemeliharan harus diberikan sampai termasuk di dalamnya biaya antarmuka modifikasi piranti lunak untuk piranti lunak baru dan divalidasi ulang modifikasi komponennya.

Basis Data (Database)
Ukuran, keruwetan, dan spesial file persyaratan access untuk basis data adalah luar biasa penting parameternya dalam memperoleh keakuratan perkiraan pengembangan piranti lunak. Perkiraan biaya harus memberikan tinjauan persyaratan basis data dan subyektivitas analisis yang berpengaruh kuat terhadap pembiayaan. Sayang faktornya tidak simpel, sebagaimana biaya per instruksi untuk kode, pengembang mempunyai taksiran biaya yang berpengaruh kuat pada keruwetan basis data.

Faktor Sumberdaya (Resource Factors)
Kategori akhir faktor biaya meliputi faktor unik sumber itu pengaruh final pada pembiayaan piranti lunak. Biaya pengembangan untuk paket piranti yang diberikan diperbolehkan merobah banyak sekali, kepercayaan sehingga pengalaman sebagai faktor yang tersedia pada manusia, kualitas staff proyek dan tersedianya sumber pengembangan komputer. Sumber faktor yang lain diberikan pengetahuan yang dalam tambahan kedalam perbedaan antara proyek, independen faktor pembiayaan selalu dibuat yang lain dalam tiga kategori. Ini berhubungan sampai perbedaan produktivitas diantara besar kecilnya proyek dan tidak samanya jadual proyek.

Banyaknya Orang (Number of People)
Kontribusi utama untuk pengurangan dalam seperangkat produktivitas (peningkatan biaya) proyek itu persyaratan besarnya staff adalah pertambahan dalam waktu yang diperlukan untuk berkomunikasinya diantara orang-orang. Faktor ini adalah cepat didiskusikan selama mempertimbangan ukuran piranti lunak (Gambar 3.1).

Orang yang Berpengalaman (Experience of People)
Data dari kedua-duanya baik besar maupun kecilnya proyek disana itu berindikasikan langsung korelasinya diantara tahun pengalaman pada personil dan daya produksi. Bagaimanapun juga perkiraan biaya harus mempertimbangkan umumnya persyaratan tingkat pengalaman dan ketrampilan untuk bermacam tugas proyek dan memasukannya upah tenaga kerja yang cocok kedalam perkiraan. Menjadi tanggung jawabnya, pengalaman dengan spesifik aplikasi tidak mempengaruhi upaya persyaratan pengembangan. Pada umumnya, grup programming akan mempersyaratkan 50-100% lagi upaya untuk dikembangkan program pada lazimnya area sampai dikembangkannya program berlainan yang terkenal sebelumnya berkembang.

Kinerja Personil (Personnel Performance)
Satu faktor dalam piranti lunak dasar pembiayaannya untuk yang berlainan besar juga adalah tingkah laku personil atau daya produkvitasnya. Sejak pengembangan piranti lunak adalah dianalisis, beberapa kreasi aktivitas disyaratkan pemikiran yang abstrak, daya produktivitas individu berlainan adalah yang diharapkan. Bagaimanapun, pemerkira berpengalaman berlainan penemuannya daya produkvitasnya sama tingginya dengan 10:1. Daya produktivitas taksirannya adalah luar biasa penting karena perkiraan biaya biasanya adalah dikurangi untuk memperoleh gambaran daya upaya produktivitas per unit (jam atau bulan) per orang untuk kategori ketrampilan yang telah diberikan. Sehingga rata-rata digunakannya gambaran produkvitas untuk perkiraan yang cenderung sampai pada luar kegiatan untuk proyek yang besar. Jika satu atau dua personil menentukan untuk proyek kecil (empat atau enam orang) proyek dalam penyelesaiannya lambat skala produksinya, yakin jelas tertutup. Oleh karena itu, dalam proyek kecil faktor ini akan diberikan pertimbangan spesial, mungkin oleh orang yang menganalisis subyektivitasnya dengan menentukan suatu faktor produktivitas pada group ini.

Tersedianya Sumberdaya Komputasi (Availability of Computing Resource)
Seringkali faktor diabaikan dalam perkiraan biaya adalah tersedianya sumber komputasi untuk mendukung proses pengembangan. Sebagai persyaratan waktu komputer bertambah selama siklus pengembangan, pengaruh yang cukup kuat adalah sumber perhitungan pada jadual dan biaya bertambah. Untuk sejumlah pengembangan sistem ini hubungannya linier diantara biaya perubahan waktu uji coba. Pengembangan yang interaktiv sistemnya signifikan dikembangkan efisien adalah kerapkali tercapai.
Dalam penjumlahan pengaruh yang kuat untuk disediakannya sumber komputasi dalam pengisian staff dan jadual (oleh karena biaya), pemeliharaan harus diambilkan sebagaimana mestinya yang memasukannya kedalam kelompok biaya yang diberikan pada sumber komputasi. Banyaknya persyaratan waktu untuk komputer yang telah diberikan pengembang agar dengan mudah diupayakan di bawah perkiraan. Banyaknya penambahan persyaratan yang kapabel sampai dukungan pengembangan diupayakan lagi persyaratan operasi. Bilamana komputer diluncurkan adalah bagian dari upaya pengembangan sistem. Ini rata-rata komputer itu dapat bertambah sampai diluncurkannya, dibolehkannya sampai pengakuan serta dukungan diupayakannya pengembangan. Data dari pengembangan yang mirip diupayakan diberikan dasar yang terbaik untuk perkiraan ini. Yang sangat mengherankan data ini adalah seringkali hilang. Mereka tidak sebagaimana mestinya dicactat/ direkam dan memisahkannya selama pengembangannya tidak dilaporkan (dengan terperinci akan diberikan yang bermanfaat biaya basis data) secara lengkap/komplit. Penyimpanan dan pelaporan data tipe ini adalah didiskusikan dalam Bab 4. (sesi 4.5).

Sumber Komputasi yang Serasi

Efek asimtot (garis lurus yang mendekati kurva) dalam biaya pengembangan sebagai kecepatan perangkat kerasnya dan memaksa ukuran memory adalah pendekatannya yang telah didemonstrasikan sejumlah sistem antara lain:
· real time,
· pesawat udara,
· militer, dan
· sistem komersil

Efek ini cocok terutama melumpuhkan selama tahap pemeliharaan piranti lunak, bilamana diperbolehkan disediakan sedikit kapasitas untuk :
¨ koreksi,
¨ modifikasi atau,
¨ persyaratan uji coba sampai verifikasi perubahan.

Lewat Waktu
Penambahan kalender waktu disediakan sampai pengembangan piranti lunak berhasil yang relatip dengan baik sekali sampai biaya pengembangan terakhir. Kelihatannya ini sampai diambang batas jadual untuk setiap proyek. Di bawah ambang batas, meningkatnya persyaratan staff sampai menyelesaikannya sesuai dengan job dalam periode yang singkat lawannya efeknya menginginkan. Malahan jadwal yang pendek, ditambah lagi orang diperbolehkan meningkatkan

1. Keruwetan yang diupayakan oleh kesempatan yang diusahakan dimasukan kedalam elemen pekerjaan di bawah fungsi yang diuraikan secara jelas.
2. Persyaratan pelatihan pada penambahan personil,
3. Proyek komunikasi yang ruwet. Jaringan efeknya boleh sampai peningkatan jadual sama sumbernya dengan biaya.

Pembatasan jadual proyek diambang batas hampir sama kesulitannya dengan estimasi biaya. Banyak pengembangan yang rangkaian tugasnya dan tidak dapat sewenang-wenang dikompres atau reorganisasi. Pengertian tugas ini dan membuat rangkaiannya jelas ini memungkinkan sampai tugas estimasi yang minimum waktunya efektiv untuk merealisasikan perincian tugas. Ini adalah istimewa yang penting sekali sampai alokasi waktu yang cukup sampai pada persyaratan analisis rancangan. Rancangan tidak sempurna kebanyakan adalah murah dan mudah sampai penentuan posisi jika selekasnya ditemukan (selama aktivitas analisis) dari pada selama uji coba.
Perubahan dalam pendistribusian staf di luar usaha proyek dapat menghasilkan perbedaan biaya antara 10 – 20%. Profil staf yang optimum untuk memberikan upaya pengembangan yang dapat diperoleh dari rincian definisi tugas pengembangan dan hubungannya dengan jadual. Usaha khas jarak pendistribusiannya untuk aktivitas pengembangan adalah sebagai berikut :

• Analisis/rancangan 30 – 40%
• Coding dan chekout 10 – 20%
• Ujicoba dan penggabungan 40 – 50 %

1.1.2 Model Estimasi Biaya ( Cost-Estimating Models)
Model perkiraan biaya mengotomatisasikan perkiraan biaya : produktivitas data adalah terpelihara dalam basis data dan aplikasi sampai proses pembiayaan sesuai prosedur, otomatisasi jalan. Model otomatis mengurangi proses perkiraan sampai penilaian yang terbatas sekumpulan variabel biaya kritis. Hubungannya faktor lain sampai variabel-variabel yang belum ditentukan dalam model, demikian asal saja dalam elemen konsisten untuk perkiraan biaya. Begitu Otomatisasi digunakan parameter model perkiraan biaya untuk sistem piranti lunak yang besar dalam industri dan pemerintahan adalah pantas dan populer lagi. Oleh karenanya parameter-parameter yang diperlukan adalah sebagai berikut :

Parameter Model
Parameter Model untuk perkiraan biaya piranti lunak jelas mampu mengukur hubungan diantara biaya pengembangan piranti lunak dan banyaknya variabel biaya dari alogaritma atau sekumpulan alogaritma. Alogaritma yang diperoleh dari historis analisis data biaya dalam syarat-syarat sekumpulan variabel biaya. Perkiraan biaya baru waktu itu boleh dibuat oleh nilai perkiraan variabel biaya untuk sistem baru dan mereka sisipkan kedalam perkiraan biaya alogaritma (i.e.model parameter) diperoleh dari historis data. Biaya kepekaan sampai ketidak tentuan dalam spesifik variabel biaya dapat juga dianalisis yang dihasilkan sekumpulan biaya dasar yang perbedaannya diberikan dalam variabel. Mempelajari sungguh-sungguh adalah terutama sekali mudah, sejak model parameter adalah seringkali komputer dan mengijinkan secara relatip cepat perhitungan perkiraan biaya.

Validasi Model Parameter Bergantung Biaya
Validasi model parameter bergantung pada biaya yang berisi basis data contoh besarnya data sebanding. Penentuan pemeliharaan basis data adalah diperlukan sampai pengembangan model parameter. Ini adalah persyaratan pada kedalamannya ilmu pengetahuan proses pengembangan piranti lunak dan mengerti teknik statistik yang digunakan sampai memperoleh biaya alogaritma. Yang sebenarnya independen dan harus bergantung variabel pilihan dalam basis analisis data dari banyaknya proyek yang besar. Bilamana pemilihan variabel model, harus dipertimbangkan diberikan juga sampai dengan mudahnya yang mana variabel dapat teratur atau terukur.

Vadidasi Model Parameter akan didemonstrasikan
Validasi model parameter akan didemonstrasikan oleh beberapa orang proyek yang menggunakannya. Kejadian penting waktu itu, model-model adalah subyeknya sampai tak dapat dipercaya dan hasilnya bias. Bagaimanapun mereka harus mengerjakan, memberikan yang sangat berguna bilamana digunakan bersama dengan dasar metode perkiraan biaya rinci dalam rincian dekomposisi piranti lunak, atau bersama dengan lain dasar perkiraan dalam perbandingan data, dibawah aturan, dan teknik lain sebagai gambaran dalam sesi selanjutnya.

Banyaknya Parameter Model Biaya
Banyak parameter model biaya digambarkannya dalam literatur yang digunakan sebagai percobaan sampai memerikasa hasil perkiraan yang lain atau membuang bagian tengah proses pembiayaan satu lagi keadaan model adalah RCA PRICE model, banyak lagi sebagian besar yang digunakan oleh :
¨ Perusahaan dan
¨ Badan-badan Pemerintahan
Sampai memberikan prediksi biaya atau memeriksa kelayakan biaya proposal oleh kontraktor.


3.1.3 Prosedur Pembiayaan (Costing Procedure )
Dua alternatif utama yang ada untuk dikembangkannya biaya proyek pengembangan piranti lunak. Dalam perkiraan total biaya yang pertama didapat berasal dari beberapa cara, sebagaimana perbandingan dengan proyek yang serupa, dan waktu itu prosentase tepat dapat dialokasikan untuk setiap bagian pengembangan piranti lunak. Persentase dapat sebagai dasar pengalaman dengan proyek yang lain atau di bawah aturan, sebagaimana ditampilkan dalam sesi 3.1.1. Hasilnya adalah uraian perincian biaya sebagaimana kekuatan persyaratan untuk biaya proposal.
Suatu problem dengan pendekatan ini adalah mempercayai seluruh proses dalam satu inisial total biaya perkiraan. Ketelitian cukup dapat diambil sampai terjaminnya alokasi biaya adalah layak dan didukung oleh besarnya dasar histori data. Bagaimanapun, terjadinya jika alokasi adalah sepenuhnya jumlah perkiraan biaya resmi didapat oleh faktor atau kejadian dalam perintah penting. Ini adalah luar biasa sulitnya, jika tidak mungkin, sampai metode ini digunakan untuk biaya proyek. Bagaimanapun ini adalah baik untuk kecepatan “ball park” diperkirakan sampai dukungan pertama proyek dan rencana praproposal.. kecepatan perkiraan pada banyaknya waktu instruksi suatu faktor produktvitas (instruksi per orang – bulan) atau dollars per faktor instruksi dapat berhasil biasanya perkiraan biaya untuk perencanaan yang dimaksud, tapi tidak untuk perintah.
Prosedur kedua pembiayaan adalah pada dasarnya yang pertama terbalik. Proyek piranti lunak ini dekomposisi top-down sampai elemen fungsional piranti lunaknya diperkirakan dengan cukup kecil: itu adalah sampai mereka dengan cukup kecil untuk dimengerti baik berfungsi penuh sampai ukuran, evaluasi (lihat Faktor Proses dalam sesi 3.1.1), dan biaya.
Perkiraan biaya piranti lunak baik ternyata sampai koreksi dan termasuk didalamnya ditentukan dengan cukup sumber dukungan jika hanya pantas persiapan adalah dibuat setelah biaya diperkirakan. Ini termasuk didalamnya;

1. Proyek yang kadaluarsa kesulitannya dapat dikendalikan kedalam (Struktur pekerjaan diuraikan secara detail)
2. Upaya pengembangan dianalisis persyaratannya.
3. Mengidentifikasi resiko yang tercakup dan perencanaan untuk resiko manajemen.
4. Problem yang khas diantisipasi dan kelambatannya
5. Dukungan sumber daya yang diperlukan diidentifikasi

Sebagai dasar informasi ini jadual terperinci dan biaya informasi dapat tersedia, dan total perkiraan biaya proyek didapat lalu dikembangkan. Format ini sebagai dasar untuk manajemen proyek piranti lunak dan permulaan perencanaan proyek. Hasil definisi aktivitas proyek akan didokumentasikan dalam perencanaan proyek, yang mana baik giliran sebagai dasar untuk manajemen proyek.
Terlalu seringkali persyaratan informasi adalah berasal dengan tak resmi sekitar daftar. Figur biaya adalah diluar pengaruh pihak luar. Ini “sentuhan (feels) “ keliru, dan proyek adalah penyelesaian proposal pada harga itu “ baiklah biarkan lihat saja lamanya berapa tahun ini akan dikerjakan” .
Proyek itu dimulai tanpa ketegasan dasar perencanaan. Beberapa atau seluruh pertanyaan berikut adalah keliru untuk manajer proyek untuk diperjuangkan setiap saat :

1. Apakah ketrampilan dan disiplin merupakan persyaratan tugas ?
2. Tugas Pertama yang akan dimulai, barangkali diberikan prioritas, dalam perintah tugas itu tidak mempercayai yang lain dalam keluarannya / mereka yang mana ?
3. Apakah penjadualan terinci ? Konflik kecil hampir terjadi pada penugasan, personil, atau tersedianya kompoter ?
4. Apakah tingkat rancangan akan mempunyai peranan utama pada pemeriksaan ulang, jika pemeriksaan ulang adalah terjadual ?
5. Apakah tujuan manajer proyek untuk setiap pemeriksaan ulang rancangan? Siapa yang akan mengurus pemeriksaan ulang dan persiapan apakah persyaratan ini ?
6. Bagaimana banyaknya anggaran pada jaman komputer ? Berapakah jumlah anggaran setiap bulan ?
7. Apakah area resiko ? Bagaimana harus menggunakan perancang dan programer yang berkompetent ?
8. Dukungan peralatan pengembangan adalah persyaratan dan apakah oleh mereka diwajibkan menyediakannya ?
9. Komputer dan perangkat keras antarmuka waktu adalah pegang peranan penting yang akan berpengaruh dalam penjadualan pelbagai tugas yang mana ?
10. Apakah dokumen piranti lunak akan dihasilkan ?
11. Bilamana ? Oleh staff proyek yang mana ?
12. Bagaimana dokumen ini diperlukan untuk bantuan pengembangan?
13. Apakah tipe organisasi proyek adalah kebutuhan untuk mengatur yang baik ini ketelitian pengembangan ?
14. Standar apakah yang akan dipakai ?
15. Apakah rancangan dan teknik pemrograman akan digunakan oleh seluruh personil proyek ?

Seluruh pertanyaan seperti di atas telah ditanyakan dan terjawab selama proses estimasi biaya. Pertanyaan ini adalah meningkat sebagai bagian proses perencanaan dan dekomposisi. Mereka memerlukan persyaratan pengembangan dengan analisa yang rinci dan rancangan pendahuluan untuk dekomposisi dan proses pembiayaan dapat ditampilkan. Suntikan pada tahap pembiayaan rancangan pendahuluan adalah dibenarkan dalam pengembangan piranti lunak yang berteknologi tinggi, sejak fasilitas rancangan baru yang seringkali pengalaman di luar yang dikerjakan sistem analis dipersyaratkan analis dan berikut pembiayaannya. Untuk non kritis atau mengerti dengan baik aspek rancangan, ini adalah mungkin seringkali sebagai jembatan diantara gap persyaratan dan biaya sebetulnya tanpa dikerjakannya rancangan pendahuluan. Ini dapat diselesaikan oleh keputusan /penemuan sistem yang serupa keadaan parameternya tergantung dari biayanya (e.g., number of instruction, rate of input data stream, persent memory utilization, processor speed, etc.). Parameter ini adalah digunakan untuk men-generate (by analog) sebuah “ukuran sistem”, yang mana dibandingkan dengan kalibrasi data untuk yang lain sistem dan modifikasi yang tepat khusus untuk dipertimpangkan (inflasi, waktu, resiko dll). Sebuah rangkaian khusus untuk estimasi/prakiraan biaya piranti lunak didekomposisikan diberikan seperti berikut :

1. Definisi persyaratan piranti lunak.
2. Persiapan rancangan pendahuluan sampai tingkat detil hingga biaya yang dibutuhkan. Estimasi ukuran modul (banyaknya instruksi).
3. Definesi waktu terinci dan kebijakan pengembangan. Identifikasi asumsi ketergantungan.
4. Identifikasi pengembangan yang potensial atau masalah waktu dan elemen resiko pengembangan yang besar. Juga, pembatasan jika sistem yang akan menarik hubungan dengan kecepatan memori.
5. Definisi tugas pengembangan dan aktivitas sampai kinerja nya di dalam setiap penugasan, termasuk tinjauan formal.
6. Pembatasan upaya dan persyaratan tingkat pengalaman untuk setiap tugas. Perencanaan yang pasti untuk tenaga kerja yang ekstra dan biaya untuk tinjauan internal seluruh dokumentasi. Juga rencana dukungan sumberdaya manusia sampai konfigurasi kinerjanya fungsi pengendalian.
7. Estimasi usaha orang dalam jam, hari, atau bulan oleh tugas pengembang dan jumlah perbulan.
8. Estimasi pertemuan formal dan informal, perjalanan, waktu instalasi, dan dukungan pelatihan di tempat dan lain sebagainya.
9. Estimasi komputer waktu, dukungan grafik, dukungan clerk, reproduksi, dukungan biaya pengembangan yang lainnya.
10. Estimasi dikonversi ke dalam dolar per tugas dan perbulan.
11. Upaya dibuat yang relativ dan di cek biayanya. Bandingkan mengerti modul dengan baik untuk melihat jika biaya dan perbedaan pekerja adalah konsisten dengan perbedaan estmasi tingkat kesulitannya. Faktor pada masalah dan lokasi resiko. Pertimbangan seluruh faktor jumlah biaya pada gambar 3.1, (sesi 3.1.1) Cost Factors and Relationship.
12. Periksa konsistensi kinerjanya pada modul dan total estimasi biaya pengembangan piranti lunak.
    a. Per instruksi dalam dolar.
    b. Per orang bulan instruksi.

Per instruksi dalam dolar untuk total dan pada setiap modul konsisten dengan data dari proyek sebelumnya? Adalah dolar per instruksi perbedaan diantara modul konsisten dengan perbedaan pada kesulitannya, dan resiko? Presentasi alokasi biaya untuk dokumentasi konsisten dengan data dari proyek sebelumnya? Persen adalah alokasi dolar untuk persyaratan dan rancangan/kode/test yang konsisten? Bilamana digunakan pemeriksaan produktivitas, perhatian penerimaan mengharuskan dasar pemeliharaam bersama (i.c., sumberdaya vs kode obyek, kode baru vs kode eksisting, penulisan kode vs hasil kode, instruksi vs kata atau tanpa data base, dan lain sebagainya).
Gambar 3.2 dan 3.3, menyediakan contoh lembar kerja untuk definisi aktivitas dan biaya tugas pengembangan untuk membantu pada item 5 dan 7 seperti daftar tersebut di atas.

3.2 RENCANA PROYEK

Rencana proyek adalah sebuah dokumen yang menggambarkan bagaimana rencana manajer proyek memimpin pengembangan proyek piranti lunak.adalah harus terdefinisi terintegrasi tahapan waktu dan persyaratan sumberdaya hingga pertemuan berdasarkan perjanjian atau komitmen internal perusahaan. Memperhatikan kekurangan bagaimana mungkin proyek kecil, adalah membutuhkan sebuah perencanaan dengan jelas definisinya adalah pada kepandaiannya, menentukan siapa dan bilamana kinerjanya adalah baik, dan mengatakan bagaimana akan besarnya biaya. Rencana tidak menguraikannya, tapi pekerjaan harus terdefinisi tepat yang mana manajer proyek adalah bertanggungjawab dan metode untuk memastikan pekerjaan itu kinerjanya akan berhasil. Khususnya, Rencana Proyek akan menyelesaikan yang berikutnya :

1. Menyediakan Managemen tingkat atas dengan ringkasan proyek level tinggi.
2. Menyediakan manajer proyek dengan sebuah rencana dari awal sampai selesai untuk memonitor laporan dan alokasi sumberdaya.
3. Menyediakan pelanggan dengan pengertian yang sama dan memonitor laporan kemampuan.
4. Pelanggan berorientasi dokumen.
5. Garis dasar dengan persetujuan pelanggan dan pembaruan sebagai persyaratan karena proyek hidup.

3.2.1 Apakah dalam Rencana ?
Elemen esensi Rencana Proyek itu harus termasuk di dalamnya adalah seperti berikutnya :

1. Sebuah ringkasan tentang proyek itu dapat dibaca dan dimengerti setiap orang. Adalah kebutuhan yang pendek dan konsisten. Harus dengan jelas dibuktikan selesai diserahkan produk, mereka dapat memeriksa kembali rencana.
2. Sebuah daftar kejadian penting yang berlainan dibuktikan itu juga dapat dilihat.
3. Definisi yang jelas mana elemen perusahaan atau pelanggan piranti lunak standar adalah aplikasi pada proyek (e.g, dokumen untuk produksi, metode konfigurasi pengendalian pekerja dan lain sebagainya. Definisi ini harus rasional di dalamya
4. Tinjauan spesifikasi proses: Bagaimana tinjauannya proyek, bilamana, dan untuk maksud apa.
5. Rencana antar muka dipertunjukan bagaimana pelanggan, garis internal perusahaan, dan komunikasi organisasi staf dengan proyek.
6. Struktur pekerjaan terinci (Work Breakdown Structure/WBS) itu cukup terinci
7. Daftar personil kunci proyek dan penempatan mereka dalam hubungannya dengan WBS.
8. Aktivitas Network itu diperlihatkan rangkaian elemen waktunya dan bagaimana hubungannya. Network ini dapat diperoleh dari WBS dan daftar peristiwa yang penting. Untuk latihan, yang mana akan diperlihatkan elemen pekerjaan dapat berjalan parallel dan yang mana hanya dapat dimulai bilamana pekerjaan sebelumnya telah komplit.
9. Anggaran yang terpisah dan jadual untuk seluruh elemen yang mana untuk individu adalah bertanggung jawab.

Bagian 1 Pengenalan
Rencana Proyek akan diperkenalkan lingkup definisi, isi, dan rencana yang digunakan. Ringkasannya adalah proyek dan filosofi pengembangan. Ringkasan proyek itu juga laporan singkat, dengan lengkap diskripsi yang lainnya disajikan dalam bab berikutnya (Bb 3). Isi Pengenalan adalah memberitahukan pada pembaca maksud dan isi dasar proyek.

Bagian 2 Pengendalian Dokumen
Bagian ini berisi referensi seluruh spesifikasi, standar, dan berdasarkan dokumen perjanjian yang dapat dipakai untuk pengembangan proyek sistem informasi dan piranti lunak.

Bagian 3 Deskripsi Proyek
Deskripsi proyek dalam tinjauannya menyediakan aktivitas proyek, termasuk di dalamnya statemen pekerjaan, asumsi, produk yang diberikan, dan persyaratan yang tak diberikan sebagai dukungan produk. Statemen pekerjaan yang melukiskan lingkup pekerjaan sampai terselesaikan. Perincian seluruh definisi dan pengembangan tugasnya sampai dengan kinerjanya, termasuk tinjauan pendukung rancangan, dokumentasi tugas, dukungan tugas, sebagaimana simulasi pengembangan, manajemen operasi komputer, dan konfigurasi manajemen: dan tugas tambahan, sebagaimana pelatihan, dukungan operasi, dan pemeliharaan piranti lunak. Anggapan yang melekat Rencana Proyek dokumennya akan eksplisit dalam bagian ini untuk gambaran manajemen dan personil pelanggan. Sepertinya anggapan yang termasuk diperbolehkan :

1. Perangkat keras komputer adalah sistem yang dikembangkan.
2. Bahasa, sistem operasi, dan paket manajemen data untuk digunakan dalam pengembangan.
3. Lokasi dimana pada porsi terbesar akan kinerjanya proyek.
4. Fasilitas pengembangan yang disediakan oleh pelanggan, termasuk tersedianya tanngal dan kondisi sebagaimana pertukaran waktu komputer digunakan vs waktu yang terbaik, dengan sekumpulan yang rata-rata menetapkan perubahan waktu vs sekumpulan perubahan malam.
5. Pertanggunganjawab untuk menyediakan data yang teruji.
6. Data yang disediakan oleh pelanggan atau yang lainnya eksternal organisasi, termasuk persyaratan tanggal.
7. Dapat dipakai spesifikasinya dan data rancangan antarmuka.
8. Waktu yang kritis peristiwa penting.
9. Ketelitian dan persyaratan memori cadangan.

Spesifikasi piranti lunak, dokumentasi, dan selama layanan yang diberikan serta kesimpulan gambaran akan proek. Dokumen yang akan didefinisikan dalam isi syarat-syarat dan perincian tingkatan. Produk piranti lunak yang akan disampaikan terdefinisi dalam syarat-syarat kesanggupan pada referensi yang tepat persyaratan spesifikasinya. Sebagaimana menyediakan layananan pelatihan, pemeliharaan piranti lunak, atau dukungan operasi akan didefinisikan dalam syarat-syarat tanggal mulai, tingkat dukungan yang diberikan, dan periode dukungan. Tugas khusus sampai kinerjanya di bawah bagian pelayanan akan teridentifikasi oleh referensi pada statemen pekerjan. Criteria penerimaan untuk seluruh penyampaian produk harus didefinisikan. Dengan persetujuan pelanggan pada permulaannya tersimpan baik perjanjian konflik selamanya diantaranya manajemen proyek dan pelanggan pada kesimpulan proyek.

Bagian 4 Rencana Pengembangan
Bagaian ini berisi yang dihasilkan tugas analisis dan jadual aktivitas kinerja yang diperintahkan sampai pada biaya proyek. Sekarang adalah deskripsi rinci tugasnya dalam format Work Breakdown Structure (WBS). Elemen WBS adalah jadual dan alokasi biayanya. Jadual dan biaya (i.e., anggaran) juga akan masuk. Tugas yang disajikan pada WBS akan terdifinisi dengan perincian yang baik teridentifikasi tugasnya dalam Statement of Work (SOW) pada bagian sebelumnya. Biasanya syarat SOW yang disyaratkan pada analisis piranti lunak, rancangan program pendahuluan dan analisis, rancangan program terinci, coding, dan jua, sebagai identifikasi pada gambar 2.4 (Bab 2). WBS akan mendefinisikan tugas-tugas itu kinerjanya dapat oleh programmer individu atau analisis oleh grub kecil programmer atau analisis pada jangka pendek (beberapa minggu sampai beberapa bulan) yang dapat dipakai ukuran permulaan dan poinnya komplit.

Definisi tugas tambahan, bagian ini rencananya akan menidentifikasi persyaratan tingkat ketrampilan/skill untuk setiap tugas dan dalam estimasi kebutuhan sampai komplit tugasnya dalam jam, atau orang-bulan. Jadual dan hubungan timbal balik tugas yang diperintahkan yang mana mereka mereka harus melengkapi yang akan termasuk dalam format tugas jadual, network, dan atau critical parth charts. Jadual juga akan memerlukan tanggal (atau periode) untukseluruh persyaratan sumberdaya eksternal. Sumber daya ini boleh memasuki antarmuka perangkat keras, pelanggan-diperlengkapi data atau komputer waktu, spesifikasi persetujuan pelanggan, pengujian data dari sumber eksternal, dan digunakan menguji fasilitas pengendalian oleh pelanggan atau pada organisasi eksternal.

Rencana pengembangan juga akan memasukan rencana tenaga kerja dan anggaran informasi lagi yang mana proyek pada waktu-waktu tertentu dapat tinjauan. Data Tenaga kerja dapat ditampilkan dalam format chart yang penetapannya tugasnya diperlihatkan untuk individu dan tanggal yang mana untuk kelengkapan tugas. Anggaran informasi akan termasuk biaya estimasi per bulan dan per tugas yang besar. Anggaran akan memasukan buruh, clerical, perjalanan, komputer waktu, produksi dokumen, komunikasi, perlengkapan khusus dan pelayanan, serta beberapa biaya yang lainnya biasanya dialokasikan langsung pada proyek. Anggaran informasi boleh ditampilkan sebagai lampiran terpisah yang dibatasi jika ini adalah keinginan untuk menyediakan distribusi yang meluas dan digunakan Rencana Proyek dimana kekuatan kebijakan perusahaan mengijinkan jika data keuangan adalah masuk.
Topik akhir bagain rencana pengembangan adalah teridentifikasi jenis-jenis yang kritis atau resiko pengembangan. Resiko yang signifikan atau permasalahan lambatnya kekuatan atau membahayakan proyek akan disebutkan satu persatu. Inii tak akan lengkap daftarnya kemungkinan setiap permasalahan itu kami hubungkan, tapi akan diperjelas permasalahan yang berpotensi khusus untuk pertimbangan manajemen dan pelanggan.

Bagian 5 Persyaratan Pendukung
Bagaian ini akan mendefinisikan seluruh fasilitas pendukung, personil dan persyaratan aktivitas untuk proyek komplit. Fasilitas pengembangan Piranti Lunak, termasuk komputer-komputer, simulasi, kompiler, assemblers, sistem operasi, sistem manajemen data, kapasitas penyimpanan data akan diidentifikasi, menggambarkan dan penjadualan. Kebutuhan pendukung dari perusahaan personil dari luar proyek dan dari pelanggan atau asosiasi personil kontraktor yang akan digambarkan rinci sebagaimana kemungkinan.

Bagian 6 Proses Pengembangan
Bagaian ini akan menggambarkan pendekatan pengembangan yang digunakan dalam proyek. Deskripsi dapat memasukan informasi dalam sebagian tugas, penyiapan dokumen, tinjauan dan audit, pengembangan serta teknik uji coba seperti yang diperlihatkan pada bagian 2 buku ini. Sebagai kemungkinan lain, adalah akan diringkas seperti informasi pada cara yang ditunjukan dalam Bab 2 dan termasuk sebuah referensi untuk standar perusahaan pengembang itu berisi informasi yang diperlihatkan tingkatanya pada bagian 2. pada kasus yang belakangan, beberapa deviasi dari referensi standar perusahaan akan diperlihatkannya dasar kebenarannya dalam bagian ini Rencana Proyek.

Bagian 7 Organisasi Proyek
Rencana akan mendefinisikan :

1. Struktur organisasi yang digunakan untuk memanaj proyek;
2. Antar muka organisasi proyek dengan organisasi perusahaan;
3. Antar muka organisasi proyek dengan staf perusahaan dan fungsi administrasi, sebagaimana kontrak, akuntan,konfigurasi manajemen, dan jaminan kualitas;
4. Antar muka personil proyek dengan pelanggan dan personil asosiasi kontraktor;
5. Tanggung jawab dan wewenang manajer proyek dengan respek untuk teknisi dan bahan dasar perjanjian;
6. Tanggung jawab dan wewenang personil proyek kunci. Beberapa organisasi merubah rencananya yang berbeda tahap proyeknya juga akan diperlihatkan.
   

Bagian 8 Standar Pengembangan
Bagian ini akan meringkas standar pengembangan untuk diaplikasikan pada proyek. Beberapa standar boleh khusus yang direferensikan yang dapat tersedia. Dimana interprestasi persyaratan, sebuah catatan akan termasuk pada bagian ini.

Bagian 9 Rencana Subkontraktor
Jika subkontraktor atau konsultan akan digunakan, bagian ini akan menggambarkan tugas-tugas untuk subkontraktor dan prosedur pemilihan yang digunakan. Dimana subkontraktornya telah telah terpilih, subkontraktor Rencana Proyek mitra setelah rencana ini akan dimasukan sebagai lampiran, separately bound if appropriate.

Bagian Tambahan

Bagian tambahan akan dimasukan dalam Rencana Proyek sebagai penutup yang mana topiknya jaminan kualitas, konfigurasi manajemen, pemeliharaan, piranti keras dan piranti lunak terintegrasi, persyaratan keamanan, fakta-fakta untuk keperluan pengembangan.

3.2.2 Penggunaan dan Memperbarui Rencana
Banyak piranti lunak yang kompetitiv berusaha memperoleh versi pendahuluan Rencana Proyek adalah dipersyaratkan sebagai bagian pengembangan proposal. Untuk proyek yang lainnya rencana adalah satu yang pertama item-item bisa disampaikan, karena biasanya dalam minggu pertama sedikit. Estimasi/prakiraan biaya yang pantas dimasukan dalam persiapan yang terbanyak rincian tugas dan jadual informasi persyaratan untuk Rencana Proyek, itu juga disampaikan dalam rencana minggu pertama sedikit adalah tidak masuk akal. Seringkali permintaan pelanggan itu baik yaitu inisial yang disampaikan dimasukan dalam rencana yang terinciuntuk kontrak tahap pertama, barangkali hingga Tinjauan Rancangan Pendahuluan. Waktu itu tambahan yang disampaikan adalah prioritas jadual untuk permulaan setiap tahap sub rangkaian. Ini pendekatan keamanan manajer proyek untuk tinjauan rencana dan memperbarui waktu-waktu tertentu sebagai definisi baru piranti lunak dan rincian pengembangan kembali tersedia.
Apa saja persyaratan yang disampaikan untuk Rencana Proyek adalah untuk basis manajemen aktivitas proyek yang akan ditinjau.


3.3 LANGKAH-LANGKAH PERENCANAAN
Tiga langkah terbesar dalam persiapan untuk suksesnya proyek pengembangan piranti lunak adalah lengkapnya generasi dan akurat Work Breakdown Structure (WBS), jadual dan anggaran. Asal saja dalam penambahan untuk memonitor proyek dan mekanisme manajer proyek piranti lunak mengendalikan, WBS, jadual, dan anggaran yang disediakan manajemen tingkat atas dan pelanggan dengan jangkauan kedalam laporan proyek dan lokasi kendala. Tiga elemen ini akan didokumentasikan dalam Rencana Proyek yang tingkatannya cukup rinci sampai penyediaan sudah jelas dalam wawasan struktur tugas proyek dan statusnya pada beberapa point dalam siklus pengembangan.

Perhatian khusus akan diberikan hingga jelas, tidak disembunyikan item-item yang kritis itu hingga proyek sukses. Item-item yang kritis yang boleh kami masukan pada setiap tiga elemen (i.e., fakta-fakta tugas itu adalah kesulitan atau definisinya yang jelek dan krusial untuk suksesnya proyek terutama sekali yang krusial jadual kejadian penting itu hubungannya kritis untuk proyek selengkapnya; atau anggaran yang dipertimbangkan dengan ragu-ragu jika pada parameter, yang mana akan menyebabkan proyek ditutup jika anggapannya yang dibuat invalid). Item-item yang kritis ini akan menggantikan keluar dalam Rencana Proyek dengan taksiran resiko, dasar kebenaran resiko yang diterima, dan tekanan khusus dalam rencana untuk memonitor ini porsi kunci pada keperluan pengembangan.

3.3.1 Definisi Struktur Pekerjaan Terinci (Work Breakdown Structure /WBS)
Work Breakdown Structure (WBS) adalah berorientasi produk yang terorganisir merumuskan rencana tugas oleh manajer proyek dan dimana didomentasikan dengan hati-hati. Ini adalah hirarki definisi seluruh tugas sampai kinerjanya dan akuntansi untuk pelajaran dalam mengembangakan proyek. Cakupan tugas yang besar adalah didefinisikan, dan setiap cakupan yang besar adalah diidentifikasi lebih lanjut yang didefinisikan sebagai sub tugas. Setiap sub tugas lebih lanjut boleh broken down itu juga pada tingkat yang paling bawah definisi tugas setiap item kembali pada unit dasar pembiayaan. Apakah sederhana atau kompleks, setelah WBS didokumentasikan ditinjau itu oleh siapa yang punya interes pada proyek dan mereka akan mempertimbangkan kekritisannya dalam perusahaan oleh manajer proyek untuk dimasukan pada Rencana Proyek.
Beberapa elemen besar dan batasan dalam perencanaan WBS adalah diberikan seperti berikut :

1. Prosedur anggaran biaya terpaksa membolehkan paket-paket pekerjaan berisi pelanggan-pelanggan internal.
2. WBS terpaksa membolehkan pelanggan untuk membuat struktur proyek berkolerasi dengan struktur manajemen pelanggan.
3. Umumnya WBS akan memisahkan biaya pengulangan dari biaya tanpa pengulangan.
4. Yang diinginkannya adalah membolehkan WBS untuk memikirkan tipe aktivitas tertentu (analisis, coding, uji coba dan lain sebagainya)
5. yang diinginkan untuk menghimpun biaya item-item tugas yang relativ hingga selesai atau produk yang diserahkan dapat dipakai.
6. Individu yang kapabel dan termasuk dalam manajer proyek diperbolehkan memikirkan ukuran paket pekerjaan hasrat untuk memonitor elemen pekerjaan lainnya yang kurang teliti.
7. Elemen WBS harus berhubungan dengan orang; ongkos seseorang dalam setiap elemen di atas setingkat di bawah sekumpulan biaya.

WBS menyediakan basis estimasi biaya, organisasi proyek, jadual tugas, dan biaya pelaporan. WBS menghasilkan segmen rancangan tugas untuk identifikasi aktivitas stand-alone itu yang mendapatkan jadual dan biaya. Segmen tugas menyediakan proses penambahan pengertian yang ditugaskan dan akurasi pembiayaan meningkat. Kelengkapan WBS dan keterangan pendukung yang disediakan oleh manajer proyek dalam Rencana Proyek dan harus diperbarui yang kami rubah dalam struktur tugas. Gambar 4.6 menyediakan contoh proyek piranti lunak WBS.

WBS akan berhubungan dengan organisasi tingkat bawah atau struktur manajemen proyek. Ini adlah perhatian untuk mengidentifikasi organisasi yang bertanggung jawab terhadap tugasnya. Ini menyediakan kemampuan mengusut tinggi asosiasi sumber persyaratan dengan setiap tugas dan hasilnya dialokasikan dalam estimasi sumber persyaratan dalam organisasi.
Demikian pula, definisi hubungan kedalam adalah diantara WBS dan jadual proyek. Setiap aktivitas atau elemen WBS, definisinya waktu pentahapannya relativ untuk element WBS yang lain dan sejak setiap elemennya adalah mendapatkan persyaratan sumber, yang menghasilkan distribusi biaya.
Pendefinisian (dan penjadualan) aktivitas prosesnya adalah interaktif itu menyediakan kerangka kerja untuk estimasi biaya dan basis Rencana Proyek. Kedalaman atau tingkatan WBS ketergantungannya akan berbeda-beda pada kesulitannya dan ukuran proyek. WBS akan mendefinisikan untuk tingkat rendah yang secukupnya dibuat sampai memadai kelihatannya dan dipercaya untuk estimasi biaya, perencanaan proyek, dan pengendalian proyek.

3.3.2 Perencanaan Jadual
Setiap elemen proyek adalah akan mendapatkannya jadual yang diperlihatkan peristiwa penting dan sejak pengantar. Rencana proyek ini memasuki jadual dan master jadual peristiwa penting untuk keseluruhan proyek.
Jadual mempunyai dua fungsi utama. Pertama adalah diperlihatkan tahapan waktu tugas tidak sama hingga kinerjanya, yang mana indikasinya dapat dikerjakan parallel dan yang mana harus dikerjakan parallel. Kedua, ini adalah sebagai alat dasar manajemen untuk memonitor pelaporan.

Kekuatan manajer proyek untuk memindahkan dengan naskah resmi akan dikerjakan pertama, item-item yang mana harus menunggu sampai elemen proyek yang lain komplit, dan dapat dimulai selekasnya untuk menghindari masalah keterlambatan proyek. Penggunaan ini biasanya sebagai bantuan untuk pengembangan yang baik estimasi biayanya. Lalu kemudian mengahaluskan dan terinci hingga penyedian jadual alat yang diperlukan untuk memonitor status proyek.
Aktivitas jadual dimulai dari inisial perencanaan dan tahap estimasi biaya proyek pengembangan piranti lunak dan diteruskan sampai selesai secepatnya tahap tinjauan dan negosisasi. Data terus menerus dihaluskann dan puncaknya dalam inisial rencana program dan jadual. Persetujuan inisial rencana jadual ini manajer mengetahui nya, dan sub rangkaian pelanggan, adalah bagian negoisasi kontrak. Bagian berikutnya didiskusikan interaksi jadual sampai pertimbangan perencanaan jadual, penghalusan struktur jadual tipe peritiwa penting pengembangan, tipe jadual lainnya bermanfaat yang mengambarkan, dan menyediakan penjadualan umum sebagai garis pedoman.

Interaksi Jadual
Dua tugas prinsipal dalam jadual penugasan adalah estimasi persyaratan waktu hingga komplit variasi tugas-tugasnya dan identifikasi kekuatan hubungan ke dalam atau memaksa jadual lama. Jadual paksaan/tidak leluasa jatuh masuk ke dalam dua kategori umum

1. Hubungan ke dalam diantara tugas dalam proyek, dan
2. Pemaksaan yang menyebabkan peristiwa eksternal di luar pengendalian proyek.

Identifikasi jadual hubungan kedalam proyek adalah produk tugas dekomposisi proyek dan aktivitas jadual.
Pemaksaan eksternal dengan hati-hati akan didokumentasikan sebagai daftar anggapan dan diperlihatkan dalam jadual formal sebagai peristiwa kritis. Pelanggan harus dibuat sadar akibat dampak setiap pemaksaan eksternal dalam jadual pengembangan.
Ujian jadual pemaksaan eksternal termasuk di dalamnya antara lain :

1. Dokumentasi pelanggan-pemasok.
2. Alogaritma pelanggan-pemasok, teknik, atau masukan definisi yang lainnya.
3. Persetujuan tinjauan pelanggan formal (i.e., pelanggan harus tanggap untu tinjauan rancangan material dalam nomor khusus setelah hari-hari tinjauan formal).
4. Masukan sistem engineering (jika di luar organisasi pengembangan piranti lunak).
5. Sub kontraktor atau jadual vendor.
6. Jadual asosiasi kontraktor.
7. Jadual pengembangan instalasi komputer.
8. Tersedianya komputer waktu.
9. Pemeliharaan Piranti keras atau waktunya menurun.
10. Maksud khusus jadual pengembangan piranti keras. (e.g., I/O boards).
11. Tersedianya uji coba data.
12. Tersedianya fasilitas uji coba formal.

Struktur Jadual

Bilamana pengembangan fakta-fakta jadual proyek, dua kategori umum akan dihasilkan : jadual program dan rincian fungsional jadual. Rincian jadual harus didokumentasikan dalam syarat-syarat yang dipersyaratkan atau peristiwa, organisasi atau individu tanggap, dan persyaratan tanggal terpenuhi. Hirarki pengembangan akan mengalir dari tingkat atas (top-level) hubungannya dengan master jadual program di bawah persyaratan hingga jadual dipaksa untuk tingkat pekerjaan rinci. Empat tipe jadual yang mana pengembangan top-down definisinya mengalir berikutnya. Pertama dua penyedia jadual program dan yang terakhir dua konstitusi rincian fungsional jadual.

Jadual Tingkat Atas
Jadual tingkat atas adalah jadual kewenangan menggambarkan end-to-end rencana yang membawa keluar program yang obyektif. Yang berisi kunci peristiwa penting program (e.g., tingkat uji coba sistem telah dilakukan), yang mana digunakan pengembang rencana jadual tingkat bawah. Jadual ini dikembangkan pada tingkat proyek dan definisi point persyaratan akhir hingga organisasi pengembangan piranti lunak.

Jadual Antar muka

Jadual antar muka diperpanjang sampai tingkat atas yang menyediakan seluruh informasi kejadian persyaratan untuk fungsional organisasi pengembangan piranti lunak, sub kontraktor dan vendor-vendor, dan lapis dalam organisasi proyek. Informasi ini membolehkan grup-grup ini untuk mengembangkan jadual mereka dan menyediakan referensi untuk antar muka status pelaporan. Jadual antar muka untuk sementara seluruh peristiwa penting antar muka pelanggan dan proyek pengembangan piranti lunak dan peristiwa penting eksternal.

Jadual Pengembangan Piranti Lunak
Jadual pengembangan piranti lunak untuk sementara keseluruhan peristiwa penting proyek pengembangan piranti lunak (PDR, CDR, etc.) konsisten dengan tingkat atas dan jadual antar muka.

Fungsional Jadual
Jadual fungsional menyediakan pengendalian jadual tingkat bawah. Jadual-jadual ini memperluas jadual pengembangan piranti lunak (dengan pengetahuan fakta-fakta kunci item dari jadual antar muka)untuk organisasi khusus dapat dipakai ukuran tugas-tugas aktivitasnya dapat dikendalikan. Jadual fungsional menyediakan kerangka kerja untuk menentukan tahapan waktu, perincian anggaran, status pelaporan, ringkasan, biaya dan kinerja jadual. Jadual fungsional siap dan dipelihara oleh organisasi proyek yang bertanggung jawab untuk tugas pengembangan tingkat bawah.

Penggunaan Jadual Lainnya
Jadual telah digambarkan adalah biasa menghubungkan jadual peristiwa penting. Jadual-jadual menidentifikasi peristiwa penting proyek besar pada setiap tingkat jadual. Mereka mengidentifikasi kejadian-kejadian itu harus sampai proyek komplit dan mereka lama melengkapinya. Mereka hanya menyediakan binary data (seringkali indicator peristiwa penting adalah berwarna di,ama lengkap kejadiannya) dan tidak disediakan informasi yang komplit atau interaksi tugas diperlukan dengan pantas jadual mengantisipasi masalah. Bar charts dan network menyediakan informasi belakangan adalah sangat berguna supllemen untuk dasar chart peristiwa penting.

Bar charts (juga menghubungkan Gantt charts) menyediakan ilustrasi grafik tugas sampai kinerjanya. Setiap status tugas ( dalam tingkat syarat-syarat komplit) indikasi tiap grafik atau dengan angka prentasi. Status pada beberapa point dalam waktu dapat diperlihatkan oleh shading barrs. Walaupun mudah untuk dibaca, chart,charts yang disukai peristiwa penting, pasti untuk menyediakan gambar hubungan antar tugas.

Network ini menanggulangi kekurangan. Satu lebih besar suksesnya prosedur teknik jadual network adalah Program Evaluasi dan Tinjauan Teknik (Program Evaluasi and Review Techniques / PERT). PERT mengilustrasikan ketergantungan antar kejadian proyek. Tugas identifikasi proyek, rangkaiannya, dan antar hubungannya. Yang mana tugas mengidentifikasi harus lengkap lebih dulu tugas lainnya dapat dimulai.

Sejak grfaik charts PERT tugasnya sekarang antar hubungan, mereka bermanfaat dalam perencanaan alokasi sumberdaya. Untuk menyelesaikan ini, estimasi sumberdaya adalah dibuat untuk setiap tugas dalam PERT network. Sumberdaya proyek dalam mengalokasikan pada basis tugas antar hubungan diperlihatkan dalam PERT chart. Pendekatan ini memastikan tugas itu yang mana pada tugas yang lainnya tergantung jadual permulaan dan mempunyai prioritas untuk sumberdaya proyek.

Garis Pedoman Jadual
Sejak tujuan utama jadual adalah sampai menetapkan bagaimana persyaratan banyaknya waktu untuk kelengkapan tugas, atau kelengkapan proyek, pemakaian fakta dalam jadual pengembangan diterima. Pertimbangan harus memberikan untuk tersedianya orang, komputer waktu, perlengkapan antar muka, data dari luar organisasi, rancangan informasi untuk elemen sistem sampai pemodelan piranti lunak, tahapan waktu tugas.

Selama periode proposal atau periode pendefinisian proyek internal perusahaan, jadual pendahuluan disiapkan. Aktivitas jadual ini akan berkembang untuk kejadian pada aktivitas yang besar dalam strktur WBS. Dekomposisi tugas dan jadual aktivitas membantu untuk mengidentifikasi masalah dengan WBS dan tidak cocok identivikasi. Dalam perusahaan jadual akan menugaskan asosiasi dengan persiapan seluruh item permintaan dan tinjauan rancangan. Jadual proposal secukupnya akan terinci sampai pendukungnya, pekerja, perjalanan dan proses estimasi.

Permulaan rincian jadual proyek yang lainnya akan dipersiapkan untuk tahap kontrak utama pada WBS tingkat bawah. Rencana rincian jadual serupa akan diprioritaskan sampai berturut-turut tahap pengembangannya.
Setiap proyek jadualnya harus ditulis, proyek kecil bukan persoalan. Untuk proyek kecil ini satu halaman jadual peristiwa penting termasuk utama. Untuk proyek besar semoga konsisten jadual peristiwa penting, pada tingkat varian, kunci untuk master jadual peristiwa penting proyek dengan bar charts dan network untuk pendukung perencanaan proyek dan proses monitoring. Persiapan tugas persyaratan jadual karena perintah keputusan yang mana aktivitas kinerjanya dan waktu adalah diberikannya. Keputusan ini adalah fundamental untuk proses perencanaan proyek dan menyediakan dasar pengendalian proyek.

Elemen dalam perhatian pada seluruh jadual proyek tugasnya terpelihara nomenklaturnya konsisten diantara jadual, tugas perencanaan (definisi WBS), anggaran, dan aktivitas organisasi proyek.Identifikasi WBS dimasukan pada setiap jadual atau item jadual dan ketentuan khusus elemen WBS sampai elemen organisasi yang konsiten menyediakan diantara jadual tugas, dan anggaran. Tipe konsistensi dalam dekomposisi tugas, jadual, dan tanggap penetapannya memastikan adanya itu tidak hanya seluruh kejadian memperoleh jadual mereka itu dapat dengan mudah termonitor. Juga perubahan fasilitas analisa dan pengendalian.

Efektivitas jadual dan manajemen jadual memperhatikan tanggung jawab manajer proyek. Dia bertanggung jawab untuk seluruh jadual pengembangan proyek. Bagaimanapun, untuk proyek besar, tinjauan dan persetujuan rincian jadual akan didelegasikan sampai manajer pengendalian proyek dan manajer subproyek. Manajer proyek akan berisiniatif dengan jadual master tingkat atas dan pertama kemungkinannya satu atau dua deretan bertingkat di bawah jadual master. Dia akan mengangkat personil proyek yang lainnya untuk persiapan jadual dereten bertingkat bawah dan persyaratannya konsisten dengan jadual tingkat tinggi. Bilamana jadual tingkat rendah mengharuskan dipaksakan dirubah pada jadual tingkat tinggi, revisi ini akan ditinjau dan pendekatan pada manajer proyek.

Sejak jadual tergantung pada kejelasan tugas dan hubungan intern organisasi, suksesnya proposal (dalam syarat-syarat yang biayanya realistis) dan proyek (dalam syarat-syarat jadualnya yang komplit pada anggaran biaya) adalah ketergantunganya sangat tinggi pada validasi dan kekomplitan aktivitas jadual. Yang jelas tidak menyenangkan selama proposal, pendefinisian proyek, atau periode pengembangan piranti lunak.


3.3.3 Perencanaan Anggaran
Anggaran adalah bagian yang harus diperhatikan pada Rencana Proyek, tapi fundamental perencnaan anggaran jatuhnya di bawah manajer proyek yang bertanggung jawab pada manajemen kontrak.

Anggaran proyek konsisten deskripsinya seperangkat pengeluaran belanja melawan sekumpulan waktu (satu kumpulan untuk keseluruhan proyek dan satu untuk setiap elemen). Sebagai kelengkapan kerja yang mendatangkan pengeluaran, sekumpulan jumlah pada chart yang sama dan variasi catatan. Job manajer proyek adalah untuk memonitor varian ini mengerti benar sebab deviasi.

Jika proyek yang sama mempunyai banyak orang yang bekerja dari permulaan hingga selesai dan ini adalah yang lainnya tak berubah, anggaran adalah garis linier. Ini jarang terjadi. Tidak hanya banyanya orang yang merubah ketelitian proyek, tapi ini biasanya berubah yang lainnya. Ini adalah umumnya ODC (Other Direct Changes), sebagaimana perjalanan bisnis, belanja perlengkapan, komputer waktu. Ongkos ini jarang terjadi pada jadual yang reguler. Namun, manajer proyek akan sanggup untuk mengestimasi perkiraan bilamana akan terjadi. ODC item-itemnya sekarang permasalahan khusus, biayanya sejak mereka muncul sistem laporan biaya yang panjang setelah didatangkannya. Ini cenderung untuk manajer proyek yang memberikan pengertian keamanan bohong, sejak chart diperlihatkannya di bawah anggaran. Perencanaan anggaran yang layak dan akan memonitor mencegah terjadinya pendapatan tertutupnya terlalu panjang.

Job manajer proyek adalah untuk memanaj hingga dolar terakhir. Varian yang tak dapat dikendalikan sebagaimana perubahan (jarang menurun) untuk beban perusahaan itu menghitung dengan memakai petunjuk biaya proyek (e.g., menghitung overhead) membuat anggaran yang tepat tak mungkin. Karena itu, ini adalah perhatian, bilamana mungkin, manajemen untuk memelihara cadangan dan tidak mengalokasikan seluruh anggaran.
Sejumlah anggaran khusus untuk proyek pengembangan piranti lunak adalah diperlihatkan dalam gambar 3.7. Yang mempredikdi sekumpulan metode dimasukan dalam Rencana Proyek dan aktualisasinya adalah disediakan dalam laporan keuangan bulanan.



3.4 ORGANISASI PROYEK
Sumber daya sebagai dasar berkembangnya program sistem komputer adalah manusia. Untuk implementasi yang sukses program komputer, manajer proyek memerlukan orang yang tepat dengan ketrampilan yang tepat pada waktu yang tepat. Perekrutan tenaga kerja enginnering untuk rancangan, dokumentasi, peng-kode-an (coding) dan uji coba adalah hanya sebagian perekrukutan dari seluruh total staff. Tambahan organisasi perusahaan yang lainnya yang diperlukan untuk personil pendukung teknis harus diidentifikasi dan permohonannya betul-betul komitmen dukungannya. Fungsi ini cermat sekali pantas/berhak mendapat perhatian, karena kurang pengakuan persyaratan fungsi pendukung untuk proyek yang signifikan penyebabnya boleh jadi masalah jadual atau biaya.

Rencana Proyek akan mendefinisikan organisasi proyek, definisi pertanggungjawaban khusus setiap grup dalam organisasi, dan mengidentifikasi personil kunci. Personil kunci adalah jabatan individu beberapa aspek proyek atas perintah manajer proyek. Mereka adalah mengharapkan meminta perhatian untuk pertimbangan dan kebijaksanaan dalam memutuskan adalah bagaimana untuk menyelesaikan tugas, siapa yang akan menyerahkan fakta-fakta tugas, dan bilamana tugas akan komplit. Alokasi tanggung jawab tugas akan cocok untuk proyek WBS. Itu adalah elemen tanggung jawab yang didelegasikan pada personil kunci korelasinya akan sampai pada elemen WBS begitu juga dengan sistem akuntansi dan pekerjaan mengikuti jalannya jadual yang berfungsi pada proyek yang tersedia akan menunjukan ukuran suksesnya personil kunci dalam memanaj pendelegasian tugasnya. Pada kebanyakan proyek jabatan ini orang cenderung, sebagaimana Paket Pekerjaan Manajer atau Pekerjaan Unit Manajer, mewakili hubungan yang bertanggungjawab untuk elemen pekerjaan WBS.

Daftar penempatan personil kunci dengan jabatannya (tanggung jawab) dalam Rencana Proyek adalah tidak dipersyaratkan pada banyak perusahaan, tapi ini adalah format yang baik dalam jaminan. Manajer proyek akan dipindah dari proyek atau beberapa alasan (dalam keadaan sakit, kecelakaan, darurat, atau tiba-tiba penugasan kembali), manajer proyek yang baru akan cepat mengambil kendali proyek jika dapat mudah diidentifikasi kunci orangnya dan pertanggungjawabannya. Informasi ini bersama dengan berhentinya Rencana Proyek dan status laporan terakhir, proyek yang akan diidefinisikan status dengan cukup cepat untuk, suksesnya pengambil alihan oleh manajer proyek baru.

Dalam perencanaan dan organisasi proyek, manajer proyek akan berpengaruh pada struktur organisasi perusahaan dan ketetapan struktur pendukung dalam keperluan pengembangan. Bagian berikutnya menggambarkan laporan singkat dampak struktur perusahaan pada organisasi proyek, alternatif organisasi proyek dan pertanggungjawaban organisasi proyek.

3.4.1 Alternatif Struktur Perusahaan
Organisasi proyek adalah dipengaruhi oleh pendekatan organisasi perusahaan. Ini adalah dua dasar pendekatan : organisasi fungsional dan organisasi proyek. Pendekatan fungsional grup orang-orang dengan fakta-fakta spesifik dalam departemen atau operasi yang mana disediakan keahlian mereka bidang khusus untuk proyek. Spesialis pada dasarnya pinjaman untuk manajer proyek kepada jabatan bagian mereka bekerja. Spesialis bertanggung jawab pada departemen atau manajer operasi (fungsional), tidak untuk manajer proyek.
Tipe ini fungsional organisasi perusahaan, menyerahkan terhadap organisasi matrik, adalah popular diantara pelayanan teknologi tinggi dan riset serta pengembangan perusahaan. Adalah mengijinkan untuk menggaji spesialis teknologi tinggi siapa yang tidak dapat diupahi untuk pendukung proyek tunggal. Bilamana banyak bersama-sama memakai spesialis proyek ini dapat digunakan sangat efektif. Kerugian organisasi matrik untuk proyek manajer adalah sebagai berikut :

1. Manajer proyek mempunyai lebih sedikit pengendalian pekerjaan : tingkat spesialis karena mereka adalah mungkin kuatir dengan fungsional organisasi daripada dengan proyek.
2. Khusus, manajer proyek punya sedikit atau tidak berkuasa dalam memilih personil, hanya dalam pendefinisian persyaratan ketrampilan dan tingkat pengalaman untuk tugas.
3. ini barangkali substitusi personil setelah tugasnya selesai.
4. ini adalah sedikit atau tidak lancarnya orang dalam jabatan, menyamakan dengan organisasi berorientasi proyek.

Analis, perancang, dan programmer adalah ditugaskan untuk proyek, mengerjakan job mereka, dan cuti. Ini barangkali sangat efisien yang lainnya sampai kurangnya spesialisasi orang siapa yang dapat menyediakan kelancaran diantara anlais, perancang, dan implementasi. Pendekatan ini juga dihindari pada proyek berbiaya besar yang berasosiasi dengan pendidikan sejumlah besar orang di atas sampai kecepatannya (belajar kurva biaya).

Sebagian terbesar alternatif bersama organisasi matrik adalah organisasi proyek. Dalam tipe ini struktur perusahaan, hanya laporan personil proyek untuk manajer proyek. Keuntungan organisasi perusahaan tipe ini adalah :

1. Manajer proyek punya pengendalian lebih komplit orang yang bekerja dalam job-nya.
2. kelancaran dapat dipercaya oleh adanya beberapa pendukung analis dua-duanya perancang dan aktivitas tahap uji coba.
3. Permasalahan staf dapat diselesaikan oleh manajer proyek oleh upah/gaji, pemecatan, menugaskan kembali dalam proyek, tanpa negoisasi kebutuhan dengan manajer fungsional siapa yang mempunyai sedikit pengertian persyaratan proyek yang sedang berjalan dan siapa yang punya motivasi tujuan lainnya.
4. Komitmen dengan proyek adalah membantu perkembangan dengan petunjuk proses pencapaian individu untuk organisasi proyek pada teknisi dan mengerti admintrasi.

Kekurangan besar pada organisasi perusahaan yang berorientasi proyek, yang menentang dengan organisasi fungsional, adalah tambahan tingkatan pertanggunganjawab oleh manajer proyek. Dalam organisasi fungsional, bilamana memberikan tugas adalah komplit, manajer proyek kembali pada spesialis untuknya atau organisasi fungsional, dimana seseorang yang lainnya bertanggung jawab pada lokasi yang baru diberikannya. Di bawah rencana proyek, manajer proyek adalah bertanggung jawab di mana untuk bekerja selanjutnya. Juga, selama periode menyusun proyek, jumlahnya besar waktu untuk manajer proyek dan personil kunci proyek harus komitment untuk menyewa personil dari luar perusahaan, sama dengan interview kandidat yang dilepaskan dari proyek lain. Interview dan penyewaan adalah menahan manajemen fungsional dalam organisasi matrik, sebagai saringan pendahuluan pada pegawai yang ada tersedia untuk posisi proyek. Dampak besar ini dua alternatif struktur perusahaan adalah tingkat pengendalian pegawai pada manajer proyek.

3.4.2 Alternatif Struktur Proyek
Struktur organisasi proyek sebagian besar adalah empat factor fungsi :

1. struktur perusahaan
2. ukuran proyek
3. kapabelitas dan gaya manajemen manajer proyek dan
4. kapabelitas personil kunci dalam proyek

Untuk varian fungsi yang luas dan tugas adalah sebagian masuk kedalam grup-grup yang tidak sama di bawah manajer proyek yang dibatasi oleh keperluan pengembangan piranti lunak. Sebuah proyek kecil bleh mempunyai tiga sampai enam orang strukturnya tidak formal, dengan seluruh personil laporannya langsung ke manajer proyek. Sedangkan proyek besar memerlukan tugas yang makin bertambah besar tingkat manajemen tanpa gabungan dengan yang lainnya. Perhatian sebagian terbesar standar dalam pendefinisian struktur manajemen adalah WBS; bilamana struktur manajemen parallel dengan WBS, biaya dikumpulkan dan status pelaporan mewakili tanggung jawab organisasi.

Walaupun besar perbedaannya diantara proyek kecil dan proyek besar adalah grup-grup tingkat spesialisasi dalam organisasi, ini adalah organisasi tingkat tinggi filosofinya memilih itu adalah pendefinisian yang dipengaruhi oleh ukuran proyek. Ini adalah pilihan diantara organisasi proyek fungsional dan job atau elemen yang berorientasi organisasi proyek.
Organisasi proyek fungsional, suka organisasi perusahaan fungsional, grup orang-orang dengan ketrampilan yang sama, sebagai ilustrasi lihat dalam gambar 3.8. analis dalam satu grup, grup sistem engineer piranti lunak, grup programmer, grup personil jaminan produk, dan lain sebagainya. Organisasi proyek fungsional punya banyak keuntungan organisasi perusahaan yang sesuai. Spesialis digunakan untuk setiap tugas, yang mana piranti lunak independen atau elemen sistem masuk di dalamnya.

Sebagai kemungkinan lain, struktur proyek dapat sekitar job atau garis elemen sistem, yang mana hasilnya dalam satu grup dipertang gungjawabankannya untuk satu elemen piranti lunak, sebagaimana display elemen, elemen manajemen data base, atau reduksi elemen data. Grup ini adalah bertanggung jawab terhadap tugasnya untuk seluruh analis, rancangan, peng-kode-an/code, dan uji coba sampai lengkap elemen piranti lunak itu. Organisasi proyek memisah piranti lunak ke dalam sub sistem dan manajer serta grupnya menyerahkan kepada pengembang setiap sub sistem. Pendekatan ini seringkali menyerahkan sampai dengan “job-shop” organisasi. Ini adalah sungguh sukses untuk kecil, bertalian dengan job-job, tapi adalah tidak direkomendasikan untuk sistem proyek besar. Ini adalah besar yang tak menguntungkan itu karena seluruh sub sitem manajer adalah kuatir sub sistemya, dengan tanpa satupun mempunyai tanggung jawab untuk tingkat sistem yang bermasalah.

Sebagaimana yang seringkali kasus, sebagian besar kenyataan proyek di dunia, terutama sekali proyek besar, kombinasi ini menggunakan dua filosofi dasar organisasi proyek. Grup fungsional seringkali digunakan untuk banyaknya fungsi tingkat sistem, sebagaimana sistem engineer piranti lunak, manajemen sub kontrak, jaminan produk, sistem tingkat uji coba, saat struktur fungsi pengembangan piranti lunak dalam “job-shop” mode, seperti yang diilustrasikan dalam gambar 4.9. dalam satu elemen job-shop , tugasnya struktur fungsional adalah biasanya untuk menerima keuntungan yang didapatkan analis, rancangan, dan spesialis uji coba.

Pertanggungjawaban yang spesifik setiap elemen diidentifikasi adalah dalam Gambar 3.8 dan 3.9 yang digambarkan dalam sesi 4.2.Pemilihan organisasi proyek harus menggambarkan Rencana Proyek. Deskripsi ini akan mengakui kemungkinan kebutuhan untuk perubahan organisasi proyek pindah dari persyaratan analis, yang tidak tanggung-tanggung rancangan dan uji coba operasi.

Perubahan bisa terjadi untuk alasan seperti berikut :

1. Proyek pengembangan ringkasan tahap pindah tidak tangung-tanggung pada sesi 2.2, menekankan shifts dari analis ke rancangan, ke coding, dan ke uji coba. Organisasi akan memikirkan yang menekankan perubahan proyek. Untuk latihan, ini tidak memerlukan pelatihan atau secepatnya grup intalasi pada proyek, dan barangkali tak memerlukan perekrutan analis atau pendefinisian grup antar muka belakangan pada proyek.
2. Organisasi akan memikirkan ketrampilan dan kekuatan staf proyek, dan penyesuaian diri yang akan membuat sebagai kebutuhan dengan kompensasi untuk kekurangan, kedua-duanya individu dan perusahaan.
3. Untuk beberapa banyak akibat, keaslian pendefinisian organisasi, yang disajikan dalam Rencana Proyek, boleh dibuktikan tak berguna. Seringkali hasil dari kondisi yang sama sekali di luar pengendalian proyek manajer, sebagaimana perubahan organisasi atau kekurangan dalam organisasi proyek pelanggan. Ini adalah kasus, proyek akan di reorganisasi, dan Rencana Proyek akan diperbarui untuk gambaran perubahan.

Sebagaian besar factor signifikan dalam organisasi proyek sukses adalah bukan fakta struktur, jumlah bok dalam chart, atau pemelihan judul untuk setiap grup, tapi luas yang mana untuk tugasnya dengan jelas yang caranya dapat dikerjakan dan setiap anggota staf proyek mengerti atau tujuannya, tanggung jawab, dan hubungan dengan staf proyek yang lainnya.

3.4.3 Organisasi Perekrutan Ketrampilan

Proyek pengembangan piranti lunak hanya punya sedikit harapan sukses jika manager proyek adalah tak sanggup untuk mengumpulkan tim dengan ketrampilan dan disiplin yang tepat untuk setiap tahap keperluan pengembangan. Gambar 3.10, menyediakan ringkasan disipli siklus proyek pengembangan piranti lunak.

Referensi

Philip Bruce, Sam M. Pederson, 1982 The Software Development Project, John Wiley and Sons, New York.

Steve McConnell, 1996, Rapid Development Taming Wild Software Schedule, Microsoft Press, Washington.

Tumar, 2002, Information System Strategic, Universitas Bina Nusantara, Jakarta.

Bob Hughes and Mike Cotterell, 2002, Software Project Management, McGraw Hill, London.