Klasik Kegiatan Manajemen Proyek

Perakitan tim

Langkah berikutnya dalam tahap organisasi proyek adalah untuk merakit tim yang akan menghasilkan kiriman.
Manajer proyek memilih pemimpin tim sebelum tim terbentuk. Selain menjadi mampu memahami status tim,
pemimpin tim harus mampu berkomunikasi secara efektif, mengenali tertunda krisis (teknis atau sosial), dan make
trade-off mempertimbangkan kekhawatiran tingkat proyek akun.

Fase proyek awal adalah waktu yang ideal untuk melatih para pemimpin tim dan mengakrabkan mereka dengan
prosedur proyek dan aturan-aturan dasar. Peran pemimpin tim berbeda dari peran pemimpin teknis. Pemimpin teknis,
biasanya penghubung ke tim arsitektur, berinteraksi dengan kepala arsitek dan penghubung arsitektur dari tim lain dan
memiliki kata akhir pada keputusan teknis dalam tim. Peran arsitektur penghubung membutuhkan keterampilan dan
pengembangan teknis pengalaman yang sangat baik.

Dalam konteks pelatihan, seperti kursus proyek universitas atau proyek percontohan industri menjelajahi metode software
baru, pemimpin tim dapat dibagi menjadi dua peran. Sebuah kereta api pelatih, menjelaskan, menyarankan tim dan bertindak
sebagai penghubung kepada manajer proyek. Seorang trainee pemimpin tim mengisi semua tanggung jawab lain dari pemimpin tim,
termasuk memfasilitasi pertemuan status dan menetapkan tugas. Dalam kursus proyek universitas, peran ini dapat diisi oleh
instruktur atau asisten dosen berpengalaman, sedangkan penghubung arsitektur dapat diisi oleh siswa. Dalam proyek pembangunan
di sebuah perusahaan, pemimpin tim diisi oleh pengembang yang memiliki pengalaman dan pengetahuan dengan prosedur
manajemen organisasi, sedangkan penghubung arsitektur diisi oleh pengembang yang memiliki keterampilan teknis yang kuat.

Pengembang yang akan bekerja untuk proyek tersebut dapat ditugaskan untuk proyek sekaligus (
kepegawaian datar), atau proyek dapat secara bertahap menggenjot produksinya dengan mempekerjakan orang
yang diperlukan ( staf bertahap). Di satu sisi, staf bertahap dimotivasi oleh menghemat sumber daya di bagian awal
dari proyek. Persyaratan elisitasi dan analisis tidak memerlukan orang sebanyak coding dan pengujian. Selain itu,
analis dan implementor adalah peran yang membutuhkan keterampilan yang berbeda dan dengan demikian harus
diserahkan kepada orang yang berbeda. Di sisi lain, staf datar memiliki keuntungan dari membangun tim awal dan
lingkungan sosial yang diperlukan untuk komunikasi spontan. Beberapa pengembang dapat ditugaskan untuk kegiatan
analisis dengan analis, dan lain-lain mungkin sudah memulai kegiatan lainnya seperti menyiapkan lingkungan
manajemen konfigurasi, survei teknologi dan evaluasi, dan pelatihan. Dengan proyek-proyek yang lebih pendek dan
tenggat waktu pasar, staf datar menjadi skema kepegawaian yang lebih disukai.

Kick-off meeting

Manajer proyek, pemimpin tim, dan klien secara resmi memulai proyek dalam pertemuan kickoff dengan
semua pengembang hadir. Tujuan dari pertemuan kick-off adalah untuk berbagi informasi dengan semua peserta
proyek tentang ruang lingkup proyek, infrastruktur komunikasi, dan tanggung jawab masing-masing tim. Presentasi
harus dibagi antara klien dan proyek
Pengelola. Klien menyajikan persyaratan dan ruang lingkup proyek. Manajer proyek hadiah infrastruktur proyek,
desain top-level dan tim tanggung jawab.

Menyetujui lingkup proyek

Dokumen ini secara resmi mendefinisikan ruang lingkup, durasi, biaya, dan Penyerahan untuk proyek
tersebut. Itu Perjanjian proyek bisa dalam bentuk kontrak, pernyataan kerja, rencana bisnis, atau project charter.
Itu Perjanjian proyek biasanya diselesaikan setelah model analisis stabil dan perencanaan sisa proyek ini
berlangsung.

SEBUAH Perjanjian proyek harus mengandung setidaknya berikut:

• daftar dokumen penyampaian

• kriteria untuk demonstrasi kebutuhan fungsional
• kriteria untuk demonstrasi persyaratan nonfungsional, termasuk akurasi, kehandalan, waktu respon,
dan keamanan
• kriteria penerimaan.

Itu Perjanjian proyek merupakan dasar dari tes penerimaan klien. Setiap perubahan dalam fungsi yang akan
disampaikan, persyaratan nonfungsional, tenggat waktu, atau anggaran proyek memerlukan negosiasi ulang Perjanjian
proyek.
Setelah selesainya proyek kick-off dan kesepakatan dalam lingkup proyek, proyek memasuki steady state.

14.4.3 Pengendalian Proyek

Untuk membuat keputusan yang efektif dalam fase steady state proyek, manajer proyek perlu informasi status akurat. Sayangnya,
mengumpulkan informasi status yang akurat sulit. Sementara sistem yang kompleks sulit dimengerti dalam dirinya sendiri, status
komponen dan dampaknya terhadap pengiriman masa depan bahkan lebih sulit untuk memahami. Pengembang tidak akan
melaporkan kepada pemimpin tim mereka masalah yang mereka percaya bahwa mereka dapat mengatasi dalam waktu. Namun,
keberangkatan kecil dari jadwal, tidak layak pelaporan secara independen, agregat dan merosot ke keberangkatan besar jauh
kemudian dalam jadwal. Pada saat pemimpin tim menemukan dan melaporkan masalah besar untuk manajer proyek, itu telah
menyebabkan penundaan substansial dalam proyek tersebut.

Beberapa alat yang tersedia untuk informasi status mengumpulkan. Karena tidak satupun dari mereka yang akurat atau dapat

diandalkan saja, pemimpin tim dan manajer proyek perlu menggunakan kombinasi ini. Di bawah ini kami meninjau kelebihan dan

kekurangan.

rapat

• status pertemuan periodik. pertemuan Status dilakukan di tingkat tim memiliki potensi terbaik untuk melaporkan status dan
informasi yang diperlukan untuk keputusan korektif. pertemuan status, bagaimanapun, juga dapat memberikan informasi
status yang tidak akurat jika anggota tim tidak bekerja sama. Peserta secara alami enggan untuk melaporkan masalah
atau kesalahan. Mereka
 bekerja sama hanya jika mereka dapat mempercayai seorang manajer untuk tidak langkah ke masalah yang mereka dapat

menyelesaikan sendiri. Manajer perlu membuat pelaporan masalah bermanfaat untuk pengembang dengan intervensi hanya bila

diperlukan.

• tonggak tajam. Kemajuan dapat diukur dengan menentukan jika pengembang memberikan produk
pekerjaan tepat waktu. Manajer dapat meningkatkan akurasi metode ini dengan mendefinisikan tonggak
tajam sehingga mereka dapat secara akurat dipantau. Misalnya, “coding selesai” tonggak bukanlah
tonggak tajam, karena tidak memperhitungkan kualitas kode disampaikan. kode bisa mengandung sedikit
atau banyak cacat dan tonggak akan dianggap selesai dalam kedua kasus. Sebaliknya, mendefinisikan
tonggak sejarah sebagai penyelesaian tes, demonstrasi, dokumentasi, dan integrasi fitur tertentu
menghasilkan informasi status yang lebih baik. Ketika mendefinisikan dan pemantauan tonggak tajam,
manajer tidak perlu kerjasama dari pengembang.

• ulasan proyek. Sebuah tinjauan proyek merupakan sarana bagi semua peserta dengan status pertukaran dan
informasi rencana tentang semua tim dengan presentasi resmi. ulasan proyek menderita masalah yang sama
seperti pertemuan status. Jika peserta sudah enggan mengakui masalah di depan pemimpin tim mereka, mereka
pasti tidak akan mengakui masalah dalam forum publik.

• inspeksi kode. peer review formal kode merupakan metode yang efektif untuk menemukan cacat awal.
Ketika dilakukan sering, hasil juga dapat digunakan sebagai indikasi kemajuan.

• demonstrasi prototipe. demonstrasi prototipe implementasi parsial dari sistem untuk mengevaluasi teknologi
atau fungsi. Mereka biasanya tidak menggambarkan bagaimana kasus perbatasan ditangani dengan atau
bagaimana kuat pelaksanaannya. Mereka adalah baik untuk mengukur kemajuan awal, tetapi tidak langkah-
langkah tajam penyelesaian.

metrik

Sulit untuk mengelola evolusi produk tanpa ukuran objektif. Meskipun pertemuan dan inspeksi membantu
menilai status proyek, mereka bergantung pada persepsi peserta dipilih dan kesediaan mereka untuk berkomunikasi
apa yang mereka ketahui. Optimisme peserta tunggal dapat menyebabkan keyakinan bahwa proyek telah
berkembang lebih jauh daripada itu. metrik perangkat lunak adalah ukuran kuantitatif dari aspek-aspek tertentu dari
proses atau sistem.
Instrumenting proses dan sistem yang berkembang dengan metrik otomatis upaya untuk menyediakan alat untuk
mengukur kemajuan obyektif.

Banyak metrik perangkat lunak telah diusulkan, seperti jumlah baris kode sumber, jumlah percabangan poin
[McCabe, 1976], jumlah variabel dan operator [Halstead, 1977], dan jumlah kebutuhan fungsional [Albrecht & Gaffney
1983]. Menggunakan metrik perangkat lunak sebagai alat manajemen telah sulit, karena banyak produk kerja yang
tidak item perangkat lunak, dan nilai-nilai dan kecenderungan yang diamati memerlukan banyak interpretasi dari
manajer.
Banyak proyek atau produk parameter memiliki dampak potensial pada metrik makhluk
diukur. Sebagai contoh, jika ukuran subsistem di baris meningkat kode sumber dengan cepat, mungkin para pengembang

ditugaskan untuk subsistem yang produktif, atau mereka mungkin sedang duplikasi kode. Dengan berulang dan pendekatan

arsitektur-sentris, bagaimanapun, komponen perangkat lunak untuk menguji dan mengukur menjadi tersedia jauh lebih awal.

Selain itu, metrik juga dapat mengukur atribut dari proses, seperti penyimpangan dengan jadwal, sumber daya dikeluarkan,

dan jumlah peserta meninggalkan prematur.

• Mengukur status keuangan. Membandingkan biaya yang direncanakan terhadap biaya yang sebenarnya dalam konteks

kemajuan yang sebenarnya memungkinkan seorang manajer untuk menilai kesehatan keuangan proyek. proyek

pengembangan perangkat lunak yang padat karya; akibatnya, sebagian besar biaya yang terkait dengan proyek ini

adalah staf. profil kepegawaian yang direncanakan proyek dari waktu ke waktu memberikan dasar biaya terhadap yang

untuk membandingkan biaya yang sebenarnya. Selain itu, model tugas dan jadwal memberikan kita dengan estimasi

usaha dan batas waktu untuk setiap tugas. Penilaian nilai yang diterima memungkinkan kita untuk menilai baik biaya dan

jadwal situasi proyek menggunakan salah satu grafik. Sebagai contoh, pada Gambar 14-13, garis tipis menggambarkan

biaya yang direncanakan dari proyek dari waktu ke waktu. Sebuah proyek yang ada di anggaran dan jadwal akan

mengikuti garis yang sama sangat erat. Garis tebal merupakan biaya yang sebenarnya proyek dari waktu ke waktu. Pada

contoh Gambar 14-13, kita benar-benar menghabiskan kurang dari yang direncanakan. Namun, jika kita hanya melihat

dua kurva ini, kita tidak akan dapat menilai apakah atau tidak proyek ini adalah dalam keadaan keuangan yang baik.

Proyek ini bisa berada di bawah biaya karena kami capai pekerjaan yang direncanakan untuk uang kurang, atau karena

kita tidak mencapai sebanyak seperti yang direncanakan. Akibatnya, kita plot kurva ketiga, nilai yang diperoleh, yang

merupakan nilai dari pekerjaan yang kita selesai sejauh ini. nilai yang diperoleh diukur dengan menambahkan biaya yang

