Halo para Penduduk! Beberapa buku tentang manajemen proyek sama pentingnya dengan The Mythical Man-Month. Campuran dari contoh pengembangan perangkat lunak nyata, opini dan pemikiran menciptakan gambaran yang jelas tentang pengelolaan proyek yang kompleks. Esai-esai ini mengacu pada pengalaman lima puluh tahun Brooks sebagai manajer proyek di IBM System / 360 dan kemudian OS / 360. Edisi pertama buku itu diterbitkan 45 tahun lalu, yang kedua 25 tahun lalu. Metodologi baru bermunculan, bahasa pemrograman baru bermunculan, jumlah prosesor bertambah, tetapi buku ini terus relevan. Mengapa? Setengah abad kemudian, kami terus mengulangi kesalahan yang dijelaskan Brooks. Beberapa topik yang dibahas dalam buku ini terkesan ketinggalan jaman, namun ini hanya penampakan. Masalah mendasar di baliknya masih relevan hingga saat ini. Penting untuk mengetahui masa lalu Anda untuk memahamitempat industri pengembangan perangkat lunak berkembang. Oleh karena itu, setelah 45 tahun kami membaca Brooks Banyak yang telah berubah di dunia, tetapi sembilan wanita masih tidak dapat melahirkan bayi dalam satu bulan.
. ,
. , , , …
, , , , .
, ', , , . .
Sebagian besar katedral Eropa dibangun secara bertahap, dan bagian-bagian yang dibangun oleh pembangun dari generasi yang berbeda berbeda dalam hal gaya arsitektur. Pembangun berikutnya tergoda untuk "menyempurnakan" desain yang sebelumnya, dipandu oleh perubahan "mode" arsitektural dan selera pribadi. Oleh karena itu, transept Norman * yang damai berbatasan dan bertentangan dengan nave Gotik yang menjulang tinggi, dan hasilnya adalah memuji kemuliaan Tuhan seperti halnya pada kebanggaan para pembangun.
Dengan latar belakang mereka, kesatuan arsitektural Reims sangat kontras. Kegembiraan yang menggairahkan pemirsa berasal dari integritas desain dan dari manfaat individu mana pun. Sebagaimana dinyatakan dalam panduan, integritas ini dicapai dengan penyangkalan diri dari delapan generasi pembangun, yang masing-masing mengorbankan sebagian ide mereka demi kemurnian desain secara keseluruhan. Hasilnya tidak hanya memberitakan kemuliaan Tuhan, tetapi juga kuasa-Nya untuk menyelamatkan orang-orang berdosa dari kesombongan mereka.
Meskipun kebanyakan sistem pemrograman tidak membutuhkan waktu berabad-abad untuk dibangun, mereka menunjukkan perpecahan konseptual yang jauh lebih buruk daripada katedral. Ini biasanya terjadi bukan karena pergantian desainer, tetapi karena pembagian proyek menjadi banyak tugas yang dilakukan oleh banyak orang.
Saya bersikeras bahwa integritas konseptual adalah pertimbangan terpenting dalam desain sistem. Lebih baik memiliki sistem yang tidak memiliki beberapa fitur dan peningkatan, tetapi mencerminkan sekumpulan ide desain, daripada memiliki sistem yang berisi banyak ide yang baik tetapi independen dan tidak konsisten. Dalam bab ini dan dua berikutnya kita akan melihat implikasi dari topik ini untuk desain sistem pemrograman:
- Bagaimana mencapai integritas konseptual?
- Bukankah argumen ini membenarkan elitisme atau aristokrasi arsitek di depan gerombolan pelaksana kampungan, yang bakat dan gagasan kreatifnya ditekan?
- Bagaimana cara menjaga arsitek agar tidak tersesat dengan spesifikasi yang tidak diterapkan atau mahal?
- Bagaimana cara memastikan bahwa setiap detail kecil dari spesifikasi arsitektural dibawa ke perhatian pelaksana, dipahami dengan benar dan akurat yang tertanam dalam produk?
Mencapai integritas konseptual
Tujuan dari sistem pemrograman adalah membuat komputer mudah digunakan. Untuk melakukan ini, ia menyediakan bahasa dan berbagai alat pendukung, yang sebenarnya merupakan program yang dipanggil dan didorong oleh kemampuan bahasa. Tetapi alat-alat ini ada harganya: deskripsi eksternal dari sistem pemrograman 10-20 kali lebih besar daripada deskripsi eksternal dari sistem komputer itu sendiri. Jauh lebih mudah bagi pengguna untuk mengatur fungsi tunggal apa pun, tetapi pilihan mereka sangat luas, dan ada lebih banyak opsi dan format yang perlu diingat.
Penggunaan hanya disederhanakan jika waktu yang diperoleh dalam spesifikasi fungsional lebih besar daripada waktu yang hilang dalam mengasimilasi, menghafal, dan mencari buku panduan referensi. Dalam sistem pemrograman modern, keuntungan ini melebihi biaya, tetapi dalam beberapa tahun terakhir, rasio keuntungan terhadap biaya tampaknya telah turun karena fitur yang semakin kompleks ditambahkan. Saya dihantui oleh ingatan akan kemudahan penggunaan IBM 650, bahkan tanpa bahasa assembly atau perangkat lunak lain sama sekali.
Karena kemudahan penggunaan adalah tujuannya, hubungan fungsionalitas dengan integritas konseptual ini merupakan ujian akhir dari desain sistem. Fungsionalitas dan kesederhanaan saja tidak menentukan desain yang baik.
Tesis ini disalahpahami secara luas. Sistem operasi OS / 360 dipuji oleh penciptanya sebagai yang terbaik yang pernah dirancang karena tidak dapat disangkal lagi yang paling fungsional. Fungsionalitas, bukan kesederhanaan, yang selalu menjadi ukuran keunggulan bagi para desainernya. Di sisi lain, sistem pembagian waktu PDP-10 dipuji oleh penciptanya sebagai yang terbaik karena kesederhanaan dan pengekangan konsep. Namun, dengan ukuran apa pun, fungsinya bahkan tidak termasuk dalam kelas yang sama dengan OS / 360. Setelah kemudahan penggunaan diambil sebagai kriteria, masing-masing pendekatan ini menjadi tidak seimbang, hanya setengah jalan menuju tujuan.
Namun, untuk tingkat fungsionalitas tertentu, sistem terbaik adalah sistem di mana hal-hal dapat ditentukan dengan kesederhanaan dan keterusterangan terbesar. Kesederhanaan saja tidak cukup. Bahasa TRAC Mooers dan Algol 68 mencapai kesederhanaan, diukur dengan jumlah konsep dasar yang berbeda. Kedekatan, bagaimanapun, bukanlah karakteristik dari mereka. Mengekspresikan niat Anda sering kali membutuhkan penggabungan alat dasar dengan cara yang kompleks dan tidak terduga. Tidaklah cukup mempelajari elemen dan aturan untuk kombinasinya; juga perlu mempelajari penggunaan idiomatik, untuk mengasimilasi seluruh tubuh pengetahuan tentang bagaimana elemen-elemen digabungkan dalam kenyataan. Kesederhanaan dan keterusterangan berasal dari integritas konseptual. Setiap karya harus mencerminkan filosofi yang sama dan tindakan penyeimbangan yang sama.Setiap bagian harus menggunakan teknik yang sama dalam sintaksis dan konsep serupa dalam semantik. Dengan demikian, kemudahan penggunaan menentukan kesatuan desain, integritas konseptual.
Aristokrasi dan Demokrasi
Integritas konseptual, pada gilirannya, mensyaratkan bahwa proyek tersebut berasal dari satu pengembang, atau sebagian kecil dari mereka, yang bertindak bersama dan serempak.
Tekanan jadwal, pada gilirannya, membutuhkan keterlibatan lebih banyak pekerja. Ada dua metode untuk mengatasi masalah ini. Yang pertama adalah pembagian kerja yang cermat antara arsitektur dan implementasi. Yang kedua adalah cara baru penataan instruksi implementasi pemrograman, yang dibahas pada bab sebelumnya.
Memisahkan upaya arsitektural dari implementasi adalah cara yang ampuh untuk mencapai integritas konseptual dalam proyek besar. Saya sendiri telah melihatnya digunakan dengan sangat sukses pada lini produk komputer IBM Stretch dan System / 360. Dan saya menyaksikan bagaimana itu tidak berhasil dalam pengembangan Sistem Operasi / 360 karena tidak cukup digunakan.
Yang saya maksud dengan arsitektur sistem adalah spesifikasi antarmuka pengguna yang lengkap dan terperinci. Untuk komputer, hal itu diwujudkan dalam manual referensi pemrograman. Untuk penyusun - dalam manual referensi bahasa. Untuk program kontrol, buku petunjuk untuk bahasa atau bahasa yang digunakan untuk memanggil fungsinya. Untuk keseluruhan sistem, ini adalah kumpulan panduan referensi untuk membantu pengguna mencapai tujuan mereka.
Arsitek sistem, seperti arsitek bangunan, adalah agen pengguna. Tanggung jawabnya mencakup penggunaan pengetahuan profesional dan teknis untuk kepentingan konsumen, dan bukan untuk kepentingan penjual, pabrikan, dll.
Arsitektur harus dibedakan dengan jelas dari penerapannya. Seperti yang dikatakan Blaauw, "Di mana arsitektur berbicara tentang apa yang terjadi, implementasi berbicara tentang bagaimana hal itu dilakukan untuk mewujudkannya." Sebagai contoh sederhana, ia mencontohkan jam tangan yang arsitekturnya terdiri dari dial, tangan dan mahkota. Ketika seorang anak mempelajari arsitektur ini, dia akan dapat mengetahui waktu dengan mudah yang sama baik dengan arlojinya maupun dengan jam di menara gereja. Implementasi dan implementasinya menggambarkan apa yang terjadi secara internal: pengalihan upaya dan kontrol ketepatan oleh masing-masing dari banyak mekanisme.
Misalnya, di System / 360, arsitektur komputer yang terpisah diterapkan dengan sangat berbeda di masing-masing dari sembilan model. Pada gilirannya, implementasi terpisah, aliran data, memori dan kode mikro dari sistem Model 30 pada waktu yang berbeda melayani empat arsitektur yang berbeda: komputer System / 360, saluran multipleks dengan 224 sub-saluran yang independen secara logis, saluran pemilih, dan komputer 1401.
Perbedaan yang sama berlaku juga untuk sistem pemrograman. AS telah mengadopsi standar Fortran IV. Ini adalah arsitektur untuk banyak kompiler. Dalam arsitektur ini, implementasi yang berbeda dimungkinkan: teks atau compiler dalam memori, fast atau optimizing, syntactic atau ad hoc. Demikian pula, bahasa assembly atau kontrol pekerjaan memungkinkan banyak implementasi assembly atau scheduler. Sekarang kita dapat mengatasi masalah yang sangat emosional dari aristokrasi dan demokrasi. Bukankah arsitek adalah aristokrasi baru, elit intelektual, yang dibentuk untuk memberi tahu pelaksana yang malang dan tidak berotak apa yang harus dilakukan? Bukankah elit ini telah mengambil alih semua aktivitas kreatif, membuat para pelaku hanya sebagai penggerak dalam mekanisme? Tidak bisakah Anda mendapatkan produk yang lebih baikmenerapkan ide-ide bagus dari seluruh tim, mengikuti filosofi demokrasi, alih-alih membatasi pengembangan spesifikasi untuk beberapa orang terpilih?
Adapun pertanyaan terakhir, itu yang paling sederhana. Saya tidak menyarankan bahwa hanya arsitek yang memiliki ide arsitektur yang bagus. Seringkali konsep baru datang dari pelaksana atau dari pengguna. Namun, semua pengalaman saya meyakinkan saya, dan saya mencoba menunjukkan ini, bahwa integritas konseptual dari suatu sistem menentukan kemudahan penggunaannya. Fitur dan ide bagus yang tidak terintegrasi dengan konsep dasar sistem sebaiknya dikesampingkan. Jika banyak ide penting tetapi tidak kompatibel seperti itu muncul, maka keseluruhan sistem dibuang secara keseluruhan dan pekerjaan dimulai lagi pada sistem yang terintegrasi dengan konsep dasar lainnya.
Sedangkan untuk tuduhan aristokrasi, jawabannya pasti “ya” dan “tidak”. Ya, dalam artian hanya ada sedikit arsitek, produk mereka harus bertahan lebih lama daripada produk pelaksana, dan arsitek berada di pusat kekuatan yang pada akhirnya harus ia arahkan untuk kepentingan pengguna. Jika sistem ingin memiliki integritas konseptual, maka satu orang harus memimpin. Ini adalah aristokrasi yang tidak membutuhkan permintaan maaf.
Mengembangkan spesifikasi eksternal sama kreatifnya dengan penerapan desain. Ini kreativitas, hanya jenis yang berbeda. Desain implementasi yang sadar arsitektur memerlukan dan memungkinkan kreativitas desain, ide baru, dan kecemerlangan teknis sebanyak desain untuk spesifikasi eksternal. Memang, rasio biaya-terhadap-kinerja suatu produk akan sangat bergantung pada pelaksana, seperti halnya kemudahan penggunaan sangat bergantung pada arsiteknya.
Ada banyak contoh dari seni dan kerajinan yang mengarah pada keyakinan bahwa disiplin meningkatkan keahlian. Memang, pepatah artis menyatakan: "bentuk membebaskan." Struktur terburuk adalah mereka yang anggarannya terlalu besar untuk layanan yang akan dilayani. Aktivitas kreatif Bach hampir tidak tertekan oleh kebutuhan untuk menerbitkan kantata mingguan dalam bentuk terbatas. Saya yakin bahwa komputer Stretch akan memiliki arsitektur yang lebih baik jika lebih ketat; kendala anggaran dari System / 360 Model 30, menurut pendapat saya, telah bermanfaat bagi arsitektur Model 75 dalam segala hal.
Demikian pula, saya menemukan bahwa outsourcing arsitektur meningkatkan, bukannya meniadakan, gaya kreatif tim implementasi. Mereka segera fokus pada bagian tugas yang tidak dipecahkan oleh siapa pun, dan penemuan mulai mengalir seperti sungai. Dalam kelompok implementasi yang tidak dibatasi, sebagian besar pemikiran dan diskusi masuk ke solusi arsitektur, dengan tenggat waktu implementasi yang singkat.
Efek ini, yang telah saya lihat berkali-kali, dikonfirmasi oleh RW Conway, yang grupnya di Cornell membangun kompiler PL / C untuk PL / 1. Dia mencatat hal-hal berikut: "Pada akhirnya, kami memutuskan untuk menerapkan bahasa tanpa perubahan dan perbaikan, karena diskusi bahasa akan menghabiskan seluruh energi kami."
Apa yang harus dilakukan pelaksana sambil menunggu?
Memalukan untuk membuat kesalahan jutaan dolar, tapi itu sangat berkesan. Saya ingat dengan jelas pada malam kami memutuskan bagaimana mengatur penulisan sebenarnya dari spesifikasi eksternal untuk OS / 360. Manajer arsitektur dan manajer program kendali dan saya mengerjakan rencana, jadwal, dan tugas tanggung jawab.
Manajer arsitektur memiliki 10 orang berbakat. Dia berargumen bahwa mereka dapat menulis spesifikasi dan melakukannya dengan benar. Ini akan memakan waktu 10 bulan, tiga bulan lagi dari jadwal yang memungkinkan.
Manajer pelaksanaan program pengendalian berjumlah 150 orang. Ia berargumen bahwa mereka dapat menyiapkan spesifikasi dengan berkoordinasi dengan tim arsitektur; itu akan dilakukan dengan baik dan praktis, dan itu akan sesuai dengan jadwal. Selain itu, jika tim arsitektur melakukan ini, 150 orangnya akan duduk diam selama 10 bulan.
Untuk ini manajer arsitektur menjawab bahwa jika saya mengalihkan tanggung jawab kepada tim program kontrol, maka sebenarnya hasilnya akan diterima 3 bulan kemudian dan kualitasnya jauh lebih rendah. Saya serahkan tanggung jawab kepada tim pelaksana program kontrol, dan ternyata seperti yang dikatakannya. Dia benar dalam kedua kasus itu. Selain itu, kurangnya integritas konseptual membuat sistem jauh lebih mahal untuk dibangun dan diubah, dan saya memperkirakan bahwa proses debug tertunda selama satu tahun.
Tentu saja, banyak faktor yang memengaruhi keputusan yang salah ini; tetapi yang paling banyak adalah kendala waktu pada jadwal dan himbauan agar 150 pelaksana ini bekerja. Nyanyian sirene inilah, penuh dengan bahaya fana, yang sekarang akan saya tunjukkan.
Terhadap proposal bahwa tim arsitektur kecil benar-benar akan menulis semua spesifikasi eksternal untuk komputer atau sistem pemrograman, pelaksana mengajukan tiga keberatan:
- Spesifikasi akan terlalu kaya fitur dan tidak akan mencerminkan biaya praktis.
- Arsitek akan memiliki semua kesenangan kreatif dan akan melepaskan kecerdikan pelaksana.
- Banyak pemain harus duduk diam sementara spesifikasi melewati hambatan tim arsitektur.
Yang pertama adalah bahaya yang nyata, dan kita akan melihatnya di bab selanjutnya. Dua lainnya adalah ilusi, murni dan sederhana. Seperti yang kita lihat di atas, penerapan juga merupakan aktivitas kreatif tingkat pertama. Kemampuan untuk menjadi kreatif dan inventif dalam desain sedikit dibatasi oleh kebutuhan untuk bekerja dalam spesifikasi eksternal yang diberikan, dan disiplin ini bahkan dapat meningkatkan kreativitas. Ini tidak diragukan lagi benar untuk proyek secara keseluruhan.
Keberatan terakhir menyangkut waktu dan fase. Jawaban cepatnya adalah tidak mempekerjakan pelaksana sampai spesifikasi selesai. Dalam konstruksi, mereka beroperasi dengan prinsip yang sama.
Dalam bisnis sistem komputer, bagaimanapun, langkahnya lebih cepat, dan setiap orang ingin memeras jadwal sebanyak mungkin. Sejauh mana spesifikasi dan pengembangan bisa tumpang tindih?
Seperti yang ditunjukkan Blaau, keseluruhan upaya kreatif mencakup tiga fase berbeda: arsitektur, implementasi, dan implementasi. Ternyata mereka memang bisa mulai secara paralel dan berlanjut pada saat yang bersamaan.
Misalnya, dalam desain komputer, pelaksana dapat memulai segera setelah dia memiliki asumsi yang relatif tidak jelas tentang manual referensi, ide yang kurang lebih jelas tentang teknologi, dan target biaya dan kinerja yang jelas. Dia dapat merancang aliran data, urutan kontrol, konsep pengemasan mentah, dll. Dia mengembangkan atau menyesuaikan alat yang dia butuhkan, terutama sistem akuntansi, termasuk sistem otomasi desain.
Pada saat yang sama, pada tingkat implementasi, desain sirkuit, kartu, kabel, rangka, catu daya dan memori harus dibuat, diperbaiki dan didokumentasikan. Pekerjaan ini sejalan dengan arsitektur dan implementasi.
Hal yang sama berlaku untuk desain sistem pemrograman. Jauh sebelum spesifikasi eksternal diselesaikan, banyak yang harus dilakukan oleh pelaksana. Dengan beberapa penyederhanaan yang berlebihan dari fungsionalitas sistem, yang pada akhirnya akan diwujudkan dalam spesifikasi eksternal, ia dapat terus bekerja. Ini harus memiliki kriteria penargetan spasial dan temporal yang jelas. Dia harus mengetahui konfigurasi sistem tempat produknya akan dijalankan. Kemudian dia dapat mulai mendesain batasan modul, struktur tabel, perincian pass dan fase, algoritme, dan segala macam alat. Beberapa waktu juga harus dihabiskan untuk berkomunikasi dengan arsitek.
Masih banyak pekerjaan yang harus diselesaikan di tingkat implementasi. Pemrograman juga memiliki teknologi. Jika mesin tersebut baru, banyak yang harus dilakukan tentang konvensi panggilan subrutin, teknologi supervisor, algoritma pencarian dan pengurutan.
Integritas konseptual mensyaratkan bahwa sistem mencerminkan filosofi tunggal dan spesifikasi yang terlihat oleh pengguna ditulis oleh banyak orang. Namun, karena pembagian kerja yang sebenarnya ke dalam arsitektur, implementasi dan implementasi, sama sekali tidak berarti bahwa perakitan sistem yang direncanakan dengan cara ini akan memakan waktu lebih lama. Pengalaman menunjukkan kebalikannya: bahwa seluruh sistem menyatu lebih cepat dan lebih cepat serta membutuhkan lebih sedikit waktu untuk menguji. Faktanya, pembagian kerja horizontal yang meluas secara drastis dibatasi oleh pembagian kerja vertikal, dan hasilnya adalah penyederhanaan komunikasi yang radikal dan peningkatan integritas konseptual.
»Rincian lebih lanjut tentang buku dapat ditemukan di situs penerbit
» Daftar Isi
» Kutipan
Untuk Habitants diskon 25% untuk kupon - Brooks
Setelah pembayaran untuk versi kertas buku, sebuah e-book dikirim ke email.