MENGELOLA PROYEK SISTEM INFORMASI DAN ATAU PIRANTI LUNAK

MENGELOLA PROYEK SISTEM INFORMASI DAN PROYEK PIRANTI LUNAK

oleh: Tumar

Evolusi manajemen proyek piranti lunak cukup lambat yang berakhir pada dua dekade yang lalu. Alasan utama untuk ini adalah kegigihan itu nampak lebih pada programming adalah bagian dari seni dan ilmu pengetahuan. Ini nampak tetap hidup diantara perusahaan, sistem teknisi proyek, dan personil manajemen serta mempunyai kontribusi kelambatan dalam pengembangan baik-definisi, baik metodologi struktur manajemen piranti lunak. Permasalahan berlangsung meskipun kemajuan baik pada teknologi piranti keras komputer, pengenalan rekayasa piranti lunak, pendefinisian pendekatan pengembangan baru, sebagaimana dekomposisi rancangan, struktur rancangan, struktur programming, hirarki defines masukan-keluaran, dan kepala programmer tim konsep manajemen.

Faktor ini yang membantu perkembangan prespektif dalam perusahaan dan manajemen proyek itu manajemen piranti lunak harus dengan berhati-hati memperkembangan dan merubah untuk melanjutkan kemajuan dalam pengembangan teknologi piranti lunak.Ya, ini kesimpulannya adalah manajemen jarang meng aplikasikan dengan cepat kemajuan elektronik menjawabnya. Mengapa proyek piranti keras berkembang, pada pertengahan luar biasa kemajuan teknologi, adalah dsiplinnya manajemen, caranya sistimatik dasarnya pada dekade yang lalu yaitu pengalaman manajemen proyek sementara proyek piranti lunak rupanya tidak dapat ???
Kontribusinya secara umum salah pengertian manajemen piranti lunak adalah banyak pandangan memperkenalkan programmer sebagai yang tak terkendalikan/terkekang kreatifnya genius, siapa yang punya kreativitas sementara proses dibuat tak berdaya oleh beberapa rekomendasi pengendalian manajemen proyek, rancangan standar, programming standar. Terpaksa puas dengan pandangan ini manajer piranti lunak, baru-baru ini seringkali mempromosikan analis atau programmer siapa yang punya pekerjaan dalam memanaj proyek sebagai koleksi seni kreativitas tindakan mereka yang independen disukai. Job Manajemen dalam proyek ini adalah untuk percobaan, bagaimanapun juga, untuk memimpin koleksi ini individu dalam keadaannya itu menunjukan juga produk mereka akan menyelesaikan tujuan proyek, adalah sanggup hingga setiap antar muka dengan yang lainnya, dalam penyelesaiannya biaya proyek dan jadual dipaksakan, dan barangkali sebagian besar perhatian, agaknya akan kembali tertutup untuk penyelesaiannya apakah pelanggan dalam pikirannya untuk piranti lunak. Khusus manajer piranti lunak baru saja tahun-tahun ini mengalami kemajuan bagaimana proyek tidak akan dimanaj, tapi punya sedikit pembukaan atau pelatihan yang digunakan efektif teknik manajemen piranti lunak.

Maksud pada bagian ini adalah untuk mengetahui latar belakang dan pengertian peryaratan untuk memanaj suksesnya proyek pengembangan piranti lunak. Metodologinya diperkenalkan yang dapat dipakai untuk seluruh proyek piranti lunak, komersial atau pemerintah sponsornya, besar atau kecil. Untuk beberapa proyek, Rencana Proyek yang baik adalah tiga halaman memorandum, persyaratan yang baik didomentasikan dalam cara yang serupa, dan rancangannya diperkenalkan dalam 30 halaman dokumen. Untuk yang lainnya, Rencana Proyek akan konsisten pada tiga jilid untuk pengalamatan yang rinci persyaratan pengembangan, konfigurasi manajemen, dan aspek pemeliharaan proyek. Untuk proyek ini, persyaratan boleh mengharuskan 100 halaman dokumen, dan rancangan rinci terdiri dari enam jilid, 3000 halaman per jilid dokumen. Salah satu perbedaan, dan di mana-mana diantara fungsi kinerjanya , produk dokumen, serta tipe persyaratan perencanaan adalah sama.Pada bagian ini didiskusikan pembuatan proyek dan gambaran antara lain kebutuhan untuk mengerjakan yang lebih baik ( banyak disukai inisialnya, variable dan tabel dimuka eksekusi blok dan kode). Sementara itu kami menggambarkan proses manajemen proyek pertanyaan berikut jawabannya. Apakah yang dikerjakan selama proyek? Bagaimana manajer akan membelanjakannya atau waktu yang diberikan berapa hari? Bagaimana manajer analis mengerjakan membuat laporan, apa saja? Akhirnya, apakah diskusi kami akan dikerjakan selamanya dan proyek selesai untuk menyediakan warisan itu benefit yang baik untuk proyek masa depan.

4.1. TITIK PERMULAAN (STARTING POINT)

Untuk setiap pengembangan proyek piranti lunak ada dua titik permulaan yaitu :

1. Satu untuk perusahaan dan
2. Satunya lagi untuk proyek.

Yang pertama adalah kebutuhan yang bisa dijadikan contoh yang kedua. Dua elemen utama itu menetapkan titik permulaan perusahaan adalah :

1. Proses keputusan proyek (dalam beberapa kasus ini adalah keputusan sampai komplit, dan proses sampai keputusan adalah benar-benar dibuat oleh pelanggan dalam memilih proposal yang dimenangkannya) dan,
2. Penyeleksian manajer proyek. Penyeleksian manajer proyek biasanya mempunyai tanggung jawab untuk kebutuhan kondisi permulaan proyek.
   

4.1.1 Titik Permulaan Perusahaan (Starting Point Company)
Proses keputusan dengan internal proyek yang meliputi banyak faktor, sebagaimana biaya versus benefit perdagangan mempertim bangkan pendekatan alternativ varian, persyaratan definisi untuk memilih pendekatan, dan menyususun keperluan yang diusahakan dan komitmen dari pendukung dan organisasi menggunakannya. Sebagian besar perusahaan-perusahan tidak bisa memungkirinya ptosedur alokasi sumber daya perusahaan untuk investigasi proyek internal bilamana kemungkinan untuk meneruskan point keputusan dan membuat komitmen pembiayaan. Komitmen pembiayaan adalah syarat utama untuk memutuskan proyek. Sumberdaya harus dialokasikan untuk persiapan untuk proses keputusan. Perusahaan akan sepenuhnya komit dengan laporan paling akhir secukupnya dengan mengerti lingkup rancangan dan kerumitan-kerumitan proyek serta harga yang diperlukan. Dalam tidakannya juga, perusahaan harus mempersiapkan untuk memperlakukan invesment sumberdaya sebagai ongkos kebutuhan untuk pendukung proses pembuatan keputusan, dan tidak sebagai pembenaran untuk diproses karena juga banyaknya “yang telah diluarkan” dalam proyek. Seperti yang ditetapkan dalam kata pengantar, maksud buku ini adalah untuk menggambarkan pada pendekatan untuk memanaj proyek piranti lunak, tidak untuk menggambarkan prosedur itu peranan penting untuk memutuskan proyek. Karena itu, yang lainnya tidak akan dibicarakan di sekitar elemen utama ini.

Demikian pula, untuk proposal yang kompetitif keputusan penawaran meliputi analisis jumlah faktornya besar, sebagaimana posisi kompetitif perusahaan sebagai dasar analisis perusahaan dan persaingan kelemahan dan, kekuatan, analisis berikutnya potensi bisnis, analisis menyamakan persyaratan sumber daya proyek untuk perusahaan sumber daya yang sudah diperhitungkan kapabel, dan analisis factor resiko proyek. Deskripsi lebih lanjut tawaran proses keputusan yang juga meninggalkan dengan publikasi yang lainnya.

Elemen kedua pada penyusunan titik permulaan perusahaan, memilih manajer proyek, membenarkan diskusinya untuk menyediakan kelengkapan analisis manajemen proyek. Pemilihan staf proyek yang baik adalah sebagian besar faktornya kritis dalam persamaan untuk suksesnya proyek sistem informasi dan piranti lunak. Pemilihan manajer proyek dapat gagasan sampai elemen eksponensial kalau tidak persamaan kuadrat. Sebuah proyek bisa mempunyai beberapa ukuran sukses dengan segolongan kecil tak berproduksinya analis atau programmer, tapi proyek tidak akan sukses dengan manajer proyek yang buruk.

Pemilihan manajer proyek adalah tugas istimewa yang sulit, sejak setiap proyek sistem informasi piranti lunak mempunyai seperangkat keunikan masalah itu cenderung pada permintaan tertentu kualifikasi manajer tidak wajib bisa proyek lain. Kualifikasi wajib untuk beberapa piranti keras atau sistem manajer proyek yang juga menggunakan untuk manajer proyek : kepemimpinan, mengerti teknik, kemampuan manajemen, kesiapan dan ketegasan, kepandaian yang beraneka ragam dan fleksibel integritas tinjauan kemasa depan

Kepemimpinan (Leadership)
Persyaratan kepemimpinan untuk berbagai posisi manajemen, tapi perhatian utama untuk manajer proyek, siapa yang harus memotivasi koleksi bermacam-macam bakat orang yang untuk sementara bekerjasama sebagai sebuah tim. Manajer pada sebuah departemen dalam organisasi fungsional boleh memanaj yang banyak atau berlainan orangnya, Tapi kebanyakan lain lingkungan yang seimbang yang lainnya karakternya homogen (e.g., grup analis dalam departemen akuntansi). Manajer proyek, pada sisi lain, harus stimulan dukungannya untuk proyek dan tim proyek untuk sementara dalam lingkungan proyek. Dia harus menyelesaikan ini dengan tim mempunyai latar belakang tidak sama dan ketrampilan yang luas, pada lingkungan bilamana perubahan yang lainnya sering dan acapkali sangat frustasi untuk anggota tim percobaan untuk rancangan pada elemen piranti lunak.

Mengerti Teknik (Technical Understanding)
Manajer proyek harus mampu untuk berkomunikasi dengan personil teknis proyek dan administrasi yang professional, sama baiknya dengan pelanggan dan manajemen tingkat atas perusahaan. Dia harus cukup genggamannya pada isu besar teknik, dan isu lainnya yang tajam teknik tingkat dua, itu dengan melihat teknik membuat keputusannya baik. Seperti banyak pada tipe proyek lainnya, isu teknologinya menonjol. Untuk manajer dengan membangkitkan atau mengevaluasi estimasi biaya, jadual, dan persyaratan staf, dia harus mempunyai pengertian permasalahan teknik dan mengetahui siapa yang menilai/mempertimbangkan isu kritis teknik, yang mana dia akan mencari advis ke ahli teknik. Dia tidak memerlukan kreativitas yang terlalu tinggi, tapi harus mampu untuk mengevaluasi produk lainnya yang kreatif, teknik membuat, biaya, dan jadual penjualan, komunikasi dengan staf teknik senior.

Kemampuan Manajemen (Management Competence)
Proyek tingkat teknologinya independen, manajer harus mengerti dasar ketrampilan manajemen dan artinya dengan suksesnya proyek. Terlalu seringkali teknisi yang sangat tinggi manajer proyek menurunkan pemeliharaan mengawasi banyak untuk prioritas rendah, hasilnya dalam teknik penyelesaiannya bagus sekali untuk sebuah proyek yang tertunda haknya untuk biaya atau berlebihnya jadual. pada seluruh proyek, baik kecil maupun besar, biaya dan jadual dimonitor adalah sama perhatiannya dengan teknik analisis. Untuk proyek yang kecil, data biaya dan jadual adalah juga yang terus terang dan visible itu sedikit memerlukan persyaratan khusus oleh manajer proyek. Untuk proyek yang besar kekomplekannya, banyak manajer harus mencurahkan waktunya untuk aktivitas manajemen nonteknik ini. Ini adalah penyebab besar mengapa banyak perusahaan memberikan sebuah chief engineer atau deputi manajer proyek untuk menyediakan waktu sepenuhnya untuk keperluan petunjuk teknis. Ini sungguh kasus, manajer proyek biasanya mempunyai sisa kemampuan teknik, tapi yang lainnya administrasi dan ketrampilan manajemen.