direncanakan dari tugas-tugas yang telah selesai. Dalam contoh ini, nilai yang diperoleh adalah antara biaya aktual dan

biaya yang direncanakan, menunjukkan bahwa proyek ini di bawah anggaran dan akhir. Jika nilai yang diperoleh telah di

atas biaya yang direncanakan,

• Mengukur kemajuan teknis. Sementara mengukur status keuangan baik dipahami dalam rekayasa
perangkat lunak dan manajemen proyek pada umumnya, proyek pengembangan perangkat lunak
memperkenalkan tantangan khusus ketika menentukan apa tugas benar-benar telah dicapai. Mengukur
kemajuan teknis membutuhkan metrik ukuran untuk masing-masing tim. Untuk tim pengembangan, ini
dapat mencakup jumlah baris kode sumber di bawah dasar atau jumlah permintaan perubahan tertutup.
Untuk tim pengujian, ini dapat mencakup jumlah cacat yang ditemukan atau jumlah permintaan perubahan
terbuka. Untuk tim arsitektur, mungkin jumlah kasus penggunaan kritis yang telah ditunjukkan. Ukuran
metrik, bagaimanapun, harus dilihat dalam kombinasi dengan metrik kualitas untuk memastikan bahwa
peserta tidak secara lokal mengoptimalkan jumlah mereka. Sebagai contoh,
 Earned biaya Planned

sebenarnya nilai

biaya yang

Waktu
Arus

waktu

Gambar 14-13 Menilai status keuangan proyek menggunakan nilai yang diperoleh. Sebuah nilai yang diterima atas biaya aktual menunjukkan bahwa lebih
banyak pekerjaan yang dilakukan untuk suatu yang sama me-mount uang (yaitu, proyek ini di bawah anggaran). Sebuah nilai yang diterima di bawah biaya

yang direncanakan menunjukkan bahwa tidak banyak pekerjaan selesai seperti yang direncanakan (yaitu, proyek terlambat).

• Mengukur stabilitas. Setelah versi awal dari sistem ini baselined, permintaan perubahan dikeluarkan untuk
kontrol dan melacak perubahan baseline. Mengukur tingkat permintaan perubahan baru yang sesuai dengan
cacat pada sistem menunjukkan seberapa stabil sistem menjadi dari waktu ke waktu. Mengukur tingkat
permintaan perubahan persyaratan sama menunjukkan seberapa stabil persyaratan telah menjadi dalam
pandangan klien. Jika penyelesaian pekerjaan menunjukkan bahwa proyek tersebut hampir selesai namun tingkat
permintaan perubahan masih tinggi, proyek mungkin tidak mencapai tujuan kualitas target.

• Mengukur modularitas. Kerusakan adalah ukuran dari dampak perubahan pada baseline (yang dapat diukur
dalam hal baris kode, jumlah file, fungsi poin, atau ukuran metrik yang sesuai dalam konteks proyek).
Diharapkan perubahan awal mempengaruhi lebih kode sumber dari yang kemudian, seperti arsitektur harus
menjadi lebih modular selama waktu proyek. Mengukur kerusakan dapat mendorong tren ini dan membuat
terlihat awal masalah arsitektur (misalnya, mengidentifikasi tipe tertentu dari perubahan yang menghasilkan
kerusakan yang tinggi). Meningkatkan kerusakan menunjukkan modularitas merendahkan selama masa
proyek, mungkin dihasilkan dari arsitektur yang tidak memadai atau persyaratan nonfungsional tertentu yang
sulit untuk bertemu.

• Mengukur jatuh tempo. waktu rata-rata antara kegagalan mengukur waktu antara cacat ditemukan selama pengujian.
Sebagai proyek mendekati pengiriman, jumlah cacat yang ditemukan harus menurun, menunjukkan jatuh tempo
peningkatan produk. Sebuah jatuh tempo menurun dapat menunjukkan bahwa pengembang berada di bawah tekanan
untuk perubahan permintaan terbuka alamat dan tidak membayar perhatian yang cukup kepada kualitas. Penurunan
jatuh tempo juga dapat hasil dari kurangnya stabilitas (lihat mengukur stabilitas, atas).
 Akhirnya, secara independen dari metode yang digunakan untuk menentukan status, manajer proyek, pemimpin tim, dan
para pengembang perlu berkomunikasi informasi status dalam hal dimengerti. Berikutnya, kami menjelaskan manajemen risiko
sebagai metode untuk mengendalikan proyek, berkomunikasi potensi masalah, dan perencanaan kontinjensi.

mengelola risiko

Fokus manajemen risiko adalah untuk mengidentifikasi masalah mungkin dalam proyek dan menangani mereka sebelum
mereka secara signifikan dapat mempengaruhi tanggal pengiriman atau anggaran. Elemen kunci dari manajemen risiko adalah untuk
mengatur informasi yang sesuai mengalir sehingga risiko dan masalah secara akurat dilaporkan secara tepat waktu. Banyak proyek
gagal entah karena masalah sederhana dilaporkan terlambat atau karena masalah yang salah itu ditujukan. Pada bagian ini, kita fokus
pada kegiatan manajemen risiko untuk mengidentifikasi, menganalisis, dan menangani risiko. Untuk rincian lebih lanjut tentang
manajemen risiko dalam rekayasa perangkat lunak, kita merujuk pembaca untuk literatur khusus (misalnya, [Boehm, 1991] dan
[Charette, 1989]).

Langkah pertama dari manajemen risiko adalah untuk mengidentifikasi risiko. Risiko masalah potensial yang
dihasilkan dari daerah ketidakpastian. Risiko dapat manajerial atau teknis. risiko manajerial termasuk ketidakpastian
yang berkaitan dengan organisasi, produk kerja, peran, atau rencana tugas. risiko teknis meliputi ketidakpastian yang
berkaitan dengan model sistem, termasuk perubahan dari fungsi sistem, persyaratan nonfungsional, arsitektur, atau
pelaksanaan sistem. Secara khusus, risiko teknis termasuk cacat ditemukan akhir dalam pengembangan. Tabel 14-5
menggambarkan contoh risiko dalam proyek perangkat lunak.

tabel 14-5 Contoh risiko yang teridentifikasi di BURUNG HANTU proyek.

Risiko jenis risiko

Perilaku dari off-the-rak komersial (COTS) komponen tidak sesuai dengan standar yang diterbitkan. Teknis

COTS tanggal komponen pengiriman kemudian dari yang direncanakan. manajerial

Pengguna tidak bersedia untuk menggunakan antarmuka pengguna memilih untuk berinteraksi dengan sistem. Teknis

middleware dipilih terlalu lambat untuk kebutuhan kinerja bertemu untuk data logging. Teknis

Pengembangan subsistem membutuhkan waktu lebih dari yang dijadwalkan. manajerial

Pengembang sering sadar akan risiko yang berlaku untuk tugas-tugas mereka. Tantangannya adalah untuk mendorong
pengembang untuk melaporkan risiko sehingga mereka dapat dikelola. Ini memerlukan menguntungkan pengembang untuk
melaporkan risiko dan masalah dan membuat kegiatan manajemen risiko secara langsung bermanfaat bagi pengembang. Spontan
pelaporan risiko biasanya tidak cukup. peserta proyek, termasuk klien, pengembang, dan manajer, biasanya enggan untuk
berkomunikasi potensial
kegagalan atau kekurangan dan terlalu optimis tentang hasil mereka. Pendekatan yang lebih sistematis untuk identifikasi risiko
adalah untuk mewawancarai para peserta proyek menggunakan kuesioner terstruktur. Peserta diminta dalam sesi kelompok untuk
daftar risiko mereka mengantisipasi sehubungan dengan tugas-tugas tertentu. Gambar 14-14 menggambarkan contoh pertanyaan
dari proses Identifikasi Risiko Taksonomi Berbasis [Carr et al., 1993]. Dalam contoh ini, upaya pewawancara untuk menentukan
apakah ada risiko yang berkaitan dengan kebutuhan nonfungsional. Tergantung pada jawaban pertanyaan pertama, pewawancara
dapat mengajukan pertanyaan tindak lanjut untuk membuat risiko terkait memastikan tidak ada lainnya yang hadir. Alasan di balik
kuesioner ini adalah untuk mencakup semua bidang pembangunan di mana risiko biasanya ditemukan.

1. Persyaratan
. ..
d. prestasi
...
[23] Telah analisis kinerja telah dilakukan?
(Ya) (23.a) Apa tingkat kepercayaan dalam analisis kinerja? (Ya) (23.b) Apakah Anda memiliki model untuk
melacak kinerja melalui desain dan implementasi?

Gambar 14-14 Pertanyaan untuk memunculkan risiko kinerja dalam proses Identifikasi Risiko Taksonomi-Based. Jika pertanyaan
pertanyaan 23 adalah positif, pertanyaan 23.a dan 23.b diminta dari pengembang [Carr et al., 1993].

identifikasi risiko sistematis menghasilkan sejumlah besar risiko manajerial dan teknis, beberapa dari mereka kritis, orang lain

tidak penting. Memprioritaskan risiko memungkinkan manajer untuk fokus pada risiko kritis. Risiko yang ditandai dengan kemungkinan

mereka bisa menjadi masalah dan dengan dampak potensial mereka untuk proyek ketika mereka menjadi masalah. Dengan

menggunakan dua atribut tersebut, risiko dapat ditugaskan untuk salah satu dari empat kategori:

• Kemungkinan besar, potensi dampak tinggi

• tidak mungkin, dampak potensi tinggi

• Kemungkinan besar, potensi dampak rendah

• tidak mungkin, rendah dampak potensial.

Manajer harus khawatir tentang risiko dari kategori pertama: kemungkinan, dampak potensial tinggi. Untuk risiko ini,
pengembang dan manajer harus menarik rencana darurat dan memantau risiko dengan hati-hati. Jika kemungkinan risiko
meningkat, manajer dapat mengaktifkan rencana kontinjensi dan mengatasi masalah dalam waktu. Selain itu, manajer harus
memantau risiko kategori kedua: tidak mungkin, dampak potensial tinggi. rencana kontingensi tidak perlu ditarik untuk
mereka kecuali kemungkinan mereka meningkat. Akhirnya, risiko dalam kategori ketiga dan keempat dapat diabaikan kecuali
sumber daya yang cukup tersedia untuk memantau mereka. Tabel 14-6 perintah risiko disajikan pada Tabel 14-5.
tabel 14-6 risiko diprioritaskan untuk proyek.

Risiko Kemungkinan Dampak potensial

Perilaku komponen COTS tidak sesuai

tidak mungkin Tinggi
dengan standar yang diterbitkan.

COTS baru tanggal pengiriman komponen kemudian dari

Mungkin Tinggi
yang direncanakan.

Pengguna tidak bersedia untuk menggunakan antarmuka pengguna. Mungkin bagi pengguna menghabiskan Tinggi
kurang dari 2 jam per hari di depan komputer

middleware dipilih terlalu lambat untuk kebutuhan Tidak mungkin, rendah frekuensi Tinggi
kinerja bertemu untuk data logging. sampling

Pengembangan komponen membutuhkan waktu lebih dari Kemungkinan besar, kejadian pertama Tinggi
yang dijadwalkan.

Setelah risiko telah diidentifikasi dan diprioritaskan, strategi mitigasi harus dirancang untuk risiko kritis. Mitigasi strategi

dapat mencakup menurunkan kemungkinan risiko atau menurunkan dampak potensial. Risiko biasanya disebabkan oleh area

ketidakpastian, seperti informasi yang hilang atau kurang percaya diri dalam beberapa informasi. Pengembang mengurangi

kemungkinan risiko dengan menyelidiki lebih lanjut penyebab risiko, dengan mengubah pemasok atau komponen, atau dengan

memilih pemasok berlebihan atau komponen. Demikian pula, pengembang mengurangi dampak risiko pada proyek dengan

mengembangkan solusi alternatif atau berlebihan. Dalam kebanyakan kasus, bagaimanapun, mengurangi risiko menimbulkan

sumber daya tambahan dan biaya. Tabel 14-7 menggambarkan mitigasi strategi untuk risiko disajikan pada Tabel 14-5.

