Design By Komite

Oleh chmood

Jumat, Januari 08, 2016

     Antipattern Nama: Desain oleh Komite
     Disebut Juga Sebagai: Gold Plating, Standar Penyakit, Membuat Semua Happy, Partai Politik
     Kebanyakan Skala Sering: global
     Refactored Nama Solusi: Rapat Fasilitasi
     Refactored Solusi Jenis: Proses
     Penyebab root: Pride, Ketamakan

Angkatan seimbang: Pengelolaan Fungsi, Kompleksitas, dan Sumber Daya
Anekdot Bukti: "A unta adalah kuda yang dirancang oleh sebuah komite." "Terlalu banyak koki merusak kaldu."

Latar belakang
Orientasi objek sering digambarkan sebagai teknologi dua generasi. Analisis objek data-centric adalah karakteristik dari generasi pertama, dan pola desain merupakan karakteristik kedua.

Generasi pertama dianut filosofi bahwa "benda adalah hal yang dapat menyentuh." Konsekuensi dari ini adalah bahwa hampir semua desain yang unik vertikal. Pada generasi pertama, orang percaya sejumlah asumsi yang tidak berdasar oleh praktek.

Salah satunya adalah bahwa tim proyek harus egaliter; dengan kata lain, setiap orang yang harus memiliki suara yang sama dan bahwa keputusan yang demokratis. Hal ini menyebabkan Desain oleh Komite. Mengingat bahwa hanya sejumlah kecil dari pengembang objek dapat menentukan abstraksi yang baik, aturan mayoritas selalu menyebabkan difusi abstraksi dan kompleksitas berlebih.

Bentuk umum
Sebuah desain software yang kompleks adalah produk dari proses komite. Ini memiliki begitu banyak fitur dan variasi yang sangat tidak layak untuk setiap kelompok pengembang untuk mewujudkan spesifikasi dalam kerangka waktu yang wajar.

Bahkan jika desain itu mungkin, itu tidak akan mungkin untuk menguji desain penuh karena kompleksitas yang berlebihan, ambiguitas, lebih kendala, dan cacat spesifikasi lainnya. Desain akan kekurangan kejelasan konseptual karena begitu banyak orang berkontribusi untuk itu dan diperpanjang selama penciptaannya.

Gejala Dan Konsekuensi Dokumentasi desain terlalu rumit, tidak terbaca, tidak koheren, atau berlebihan rusak. Dokumentasi desain tebal (ratusan atau ribuan halaman). Konvergensi dan stabilitas yang hilang dari persyaratan dan desain. Pertemuan Komite menyerupai sesi banteng selama isu-isu substantif yang jarang dibahas dan kemajuan susah payah lambat. Orang berbicara dan bekerja secara serial; yaitu, ada satu benang diskusi, dan kebanyakan orang tidak produktif sebagian besar waktu.

Lingkungan adalah politik berubah, dan beberapa keputusan dan tindakan dapat dilakukan di luar rapat; dan proses pertemuan menghalangi mencapai keputusan yang tepat waktu. Tidak ada prioritas dari fitur desain, dan tidak ada jawaban siap untuk pertanyaan: Fitur apa yang tidak penting? Fitur yang akan dilaksanakan dalam pengiriman awal? Arsitek dan pengembang memiliki interpretasi yang saling bertentangan dari desain. Pengembangan desain menjadi signifikan selama-anggaran dan

terlambat. Menjadi perlu untuk mempekerjakan spesialis untuk menafsirkan, mengembangkan, dan mengelola spesifikasi. Dengan kata lain, berhadapan dengan spesifikasi masing-masing yang dirancang oleh panitia menjadi pekerjaan penuh waktu.

