วิธีที่ดีในการประเมินสถาปัตยกรรมที่มีน้ำหนักเบาคืออะไร?

ฉันคุ้นเคยกับวิธีการประเมินผลสถาปัตยกรรมเช่นเทคนิควิธีสถาปัตยกรรม tradeoff วิเคราะห์ (Atam)และธุรกิจที่มุ่งเน้นมากขึ้นค่าใช้จ่ายผลประโยชน์ของวิธีการวิเคราะห์ (CBAM) อย่างไรก็ตามวิธีการเหล่านี้มีขนาดใหญ่พอสมควร: พวกเขากำหนดช่วงการระดมสมองหลายครั้งการนำเสนอการพัฒนาโฮสต์ของสถานการณ์ที่อธิบายถึงการแลกเปลี่ยน ฯลฯ ในขณะที่มีประโยชน์สำหรับโครงการที่มีขนาดที่แน่นอนพวกเขามีขนาดใหญ่เกินไปสำหรับโครงการภายใน พัฒนาโดยนักพัฒนาไม่กี่คน (หรือน้อยกว่า) แม้ว่าจะมีขนาดเล็ก แต่ก็มีข้อ จำกัด ด้านคุณภาพค่อนข้างสูง (ประสิทธิภาพ, ความสามารถในการปรับขนาด, ความสามารถในการปรับตัว)

การปฏิบัติทั่วไปที่ฉันเคยใช้ในอดีตคือการมีนักพัฒนาหนึ่งคน (หรือสถาปนิกหากทีมมีหนึ่งคน) เพื่อสร้างสถาปัตยกรรมทั่วไปสำหรับแอปพลิเคชันแล้วพูดคุยกันบนกระดานไวท์บอร์ดกับส่วนที่เหลือของทีม เครื่องหมายหลอก - UML บางอย่างที่ง่ายต่อการวาดและเข้าใจ โดยทั่วไปจะนำไปสู่ข้อเสนอแนะและการวนซ้ำในสถาปัตยกรรม แต่มันก็มีแนวโน้มที่จะไม่เป็นทางการเกินไปจนทำให้มีการตั้งสมมติฐานทุกชนิดซึ่งอาจกลายเป็นการตัดสินใจที่ผิดพลาดในภายหลัง

วิธีการเช่น Atam มักจะบังคับให้ผู้มีส่วนได้เสียทุกคนที่จะคิดอย่างลึกซึ้งเกี่ยวกับสถาปัตยกรรมซึ่งนำไปสู่การอภิปรายจนทุกคนอย่างน้อยเห็นด้วยกับสิ่งที่สถาปัตยกรรมว่าเป็น

ใครบ้างมีประสบการณ์กับการทำการประเมินสถาปัตยกรรมเบื้องหน้าบ้างไหม? ถ้าเป็นเช่นนั้นการปฏิบัติที่ดีคืออะไร?

กุญแจสำคัญในการประเมินน้ำหนักเบาคือการประเมินสิ่งที่ถูกต้องในเวลาที่เหมาะสม มีสองวิธีที่ฉันรู้ว่าทำอย่างมีประสิทธิภาพ ด้วยการประเมินตามสถานการณ์คุณใช้สถานการณ์คุณลักษณะคุณภาพและใช้กรณีเพื่อผลักดันการประเมินโดยมุ่งเน้นเฉพาะคุณลักษณะคุณภาพที่มีความสำคัญสูง ด้วยการประเมินตามความเสี่ยงคุณสามารถระบุความเสี่ยงและให้ความเสี่ยงที่ระบุนั้นผลักดันกิจกรรมการออกแบบสถาปัตยกรรมของคุณ

มีหนังสือสองเล่มที่ฉันสามารถแนะนำซึ่งสำรวจแนวทางทั้งสองนี้ (ค่อนข้างเกี่ยวข้อง)

Architecting Systems Intensive Softwareโดย Anthony Lattanze แนะนำวิธีการออกแบบสถาปัตยกรรมเป็นศูนย์กลางและครอบคลุมการประเมินตามสถานการณ์ที่มีน้ำหนักเบา คุณอาจรู้จัก Lattanze จากเวิร์กช็อปคุณลักษณะคุณภาพของ SEI และมีแนวคิดที่คล้ายกัน

สถาปัตยกรรมซอฟต์แวร์ที่เพียงพอ: วิธีการที่ขับเคลื่อนด้วยความเสี่ยงโดย George Fairbanks แนะนำวิธีการที่ขับเคลื่อนด้วยความเสี่ยงในการออกแบบและประเมินสถาปัตยกรรมของระบบซอฟต์แวร์ นอกจากนี้ยังมีบางบทฟรีบนเว็บไซต์ของเขาหากคุณต้องการดูตัวอย่าง ในขณะที่หลักการในหนังสือเล่มนี้มีผลบังคับใช้ทันทีวิธีการที่ไม่ได้มาพร้อมกับวิธีการเฉพาะดังนั้นคุณจะต้องรวมความคิดจากพื้นที่อื่น ๆ ฉันขอแนะนำวิธีการจัดการความเสี่ยงอย่างต่อเนื่องของ SEIสำหรับการระบุ / จัดลำดับความเสี่ยง