Setelah risiko diidentifikasi, diprioritaskan, dan dikurangi, rencana manajemen risiko harus dikomunikasikan kepada
semua yang bersangkutan. Manajemen risiko bergantung pada komunikasi yang tepat waktu. pelaporan spontan dan tepat
waktu potensi masalah harus didorong. rencana manajemen risiko dan dokumen teknis dikomunikasikan menggunakan
saluran yang sama. Pengembang dan peserta proyek lainnya tinjauan risiko pada saat yang sama mereka meninjau isi
teknis proyek. Seperti disebutkan sebelumnya, komunikasi adalah hambatan paling signifikan ketika berhadapan dengan
ketidakpastian.

14.4.4 Pengakhiran Proyek

Pada tahap penghentian proyek manajer proyek mempersiapkan untuk tes penerimaan klien, mengelola integrasi
sistem, pengujian, dan instalasi di situs klien. Akhirnya manajer proyek mengawasi postmortem proyek.
tabel 14-7 Mitigasi strategi untuk sebuah proyek.

Risiko strategi mitigasi

Perilaku komponen COTS tidak sesuai dengan standar

• benchmark dijalankan untuk mengidentifikasi ketidaksesuaian.
yang diterbitkan.
• Menyelidiki apakah fungsi tidak sesuai dapat dihindari.

Dipan tanggal pengiriman komponen kemudian dari • Memonitor risiko dengan meminta produsen untuk

yang direncanakan. laporan status menengah.

Pengguna tidak bersedia untuk menggunakan antarmuka pengguna. • Lakukan kegunaan studi menggunakan mock-up.
• Mengembangkan antarmuka alternatif.

middleware dipilih terlalu lambat untuk kebutuhan

• memonitor risiko. Rencana prototipe
kinerja bertemu untuk data logging.
evaluasi kinerja.

Pengembangan komponen membutuhkan waktu lebih dari • Meningkatkan prioritas dari tugas ini sehubungan dengan

yang dijadwalkan. pelaksanaan tugas-tugas lainnya.

• Menetapkan pengembang kunci untuk tugas ini.

Menerima sistem

Tujuan dari tes penerimaan klien adalah presentasi dari sistem dan persetujuan dari klien sesuai dengan
kriteria penerimaan yang ditetapkan dalam Perjanjian proyek. Hasilnya adalah penerimaan formal (atau penolakan)
dari sistem oleh klien. Instalasi sistem dan lapangan tes oleh klien mungkin sudah terjadi. Tes penerimaan klien
merupakan akhir yang terlihat dari proyek.

Tes penerimaan klien dilakukan sebagai serangkaian presentasi dari fungsi dan fitur baru dari sistem. skenario
penting dari Pernyataan masalah itu dilakukan dan ditunjukkan oleh pengembang atau oleh pengguna di masa
depan. demonstrasi tambahan fokus pada persyaratan nonfungsional dari sistem seperti akurasi, kehandalan, waktu
respon, atau keamanan. Jika instalasi dan pengguna evaluasi terjadi sebelum tes penerimaan klien, hasil mereka
disajikan dan dirangkum. Akhirnya, tes penerimaan klien juga berfungsi sebagai forum diskusi untuk kegiatan
selanjutnya seperti pemeliharaan, transfer pengetahuan, atau perangkat tambahan sistem.

Instalasi

Tahap instalasi proyek meliputi tes bidang sistem, perbandingan hasil sistem dengan sistem warisan,
peluncuran sistem warisan, dan pelatihan pengguna. Instalasi dapat dilakukan oleh pemasok, kontraktor, atau oleh
klien, tergantung pada Perjanjian proyek.
Agile Kegiatan Proyek Manajemen
6

Untuk meminimalkan risiko, instalasi dan pengujian lapangan biasanya dilakukan secara bertahap, dengan situs
noncritical digunakan sebagai lingkungan pengujian lapangan. Ketika klien yakin bahwa gangguan bisnisnya akan minimal,
sistem disampaikan memasuki skala penuh operasi. sistem penggantian dan upgrade jarang diperkenalkan dalam “big-bang”
mode karena jumlah terbesar dari masalah-masalah yang ditemukan selama beberapa hari pertama operasi.

postmortem

Setiap proyek mengungkap masalah baru, kejadian tak terduga, dan kegagalan tak terduga. Setiap proyek, oleh
karena itu, merupakan kesempatan untuk belajar dan mengantisipasi risiko baru. Banyak perusahaan perangkat lunak
melakukan studi postmortem dari setiap proyek setelah selesai. postmortem meliputi pengumpulan data tentang
direncanakan vs tanggal pengiriman aktual dan jumlah cacat yang ditemukan, informasi kualitatif tentang
teknis dan masalah manajerial
dihadapi, dan saran untuk proyek-proyek masa depan. Meskipun fase ini adalah yang paling terlihat dalam siklus hidup, perusahaan

tergantung pada hal itu untuk belajar dan meningkatkan efisiensi.

14,5 Agile Kegiatan Proyek Manajemen

Metode manajemen proyek yang dijelaskan di bagian sebelumnya berevolusi dari pengelolaan proyek yang kompleks besar,
di mana tujuan dari manajemen proyek adalah untuk mengembangkan proses berulang dan dapat diprediksi sebagai dasar
perencanaan dan pengambilan keputusan. Sementara metode tersebut sesuai untuk kebutuhan yang jelas dan matang
teknologi, mereka menyebabkan organisasi yang kaku dan lambat untuk merespon kejadian tak terduga atau persyaratan
tidak jelas khas pengembangan produk baru.

metode Agile menangani lebih baik dengan persyaratan tidak jelas dan muncul teknologi solusi, yang ditandai
dengan perubahan sering. Persyaratan berubah sebagai wawasan baru diperoleh dengan klien dan pengguna, perubahan
arsitektur perangkat lunak seperti teknologi baru yang diadopsi atau dibuang, sehingga tegang pendekatan klasik di mana
perubahan dikendalikan atau bahkan putus asa. metode Agile mencoba untuk menghadapi tantangan ini dengan berfokus
pada peningkatan produk kecil yang dikembangkan dalam semburan waktu singkat. Setelah setiap kenaikan produk,
kemajuan ditinjau, pelajaran yang dipelajari, organisasi proyek atau tujuan yang disesuaikan.

Pada bagian ini, kami menjelaskan Scrum [Schwaber & Beedle 2002], contoh dari metode manajemen proyek
tangkas, dan kontras dengan bagian sebelumnya. Perhatikan bahwa banyak kegiatan yang dijelaskan di bagian
sebelumnya, seperti manajemen skill, manajemen risiko, sistem instalasi, relevan di kedua pendekatan.

14.5.1 Perencanaan Proyek: Membuat Produk dan Sprint backlog

The Scrum Pendekatan ini ditandai dengan iterasi pendek, disebut sprint, di mana kandidat rilis dikembangkan.
Dalam Scrum, ini disebut Peningkatan produk berpotensi penyampaian.
Akibatnya, Scrum adalah contoh dari integrasi vertikal (lihat Bagian 11.4.4).
 Proyek ini dimulai dengan proyek kick off meeting, di mana pemilik produk dan master Scrum brainstorming
versi pertama dari persyaratan. Pada akhir kick off, persyaratan diprioritaskan ke dalam daftar yang disebut produk
backlog. Backlog proyek dimulai sebagai visi dirumuskan dalam hal kebutuhan bisnis, dan diperbarui dan
disempurnakan dalam hal persyaratan sistem sebagai tim membuat kemajuan dalam mewujudkan produk. Backlog
proyek mencerminkan pemahaman saat produk antara klien dan proyek, daripada kontrak tetap menentukan produk
akhir.

Sebuah lari dimulai dengan perencanaan pertemuan berlari, selama stakeholder (klien, manajemen, dan
tim) memilih item dari backlog produk harus dipertimbangkan untuk kenaikan produk berikutnya. Tim kemudian
menentukan satu set tugas, bersama-sama dengan perkiraan usaha, untuk mewujudkan persyaratan yang dipilih.
Daftar tugas dan estimasi usaha mereka merupakan sprint backlog. Pada akhir rapat perencanaan sprint, tim
bertanggung jawab untuk sprint backlog dan berkomitmen untuk memberikan kenaikan produk pada akhir sprint.
Sebuah sprint timeboxed untuk biasanya 30 hari. Pada akhir sprint, kenaikan produk ditinjau dan ruang lingkup sprint
berikutnya didefinisikan. Setiap pekerjaan yang belum selesai dikembalikan ke backlog produk.

Item dalam backlog produk dikelompokkan ke dalam rilis dengan tanggal rilis yang direncanakan. Sebagai sprint hasil
ke bertahap selesai, pemilik produk memiliki tiga pilihan:

1. memutuskan apakah akan mengubah hasil lari ke dalam pertambahan produk

2. menyatakan proyek selesai dan memberikan produk akhir

3. menyesuaikan perencanaan rilis dengan menggeser item antara rilis atau menyesuaikan tanggal rilis,
berdasarkan kemajuan tim

14.5.2 Pengorganisasian Proyek

Scrum mendefinisikan tiga peran:

• Itu pemilik produk bertanggung jawab untuk persyaratan. Pemilik produk berpartisipasi dalam
penciptaan backlog produk, dan mengutamakan backlog produk sebelum setiap berlari. Pemilik produk
mewakili klien dan pengguna dengan satu suara. Perubahan pemilik produk dan re-memprioritaskan
backlog produk sebelum setiap lari untuk mencerminkan pelajaran. Pemilik produk bertanggung jawab
untuk backlog produk dan tidak memiliki pengaruh pada tim selama sprint.

• Itu scrum Master adalah peran manajemen yang bertanggung jawab untuk proses tersebut. The Scrum
Master set up dan memberlakukan peraturan dan praktik proyek. The Scrum Master memfasilitasi rapat
harian Scrum, kemajuan monitor, dan menghilangkan hambatan mencegah tim untuk melakukan
tugasnya. The Scrum master antarmuka antara tim Scrum dan pemilik produk, memastikan produktivitas
tim, dan melindungi tim dari gangguan.
 • Itu tim scrum bertanggung jawab untuk mengembangkan kenaikan produk. Tim ini lintas fungsional termasuk semua

keterampilan yang dibutuhkan untuk membangun peningkatan produk. Tim ini mengorganisir diri di setiap berkomitmen

anggota bekerja berdasarkan keahlian dan ketersediaan mereka sendiri. Tidak ada peran atau deskripsi pekerjaan yang

ditugaskan kepada anggota tertentu, seperti analis, programmer, atau penguji. Anggota belajar dan beradaptasi

keterampilan mereka didasarkan pada pekerjaan yang harus dilakukan. The berpartisipasi tim dalam rapat perencanaan

sprint dan komit untuk daftar tugas yang didefinisikan dalam sprint backlog.

14.5.3 Pengendalian Proyek: Harian Scrums dan Burn Bawah Charts

The Scrum Master monitor kemajuan proyek dengan pertemuan Scrum harian dan membakar grafik.

Itu Pertemuan harian Scrum berlangsung pada awal hari kerja, dan berlangsung paling 15 menit. Selama
pertemuan Scrum harian, setiap anggota tim melaporkan secara individu:

• Status: pekerjaan yang dilakukan sejak pertemuan Scrum terakhir harian

• isu-isu baru: hambatan yang mencegah mereka untuk menyelesaikan pekerjaan mereka

• item tindakan baru: pekerjaan berjanji untuk sisa hari

Pelaporan tiga poin memungkinkan master Scrum untuk memantau kemajuan setiap anggota dan untuk
mengidentifikasi tindakan perbaikan, seperti:

• Merencanakan pekerjaan baru yang tidak teridentifikasi dalam rapat perencanaan sprint atau dalam pertemuan Scrum
harian sebelumnya

• Realokasi tugas antara anggota karena ketidakcocokan keterampilan atau kurang menarik
• menghilangkan hambatan

Dibandingkan dengan template pertemuan disajikan dalam Bab 3, Organisasi proyek dan Komunikasi ( Bagian 3.4.3) dan
dalam Bab 12, Manajemen Dasar Pemikiran ( Bagian 12.4.2), Scrum menggunakan template pertemuan dikurangi menjadi minimum
absolut. Sebagai contoh, diskusi dan resolusi masalah baru ditunda untuk menindaklanjuti pertemuan dijadwalkan di kemudian hari di
mana hanya pemangku kepentingan terkait berpartisipasi. The Scrum Pendekatan demikian meminimalkan pengembang waktu yang
dihabiskan dalam pertemuan yang tidak perlu, oleh timeboxing pelaporan status dan dengan hemat mereka dari diskusi yang tidak
relevan untuk mereka. Terjadinya harian pertemuan Scrum memungkinkan tim untuk mengidentifikasi isu-isu yang tak terduga awal
dan membuat keputusan dengan cepat.