Penyebab khas ada yang ditunjuk arsitek proyek. Sebuah merosot atau proses perangkat lunak tidak efektif. Proses pertemuan yang buruk, ditandai dengan kurangnya fasilitasi atau fasilitasi tidak efektif. Pertemuan adalah sesi bull; orang-orang paling keras menang dan tingkat wacana adalah common denominator terendah kecanggihan. Emas plating-yaitu, fitur ditambahkan dengan spesifikasi berdasarkan kepentingan proprietary. Hal ini dapat terjadi karena berbagai alasan: jual, keberadaan teknologi proprietary sudah mengandung fitur ini, atau penempatan spekulatif fitur dalam spesifikasi potensi pekerjaan di masa depan. Usaha untuk membuat semua orang senang, untuk memuaskan semua peserta panitia dengan memasukkan ide-ide mereka. Sayangnya, tidak mungkin untuk menerima setiap ide dan masih mengelola kompleksitas. Desain dan editing dicoba selama pertemuan dengan lebih dari lima orang. Prioritas eksplisit dan sistem software-nilai yang ditentukan Kekhawatiran tidak dipisahkan, dan model referensi tidak digunakan.

Dikenal Pengecualian
Ada beberapa pengecualian untuk Desain oleh Komite antipattern, dan mereka terjadi ketika panitia kecil: sekitar 6 sampai 10 orang; lebih dari itu dan konsensus menjadi mungkin; kurang dari enam orang dan luasnya pemahaman dan pengalaman menjadi cukup.
Juga, komite harus sering menjadi tim harimau, sekelompok kecil "ahli" dalam domain masalah tertentu, yang diselenggarakan selama solusi untuk masalah atau isu tertentu.

Solusi refactored
Inti dari solusi untuk Desain oleh Komite untuk mereformasi proses pertemuan. Ini adil untuk mengatakan bahwa kebanyakan orang terbiasa abadi pertemuan buruk, sebagian besar waktu.
Jadi, bahkan perubahan sederhana dalam proses pertemuan dapat menghasilkan peningkatan produktivitas yang cukup besar. Dengan peningkatan produktivitas, ada kesempatan untuk meningkatkan kualitas dan solusi yang lebih canggih. Keuntungan khas untuk optimasi perangkat lunak kurang dari urutan besarnya (2 sampai 10 kali). Keuntungan memenuhi produktivitas jauh lebih dramatis, dengan beberapa kali lipat khas (100 kali), dan kita telah melihat peningkatan produktivitas lebih dari 100.000: 1.

Pertama, sebagian besar ruang pertemuan tidak memiliki jam di dinding, terutama di fasilitas hotel. Kesadaran Waktu adalah penting untuk memenuhi kemajuan. Peserta harus dilatih untuk mengelola waktu yang diberikan secara efisien; peserta harus mulai komentar mereka dengan "25-kata-atau-kurang" Ringkasan, dan menambahkan rincian hanya jika diminta. Posting tujuan pertemuan, agenda, dan jam di mana mereka terlihat untuk semua peserta dapat meningkatkan pertemuan secara dramatis.

Kedua, dalam semua pertemuan penting bahwa anggota kelompok menjawab dua pertanyaan: "Mengapa kita di sini?" dan "hasil Apa yang kita inginkan?" Ketika ada rencana pertemuan disiapkan, sangat penting bahwa kelompok mulai dengan dua pertanyaan ini, dan kemudian bekerja pada menghasilkan hasil yang diinginkan.

Reformasi penting lainnya adalah untuk memberikan peran eksplisit dalam proses perangkat lunak: pemilik, fasilitator, arsitek, pengembang, penguji, dan pakar domain. Pemilik adalah manajer yang bertanggung jawab untuk pengembangan perangkat lunak. Dia membuat keputusan strategis tentang proses perangkat lunak secara keseluruhan, dan undangan dan mengatur peserta.

Pada awal pertemuan, pemilik proses menetapkan tujuan dan menetapkan harapan mengenai penanganan hasil. Misalnya, keputusan yang dibuat pada pertemuan tersebut dapat dianggap hanya sebagai saran atau dilaksanakan persis seperti yang dibahas.

Fasilitator bertugas menjalankan pertemuan. Dia bertanggung jawab untuk proses; peserta lain yang bertanggung jawab atas konten teknis. Fasilitator ternyata pemilik proses jika ada keputusan penting yang harus dibuat mengenai proses.

Arsitek adalah memimpin teknis senior untuk proyek software. Dia mengontrol pengeditan dokumentasi arsitektur, dan mungkin bertanggung jawab atas kunci, batas sistem-tingkat, seperti antarmuka program aplikasi subsistem.