Kesiapan dan Ketegasan (Alertness and Decisiveness)
Manajer proyek harus mengobservasi, mengevaluasi dan tegas . Dia harus mengintegrasikan data dan mengenai terdedianya pelbagai personil proyek, termasuk staf supervisi teknik staf personil administrasi, dengan menyediakan data yang formal dan pengendalian sistem informal. Dia harus mengidentifikasi, menaksir, dan mengevaluasi data dampak proyek, berkomentar, dan kecenderungan serta memutuskan apakah beberapa kegiatan baik. Manajer proyek harus mengakui bilamana diperlukan keputusan untuk membuat, menghimpun data yang diperlukan untuk membuat keputusan, dan tidak menangguhkan keputusan yang tidak seharusnya. Tidak bergaya atau banyak membuat keputusan pada tingkat manajer proyek itu adalah yang diperhatikan, tapi prosentase membuat keputusan yang baik. Beberapa manajer akan diminta tanggung jawabnya rinci teknik keputusan hari ke hari, yang lainnya saat banyak yang akan didelegasikan ini kewenangan keputusan. Tiap metode dapat sukses , tergantung pada gaya manajer dan kecakapan tekniknya. Pendapat yang baik, dua-duanya orang dan dengan rasa hormat untuk teknisi dan keputusan manajemen, ini adalah kunci. Pendelegasian peranan penting boleh untuk diabaikan jika manajer adalah dinilai orang jelek dan pendelegasian banyak kewenangan keputusannya untuk anggota staf dengan keputusan yang jelek. Sisi lainnya, terlalu kuat kewenangan pembuat keputusan dapat gagalnya proyek ini yang ditunggu untuk manajer proyek untuk banyak membuat perincian teknik keputusan.

Kepandaian yang beraneka ragam dan Fleksibel (Versatility and Flexibility)
Perencanaan itu awalnya adalah kunci suksesnya proyek. Perencanaan yang baik dan persyaratan kecakapan manajemen untuk mengantisipasi dan mengatur pada perubahan yang tak diduga-duga itu terdapat di atas setiap proyek yang sebenarnya. Manajer proyek harus kapabel mengatur menempatkan kejadian kedalam prespektif, analisisnya dampak realistis dalam setiap aspek proyek, dan mempunyai keluwesan untuk perubahan yang dipersyaratkan. Ini tidak sedang dalam perubahan setiap waktu rencana deviasi biaya actual dari anggaran. Pembatasan ini sedang hingga proyek diperkenalkan obyektif dengan rencana yang berjalan, tapi dengan kemauan untuk menyelesaikan, bilamana persyaratan, untuk menjamin rencana itu terhadap yang mana status tindakannya adalah realistis dan akurat dasarnya untuk aktivitas manajemen.

Integritas (Integrity)
Untuk suksesnya perekrutan orang yang baik dan untuk menambah kepercayaan pelanggan manajer proyek harus mempunyai reputasi untuk kejujuran dan integritas. Dia jobnya mendorong yang lainnya dengan hasil proyek yang baik lengkap. Tipudaya, operator yang cerdas yang pertama boleh dipandang baik pada pemandangan sekilas, tapi bilamana timbul karakter permasalahan proyek manajer proyek akan terbatas pada bagian proyek. Jika kesulitan proyek disembunyikan, dampaknya akan semakin membesar bilamana jangkauan mereka terbatas bilamana mereka tidak dapat bersembunyi lama. Jika dia memutuskannya memikirkan kepentingan pelayanan dirinya sendiri, daripada kepentingan besar proyek dan perusahaan, ini akan segera kelihatan pada staf proyek. Permasalahan akhlak akan dengan cepat, menghasilkan staf yang keluar masuk.

Tinjauan kemasa depan (Foresight)
Kecakapan yang terlihat di depan, mengantisi permasalahan yang berpotensi dan jalan untuk penyelesaian, adalah perhatian untuk suksesnya proyek. Pengalaman adalah kontribusinya besar untuk tinjauan manajemen kemasa depan.

4.1.2 Titik Permulaan Proyek (Project Starting Point)

Dalam tahap definisi proyek untuk proyek internal hendaknya selekasnya, atau selama aktivitas proposal yang dipersaingkan diusahakan untuk mendapatkannya, pemilihan manajer proyek akan menerima peranan penting dalam kebutuhan titik permulaan proyek. Tugas ini antara lain termasuk :

1. Mengidentifikasi area yang beresiko tinggi dan
2. Kebutuhan biaya,
3. Jadual,
4. Perencanaan staff,
5. Pengalokasian tugas,
6. Dukungan persyaratan organisasi, dan
7. Proyek/pelanggan pendekatan antar muka.

Hasil aktivitas ini akan termasuk di dalam proposal manajemen dan Rencana Proyek. Rencana Proyek, digambarkan dalam Modul 3 definisi titik permulaan proyek. Bilamanakah memprakarsai

• mengupayakan pengembangan internal atau,
• kontrak untuk pengembangan piranti lunak atau,
• sistem untuk informasi pelanggan

Yang telah didefinisikan dalam Bab 3 yang akan didapat dalam Rencana Proyek Yang ditetapkan sebelumnya adalah sebagai berikut :

• rencana ini memberikan definisi apakah yang akan dikerjakan,
• bagaimana,
• oleh siapa,
• jadual dalam apa, dan yang mana
• manajemen dan alat pengembangan dan
• teknik yang akan digunakan

Pengawasan manajer proyek pada aktivitas pengembangan piranti lunak di dalam dasar persiapan rencana pada awal proyek dan diperbarui sebagai persyaratan. Kelengkapan manajemen ini ada beberapa orang yaitu assisten manajer proyek yang dengan suskses menyeluruhnya proyek pengembangan piranti lunak :

Ø Jadual,
Ø WBS,
Ø Dokumentasi,
Ø Tinjauan,
Ø Konfigurasi Pengawasan,
Ø Standar dan
Ø Konvensi/rapat-rapat,
Ø Organisasi fleksibel, dan
Ø Sub kontraktor

Bagian Rencana Proyek termasuk di dalam untuk setiap areal, yang menggambarkan maksud ini digunakan oleh setiap kelengkapan manajemen untuk mendukung tugas manajer proyek antara lain :

• Perencanaan,
• Analisis Laporan,
• Pemecahan Problem, dan
• Koordinasi Proyek.

Setiap kelengkapan menggambarkan dalam selekasnya bagian, kecuali untuk organisasi yang fleksibel dan sub kontraktor, yang mana didiskusikan dalam sesi 4.2 dan 4.3


4.2 ORGANISASI FLEKSIBEL

Sebelum itu mempunyai ketetapan dasar sumber untuk pengembangan piranti lunak adalah manusia, dan telah didiskusikannya filosofi dasar organisasi dalam perusahaan yang mana proyek harus beroperasi. Pengalamatan modul ini menggunakan organisasi fleksibel dalam proyek sebagai suatu pelengkapan manajemen sampai pendistribusian tanggung jawab dan personil proyek sebagai sumber dengan hasil yang baik lagi.
Dalam diskusi perkiraan biaya dan definisi Rencana Proyek, menarik perhatian untuk dimengerti yaitu :

• Tahap pengembangan,
• Lay out sekumpulan kegiatan, atau
• Langkah-langkah kejadian berlawanan dengan waktu, dan
• Perkiraan sumber syarat-syarat proyek sampai tugas selelesai.

Aktivitas ini sama merupakan pengembangan pertama yang teratur organisasi proyek yang efektiv. Untuk proyek pengembangan piranti lunak, mengenai ukuran dan keruwetan piranti lunak, prosesnya termasuk selesainya transisi pada tingkat berikutnya anarata lain :

1. Definisi Piranti Lunak (Software Definition). Identifikasi persyaratan piranti lunak dan antar muka dan definisi pendekatan rancangan sampai memenuhi syarat-syarat (Tahap Rancangan Awal).
2. Rancangan Piranti Lunak (Software Design). Perilaku analis, rancangan antar muka, kebutuhan rancangan rinci piranti lunak sampai persiapan untuk kode piranti lunak (Tahap rancangan rinci).
3. Kode dan Uji Coba (Code and Test). Seringkali menyerahkan sampai implemtasi dan validasi, termasuk kode, debug, uji coba programmer tingkat rendah dan piranti lunak formal verifikasi dan validasi (Tahap Implementasi dan Operasi).
4. Dukungan Operasi (Operational Support). Pemeliharaan piranti lunak diperlakukan dan dukungan operasi setelah piranti lunak diterima oleh pelanggan (Tahap Implementasi dan Operasi).

Tahap pengembangan piranti lunak tepat teridentifikasi adalah ringkasan dalam bab 2 dan digambarkan secara detail pada Bab 5-8. Untuk setiap tahap ini, barangkali kebutuhannya untuk struktur organisasi menyesuaikan dengan kinerja pekerja itu dalam tahap. Bagian berikutnya organisasi proyek selama didiskusikan pada tiap tahap ini.

4.2.1 Organisasi Rancangan Awal (Pleminary Design Organization)

Suatu organisasi yang khas sampai dengan sekumpulannya menyelesaikan tugas Tahap Rancangan Awal ini diperlihatkan dalam gambar 4.1. Manajer Proyek Piranti Lunak harus menegaskan persyaratan analisis antara lain :

• Identifikasi antar muka (interface) dan
• Definisi dan
• Fungsi Perencanaan Perancangan sampai
• meningkatnya kualitas piranti lunak yang dihasilkan dan probalitasnya sukses.
• Untuk proyek sistem yang besar,
• banyak inisial aktivitasnya termasuk di dalamnya mendukung persyaratan tugas analis tingkat sistem,
• tugas berikutnya oleh analis sistem atau piranti lunak.
• Untuk proyek yang kenyataannya terbukti keras sebagai aktivitas pengembangan piranti lunak,
• banyak analis sistem level aktivitasnya mendahului pembukaan proyek

Setiap aktivitas utama yang teridentifikasi pada elemen organisasi untuk Tahap Rancangan Awal dalam Gambar 4.1 adalah sebagai berikut :

1. Sub Kontrak Manajemen ( Subcontract Management). Sebuah SubKontrak fungsi manajemen akan segera diadakan setelah kebutuhan yang tidak bisa dipungkiri selesai dibuat atau beli perencanaan, Tanggung jawab utama fungsi manajemen sub kontrak adalah sampai dukungan menyeleksi subkontrak dan memberikan pengawasan dan konsumen antarmuka untuk piranti lunak dan piranti lunak dan piranti keras berhubungan subkontraktor.
2. Sistem Rekayasa Piranti Lunak (Software System Engineering). Fungsi Sistem Rekayasa Piranti Lunak adalah bertanggung jawab untuk definisi persyaratan dokumen, sistem analis, dan dasar rancangan piranti lunak. Organisasi ini mempunyai pertanggungan jawab untuk Persyaratan Spesifikasi Piranti Lunak yang dihasilkan dan Fungsi Dokumen Rancangan. Ini adalah tanggung jawab untuk perencanaan dan memimpin Tinjauan Persyaratan Piranti Lunak dan Tinjauan Rancangan Awal.
3. Jaminan Kualitas (Quality Assurance). Fungsi jaminan kualitas adalah organisai yang terbaik untuk terjaminya pengembangan dan penyerahan berdasarkan perjanjian penerimaan hasilnya. Assiten ini dengan program jadualnya, pemantauan rancangan vs persyaratan, tingkat persyaratan tingkat uji coba rencana pengembangan. Seluruh dokumen akan diaudit oleh penjamin kualitas, memerksa kembali dokumen standar dan persyaratan kontrak.
4. Produk Pengawasan (Control Product) . Fungsi Produk Pengawasan mempunyai fungsi utama pertanggungan jawab untuk mekanisme konfigurasi manajemen piranti lunak. Ini juga rencana prosedur untuk proyek Komputer Program Perpustakaan.

4.2.2 Organisasi Rancangan Rinci

Bilamana Rancangan Awal ditinjau kelengkapannya, terutama dari pergantian syarat-syaratnya dan fungsi analis sampai dengan rancangan analis serta pembuktian perencanaan. Organisasi yang khas sampai menyelesaikan sekumpulan tugasnya dengan tahap ini yang diilustrasikan dalam Gambar 4.2. Peralihan dari tipe organisasi diperlihatkan dalam Gambar 4.1 biasanya akan terjadi secara berangsur-angsur, dengan menyelesaikan pergantian dari fungsi sistem rekayasa piranti lunak sampai pada format fungsi pengembangan piranti lunak baru.
Aktivitas utama setiap elemen organisasi adalah mengedintivikasi Tahap Rancangan Rinci antara lain :

• Subkontrak Manajemen
• Sistem Rekayasa Piranti Lunak
• Jaminan Kualitas
• Pengembangan Piranti Lunak
• Control Product.

Fungsinya jaminan kualitas diperlihatkan dalam Gambar 4.3 dilakukan secara independen pemantauan kualitasnya