Pertemuan Scrum harian memberikan pandangan jangka pendek dari sprint. Ulasan kemajuan dan menilai tren, master
Scrum menggunakan membakar grafik, yang menggambarkan upaya perkiraan sisa sebagai fungsi waktu (lihat Gambar 14-15).
Setiap item backlog di log lari berisi perkiraan informal jam yang diperlukan untuk menyelesaikan item. Para anggota tim
memperbarui perkiraan mereka sehari-hari, didasarkan pada karya yang telah mereka capai sejauh ini dan pada wawasan yang
diperoleh. Pekerjaan yang telah diselesaikan mengurangi upaya yang tersisa di sprint backlog. pekerjaan baru atau direvisi
memperkirakan untuk suatu tugas yang ternyata meningkat lebih kompleks upaya yang tersisa dalam sprint. Sebagai sprint
membakar grafik plot perkiraan jumlah kumulatif bekerja untuk sprint backlog, master Scrum dapat menilai kecenderungan
umum dari sprint dan mengidentifikasi kebutuhan untuk tindakan korektif

sisa
Upaya
[jam]

2000

1000

Waktu [hari]
3 612 15 18 9 21 24 27 30

Gambar 14-15 Menilai kemajuan tren dengan membakar bawah grafik. Peningkatan sesuai dengan revisi naik dari perkiraan kerja
(kerja baru, tugas awalnya diremehkan). Penurunan sesuai dengan estimasi menurun dari sisa pekerjaan (pekerjaan selesai,
tugas usang dibawa keluar dari rencana).

Demikian pula, rilis membakar bawah grafik, diperbarui pada akhir setiap lari, menunjukkan upaya yang tersisa di
hari untuk rilis, berdasarkan perkiraan dari item produk backlog di hari.

14.5.4 Pengakhiran Proyek: Ulasan Sprint

Sementara kemajuan harian tim ini sangat terlihat (misalnya, rapat Scrum harian, update lari backlog setiap hari),
pemilik produk tidak dapat mengganggu tim selama sprint. Setelah rapat perencanaan sprint, tim mengasumsikan
otoritas lengkap untuk kenaikan produk dan dibiarkan sendiri sementara master scrum bertanggung jawab untuk
menghilangkan hambatan yang diajukan oleh tim. Pada akhir sprint, manajemen dapat menyesuaikan komposisi tim
atau pemilik produk dapat berubah persyaratan berdasarkan kinerja tim di masa lalu. Jika tujuan dari sprint menjadi
usang atau tidak terjangkau, sprint juga dapat diakhiri secara abnormal oleh tim atau manajemen. Sebagai sprint
biasanya pendek, terminasi abnormal jarang terjadi.

Dengan akhir setiap lari, pemilik produk dapat menegosiasikan kembali backlog produk dengan klien.
Berdasarkan kenaikan produk terbaru, pemilik produk dapat mengusulkan untuk merevisi persyaratan tertentu atau
prioritas baru assign. Berdasarkan kinerja tim, pemilik produk dapat mengusulkan jadwal rilis atau mengubah alokasi
persyaratan untuk rilis.

Gambar 14-16 menunjukkan gambaran dari proses Scrum.

 Tim scrum scrum Guru Pemilik produk Klien

:Pernyataan masalah

Kick off Proyek

: Product Backlog

rencana Sprint

: Sprint Backlog

Harian Scrum:
Ulasan Tindakan, Mengidentifikasi Hambatan

:Barang Aksi : Hambatan

Bekerja Hapus Hambatan

: Produk Kenaikan

[Terus berlari]

[End lari]

Ulasan Sprint

[Kenaikan baru]

[Rilis baru]

Memberikan Rilis
Produk

: Rilis Produk

Gambar 14-16 Sekilas proses Scrum (UML diagram aktivitas).

14,6 Bacaan lebih lanjut

Sebuah gambaran yang baik dari konsep manajemen proyek generik dapat ditemukan di Portny [Portny, 2001]. Tim adalah
kunci untuk banyak organisasi berbasis proyek. Katzenbach menyediakan kategorisasi jenis tim yang berbeda, mulai dari
kelompok kerja untuk tim berkinerja tinggi [Katzenbach & Smith, 1994]. IEEE-1058 yang diuraikan dalam bab ini adalah di
bawah revisi dan disetujui pada tahun 2009. Royce menggambarkan peran awal seorang arsitek perangkat lunak selama
pengembangan sistem perangkat lunak menggunakan Unified Process [Royce, 1998].

Buku Paulish tentang manajemen proyek arsitektur-sentris berisi penjelasan rinci tentang peluang dan
tantangan ketika arsitektur perangkat lunak diformulasikan secara bersamaan dengan rencana manajemen proyek
software [Paulish, 2001].
Estimasi usaha pengembangan perangkat lunak sulit, dan beberapa pendekatan menghasilkan hasil yang akurat dalam
kasus umum. COCOMO II adalah model statistik yang menyediakan usaha dan waktu perkiraan berdasarkan sejumlah besar
parameter [Boehm et al., 2000].
Di ujung lain dari spektrum estimasi, Perencanaan poker [Grenning 2002] adalah metode estimasi konsensus-driven, di
mana para pemangku kepentingan memperkirakan dan mendiskusikan upaya dalam diskusi moderator. metode konsensus-
driven bertujuan untuk leverage dari pengalaman stakeholder sementara mendamaikan tujuan yang saling bertentangan.
metode berbasis konsensus telah dipopulerkan oleh pengembangan tangkas [Cohn, 2006].

Scrum, yang dikembangkan bersama oleh Ken Schwaber dan Jeff Sutherland di awal 1990-an [Schwaber,
1995], adalah salah satu metode manajemen tangkas awal. Metode pengembangan Scrum dijelaskan dalam
[Schwaber & Beedle, 2002]. Banyak buku telah mengikuti tentang topik ini, termasuk pola adopsi untuk metode
tangkas [Elssamadisy, 2009] dan praktik terbaik [Schwaber, 2004].

Kepentingan sejarah dua bentuk organisasi proyek perangkat lunak yang diusulkan oleh Brooks dan Weinberg. Itu Kepala
programmer organisasi [ Brooks, 1995] adalah organisasi hirarkis yang memberikan semua keputusan tim untuk pemimpin
tim, yang disebut Kepala programmer. Kepala programmer bertanggung jawab untuk desain dan pengembangan subsistem

dan delegasi pemrograman tugas untuk kolam spesialis. Sebaliknya, pemrograman tanpa ego [ Weinberg, 1971] mengambil
struktur yang demokratis, yang diadopsi oleh diri mengorganisir tim Scrum. Bagi orang-orang yang tertarik pada organisasi,
kami merekomendasikan buku dari Wigand, Picot, dan Reichwald [Wigand et al., 1997].
latihan
6

14,7 Latihan

14.1 Dalam Gambar 14-1, kita dimodelkan tahapan proyek dengan bagan negara. Gunakan Pat-negara
tern dengan membuat masing-masing fase ini kelas yang berbeda. Gunakan kegiatan manajemen proyek
diperkenalkan dalam bab ini untuk membuat mereka operasi umum di kelas ini. Asumsikan organisasi proyek
berbasis tim.

14.2 Apa keuntungan relatif dari staf datar dibandingkan staf bertahap? 14-3 Apa perbedaan antara melaporkan status

dan membuat keputusan dalam rapat?

Haruskah mereka selalu disimpan terpisah dalam rapat?

14-4 Mengapa arsitek perangkat lunak dan pemimpin proyek menjadi orang yang berbeda? 14-5 Menggambar

model UML organisasi tim dari ARENA proyek untuk setiap utama
fase (yaitu, konsepsi, definisi, mulai, steady state, terminasi). 14-6 Menggambar model tugas dari desain

sistem yang Perjalananku Sistem yang disajikan dalam Bab 6,

Desain Sistem: Decomposing Sistem.

14.7 Perkirakan waktu untuk menyelesaikan setiap tugas dari model tugas diproduksi di Latihan 14-6

dan menentukan jalur kritis.

14.8 Mengidentifikasi, memprioritaskan, dan rencana atas lima risiko yang berkaitan dengan desain sistem Perjalananku

disajikan dalam Bab 6, Desain Sistem: Decomposing Sistem.

14.9Mengidentifikasi, memprioritaskan, dan rencana atas lima risiko yang berkaitan dengan subsistem antarmuka pengguna

dari CTC disajikan dalam Bab 12, Manajemen alasan.

14.10 Linux, yang dikembangkan menggunakan model bazaar, lebih handal dan lebih responsif dari

banyak sistem operasi yang berjalan pada Intel PC. Membuat kasus mengapa model bazaar harus atau

tidak boleh digunakan untuk perangkat lunak kontrol Space Shuttle. 14-11 Mengatur peserta proyek menjadi

tim empat orang. Setiap tim memiliki

berikut sumber daya yang tersedia: 2 butir telur, 1 rol film TESA, 1 gulungan kertas toilet, cangkir dengan air, ember

dengan dua liter pasir, 20 bola busa (masing-masing diameter sekitar 1 cm), 1 meja yang permukaannya adalah
sekitar 1 meter di atas tanah. Setiap tim memiliki 25 menit waktu untuk membangun dan menguji sebuah artefak
yang memungkinkan telur akan dirilis 75 cm di atas meja sehingga telur jatuh di atas meja tanpa retak. Setiap tim
memiliki 5 menit untuk menunjukkan artefak untuk manajemen proyek.

14-12 Mengatur proyek menjadi tim empat orang. Setiap tim memiliki sumber daya berikut
tersedia: 2 ember buah DUPLO, 2 meja dipisahkan oleh jarak 1,50 meter. Setiap tim memiliki 25 menit waktu untuk

membangun dan menguji sebuah jembatan semata-mata dari potongan-potongan DUPLO tersedia yang hang membebaskan

setidaknya selama satu menit antara dua permukaan meja. Setiap tim memiliki 5 menit untuk menunjukkan artefak untuk

manajemen proyek. 14-13 Tentukan semua model manajemen untuk proyek kapal pemecah es yang dijelaskan dalam Latihan

14-11. 14-14 Menulis sebuah SPMP untuk proyek kapal pemecah es yang dijelaskan dalam Latihan 14-11. 14-15 Apa bagian

datar di luka bakar bawah grafik mean (misalnya bagian antara

hari 3 dan 6 pada Gambar 14-15)?

Referensi
[Albrecht & Gaffney, 1983] AJ Albrecht & JE Gaffney, Jr., “fungsi Software, baris kode sumber, dan pengembangan usaha prediksi:
Sebuah validasi ilmu software,” Transaksi IEEE Rekayasa Perangkat Lunak, Vol. SE-9, No 6, November 1983.

[Boehm, 1991] B. Boehm, “manajemen risiko Software: Prinsip dan praktek,” IEEE Software,
Vol. 1, pp. 32-41, 1991.

[Boehm et al., 2000] B. Boehm, E. Horowitz, R. Madachy, D. Reifer, BK Clark, B. Steece, AW Brown,
S. Chulani, & C. Abts, Software Estimasi Biaya dengan COCOMO II, Prentice Hall, Upper Saddle River, NJ,
2000.

[Brooks, 1995] FP Brooks, The Mythical Man Month, Anniversary Edition: Esai tentang Rekayasa Perangkat Lunak, Addison-Wesley,
Reading, MA, 1995.

[Carr et al., 1993] MJ Carr, SL Konda, I. Monarch, FC Ulrich, & CF Walker, Taksonomi Berbasis Risiko Identifikasi, Laporan
Teknis CMU / SEI-93-TR-6, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA,
1993.

[Charette, 1989] RN Charette, Software Analisis Risiko Teknik dan Manajemen, McGraw-Hill, New York, 1989.

[Cohn, 2006] M. Cohn, Agile Memperkirakan dan Perencanaan, Pearson, Upper Saddle River, NJ 2006.

[Elssamadisy, 2009] A. Elssamadisy, Agile Adopsi Pola, Addison-Wesley, Reading, MA, 2009.