Setiap pengembang biasanya bertanggung jawab untuk subsistem tunggal dan unit testing. Penguji bertanggung jawab untuk spesifikasi pemantauan kualitas dan pengujian nilai tambah seperti integrasi, portabilitas, dan tes stres. Para ahli domain masukan persyaratan utama untuk proses, tetapi mungkin tidak terlibat dalam semua aspek pembangunan.

Ada tiga kategori dari proses pertemuan: divergen, konvergen, dan berbagi informasi. Dalam proses divergen, ide-ide yang dihasilkan untuk pemanfaatan kemudian. Dalam proses konvergen, pilihan atau keputusan yang dibuat yang mewakili konsensus. Berbagi informasi dapat melibatkan presentasi, mengajar, menulis, dan ulasan.

Jumlah orang yang terlibat dalam setiap proses pertemuan dikelola oleh fasilitator. Proses kreatif yang memerlukan menulis, menyoroti, atau gambar harus dibatasi untuk pelarian tim dari lima orang atau lebih sedikit.

Kelompok yang lebih besar dari lima kurang efektif membuat kemajuan dalam tugas-tugas kreatif, meskipun mereka berhasil meninjau dan mengintegrasikan hasil setelah proses kreatif. Sangat pertemuan produktif melibatkan banyak proses paralel, dan iterasi sering pelarian dan review kelompok. Mendorong orang untuk membuat perubahan paradigma antara diskusi single-threaded dan bekerja paralel merupakan tantangan utama bagi fasilitator.

Tujuan utama dari sebagian besar pertemuan adalah pemecahan masalah. Sebuah pendekatan pemecahan masalah umum dimulai dengan proses konvergen: Masalahnya didefinisikan dan scoped untuk kelompok untuk menyelesaikan

.

Sebuah proses yang berbeda digunakan untuk mengidentifikasi solusi alternatif. Berbagi informasi mungkin diperlukan untuk mengeksplorasi rincian dan konsekuensi dari alternatif yang dipilih. Akhirnya, proses konvergen digunakan untuk memilih di antara pilihan.

Satu proses pertemuan yang sangat efektif disebut Spitwads Ini adalah prosedur umum-tujuan yang telah kita gunakan pada banyak kesempatan dengan hasil yang sangat baik. Mengajukan pertanyaan. Fasilitator menimbulkan pertanyaan bagi kelompok untuk melakukan brainstorming.

Pertanyaan tersebut diturunkan pada viewgraph atau flipchart) untuk menghindari kesalahpahaman. Kelompok ini ditanya apakah ada perubahan disarankan untuk pertanyaan sebelum brainstorming dimulai. Pertanyaan yang khas adalah: "Apa cara yang bisa kita meningkatkan kinerja sistem?" dan "Apa persyaratan yang paling penting yang belum dibahas?" Menulis diam-diam. Para peserta menulis tanggapan pada slip identik kertas.

Setiap respon ditulis pada selembar kertas terpisah, dan terbatas pada frasa singkat. Melemparkan spitwads. Sebagai peserta menyelesaikan setiap ide, fasilitator menginstruksikan mereka untuk wad kertas itu dan melemparkannya ke seberang ruangan menjadi wadah-kotak kardus atau keranjang yang terbaik. Hal ini dilakukan gaya basket, dan fasilitator mendorong peserta untuk bersenang-senang dengan latihan ini. Melakukan apel Spitwad. The "spitwads" didistribusikan secara acak kembali ke peserta, yang satu per satu membaca ide-ide keras untuk dicatat di atas kertas. Dua perekam flipchart dapat digunakan secara bersamaan untuk mempercepat proses. Flipchart yang diposting di dinding untuk semua peserta untuk melihat.

Mencapai pemahaman bersama. Ide-ide pada flipchart diberi nomor. Fasilitator kemudian meminta kelompok jika ada ide-ide yang mereka tidak mengerti. Jika demikian, anggota kelompok didorong untuk menawarkan definisi. Jika ide tidak dapat didefinisikan, adalah aman untuk menghilangkannya. Menghilangkan duplikasi. Fasilitator meminta kelompok untuk mengidentifikasi ide-ide yang duplikat atau yang harus dikombinasikan. Peserta mengidentifikasi ide-ide dengan nomor untuk menyarankan perubahan. Jika ada keberatan, perubahan ditolak. (Ini adalah pendekatan fasilitasi umum untuk editing: Jika ada keberatan terhadap perubahan yang diusulkan, maka perubahan itu tidak diterima.) Memprioritaskan. Kelompok ini diarahkan untuk diam-diam memilih ide-ide terbaik dalam daftar dengan nomor

