Apa metode yang baik untuk melakukan evaluasi arsitektur ringan?

Saya akrab dengan metode evaluasi arsitektur seperti Teknik Arsitektur Tradeoff Analysis Method (ATAM) dan Metode Cost Benefit Analysis (CBAM) yang lebih berorientasi bisnis . Namun, metode ini berskala cukup besar: mereka meresepkan beberapa sesi curah pendapat, presentasi, pengembangan sejumlah skenario yang menggambarkan pengorbanan, dll. Meskipun berguna untuk proyek-proyek dengan ukuran tertentu, mereka terlalu besar untuk proyek internal atau aplikasi desktop yang biasanya dikembangkan oleh segelintir pengembang (atau kurang), yang walaupun kecil, memiliki beberapa kendala kualitas yang cukup curam (kinerja, skalabilitas, kemampuan beradaptasi).

Praktik khas yang saya gunakan di masa lalu adalah memiliki satu pengembang (atau arsitek jika tim memiliki satu) untuk membuat arsitektur umum untuk aplikasi dan kemudian mendiskusikannya di papan tulis dengan anggota tim lainnya, biasanya menggunakan beberapa notasi pseudo-UML yang mudah digambar dan dipahami. Ini biasanya mengarah pada umpan balik dan beberapa iterasi pada arsitektur. Tapi itu cenderung sedikit terlalu informal menyebabkan semua jenis asumsi dibuat yang nantinya bisa berubah menjadi keputusan yang salah.

Metode seperti ATAM biasanya memaksa semua pemangku kepentingan untuk berpikir mendalam tentang arsitektur, yang mengarah pada diskusi sampai semua orang setidaknya setuju tentang apa sebenarnya arsitektur itu .

Adakah yang punya pengalaman dengan melakukan evaluasi arsitektur ringan di muka? Jika demikian, apa praktik yang baik?

Kunci untuk evaluasi ringan adalah untuk mengevaluasi hal-hal yang tepat pada waktu yang tepat. Ada dua cara yang saya tahu untuk melakukan ini secara efektif. Dengan evaluasi berbasis skenario Anda menggunakan skenario atribut kualitas dan menggunakan case untuk mendorong evaluasi hanya berfokus pada atribut kualitas prioritas tinggi. Dengan evaluasi berbasis risiko Anda mengidentifikasi risiko dan membiarkan risiko yang diidentifikasi mendorong aktivitas desain arsitektur Anda.

Ada dua buku yang bisa saya rekomendasikan yang mengeksplorasi dua pendekatan (agak terkait) ini.

Sistem Intensif Perancangan Perangkat Lunak oleh Anthony Lattanze memperkenalkan Metodologi Desain Centric Arsitektur dan mencakup evaluasi berbasis skenario ringan. Anda dapat mengenali Lattanze dari Workshop Atribut Kualitas SEI dan ada ide-ide serupa yang terlibat.

Arsitektur Perangkat Lunak Cukup Cukup: Suatu Pendekatan Berbasis Risiko oleh George Fairbanks memperkenalkan, yah, pendekatan berbasis risiko untuk merancang dan mengevaluasi arsitektur sistem perangkat lunak. Ada juga beberapa bab gratis yang tersedia di situs webnya jika Anda menginginkan pratinjau. Meskipun prinsip-prinsip dalam buku ini segera berlaku, pendekatannya tidak datang dengan metode khusus sehingga Anda perlu menggabungkan ide-ide dari bidang lain. Saya sangat merekomendasikan pendekatan manajemen risiko berkelanjutan SEI untuk mengidentifikasi / memprioritaskan risiko.

Ide dasar di balik pendekatan ini adalah bahwa Anda mengurangi biaya evaluasi (dan desain) dengan mengevaluasi saat Anda pergi daripada menunggu sampai akhir. Meskipun ini tentu sedikit lebih berat daripada berbicara di sekitar papan tulis, itu tidak sedekat mahal seperti ATAM yang penuh sesak nafas. Dan jika Anda merasa nyaman, Anda dapat memilih praktik ceri untuk memenuhi kebutuhan spesifik Anda.

Tidak peduli pendekatan mana yang Anda gunakan untuk mendorong evaluasi, ide umumnya akan sama ...

Sebelum kamu memulai:

• Skenario atau risiko atribut kualitas, diprioritaskan (bisa bersifat informal jika hanya itu yang Anda punya)
• Definisi yang jelas untuk keputusan go / no-go (bagaimana Anda tahu arsitekturnya "cukup baik")
• Pemotongan terbaru dari deskripsi arsitektur (artefak yang Anda evaluasi)

Duduklah untuk sesi evaluasi:

• Arsitek menyajikan gambaran arsitektur
• Berjalanlah melalui suatu pandangan, tunjukkan bagaimana skenario atau risikonya terpenuhi
• Masalah dicatat untuk diperbaiki nanti
• Peran dan prosedur umum serupa dengan yang digunakan untuk inspeksi Fagan (arsitek atau penulis, moderator, perekam).
• Sesi ini dapat memakan waktu satu atau dua jam tergantung pada ukuran sistem Anda.

Setelah sesi selesai:

• Tinjau masalah yang diidentifikasi dan tentukan apakah kriteria go / no-go dipenuhi. Biasanya dibutuhkan sekitar 3 ulasan untuk menyelesaikan semuanya. Jika tidak dipenuhi, teruskan menyempurnakan dan bereksperimen (atau mengurangi risiko arsitektur).
• Ini bukan evaluasi "semua atau tidak sama sekali" - beberapa bagian arsitektur Anda mungkin "lulus" sementara yang lain masih perlu disempurnakan.

Untuk membantu Anda merasakan seperti apa pendekatan berbasis skenario itu, ada beberapa dokumentasi publik dari proyek batu penjuru yang saya kerjakan di sekolah pascasarjana. Dokumentasinya agak kasar, tetapi bisa membantu memberikan beberapa contoh pendekatan berbasis skenario dalam konteks ACDM. Kami adalah tim 5 dan membangun aplikasi berbasis web yang khas, sekitar 35 KLOC Java / GWT.

Saya suka diskusi papan tulis informal untuk memulai. Saya suka menulis hanya bagian dari aplikasi yang diperlukan hari ini dan kemudian secara bertahap membiarkan arsitektur muncul selama implementasi. Ini lebih seperti "menemukan arsitektur", daripada mencoba untuk menciptakannya sebelumnya. Pendekatan ini tidak memerlukan banyak evaluasi di muka dan itu membantu Anda tetap fokus pada apa yang penting (memberikan perangkat lunak yang berfungsi).

Tentu saja, jika persyaratan non-fungsional Anda memerlukannya (kendala memori, waktu respons, jumlah pengguna bersamaan, dll), Anda harus mempertimbangkannya saat menerapkan sistem.