[Grenning 2002] J. Grenning, Perencanaan Poker, http://www.planningpoker.com/ 2002.

[Halstead, 1977] MH Halstead, Elemen Ilmu Software, Elsevier, New York, 1977.

[IEEE Std. 1058-1998] Standar IEEE untuk Software Rencana Manajemen Proyek, IEEE Computer Society, New York, 1998.

[Katzenbach & Smith, 1994] JR Katzenbach & DK Smith, Kebijaksanaan Tim: Menciptakan berkinerja tinggi Organisasi, Harper
Business, 1994.

[Kayser, 1990] TA Kayser, Mining Group Emas, Serif, El Segundo, CA, 1990.

[McCabe, 1976] T. McCabe, “kompleksitas Sebuah perangkat lunak mengukur,” Transaksi IEEE Rekayasa Perangkat Lunak, Vol.

2, No. 12, Desember 1976.

[Paulish 2001] DJ Paulish, Arsitektur-Centric Perangkat Lunak Manajemen Proyek: Sebuah Panduan Praktis,

SEI Series di Rekayasa Perangkat Lunak, Addison-Wesley, Reading, MA, 2001.

[Portny 2001] SE Portny, Manajemen Proyek for Dummies, John Wiley & Sons, 2000.

[Rogers et al., 1986] Komisi Presiden tentang Space Shuttle Challenger Kecelakaan Laporan.
Washington, DC, 6 Juni 1986.

[Royce, 1998] W. Royce, Perangkat Lunak Manajemen Proyek: Sebuah Bersatu Framework, Addison-Wesley, Reading, MA, 1998.

[Schwaber, 1995] K, Schwaber, “Proses Scrum Pembangunan,” Obyek bisnis Desain dan Implementasi Workshop, OOPSLA'95,
Austin, TX, Oktober 1995.

[Schwaber & Beedle 2002] K. Schwaber & M. Beedle, Agile Software Development dengan Scrum, Prentice Hall, Upper Saddle River,
2002.

[Schwaber, 2004] K. Schwaber, Agile Manajemen Proyek Dengan Scrum, Microsoft, Redwood 2004.

[Vaughan, 1996] D. Vaughan, The Challenger Peluncuran Keputusan: Risky Teknologi, Budaya, dan Penyimpangan
di NASA, The University of Chicago Press, Chicago, 1996.

[Weinberg, 1971] GM Weinberg, The Psychology of Pemrograman Komputer, Van Nostrand, New York, 1971.

[Wigand et al., 1997] RT Wigand, A. Picot, & R. Reichwald, Informasi, Organisasi dan Manajemen: Pasar Memperluas dan Batas
Perusahaan, John Wiley & Sons, London, 1997.
Halaman ini sengaja dikosongkan
15

15.1 Pendahuluan: Polinesia Navigasi 622

15.2 IEEE 1074: Standar untuk Mengembangkan Life Cycle Proses 626
15.2.1 Proses dan Kegiatan 626
15.2.2 Life Cycle Modeling 628
Manajemen Proyek 15.2.3 628
15.2.4 Pre-Pembangunan 629
Pengembangan 15.2.5 630
15.2.6 Post-Pembangunan 631
15.2.7 Proses Integral (Cross-Pembangunan) 632

15,3 Karakterisasi Kematangan Model Software Life Cycle 633

15.4 Model Life Cycle 636

Model 15.4.1 Sequential Kegiatan-Centered 637

Model 15.4.2 Iteratif Kegiatan-Centered 639
Model 15.4.3 Entity-Centered 644

15,5 Bacaan lebih lanjut 647

15,6 Latihan 648

Referensi 649

620
 15
Software Life Cycle

Harus selalu ada perbedaan antara konsep dan realitas, karena mantan yang
statis sedangkan yang kedua adalah dinamis dan mengalir.

- Robert Pirsig, di lila

SEBUAH software Model siklus hidup mewakili semua kegiatan dan produk kerja yang diperlukan
untuk mengembangkan sistem perangkat lunak. Hidup model siklus memungkinkan manajer dan pengembang untuk
menangani kompleksitas proses pengembangan perangkat lunak dalam cara yang sama seperti model analisis atau
model desain sistem memungkinkan pengembang untuk menangani kompleksitas sistem perangkat lunak. Dalam
kasus sistem perangkat lunak, realitas yang dimodelkan termasuk fenomena seperti jam tangan, kecelakaan, kereta
api, sensor, dan bangunan. Dalam hal pengembangan perangkat lunak, kenyataannya termasuk fenomena seperti
peserta, tim, kegiatan, dan produk kerja. Banyak model siklus hidup telah diterbitkan dalam literatur dalam upaya
untuk lebih memahami, mengukur, dan mengontrol proses pembangunan.

Dalam bab ini, kita kembali kegiatan yang dijelaskan dalam bab-bab sebelumnya dari perspektif pemodelan siklus hidup.

Teknik-teknik pemodelan yang kita digunakan untuk memodelkan sistem perangkat lunak juga dapat digunakan untuk mewakili siklus

hidup. Sedangkan model siklus hidup biasanya diwakili dengan notasi ad hoc, kami mencoba untuk menggunakan diagram UML bila

memungkinkan. Pertama, kita menggambarkan kegiatan khas dan produk kerja dari siklus hidup perangkat lunak seperti yang

didefinisikan oleh standar IEEE 1074 [IEEE Std. 1074-2006]. Berikutnya, kami memperkenalkan Capability Maturity Model, kerangka kerja

untuk menilai kematangan organisasi dan siklus hidup mereka. Kami kemudian mendiskusikan model siklus hidup yang berbeda yang

telah diusulkan untuk mengembangkan sistem software yang kompleks; ini termasuk model air terjun, model spiral, yang V- model, dan

proses perangkat lunak terpadu. Kami juga membahas model siklus hidup disebut model berbasis masalah, di mana produk dan aktivitas

dimodelkan sebagai satu set isu yang disimpan dalam basis pengetahuan. Model berbasis masalah adalah pandangan entitas yang

berpusat pada siklus hidup perangkat lunak yang dapat mengakomodasi perubahan sering selama durasi proyek.

621
 Bab 15 • Software Life Cycle
6

15.1 Pendahuluan: Polinesia Navigasi

navigasi Polinesia

Polinesia adalah set besar pulau-pulau sekitar membentuk segitiga dengan Tahiti di pusat, Hawaii di utara, Pulau Paskah di
timur, dan Selandia Baru di barat daya. Polinesia berasal dari Asia tenggara, menetap pulau-pulau Pasifik sistematis dari
barat ke timur. Polinesia telah menyelesaikan pemukiman mereka beberapa ratusan tahun sebelum Columbus tiba di Karibia.
Mereka mencapai Tahiti pada tahun 1400 SM, Hawaii di 500 AD, dan Selandia Baru antara tahun 500 AD dan 1100 AD
nelayan Polinesia akan menemukan sebuah pulau baru oportunis, mengidentifikasi lokasi, dan memberitahu orang-orang
kembali ke rumah. Penyelesaian pulau baru itu disengaja, yang melibatkan transplantasi keluarga, tanaman seperti pisang,
tebu, dan ubi jalar, dan hewan peliharaan seperti anjing, babi, dan ayam.

Apa yang membuat prestasi ini bahkan lebih luar biasa adalah bahwa Polinesia adalah teknologi di Zaman Batu. Mereka membangun
multi-dikuliti kano dengan alat tulang dan batu dan tanpa menggunakan logam apapun. kano mereka dirancang untuk tetap pada spesifik
kursus dan menahan badai, dan bisa berlayar signifikan lebih cepat daripada kapal-kapal Eropa waktu. Mereka ditularkan pengetahuan
tentang pelayaran dan lokasi pulau-pulau dari mulut ke mulut dari satu generasi ke generasi berikutnya.

Polinesia berlayar tanpa instrumen, bergantung pada terbit dan terbenam dari bintang, arah angin, dan gelombang laut untuk
mempertahankan kursus. Orang-orang dari pulau Truk di Mikronesia, timur dari Polinesia, telah diawetkan keterampilan ini navigasi kuno
dan memungkinkan kita untuk berspekulasi tentang bagaimana Polinesia berhasil melakukan perjalanan beberapa ribu kilometer dengan
kano. Dekat khatulistiwa, bintang naik dan set sekitar sumbu utara-selatan. Altair, misalnya, terbit di timur dan tenggelam di barat.
Beberapa bintang naik dan set lebih lanjut utara: Vega terbit di timur laut dan set di barat laut. bintang lainnya naik dan set lebih jauh ke
selatan: Antares terbit di sebelah tenggara dan set di barat daya. Ketika menghadapi titik meningkatnya Vega, navigator akan berubah
kembali pada titik pengaturan dari Antares. Dengan menghafal posisi relatif 16, navigator Polinesia selalu bisa menemukan sebuah
bintang yang terlihat untuk menyesuaikan nya saja. Selama hari atau mendung malam, navigator akan menggunakan arah angin dan
membengkak dari laut, yang ia akan hafal dalam hubungan dengan bintang-bintang ini.

Dekat daratan, bentuk dan suara ombak akan berubah. Pada saat itu, mereka mencari spesies tertentu dari burung darat yang
akan terbang ke laut di pagi hari untuk ikan dan kembali ke tanah di malam hari. Ketika bercak burung ini di malam hari, mereka
akan mengikuti penerbangan mereka. Ketika bercak mereka di pagi hari, mereka akan berlayar menuju titik asal mereka.

Sebaliknya, pembuat kapal dari usia Columbus telah menguasai penggunaan logam untuk beberapa ribu tahun. log Columbus
menunjukkan bahwa ia bukan navigator langit. Alih-alih bintang berikutnya, ia menggunakan perhitungan mati: juru mudi diadakan
kursus dengan melihat kompas magnetik. Setiap jam, kecepatan kapal diukur dengan melemparkan sepotong kapar dalam air dan
dengan mengukur waktu yang dibutuhkan untuk membersihkan panjang kapal. Dengan mengetahui arah dan kecepatan kapal setiap
saat, Columbus bisa menghitung jarak yang telah berlayar sejak meninggalkan pelabuhan. Kita tahu dari catatan bahwa ia tidak
menggunakan kompas dikoreksi, karena kursus ke arah Amerika melayang ke selatan. Dalam perjalanan punggungnya, tentu saja itu
melayang dengan jumlah yang sama ke utara, jadi dia tidak melihat keterbatasan kompas magnetik.
Contoh di atas menggambarkan bagaimana tujuan yang sama dapat dicapai dengan proses yang sangat berbeda. Polinesia
berkembang kerajinan mereka navigasi dan pengetahuan mereka tentang bintang-bintang selama perjalanan laut semakin lama,
karena jarak antar pulau meningkat secara signifikan saat mereka bergerak ke arah timur. Mereka diciptakan dan disempurnakan
sebuah proses yang bisa diulang secara akurat setiap kali sebuah pulau baru ditemukan. Pada saat Columbus, paling navigator
tinggal dekat dengan pantai, karena mereka berlayar menuju Hindia sekitar Afrika menggunakan hisab mati. Columbus
menerapkan proses navigasi yang ada untuk menyeberangi Atlantik. Dalam kedua kasus, navigator memiliki tujuan (misalnya,
menetap sebuah pulau tertentu, mencari rute transatlantik ke Hindia) dan satu set keterampilan bertahan hidup diterapkan pada
situasi lokal yang akhirnya didukung bahwa tujuan (misalnya, mengakui kedekatan pulau, kemampuan untuk mengatur kursus,
kemampuan untuk memperbaiki kursus). Jika Columbus dan Polinesia telah bertemu dan bisa berkomunikasi, masing-masing bisa
belajar berbagai keterampilan baru dan dimodifikasi proses masing-masing sesuai. Transfer ini pengetahuan, bagaimanapun,
mengasumsikan bahwa Columbus dan Polinesia akan mampu untuk berbagi model umum navigasi.

Dalam bab-bab sebelumnya, kita menggunakan UML sebagai bahasa pemodelan untuk menggambarkan dan mengkomunikasikan

tentang sistem. Dalam bab ini, kita fokus pada model proses pengembangan perangkat lunak, yang disebut software model siklus hidup. Pemodelan

siklus hidup perangkat lunak adalah suatu usaha yang sulit karena merupakan sistem yang kompleks dan berubah. Seperti sistem