Mereka dapat memilih lebih dari satu. Fasilitator berjalan melalui daftar tabulasi suara (mengangkat tangan, tidak ada diskusi). Membahas. Latihan selesai. Kelompok ini membahas pilihan prioritas tertinggi dan menyarankan apa tindak lanjut akan.

Variasi
The Railroad (juga dikenal sebagai Karet Stamp) antipattern adalah variasi dari Desain oleh Komite, dimana koalisi politik mendominasi proses dan memaksa adopsi desain dengan cacat serius. Railroad sering dimotivasi oleh kepentingan bisnis yang saling menguntungkan dari banyak anggota komite. Dengan mengadopsi spesifikasi lengkap dan cacat, rincian teknologi dapat disembunyikan secara efektif dalam perangkat lunak.
Dengan cara ini, perangkat lunak dari pengembang koalisi menjadi standar de facto, yang bertentangan dengan spesifikasi tertulis. Beberapa pengembang luar koalisi bahkan akan mencoba untuk menerapkan "misfeatures," sehingga waktu yang terbuang dan uang.\

Contoh
   Dua contoh klasik Desain oleh Komite berasal dari domain software standarisasi: Structured Query Language (SQL) dan Object Request Broker Architecture Umum (CORBA).
Sql

   Structured Query Language (SQL) menjadi standar internasional di tahun 1989. aslinya, SQL89, adalah kecil dokumen-115 halaman-yang mewakili efisien, desain minimal untuk teknologi Hampir semua produk database relasional menerapkan spesifikasi lengkap.

   Pada tahun 1992, versi kedua dari SQL adalah standar dengan ekstensi signifikan yang mengakibatkan dokumen 580-halaman. The SQL92 spesifikasi dilaksanakan dengan dialek yang unik di setiap produk; Beberapa produk menerapkan seluruh spesifikasi. Versi berikutnya dari SQL, yang disebut SQL3, mungkin menjadi ribuan halaman panjang.

   Komite standar yang bertanggung jawab untuk desain adalah menambahkan hamparan fitur baru yang memperpanjang konsep melampaui maksud asli. Beberapa fitur baru termasuk ekstensi objek-orientasi, ekstensi geospasial, dan ekstensi temporal-logika.

   Ini tidak mungkin bahwa setiap produk akan pernah sepenuhnya melaksanakan SQL3, juga tidak mungkin bahwa dua produk akan melaksanakan bagian yang sama dengan cara yang portabel. Desain klasik ini dengan Komite, standar SQL telah menjadi tempat pembuangan untuk fitur database canggih.

Sebuah solusi menarik untuk masalah SQL konvergensi disajikan oleh teknologi: Open Database Connectivity (ODBC) dan Java Database Connectivity (JDBC). Setiap mendefinisikan program aplikasi antarmuka standar untuk akses database berdasarkan permintaan dinamis, pernyataan permintaan yang diajukan dan diurai pada waktu berjalan.

Karena ODBC dan JDBC menentukan interface query dan bahasa query untuk klien, mereka menyediakan isolasi dari database fitur khusus produk. Klien dapat mengakses beberapa produk database transparan. ODBC menjadi standar industri melalui SQL Access Group (SAG), sebuah konsorsium industri perangkat lunak.

Microsoft mengembangkan spesifikasi ODBC independen dari SAG, dan kemudian diusulkan kepada kelompok. Spesifikasi diadopsi dengan cepat oleh SAG dan menjadi standar industri de facto. Vendor yang mempromosikan solusi proprietary telah mengalami kesulitan mengganti teknologi yang sangat efektif, yang universal didukung oleh vendor database dan pengembang alat basis data.
Corba

Objek Permintaan Umum Broker Architecture (CORBA) standar diadopsi oleh industri pada tahun 1991. Dokumen-kurang dari 200 halaman asli-itu mudah dibaca oleh pihak luar ke Management Group (OMG) proses Obyek. Pada tahun 1995, sebuah CORBA2 spesifikasi direvisi dirilis, dengan upgrade yang signifikan dan ekstensi, termasuk C ++ dan pemetaan Smalltalk, Repositori Interface, dan Internet Inter-ORB Protocol (IIOP).

