...

• آیا قالب سند معماری رعایت شده است؟ (دوباره آخرین نسخه از قالب سند معماری را با مستندی که نوشته‌اید مقایسه کنید)
• آیا همه فصل‌های قالب سند معماری را تکمیل کرده‌اید؟ 
• آیا سند از دید معماری نوشته شده است؟ (سند باید توسط فردی که طراحی کلان سامانه را از نظر فنی می‌شناسد نوشته یا تایید شده باشد)
• آیا مستند را در قالب ورد تحویل داده‌اید؟ (اگر سامانه مدیریت دانش مبتنی بر ویکی هنوز راه‌اندازی نشده است، مستند در قالب docx و اگر نه، در قالب pdf تحویل داده شود)

اشتباه‌های رایج در نگارش سند معماری

• اشتباه رایج: رعایت نشدن قالب سند
  • سند معماری طبق قالب باشد. انطباق با قالب سند معماری، مهم است.
  • همه بخش‌های مطرح‌شده در قالب سند معماری و با همان ترتیب، در مستندسازی پوشش داده شود.
• نویسنده سند معماری، یک فرد ارشد فنی (مثلا مدیر فنی، معمار نرم‌افزار یا ...) باشد که در جریان تصمیمات اصلی و کلان طراحی سامانه باشد.
  • این نکته برای سند معماری (SAD) است. در مورد سند SCD (سند توصیف ارتباطات سامانه) لازم نیست نویسنده‌ سند SCD معمار سامانه (یا یک فرد ارشد فنی) باشد. کسی که در جریان کلیات کارکرد و ارتباطات سامانه باشد می‌تواند سند SCD را بنویسد.
• انگیزش: توجه شود که سند معماری به درد تیم توسعه هم می‌خورد (خود شرکت پیمانکار ذی‌نفع تولید این سند است). اگر معماری سامانه مستند نشده، یک مخاطره (ریسک) برای تیم/شرکت توسعه‌دهنده هم هست. به این سند، فقط به عنوان یک نیازمندی از سمت کارفرما نگاه نشود. ذی‌نفعان مختلفی (طراحان، مدیران، کارفرما، برنامه‌نویسان و ...) در طول زمان ممکن است ازبخش‌هایی از سند معماری استفاده کنند.
• به سطح سند معماری توجه شود. در نمودارها و جداول سند معماری، معمولا درباره المان‌ها و ساختارهای سطح بالا صحبت می‌کنیم و درباره جزییات پیاده‌سازی صحبت نمی‌کنیم. مثلا نمودار sequence بین چند کلاس پروژه در سند معماری جای نمی‌گیرد ولی نمودار sequence بین چند کامپوننت سطح بالا ممکن است در معماری نمایش داده شود.
• به فلسفه‌ ایجاد سند معماری (SAD) توجه شود.
  • این سند دارای دو بخش اصلی است:
    • بخش اول: شامل بیان نیازمندی‌های کارکردی و غیرکارکردی سیستم (فضای مساله)
      • این بخش باید دقیق و شفاف باشد (مساله به خوبی بیان شود)
    • بخش دوم: بیان راهکارها و تکنیک‌ها برای پوشش نیازمندی‌های بخش اول از نماها/دیدگاه‌های مختلف (فضای راه‌حل)
      • فضای راه‌حل، باید مطابق با فضای مساله باشد.
      • هر مورد از محتوای این بخش باید سرنخی در بخش اول داشته باشد.

• اشتباه‌های رایج در بخش اول (فضای مساله)
  • اشتباه‌های رایج در بخش نمای Usecase (مورد کاربرد):
    • بیان نیازمندی‌ها به صورت یک عنوان و عدم ارایه توضیحات کافی  
    • تمرکز بیش از حد بر روی نمودارهای موارد کاربرد و عدم توجه به ارایه مطالب به صورت سازمان‌دهی‌شده و گویا
    • عدم تبیین کنشگرها (actorهای سامانه) به تفکیک کنشرگرهای انسانی و سیستمی
  • اشتباه‌های رایج در بخش ویژگی‌های کیفی
    • بیان کلی ویژگی‌های کیفی (مثلا امنیت و کارایی). نام بردن از ویژگی‌های کیفی کافی نیست و بی‌فایده است.
    • عدم ذکر  معیار ارزیابی. روش محاسبه میزان کیفیت در هر ویژگی کیفی باید ذکر شود (مثلاً معیار TPS برای کارایی)
    • عدم ذکر محدوده مطلوب (مثلا محدوده‌ی حداقل 100 برای معیار TPS)