perangkat lunak, siklus hidup perangkat lunak dapat digambarkan oleh beberapa model yang berbeda. Kebanyakan model siklus hidup

yang diusulkan telah difokuskan pada kegiatan pengembangan perangkat lunak dan mewakili mereka secara eksplisit sebagai objek kelas.

Pandangan dari siklus hidup perangkat lunak disebut Kegiatan dipusatkan. Pandangan lain dari siklus hidup perangkat lunak adalah untuk

fokus pada produk kerja yang diciptakan oleh kegiatan ini. tampilan lain ini disebut entitas berpusat. Kegiatan yang berpusat pandangan

mengarah peserta untuk fokus pada bagaimana produk pekerjaan diciptakan. Entitas yang berpusat pandangan mengarah peserta untuk

fokus pada konten dan struktur produk kerja. Gambar 15-1 menggambarkan siklus hidup sederhana untuk pengembangan perangkat lunak

menggunakan tiga kegiatan: Definisi masalah, Pengembangan sistem, dan Sistem operasi.

Gambar 15-2 menunjukkan pandangan aktivitas yang berpusat model siklus hidup sederhana ini. Hubungan antara
kegiatan menunjukkan waktu ketergantungan linier, yang tersirat dengan menggunakan notasi diagram aktivitas: masalah
mendahului pernyataan pengembangan sistem, yang pada gilirannya sistem operasi mendahului. dependensi waktu lain yang
mungkin.

Misalnya, dalam siklus hidup perangkat lunak dari Gambar 15-3, kegiatan Pengembangan sistem

dan penciptaan pasar bisa dilakukan secara bersamaan.

Gambar 15-4 adalah pandangan entitas yang berpusat dari model yang digambarkan oleh tokoh 15-2. pengembangan perangkat

lunak menghasilkan empat entitas: a Pasar penelitian dokumen, Sebuah Persyaratan

dokumen spesifikasi, sebuah sistem dieksekusi, dan Pelajaran dokumen.

Pandangan aktivitas yang berpusat dan entitas berpusat saling melengkapi, seperti yang digambarkan oleh
Gambar 15-5. Setiap produk yang dihasilkan oleh satu atau lebih kegiatan. Itu Kegiatan definisi masalah menggunakan
dokumen

survei pasar sebagai masukan dan menghasilkan Persyaratan spesifikasi dokumen. Itu Pengembangan sistem Kegiatan mengambil dokumen

persyaratan spesifikasi sebagai masukan dan menghasilkan sistem dieksekusi. Sistem operasi
 Pengembangan perangkat lunak
«Meliputi» «Meliputi»
«Meliputi»

Sistem operasi
Definisi masalah Pengembangan sistem

Klien
Manajer proyek pembangun Administrator Pengguna akhir

Gambar 15-1 Sederhana siklus hidup untuk pengembangan perangkat lunak (UML menggunakan diagram kasus).

Kegiatan definisi masalah Pengembangan sistem Kegiatan operasi sistem

aktivitas

Gambar 15-2 Sederhana siklus hidup untuk pengembangan perangkat lunak (UML diagram aktivitas).

aSkistitveimtas pengembangan penciptaan pasar

Kegiatan Kegiatan peningkatan sistem

Gambar 15-3 Lain hidup sederhana siklus (UML diagram aktivitas).

menghasilkan Dokumen pelajaran yang dapat digunakan selama pengembangan produk berikutnya. Atau, setiap kegiatan
menghasilkan satu atau lebih produk.

Dalam Bagian 15.2, kita menggambarkan kegiatan siklus hidup didefinisikan oleh IEEE 1074 standar [IEEE Std.

1074-2006]. Ini memperkenalkan standar definisi yang tepat yang memungkinkan peserta proyek untuk memahami dan

berkomunikasi secara efektif tentang siklus hidup. Pada bagian ini, kami juga menggambarkan arus informasi antara kegiatan.
 Pengembangan perangkat lunak

pelajaran
Survei pasar
dokumen
dokumen

Spesifikasi kebutuhan
dokumen sistem executable

Gambar 15-4 Entitas yang berpusat pandangan pengembangan perangkat lunak (diagram kelas UML).

Aktivitas produk kerja

belajar
mengkonsumsi do kumen
Definisi masalah
aktivitas
menghasilkan
Sp esifikasi
dokumen
mengkonsumsi
Pengembangan sistem
aktivitas

menghasilkan
sistem e xecutable
mengkonsumsi
Sistem operasi
aktivitas
mengha aran survei Market
silkan Pelaj
dokumen

Gambar 15-5 Kegiatan dan produk dari siklus hidup sederhana Gambar 15-2 (UML class diagram).

Dalam Bagian 15.3, kita menggambarkan Capability Maturity Model, kerangka kerja untuk menilai kematangan organisasi
dan siklus hidup mereka. Kerangka kerja ini memungkinkan organisasi dan proyek yang akan dibandingkan berdasarkan pada
kegiatan siklus hidup mereka.
Dalam Bagian 15.4, kita survei beberapa model siklus hidup kegiatan berpusat yang mengusulkan penataan yang
berbeda dari kegiatan. Kami membahas dua model sekuensial, model air terjun [Royce, 1970] dan V- Model [Jensen &
Tonies, 1979], dan dua model berulang, model spiral [Boehm, 1987] dan Software Unified Process [Jacobson et al., 1999].
Kami juga menggambarkan model siklus hidup berbasis entitas berdasarkan isu.
15.2 IEEE 1074: Standar untuk Mengembangkan Life Cycle Proses

Itu Standar IEEE untuk Proses Software Life Cycle menggambarkan serangkaian kegiatan dan proses yang wajib untuk
pengembangan dan pemeliharaan perangkat lunak [IEEE Std. 1074-2006]. Tujuannya adalah untuk membangun kerangka
kerja umum untuk mengembangkan model siklus hidup dan memberikan contoh untuk situasi yang khas. Pada bagian ini, kami
menggambarkan kegiatan utama diperkenalkan oleh standar dan memperjelas konsep dasar dengan menggunakan diagram
UML.

15.2.1 Proses dan Kegiatan

SEBUAH proses adalah serangkaian kegiatan yang dilakukan ke arah tujuan tertentu (misalnya, persyaratan, manajemen,
pengiriman). IEEE daftar standar total 17 proses, dikelompokkan ke tingkat yang lebih tinggi dari abstraksi yang disebut kelompok
proses ( Tabel 15-1). Contoh kelompok proses yang manajemen proyek, pra-pembangunan, pengembangan, dan
pasca-pembangunan. Contoh proses dalam kelompok proses pembangunan termasuk

• itu Persyaratan Proses di mana para pengembang mengembangkan model sistem

• itu Proses desain di mana pengembang mendekomposisi sistem menjadi komponen-komponen

• itu Proses implementasi di mana pengembang menyadari setiap komponen.

tabel 15-1 proses perangkat lunak dalam IEEE 1074.

kelompok proses proses

Life Cycle Modeling Pemilihan Cycle Model Hidup

Manajemen proyek Proyek Inisiasi Pemantauan dan

Pengendalian Software
Manajemen Mutu

Pre-Pembangunan Konsep
Eksplorasi Sistem
Alokasi

Pengembangan Persyaratan
Desain
Implementasi

Post-Pembangunan Instalasi Operasi dan

Dukungan Pemeliharaan
Pensiun

Integral Dokumentasi Verifikasi dan Validasi Perangkat

Lunak Manajemen Konfigurasi Pelatihan
Pengembangan
IEEE 1074: Standar untuk Mengembangkan Life Cycle Proses
6

Setiap proses terdiri dari kegiatan. Sebuah aktivitas adalah tugas atau kelompok subactivities yang ditugaskan
untuk tim atau peserta proyek untuk mencapai tujuan tertentu. Itu Persyaratan Proses, misalnya, terdiri dari tiga
kegiatan:

• Mendefinisikan dan Mengembangkan Persyaratan Software di mana fungsi dari sistem didefinisikan
secara tepat

• Mendefinisikan Antarmuka Persyaratan di mana interaksi antara sistem dan pengguna didefinisikan secara
tepat

• Memprioritaskan dan Mengintegrasikan Persyaratan Software di mana semua persyaratan yang terintegrasi
untuk konsistensi dan diprioritaskan oleh preferensi klien.

Tugas mengkonsumsi sumber daya (misalnya, tenaga, waktu, uang) dan menghasilkan produk kerja. Selama perencanaan,
kegiatan didekomposisi menjadi tugas proyek tertentu, diberi mulai dan tanggal berakhir, dan ditugaskan untuk tim atau peserta
proyek (Gambar 15-6). Selama proyek, pekerjaan yang sebenarnya dilacak terhadap tugas-tugas yang direncanakan, dan sumber
daya dialokasikan untuk menanggapi masalah.

Software Life Cycle

* Uang

proses Grup Waktu

* Peserta

Proses *
Sumber

*
Unit kerja

dikonsumsi oleh
* *

Tugas Produk kerja

menghasilkan
Aktivitas

Gambar 15-6 Model siklus hidup perangkat lunak (UML class diagram). Sebuah siklus hidup perangkat lunak terdiri dari kelompok proses, yang pada

gilirannya terdiri dari proses. Sebuah proses menyelesaikan tujuan tertentu (misalnya, persyaratan, desain, instalasi). Sebuah proses terdiri dari kegiatan,
yang pada gilirannya terdiri dari subactivities atau tugas. Tugas mewakili bagian terkecil dari kerja yang relevan dengan manajemen. Tugas

mengkonsumsi sumber daya dan menghasilkan satu atau lebih produk kerja. Sebuah proyek adalah sebuah contoh dari siklus hidup perangkat lunak.
 Proses yang diperlukan oleh IEEE 1074 tercantum pada Tabel 15-1. Dari titik pengembang pandang, enam
proses pertama (yaitu, Life Cycle Modeling, itu Manajemen proyek, dan
Pre-Pengembangan Proses) sering sudah dimulai sebelum keterlibatan mereka dengan proyek.

15.2.2 Life Cycle Modeling

Selama Life Cycle Modeling, manajer proyek mengkustomisasi kegiatan didefinisikan dalam IEEE 1074 untuk proyek tertentu (yaitu,
untuk contoh model siklus hidup). Tidak semua proyek memerlukan kegiatan yang sama dan sequencing yang sama kegiatan.
Misalnya, proyek-proyek yang tidak berhubungan dengan penyimpanan persisten tidak perlu menjalankan aktivitas Desain Data

Base. Model siklus hidup yang dipilih berfungsi sebagai input ke Proses Inisiasi proyek dijelaskan pada bagian berikutnya.

Manajemen Proyek 15.2.3

Selama Manajemen proyek, para inisiat manajer proyek, monitor, dan kontrol proyek sepanjang siklus hidup perangkat
lunak. Manajemen proyek terdiri dari tiga proses (Tabel 15-2).

Itu Proses Inisiasi proyek menciptakan infrastruktur untuk proyek tersebut. Selama proses ini, rencana tugas,
jadwal, anggaran, organisasi, dan lingkungan proyek didefinisikan. Lingkungan proyek meliputi standar proyek,
infrastruktur komunikasi, prosedur pertemuan dan pelaporan, metodologi pengembangan, dan alat-alat pengembangan.
Sebagian besar

tabel 15-2 proses manajemen proyek.

Proses Ayat Sebuah Kegiatan

Inisiasi proyek 3.1.3

Peta Kegiatan untuk Software Life Cycle Model Alokasikan
3.1.4
Proyek Sumber Daya Membangun Proyek Lingkungan
3.1.5
Rencana Manajemen Proyek
3.1.6

Pemantauan dan Pengendalian Proyek 3.2.3

Menganalisis Risiko Melakukan Perencanaan
3.2.4
Kontinjensi Mengelola Proyek
3.2.5
Mempertahankan Rekor
3.2.6
3.2.7
Menerapkan Masalah Pelaporan Model

Software Manajemen Mutu 3.3.3

Rencana Software Manajemen Mutu Tentukan Metrik
3.3.4
Mengelola Kualitas Software Mengidentifikasi
3.3.5
Kebutuhan Peningkatan Kualitas
3.3.6

Sebuah. Klausul Kolom dalam tabel ini dan tabel lain dalam bab ini mengacu pada sejumlah klausul dalam IEEE 1074. Ini adalah referensi silang ke
dokumen standar yang diterbitkan dalam [IEEE Std. 1074-2006].
Informasi yang dihasilkan selama proses ini didokumentasikan dalam Software Rencana Manajemen Proyek (SPMP). Itu Proses
Inisiasi proyek selesai secepat lingkungan yang stabil untuk proyek tersebut didirikan.

