کنترل‌کننده مدل رویت؛ خودکارسازی کنترل کیفیت، نه جایگزین آن

Model Checker رویت بیشتر به یک غلط‌یاب برای داده‌های داخلی مدل شبیه است تا یک ابزار کامل کنترل کیفیت. این ابزار داده‌هایی را بررسی می‌کند که رویت ذخیره کرده است: اینکه پارامترها پر شده‌اند، نام‌ها از الگوی مشخص پیروی می‌کنند و تایپ درست بارگذاری شده است. کیفیت خود طراحی در این بررسی قرار نمی‌گیرد.

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

اجرای چک‌ست روی مدلی که از قبل نامرتب است، فهرست بلندی از هشدارها تولید می‌کند که کسی فرصت رسیدگی به آن را ندارد. تایپ‌های تکراری، پارامترهای بی‌استفاده و فمیلی‌های دانلودی بررسی‌نشده، همان مواردی که در نوشته‌ی بهینه‌سازی کتابخانه رویت بررسی شده‌اند، گزارش را به‌جای موارد واقعی با موارد بی‌اهمیت پر می‌کنند.

یک پاک‌سازی اولیه شامل Purge Unused، بررسی Object Styles و یکدست‌کردن نام‌گذاری، تفاوت میان گزارشی است که کسی آن را بررسی می‌کند و گزارشی که هرگز باز نمی‌شود.

Model Checker Configurator از Autodesk امکان نوشتن قواعد اختصاصی را فراهم می‌کند و چک‌ست‌های نمونه، مانند مجموعه‌های Revit Best Practice و COBie، نقطه‌ی شروع مناسبی هستند. چک‌ست وارداتی به‌ندرت دقیقاً با نیاز دفتر شما مطابقت دارد؛ نقطه‌ی شروع است، نه پاسخ نهایی.

ساخت چک‌ست یک مهارت است، نه چند کلیک ساده. سه روش کاری بیشترین تفاوت را ایجاد می‌کنند:

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

چک‌ست اول باید آن‌قدر کوتاه باشد که بتوان بر اساس آن اقدام کرد. پنج گروه قاعده، بیشتر موضوعاتی را پوشش می‌دهند که در دفاتر درباره‌ی آن‌ها اختلاف‌نظر وجود دارد:

• نام‌گذاری: ویوها، شیت‌ها، فمیلی‌ها و تایپ‌ها بر اساس الگوی دفتر.
• پارامترهای ضروری: فیلدهایی که اسکجوال‌ها و تگ‌ها به آن‌ها وابسته‌اند، پر و با قالب درست.
• ویوتمپلیت‌ها: هر ویوی کاری تمپلیت دارد و کسی آن را به‌صورت دستی تغییر نداده است.
• پاکیزگی مدل: فمیلی‌های In-Place، فایل‌های CAD واردشده و المان‌های بی‌استفاده، در حد نیاز واقعی پروژه.
• داده‌های تحویل: فیلدهایی که قالب تحویلی مانند COBie انتظار دارد، اگر پروژه به آن نیاز داشته باشد.

هر قاعده‌ای فراتر از این موارد، به چک‌ست دوم تعلق دارد؛ چک‌ستی که پس از اجرای چک‌ست اول روی پروژه‌های واقعی و اطمینان از نتیجه‌ی آن نوشته می‌شود.

هر علامت در گزارش یکی از سه حالت است: خطای واقعی، موردی که به دلیل نبود اطلاعات زمینه‌ای علامت خورده، یا موردی که به تصمیم یک نفر نیاز دارد. اگر همه‌ی موارد به ترتیب فهرست و بدون این دسته‌بندی اصلاح شوند، زمان صرف موارد نادرست می‌شود و موارد مهم دیرتر از همه پیدا می‌شوند.

فهرست بلند علامت‌ها ممکن است علت‌های محدودی داشته باشد. اگر فمیلی‌ای با تایپ پارامتر نادرست بارگذاری شده باشد، همه‌ی نمونه‌های آن در گزارش علامت می‌خورند. پیش از هر اصلاحی، علامت‌ها را بر اساس فمیلی و قاعده گروه‌بندی کنید.

پس از اصلاح، بررسی را دوباره اجرا کنید تا از رفع مشکل مطمئن شوید و قاعده را برای دفعات بعد نگه دارید. موردی که یک‌بار پیدا شده است، نباید دوباره با جست‌وجوی دستی پیدا شود.

Model Checker فقط داده‌هایی را می‌خواند که رویت ذخیره کرده است. تشخیص تداخل میان رشته‌ها، بررسی‌های هندسی و انتقال پارامترها به صفحه‌گسترده برای بازبینی، خارج از محدوده‌ی آن قرار دارند. Navisworks و Solibri تداخل و هندسه را پوشش می‌دهند و اسکریپت‌های Dynamo و افزونه‌هایی مانند Ideate BIMLink، بازبینی پارامترها را.

ترتیب معمول، ابتدا داده و سپس هندسه است. ابتدا نام‌گذاری و پارامترها را با کنترل‌کننده‌ی داخلی تأیید کنید و سپس تشخیص تداخل را اجرا کنید. گزارش تداخل روی مدلی که داده‌های پایه‌ی آن هنوز نادرست است، ارزش بررسی ندارد.

اگر قواعد دفتر شما در Configurator قابل‌تعریف نباشند، کنترل‌کننده‌ی اختصاصی بر پایه‌ی Revit API قدم بعدی است؛ همان قواعد به‌صورت تست روی هر مدل اجرا می‌شوند و گزارش برای افرادی نوشته می‌شود که باید بر اساس آن اقدام کنند. کنترل کیفیت مدل یکی از جریان‌های کاری است که در نوشته‌ی توسعه پلاگین رویت چقدر هزینه دارد بررسی شده است.

یک بررسی یک‌باره تنها چند هفته فرصت ایجاد می‌کند. مدل‌ها زیر فشار زمان‌بندی، همانند کتابخانه‌ها، دوباره نامرتب می‌شوند. اجرای فصلی چک‌ست برای پروژه‌های فعال، پیش‌فرض مناسبی است.

با اجرای منظم، نتیجه‌ی بررسی‌ها از یک فهرست به یک روند تبدیل می‌شود: کدام پروژه‌ها بهتر می‌شوند و کدام‌ها دوباره به همان مشکلات برمی‌گردند. این روند ارزش نمایش در داشبوردی را دارد که تیم واقعاً از آن استفاده می‌کند، نه در صفحه‌گسترده‌ای که یک‌بار ارسال و فراموش می‌شود.

اگر یک پروژه دارید، چند قاعده‌ی محدود کافی است و ابزار رایگان Autodesk همان را پوشش می‌دهد، نیازی به استخدام کسی نیست، از جمله ما. به‌جای آن، یک بعدازظهر را صرف کار با Model Checker Configurator کنید.

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