...

• نحوه‌ ارتباط بین مولفه‌های اصلی سامانه مشخص شود.
  • عبارت مولفه اصلی در جمله قبل نقش کلیدی دارد. همانطور که ارتباطات بین سامانه‌های مختلف مهم است، ارتباط بین مولفه‌های مهم درون یک سامانه نیز مهم است.
• هریک از نمودارهای ارایه‌شده مربوط به یک یا چند نیازمندی functional یا nonfunctional باشد.
• مولفه‌ اصلی، یک صفحه‌ (مثلا یک فرم کاربری) یا یک موجودیت سطح پایین (در سطح پیاده‌سازی) در نظر گرفته نشود. بلکه یک کامپوننت یا موجودیت نرم‌افزاری سطح بالا (مهم در سطح معماری) باشد.
•  موارد کاربرد کوچک و جزیی (مثل مورد کاربرد ورود به سامانه) نباید به صورت نمودار در این بخش توصیف شود.
• صرفا ارایه یک یا چند نمودار کافی نیست و حتما بایستی شرحی در کنار نمودارها باشد.

...

• گاهی در نمای استقرار چندین سرور مشاهده می‌شود ولی در نمای پردازه فقط نام پردازه‌ها ذکر می‌شود.
  • دقیقا ذکر شود در هر سرور چه پردازه‌هایی در حال اجرا هستند.
• در نمای استقرار، اطلاعاتی مثل IP سرورها ذکر نشود.

...

• بیان الگوهای کلی بی‌فایده است. در عوض باید بیان شود چه تقسیم‌بندی‌ها و تصمیماتی در سطح کد گرفته شده است. مثلا به جای ترسیم شکل یک معماری سه لایه، که احتمالا از اینترنت کپی شده است، تبیین شود که محتوای لایه‌ها در پروژه چگونه است و در هر لایه، چه بسته‌ها و کدهایی قرار می‌گیرد.
• در این نما بایستی مولفه‌های اصلی و ارتباطاتشان مشخص شود.
• هم‌چنین تصمیات کلیدی در پیاده‌سازی، بیان شود. مثلا ذکر شود بحث validation مربوط به موجودیت‌ها و درخواست‌های وب‌سرویس به صورت کد پیاده‌سازی شده و یا توصیف آن در فایل XML ذخیره می‌شود. نحوه‌ دسترسی به افراد در پایگاه‌داده جدا ذخیره شده است.

...

• معرفی ابزارهای تست
• بیان سطوح تست
• بیان تصمیمات کلان برای تست سامانه
• نحوه مدیریت ارتباط تست‌ها با نیازمندی‌ها 

...

• بیان دقیق اطلاعات ذخیره‌شده در لاگ
  • مثلا بیان کلی این که «اطلاعات نشست کاربری لاگ می‌شود» کافی نیست.

...

• بیان سناریوهایی مثل اندازه‌گیری میزان استفاده از شبکه و منابع سیستم کافی نیست.
• نحوه استفاده از لاگ‌های سامانه (موضوع فصل قبل) برای پایش ذکر شود.
• سناریوهای پایش (افراد/نقش‌ها/فرایندها/هشدارها/اقدام‌ها/...) بیان شود.

...

• تصمیمات اساسی در زمینه داده‌های سامانه ذکر شود. این تصمیمات فقط شامل مدل داده‌ها (مثلا جداول اصلی و مهم) نیست. بلکه مواردی مثل تکنیک‌های کلان مورد استفاده در لایه داده (مثلا نحوه و فناوری Cache و Backup/Restore و Data Migration و ...) ذکر شود.

...

• قرار نیست جزییات روش‌ها بیان شود، بلکه به طور کلی بیان شود که برای هر مساله/نیازمندی دقیقا چه تکنیک‌هایی مورد استفاده قرار گرفته است.

...

محتوای این بخش حذف شده است.

پیوست

فایل قالب پیشنهادی

محتوای این بخش حذف شده است.