Itu Pemantauan proyek dan Kontrol Proses memastikan bahwa proyek dilaksanakan sesuai dengan rencana
tugas dan anggaran. Jika manajer proyek mengamati setiap penyimpangan dari jadwal, dia akan mengambil tindakan
korektif seperti realokasi beberapa sumber daya, mengubah prosedur, atau replanning jadwal. The SPMP diperbarui
untuk mencerminkan perubahan ini. Itu Pemantauan proyek dan Kontrol Proses aktif sepanjang siklus hidup.

Itu Proses Perangkat Lunak Manajemen Mutu memastikan bahwa sistem dalam pembangunan memenuhi standar
kualitas yang diperlukan (yang dipilih selama Inisiasi Proyek). Proses ini dijalankan oleh tim manajemen mutu yang
terpisah untuk menghindari konflik kepentingan (yaitu, tujuan dari pengembang adalah untuk melengkapi sistem pada
waktu, dan tujuan dari tim manajemen mutu adalah untuk memastikan bahwa sistem ini tidak dianggap lengkap sampai
memenuhi standar mutu yang diperlukan). Itu Proses Perangkat Lunak Manajemen Mutu aktif di hampir seluruh siklus
hidup.

Kami dijelaskan pada Bab 14, Manajemen proyek, kegiatan Inisiasi proyek dan
Pemantauan dan Pengendalian Proyek yang terkait dengan perencanaan, organisasi, dan pelacakan. kegiatan ini
Membangun Proyek Lingkungan membutuhkan perhatian khusus dalam konteks proyek teambased. Salah satu bagian penting
dari lingkungan proyek infrastruktur komunikasi yang akan mendukung penyebaran informasi di antara para peserta. Untuk
dapat bereaksi dengan cepat terhadap perubahan dan masalah laporan tanpa memperkenalkan overhead yang tidak
masuk akal, semua peserta proyek perlu menyadari dari arus informasi melalui proyek dan mekanisme untuk
menyebarkan informasi. Kami dijelaskan pada Bab 3, Organisasi proyek dan Komunikasi,

kegiatan yang berkaitan dengan mendefinisikan dan menggunakan

infrastruktur komunikasi. Perhatikan bahwa untuk menentukan struktur tim pengembangan, dan dengan demikian
infrastruktur komunikasi, arsitektur sistem awal (diproduksi oleh Proses Alokasi sistem dijelaskan pada bagian berikutnya)
pertama harus didefinisikan.

15.2.4 Pre-Pembangunan

Selama Pre-Pembangunan, manajemen (atau pemasaran) dan klien mengidentifikasi ide atau kebutuhan. Hal ini dapat
diatasi dengan upaya baru pengembangan (engineering greenfield), atau perubahan ke antarmuka sistem (rekayasa
interface) yang ada, atau penggantian perangkat lunak dari proses bisnis yang ada (rekayasa ulang). Itu Proses Alokasi
sistem menetapkan arsitektur sistem dan perangkat keras mengidentifikasi, perangkat lunak, dan persyaratan
operasional awal. Perhatikan bahwa subsistem dekomposisi adalah dasar dari infrastruktur komunikasi di antara anggota
proyek. Persyaratan, subsistem dekomposisi, dan infrastruktur komunikasi dijelaskan dalam Pernyataan masalah, 1 yang
berfungsi sebagai masukan untuk

Pengembangan proses. Itu Pre-Pembangunan proses yang digambarkan dalam Tabel 15-3.

1. Pernyataan Need disebutkan dalam IEEE 1074 standar mirip dengan Pernyataan masalah, tapi tidak
mengandung informasi organisasi proyek apapun.
tabel 15-3 proses pra-pembangunan.

Proses Ayat Kegiatan

konsep Eksplorasi 4.1.3

Mengidentifikasi Ide atau Kebutuhan Merumuskan
4.1.4
Potensi Pendekatan Perilaku Studi Kelayakan
4.1.5
Rencana Sistem Transisi (jika Berlaku) Perbaiki dan
4.1.6
Finalisasi Ide atau Kebutuhan
4.1.7

sistem Alokasi 4.2.3

Analisa Fungsi Mengembangkan
4.2.4
Persyaratan Sistem Arsitektur terurai
4.2.5
Sistem

Pengembangan 15.2.5

Pengembangan terdiri dari proses diarahkan pada pembangunan sistem (Tabel 15-4).

Itu Persyaratan Proses dimulai dengan deskripsi informal persyaratan dan mendefinisikan persyaratan sistem
dalam hal kebutuhan fungsional tingkat tinggi, menghasilkan spesifikasi lengkap dari sistem dan prioritas kebutuhan.
Kami menggambarkan
Persyaratan Proses dalam Bab 4, Persyaratan elisitasi, dan Bab 5, Analisis.

Itu Proses desain mengambil arsitektur yang dihasilkan selama Proses Alokasi sistem
dan spesifikasi dari Persyaratan dan menghasilkan koheren dan representasi baik terorganisir dari sistem. Aktivitas Lakukan
Desain Arsitektur dan desain Antarmuka

tabel 15-4 proses pembangunan.

Proses Ayat Kegiatan

Persyaratan 5.1.3
Mendefinisikan dan Mengembangkan Persyaratan Software
5.1.4
mendefinisikan Antarmuka Persyaratan Prioritaskan dan
5.1.5
Mengintegrasikan Persyaratan Software

Rancangan 5.2.3
5.2.4 Lakukan Desain Arsitektur Data Base
5.2.5 (jika Berlaku) Desain Antarmuka
5.2.6
5.2.7 Pilih atau Mengembangkan Algoritma (jika Berlaku)
Lakukan Detil Desain

Penerapan 5.3.3
5.3.4 Buat Data Uji Buat Sumber
5.3.5 Menghasilkan Obyek Kode Buat Operasi

5.3.6 Dokumentasi Rencana Integrasi Lakukan

5.3.7 Integrasi

5.3.8
memperbaiki dekomposisi subsistem. Ini juga termasuk alokasi persyaratan perangkat keras dan perangkat lunak
sistem, deskripsi kondisi batas, pemilihan komponen off-theshelf, dan definisi tujuan desain. Desain rinci dari
masing-masing subsistem dilakukan selama Lakukan Desain Rinci aktivitas. Itu Proses desain menghasilkan definisi objek
desain, atribut dan operasi mereka, dan organisasi mereka ke dalam paket. Pada akhir kegiatan ini, semua metode dan
jenis tanda tangan mereka didefinisikan. kelas baru diperkenalkan untuk memperhitungkan kebutuhan nonfungsional
akun dan rincian komponen-spesifik. Itu Rancangan

proses yang digunakan dalam buku ini dijelaskan dalam Bab 6, Desain Sistem: Decomposing Sistem,

Bab 8, Obyek Desain: Menggunakan kembali Pola Solusi, dan Bab 9, Obyek Desain: Menentukan Interfaces.

Itu Proses implementasi mengambil model desain dan menghasilkan representasi dieksekusi setara. Itu Proses
implementasi meliputi perencanaan integrasi dan kegiatan integrasi. Perhatikan bahwa tes yang dilakukan selama proses
ini adalah independen dari mereka yang dilakukan selama kontrol kualitas atau Verifikasi dan Validasi. Kami menjelaskan
dalam Bab 11,
pengujian, pengujian dan integrasi aspek Penerapan.

15.2.6 Post-Pembangunan

Post-Pembangunan terdiri dari instalasi, pemeliharaan, operasi dan dukungan, dan proses pensiun (Tabel 15-5).

Selama Instalasi, perangkat lunak sistem didistribusikan dan dipasang di situs klien. Berpuncak instalasi
dengan tes penerimaan klien sesuai dengan kriteria yang ditetapkan dalam
Perjanjian proyek. Operasi dan Dukungan berkaitan dengan pelatihan pengguna dan pengoperasian sistem. Pemeliharaan
berkaitan dengan resolusi kesalahan perangkat lunak, kesalahan, dan kegagalan setelah pengiriman sistem. Pemeliharaan
membutuhkan ramping dari siklus hidup perangkat lunak

tabel 15-5 proses pasca-pembangunan.

Proses Ayat Kegiatan

Instalasi 6.1.3
Rencana Pemasangan Distribusi
6.1.4
Instalasi Perangkat Lunak Perangkat
6.1.5
Lunak
6.1.7
Terima Software di Lingkungan Operasional

Operasi dan Dukungan 6.2.3

Mengoperasikan Sistem
6.2.4
Memberikan Bantuan Teknis dan Konsultasi Menjaga
6.2.5
Dukungan Permintaan Login

Pemeliharaan 6.3.3 Mengajukan permohonan kembali Software Life Cycle

pengunduran diri 6.4.3

6.4.4 Beritahu Pengguna
6.4.5 Melakukan Operasi Paralel (Jika Berlaku) Pensiun
Sistem
proses dan kegiatan dalam sebuah proyek baru. pengunduran diri menghapus sistem yang ada, mengakhiri operasinya atau
dukungan; ini terjadi ketika sistem upgrade atau diganti dengan sistem baru. Untuk memastikan kelancaran transisi antara dua
sistem, baik sistem sering dijalankan secara paralel sampai pengguna telah terbiasa dengan sistem baru. Kecuali untuk
pengiriman klien dan penerimaan, kita tidak membahas proses pasca-pembangunan di buku ini.

15.2.7 Proses Integral (Cross-Pembangunan)

Beberapa proses berlangsung selama durasi lengkap proyek. Ini disebut

proses Integral ( kami juga menggunakan istilah cross-pengembangan proses) dan termasuk Validasi dan Verifikasi, Software
Configuration Management, Dokumentasi Pembangunan, dan
pelatihan ( Tabel 15-6).

Verifikasi dan Validasi termasuk verifikasi dan validasi tugas. Verifikasi tugas fokus pada menunjukkan bahwa
model sistem sesuai dengan spesifikasi. Verifikasi meliputi ulasan, audit, dan inspeksi. Validasi tugas memastikan
bahwa alamat sistem kebutuhan klien dan termasuk pengujian sistem, pengujian beta, dan pengujian penerimaan klien. Verifikasi
dan Validasi kegiatan terjadi sepanjang siklus hidup dengan maksud mendeteksi anomali sedini mungkin. Sebagai
contoh, setiap model dapat ditinjau terhadap checklist pada akhir proses yang dihasilkan itu. Review model,
mengatakan model desain, dapat mengakibatkan modifikasi model yang dihasilkan dalam proses lainnya, mengatakan
model analisis. kegiatan ini

tabel 15-6 proses Integral (juga disebut proses cross-pengembangan).

Proses Ayat Kegiatan

Verifikasi dan Validasi 7.1.3

Rencana Verifikasi dan Validasi Jalankan Verifikasi dan
7.1.4
Validasi Tugas Mengumpulkan dan Menganalisis Metric
7.1.5
Rencana Pengujian Data Mengembangkan Persyaratan Uji
7.1.6
Jalankan Tes
7.1.7
7.1.8

Software Manajemen
7.2.3 Rencana Pengelolaan Konfigurasi
Konfigurasi
7.2.4 Mengembangkan Konfigurasi Identifikasi Lakukan
7.2.5 Pengendalian Konfigurasi Lakukan Akuntansi
7.2.6 Status

Pengembangan dokumentasi 7.3.3

7.3.4 Dokumentasi rencana Melaksanakan

7.3.5 Dokumentasi Produksi dan Distribusi

Dokumentasi

Latihan 7.4.3
7.4.4 Rencana Program Pelatihan

7.4.5 Pengembangan Validasi Program Bahan

7.4.6 Pelatihan Pelatihan Melaksanakan Program

Pelatihan
Mencirikan Kematangan Model Software Life Cycle
6

Mengumpulkan dan Menganalisis Metric data menghasilkan data proyek yang juga dapat berfungsi untuk proyek-proyek masa
depan dan berkontribusi pada pengetahuan organisasi. Aktivitas rencana Pengujian dan Mengembangkan Persyaratan Uji
dapat dimulai sedini setelah selesainya persyaratan. Dalam proyek-proyek besar, tugas-tugas ini dilakukan oleh peserta yang
berbeda dari para pengembang. Kami menjelaskan mekanisme ulasan, audit, dan inspeksi dalam Bab 3, Organisasi proyek