1. Manajemen Subkontrak. Fungsi ini tinggal sangat utama yang sama, kecuali pemilihan pemborong bawahan, yang harus diselesaikan sepanjang Tahap Disain Persiapan.
2. Rekayasa Sistem Piranti lunak. Perubahan sebagai hasil Disain persiapan Tinjauan ulang harus di gabungkan ke dalam dokumen yang telah diproduksi sepanjang Tahap Disain Persiapan. Sistem Perangkat lunak fungsi rancang-bangun melanjut monitoring disain piranti lunak dan kebutuhan, dan mengkoordinir produksi Dokumen Disain Yang terperinci bersama dengan pengembangan piranti lunak/software berfungsi. Sistem Piranti lunak fungsi rancang-bangun juga merencanakan Tinjauan ulang Disaen Kritis.
3. Penjamin Kualitas. Selama desain terperinci, fungsi jaminan menyiapkan rencana untuk semua pengujian formal diuji. Ini memerlukan monitoring pengembangan piranti lunak/software dan rancang-bangun sistem piranti lunak itu berfungsi. Itu juga memulai persiapan verifikasi program komputer dan penerimaan pengujian prosedur.
4. Pengembangan Piranti Lunak/Software. Fungsi Pengembangan software diformat untuk menyiapkan disain piranti lunak yang terperinci. Persandian informal mungkin dilaksanakan dan simulasi pengembangan untuk memperoleh pengertian yang mendalam ke dalam unsur desain. Fungsi Pengembangan piranti lunak/software menyiapkan rencana pengujian untuk semuanya dieksekusi oleh programmer pengembangan sebelum verifikasi formal pengujian. Fungsi juga mengambil bagian Tinjauan ulang Desain Kritis.
5. Pengawasan Produksi. Tanggung-Jawab fungsi pengawasan produksi sangat utama sama halnya selama Tahap Desain pendahunan bagaimanapun, jumlah aktivitas meningkat menurut perbandingan dengan kemajuan langkah-langkah program.

4.2.3 Implementasi Organisasi
Seteleh Tinjauan Rancangan Kritis, perhatian proyek berganti lagi. Pengembangan piranti lunak berfungsi kontinyu sampai pemeliharaannya, memberikan tambahan dukungan programer sampai selesainya kode dan percobaan yang ditugaskannya. Organisasi mencoba berhubungan yang menekankan pada persiapan dan untuk penyelesaian uji coba piranti lunak secara formal. Sampai menyelesaikan tugasnya yang diimplementasikan, suatu ke-khas-an organisasi termasuk di dalamnya tentang fungsi yang diilustrasikan dalam Gambar 4.3.
Setiap aktivitas utama element organisasi diidentifikasi untuk periode implementasi adalah digambarkan sebagai berikut :

1. Manajemen Subkontrak . Manajemen subkontrak berfungsi kontinyu dengan perbedaan yang relatif sedikit dari Tahap Rancangan Rinci.
2. Sistem Rekayasa Pintai Lunak. Diutamakan sampai tahap permulaan ini, seluruh spesifikasi pertama dan kelengkapan dokumen. Sistem rekayasa piranti lunak dalam perusahaan berfungsi menghasilkan Tinjauan Rancangan Kritis dan meninjau kembali spesifikasi dan dokumen yang hanya menyusun perubahan rancangan piranti lunak. Persiapan akhir persyaratan Dokumen Instruksi Operasi sampai pada dukungan penerimaan dan pemesanan piranti lunak bagian terakhir dan persiapan untuk menyelesaikan Fungsi dan Audit Konfigurasi Fisik dengan pelanggan.
3. Jaminan Kualitas. Besarnya fungsi ini bertambah terkenal selama tahap ini sampai dengan memelihara pengawasan pada pelbagai aktivitas uji coba. Fungsi jaminan kualitas adalah bertanggung jawab untuk memberikan verifikasi program komputer dan penerimaan aktivitas uji coba. Ini juga bertanggung jawab untuk kesaksian dan pelaporan kinerja uji coba oleh berfungsinya pengembangan piranti lunak dan seluruh uji coba dikerjakan oleh subkontraktor.
4. Pengembangan Piran Lunak. Tugas yang besar peng-kode-an program komputer dan pemeriksaan informal yaitu kode adalah inisial kinerja tuganya oleh fungsi ini. Pada persiapan pengembangan (unit dan tingkat modul) prosedur uji cobanya dan yang akan memimpin kinerja uji coba oleh fungsi utama pengembangan piranti lunak sampai piranti lunak ditransfer dan dukungan material hingga Program Komputer Kepustakaan. Yang berikutnya uji coba tingkat tinggi adalah didukung oleh fungsi pengembangan piranti lunak sebagai persyaratan.
5. Pengawasan Produk. Aktivitasnya kontinyu dengan bertambahnya perhatian dalam pangawasan dan status pelaporannya.

Fungsi jaminan kualitas diperlihatkan dalam Gambar 4.3 independen kualitas kinerjanya termonitor dan fungsi uji coba dalam mendukung proyek piranti lunak. Dalam gambar ini fungsinya adalah pelaporan yang diperlihatkan untuk manajer program. Fungsi ini barangkali kinerjanya oragnisasi independen dalam organisasi, perusahaan terpisah pembayarannya oleh pelanggan seperti asosiasi kontraktor untuk fungsi kinerja ini, atau oleh grup pada organisasi pelanggan. Verifikasi dan penerimaan uji coba fungsinya adalah seringkali terpisah dari kualitas tinjauan fungsi dan barangkali terpisah organisasinya, sebagaimana yang dihubungkan nama-nama pada :

• Uji Coba Formal,
• Uji Coba Sistem,
• Uji Coba Verifikasi,
• Uji Coba Independent, atau
• Verifikasi Independen dan Validasi.

Struktur organisasi organisasi setelah penerimaan piranti lunak adalah sangat tergantung pada tingkat pendidikan dan peningkatan aktivitas itu pelanggan memilih yang dimasukan sebagai bagian operasi dan aktivitas pemeliharaan. Proyek mungkin konsis pada grup programming yang kecil untuk memelihara kode, dengan dukungan dari fungsi pengendalian produk (Operasi Komputer Program Library, pengendalian konfigurasi, dan permasalahan status pelaporan). Jika peningkatan aktivitas adalah termasuk, sistem rekayasa piranti lunak yang kecil dan pengembangan piranti lunak fungsinya juga boleh diwajibkan.

4.2.4 Ringkasan Pertanggungan Jawab Organisasi
Gambar 4.4 dan 4.5 memberikan ringkasan pertanggung jawaban organisasi untuk dokumentasi dan uji coba fungsi oleh tahap pengembangan. Gambar ini adalah basis dalam suatu definisi struktur organisasi dalam Gambar 4.1, 4.2 dan 4.3. banyak variasinya dalam suatu struktur organisasi adalah memungkinkan, mempercayai dalam ketelitiannya pada suatu proyek.barangkali sebagian besar berat berlatihnya adalah suatu definisi uji coba struktur organisasi. Suatu organisasi disini mendefinisikan gambaran pengawasan programmer pada unit tingkat uji coba dan organisasi pengawasan pada modul yang uji cobanya terintegrasi, dengan memantau dan dukungan dari fungsi jaminan kualitas, pada grup yang indepeenden dalam proyek. Persyaratan uji coba sekali lagi, verifikasi uji coba, dan penerimaan uji coba adalah kinerjanya organisasi penjamin kualitas.Banyak variasi pada tema ini adalah memungkinkan. Untuk latihan, uji coba kewajiban yang telah diberikan fungsi penjamin kualitas dalam Gambar 4.3 dan Gambar 4.5 adalah dapat ditangani oleh fungsi sistem uji coba, dengan dipantau oleh penjamin kualitas. Alternativ, dalam uji coba yang independen dan grup verifikasi paling lama pengembangan proyek piranti lunak diperbolehkan syarat-syaratnya oleh kontrak atau manajer proyek. Dalam proyek yang berskala kecil, kegiatannya, fungsi penjamin kualitas independen tidak boleh dipersyaratkan, dengan kewajiban yang khas ini adalah tanggung jawab manajer proyek, dengan tambahan dukungan dari fungsi pengembangan piranti lunak.

Maksud uji coba yang independen adalah sampai diberikannya tambahan jaminan kualitas sampai berhasilnya piranti lunak. Beberapa kesalahan adalah hak subyektivitas perancang atau programer, dan uji coba yang independen adalah cara kompensasi untuk subyektivitas. Faktor hingga pertimbangan dalam pembatasan keperluan untuk uji coba yang independen termasuk di dalamnya : biaya, kuantitas kepercayaan itu akan memperoleh keuntungan, kekritisan piranti lunak sampai uji coba, ukuran pada pengembangan piranti lunak diupayakan, pada pengembang piranti lunak yang kapabel, derajatnya yang mana sampai menyatakan tidak langsung rencana uji coba adalah berterus terang (karena itu lebih lanjut bebas menginterprestasikan hasil uji coba subyektiv).

Keuntungan yang utama pada grup uji coba independen adalah :

1. Komprehensif/ meliputi banyak hal dan luas uji cobanya,
2. Subyektivitasnya dieliminir dan tetap interes dalam prosedur uji coba,
3. Kekurangan yang dikhawatiran diketahui pada implementasinya yang tidak baik, dan
4. Berpengalaman dalam kedisiplinan uji coba piranti lunak dan ini adalah sekumpulan dan verifikasi peralatan.

Yang terpenting keadaan merugikan pada pelaksanaan uji coba yang independen adalah sebagai berikut :

• Biaya secara keseluruhan besar,
• Persyaratan waktu yang panjang, dan
• Beberapa kemungkinan termasuk tak realistik atau tak relevan uji cobanya.

Secara umum keadaan merugikan pada uji coba independen jauh lebih berat dari pada keadaan merugikan bilamana menyisihkan faktor biaya. Uji coba independen selalu akan menolong jika tim uji coba adalah sungguh-sungguh independen dalam pertanggung jawabnya dan terpisah dari fungsi pengembangan sistemm informasi dan piranti lunak.
Bagaimana persoalan bukan pada uji coba dan seluruh fungsi lainnya dalam diskusi yang terdahulu adalah telah diatur alokasinya, ini adalah yang diperhatikan sampai dengan jelas digambarkan setiap fungsi dan memberikan tanggung jawab. Pemilihan organisasi harus dengan jelas definisi Rencana Proyek.


4.3 SUBKONTRAKTOR PIRANTI LUNAK

Ini adalah yang sebenarnya bukan perbedaan diantara manajemen piranti lunak dan manajemen subkontrak piranti lunak. Peraturan sama pengembangan piranti lunak akan sukses diaplikasikan sampai subkontraktor, adalah mereka yang baru saja dipergunakan sampai seluruh elemen lain proyek. Berikutnya kunci garis pedoman yang akan diikuti oleh manajer proyek siapa subkontraktornya pada beberapa pekerjaan pengembangan piranti lunak adalah sebagai berikut :

1. manajer proyek akan memberikan sebuah kontak titik tunggal sampai memanaj subkontraktor : manajer subkontrak,
2. manajer subkontrak akan menunjuk sampai setepat mungkin praktis pengembangan piranti lunak dalam subkontraktor (lihat bag.2), benar-benar manajer proyek menentukan mereka yaitu : supervisor, group leaders, assisten manajer proyek, atau paket kerja manajer proyek.
3. Subkontraktor Rencana Proyek, yang isinya sama dengan Rencana Proyek, persyaratan subkontraktor. Rencana itu akan didefinisikan dengan jelas sebagai berikut :
   a. Apa yang akan dikerjakan (persyaratan & WBS).
   b. Oleh siapa akan dikerjakan (perencanaan organisasi),
   c. Tanggal berapa (schedule)
   d. Biayanya banyak akan bagaimana (budget)

4.3.1 Pertimbangan Subkontraktur
Jenis pertimbangan berikutnya jenis perhatian yang akan dipertimbangkan bilamana penyeleksian perusahaan sebagai subkontrak piranti lunak antara lain

1. Perusahaan tertarik dan solider,
2. Skil Manajemen Perusahaan dan derajat komitmen dukungan manajemen terhadap proyek anda.
3. Reputasi perusahaan dengan pelanggan lain.
4. Pengalaman dan reputasi ketelitian individu sampai ditentukannya job anda (pertimbangan biasanya kebanyakan lebih berat daripada yang lain).
5. Pengalaman perusahaan dan prosedur formal dengan respek hingga pengembangan piranti lunak.
6. Kecakapannya didemonstrasikan sampai orang baru yang menarik hingga persyaratan perusahaan memuaskan.
7. Biaya yang efektif.

4.3.2 Seleksi Subkontraktor
Dua jalan utama yang ditempuh sampai digunakannya subkontraktor pengembang sistem informasi dan piranti lunak antara lain :