C ++ pemetaan di CORBA2, khususnya, terdapat detail yang rumit sehingga tidak dapat diterapkan secara konsisten oleh Object Request Broker (ORB) vendor, beberapa di antaranya mengubah API yang dihasilkan oleh mereka IDL / C ++ compiler berulang kali. Object Basic Adapter (BOA) telah secara substansial direvisi di CORBA2.

Sebuah penggantian ini bagian dari CORBA, yang disebut Portable Object Adapter (POA), diadopsi pada tahun 1997. Sejak fungsi duplikat POA BOA sudah dalam produk bekerja, vendor yang sukses mungkin memiliki sedikit motivasi untuk meng-upgrade produk mereka. Dan karena semua perhatian ini pada infrastruktur dasar, beberapa kebutuhan yang lebih penting dari pengguna dialokasikan prioritas yang lebih rendah.

Proses alternatif yang digunakan oleh OMG untuk mengidentifikasi dan menentukan teknologi untuk diadopsi digunakan oleh OMG untuk menghasilkan CORBAfacilities Arsitektur. Proses ini digunakan kembali oleh gugus tugas lain dan perusahaan pengguna akhir untuk menentukan arsitektur mereka dan peta jalan. Para penulis menyebut ini "Lost Proses Arsitektur" karena itu tidak tercatat (sampai sekarang).

The Lost Arsitektur Proses adalah prosedur arsitektur-definition difasilitasi yang memerlukan langkah-langkah berikut. Ini mungkin disesuaikan dengan kebutuhan perusahaan tertentu, dengan mengganti proses OMG dengan proses organisasi-spesifik, seperti survei internal dan off-site workshop. Merilis permintaan informasi (RFI). Tujuan dari RFI adalah untuk survei pihak yang berkepentingan baik di dalam dan luar OMG. Pihak yang berkepentingan dari setiap organisasi diminta untuk menyerahkan

persyaratan mereka, masukan arsitektur, dan deskripsi dari teknologi yang relevan untuk membantu dalam proses perencanaan. Tinjau tanggapan RFI. Setiap tanggapan diterima (biasanya belasan atau kurang) ditinjau oleh gugus tugas. Ini melengkapi survei dan pengumpulan data tahap proses. Setelah satgas telah mengkaji masukan ini, itu menjadi tanggung jawab dari orang-orang di ruang untuk mendefinisikan arsitektur. Proses RFI merupakan langkah penting secara psikologis, karena mengubah set terdefinisi pemangku kepentingan dan kebutuhan implisit menjadi tanggung jawab peserta rapat untuk menentukan arsitektur dan menggambar peta jalan. Mengidentifikasi layanan kandidat dan fasilitas

. Layanan kandidat terdaftar di flipchart dan diposting di ruang pertemuan bagi peserta untuk meninjau. Daftar ini dapat dimulai selama proses RFI, dan sesi curah pendapat dapat memperpanjang daftar ini dengan fasilitas tambahan. Hal ini penting untuk meminta semua ide, kemudian menyisihkan daftar, menonton duplikat dan layanan yang tumpang tindih. Meluncurkan proses RFP awal.

Mungkin, setidaknya salah satu layanan yang diidentifikasi akan menjadi calon yang jelas untuk rilis RFP. Hal ini sangat mungkin bahwa beberapa tim vendor menghadiri pertemuan dengan tujuan mengadopsi teknologi tertentu. Tim ini bisa menembus bekerja pada RFP awal dan memulai proses adopsi gugus tugas. Layanan dan fasilitas lainnya akan ditentukan pada keseimbangan proses. Diagram arsitektur. Sekelompok kecil breakout mengatur daftar layanan ke dalam kategori, dalam bentuk diagram blok yang menunjukkan lapisan layanan dan penggambaran horisontal. Jelas, kelompok ini membutuhkan setidaknya satu orang yang ahli dalam model referensi teknik diagram. Diagram referensi arsitektur ini adalah abstraksi yang berguna dari layanan yang tercantum, dan akan menjadi gambaran penting dalam dokumen arsitektur.