dan Komunikasi. Kami menjelaskan ulasan khusus yang terkait dengan persyaratan elisitasi, analisis, dan desain sistem dalam
Bab 4, 5, dan 6, masing-masing. Kami menggambarkan kegiatan pengujian dalam Bab 11, Pengujian.

Itu Proses Manajemen konfigurasi berfokus pada pelacakan dan pengendalian perubahan dari produk kerja. Item
di bawah manajemen konfigurasi termasuk kode sumber untuk sistem, semua model pengembangan, rencana
manajemen proyek perangkat lunak, dan semua dokumen terlihat dengan peserta proyek. Kami menjelaskan manajemen
konfigurasi pada Bab 13, Manajemen konfigurasi.

Itu Proses dokumentasi berkaitan dengan produk kerja (tidak termasuk kode), mendokumentasikan hasil
yang dihasilkan oleh proses lainnya. Dokumen template yang dipilih selama kegiatan ini. IEEE 1074 standar, namun,
tidak menetapkan dokumen tertentu atau template. Pembangunan dan lintas-pengembangan isu dokumentasi spesifik
dibahas dalam bab-bab mana dokumen diproduksi (misalnya, Bab 5, Analisis, membahas Analisis Persyaratan Dokumen; Bab
13, Manajemen konfigurasi, membahas Konfigurasi Software Manajemen Plan).

15,3 Karakterisasi Kematangan Model Software Life Cycle

Pada bagian sebelumnya kita memperkenalkan kegiatan dan artefak yang merupakan siklus hidup perangkat lunak. Manakah dari
kegiatan ini dan artefak yang dipilih untuk proyek tertentu tidak didefinisikan oleh standar. Salah satu tujuan dari Capability Maturity
Model (CMM) adalah untuk memberikan pedoman untuk memilih kegiatan siklus hidup. CMM mengasumsikan bahwa
pengembangan sistem perangkat lunak yang dibuat lebih diprediksi ketika sebuah organisasi menggunakan proses siklus hidup
yang terstruktur dengan baik, terlihat semua peserta proyek, dan ketika beradaptasi organisasi untuk perubahan. CMM
menggunakan lima tingkat berikut untuk mengkarakterisasi jatuh tempo dari sebuah organisasi [Paulk et al, 1995.]:

Level 1: Initial. Sebuah organisasi pada tingkat awal berlaku kegiatan ad hoc untuk mengembangkan perangkat lunak.
Beberapa dari kegiatan ini didefinisikan dengan baik. Keberhasilan suatu proyek pada tingkat kematangan ini biasanya
tergantung pada upaya heroik dan keterampilan individu kunci. Dari titik klien pandang, model siklus hidup perangkat lunak,
jika ada sama sekali, adalah kotak hitam: setelah memberikan pernyataan masalah dan negosiasi perjanjian proyek, klien
harus menunggu sampai akhir proyek untuk memeriksa kiriman dari proyek. Selama durasi proyek, klien memiliki efektif cara
untuk berinteraksi dengan manajemen proyek.

Level 2: Repeatable. Setiap proyek memiliki model siklus hidup perangkat lunak didefinisikan dengan baik. Model, bagaimanapun, berbeda di

antara proyek-proyek, mengurangi kesempatan untuk kerja sama tim dan penggunaan kembali pengetahuan.
proses manajemen proyek dasar yang digunakan untuk biaya melacak dan jadwal. proyek-proyek baru didasarkan pada

pengalaman organisasi dengan proyek-proyek sebelumnya yang serupa dan keberhasilan diprediksi untuk proyek-proyek di domain

aplikasi serupa. Klien berinteraksi dengan organisasi pada titik-titik welldefined dalam waktu, seperti ulasan klien dan tes

penerimaan klien, yang memungkinkan beberapa koreksi sebelum pengiriman.

Level 3: Defined. Tingkat ini menggunakan hidup perangkat lunak model siklus didokumentasikan untuk semua
kegiatan manajerial dan teknis di seluruh organisasi. Sebuah versi disesuaikan dari model diproduksi pada awal
setiap proyek selama Life Cycle Modeling aktivitas. Klien tahu model standar dan model yang dipilih untuk proyek
tertentu.

Level 4: Managed. Tingkat ini mendefinisikan metrik untuk kegiatan dan kiriman. Data terus dikumpulkan selama
durasi proyek. Akibatnya, model siklus hidup perangkat lunak dapat secara kuantitatif dipahami dan dianalisis. Klien
diberitahu tentang risiko sebelum proyek dimulai dan tahu langkah-langkah yang digunakan oleh organisasi.

Level 5: Dioptimalkan. Data pengukuran yang digunakan dalam mekanisme umpan balik untuk memperbaiki hidup
perangkat lunak model siklus selama masa klien organization.The, manajer proyek, dan pengembang berkomunikasi dan
bekerja sama selama pengembangan proyek.

Untuk dapat mengukur kematangan organisasi, satu set area proses kunci (KPA)
telah didefinisikan oleh Engineering Institute Software (SEI). Untuk mencapai tingkat tertentu kematangan, organisasi harus

menunjukkan bahwa alamat semua area proses kunci yang ditetapkan untuk tingkat itu. Beberapa area proses kunci ini

melampaui kegiatan didefinisikan dalam IEEE 1074 standar. Tabel 15-7 menunjukkan pemetaan antara tingkat kematangan

dan area proses kunci.

tabel 15-7 Pemetaan kematangan proses dan area proses kunci.

Tingkat kedewasaan Key Proses Lokasi

1. awal Tak dapat diterapkan

2. Repeatable Fokus: Menetapkan kontrol manajemen proyek dasar.

• Persyaratan manajemen: Persyaratan baselined dalam perjanjian proyek dan dipelihara

selama proyek.
• perencanaan proyek dan pelacakan: Sebuah rencana manajemen proyek perangkat lunak didirikan
pada awal proyek dan dilacak selama proyek.
• manajemen Subkontraktor: Yang ditunjuk oleh organisasi dan efektif mengelola subkontraktor software
yang berkualitas.
• manajemen jaminan kualitas: Semua kiriman dan kegiatan proses diperiksa dan diaudit
untuk memastikan bahwa mereka memenuhi standar dan pedoman yang diadopsi oleh
organisasi.

• Manajemen konfigurasi: Satu set konfigurasi item manajemen didefinisikan dan dipelihara
sepanjang seluruh proyek.
tabel 15-7 Lanjutan.

Tingkat kedewasaan Key Proses Lokasi

3. Ditetapkan Fokus: Membangun infrastruktur yang memungkinkan hidup perangkat lunak model siklus efektif tunggal di semua

proyek.

• Proses organisasi fokus: Organisasi ini memiliki tim permanen untuk terus mempertahankan dan meningkatkan
model siklus hidup perangkat lunak.
• Organisasi definisi proses: Sebuah hidup perangkat lunak model siklus standar digunakan untuk semua proyek
dalam organisasi. Sebuah database digunakan untuk hidup perangkat lunak informasi yang berhubungan dengan
siklus dan dokumentasi.
• Program pelatihan: Organisasi mengidentifikasi kebutuhan untuk pelatihan untuk proyek-proyek tertentu dan
mengembangkan program pelatihan.
• manajemen perangkat lunak yang terintegrasi: Setiap tim proyek dapat menyesuaikan nya proses
spesifik dari proses standar.
• Perangkat lunak rekayasa produk: Perangkat lunak ini dibangun sesuai dengan hidup perangkat lunak siklus,
metode, dan alat-alat didefinisikan.
• koordinasi antar kelompok: Tim proyek berinteraksi satu sama lain untuk kebutuhan alamat
dan masalah.
• peer review: Pengembang memeriksa kiriman masing-masing untuk mengidentifikasi cacat potensial dan daerah di
mana perubahan yang diperlukan.

4. Dikelola Fokus: pemahaman kuantitatif dari proses siklus hidup perangkat lunak dan kiriman.

• manajemen proses kuantitatif: Produktivitas dan metrik kualitas didefinisikan dan terus-menerus
diukur di proyek. Sangat penting bahwa data ini tidak segera digunakan selama proyek, khususnya
untuk menilai kinerja pengembang, tetapi disimpan dalam database untuk memungkinkan
perbandingan dengan proyek-proyek lainnya.

• Manajemen mutu: Organisasi ini telah ditetapkan satu set tujuan kualitas untuk produk perangkat lunak. Memonitor
dan menyesuaikan tujuan dan produk untuk memberikan produk berkualitas tinggi kepada pengguna.

5. Dioptimalkan Fokus: Melacak teknologi dan proses perubahan yang dapat menyebabkan perubahan dalam model sistem
atau deliverables, bahkan selama proyek.

• pencegahan cacat: Kegagalan dalam proyek-proyek masa lalu dianalisis, menggunakan data dari database
metrik. Jika perlu, tindakan spesifik yang diambil untuk mencegah cacat mereka dari terjadi lagi.

• Teknologi manajemen perubahan: enabler dan inovasi teknologi terus-

menerus diselidiki dan berbagi seluruh organisasi.
• manajemen perubahan proses: Proses perangkat lunak terus disempurnakan dan diubah menjadi
kesepakatan dengan inefisiensi diidentifikasi oleh metrik proses software. perubahan konstan adalah norma,
bukan pengecualian.
15.4 Model Life Cycle

Gambar 15-7 menggambarkan arus informasi antara proses dalam IEEE 1074 standar. Kompleksitas standar yang
signifikan seperti dapat dilihat dalam banyak ketergantungan antar proses. Setiap asosiasi merupakan produk kerja
yang dihasilkan oleh satu proses dan dikonsumsi oleh proses lain. Setiap asosiasi juga merupakan saluran komunikasi
formal antara peserta proyek yang didukung oleh pertukaran dokumen, model, atau kode.

proses pembangunan proses manajemen proses Integral

Proses

sistem Alokasi

Proses

Persyaratan
Proses Pengelolaan
Proses Proses

Eksplorasi

Penerapan
Monitoring Proyek Pengembangan
Proses & Pr o s e s Ctrl dokumentasi
P r o y ek
Proses

Instalasi
Proses
proses Konsep

Proses Operasi &

Dukungan S / W Manajemen
Proses
Mutu
pelatihan
Proses Inisiasi

Pemeliharaan
Proses Desain Verifikasi & Validasi

Konfigurasi proses

pengunduran diri
Proses

Gambar 15-7 Proses hubungan timbal balik dalam IEEE 1074 standar (diagram aktivitas UML, diadaptasi dari [IEEE Std. 1074-2006]).
Seperti yang disarankan oleh gambar ini, ketergantungan antar proses dan kegiatan yang kompleks dan jarang memungkinkan
eksekusi berurutan proses.
Model Life Cycle
6

Dalam bagian ini kita meninjau beberapa model siklus hidup. Sebagian besar dari model ini fokus pada proses pembangunan

secara eksklusif.

Model 15.4.1 Sequential Kegiatan-Centered

Kita mulai dengan model siklus hidup kegiatan-berpusat. Model siklus hidup perangkat lunak tertua adalah model air
terjun, yang mengatur eksekusi berurutan dari kegiatan. Itu V- Model adalah variasi dari model air terjun yang
memperkenalkan berbagai tingkat abstraksi untuk kegiatan.

model air terjun

Itu Waterfall Model, pertama dijelaskan oleh Royce [Royce, 1970], adalah kehidupan model siklus aktivitas yang berpusat yang

diresepkan eksekusi berurutan dari himpunan bagian dari proses pembangunan dan proses manajemen yang diuraikan pada bagian

sebelumnya (Gambar 15-8).

Inisiasi proyek
Proses

konsep Eksplorasi
Proses

Proses
Sistem Alokasi
Persyaratan
Proses

Proses desain

Penerapan
Proses

Verifikasi & Validasi

Proses

Instalasi
Proses

Proses Operasi & Dukungan

Gambar 15-8 Model air terjun dari pengembangan perangkat lunak adalah pandangan aktivitas yang berpusat pada siklus hidup perangkat lunak. kegiatan

pengembangan perangkat lunak dilakukan secara berurutan (aktivitas UML diagram diadaptasi dari [Royce, 1970] menggunakan IEEE 1074 nama; proses
manajemen proyek dan lintas-pengembangan dihilangkan).