Analisis Kelumpuhan

AnalisisKelumpuhan

Antipattern Nama: Analisis Kelumpuhan Disebut Juga Sebagai: Waterfall, Proses Mismatch Kebanyakan Skala Sering: Sistem Refactored Nama Solusi: Pengembangan Iteratif-Incremental Refactored Solusi Jenis: Software Penyebab root: Pride, Narrow-Mindedness Angkatan seimbang: Manajemen Kompleksitas Bukti anekdotal: "Kita harus mengulang analisis ini untuk membuatnya lebih object-oriented, dan menggunakan lebih banyak warisan untuk mendapatkan banyak penggunaan kembali." "Kami harus menyelesaikan analisis berorientasi objek, dan desain sebelum kita dapat mulai coding." "Nah, bagaimana jika pengguna ingin membuat daftar karyawan berdasarkan huruf keempat dan kelima dari nama pertama mereka dikombinasikan dengan proyek mereka dikenakan paling jam untuk antara Thanksgiving dan Memorial Day dari sebelumnya empat tahun?" "Jika Anda memperlakukan setiap objek atribut sebagai objek, Anda dapat menggunakan kembali bidang format antara kelas yang tidak berhubungan."

Latar belakang
   Analisis Kelumpuhan adalah salah satu antipatterns klasik dalam pengembangan perangkat lunak berorientasi objek. Analisis berorientasi objek difokuskan pada membusuk masalah menjadi bagian-bagian penyusunnya, tapi tidak ada metode yang jelas untuk mengidentifikasi tingkat yang tepat dari detail yang diperlukan untuk desain sistem Sering, fokusnya adalah bergeser dari membusuk ke tingkat di mana masalah dapat dengan mudah dipahami oleh desainer untuk menerapkan teknik untuk mencapai mitos "kelengkapan."

   Juga, pengembang sistem sering rela menjadi mangsa Analisis Paralysis, sebagai "desain tidak pernah gagal, hanya implementasi." Dengan memperpanjang analisis dan desain fase, mereka menghindari risiko akuntabilitas untuk hasil. Tentu saja, ini adalah strategi yang kalah, karena biasanya ada beberapa titik setelah implementasi kerja diharapkan.
Bentuk umum

   Analisis Kelumpuhan terjadi ketika tujuannya adalah untuk mencapai kesempurnaan dan kelengkapan tahap analisis. Antipattern ini ditandai dengan omset, revisi model, dan generasi model rinci yang kurang dari berguna untuk proses hilir.

   Banyak pengembang metode untuk object-oriented baru melakukan terlalu banyak muka analisis dan desain. Kadang-kadang, mereka menggunakan analisis pemodelan sebagai latihan untuk merasa nyaman dalam domain masalah. Salah satu manfaat dari metode berorientasi objek adalah mengembangkan model analisis dengan partisipasi para ahli domain. Jika tidak, itu mudah untuk terjebak dalam proses analisis ketika tujuannya adalah untuk membuat model yang komprehensif.

Analisis Kelumpuhan biasanya melibatkan asumsi terjun:

Analisis rinci dapat berhasil diselesaikan sebelum coding.
Segala sesuatu tentang masalah ini dikenal apriori.
Model analisis tidak akan diperpanjang atau ditinjau kembali selama pengembangan. Pengembangan berorientasi objek buruk cocok untuk air terjun analisis, desain, dan proses pelaksanaan. Pengembangan berorientasi objek yang efektif adalah proses bertahap selama hasil tambahan dan berulang analisis divalidasi melalui desain dan implementasi dan digunakan sebagai umpan balik dalam analisis sistem kemudian.

   Sebuah indikator kunci Analisis Kelumpuhan adalah bahwa dokumen analisis tidak lagi masuk akal untuk para ahli domain. Sebagai Analisis Kelumpuhan berlangsung, model analisis lebih sering menutupi rincian yang tidak menarik bagi para ahli domain. Sebagai contoh, model domain dari sistem perawatan kesehatan untuk rumah sakit harus dimengerti oleh administrator dan staf rumah sakit.

Jika model domain mendefinisikan konsep terduga software, kategori, dan spesialisasi, pemodelan analisis mungkin telah pergi terlalu jauh. Jika makna ini kelas baru harus dijelaskan secara rinci kepada orang-orang akrab dengan sistem saat ini, ada kemungkinan bahwa masalah telah overanalyzed.

Gejala Dan Konsekuensi

Ada beberapa restart proyek dan banyak model yang ulang, karena perubahan personil atau perubahan arah proyek.

   Masalah desain dan implementasi terus diperkenalkan kembali dalam tahap analisis.