แนวคิดพื้นฐานเบื้องหลังแนวทางเหล่านี้คือคุณลดค่าใช้จ่ายในการประเมิน (และการออกแบบ) โดยการประเมินตามที่คุณไปแทนที่จะรอจนถึงจุดสิ้นสุด แม้ว่านี่จะเป็นเฮฟวี่เวทที่หนักหนากว่าการพูดคุยกับไวท์บอร์ด แต่มันก็ไม่ได้ใกล้เคียงกับ ATAM ที่มีค่าใช้จ่ายสูง และถ้าคุณสะดวกสบายคุณสามารถเลือกวิธีการเชอร์รี่เพื่อตอบสนองความต้องการเฉพาะของคุณ

ไม่ว่าคุณจะใช้วิธีการใดในการประเมินผลแนวคิดทั่วไปจะเหมือนกัน ...

ก่อนที่คุณจะเริ่ม:

• สถานการณ์หรือความเสี่ยงของแอตทริบิวต์คุณภาพจัดลำดับความสำคัญ (อาจไม่เป็นทางการหากนั่นคือทั้งหมดที่คุณมี)
• คำจำกัดความที่ชัดเจนสำหรับการตัดสินใจไป / ไม่ไป (คุณรู้ได้อย่างไรว่าสถาปัตยกรรมนั้น "ดีพอ")
• การตัดคำอธิบายสถาปัตยกรรมล่าสุด (สิ่งประดิษฐ์ที่คุณกำลังประเมิน)

นั่งลงสำหรับช่วงการประเมินผล:

• สถาปนิกนำเสนอภาพรวมของสถาปัตยกรรม
• เดินผ่านมุมมองแสดงให้เห็นว่าสถานการณ์หรือความเสี่ยงนั้นน่าพอใจเพียงใด
• ปัญหาจะถูกบันทึกไว้เพื่อแก้ไขในภายหลัง
• บทบาทและขั้นตอนทั่วไปคล้ายกับที่ใช้สำหรับการตรวจสอบ Fagan (สถาปนิกหรือผู้แต่งผู้ดำเนินรายการบันทึก)
• เซสชันอาจใช้เวลาเพียงหนึ่งหรือสองชั่วโมงขึ้นอยู่กับขนาดของระบบของคุณ

เมื่อเซสชันสิ้นสุดลง:

• ตรวจสอบปัญหาที่ระบุและพิจารณาว่าเป็นไปตามเกณฑ์ Go / no-go หรือไม่ โดยทั่วไปจะใช้เวลาประมาณ 3 รีวิวเพื่อให้ทุกอย่างเป็นไปได้ หากไม่พบให้ปรับและทดลองต่อไป (หรือลดความเสี่ยงด้านสถาปัตยกรรม)
• นี่ไม่ใช่การประเมิน "ทั้งหมดหรือไม่มีเลย" - ส่วนต่าง ๆ ของสถาปัตยกรรมของคุณอาจ "ผ่าน" ในขณะที่คนอื่นยังคงต้องการการปรับแต่ง

เพื่อช่วยให้คุณรู้สึกว่าแนวทางตามสถานการณ์จำลองเป็นอย่างไรมีเอกสารสาธารณะบางส่วนจากโครงการสุดที่ฉันทำงานในโรงเรียนระดับบัณฑิตศึกษา เอกสารมีความหยาบเล็กน้อย แต่อาจช่วยยกตัวอย่างบางส่วนของวิธีการตามสถานการณ์ภายในบริบทของ ACDM เราเป็นทีม 5 คนและสร้างแอปพลิเคชันบนเว็บทั่วไปประมาณ 35 KLOC Java / GWT

ฉันชอบการอภิปรายไวท์บอร์ดที่ไม่เป็นทางการเพื่อเริ่มต้นด้วย ฉันชอบที่จะเขียนเฉพาะส่วนของแอปพลิเคชันที่จำเป็นในปัจจุบันและจากนั้นค่อยๆปล่อยให้สถาปัตยกรรมเกิดขึ้นในระหว่างการนำไปใช้ มันเหมือน "การค้นหาสถาปัตยกรรม" มากกว่าที่จะลองประดิษฐ์มันมาก่อน วิธีการนี้ไม่ต้องการการประเมินล่วงหน้ามากและช่วยให้คุณมุ่งเน้นไปที่สิ่งที่สำคัญ (ส่งมอบซอฟต์แวร์ที่ใช้งานได้)

แน่นอนหากความต้องการที่ไม่ใช่หน้าที่การใช้งานของคุณต้องการ (ข้อ จำกัด ของหน่วยความจำเวลาตอบสนองจำนวนผู้ใช้พร้อมกันเป็นต้น) คุณต้องคำนึงถึงสิ่งนั้นเมื่อนำระบบไปใช้