در مطالب قبلی در مورد پیچیدگی نیازمندی‌های نرم‌افزار و مدلسازی نیازمندی‌های کیفی نکاتی مطرح شد. اما موضوعی که سبب استفاده از این مفاهیم به صورت یکپارچه می‌شود، فرآیند تدوین معماری است. فرآیند تدوین معماری نرم‌افزار از جمله مفاهمیی است که همانند هوا در بسیاری از پروژه‌های توسعه نرم‌افزار خصوصاً در نرم‌افزارهای بسیار وسیع نادیده گرفته می‌شود، در حالیکه عدم وجود آن سبب از بین رفتن تمام گیاهان و حتی جانوران خواهد شد. در اغلب موارد، برای تدوین معماری از روش Attribute Driven Design که توسط SEI ارائه شده است، پیشنهاد می‌شود. اما آیا این روش کارایی لازم برای توسعه معماری در فضای واقعی را دارد؟
قبل از پاسخ به این سوال، بهتر است به این سوال پاسخ داده شود که در فرایند توسعه نرم‌افزار، جایگاه فرآیند توسعه معماری کجاست؟
پاسخ ساده به این سوال، پس از تدوین نیازمندی‌ها و قبل از طراحی نرم‌افزار است. شکل زیر (منبع) نشان‌دهنده این موضوع است که تدوین معماری با تدوین نیازمندی‌ها در تعامل است. بدین معنی که فرآیند معماری با فرآیند تدوین نیازمندی‌های نرم‌افزار، به صورت تدریجی و افزایشی کامل می‌شوند. این موضوع در توسعه نرم‌افزارها معقول است چرا که نیازمندی‌های مورد نیاز برای معماری همواره مد نظر تدوین‌کنندگان نیازمندی‌های نرم‌افزار نیست و نیازمندی‌های اولیه بدون در نظر داشتن طرح معماری تعیین می‌شوند. از طرفی به‌گونه‌ای تعیین معماری شکل‌دهنده نیازمندی‌های نرم‌افزار است و همانطور که در مثال عملی ADD نیز مشاهده می‌شود، نیازمندی‌های کیفی در قالب سناریوهای خصوصیات کیفی مد نظر قرار گرفته است، چیزی که از عهده مسئول نیازمندی‌های خارج است و این معمار است که می‌بایست چنین سناریوهایی را تدوین نماید. با توجه به این موضوع، به نظر میرسد که فرآیند معماری همزمان با فرآیند نیازمندی‌ها می‌بایست شروع شود تا یکدیگر را حمایت نماید. با طرح این موضوع، این سوالات متعددی به وجود می‌آید به‌عنوان مثال آیا شناخت نیازمندی‌های کیفی با شناخت نیازمندی‌های نرم‌افزار توسط دو نفر انجام می‌شوند؟ مستقل از هم انجام می‌شوند؟ چگونه با یکدیگر ارتباط دارند؟
با بیان این موضوعات، ابهام برای جایگاه فرآیند توسعه معماری پیچیده‌تر می‌شود. با آنکه اغلب منابع در مورد روند یا فرآیند توسعه معماری گام‌هایی را ذکر نموده‌اند، اینکه واقعاً فعالیت معمار از کجا شروع شده، چه فعالیت‌های انجام می‌دهد، ارتباط فعالیت‌های با سیر فعالیت‌های مهندسی نرم‌افزار چگونه است؟ چه چیزی تولید می‌نماید و چه خروجی‌هایی به سایر فعالیت‌های مهندسی نرم‌افزار ارائه می‌دهد جای سوال فراوان دارد.
در پاسخ به این سوالات فراوان، قبل از هر چیز باید اذعان نمود که جایگاه معماری نرم‌افزار در پروژه‌ها مختلف و با توجه به اندازه پروژه و برخی خصوصیات دیگر، متفاوت است. آقای Nick Rozanski و همکارش Eoin Woods در کتاب خود (Software Systems Architecture) به بررسی جایگاه تدوین معماری در فرآیندهای توسعه نرم‌افزار متداول از جمله آبشاری، چابک و تکراری و تدریجی پرداختند و تلاش نمودند تا جایگاه اصلی آن را مشخص نمایند. سه جایگاه پیشنهادی آنها، الف) قبل از نیازمندی‌ها، ب) همزمان با نیازمندی‌ها و ج) بعد از نیازمندی‌ها می‌باشد. اما چرا جایگاه معماری نرم‌افزار در توسعه نرم‌افزار متفاوت است، پاسخ در انتظاری که از معماری وجود دارد، می‌باشد. با دقت در منابع مختلف معماری نرم‌افزار مشخص می‌شود که تنوع انتظارات از معماری و معمار نرم‌افزار متفاوت است و پوشش این تنوع سبب می‌شود تا جایگاه معماری نرم‌افزار در فرآیند توسعه نرم‌افزار متفاوت باشد. به‌عنوان نمونه، فرآیند توسعه نرم‌افزار RUP، سند معماری را در فاز Elaboration بیشتر مورد توجه قرار می‌دهد و سند معماری فاقد خصوصیاتی است که اغلب معماران در نظر دارند، در حالیکه روش ADD، معماری را نقطه کلیدی تدوین ساختار و توازن‌های خصوصیات کیفی در نظر می‌گیرد، یا در متدولوژی V انتظار از معماری اغلب توزیع وظایف بین مولفه‌ها است. همین موضوع در نویسندگان مختلف کتاب‌های معماری نیز وجود دارد به‌عنوان نمونه آقای Paul Clements و همکارانش (Software Architecture in Practice) در چرخه حیات معماری، بر این نکته تاکید دارند که معمار با تمامی ذی‌نفعان در ارتباط است اما اغلب نویسندگان معماری را یا فعالیت می‌دانند که نقطه پایان آن قبل از طراحی بوده و معمار سرو کاری با همه ذی‌نفعان ندارند.
با توجه به جایگاه معماری نرم‌افزار در پروژه‌ها، طبیعتاً پاسخی که به سوالات مطرح‌شده می‌توان داد و انتظاری که از فرآیند توسعه معماری می‌توان داشت، متفاوت است. در صورتیکه معماری نرم‌افزار قبل از تدوین نیازمندی‌ها اجرا شود، انتظار بر شکل دهی نیازمندی‌ها و برخی تصمیمات و انتخابات اولیه توسعه نرم‌افزار است. در حالیکه اگر معماری نرم‌افزار پس از تدوین نیازمندی‌ها شروع شود، طبیعتاً انتظار بر تاکید بر روی طراحی و توزیع وظایف خواهد بود. این موضوع همچنین بر استفاده از مفاهیم معماری همچون Style, Pattern و Concern نیز اثرگذار است. در نوشته‌های بعدی به بررسی جزئیات فرآیند توسعه معماری در هر یک از جایگاه‌ها خواهم پرداخت.
خیلی مقاله قوی و غنی ای بود. احسنت