Semua layanan dan fasilitas yang tercantum dalam diagram. Mendefinisikan layanan awal. Kelompok parsel keluar layanan yang akan didefinisikan dalam hal sejumlah peluru viewgraph. Orang bertemu dalam kelompok kecil atau bekerja secara individu untuk menentukan layanan dalam bentuk ini. Hasilnya Ulasan dan dibahas oleh seluruh satuan tugas, di mana penambahan dan pengeditan frase bullet dianjurkan dan dibahas. Menulis definisi layanan. Menggunakan bagian isi template RFP, masing-masing layanan diidentifikasi ditulis up.

Tugas menulis yang bekerja di dalam antara pertemuan. Pada titik ini, editor dokumen arsitektur (hanya satu orang yang terbaik) harus ditunjuk untuk menerima masukan dan membuat dokumen rancangan. Draft dokumen. Editor dokumen merakit definisi layanan disampaikan dan diagram arsitektur ke dalam dokumen rancangan. Editor dapat menambahkan deskripsi boilerplate dari keseluruhan arsitektur sehingga dokumen dapat berdiri sendiri. Sebuah meja layanan dan kategori layanan juga termasuk dalam dokumen untuk merangkum dan abstrak isi definisi layanan. Tinjau proses. Draft terbaru dari dokumen arsitektur ditinjau pada setiap pertemuan. Perubahan editorial yang diusulkan dan dibahas untuk revisi berikutnya.

Setiap bagian yang hilang atau layanan write-up yang ditugaskan kepada anggota kelompok untuk bekerja independen dan penggabungan oleh editor. Mendefinisikan peta jalan. Peta jalan adalah profil dari arsitektur yang berfokus pada prioritas dan jadwal. Beberapa kriteria utama menetapkan prioritas dan menentukan jadwal. Ini termasuk kebutuhan industri untuk teknologi, ketergantungan antara teknologi, luasnya penerapan teknologi, dan beban kerja gugus tugas.

Definisi peta jalan adalah bagian penting dari proses yang memungkinkan kelompok-kelompok anggota untuk mengatur sumber daya dan penelitian rencana yang relevan dengan proses adopsi. Melakukan proses persetujuan. Setelah beberapa iterasi dari proses review, gerak dibuat untuk melepaskan arsitektur dan peta jalan sebagai versi 1.0. Revisi lebih lanjut dapat terjadi setelah versi 1.0 dirilis; Namun, bagian dari gerakan ini menunjukkan bahwa satgas telah mencapai konsensus tentang arsitektur awal.

Solusi terkait, Pola, dan antipatterns
Kyle Brown membukukan versi Desain dengan Komite antipattern dari Portland Pola situs Repository Pola itu menggunakan template yang berbeda, yang berfokus sepenuhnya pada menjelaskan solusi bermasalah dan bukan pada solusi refactored. Sebaliknya, buku ini mencakup solusi refactored dengan masing-masing antipattern, mencatat bahwa Socrates dihukum mati untuk mengekspos kontradiksi masyarakat tanpa menawarkan saran konstruktif.
Penerapan untuk Pandangan dan Timbangan Lainnya

    Dampak dari Desain oleh Komite antipattern pada pengembang adalah bahwa mereka diharapkan untuk menerapkan desain yang sangat kompleks dan ambigu, yang merupakan situasi stres. Mereka mungkin merasa perlu untuk diam-diam menumbangkan tuntutan panitia dengan pendekatan desain yang lebih realistis.

    Manajer menderita antipattern ini melalui peningkatan dramatis dalam risiko proyek yang disebabkan oleh kompleksitas yang berlebihan. Sejalan dengan itu, jadwal dan anggaran proyek cenderung meningkat secara dramatis sebagai konsekuensi dari desain yang ditemukan di laboratorium.
Pada tingkat sistem, mungkin masuk akal untuk memberikan sistem berbasis pada Desain oleh spesifikasi Komite, jika tidak ada variasi (beberapa konfigurasi) yang diperlukan dan jadwal pelaksanaan yang diusulkan diperpanjang oleh 30 persen atau lebih. Kebanyakan pengembang dapat mengatur hanya beberapa variasi, dalam platform, database, dan set fitur.”

Category

Pemograman

Komentar

Postingan Lebih Baru Postingan Lama