Biaya analisis melebihi harapan tanpa titik akhir diprediksi.
Tahap analisis tidak lagi melibatkan interaksi pengguna. Banyak analisis yang dilakukan adalah spekulatif.
Kompleksitas model analisis menghasilkan implementasi yang rumit, membuat sistem sulit untuk mengembangkan, dokumen, dan tes.
Desain dan implementasi keputusan seperti yang digunakan dalam Gang pola desain Empat dibuat dalam tahap analisis.

Penyebab khas
   Proses manajemen mengasumsikan perkembangan terjun dari fase. Pada kenyataannya, hampir semua sistem yang dibangun secara bertahap bahkan jika tidak diakui dalam proses formal.
Manajemen memiliki lebih percaya diri dalam kemampuan mereka untuk menganalisis dan menguraikan masalah daripada untuk merancang dan mengimplementasikan.
Manajemen bersikeras menyelesaikan semua analisis sebelum tahap desain dimulai.
Gol dalam tahap analisis yang tidak didefinisikan dengan baik.
Perencanaan atau kepemimpinan penyimpangan ketika bergerak melewati fase analisis.
Manajemen tidak bersedia untuk membuat keputusan tegas tentang kapan bagian dari domain yang cukup dijelaskan.
Visi proyek dan fokus pada tujuan / penyampaian kepada pelanggan yang tersebar. Analisis melampaui memberikan nilai yang berarti.

Dikenal Pengecualian

Seharusnya tidak akan ada pengecualian untuk Analisis Paralysis antipattern.
Solusi refactored

Kunci keberhasilan pembangunan berorientasi obyek pembangunan inkremental. Sedangkan proses terjun mengasumsikan pengetahuan apriori dari masalah, proses pembangunan inkremental menganggap bahwa rincian dari masalah dan solusinya akan dipelajari dalam kursus dari proses pembangunan.

Dalam pembangunan inkremental, semua tahapan proses berorientasi terjadi dengan setiap iterasi-analisis, desain, coding, pengujian, dan validasi. Analisis awal terdiri review tingkat tinggi dari sistem sehingga tujuan dan fungsi umum sistem dapat divalidasi dengan pengguna. Setiap kenaikan sepenuhnya detail bagian dari sistem.

Ada dua jenis bertahap: internal dan eksternal. Kenaikan internal yang membangun perangkat lunak yang sangat penting untuk infrastruktur pelaksanaannya. Sebagai contoh, database dan data-akses lapis lapisan akan terdiri kenaikan internal. Peningkatan internal yang membangun infrastruktur umum yang digunakan oleh beberapa kasus penggunaan. Secara umum, peningkatan internal yang meminimalkan ulang. Kenaikan eksternal terdiri pengguna terlihat fungsi.

Bertahap eksternal sangat penting untuk memenangkan konsensus politik untuk proyek dengan menunjukkan kemajuan. Bertahap eksternal juga penting untuk validasi pengguna. Mereka biasanya melibatkan beberapa coding pakai untuk mensimulasikan bagian yang hilang dari infrastruktur dan back-end tingkatan. Ini hak prerogatif manajer proyek untuk memilih kenaikan yang menyeimbangkan kekuatan hidup proyek, validasi pengguna, dan biaya minimal. Lihat Project salah urus antipattern mengenai penjadwalan bertahap berkaitan dengan risiko.

Sering, saat melakukan analisis berorientasi objek, lebih mudah untuk melanjutkan analisis daripada untuk mengakhirinya dan beralih ke desain perangkat lunak. Karena banyak dari teknik analisis juga diterapkan pada tingkat tertentu untuk desain, mudah untuk menggunakan tahap analisis untuk mengarahkan spesifik dari desain secara keseluruhan.

Kadang-kadang, ini juga hasil dari pemikiran bahwa analisis minimal dibutuhkan bersamaan dengan desain, dan desain yang dapat dimulai kemudian pergi kembali ke. Biasanya, hasil ini dalam produk yang tidak menyerupai model domain pengguna dapat memahami atau desain yang diinginkan untuk sistem yang diterapkan.

Analisis Kelumpuhan juga berlaku pada tingkat arsitektur dan mengambil bentuk mirip dengan antipattern di tingkat perkembangan. Arsitektur tentu dapat ditentukan jauh melampaui apa yang diperlukan untuk pengembang untuk mematuhi prinsip-prinsip arsitektur dan konstruksi.

Misalnya, menentukan subclass dikenal dan diijinkan yang digunakan oleh sebuah konstruk arsitektur yang dirancang untuk beroperasi hanya pada antarmuka kelas dasar objek yang berlebihan. Sebaliknya, itu adalah lebih baik untuk menentukan kendala yang diperlukan di kelas dasar yang beroperasi komponen arsitektur dan kepercayaan (dan mungkin juga memverifikasi) pengembang untuk mempertahankan kendala dalam subclass mereka.

Pada tingkat manajerial, Analisis Kelumpuhan dikenal sebagai micromanagement dan terjadi ketika manajer overspecify tugas dan tugas oversupervise didelegasikan.