1. Konsultan dan body-shop kontraktor (tiap jam : personil subkontraktor sebagian kembali ke tim di rumah adalah dimanaj khas oleh staff proyek.
2. Kontraktor didefinisikan untuk suatu job porsinya tetap.

Belakangan menguasai satu teknik dari dua terutama yang tak menguntungkan subkontraktor : kekurangan pengawasan kinerjanya belebihan. Kedua Yang tidak menguntungkan subkontraktor masalah biaya. Sejak kontraktor yang terbaik melaksanakan administrasinya ongkos dan keuntungan sampai biaya subkontraktor, dan sejak kontraktor yang baik mensuplai personil khusus hingga memantau penunjukan subkontrak, didapat hasil bersih besarnya biaya sampai pada pelanggan. Akan tetapi besarnya biaya, barangkali, jika diimbangi :
1. Kontraktor yang baik tak dapat bekerja (kekurangan staff atau skil),
2. Subkontraktor kinerjanya dapat bekerja dan lagi sangat effisien karena berpengalaman atau lainya yaitu pangsa pasar menguntungkan, atau
3. Subkontraktor mempunyai tenaga kerja yang ongkosnya murah.

Penyeleksian subkontraktor adalah yang dapat memperhatikan tugasnya itu, dan seringkali prosesnya panjang. Gambar 4.6 ilustrasi flow aktivitas formal termasuk di dalamnya kompetitif dalam penyeleksian subkontrak atau nonkompetitif subkontrak ini tahapnya formal tidak diperoleh persyaratannya, pada chart akan ditinjau sampai diingatkan manajer proyek biasanya tahap persyaratan dalam penyeleksian subkontrakor.

4.3.3 Manajemen Subkontraktor
Waktu subkontraktor diseleksi, sub kontrak dimanaj oleh subkontraktor dengan cara yang sama itu assisten manajer proyek atau paket pekerjaan manajer dilaporkan sampai manajer proyek dalam memanaj setiap proyek yang mereka tugaskan. Manajer subkontrak akan kerja berikutnya adalah :

1. Syarat subkontraktor Struktur Pekerjaan Diuraikan dengan Rinci,
2. Syarat dalam aktivitas jaringan kerja itu ditampilkan ketergantungan kegiatan internal dan kegiatan eksternal. Ketergantungan subkontraktor pada kegiatan eksternal kembali pada tanggung jawab manajer subkontrak.
3. Subkontraktor yakin mengawasi sebagaimana mestinya pendistribusian pekerjaan sampai organisasinya mendapatkan yang selayaknya, teknik yang digunakan sunguh-sungguh sebagai suatu otorisasi pekerjaan proyek. Otorisasi Pekerjaan Proyek adalah pada kontrak yang intraorganisasi, dan definisinya sama tepatnya dengan Rencana Proyek siapakah yang mengerjakan, oleh siapa, bilamana, dan berapa banyak.
4. Menentukan syarat-syarat untuk memproduksi sebuah master schedule peristiwa penting dalam subkontrak. Schedule ini adalah diproduksi dalam hubungannya biasa dan biasanya dengan bagian subkontraktor Rencana Proyek.
5. Menentukan persyaratan subkontraktor itu yang memberikan status laporan biaya dan tinjauan dan mengerti seluruh penyimpangannya. Formatnya akan konsisten dengan perjanjian proyek komitmen laporannya.
6. Kelakuan seluruh subkontrak ditinjau, biasanya ini akan mengidentifikasi sekumpulan tinjauan dalam Bab 2 (Gambar 2,5) dan digambarkan secara rinci dalam Bagian II.
7. Mengetahui siapa personil kunci subkontraktor dan subkontraktor mengerti rencana untuk dapat dipakai sebagai pengganti.

Subkontraktor Pengembangan Piranti Lunak dapat menugaskan yang sangat produktiv jika subkontraktor adalah dengan hati-hati menyeleksinya dan dimanaj sama dengan teliti cara penugasannya dalam proyek.

4.4 PROSES MANAJEMEN

Satu atribut utama membedakan pengembangan sistem informasi dan piranti lunak dari pengembangan piranti keras adalah kekurangan hal referensi fisik untuk membantu mengukur pelaporan. Menambah permasalahan manajemen dan membuat proses manajemen banyak kekomplekan lainnya. Bagaimana memanaj waktu itu mengerjakannya bermacam proyek? Bagian sebelumnya menyediakan jawaban: perencanaan yang hati-hati, realistis harganya, efektif organisasinya, dan konstrukstif menggunakan dokumen dan tinjauan. Bagian ini mengalamatkan elemen lainnya sangat diperhatikan pada proyek pengembangan sistem informasi dan piranti lunak proses manajemen : mengerti job manajer proyek sistem informasi dan piranti lunak, manajer pelaksana proyek, manajemen personil, manajement teknisi, manajemen biaya, dan efektif digunakan mendukung pelayanan.

4.4.1 J o b
Sebagai manajer proyek, adalah bertanggung jawab untuk perencanaan proyek, staf, pelaporan analisis, pemecahan masalah dan coordination. Anda membuat keputusan pendekatan itu menentukan yang diterima tim proyek dan akhirnya menentukan proyek yang sukses. Apa keputusan anda yang diperlukan untuk mengerjakan, bilamana akan mengerjakan, dan siapa atau organisasi proyek yang mana baik kinerja tugasnya. Satu pada kebanyakan kesulitan konsep untuk manajer proyek baru untuk mengerti itu adalah tidak memutuskan bagaimana tugas yang telah terjadi.

Untuk proyek kecil, kinerja anda dari pada yang lainnya satu aturan. Barangkali anda Chief engneer atau peranan teknisi, sama baiknya dengan manajer proyek. Dalam kasus ini, anda akan sungguh-sungguh berbelit-belit bagaimana tugas yang telah terjadi dan teknisi itu menjual peranan penting untuk menyeleksi penyelesaian. Seringkali terlalu, bagaimanapun pendekatan ini adalah mengangkat keluar untuk proyek besar, bilamana manajer proyek tak dapat hasil yang baik menyediakan kedua-duanya tekninisi dan kepemimpinan administrasi. Keinginan tahu kualitas teknisi dan kinerjanya, yang mana peranan penting untuk promosi ke manajer proyek, harus surprise. Ini harus menempatkan lagi dengan yang asosiasi kualitas dengan manajemen, yang menentang dengan kinerja, tugas teknisi. Sebagaimana suatu kinerja, kualitas itu membawa perhatian dan mungkin promosi yang mempunyai pengetahuan dan spesial teknisi, ketrampilan teknisi yang dipercaya, bergairan dan keinginan tahu teknisi, dengan kecakapan bekerja walaupun dengan petunjuk yang minimum dan tugas menyelesaikan permasalahan. Ini adalah kualitas. Ini adalah kualitas anda sukai itu untuk melihat seseorang dalam proyek. Tapi sebagai manajer proyek, mereka kualitas mereka tidak luas itu baik keputusannya anda sukses atau gagal. Dalam fakta , mereka mungkin memperoleh jalan pada job anda.
Bilamana cocok menjadi manajer proyek, tujuan, dan prespektif harus dirubah :

1. Harus terfokus perhatiannya pada hasil, bukan bagaimana caranya mereka menghasilkan. Anda mengijinkan untuk membiarkan keputusan yang lainnya bagaimana bagian job dikerjakan dengan baik, terjadi lebih dulu ketrampilan teknis anda ceriterakan bagaimana mereka “ sebaiknya” untuk mengerjakannya.
2. Harus menentang godaan untuk mengerjakan banyak job bagi dirimu sendiri (belajar untuk delegasi). Anda harus memperhatikan yang lainnya harus dikerjakan job anda “tahu” akan mengerjakan makin baik dan cepat.
3. Tidak dapat lama menyandarkan diri pada yang lainnya untuk memberitahu pekerjaan selanjutnya.
4. Kebaikan tak sebanyak kesempatan yang digunakan ketrampilan teknis seperti pindah ke proyek yang besar.
5. Perhatian besar yang baik adalah masalah manajemen orang dan motivasi orang bukan masalah teknisi.

Beberapa outline ini realistis langkahnya untuk manajemen proyek. Bagaimana mengerjakan satu dari pada membuat transisi ini ? Sebagian besar oleh point kesadaran adil kedengarannya dan utilitas penunjuk garis dan ceklis disediakan oleh persahaan anda kebijakan pengendalian proyek, banyak artikel jurnal pada subyek, dan buku sebagaimana yang satu ini. Gambar 4.7 disediakan pada cek list tambahan pertimbangan untuk empat job manajer proyek piranti lunak. Manajer sangat baik yang akan mempunyai ceklis yang serupa, yang mana dapat berhubungan secara tetap, dalam laci menja tulisnya dia surat peringatan Tanggung jawab manajer proyek.
Esensi list yang disediakan dalam gambar 4.7 adalah rencana manajer proyek harus, meninjau laporan, penyelesaian masalah, dan koordinasi (peranan penting) aktivitas proyek.

4.4.2 Manajer Pelaksana Proyek

Sebagai manajer proyek untuk proyek piranti lunak atau beberapa proyek lainnya, langkah utama terhadap kesuksesan adalah belajar untuk memananj diri sendiri. Ini termasuk belajar bagaimana untuk memanaj waktu, bilamana untuk actual, bilamana rencana diulang, dan bagaimana untuk memperoleh tinjauan ke belakang proyek termasuk prespektifnya.

• Persiapan dan pemeliharaan suatu penulisan rencana petunjuk, tapi bukan kinerja, tugas teknisi
• Pendengaran untuk personil proyek
• Tersedianya untuk penyelesaian masalah
• Dengan jelas definisi tugasnya
• Menganjurkan kreatif berfikir, pendekatan, dan penyelesaian
• Pengendalian kontrak pelanggan: penahan/penyangga campur tangan
• Penyangga organisasi hal-hal yang sepele
• Seperangkat kejadian penting yang berarti
• Periksa laporan yang bertentangan dengan rencana
• Menuntut dengan tegas pada tinjauan tetap proyek dengan bos anda
• Promosi karier pengembangan dan pelatihan staf
• Menafsikan/mengartikan kontrak
• Mendesak aktivitas dengan yang disyaratkan itu berdasarkan perjanjian
• Menggunakan pertemuan, dan tinjauan yang berguna
• Menyusun standar proyek dan persyaratan kompilasi
• Sumberdaya utilitas perusahaan sebagaimana kontrak, penjamin produk, dan relasi industri.
• Tersedianya untuk kemungkinan
• Memanaj waktu yang sewajarnya efektif.
  

Gambar 4.7, Tanggung jawab Manajer Proyek Piranti Lnak

Manajemen Waktu
Bagian utama job sebagai manajer proyek adalah untuk promosi keefektipan dalam proyek yang lainnya. Ini adalah pandai oleh banyaknya waktu anda untuk orang, termasuk kesediaan untuk konsultasi pada beberapa subyek dan memelihara sentuhan dengan personil proyek pada setiap hari. Pada proyek yang besar ini adalah mudah untuk manajer proyek menjadi terpencil dari aktivitas proyek sebagai antar muka dia dengan pelanggan, subkontraktor, dan organisasi perusahaan lainnya. Sebagai suatu akibat, dia tidak punya waktu untuk memanaj atau petunjuk proyek. Untuk menghindari keterpencilan ini, manajer proyek harus mengambil langkah untuk dia memanaj waktu yang selayaknya.

Manajemen waktu adalah dengan suatu analisis waktu anda yang diminta, evaluasi yang signifikan setiap tipe persediaan, dan anda menggunakannya optimal yang disediakan. Untuk manajer proyek piranti lunak, ini mendapat kepandaian oleh tiga klas definisi aktivitas dan daripada alokasi setiap waktu yang diminta atau aktivitas untuk satu kelas ini. Tiga kelas ini adalah sebagai berikut :

1. Aktivitas Pertama
Aktivitas yang mempunyai efek signifikan pada proyek dan dapat tiada seorangpun yang didelegasikan maupun disisihkan.

2. Aktivitas Kedua
Aktivitas siapa yang efeknya proposional dengan waktu yang disyaratkan untuk mereka selesaikan. Aktivitas ini dapat dan akan didelegasikan untuk proyek besar. Untuk proyek kecil mereka akan didelegasikan untuk keperluan yang luas untuk menyelesaikan tugas utama.

3. Pekerjaan Sibuk
Yang mana aktivitasnya mempunyai efek sedikit pada proyek. Aktivitas ini seluruhnya akan didelegasikan atau disisihkan.

Manajemen yang baik waktu yang disyaratkan manajer proyek untuk petunjuk porsinya waktu besar untuk aktivitas utama, pendelegasian cukup pada aktivitas sekunder dengan menyediakan waktu untuk kelengkapan aktivitas utama, dan mengeliminir atau mendelegasikan seluruh aktivitas kerja yang sibuk. Contoh tipe aktivitas yang dialokasikan untuk setiap kelas adalah seperti yang tersedia dalam Gambar 4.8.

Ironis, satu permasalahan pada beberapa proyek engineering, sama halnya dengan manajer proyek, adalah tendesinya kuat dengan kecepatan yang berkongsi besar yang didapat waktu pekerjaan sibuk, bilamana kejadian mereka yang mengetahuinya ini adalah masalah serius untuk yang mana kebutuhan mereka akan langsung diteliti aktivitas utama dan aktivitas sekunder. Ini adalah ungkapan itu yang menggambarkan fenomena ini: “grazing on concrete.” Ungkapan datang dari analog fenomena dalam industri sapi. Bilamana sapi adalah mengakibatkan untuk pemuatan kandang dan lainnya adalah dengan mengendarai di atas ramp termasuk jalan kereta api persediaan mobil, mereka seringkali memindahkan untuk sudut paling ujung pada rumput dan kandang, kejadian yang lebih dulu ini adalah rumput. Mereka yang mengetahui ramp itu adalah permasalahan riil untuk mereka, mereka juga memilih dengan mengabaikan tanggung jawab ini yang hampir menyerupai kenyataan.

Aksi versus Reaksi
Menajemen waktu yang baik membantu untuk mereduksi tendensi manajer proyek dengan reaksi atau manajer pemadam kebakaran. Mempunyai waktu yang tersedia untuk mempelajari permasalahan dan rencana mereduksi penyelesaian ketegangan itu promosi dengan reaksi yang tergesa-gesa. Seringkali kualitas reaksi cepat dan meyakinkan untuk seluruh permasalahan, beberapa waktu dengan informasi yang cukup, kasus subordinat dengan menyembunyikan permasalah yang potensial.

Ini dapat terjadi jika mereka adalah ketakutan manajer proyek akan cepat mengambil, menentukan reaksi daripada mendengarkan dengan rencananya untuk menahan permasalahan yang berpotensi. Manajer proyek yang baik adalah harus sanggup untuk menentukan untuk perbuatan dia bilamana dengan mendukung aksi pada subordinat. Pada kasus yang belakangan, dia akan memonitor situasi, dia menentukan posisinya jika diperlukan, dan membawa sumberdaya proyek yang lainnya yang permasalahannya hanyapersyaratan. Begitu bijaksana reaksinya yang membesarkan hati secepatnya teridentifikasi permasalahan yang berpotensi. Subordinat yang baik daripada situasi begitu teridentifikasi, karena mereka itu yang mengetahui manajer proyek yang baik tidak berlebihan reaksinya dalam mempertahankan tugas yang dibawakan kecuali kalau realita permasalahan yang membenarkan aksi seperti itu. Mereka baik juga menganjurkan dengan situasi permukaan begitu secepatnyasejak mereka mengetahuinya permasalahan itu di pending baik bantuan dengan membuatnya prioritas untuk sumberdaya proyek dan waktu manajer proyek.

Yang tidak bisa dipungkirinya dirinya sendiri yang pada satu manajer beraksi siapa yang akan mengetahuinya permasalahan kecil lainnya dengan dukungan penyelesaian mereka oleh subordinat, daripada reaksinya yang cukup dengan mendadak permasalahan besar ditemukan manajer proyek harus menyaring kemampuannya untuk mempertimbangkan status permasalahan yang berpotensi. Patnya baik pada seluruh aksi/kegiatan di bawah samaran permasalahan yang ditahan terus subordinat adalah hampir sama buruknya dengan reaksi untuk setiap permasalahan sebagai satu krisis. Seorang manajer mengapa menolak untuk membuat keputusan keras yang dapat cepat alirannya dari air yang tenang memasuki aliran yang deras. Daripada dengan reaksi, mengambil pendukung aksi, atau memonitor aksi subordinat yang tergantung pada keseriusan permasalahan dan ini adalah dampak terletak pada usaha pengembangan. Manajemen waktu yang baik akan mengijinkan manajer proyek untuk mengalihkan waktu untuk mengerti permasalahan dan mengevaluasi alternatif, tanpa gangguan menghentikan proyek. Ini adalah bilamana waktu tidak untuk alasan mengevaluasi, tekanan dari area permasalahan dan yang lainnya mengganggu area penerangan yang baik sama sebuah seri yang berurutan bersentuhan melakukan pekerjaan berbahaya, berturut-turut yang lainnya serius sampai pada krisis pengembangan.

Direncanakan Ulang Kembali
Ini adalah mandatory proyek yang mempunyai rencana realistis yang mana menentang dengan ukuran pelaporan. Ini juga adalah sifat manusia yang tidak seharusnya lihatlah dalam kesulitan olehnya untuk kemajuan pelaporan itu mengecewakan rencana. Tendensi beberapa manajer adalah yang mendeklarasikan rencananya invalid dan direncanakan ulang untuk membuat keadaan nyata yang seimbang. Sebagaian besar proyek, bagaimanapun, sebagaian kecil mempunyai kunci anggaran selama peristiwa penting, sebagaimana pembiayaan tahun fiscal dan anggaran total, itu tidak berubah.terus menerus direncanakan ulang hanya diperketat waktu dan anggaran yang tersedia untuk tahap proyek yang belakangan. Pendekatan ini mendapat peranan penting dengan keadaan yang mana dua pertiga berjalan proyek selesai (menurut rencana yang terakhir) jadual atau anggaran tiba-tiba menjadi kritis, dan mengakhiri proyek dengan penyampaian setahun terlambat dan dengan biaya yang membengkak.

Jika kegiatan pelanggan adalah sepenuhnya tak dibuat-buat dengan betul-betul mengijinkan direncanakan ulang, manajer proyek harus mencari penyebab pokok permasalahan pada jadual atau anggaran. Perencanaan ulang biasanya adalah atas permintaan bilamana perubahan proyek besar terjadi, sebagaimana pada antar muka, terlambat penerimaan data dari luar organisasi, perubahannya dalam pembiayaan tahun fiscal, atau perubahan pada pesyaratan. Catatan itu sebagias besar ini biasanya hasil perubahan yang tertulis dalam perubahan kontrak. Bagaimanapun, bilamana permasalahan teknisi atau permasalahan staf adalah terjadi deviasi dari rencana, ini adalah kenyataan yang akan terus menerus untuk dilaporkan dan dimonitor.

Mereka tidak akan berkedok dengan penjadualan ulang.
Sebagai manajer proyek, anda harus dengan hati-hati menaksir motiv dan dampak seluruh rancana ulang. Tidak mencoba untuk melihat hari ini yang baik pada biaya hari esok. Yang akbibatnya anda menekankan hari ini, itu juga bilamana sebagian besar peristiwa penting diperhatikan penyampaiannya diperiksa, proyek yang baik ini dijumpai.

Perspektiv Ulang Kembali
Manajer proyek cenderung untuk menjadi ruwet sekali pada proyek di bawah pengendalian mereka, seringkali bilamana ujung-ujungnya mereka mempunyai kesulitan kalau sudah melihat tanda peringatan. Pada area teknisi, manajer proyek yang baik mendapatkan bantuan dari tinjauan teknisi oleh pakar dari luar, kejadiannya jika mereka adalah tidak dipersyaratkan pelanggan. Dalam area administrasi proyek, ini adalah bukan sebagai kemudahan atau otomatis. Sebagian besar perusahaan sekarang mempunyai standar evolusi proyek piranti lunak itu dipersyaratkan tinjauan teknisi untuk seluruh proyek, tapi seringkai terlalu persyaratan tidak serupa dan lainnya tinjauan manajemen sering. Manajer seringkali harus membujuk bosnya untuk mempertahankan tinjauan reguler atau percobaan untuk merubah prespektivnya pada interval reguler. Kami ini menetapkannya berhubungan dengan sebuah prespektiv ulang.
Jika sebagai bos tidak dipersyaratkan tinjauan reguler proyek untuk anda atau yang seringkali terlalu sibuk untuk menghadiri tinjauan, ini adalah terserah anda untuk memanaj diri anda sendiri. Pada kebanyakan jalan yang sama sepertinya anda mengevaluasi permintaan waktu pada anda, anda harus berbalik langkah dari rincian permasalah harian untuk menaksir status proyek yang benar. Melihat dengan hari-hati pada peristiwa penting tingkat atas, rencana staf, dan anggaran. Realistis taksirannya proyek berlawanan dengan rencana. Menanyakan pada diri anda sendiri yang agak menyelidik pertanyaannya anda akan mengharapkan dari bos anda atau tinjauan tim manajemen perusahaan.

Ini kembali prespektif anda giliran menaruh barang pada ruang yang layak. Tujuan anda proyek adalah sampai lengkap pengembangannya sebagai perencana dan sebagai bagian pada sebuah kontrak, yang salah satunya dengan resmi tertulis pelanggan sebelah luar atau dokumen internal yang disetujui diantara organisasi. Batas permulaannya prespektiv diulang kembali harus dilihat kontraknya dan analisis aktivitas proyek, rencana, dan permasalahan berlawanan dengan komitmen berdasarkan perjanjian. Ini adalah mudah untuk rekayasa piranti lunak sampai pada penambahan fasilitas ekstra yang mana mereka rasanya memerlukannya, kejadian yang lebih dulu tak disediakan di dalam kontrak. Kecuali kalau mereka dipersyaratkan rancangannya yang baik atau ini adalah alasan yang baik untuk mereka tambahkan (dan ini dapat dikerjakan sampai anggaran dan jadual), diskusi mereka dengan pelanggan. Jika pelanggan ingin mereka, perubahan dalam kontrak barangkali beres.

Untuk menyelesaikan pengulangan kembali prespektiv yang penuh dengan arti itu akan memperbaiki manajemen proyek anda, menanyakan kepada diri anda banyak pertanyaan proyek lainnya, rencana anda, staf, dan anda mengerti tugas proyek. Gambar 4.9, menyediakan dalam contoh benyediakan bermacam pertanyaan itu yang akan ditinjau.

Penjadualan
Penjadualan yang Optimis, adalah jadual yang dipaksakan tidak melihat dari aspek-aspek proyek antara lain sumber daya manusia yang terlibat langsung dalam proyek pengembangan piranti lunak apakah tersedia cukup seperti programmer, teknisi analis dan staf pendukungnya, serta tingkat kesulitan dari proyek itu sendiri dimana aktivitas proyek itu tiap-tiap kegiatan saling ketergantungan sehingga diperlukan ketelitian secermat mungkin.
Mengatasi penjadualan yang optimis, untuk mengatasi hal ini diperlukan

Penjadualan Optimis

• Jadual yang terlalu optimis telah menjadi bahan diskusi selama lebih dari 20 tahun, tetapi tetap saja terjadi.
• Merupakan jadual yang membuat stress tim pengembang.
• 50% dari proyek menetapkan jadual proyek sebelum keputusan kebutuhan sebenarnya ditetapkan.

Contoh :
Microsoft Word for Windows 1.0 ditetapkan dibangun dengan waktu : 395 hari. Padahal lintasan kritisnya 460 hari. Sasaran yang ingin dicapai :
1. Membuat Pengolah kata terbaik di dunia.
2. Dibuat dalam 12 bulan.

Kenyataan : 5 tahun, 660 man-months, 249.000 baris program.

• Proyek mengalami banyak turn-over (dari 4 orang pemimpin proyek : 2 orang mengundurkan diri dan 1 mundur karena alasan kesehatan).
• Karena jadual ketat, tim pengembang merubah kemampuannya, kualitasnya jadi rendah dan tidak lengkap. Sebab-sebab Penjadualan Optimis

Penyebab penjadualan optimis adalah adanya pengaruh eksternal yakni:

• Adanya pameran
• Perubahan pajak
• Hari raya

Manajer proyek dan pelanggan enggan memakai suatu estimasi rangkuman sehingga memakai estimasi tunggal. Manajer proyek dan tim menganggap ringan atau memang ingin bekerja di bawah tekanan. Pimpinan, bagian pemasaran atau pelanggan menginkan tanggal tertentu proyek dapat diselesaikan dengan baik dan bisa segera dioperasikan sedangkan pemimpin proyek tidak bisa berbuat apa-apa.Proyek diestimasi dengan buruk baik penjadualan dan biaya.

Gambar 4.9 Jadwal khusus pengembang. Pengembang yang secara khusus menaksir 20 sampai 30 persen lebih rendah dari keperluan nyata mereka. Hanya menggunakan perkiraan yang normal mereka menaruh kesempatan melengkapi tepat waktu di bawah 50 persen· Kualitas perencanaan proyek berakibat pada perencanaan lainnya seperti personil, pemilihan staf, modul yang harus dibuat dokumentasi, integrasi, pengujian.

• Proyek berjalan tanpa rencana yang jelas
• Waktu yang digunakan analisis dan perancangan menjadi lebih sedikit.
• Terlalu focus pada kemajuan proyek daripada kualitas kegiatannya sendiri.
• Mengurangi tingkat kepercayaan pelanggan.
• Penggabungan sehingga proses debug ini lebih sedikit.
• Hilangnya wibawa pemimpin proyek atau manajer proyek.
  

Mengatasi Jadual yang Optimis
Jadual optimis tidak dapat dipecahkan oleh pengembang secara cepat, kecuali dipecahkan lebih dulu masalah ketatnya jadual.

3 faktor yang dapat memunculkan masalah pada penjadualan :

1. Terlalu banyak berharap
   · Ingin dapat uang secepatnya.
   · Terlalu ambisius.
2. Mengabaikan atau belum pernah dengar cerita tentang estimasi pembuatan piranti lunak atau pengaruh sesungguhnya dari jadual yang ketat.
3. Lemahnya kemampuan saat negoisasi.
   · Pengembangnya introvert.
   · Kalah bernegoisasi dengan pihak pimpinan atau pihak marketing.
   · Pengembang tidak suka bernegoisasi.

Karena itu ketiga faktor tersebut harus dapat diatasi oleh tim pengembang. Faktor 1 dan 2 sudah dibahas pada pertemuan-pertemuan sebelumnya.

Strategi Negoisasi
Terdiri dari 4 bagian yaitu :

1. Pisahkan faktor manusia dengan faktor masalah. Bila kepribadian negoisator (pengembang vs pemasaran) berbeda jauh maka negoisasi akan sulit mendapatkan titik temu. Karena itu kemampuan untuk memahami pihak lawan sangat penting.
   o Perbaiki hubungan dengan pelanggan dengan membuka kerjasama.
   o Jangan emosi saat bernegoisasi.
2. Fokuskan pada minat, bukan posisi. Dengan menempatkan diri pada posisi, maka kondisi negoisasi adalah kalah-menang.
   § Tunjukan kelebihan pengembang secara cepat.
   § Tunjukan meningkatnya peluang keberhasilan.
   § Tunjukan keberhasilan pengalaman perusahaan.
3. Temukan pilihan-pilihan untuk mendapat kan manfaat bersama. Ada 3 hal yang bisa dinegoisasikan: jadual, biaya dan produk. Galilah dari 3 hal tersebut, faktor yan dapat dibuat pilihan negoisasi.
4. Minta ketegasan terhadap kriteria obyektif.
   o Jangan negoisasi tentang estimasi.
   o Bila perlu estimasi dilakukan oleh pakar.
   o Minta alasan prosedur estimasi

4.4.3 Manajemen Personil
Pada Bagian 4.1, kami diskusikan yang sebagian besar esensinya elemen yang pada awalnya ketepatan manajer proyek dalam penyeleksian sebuah proyek. Waktu ini mempunyai kepandaian, tugas individu itu adalah untuk merekrut staf proyek dan untuk memanaj nya ini sampai proyek sukses dengan kelengkapannya.

Perekrutan
Definisi persyaratan proyek biasanya adalah yang dikerjakan sebagai bagian persiapan proposal. Jika tidak, ini adalah sebagian besar harus diperhatikan jenisnya pada agenda manajer proyek pada awal proyek. Ketergantungan pada struktur organisasi perusahaan, manajer proyek harus merekrut dari dalam perusahaan, dan mungkin juga dari luar perusahaan, untuk memenuhi staf proyek yang diperlukan. Ini adalah harus diperhatikan oleh manajer proyek untuk mengidentifikasi areal resiko yang tinggi itu baik dipersyaratkan fakta-fakta orang yang berbakat atau berpengalaman unik. Penekanan dapat dari tempatnya mendapatkan orang kunci untuk menutup area proyek yang spesifik.

Pendekatan yang digunakan untuk merekrut staf untuk proyek dapat mempunyai efek yang abadi dalam sikapnya staf proyek. Kontak pertama yang dibuat oleh manajer proyek, pendekatan yang digunakan, informasi yang disediakan dalam proyek, dan deskripsi kandidat proyek berkewajiban akan memutuskan jika manajer proyek yang baik sukses dalam mentransfer kandidat untuk proyek atau menyewa kandidat dari luar perusahaan. Faktor ini baik juga mempengaruhi sikap kandidat suatu kejadian yang ditempatkan pada proyek. Kebijakan rekrutmen yang akan distandarkan dan disetujui pada kemajuan manajemen bawah. Komitmen dengan rasa hormat untuk tingkat job (promosi), kondisi pekerjaan, kompensasi, dan susunan administrasi yang berhubungan dengan perjalanan, relokasi, jam khusus bekerja, dan lembur yang akan mendapatkan prioritas untuk permulaan keperluan rekrutmen dengan konsisten menjamin komitmen untuk seluruh staf proyek.
Rekrutmen yang didiskusikan atau interview akan dimasukan yang paling sedikit seperti berikut ini :

1. Informasi umum lainnya latar belakang proyek, ini adalah tujuan dan tipe umum pekerjaan yang berbelit-belit.
2. Informasi organisasi proyek bagaimana yang baik ini interaksinya dengan aktivitas perusahaan lainnya banyaknya orang dengan segala keruwetan, siapa yang menentukan untuk teknisi besar dan posisi administrasi.
3. Deskripsi proyek menetapkan penawran.
4. Alasan penyeleksian kandidat sudah ditetapkan.
5. Deskripsi perubahan kompensasi dan perubahan klasifikasi job, jika apa saja, dimasukan dengan ketetapan proyek.
6. Diskusikan bahan administrasi yang berhubungan dengan relokasi, jam kerja, dan lembur yang pantas.
7. Yang bersangkutan dengan informasi lainnya yang berkenaan dengan proyek barangkali tidak sama dari proyek perusahaan lainnya yang mana kandidat barangkali familier.

Banyak identifikasi material untuk rekrutmen ini didiskusikan adalah keadaan dengan sebagian besar posisi itu adalah untuk dasar. Ini akan tertulis di bawah untuk menghindari salah pengertian dan dengan konsisten disediakan bilamana yang lainnya daripada supervisor atau anggota staf senior proyek adalah yang ruwet pada proses perekrutan proyek.

Setelah Perekrutan – Langkah Selanjutnya
Perekrutan mempunyai inisial staf proyek, manajer proyek harus memulai satu yang sebagaian besar manajemen berkepentingan pada aktivitas manajemen personil itu. Peranan penting manajer proyek terhadap staf harus bersama tujuan pengembanan khusus yang lengkap diperlukan. Pada suhu yang kondusif untuk membuka komunikasi, kebanggan, umpan balik yang positif, sikap yang konstruktiv telah dapat dengan ulungnya menyelesaikan kepemimpinan dengan baik, perlakuan yang fair, dan diperlukan kejujuran pada bagian manajemen proyek untuk bersama-sama bangga dengan staf proyek siapa yang membuat terjadi. Orang adalah banyak yang termotivasi oleh yang tidak dinyatakan secara jelas itu tergantung pada sikap pemimpin proyek terhadap individu pada proyek. Probalitias proyek sukses adalah mempertinggi signifikan bilamana orang dalam proyek yang tepat kontribusi mereka adalah diperhatikan. Ini adalah job manajer proyek, sewaktu dia merekrut sebuah grup individu untuk proyek, dengan memberikan mereka setiap perasaan penting dan membuatnya masuk tim proyek. Langkah pertama ini dalam proses terjadi selama aktivitas perekrutan. Oleh pemberitaan individu kenapa mereka telah mempunyai seleksi untuk proyek dan jelas definisi job-nya pada proyek, perasaan penting dan dimulainya spirit tim proyek. Yang telah dapat mengasuh selama proyek dengan banyaknya konsep manajemen personil yang sederhana :

1. Ingat komitmen yang dibuat selama proyek merekrut dan memikirkannya dalam rencana proyek.
2. Menganjurkan berkomunikasi dalam tim kegiatan yang konflik. Konflik yang keliru hingga memburuk akhirnya akan muncul ke permukaan dengan cara yang destruktif. Membawa secepatnya keluar dalam lingkungan penyelesaian permasalahan, konflik dapat diselesaikan ulang yang konstruktif, cara untuk menghindarkan malu.
3. Mengumpulkan ide dari anggota tim proyek.
4. Tersedianya peluang untuk anggota tim proyek untuk mendemonstrasikan keahliannya atau pengetahuannya di hadapan kawan sebaya mereka, pelanggan, dan manajemen tingkat atas.
5. Manajemen mungkin menyediakan pengakuann prestasi individu dan lengkap peristiwa pentingnya (i.e., tidak diperlihatkan interesnya hanya pada area persoalan). Yang demikian umpan balik yang positif adalah pendorong moral yang baik dan disediakan insentif yang meyakinkan untuk melanjutkan kinerja yang tinggi.
6. Jadi konsisten pada kebijakan administrasi personil.
7. Berikan kredit untuk kinerja personil proyek yang tidak mendapat kredit dari anda sendiri. Kredit akan datang untuk manajer proyek bilamana proyek telah lengkap dengan jadual dan biaya.
8. Menyediakan waktu pada jadual anda sebagai manajer proyek untuk orang yang bermasalah

Konsep ini, kombinasi dengan organisasi, yang akan diperlukan perencanaan, kontribusi yang baik sebagian besar sampai proyek berhasil. Untuk proyek yang besar, bagaimanapun, ini adalah tidak cukup untuk manajer proyek dengan menggunakan konsep manajement personil ini. Berhati-hati memilih manajer subproyek, paket pekerjaan manajer, pimpinan grup, atau tingkat apapun manajemen adalah menetapkan untuk proyek yang dipersyaratkan untuk promosi spirit tim dan sikap yang positif sepanjang proyek.

Penugasan Ulang
Satu pendekatan yang juga seringkali diberikan oleh manajer proyek, yang mana personil proyek frustasi, itu adalah frekuensi penugasan ulang. Manajer proyek yang mempercayakan itu oraginisasi harus direkstruturisasi, atau pada yang paling sedikit jumlah penugasan ulang dibuat, sampai pada setiap pertemuan proyek krisis. Berulang-ulang penugasan ulang staf dari satu tugas untuk yang lainnya signifikan

Langkah Selanjutnya
Kapan tugas individu proyek diselesaikan, manajer proyek berfungsi sebagai manajemen personalia tidak mungkin menyelesaikan. Tergantung pada kebijakan perusahaan itu, struktur organisasi, dan komitmen yang dilakukan di awal proyek, manager proyek mungkin mempunyai beberapa tanggung jawab untuk membantu personil perusahaan lain di dalam mengidentifikasi tugas yang baru yang sesuai untuk proyek yang ditinggalkan orang. Tanggung jawab ini, jika diabaikan, akan menghasilkan suatu hambatan pada pihak karyawan untuk menerima tugas proyek yang akan datang. Karyawan menghormati manager proyek siapa yang melanjutankan atas semua komitmen manajemen personalia dan tanggung-jawab, seperti halnya teknis dan tanggung-jawab manajemen adminitratif

4.4.4 Manajemen Teknik.
Tingkat manajemen teknik mengarahkan diperlukannya suatu manager proyek adalah suatu fungsi ukuran proyek dan jenis proyek. Karena proyek sangat kecil, manager proyek menyediakan teknis seperti halnya manajemen adminitratif. Karena proyek besar, manager proyek harus, seperti yang diuraikan bagian 4.4.1, memusatkan aktivitasnya pada yang lainnya bukan isu teknis proyek. Pada umumnya suatu sistem subprojek manajer rancang-bangun, dikepalai seorang engineer, atau seorang analis proyek senior didelegasikan kebanyakan dari otoritas dan tanggung jawab untuk aspek yang teknis proyek itu. Bagaimanapun, keputusan teknis yang utama berdampak pada biaya-biaya, jadual, antarmuka, atau lainnya unsur-unsur proyek tidak bisa didelegasikan dan harus dipecahkan oleh manager proyek itu sendiri. Teknis, sesuai kontrak, dan informasi administratif memerlukan untuk pembuatan keputusan dan rekomendasi yang harus disiapkan oleh spesialis perancang untuk dipertimbangkan oleh manager proyek.

Peralatan (tools), Konsep, dan teknik untuk manajemen teknik telah dibahas Bab 2 dan 3. penggunaan dokumentasi yang bersifat membangun dan tinjauan ulang disain barangkali yang paling kritis. Lingkungan itu menyediakan di mana jika proyek tidak dapat bermanfaat bagi spesialis teknis yang berpengalaman secara langsung mendukung usaha pengembangan itu untuk mengesahkan kebutuhan, disain, dan informasi test. Karena sejak beberapa konsep pengembangan menyediakan jarak penglihatan yang lebih teknis dibanding orang lain, pengembangan yang memilih pendekatan berdampak pada manajemen teknik. Bagaimanapun, konsep manajemen teknik yang utama diterapkan berlaku untuk semua orang. Suatu lingkungan harus menyediakan untuk teknis berkomunikasi, dokumentasi, tinjauan ulang, dan pengendalian. Standard untuk masing-masing harus dibentuk dan diperkuat oleh manager proyek. Buku ini menyediakan dokumentasi dan petunjuk tinjauan ulang ini yang diperlukan sebagai pendukung manajemen teknik yang sukses, dan test standard diperlukan juga dibentuk. Tingkatan formalitas dan kompleksitas standard harus konsisten dengan ukuran, kompleksitas, dan resiko usaha pengembangan.

Kemajuan Penilaian
Perencanaan yang baik memudahkan pelaporan dan penilaian kemajuan teknis untuk membantu manager proyek itu di dalam mengalokasikan personil yang memenuhi tugas teknis yang diperlukan. Faktor penting di dalam perencanaan teknis adalah tujuan dari pos pemeriksaan cara mengukurnya terpenuhi, penetapan suatu kemajuan yang mekanisme pelaporannya yang sesuai kepada ukuran proyek, dan penetapan suatu masalah yang dilaporkan dan rencana perkerjaan mengikuti jalannya pola terhadap kebutuhan proyek.
Untuk teknis membuat laporan internal pekerjaan, tanggung jawab dari semua anggota staff di dalam melaporkan kemajuan harus diperkuat dan tergambar dengan jelas. Mata rantai yang lemah di dalam siklus pelaporan proyek adalah seringnya anggota tim mengalami kegagalan atau para supervisor tingkat pertama untuk memahami arti kemajuan sistem pelaporan dan bagaimana digunakan dalam membantu manajer proyek menetapkan prioritas dan mengalokasikan sumber daya proyek. Ini sering mengakibatkan 90% sindrom penyelesaiannya, dengan anggota tim yang melaporkan tugas itu ketika 90% yang diselesaikan setelah berminggu-minggu.

Suatu pendekatan yang lebih baik adalah untuk keperluan yang diperkirakan usaha dan waktu untuk menyelesaikan tugas itu. Sedangkan yang lebih kuantitatif dan terukur, ini disediakan oleh manager proyek dengan informasi yang mana ia dapat lebih teliti dengan cara membaca untuk menentukan skala bahwa untuk menaksir kemampuan dari tiap anggota tim dan yang lebih secara realistis menginterpretasikan arti dari status informasi. Kemudian manager proyek, bekerjasama dengan staff teknis yang sesuai, dapat menentukan tindakan korektif yang sesuai.

Pertemuan-Pertemuan.
Gunanya pertemuan-pertemuan teknis dapat berperan untuk penyelesaian proyek atau memboroskan waktu dari banyak orang-orang kunci dan merintangi aktivitas administratif, seperti halnya kemajuan teknis. Manager proyek harus mengendalikan kecenderungan itu untuk mencoba memenuhi pekerjaan teknis dengan pertemuan-pertemuan. Pertemuan-pertemuan, dengan baik ditangani, dapat dimanfaatkan untuk :

1. mendidik mereka yang harus mengetahui lebih banyak tentang status yang sekarang perancangan unsur piranti lunak dengan produk mana mereka akan menghubungkan,
2. melayani untuk mengkoordinir disain atau keputusan antarmuka (dengan cepat dan mau mendengarkan dibandingkan dengan cara merancang nota),
3. mengumpulkan gagasan yang dengan cepat pada suatu keputusan segera terjadi,
4. menyediakan informasi penting mengenai perubahan,
5. konflik yang tersembunyi mengemuka, dan
6. mendamaikan pandangan yang berlawanan.

Pertemuan kemudian memecahkan isu, mengumpulkan informasi, melaporkan status, atau mendidik staff tentang tugas teknis, tetapi tidak memenuhi pekerjaan teknis yang spesifik diperlukan untuk melengkapi penyelesaian projek itu. Dengan pemikiran ini, sasaran yang harus dijaga hanya untuk pertemuan yang mereka perlukan untuk mengkoordinir aktivitas dan memelihara saluran komunikasi yang diperlukan untuk memenuhi tugas pengembangan itu.
Kapan pertemuan-pertemuan diperlukan untuk mengatur kegiatan teknis itu, adalah penting bahwa manager proyek memerlukan pemanggilan orang dalam pertemuan untuk melakukan hal-hal sebagai berikut:

• jadikanlah pertemuan mempunyai tujuan pasti dan terbatas bahwa peserta memahami tujuan itu.
• jadikanlah peserta mengetahui secara pasti apa yang diharapkan dari mereka.
• jadikanlah dengan pasti bahwa orang-orang yang hadir itu baik untuk memenuhi tujuan yang telah dinyatakan.
• jadikanlah dengan pasti untuk memelihara pertemuan sekecil mungkin untuk menyediakan komunikasi yang lebih efektif. Hanya penyokong, pembuat keputusan, dan dengan tugas menghadirinya itu menyelesaikan keputusan yang diperlukan.
• jadikanlah dengan pasti untuk membatasi pertemuan yang panjang itu. Jika isu masih belum terpecahkan, kemungkinan skeduling suatu kelanjutan pertemuan dengan suatu kelompok yang lebih kecil perlu diselidiki.
• jadikanlah dengan pasti untuk membawa pertemuan itu kepada suatu kesimpulan yang terbatas. Peserta perlu ikut memahami keputusan yang dibuat. Menuju tindakan yang direncanakan, dan siapa yang mempunyai tanggung jawab untuk tindakan yang berikutnya. Karena suatu pertemuan perlu menginformasikan kesimpulan dengan ringkasan titik kunci yang diperkenalkan sepanjang pertemuan.

Pertemuan yang sering dilakukan adalah satu-satunya cara efektif untuk mendapatkan orang kunci untuk memusatkan atas isu yang sangat teknis itu dapat dipecahkan untuk dipelihara dari pada menunda salah satu dari tugas pengembangan. Ini adalah produktif jika pertemuan yang direncanakan dengan baik dan sesuatu yang diijinkan untuk perbedaan ke dalam lain area. Suatu pertemuan adalah produktif tidak jika:

• pertemuan bisnis mungkin secara efisien telah lebih yang ditangani oleh nota percakapan telepon individu, atau lainnya yang lebih sedikit mengkonsumsi waktu yang berarti
  pertemuan menjadi suatu diskusi teknis yang terperinci antara beberapa partisipan.
• orang-orang yang diperlukan untuk memenuhi sasaran pertemuan tidak hadir.
• peserta datang tidak disiapkan.
• biaya pertemuan melebihi nilai keuntungan yang dimiliki mungkin untuk melakukan keputusan dipertemuan itu.

4.4.5 Manajemen Biaya
Manajemen biaya yang benar-benar dimulai dari sepanjang proses estimasi biaya seperti yang diuraikan pada bab 3. estimasi biaya, biaya persiapan proposal, persiapan penawaran akhir, dan negosiasi yang diarahkan; mendahului aktivitas manajemen biaya proyek riil. Penetapan biaya yang realistis dan negosiasi sehingga mendapatkan suatu proyek yang memulai melangkahkan kaki kanan. Bagaimanapun, tanpa melaporkan biaya dan pentingnya biaya pada pihak manager proyek, suatu proyek sukses menjadi kebalikannya dapat menjadi suatu malapetaka untuk perusahaan dan, barangkali, karier manager proyek itu.

Biaya yang paling utama yaitu mengendalikan pertimbangan di dalam menentukan atas proyek adalah untuk menetapkan mengatur pembelanjaan masing-masing tugas teknis atau paket pekerjaan. Dengan keuangan yang telah diberitakan /dikomentari perincian tugas yang sama sebagai manajemen teknik, kemajuan teknis dan laporan keuangan yang dapat siap dihubungkan. Dengan kemampuannya siap dibandingkan yang teknis dan informasi keuangan, status yang benar proyek dapat dengan mudah ditentukan tanpa suatu latihan konversi raksasa (masive).

Laporan Biaya
Laporan keuangan pada umumnya dihasilkan menjadi suatu fungsi akuntansi biaya perusahaan untuk manager proyek itu. Uraian biaya dan tingkatan Pekerjaan Uraian biaya-biaya adalah jalur yang sedikit banyaknya dipertimbangkan manager proyek itu. Pertimbangan yang menjadi penting dan penggunaannya visible. Manager proyek harus memutuskan tidak tentang apa pelaporan biaya tingkatan yang diperlukan untuk menyediakan informasi itu diperlukan untuk mengendalikan proyek itu. Terlalu banyak yang detil pada berbagai hal kacau balau dan dapat menyembunyikan apa yang sesungguhnya terjadi.
Bagaimanapun, data bagi suatu tingkatan yang terperinci diperlukan untuk menentukan di mana jika permasalahan biaya di dalam proyek itu terjadi.

Akuntansi biaya perusahaan akan secara normal menyediakan data anggaran dan pembelanjaan nyata sampai saat ini oleh perancang akuntansi biaya. Manager proyek perlu mempunyai data ini yang direncanakan untuk menyediakan suatu penyajian grafis, yang mana adalah lebih cepat untuk berasimilasi dan menandai adanya kecenderungan lebih siap terpenuhi dibanding meninjau ulang daftar angka-angka yang pada umumnya disajikan oleh sistem akuntansi biaya. Yang secara hati-hati merekam dan perkerjaan mengikuti jalannya biaya-biaya yang dapat juga mendukung nilai data sebagai bagian dari legasi proyek terhadap proposal proyek yang berikutnya. Suatu catatan yang baik dari biaya riil, dengan menggunakan anggaran proposal, itu menyediakan dasar untuk estimasi biaya ditingkatkan.

Alokasi Sumber Daya.
Tujuan nilai proyek sistem informasi yang mana, ketika dibandingkan anggaran, dapat digunakan untuk menentukan jika tindakan manajemen diperlukan. Anggaran menghadirkan suatu alokasi sumber daya yang direncanakan oleh petugas dan dengan periode waktu dalam keseluruhan proyek itu. Suatu masalah biaya di dalam satu area bisa memerlukan realokasi sumber daya dari yang lain atau dari suatu cadangan manajemen.
Area Cadangan Manajemen adalah suatu mekanisme perusahaan yang menggunakan banyak untuk menyediakan manager proyek itu dengan kemampuan untuk bereaksi terhadap biaya yang melebihi dari ketentuan semula, karena apapun juga alasannya, di dalam satu bagian dari proyek itu. Dengan pengaturan yang mengesampingkan pada awal start manager proyek itu mempunyai sumber daya yang tersedia untuk mendukung lingkup permasalahan. Jumlah cadangan manajemen pada umumnya suatu fungsi resiko proyek (resiko lebih tinggi, cadangan lebih besar), jenis kontrak , petunjuk perusahaan, dan, yang adakalanya, petunjuk pelanggan yang dirundingkan.

Pencatatan Komitmen
Terutama sekali untuk proyek lebih kecil, manager proyek dapat mendapatkan suatu kejutan riil ketika bukan biaya tenaga kerja yang akhirnya memasuki sistem akuntansi biaya itu. Suatu proyek yang nampak menjadi benar pada anggaran dapat dengan tiba-tiba berubah menjadi melebihi dari yang ditentukan semula. Jalan yang terbaik untuk menghindari situasi ini adalah untuk menjejaki itu bukan komitmen tenaga kerja sebagaimana adanya yang dibuat dengan suatu Pencatatan Komitmen. Catatan ini perlu mempunyai masukan untuk masing-masing komitmen, seperti perangkat keras atau pembelian peralatan komputer, jasa teknis dari lain organisasi perusahaan, atau biaya perjalanan. Seperti komitmen yang nampak pada laporan akuntansi biaya, mereka ditunda dari Pencatatan Komitmen. Catatan kemudian hanya berisi komitmen itu yang telah tidak tercakup di laporan keuangan dari sistem akuntansi biaya.
Variasi Proyek biaya dapat dengan tepat menyaingi bantuan Pencatatan Komitmen. Sistem Akuntansi biaya melaporkan lebih komitmen yang tidak ditunda di dalam Catatan Komitmen harga yang sama sebenarnya sampai saat ini. Pendekatan ini perlu menghindari kejutan yang berlebihan dalam kaitannya dengan keterlambatan dalam mengusahakan biaya-biaya yang bukan tenaga kerja ke dalam laporan keuangan itu.

4.4.6 Dukungan Pelayanan
Manager proyek mungkin telah mengkhususkan bantuan yang tersedia untuk mendukung proyek itu. Banyak perusahaan memelihara staff spesialis di dalam kontrak, hubungan industri, pemasaran, penetapan harga, merancang perencanaan dan pengendalian, dan konfigurasi manajemen untuk mendukung semua proyek. Manager proyek Piranti lunak perlu mencari-cari sumber pendukung ini dan menggunakannya kepada keuntungan proyek. Banyak perusahaan yang juga menyediakan spesialis penasehat yang sah tentang undang-undang, teknis penerbitan, hak paten, fasilas perencanaan, pembelian, keamanan, dan pengembangan karier. Ketika yang diperlukan oleh proyek, spesialis ini harus terdaftar oleh manager proyek itu. Area lain yang dapat berguna bagi suatu proyek adalah perusahaan riset dan pengembangan mandiri ( IR&D) aktivitas. Manager proyek harus terbiasa dengan IR&D aktivitas yang mungkin telah memproduksi hasil atau peralatan yang berguna bagi proyek. Ia perlu juga siaga ke peluang untuk menyelidiki teknologi atau mengembangkan peralatan yang berguna bagi proyek melalui IR&D membiayai studi atau aktivitas pengembangan.


4.5 LEGASI PROYEK.
Implementasi yang sukses perencanaan dan pendekatan perkiraan biaya diperkenalkan pada bab 3 dan konsep pendekatan manajemen proyek yang dibahas bab ini memerlukan pengembangan dari suatu dasar pengalaman dari proposal diselesaikan dan dirancang. Itu tidaklah wajib bahwa satuan individu yang menyiapkan perkiraan biaya itu dan Rencana Proyek untuk proyek yang sekarang secara pribadi sudah mengalami menyelesaikan proyek. Itu adalah, bagaimanapun, diperlukan personil itu di dalam dokumen proyek yang diselesaikan proyek dari sejumlah perspektif yang berbeda dalam urutan bagi proyek masa depan untuk bermanfaat. Perspektif ini diperlukan yang meliputi suatu evaluasi dari perspektif manager proyek, dari suatu perspektif teknis yang senior atau staf manajemen yang ahli dekat dengan proyek, dan dari suatu perspektif biaya/perencanaan jadual.
Produk dari ini memutar kembali yang memperhatikan masing-masing dan proposal utama proyek yang diperlukan meliputi :

• uraian proyek,
• evaluasi Perencanaan Proyek,
• evaluasi pada proyek karena ia diterapkan, dan
• rekommedasi untuk proyek masa depan.

Suatu garis besar suatu dokumen sejarah proyek yang meliput topik yang utama ini disiapkan dalam bentuk gambar 4.14. untuk kebanyakan perancangan piranti lunak, jadi dokumen ini akan tidak lagi dibandingkan suatu lima sampai enam nota halaman. Bagaimanapun, untuk dokumen tertentu yang lebih besar mungkin adalah yang diperlukan untuk mengevaluasi proyek itu dalam kaitannya dengan berbagai unsur piranti lunak utama, dengan suatu evaluasi capaian dan satu set rekomendasi pada setiap area, seperti halnya deposit merancang rekomendasi evaluasi, haruslah dicatat bahwa topik tertentu tercakup di diskusi ini berlaku bagi proposal utama, seperti halnya pada proyek yang telah diselesaikan. Itu adalah, sesi 1,5 dan 6 garis besar di dalam gambar 4.10 perlu juga diselesaikan untuk semua proposal utama, bahkan usaha yang gagal / kehilangan, untuk membantu meningkatkan mutu tentang usaha proposal masa depan.

Petunjuk untuk masing-masing bagian utama yang teridentifikasi pada gambar 4.10 yang diperkenalkan seperti pada paragrap yang berikut ini yaitu :

Bagian 1 Pengenalan Dan Ikhtisar
Pengenalan Dan Bagian Ikhtisar dokumen sejarah proyek perlu menyediakan pemakai dokumen dengan informasi latar belakang cukup untuk dengan teliti menilai mudah diterapkan dari proyek ini mengalami suatu usaha masa depan yang spesifik. Uraian dan latar belakang Material perlu mengidentifikasi atau sedikitnya menguraikan sebagai berikut:

1. Sebutan/judul Proyek.
2. Periode Capaian.
3. Pelanggan.
4. Usaha awal memasarkan (jika bisa diterapkan).
5. Lingkungan Proposal, jika yang bisa diterapkan (tampak sumber atau penawaran kompetitif).
6. Jenis Kontrak (harga pasti, kelebihan biaya ditetapkan, penghargaan atau pembayaran perangsang, atau lainnya).
7. Struktur Pembayaran Dan Faktor Evaluasi, sebagai kesesuaian.
8. Pendekatan memonitor Pelanggan (tinjauan ulang bulanan, perwakilan ditempat, tinjauan ulang formal, tim pendukung teknis pelanggan kecil atau besar, penggunaan pelanggan konsultan, dll).
9. Topik Negosiasi utama (area spesifik di mana jika perubahan telah dibuat, dasar pemikiran, dan yang berhubungan dengan biaya / dampak jadual).
10. Tindakan khusus mengambil untuk memperoleh kontrak itu dalam kaitannya dengan komitmen proposal awal perusahaan dan dana proposal, personil, sumber daya riset dan pengembangan, pengaturan tim, dan pemilihan subkontraktor.
11. Faktor Evaluasi Proposal spesifik dalam kaitannya dengan kekuatan dan kelemahan, dengan suatu indikasi faktor yang paling berpengaruh di dalam kemenangan atau kerugian kontrak yang diusulkan.

Sebagai tambahan di atas, suatu bagian penting untuk dimasukkan adalah apa yang diidentifikasi sumber dokumen itu. Bagian ini perlu mengidentifikasi personil yang berhubungan dengan proposal dan / atau perancang dari siapa informasi tambahan dapat diperoleh. Personil bagian ini didaftar yang diperlukan antara lain meliputi:

1. Lini manajer yang secara langsung dilibatkan dalam keputusannya untuk menawar atau proses dengan proyek itu.
2. Untuk proposal, manajer proposal dan anggota tim proposal senior yang bertanggung jawab untuk yang berifat teknis dan masukan yang berharga.
3. Lini manajer untuk siapa manager proyek melaporkan.
4. Manager proyek, teknis senior, dan keuangan proyek senior mengorganisir anggota.
5. Jika tim pendukung gugus tugas atau tim tinjauan ulang internal telah digunakan sepanjang proyek, pimpinan . itu seperti tim.

Untuk kelengkapan, jika sepanjang hidup perubahan manajemen proyek telah dibuat, periode perubahan keterlibatan telah dibuat, periode dari tiap keterlibatan dalam kaitannya dengan kalender waktu, tugas teknis, dan tinjauan ulang yang yang terpenuhi harus dimasukkan.

Bagian 2. Evaluasi Rencana Proyek
Bagian dua perlu menyediakan suatu evaluasi tugas yang mula-mula diusulkan, tenaga kerja dan perkiraan pendukung, jadual, dan informasi anggaran dengan membandingkannya dengan proyek yang nyata. Data Proposal harus disesuaikan untuk perubahan apapun harus dirundingkan dan kemudian membandingkan dengan akhir proyek riil. Informasi harga dari proposal dan data yang nyata harus dimasukan format serupa dan kemudian dibandingkan.
Suatu ringkasan seperti pada gambar 4.15 dapat digunakan untuk tujuan ini. Subbagian di dalam evaluasi proyek bagian ini perlu menyediakan informasi yang cukup tentang tugas, jenis permasalahan piranti lunak, atau permasalahan antarmuka yang tidak biasa untuk mengijinkan analisa biaya proposal masa depan untuk menginterpretasikan ringkasan data keuangan. Khususnya, biaya per instruksi informasi harus dievaluasi secara hati-hati, bersama-sama dengan faktor proyek seperti

• waktu riil vs. piranti lunak batch,
• HOL, vs bahasa asembler,
• ilmiah vs manajemen data,
• disain baru vs usaha konversi, atau
• piranti lunak pendukung vs sistem pengembangan yang matang.

Bagian ini harus menyediakan informasi cukup untuk mengijinkan pemakai dari dokumen ini untuk koreksi yang membandingkan perkiraan biaya dan tugas yang nyata untuk proyek ini dengan lain proyek yang diselesaikan dan menggunakan data itu untuk meningkatkan perkiraan proposal.

Bagian 3. Teknik Manajemen
Bagian ini perlu menguraikan teknik manajemen yang digunakan proyek, mengidentifikasi permasalahan yang ditemukan manajemen, menguraikan tindakan korektif mengambil, dan mengidentifikasi teknik yang bisa menjadi keuntungan proyek itu. Penggunaan sejarah untuk proyek sistem informasi masa depan yang potensial dari informasi ini harus dipertimbangkan ketika menyiapkan bagian ini. Manajemen spesifik Personil tidak terpuji atau harus dikritik. Sesungguhnya, nama dari para manajer individu adalah tak perlu. Teknik yang digunakan untuk mengkoordinasikan pelanggan, penjadualan, alokasi sumber daya (personil, perjalanan, perlengkapan, dan dukungan pelayanan). Tugas pengendalian dan kemajuan analisa harus diuraikan dan dievaluasi. Dalam beberapa hal, kepribadian akan masuk untuk merekomendasikan sejumlah atau seseorang dengan kelemahan tertentu untuk peranan tertentu di dalam proyek itu. Informasi jenis ini adalah berharga dan harus dimasukkan, tetapi yang dinyatakan adalah suatu cara yang konsisten dengan tujuan yang sebelumnya dinyatakan dan penggunaannya tentang dokumen ini.

Bagian 4 Teknik Pengembangan
Bagian ini menjadi terus meningkat pada periode yang lebih penting ketika perusahaan yang sedang mengadakan percobaan dengan pendekatan pengembangan baru. Teknik yang digunakan untuk proyek harus diuraikan, capaian mereka dievaluasi, dan membuat rekomendasi. Seperti dengan bagian pada teknik manajemen, penggunaan sejarah utuk masa depan proyek sistem informasi harus dikendalikan tingkatannya dari yang detil hingga lingkupnya.
Ini adalah untuk tidak menjadikan suatu penjualan yang dilemparkan untuk favorit manager proyek teknik pengembangan baru. Suatu usaha yang harus dibuat untuk secara obyektif mengevaluasi teknik yang digunakan proyek itu dan, dimana mungkin, untuk menyarankan teknik yang bisa menjadi lebih efektiv di dalam proyek atau yang tak memuaskan itu dibuktikan. Teknik Pengembangan Evaluasi perlu menunjuk metoda dulu pendekatan tugas teknis yang utama dalam kaitannya dengan personil yang ditugaskan, teknik audit dan tinjauan ulang teknis trainning khusus, dan penggunaan disain dan peralatan pendukung pengembangan.

Bagian 5. Mempelajari
Bagian ini perlu meringkas poin-poin yang penting dari permulaan empat bagian dalam kaitannya dengan pembelajaran. Itu perlu mengidentifikasi teknik atau pendekatan membuktikan yang memuaskan terjadi dan membuktikan menjadi lebih efective. Itu perlu mengidentifikasi permasalahan penaksiran sumber daya yang ditemukan pada proyek itu. Jika ada suatu biaya yang melebihi dari yang ditentukan semula atau biaya di bawah yang telah ditentukan semula, tentang suatu kelebihan jadual, itu perlu mengidentifikasi unsur-unsur yang utama, tugas, atau kebutuhan sumber daya yang salah diperkirakan di mulainya proyek itu. Jika[di sana para subkontraktor, mengevaluasi capaian mereka, teknik manajemen, dan disain teknik perlu juga ditujukan. Bentuk serupa yang digambarkan 4.15 dapat juga digunakan untuk data pemilihan subkontraktor dengan capaian subkontraktor akan juga bermanfaat.

Bagian 6 Rekomendasi
Bagian ini perlu menyediakan rekomendasi spesifik yang akan meningkatkan perkiraan itu untuk dan capaian pada proyek masa depan yang serupa. Bagian ini dan yang sebelumnya adalah dua bagian yang paling utama dokumen sejarah proyek. Sisa dari bagian yang menyediakan dukungan detil diperlukan untuk memahami dan menerapkan pelajaran itu yang mempelajari dan merekomendasi kan untuk proyek masa depan.



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.