200 سوال تحلیل نرم افزار در سطح ارشد

بخش اول: نقش، جایگاه و تعاملات تحلیل‌گر سیستم

سوال ۱

·         سوال: با توجه به مفهوم «پل ارتباطی بین دنیای کسب‌وکار و فناوری»، یک تحلیل‌گر سیستم چگونه باید تعارض میان یک نیازمندی با ارزش تجاری بالا و یک محدودیت جدی در معماری زیرساخت را مدیریت و حل‌وفصل کند؟

·         پاسخ مورد انتظار: تحلیل‌گر با هدایت فرآیند کشف، تحلیل هزینه-فایده و بررسی بده‌بستان‌ها (Trade-offs)، گزینه‌های فنی جایگزین را تدوین کرده و با تشکیل جلسات مشترک میان ذینفعان، به یک راه‌حل متوازن و مستند می‌رسد تا اهداف سازمان بدون ایجاد بدهی فنی شدید محقق شود.

·         راهنما: به نقش تحلیل‌گر در هدایت فرآیند کشف، مدیریت بده‌بستان‌ها و تسهیل ارتباطات بین تیم فنی و تجاری توجه کنید.

سوال ۲

·         سوال: بر اساس زنجیره ارزش پروژه، تفاوت بنیادین در خروجی‌های مستندسازی یک تحلیل‌گر کسب‌وکار (BA) و یک تحلیل‌گر سیستم (SA) چیست و این دو چگونه به تیم توسعه جهت می‌دهند؟

·         پاسخ مورد انتظار: خروجی BA متمرکز بر «چیستی و چراایی» نیازهای مالک در قالب اسناد اهداف تجاری است؛ اما خروجی SA متمرکز بر «چگونگی پیاده‌سازی فنی» در قالب اسناد طراحی سیستم، نمودارهای جریان داده، مشخصات موارد استفاده و وایرفریم‌ها است که به عنوان نقشه مهندسی دقیق در اختیار تیم توسعه قرار می‌گیرد.

·         راهنما: به تقدم و تاخر فعالیت‌ها و قیاس مالک خانه در برابر مهندس سازه فکر کنید.

سوال ۳

·         سوال: زمانی که تیم فنی به دلیل محدودیت‌های زمانی تمایلی به مطالعه مستندات تحلیل ندارد، تحلیل‌گر سیستم از چه تکنیک‌هایی برای انتقال موثر نیازمندی‌ها استفاده می‌کند؟

·         پاسخ مورد انتظار: استفاده از مدل‌های بصری (مانند نمودارهای حالت و توالی)، برگزاری جلسات بازخوانی سریع (Walkthrough) و شکستن مستندات به بخش‌های کوچک و قابل‌فهم در قالب یوزرکیس‌ها یا پیوست‌های کوتاه فنی.

·         راهنما: روی روش‌های ساده‌سازی و بصری‌سازی اطلاعات تمرکز کنید.

سوال ۴

·         سوال: یک تحلیل‌گر سیستم چگونه می‌تواند مرز وظایف خود را با معمار نرم‌افزار (Software Architect) شفاف کند تا از تداخل کاری جلوگیری شود؟

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

·         راهنما: به تفاوت میان «منطق رفتار سیستم» و «ساختار زیربنایی کد» توجه کنید.

سوال ۵

·         سوال: در یک پروژه چابک (Agile)، نقش تحلیل‌گر سیستم در فرآیند پالایش بک‌لاگ (Backlog Refinement) چیست؟

·         پاسخ مورد انتظار: او به عنوان بازوی فنی مالک محصول عمل کرده، نیازمندی‌های بزرگ را به داستان‌های کاربر (User Stories) کوچک‌تر می‌شکند، وابستگی‌های فنی بین بخش‌ها را کشف می‌کند و معیارهای پذیرش شفاف برای هر داستان می‌نویسد.

·         راهنما: به آماده‌سازی داستان‌ها برای ورود به اسپرینت و نقش کاتالیزوری تحلیل‌گر فکر کنید.

بخش دوم: مهندسی نیازمندی‌ها و مدیریت ابهام

سوال ۶

·         سوال: یکی از الگوهای ضدکاربردی (Anti-patterns) رایج، «گرایش زودهنگام به راه‌حل‌محوری فنی» است. این پدیده چه آسیبی به کیفیت مهندسی نیازمندی‌ها می‌زند و راهکار پیشگیری از آن چیست؟

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

·         راهنما: به پیامدهای فرار از ابهام‌زدایی صورت‌مسئله و اهمیت معیارهای پذیرش فکر کنید.

سوال ۷

·         سوال: در پروژه‌های بزرگ‌مقیاس که اطلاعات و اصطلاحات به سرعت تغییر می‌کنند، یک تحلیل‌گر چگونه از بروز سوءتفاهم میان تیم ساخت و تیم کسب‌وکار در خصوص مفاهیم تخصصی جلوگیری می‌کند؟

·         پاسخ مورد انتظار: با ایجاد و نگهداری مستمر یک «واژه‌نامه زنده از اصطلاحات» (Living Glossary) که به عنوان مرجع واحد عمل کرده و زبان مشترکی را پدید می‌آورد تا مفاهیم تجاری به طور دقیق به کدهای نرم‌افزاری ترجمه شوند.

·         راهنما: به اهمیت ایجاد زبان مشترک و ابزار کنترل یکپارچگی اصطلاحات توجه کنید.

سوال ۸

·         سوال: تکنیک «پنج چرا» (5 Whys) در فاز استخراج نیازمندی‌ها چه کاربردی دارد و چگونه جلوی درخواست‌های سطحی ذینفعان را می‌گیرد؟

·         پاسخ مورد انتظار: این تکنیک با تکرار سوال «چرا» به تحلیل‌گر کمک می‌کند تا از لایه درخواست‌های ظاهری کاربر عبور کرده و به علت ریشه‌ای و نیاز واقعی کسب‌وکار برسد تا راه‌حل به جای نشانه‌ها، علت اصلی را حل کند.

·         راهنما: به تفاوت میان «آنچه کاربر می‌خواهد» و «آنچه کاربر واقعاً نیاز دارد» نگاه کنید.

سوال ۹

·         سوال: معیار تاییدپذیری یا تست‌پذیری (Testability) یک نیازمندی به چه معناست و تحلیل‌گر چگونه آن را تضمین می‌کند؟

·         پاسخ مورد انتظار: یعنی نیازمندی باید به گونه‌ای نوشته شود که تیم تضمین کیفیت بتواند با اجرای یک تست عینی، پاس یا فیل شدن آن را مشخص کند. تحلیل‌گر این کار را با حذف کلمات مبهم (مانند سریع، امن، کاربرپسند) و جایگزینی آن‌ها با اعداد و معیارهای سنجش‌پذیر انجام می‌دهد.

·         راهنما: به نحوه تبدیل توصیف‌های کیفی به معیارهای عددی و قطعی فکر کنید.

سوال ۱۰

·         سوال: مفهوم «خزش محدوده» (Scope Creep) چیست و تحلیل‌گر سیستم با چه ابزاری در لایه نیازمندی‌ها با آن مقابله می‌کند؟

·         پاسخ مورد انتظار: خزش محدوده یعنی اضافه شدن تدریجی و کنترل‌نشده نیازمندی‌ها بدون ارزیابی تاثیر آن‌ها روی زمان و بودجه. تحلیل‌گر با استفاده از «ماتریس ردیابی نیازمندی‌ها» (RTM) و فرآیند رسمی مدیریت تغییرات با آن مقابله می‌کند.

·         راهنما: به کنترل مرزهای پروژه و ثبت اثرات تغییرات جدید توجه کنید.

بخش سوم: کیفیت و نیازمندی‌های غیرعملکردی (NFR)

سوال ۱۱

·         سوال: بر اساس «طرز فکر کیفی»، چرا آشکارسازی نیازهای غیرعملکردی (NFR) مانند امنیت، کارایی و مقیاس‌پذیری نباید به فازهای پایانی یا پس از استقرار در محیط عملیاتی موکول شود؟

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

·         راهنما: به قیاس ساختار زیربنایی ساختمان در مواجهه با نیازهای کیفی نگاه کنید.

سوال ۱۲

·         سوال: چگونه می‌توان یک نیازمندی غیرعملکردی کیفی مانند «سیستم باید سرعت بالایی داشته باشد» را به یک نیازمندی سیستمی دقیق تبدیل کرد؟

·         پاسخ مورد انتظار: با مشخص کردن معیارهای فنی سنجش‌پذیر؛ مثلاً: «زمان پاسخ‌دهی سیستم به درخواست‌های جستجوی متنی در شرایط بارگذاری عادی باید کمتر از ۲ ثانیه باشد و نرخ خطای سرور نباید از ۰.۱ درصد فراتر رود.»

·         راهنما: به تعریف بازه‌های زمانی، حجم بار و شرایط محیطی برای سنجش کارایی فکر کنید.

سوال ۱۳

·         سوال: مفهوم «قابلیت نگهداری» (Maintainability) در تحلیل سیستم چیست و تحلیل‌گر چگونه در مستندات خود به توسعه آن کمک می‌کند؟

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

·         راهنما: به اثرات تغییر یک بخش روی بخش‌های دیگر و نحوه کاهش این وابستگی‌ها توجه کنید.

سوال ۱۴

·         سوال: تفاوت اصلی میان نیازمندی‌های دسترسی‌پذیری (Availability) و قابلیت اطمینان (Reliability) چیست؟

·         پاسخ مورد انتظار: قابلیت اطمینان یعنی سیستم چقدر بدون خرابی و خطا کار خود را درست انجام می‌دهد، در حالی که دسترسی‌پذیری یعنی درصد زمانی که سیستم در بالا و آماده سرویس‌دهی به کاربران است (مثلاً آپتایم ۹۹.۹ درصد).

·         راهنما: به تفاوت میان «درست کار کردن در حین کار» و «در دسترس بودن برای شروع کار» فکر کنید.

سوال ۱۵

·         سوال: تحلیل‌گر سیستم چگونه فرآیند احراز هویت (Authentication) و مجوزدهی (Authorization) را در اسناد نیازمندی‌ها تفکیک و مدل‌سازی می‌کند؟

·         پاسخ مورد انتظار: احراز هویت یعنی بررسی اینکه کاربر همانی است که ادعا می‌کند (صحت‌سنجی ورودی)؛ اما مجوزدهی یعنی بررسی سطح دسترسی کاربر پس از ورود. تحلیل‌گر این موارد را در ماتریس دسترسی‌ها (CRUD Matrix) بر اساس نقش‌های کاربری مدل‌سازی می‌کند.

·         راهنما: به تفاوت هویت کاربر و سطح اختیارات او در سیستم نگاه کنید.

بخش چهارم: مدل‌سازی و ابزارهای تحلیلی

سوال ۱۶

·         سوال: در نمودار جریان داده (DFD)، تفاوت سطح صفر (Context Diagram) با سطح یک در چیست و هرکدام چه هدفی را دنبال می‌کنند؟

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

·         راهنما: به مفهوم شکستن ساختار (Decomposition) و میزان جزئیات در هر سطح توجه کنید.

سوال ۱۷

·         سوال: کاربرد اصلی نمودار حالت (State Machine Diagram) در تحلیل سیستم چیست و برای چه نوع موجودیت‌هایی استفاده می‌شود؟

·         پاسخ مورد انتظار: برای مدل‌سازی چرخه عمر موجودیت‌های پیچیده‌ای که رفتار آن‌ها بر اساس وضعیت فعلی‌شان تغییر می‌کند (مانند وضعیت یک سفارش از سبد خرید تا تحویل نهایی) و نشان می‌دهد چه رویدادهایی باعث تغییر حالت می‌شوند.

·         راهنما: به موجودیت‌هایی که رفتارهای پویا و وابسته به زمان دارند فکر کنید.

سوال ۱۸

·         سوال: ماتریس CRUD چه کمکی به تحلیل‌گر سیستم در ارزیابی جامعیت داده‌ها و فرآیندها می‌کند؟

·         پاسخ مورد انتظار: این ماتریس مشخص می‌کند که هر موجودیت داده‌ای در کدام فرآیندها ایجاد (Create)، بازخوانی (Read)، به‌روزرسانی (Update) یا حذف (Delete) می‌شود. وجود موجودیتی که هیچ‌جا ایجاد یا خوانده نمی‌شود، نشان‌دهنده گپ تحلیلی است.

·         راهنما: به ارتباط مستقیم بین توابع سیستم و جداول اطلاعاتی نگاه کنید.

سوال ۱۹

·         سوال: در مدل‌سازی با Use Case، چه زمانی از رابطه Extends و چه زمانی از رابطه Includes استفاده می‌شود؟

·         پاسخ مورد انتظار: از Includes زمانی استفاده می‌شود که یک رفتار در چندین یوزکیس اجباری و مشترک باشد (مثل احراز هویت)؛ اما از Extends زمانی استفاده می‌شود که یک رفتار به صورت اختیاری و تحت شرایطی خاص به یوزکیس اصلی اضافه شود (مثل پرداخت با کد تخفیف).

·         راهنما: به اجباری یا مشروط بودن رفتار ثانویه نسبت به رفتار اصلی توجه کنید.

سوال ۲۰

·         سوال: اهمیت و کاربرد نمودار توالی (Sequence Diagram) در لایه تحلیل سیستم چیست؟

·         پاسخ مورد انتظار: این نمودار تعاملات زمانی بین اشیاء یا اجزای سیستم را برای اجرای یک سناریوی خاص نشان می‌دهد و به تیم فنی کمک می‌کند تا متوجه شود پیام‌ها با چه ترتیبی و بین کدام بخش‌ها ردوبدل می‌شوند.

·         راهنما: روی خط زمان (Timeline) و ترتیب ارسال پیام‌ها تمرکز کنید.

بخش پنجم: متدولوژی‌ها و چرخه‌های حیات سیستم

سوال ۲۱

·         سوال: در متدولوژی آبشاری (Waterfall)، بروز یک خطا در فاز تحلیل چه تاثیری روی فازهای تست و استقرار دارد و چرا هزینه رفع آن تصاعدی است؟

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

·         راهنما: به اثر بهمنی (Snowball Effect) خطاهای مراحل اولیه در مدل‌های خطی فکر کنید.

سوال ۲۲

·         سوال: مفهوم MVP (حداقل محصول پذیرفتنی) چیست و تحلیل‌گر سیستم چگونه نیازمندی‌ها را برای رسیدن به آن غربال می‌کند؟

·         پاسخ مورد انتظار: گزیده‌ای از محصول با حداقل ویژگی‌هاست که بتواند ارزش اصلی را به مشتری برساند و بازخورد ایجاد کند. تحلیل‌گر با تکنیک‌هایی مثل MoSCoW نیازمندی‌های حیاتی (Must Have) را از نیازمندی‌های ترجیحی جدا می‌کند.

·         راهنما: به تمرکز بر حل مسئله اصلی با کمترین هزینه و بیشترین سرعت توجه کنید.

سوال ۲۳

·         سوال: تفاوت رویکرد تکرارپذیر (Iterative) و افزایشی (Incremental) در توسعه سیستم‌های نرم‌افزاری چیست؟

·         پاسخ مورد انتظار: در رویکرد افزایشی، سیستم بخش به بخش ساخته و تحویل داده می‌شود (تکمیل تکه‌تکه اسکوپ)؛ اما در رویکرد تکرارپذیر، ابتدا کل سیستم به صورت نسخه‌های اولیه و ساده ساخته شده و در هر تکرار کیفیت و جزئیات آن بهبود می‌یابد.

·         راهنما: به نحوه تکامل سیستم از نظر عمق و سطح در هر دو مدل نگاه کنید.

سوال ۲۴

·         سوال: تحلیل‌گر سیستم در متدولوژی اسکرام، چگونه معیارهای پذیرش (Acceptance Criteria) را با مفهوم DoD (تعریف کارِ تمام‌شده) هماهنگ می‌کند؟

·         پاسخ مورد انتظار: معیارهای پذیرش اختصاصیِ هر داستان کاربر هستند و رفتار کاربردی آن را می‌سنجند، در حالی که DoD یک چک‌لیست عمومی و فنی برای تمام داستان‌هاست (مانند نوشتن تست واحد، بررسی امنیت و کد ریویو). یک ویژگی زمانی تمام است که هر دو را پاس کند.

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

سوال ۲۵

·         سوال: مفهوم «بدهی فنی» (Technical Debt) چیست و تصمیمات شتاب‌زده در فاز تحلیل چگونه به آن دامن می‌زنند؟

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

·         راهنما: به بهای سنگینی که تیم‌ها در آینده برای سرعت کاذب امروز می‌پردازند فکر کنید.

بخش ششم: تحلیل داده‌ها و ساختار اطلاعاتی

سوال ۲۶

·         سوال: نقش تحلیل‌گر سیستم در فرآیند نرمال‌سازی پایگاه‌داده (Normalization) چیست و چرا تعادل بین نرمال‌سازی و کارایی اهمیت دارد؟

·         پاسخ مورد انتظار: تحلیل‌گر با تحلیل وابستگی‌های تابعی، افزونگی داده‌ها را کاهش می‌دهد تا یکپارچگی حفظ شود. اما نرمال‌سازی بیش از حد باعث افزایش جُین‌های پیچیده و کاهش سرعت سیستم می‌شود؛ لذا گاهی برای بهبود کارایی، تحلیل‌گر دستور به غیرنرمال‌سازی (Denormalization) می‌دهد.

·         راهنما: به بده‌بستان بین یکپارچگی داده‌ها و سرعت بازخوانی آن‌ها توجه کنید.

سوال ۲۷

·         سوال: تفاوت بین داده‌های تراکنشی (Transactional Data) و داده‌های مرجع/پایه (Master Data) در تحلیل سیستم‌های سازمانی چیست؟

·         پاسخ مورد انتظار: داده‌های پایه موجودیت‌های اصلی و ثابت کسب‌وکار هستند که به ندرت تغییر می‌کنند (مانند اطلاعات مشتری یا کالا)، در حالی که داده‌های تراکنشی رویدادهای حاصل از تعامل این موجودیت‌ها هستند که حجم بالا و پویایی دارند (مانند فاکتور فروش).

·         راهنما: به طول عمر داده‌ها و فرکانس تغییرات آن‌ها نگاه کنید.

سوال ۲۸

·         سوال: تحلیل‌گر سیستم چگونه جریان داده‌های ورودی از سیستم‌های بیرونی را از نظر امنیت و جامعیت اعتبارسنجی (Validation) می‌کند؟

·         پاسخ مورد انتظار: با تعریف مکانیزم‌های کنترلی در لایه ورودی؛ شامل بررسی فرمت، طول داده، محدوده منطقی اعداد، عدم وجود کدهای مخرب (Sanitization) و تطابق با قراردادهای API (مانند اسکیماهای JSON).

·         راهنما: به اصل «ورودی کثیف، خروجی کثیف» و لزوم فیلترینگ در مرزهای سیستم فکر کنید.

سوال ۲۹

·         سوال: مفهوم Data Dictionary (دیکشنری داده) چیست و چه تفاوتی با پایگاه‌داده واقعی دارد؟

·         پاسخ مورد انتظار: دیکشنری داده یک مستند تحلیلی (متاداده) است که ساختار، نوع، محدودیت‌ها، تعاریف و روابط فیلدهای اطلاعاتی را به زبان فنی و تجاری توصیف می‌کند، در حالی که پایگاه‌داده محل ذخیره‌سازی فیزیکی خودِ این داده‌هاست.

·         راهنما: به مفهوم «داده درباره داده» یا متاداده توجه کنید.

سوال ۳۰

·         سوال: در طراحی سیستم‌های توزیع‌شده، تحلیل‌گر چگونه با چالش همگام‌سازی داده‌ها (Data Synchronization) مواجه می‌شود؟

·         پاسخ مورد انتظار: با تعیین استراتژی‌های به‌روزرسانی؛ او باید مشخص کند که آیا سیستم نیاز به همگام‌سازی آنی (Real-time) دارد یا همگام‌سازی دوره‌ای و نهایتاً سازگار (Eventual Consistency) برای بیزینس کفایت می‌کند.

·         راهنما: به نیازهای بیزینس از نظر حساسیت زمان و تاخیر مجاز در به‌روزرسانی داده‌ها نگاه کنید.

بخش هفتم: مدیریت ذینفعان و استخراج نیازمندی‌ها

سوال ۳۱

·         سوال: در مواجهه با ذینفعانی که خودشان دقیقاً نمی‌دانند چه می‌خواهند، بهترین تکنیک استخراج نیازمندی‌ها چیست؟

·         پاسخ مورد انتظار: استفاده از تکنیک «نمونه‌سازی سریع» (Prototyping) یا وایرفریم‌های تعاملی. دیدن یک طرح بصری ملموس به ذینفعان کمک می‌کند تا ایده بهتری پیدا کنند و نیازهای واقعی خود را بروز دهند.

·         راهنما: روی تبدیل مفاهیم انتزاعی به ابزارهای بصری و ملموس تمرکز کنید.

سوال ۳۲

·         سوال: تحلیل‌گر سیستم چگونه نیازمندی‌های متناقض دو دپارتمان مختلف (مثلاً فروش و حسابداری) را در یک سیستم واحد هم‌راستا می‌کند؟

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

·         راهنما: به نقش تسهیل‌گری و بی‌آطرف بودن تحلیل‌گر در حل مناقشات سازمانی توجه کنید.

سوال ۳۳

·         سوال: مفهوم ماتریس قدرت/علاقه (Power/Interest Matrix) در مدیریت ذینفعان چیست و چه کاربردی برای تحلیل‌گر دارد؟

·         پاسخ مورد انتظار: ابزاری است برای دسته‌بندی ذینفعان بر اساس میزان نفوذ و اهمیت آن‌ها در پروژه. این ماتریس مشخص می‌کند تحلیل‌گر چقدر زمان و چه نوع استراتژی ارتباطی (مدیریت نزدیک، مطلع نگه داشتن و...) برای هر گروه بگذارد.

·         راهنما: به بهینه‌سازی کانال‌های ارتباطی بر اساس وزن ذینفعان فکر کنید.

سوال ۳۴

·         سوال: در جلسات طوفان فکری (Brainstorming) برای استخراج نیازمندی‌ها، نقش اصلی تحلیل‌گر سیستم چیست؟

·         پاسخ مورد انتظار: نقش تسهیل‌کننده (Facilitator)؛ او باید فضا را برای ایده پردازی باز کند، مانع قضاوت‌های زودهنگام فنی شود، جلسه‌ را در مسیر اهداف نگه دارد و در نهایت ایده‌ها را دسته‌بندی و مستند کند.

·         راهنما: به عدم سرکوب ایده‌ها در مراحل اولیه و مدیریت پویایی جلسه توجه کنید.

سوال ۳۵

·         سوال: خطرات تکیه انحصاری بر روش «پرسشنامه» برای جمع‌آوری نیازمندی‌ها چیست؟

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

·         راهنما: به محدودیت‌های ارتباطات یک‌طرفه و بدون تعامل فکر کنید.

بخش هشتم: طراحی واسط کاربری و مستندسازی رفتار سیستم

سوال ۳۶

·         سوال: تفاوت بین یک وایرفریم (Wireframe) کم‌جزئیات (Low-Fidelity) و پرجزئیات (High-Fidelity) در چیست و هرکدام در چه مرحله‌ای استفاده می‌شوند؟

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

·         راهنما: به میزان تمرکز روی «ساختار رفتار» در مقابل «جزئیات بصری» نگاه کنید.

سوال ۳۷

·         سوال: یک سند سناریوی Use Case (مشخصات مورد استفاده) حداقل باید شامل چه بخش‌های کلیدی باشد؟

·         پاسخ مورد انتظار: نام یوزکیس، بازیگران (Actors)، پیش‌شرط‌ها (Pre-conditions)، پس‌شرط‌ها (Post-conditions)، جریان اصلی (Main Flow)، جریان‌های جایگزین (Alternative Flows) و جریان‌های استثنا (Exception Flows).

·         راهنما: به تمام مسیرهایی که یک کاربر ممکن است برای رسیدن یا نرسیدن به هدفش طی کند فکر کنید.

سوال ۳۸

·         سوال: تحلیل‌گر سیستم چگونه بین خطای سیستمی (System Error) و خطای کاربری (User Error) در طراحی پیام‌های خطا تفکیک قائل می‌شود؟

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

·         راهنما: به تجربه کاربری (UX) و حفظ امنیت اطلاعات فنی سیستم توجه کنید.

سوال ۱۹

·         سوال: مفهوم «قوانین کسب‌وکار» (Business Rules) چیست و چرا نباید آن‌ها را مستقیماً داخل سناریوهای رابط کاربری ترکیب کرد؟

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

·         راهنما: به اصل جداسازی منطق بیزینس از لایه نمایش (Presentation Layer) فکر کنید.

سوال ۴۰

·         سوال: در طراحی فرآیندهای گام‌به‌گام (Wizards) پیچیده، تحلیل‌گر چگونه مانع خستگی و رها کردن فرآیند توسط کاربر می‌شود؟

·         پاسخ مورد انتظار: با طراحی شاخص‌های پیشرفت (Progress Indicators)، ذخیره‌سازی خودکار اطلاعات وارد شده در هر گام (Draft Saving)، دسته‌بندی منطقی فیلدها و به حداقل رساندن ورودی‌های اجباری غیرضروری.

·         راهنما: به بهینه‌سازی تجربه کاربری در فرم‌های طولانی توجه کنید.

بخش نهم: یکپارچه‌سازی، تست و فرآیندهای گذار

سوال ۴۱

·         سوال: نقش تحلیل‌گر سیستم در زمان طراحی و مستندسازی APIها برای یکپارچه‌سازی (Integration) با سیستم‌های ثالث چیست؟

·         پاسخ مورد انتظار: او وظیفه نگاشت داده‌ها (Data Mapping)، تعیین فرمت درخواست‌ها و پاسخ‌ها، مدیریت کدهای خطا، مشخص کردن متدهای احراز هویت و تعریف سناریوهای ناموفق ارتباطی را بر عهده دارد.

·         راهنما: به توافق‌نامه‌های فنی بین دو سیستم مستقل (قرارداد API) فکر کنید.

سوال ۴۲

·         سوال: تفاوت اصلی بین تست پذیرش کاربر (UAT) و تست سیستم (System Testing) چیست و تحلیل‌گر در کدام‌یک نقش فعال‌تری دارد؟

·         پاسخ مورد انتظار: تست سیستم توسط تیم QA انجام می‌شود تا فنی و بدون باگ بودن کدها تایید شود؛ اما UAT توسط کاربران نهایی انجام می‌شود تا انطباق با نیازهای واقعی بازار تایید گردد. تحلیل‌گر در UAT نقش کلیدی در هماهنگی و هدایت کاربران دارد.

·         راهنما: به تفاوت تایید از دیدگاه «صحت فنی» در برابر «برآورده شدن نیاز بیزینس» توجه کنید.

سوال ۴۳

·         سوال: استراتژی «گذار سیستم» (System Migration) به روش موازی (Parallel Running) چه مزایا و معایبی دارد؟

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

·         راهنما: به بده‌بستان بین امنیت عملیاتی و هزینه‌های جاری سازمان نگاه کنید.

سوال ۴۴

·         سوال: مفهوم «تست رگرسیون» (Regression Testing) چیست و تحلیل‌گر چگونه در ماتریس ردیابی خود به این تست کمک می‌کند؟

·         پاسخ مورد انتظار: تستی است برای اطمینان از اینکه تغییرات یا قابلیت‌های جدید، بخش‌های قدیمی و سالم سیستم را خراب نکرده باشند. ماتریس ردیابی (RTM) به تیم تست نشان می‌دهد هر تغییر روی کدام بخش‌ها و نیازمندی‌های وابسته اثر می‌گذارد تا همان بخش‌ها مجدد تست شوند.

·         راهنما: به اثرات جانبی ناشی از تغییرات جدید در سیستم‌های مستقر شده فکر کنید.

سوال ۴۵

·         سوال: تحلیل‌گر سیستم چگونه سناریوهای استثنا در فرآیند مهاجرت داده‌ها (Data Migration) از سیستم قدیمی به جدید را پیش‌بینی می‌کند؟

·         پاسخ مورد انتظار: با اجرای تحلیل گپ (Gap Analysis) روی اسکیماهای داده، شناسایی داده‌های کثیف یا ناقص در سیستم قدیمی، تعریف قواعد پیش‌فرض برای فیلدهای اجباری جدید و نوشتن اسکریپت‌های تبدیل و پاک‌سازی داده‌ها قبل از انتقال نهایی.

·         راهنما: به تفاوت‌های ساختاری بانک‌های اطلاعاتی قدیمی و جدید توجه کنید.

بخش دهم: ارزیابی سیستم، متاداده و تفکر ساختاری

سوال ۴۶

·         سوال: تکنیک تحلیل SWOT در ارزیابی یک ایده یا سیستم نرم‌افزاری جدید، چگونه به تحلیل‌گر دید همه‌جانبه می‌دهد؟

·         پاسخ مورد انتظار: با بررسی نقاط قوت (Strengths) و ضعف (Weaknesses) داخلی سیستم در کنار فرصت‌ها (Opportunities) و تهدیدهای (Threats) محیط بیرونی، تا مشخص شود ایده چقدر پتانسیل موفقیت و چه ریسک‌هایی دارد.

·         راهنما: به تفکیک فاکتورهای درونی سیستم از فاکتورهای کلان محیطی فکر کنید.

سوال ۴۷

·         سوال: مفهوم «تحلیل تاثیر» (Impact Analysis) قبل از اعمال یک تغییر در سیستم چیست؟

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

·         راهنما: به جلوگیری از غافلگیری تیم فنی در مواجهه با درخواست‌های به ظاهر کوچک توجه کنید.

سوال ۴۸

·         سوال: در سیستم‌های مبتنی بر معماری میکروسرویس، چالش اصلی تحلیل‌گر سیستم در ردیابی جریان فرآیندها چیست؟

·         پاسخ مورد انتظار: از آنجا که فرآیندها بین چندین سرویس مستقل و مجزا توزیع شده‌اند، ردیابی یک تراکنش واحد سخت است. تحلیل‌گر باید طراحی شناسه پیگیری یکتا (Correlation ID) را در مستندات بگنجاند تا جریان داده در تمام سرویس‌ها قابل پیگیری باشد.

·         راهنما: به از دست رفتن یکپارچگی خطی فرآیندها در معماری‌های توزیع‌شده فکر کنید.

سوال ۴۹

·         سوال: یک تحلیل‌گر سیستم چگونه تفاوت بین یک «مشکل بیزینسی» و یک «نشانه خطا» را در فاز عیب‌یابی سیستم تشخیص می‌دهد؟

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

·         راهنما: به تفاوت درمان موقت علائم در برابر حل ریشه‌ای مشکلات ساختاری نگاه کنید.

سوال ۵۰

·         سوال: اهمیت مستندسازی تصمیمات معماری (ADR) برای تیم‌های آینده‌ای که روی سیستم کار خواهند کرد چیست؟

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

·         راهنما: به حفظ دانش فنی پروژه و انتقال تاریخچه تصمیمات کلیدی به آیندگان توجه کنید.

مبحث ۱: نقش تحلیل‌گر سیستم و تعاملات سازمانی (The Role of the Systems Analyst)

سوال ۱

• سوال: با توجه به مفهوم «پل ارتباطی بین دنیای کسب‌وکار و فناوری»، یک تحلیل‌گر سیستم چگونه باید تعارض میان یک نیازمندی با ارزش تجاری بالا و یک محدودیت جدی در معماری زیرساخت را مدیریت کند؟

• پاسخ مورد انتظار: با هدایت فرآیند کشف، تحلیل هزینه-فایده، بررسی بده‌بستان‌ها (Trade-offs) و تدوین گزینه‌های فنی جایگزین؛ سپس برگزاری جلسه مشترک با ذینفعان جهت رسیدن به راه‌حلی متوازن و مستند بدون ایجاد بدهی فنی شدید.

• راهنما: به نقش تحلیل‌گر در تسهیل ارتباطات بین تیم فنی و تجاری توجه کنید.

سوال ۲

• سوال: بر اساس زنجیره ارزش پروژه، تفاوت بنیادین در خروجی‌های مستندسازی یک تحلیل‌گر کسب‌وکار (BA) و یک تحلیل‌گر سیستم (SA) چیست؟

• پاسخ مورد انتظار: خروجی BA متمرکز بر «چیستی و چراایی» نیازها در قالب اسناد اهداف تجاری است؛ اما خروجی SA متمرکز بر «چگونگی پیاده‌سازی فنی» در قالب اسناد طراحی سیستم، DFDها، مشخصات یوزکیس‌ها و وایرفریم‌ها به عنوان نقشه مهندسی است.

• راهنما: به قیاس مالک خانه (BA) در برابر مهندس سازه (SA) فکر کنید.

سوال ۳

• سوال: زمانی که تیم فنی به دلیل محدودیت‌های زمانی تمایلی به مطالعه مستندات تحلیل ندارد، تحلیل‌گر سیستم از چه تکنیک‌هایی برای انتقال موثر نیازمندی‌ها استفاده می‌کند؟

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

• راهنما: روی روش‌های ساده‌سازی و بصری‌سازی اطلاعات تمرکز کنید.

سوال ۴

• سوال: یک تحلیل‌گر سیستم چگونه می‌تواند مرز وظایف خود را با معمار نرم‌افزار (Software Architect) شفاف کند تا از تداخل کاری جلوگیری شود؟

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

• راهنما: به تفاوت میان «منطق رفتار سیستم» و «ساختار زیربنایی کد» توجه کنید.

سوال ۵

• سوال: در یک پروژه چابک (Agile)، نقش تحلیل‌گر سیستم در فرآیند پالایش بک‌لاگ (Backlog Refinement) چیست؟

• پاسخ مورد انتظار: او به عنوان بازوی فنی مالک محصول عمل کرده، نیازمندی‌های بزرگ را به داستان‌های کاربر (User Stories) کوچک‌تر می‌شکند، وابستگی‌های فنی بین بخش‌ها را کشف می‌کند و معیارهای پذیرش شفاف می‌نویسد.

• راهنما: به آماده‌سازی داستان‌ها برای ورود به اسپرینت توجه کنید.

سوال ۶

• سوال: تحلیل‌گر سیستم چگونه می‌تواند از ایجاد انتظارات غیرواقعی در ذینفعان کسب‌وکار جلوگیری کند؟

• پاسخ مورد انتظار: با درگیر کردن زودهنگام تیم فنی در جلسات استخراج نیازمندی‌ها، ارائه وایرفریم‌های اولیه و شفاف‌سازی محدودیت‌های تکنولوژی و بودجه در اسناد صورت‌مسئله.

• راهنما: به مدیریت انتظارات از طریق شفافیت فنی نگاه کنید.

سوال ۷

• سوال: اهمیت نگهداری یک «واژه‌نامه زنده از اصطلاحات» (Living Glossary) توسط تحلیل‌گر سیستم در طول چرخه حیات پروژه چیست؟

• پاسخ مورد انتظار: ایجاد یک زبان مشترک (Ubiquitous Language) بین تیم فنی و کسب‌وکار، جلوگیری از سوءتفاهم در تعریف مفاهیم داده‌ای و تضمین این که کدهای نرم‌افزاری دقیقاً منطق بیزینس را پیاده‌سازی می‌کنند.

• راهنما: به نقش واژه‌نامه به عنوان مرجع واحد اطلاعات (Single Source of Truth) فکر کنید.

سوال ۸

• سوال: در صورت تغییر ناگهانی مدیر پروژه یا ذینفعان کلان، مستندات تحلیل‌گر سیستم چگونه به حفظ پایداری پروژه کمک می‌کند؟

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

• راهنما: به حفظ دانش فنی و انتقال تاریخچه تصمیمات پروژه توجه کنید.

سوال ۹

• سوال: چرا یک تحلیل‌گر سیستم باید علاوه بر مهارت‌های فنی، به مهارت‌های نرم (Soft Skills) مسلط باشد؟

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

• راهنما: به نقش تحلیل‌گر به عنوان یک تسهیل‌کننده و مذاکره‌کننده نگاه کنید.

سوال ۱۰

• سوال: نقش تحلیل‌گر سیستم در ارزیابی آمادگی سازمان (Organizational Readiness) برای استقرار یک نرم‌افزار جدید چیست؟

• پاسخ مورد انتظار: تحلیل فرآیندهای فعلی (As-Is)، شناسایی شکاف مهارت‌های کاربران، ارزیابی مقاومت در برابر تغییر و ارائه‌ پیشنهادهای آموزشی و مستندات راهنما برای انتقال نرم به فرآیندهای جدید (To-Be).

• راهنما: به مدیریت تغییرات انسانی و ساختاری در سازمان توجه کنید.

سوال ۱۱

• سوال: چگونه یک تحلیل‌گر سیستم تضمین می‌کند که ارزش تجاری تعریف‌شده توسط BA در محصول نهایی پیاده‌سازی شده است؟

• پاسخ مورد انتظار: با متصل کردن نیازمندی‌های کارکردی سیستم به اهداف تجاری در ماتریس ردیابی (RTM) و ردیابی آن‌ها تا فاز تست‌های پذیرش نهایی (UAT).

• راهنما: به فرآیند قابلیت ردیابی (Traceability) نگاه کنید.

سوال ۱۲

• سوال: در سیستم‌های توزیع‌شده یا میکروسرویس، تعامل تحلیل‌گر سیستم با مهندسان DevOps حول چه محورهایی شکل می‌گیرد؟

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

• راهنما: به نیازمندی‌های مرزی بین منطق نرم‌افزار و زیرساخت توجه کنید.

سوال ۱۳

• سوال: چرا مشارکت تحلیل‌گر سیستم در فاز تایید نتایج در محیط عملیاتی (Production) ضروری است؟

• پاسخ مورد انتظار: برای اطمینان از این که رفتار سیستم در زیر بار واقعی با مستندات تحلیل همخوانی دارد و معیارهای موفقیت تعریف‌شده در ابتدای پروژه کاملاً محقق شده‌اند.

• راهنما: به حضور تحلیل‌گر در تمام فازهای چرخه عمر نرم‌افزار فکر کنید.

سوال ۱۴

• سوال: یک تحلیل‌گر سیستم چگونه تعادل بین مستندسازی جامع (Comprehensive Documentation) و سرعت توسعه را برقرار می‌کند؟

• پاسخ مورد انتظار: با تمرکز بر مستندسازی چابک (Just-in-time & Just-enough)؛ یعنی مستند کردن بخش‌های پیچیده، تصمیمات کلیدی معماری و ساختارهای داده، و پرهیز از نوشتن جزئیات بدیهی که با کدخوانی قابل درک هستند.

• راهنما: به بهینه‌سازی حجم مستندات بر اساس پیچیدگی سیستم توجه کنید.

سوال ۱۵

• سوال: در مواجهه با یک «جعبه سیاه» فنی (سیستم قدیمی بدون مستندات)، رویکرد تحلیل‌گر برای استخراج نیازمندی‌ها چیست؟

• پاسخ مورد انتظار: استفاده از مهندسی معکوس (Reverse Engineering)، تحلیل رفتاری ورودی‌ها و خروجی‌ها، لاگ‌خوانی سیستم قدیمی و مصاحبه با کاربران کلیدی که سال‌ها با آن کار کرده‌اند.

• راهنما: به روش‌های کشف اطلاعات از سیستم‌های مجهول فکر کنید.

سوال ۱۶

• سوال: نقش تحلیل‌گر سیستم در تعریف معیارهای موفقیت (Success Criteria) پروژه در فاز صفر چیست؟

• پاسخ مورد انتظار: تبدیل اهداف کیفی مدیریت به شاخص‌های کلیدی عملکرد (KPI) کمی و قابل اندازه‌گیری در نرم‌افزار، تا در پایان پروژه بتوان موفقیت سیستم را به طور عینی سنجید.

• راهنما: به سنجش‌پذیر کردن اهداف پروژه توجه کنید.

سوال ۱۷

• سوال: یک تحلیل‌گر سیستم چگونه ریسک تعامل با سیستم‌های ثالث (Third-party APIs) را در فاز تحلیل مدیریت می‌کند؟

• پاسخ مورد انتظار: با بررسی مستندات فنی سیستم ثالث، تست لایو متدها در لایه پایلوت، ثبت سناریوهای عدم پاسخ‌دهی (Timeout) و تعریف مکانیزم‌های جایگزین (Fallback) در مستندات طراحی.

• راهنما: به مدیریت وابستگی‌های خارجی سیستم نگاه کنید.

سوال ۱۸

• سوال: تفاوت نگاه تحلیل‌گر سیستم با توسعه‌دهنده (Developer) نسبت به یک نیازمندی چیست؟

• پاسخ مورد انتظار: تحلیل‌گر سیستم به تاثیر نیازمندی بر کل فرآیند بیزینس، کاربران و سایر ماژول‌ها نگاه می‌کند (کل‌نگر)، در حالی که توسعه‌دهنده بر چگونگی پیاده‌سازی بهینه، الگوریتم‌ها و ساختار کد آن ماژول تمرکز دارد (جزء‌نگر).

• راهنما: به تفاوت دیدگاه سیستماتیک و دیدگاه پیاده‌سازی فکر کنید.

سوال ۱۹

• سوال: تحلیل‌گر سیستم چگونه از بروز تداخل بین نیازمندی‌های موازی در پروژه‌های چندتیمی جلوگیری می‌کند؟

• پاسخ مورد انتظار: با تشکیل جلسات هماهنگی بین‌تیمی (Scrum of Scrums)، بررسی ماتریس وابستگی‌ها و معماری ماژولار جریان داده‌ها تا تغییرات یک تیم باعث شکست کدهای تیم دیگر نشود.

• راهنما: به مدیریت یکپارچگی در پروژه‌های بزرگ نگاه کنید.

سوال ۲۰

• سوال: مفهوم «تفکر سیستمی» (Systems Thinking) در عملکرد یک تحلیل‌گر به چه معناست؟

• پاسخ مورد انتظار: درک این نکته که نرم‌افزار یک موجودیت مستقل نیست، بلکه جزیی از یک کل بزرگ‌تر (شامل انسان‌ها، فرآیندها و ساختار سازمانی) است و تغییر در هر بخش، رفتارهای موجی در کل سازمان ایجاد می‌کند.

• راهنما: به تحلیل اثرات جانبی و تعاملی سیستم بر محیط پیرامون توجه کنید.

مبحث ۲: مهندسی نیازمندی‌ها و مدیریت ابهام (Requirements Engineering)

سوال ۲۱

• سوال: یکی از الگوهای ضدکاربردی (Anti-patterns) رایج، «گرایش زودهنگام به راه‌حل‌محوری فنی» است. این پدیده چه آسیبی به کیفیت مهندسی نیازمندی‌ها می‌زند و راهکار پیشگیری از آن چیست؟

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

• راهنما: به پیامدهای فرار از ابهام‌زدایی صورت‌مسئله توجه کنید.

سوال ۲۲

• سوال: تکنیک «پنج چرا» (5 Whys) در فاز استخراج نیازمندی‌ها چه کاربردی دارد و چگونه جلوی درخواست‌های سطحی ذینفعان را می‌گیرد؟

• پاسخ مورد انتظار: این تکنیک با تکرار سوال «چرا» به تحلیل‌گر کمک می‌کند تا از لایه درخواست‌های ظاهری کاربر عبور کرده و به علت ریشه‌ای و نیاز واقعی کسب‌وکار برسد تا راه‌حل به جای نشانه‌ها، علت اصلی را حل کند.

• راهنما: به تفاوت میان «خواسته کاربر» و «نیاز واقعی کاربر» نگاه کنید.

سوال ۲۳

• سوال: معیار تاییدپذیری یا تست‌پذیری (Testability) یک نیازمندی به چه معناست و تحلیل‌گر چگونه آن را در مستندات خود تضمین می‌کند؟

• پاسخ مورد انتظار: یعنی نیازمندی باید به گونه‌ای نوشته شود که تیم تضمین کیفیت بتواند با اجرای یک تست عینی، پاس یا فیل شدن آن را مشخص کند. تحلیل‌گر این کار را با حذف کلمات مبهم (مانند سریع، امن، کاربرپسند) و جایگزینی آن‌ها با اعداد و معیارهای سنجش‌پذیر انجام می‌دهد.

• راهنما: به نحوه تبدیل توصیف‌های کیفی به معیارهای عددی فکر کنید.

سوال ۲۴

• سوال: روش MoSCoW در اولویت‌بندی نیازمندی‌ها چیست و چگونه به مدیریت محدوده پروژه کمک می‌کند؟

• پاسخ مورد انتظار: نیازمندی‌ها را به چهار دسته حیاتی (Must have)، مهم اما غیرحیاتی (Should have)، ترجیحی (Could have) و غیرضروری در حال حاضر (Won't have) تقسیم می‌کند. این کار به تیم اجازه می‌دهد در شرایط کمبود زمان، روی بخش‌های حیاتی تمرکز کند.

• راهنما: به مدیریت هوشمندانه محدوده پروژه در شرایط بحران زمانی نگاه کنید.

سوال ۲۵

• سوال: در فرآیند مهندسی نیازمندی‌ها، تفاوت بین فعالیت الاستیشن (Elicitation) و آنالیز (Analysis) چیست؟

• پاسخ مورد انتظار: الاستیشن فرآیند جمع‌آوری، استخراج و کشف نیازمندی‌ها از زبان ذینفعان است (مانند مصاحبه)؛ اما آنالیز، فرآیند پالایش، دسته‌بندی، مدل‌سازی، حل تعارضات و بررسی امکان‌پذیری فنی کارهای جمع‌آوری شده است.

• راهنما: به تفاوت فاز «کشف و دریافت» در برابر فاز «پردازش و مدل‌سازی» توجه کنید.

سوال ۲۶

• سوال: مفهوم «ماتریس ردیابی نیازمندی‌ها» (RTM) چیست و چه کمکی به مدیر پروژه و تیم تست می‌کند؟

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

• راهنما: به قابلیت ردیابی دوطرفه (Forward & Backward Traceability) نگاه کنید.

سوال ۲۷

• سوال: یک نیازمندی مبهم مانند «سیستم باید گزارشات را به سرعت تولید کند» را چگونه به یک نیازمندی مهندسی‌شده تبدیل می‌کنید؟

• پاسخ مورد انتظار: تبدیل به فرمت کمی: «سیستم باید تمامی گزارشات داشبورد مدیریتی را در شرایط بارگذاری استاندارد (تا ۱۰۰ کاربر همزمان) در زمانی کمتر از ۳ ثانیه تولید و نمایش دهد.»

• راهنما: به حذف صفات کیفی و جایگزینی با معیارهای عددی توجه کنید.

سوال ۲۸

• سوال: تکنیک پروتوتایپینگ (Prototyping) یا نمونه‌سازی سریع چه زمانی در مهندسی نیازمندی‌ها به عنوان ابزار ابهام‌زدایی استفاده می‌شود؟

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

• راهنما: به نقش مدل‌های ملموس در کاهش سوءتفاهم‌ها نگاه کنید.

سوال ۲۹

• سوال: چالش «نیازمندی‌های پنهان» (Hidden/Implicit Requirements) چیست و تحلیل‌گر چگونه آن‌ها را کشف می‌کند؟

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

• راهنما: به کشف فرضیات ناگفته کاربران توجه کنید.

سوال ۳۰

• سوال: در مهندسی نیازمندی‌ها، منظور از «تحلیل گپ» (Gap Analysis) چیست؟

• پاسخ مورد انتظار: بررسی و مقایسه وضعیت موجود فرآیندها و سیستم‌ها (As-Is) با وضعیت مطلوب و آینده (To-Be) جهت شناسایی دقیق کمبودها، ویژگی‌ها و کارهایی که باید برای رسیدن به هدف انجام شوند.

• راهنما: به پل زدن میان وضعیت فعلی و آینده نرم‌افزار فکر کنید.

سوال ۳۱

• سوال: چرا بازبینی رسمی مستندات نیازمندی‌ها (Requirements Review/Sign-off) یک نقطه عطف حیاتی در پروژه است؟

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

• راهنما: به نقش تاییدیه به عنوان مرز رسمی شروع فاز طراحی نگاه کنید.

سوال ۳۲

• سوال: چگونه تحلیل‌گر سیستم از بروز تعارضات ساختاری در اسناد نیازمندی‌های چند دپارتمان جلوگیری می‌کند؟

• پاسخ مورد انتظار: با مدل‌سازی فرآیندهای متقاطع (Cross-functional) با نمودارهای شناوری (Swimlane DFDs)، مشخص کردن دقیق مالکان داده‌ها و نقاط انتقال اطلاعات بین دپارتمان‌ها.

• راهنما: به یکپارچه‌سازی فرآیندهای سازمانی توجه کنید.

سوال ۳۳

• سوال: مفهوم «داستان کاربر» (User Story) در مهندسی نیازمندی‌های چابک چه فرمت استانداردی دارد و چرا از سه بخش تشکیل شده است؟

• پاسخ مورد انتظار: فرمت: «به عنوان یک [نقش]، من می‌خواهم [خواسته] تا بتوانم [ارزش تجاری]». این فرمت تضمین می‌کند که ذینفع، هدف و ارزش افزوده پشت هر نیازمندی کاملاً شفاف و مشخص است.

• راهنما: به فرمت استاندارد داستان کاربر فکر کنید.

سوال ۳۴

• سوال: تکنیک کارگاه‌های مشترک (JAD Sessions) چه مزیتی نسبت به مصاحبه‌های انفرادی در استخراج نیازمندی‌ها دارد؟

• پاسخ مورد انتظار: سرعت بالای جمع‌آوری اطلاعات، حل آنی تعارضات بین ذینفعان مختلف در طول جلسه، افزایش همسویی و تایید سریع‌تر نیازمندی‌ها به دلیل حضور همزمان تصمیم‌گیرندگان.

• راهنما: به مزایای کار تیمی و همزمان در مهندسی نیازمندی‌ها نگاه کنید.

سوال ۳۵

• سوال: یک تحلیل‌گر چگونه نیازمندی‌های ناشی از «قوانین بالادستی و رگولاتوری» (مانند قوانین مالیاتی یا بانکی) را مدیریت می‌کند؟

• پاسخ مورد انتظار: با استخراج این قوانین به عنوان «قوانین کسب‌وکار» مستقل (Business Rules)، مستندسازی مراجع قانونی آن‌ها و طراحی سیستم به گونه‌ای که این قوانین از منطق برنامه تفکیک شده تا تغییرات آن‌ها به راحتی اعمال شود.

• راهنما: به پایداری سیستم در برابر تغییرات قانونی توجه کنید.

سوال ۳۶

• سوال: چرا نیازمندی‌های نوشته شده در سند نیازمندی‌ها نباید حاوی کلماتی مثل «یا»، «احتمالاً» یا «در صورت امکان» باشند؟

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

• راهنما: به اصل قاطعیت و صراحت در نگارش نیازمندی‌ها توجه کنید.

سوال ۳۷

• سوال: مفهوم «سناریوی منفی» (Negative/Misuse Case) در آنالیز نیازمندی‌ها چیست؟

• پاسخ مورد انتظار: توصیف رفتارهایی که سیستم نباید اجازه انجام آن‌ها را به کاربران بدهد (مانند تلاش برای دسترسی به داده‌های مالی دیگران)؛ این کار به مهندسی نیازمندی‌های امنیتی و کنترل خطا کمک می‌کند.

• راهنما: به تحلیل رفتارهای مخرب یا ناخواسته در سیستم نگاه کنید.

سوال ۳۸

• سوال: تحلیل‌گر سیستم چگونه فرضیات (Assumptions) و محدودیت‌ها (Constraints) را از نیازمندی‌های واقعی تفکیک می‌کند؟

• پاسخ مورد انتظار: محدودیت‌ها فاکتورهای غیرقابل تغییری هستند که توسط محیط یا تکنولوژی تحمیل می‌شوند (مثل بودجه یا دیتابیس خاص)؛ فرضیات عواملی هستند که برای پیشبرد کار درست فرض می‌شوند اما نیاز به تایید دارند، در حالی که نیازمندی‌ها رفتارهای درخواستی از خود سیستم هستند.

• راهنما: به تفاوت عوامل محیطی با کارکردهای نرم‌افزار توجه کنید.

سوال ۳۹

• سوال: چرا تغییر نیازمندی‌ها در متدولوژی‌های چابک پذیرا دانسته می‌شود اما همچنان به مدیریت نیاز دارد؟

• پاسخ مورد انتظار: چابکی به معنای استقبال از تغییر برای هماهنگی با بازار است، اما تغییرات بی‌ضابطه باعث از هم پاشیدن تمرکز اسپرینت جاری می‌شود؛ لذا تغییرات جدید باید وارد بک‌لاگ شده، اولویت‌بندی شوند و در اسپرینت‌های بعدی قرار گیرند.

• راهنما: به تعادل بین چابکی و انضباط فرآیندی نگاه کنید.

سوال ۴۰

• سوال: فرآیند اعتبارسنجی نیازمندی‌ها (Requirements Validation) به چه سوال اصلی پاسخ می‌دهد؟

• پاسخ مورد انتظار: به این سوال که: «آیا ما داریم سیستم درستی را می‌سازیم؟» یعنی آیا مستندات نگارش‌شده دقیقاً همان چیزی است که نیاز واقعی کاربران و کسب‌وکار را برطرف می‌کند یا خیر.

• راهنما: به تفاوت اعتبارسنجی (ساخت سیستم درست) با تایید صحت (درست ساختن سیستم) توجه کنید.

مبحث ۳: نیازمندی‌های غیرعملکردی و ویژگی‌های کیفی (Non-Functional Requirements)

سوال ۴۱

• سوال: چرا نیازمندی‌های غیرعملکردی (NFR) را به عنوان «محدودیت‌های سیستم» (System Constraints) نیز می‌شناسند؟

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

• راهنما: به نقش NFRها در تعیین مرزها و استانداردهای حرکتی سیستم توجه کنید.

سوال ۴۲

• سوال: تفاوت اصلی بین مقیاس‌پذیری عمقی (Vertical Scaling) و مقیاس‌پذیری افقی (Horizontal Scaling) در تحلیل سیستم چیست؟

• پاسخ مورد انتظار: مقیاس‌پذیری عمقی یعنی افزایش قدرت یک سرور واحد (مثل ارتقای RAM یا CPU)، اما مقیاس‌پذیری افقی یعنی اضافه کردن سرورهای بیشتر به شبکه تا بار کاری توزیع شود. تحلیل‌گر باید ساختار داده را متناسب با مدل افقی طراحی کند تا گره کور ایجاد نشود.

• راهنما: به تفاوت ارتقای سخت‌افزار یک دستگاه در برابر تکثیر دستگاه‌ها نگاه کنید.

سوال ۴۳

• سوال: معیار «پایداری سیستم در برابر خطا» (Fault Tolerance) به چه معناست و چه تفاوتی با لایه‌ی امنیت دارد؟

• پاسخ مورد انتظار: پایداری در برابر خطا یعنی توانایی سیستم برای ادامه‌ی کارکرد (حتی با راندمان کمتر) در زمان خرابی بخشی از سخت‌افزار یا نرم‌افزار؛ در حالی که امنیت متمرکز بر جلوکیری از دسترسی‌های غیرمجاز و حملات مخرب است.

• راهنما: به زنده ماندن سیستم در شرایط بحران‌های فنی داخلی فکر کنید.

سوال ۴۴

• سوال: مفهوم «قابلیت جابجایی» (Portability) در سیستم‌های نرم‌افزاری چیست و تحلیل‌گر چگونه آن را مستند می‌کند؟

• پاسخ مورد انتظار: به میزان سادگی انتقال نرم‌افزار از یک محیط (مثلاً یک سیستم‌عامل یا ابر سخت‌افزاری) به محیط دیگر گفته می‌شود. تحلیل‌گر با ملزم کردن تیم فنی به استفاده از تکنولوژی‌های مستقل از پلتفرم (مانند داکر)، این معیار را تضمین می‌کند.

• راهنما: به عدم وابستگی نرم‌افزار به یک لایه‌ی سخت‌افزاری خاص توجه کنید.

سوال ۴۵

• سوال: تحلیل‌گر سیستم چگونه شاخص زمان بازیابی (RTO) و شاخص نقطه‌ی بازیابی (RPO) را در نیازمندی‌های پشتیبان‌گیری تبیین می‌کند؟

• پاسخ مورد انتظار: شاخص RTO حداکثر زمان مجاز برای بالا آمدن سیستم پس از خرابی است، و RPO حداکثر حجم داده‌ای است که سازمان می‌تواند در صورت بروز حادثه از دست بدهد (مثلاً داده‌های ۲ ساعت گذشته).

• راهنما: به تفاوت «زمان قطع بودن سیستم» در برابر «میزان داده‌های از دست رفته» نگاه کنید.

سوال ۴۶

• سوال: مفهوم «دسترسی‌پذیری همه‌جانبه» (Accessibility) در نیازمندی‌های غیرعملکردی به چه گروه از کاربران اشاره دارد؟

• پاسخ مورد انتظار: طراحی سیستم به گونه‌ای که افراد دارای ناتوانی‌های جسمی (مانند نابینایان یا کم‌بینایان) نیز بتوانند با ابزارهای کمکی (مثل صفحه‌خوان‌ها) از نرم‌افزار به راحتی استفاده کنند.

• راهنما: به استانداردهای جهانی وب برای دسترسی همگانی فکر کنید.

سوال ۴۷

• سوال: چرا نادیده گرفتن نیازمندی «قابلیت مانیتورینگ» (Observability) فرآیند پشتیبانی نرم‌افزار را در محیط عملیاتی با بحران مواجه می‌کند؟

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

• راهنما: به اهمیت شفافیت رفتار داخلی سیستم در زمان اجرای واقعی توجه کنید.

سوال ۴۸

• سوال: مفهوم قانون حفاظت از داده‌ها (مانند GDPR یا قوانین حریم خصوصی بومی) چه تأثیری بر تحلیل سیستم‌های ذخیره‌سازی اطلاعات دارد؟

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

• راهنما: به الزامات قانونی و حقوقی در لایه‌ی مهندسی داده نگاه کنید.

سوال ۴۹

• سوال: تفاوت بین دو شاخص عملکردی Throughput (نرخ پردازش) و Latency (تأخیر) در تحلیل کارایی سیستم چیست؟

• پاسخ مورد انتظار: نرخ پردازش یعنی سیستم در یک واحد زمانی مشخص چه تعداد تراکنش را می‌تواند پردازش کند (مثلاً ۵۰۰ تراکنش در ثانیه)، اما تأخیر یعنی زمان سپری‌شده برای پاسخ به یک درخواست واحد از سمت کاربر.

• راهنما: به تفاوت حجم کارِ خروجی در برابر سرعت پاسخ‌دهی انفرادی توجه کنید.

سوال ۵۰

• سوال: تحلیل‌گر سیستم چگونه نیازمندی‌های مرتبط با «قابلیت ممیزی» (Audit Trail) را در سیستم‌های مالی پیاده‌سازی می‌کند؟

• پاسخ مورد انتظار: با طراحی یک جدول لاگِ غیرقابل تغییر که هرگونه ایجاد، ویرایش یا حذف داده‌های مالی را با ذکر دقیق شناسه کاربر، مهر زمانی (Timestamp) و مقدار قبل و بعد از تغییر ثبت کند.

• راهنما: به زنجیره‌ی ردیابی رفتارهای کاربران در سیستم‌های حساس نگاه کنید.

سوال ۵۱

• سوال: مفهوم Concurrency (همزمانی) در تحلیل سیستم چه چالشی را برای پایگاه‌داده ایجاد می‌کند و نیازمندی آن چیست؟

• پاسخ مورد انتظار: چالش دسترسی همزمان چند کاربر به یک ردیف داده‌ی واحد (مثل خرید آخرین بلیت هواپیما). نیازمندی غیرعملکردی سیستم در اینجا، تعریف مکانیزم‌های قفل‌گذاری (Locking) جهت حفظ یکپارچگی داده‌هاست.

• راهنما: به پیشگیری از تداخل داده‌ها در ثانیه‌های بحرانی فکر کنید.

سوال ۵۲

• سوال: چرا «امنیت ایستا» در فاز تحلیل کافی نیست و سیستم باید امنیت در حال حرکت (Security in Transit) را هم پوشش دهد؟

• پاسخ مورد انتظار: زیرا داده‌ها در طول شبکه مابین مرورگر کاربر و سرور در جریان هستند و اگر رمزنگاری نشوند (مثلاً عدم استفاده از HTTPS)، هکرها می‌توانند اطلاعات را در میانه‌ی راه سرقت کنند.

• راهنما: به محافظت از داده‌ها در زمان جابجایی بین لایه‌های مختلف نگاه کنید.

سوال ۵۳

• سوال: معیار «قابلیت استفاده مجدد» (Reusability) در تحلیل ماژول‌های سیستم چه ارزش افزوده‌ای دارد؟

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

• راهنما: به جلوگیری از دوباره‌کاری در کدنویسی‌های سازمانی فکر کنید.

سوال ۵۴

• سوال: یک سیستم نرم‌افزاری چگونه می‌تواند شاخص «تجربه‌ی کاربری یکپارچه» (UI Consistency) را به عنوان یک نیازمندی غیرعملکردی تضمین کند؟

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

• راهنما: به همسانی المان‌ها، رنگ‌ها و فونت‌ها در کل سیستم توجه کنید.

سوال ۵۵

• سوال: مفهوم Extensibility (قابلیت توسعه‌پذیری) در تحلیل سیستم به چه معناست؟

• پاسخ مورد انتظار: ساختار سیستم باید به گونه‌ای منعطف طراحی شود که در آینده بتوان قابلیت‌ها یا ماژول‌های جدید را با کمترین تغییر در کدهای قدیمی و بدون آسیب به پایداری سیستم اضافه کرد.

• راهنما: به آمادگی معماری نرم‌افزار برای پذیرش تغییرات بزرگ آینده نگاه کنید.

سوال ۵۶

• سوال: تحلیل‌گر سیستم چگونه محدودیت پهنای باند شبکه را در نیازمندی‌های برنامه‌های موبایل لحاظ می‌کند؟

• پاسخ مورد انتظار: با ملزم کردن سیستم به فشرده‌سازی داده‌های ارسالی، استفاده از مکانیزم‌های کش کردن اطلاعات (Caching) روی گوشی کاربر و طراحی سناریوهای آفلاین برای زمان قطع بودن اینترنت.

• راهنما: به بهینه‌سازی مصرف داده در سمت کاربر فکر کنید.

سوال ۵۷

• سوال: شاخص MTTF (میانگین زمان تا بروز اولین خرابی) در بررسی کیفیت سیستم نشان‌دهنده‌ی چیست؟

• پاسخ مورد انتظار: این شاخص معیاری برای سنجش قابلیت اطمینان سیستم‌های غیرقابل تعمیر یا قطعات حیاتی است و نشان می‌دهد سیستم به طور متوسط چقدر بدون نقص به کار خود ادامه می‌دهد.

• راهنما: به پایداری و طول عمر کارکرد بدون خطای نرم‌افزار توجه کنید.

سوال ۵۸

• سوال: مفهوم «مستندات مرجع» (Documentation Quality) به عنوان یک ویژگی غیرعملکردی، چه تأثیری بر طول عمر سیستم دارد؟

• پاسخ مورد انتظار: تضمین می‌کند که با رفتن اعضای قدیمی تیم، دانش فنی سیستم حفظ شده و فرآیند ورود نیروهای جدید (Onboarding) و توسعه‌های آتی با سرعت بالا و خطای کم انجام می‌شود.

• راهنما: به زنده نگه داشتن دانش فنی پروژه در بستر زمان نگاه کنید.

سوال ۵۹

• سوال: چالش تعارض بین امنیت (Security) و قابلیت استفاده (Usability) را در تحلیل سیستم چگونه حل می‌کنید؟

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

• راهنما: به ایجاد توازن بین سخت‌گیری‌های امنیتی و راحتی کار با سیستم توجه کنید.

سوال ۶۰

• سوال: نیازمندی غیرعملکردی مرتبط با «پشتیبانی از چند زبانی» (Localization/i18n) چه الزاماتی را به طراحی پایگاه‌داده تحمیل می‌کند؟

• پاسخ مورد انتظار: الزام به ذخیره‌سازی متون دینامیک سیستم (مثل نام محصولات) در جداول چندزبانه یا به صورت فرمت‌های ساختاریافته (مثل JSON)، تدارک فونت‌های متناسب و پشتیبانی از جهت‌های راست‌به‌چپ (RTL) و چپ‌به‌راست (LTR).

• راهنما: به فراتر رفتن از ترجمه‌ی ساده و تغییرات ساختاری در ظاهر و دیتابیس نگاه کنید.

مبحث ۴: مدل‌سازی فرآیندها و ابزارهای تحلیلی (Process Modeling & Diagramming)

سوال ۶۱

• سوال: چرا نمودار جریان داده (DFD) یک مدل فرآیندی است و نه یک مدل کنترلی یا برنامه‌نویسی؟

• پاسخ مورد انتظار: چون DFD حرکت داده‌ها، منابع ذخیره‌سازی، ورودی‌ها، خروجی‌ها و فرآیندهای دگرگون‌کننده‌ی داده را نشان می‌دهد و هیچ اطلاعاتی درباره‌ی حلقه‌ها (Loops)، شرط‌های برنامه‌نویسی یا توالی زمانی اجرای دستورات ارائه نمی‌دهد.

• راهنما: به تفاوت جریان داده با منطق و دستورات کدنویسی فکر کنید.

سوال ۶۲

• سوال: فرآیند «موازنه کردن نمودار» (Balancing DFD) در تبدیل سطح صفر به سطح یک به چه معناست؟

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

• راهنما: به قانون بقای ورودی‌ها و خروجی‌ها در شکستن سطوح نمودار توجه کنید.

سوال ۶۳

• سوال: کاربرد موجودیت خارجی (External Entity) در DFD چیست و آیا سیستم می‌تواند روی رفتار آن کنترلی داشته باشد؟

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

• راهنما: به مرزبندی دقیق بین فضای داخل سیستم و دنیای بیرون نگاه کنید.

سوال ۶۴

• سوال: چرا اتصال مستقیم دو انبار داده (Data Store) به یکدیگر یا اتصال مستقیم دو موجودیت خارجی به هم در نمودار DFD یک خطای تحلیلی (Syntax Error) است؟

• پاسخ مورد انتظار: چون انبار داده و موجودیت خارجی پسیو هستند و توانایی حرکت دادن یا پردازش خودکار داده را ندارند. هرگونه جابجایی یا انتقال داده در DFD حتماً باید از طریق یک «فرآیند اکتیو» (Process) انجام شود.

• راهنما: به لزوم وجود یک موتور پردازشی برای جابجایی اطلاعات فکر کنید.

سوال ۶۵

• سوال: تفاوت کلیدی بین نمودار فعالیت (Activity Diagram) در UML و نمودار جریان داده (DFD) چیست؟

• پاسخ مورد انتظار: نمودار فعالیت روی جریان کار (Workflow)، ترتیب اقدامات، تصمیم‌گیری‌ها و موازی‌سازی فعالیت‌ها تمرکز دارد؛ در حالی که DFD صرفاً متمرکز بر نحوه‌ی تبدیل و حرکت داده‌ها بین اجزا است.

• راهنما: به تفاوت «جریان کار و فرآیند اجرایی» در برابر «جریان اطلاعات» توجه کنید.

سوال ۶۶

• سوال: در نمودار Use Case، منظور از بازیگر (Actor) چیست و آیا یک آکتور لزوماً یک انسان است؟

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

• راهنما: به نقش تعامل‌کننده با سیستم به جای هویت فیزیکی آن نگاه کنید.

سوال ۶۷

• سوال: خطای تحلیلی موسوم به «سیاه‌چاله» (Black Hole) در طراحی فرآیندهای DFD چیست؟

• پاسخ مورد انتظار: زمانی رخ می‌دهد که یک فرآیند در نمودار، جریان‌های داده‌ی ورودی متعددی دارد، اما هیچ جریان خروجی از آن خارج نمی‌شود. این یعنی داده‌ها وارد فرآیند شده اما ناپدید می‌شوند.

• راهنما: به لزوم تولید خروجی منطقی به ازای ورودی‌های یک فرآیند توجه کنید.

سوال ۶۸

• سوال: خطای تحلیلی موسوم به «معجزه» (Miracle) در فرآیندهای DFD به چه معناست؟

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

• راهنما: به غیرممکن بودن خلق داده از هیچ نگاه کنید.

سوال ۶۹

• سوال: کاربرد اصلی جدول تصمیم‌گیری (Decision Table) در اسناد تحلیلی چیست و چه زمانی از آن استفاده می‌شود؟

• پاسخ مورد انتظار: زمانی استفاده می‌شود که قوانین کسب‌وکار حاوی شرایط متعدد و پیچیده‌ای هستند که ترکیب آن‌ها خروجی‌های متفاوتی ایجاد می‌کند. این جدول مانع از جا افتادن حالت‌های خاص (Edge Cases) در تحلیل می‌شود.

• راهنما: به فرموله‌کردن منطق‌های شرطی پیچیده به صورت ماتریسی فکر کنید.

سوال ۷۰

• سوال: در نمودار کلاس (Class Diagram)، تفاوت بین رابطه‌ی تجمیع (Aggregation) و ترکیب (Composition) چیست؟

• پاسخ مورد انتظار: در تجمیع، طول عمر شیء وابسته به کلاس اصلی نیست و می‌تواند مستقل وجود داشته باشد (مثل استاد و دانشگاه)؛ اما در ترکیب، شیء فرعی بدون کلاس اصلی معنا ندارد و با نابودی آن نابود می‌شود (مثل اتاق و ساختمان).

• راهنما: به شدت وابستگی چرخه عمر اشیاء به یکدیگر توجه کنید.

سوال ۷۱

• سوال: نمودار توالی (Sequence Diagram) عمدتاً چه بعدی از سیستم را مدل‌سازی می‌کند و چرا برای توسعه‌دهندگان جذاب است؟

• پاسخ مورد انتظار: بعد پویا و زمانی سیستم را مدل‌سازی می‌کند. این نمودار ترتیب دقیق پیام‌های ردوبدل شده بین اشیاء را در طول زمان نشان می‌دهد و عملاً ساختار کدنویسی متدها را برای برنامه‌نویس ترسیم می‌کند.

• راهنما: به ترتیب خط زمانی تعاملات اجزای سیستم نگاه کنید.

سوال ۷۲

• سوال: مفهوم «پیام بازگشتی» (Return Message) در نمودار توالی چیست و آیا ترسیم آن همیشه اجباری است؟

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

• راهنما: به جریان برگشت اطلاعات پس از اتمام یک کارکرد توجه کنید.

سوال ۷۳

• سوال: در نمودار Use Case، استفاده بیش از حد از روابط Includes و Extends نشان‌دهنده‌ی چه مشکل تحلیلی است؟

• پاسخ مورد انتظار: نشان‌دهنده‌ی این است که تحلیل‌گر دچار دیدگاه برنامه‌نویسی و ریزدانه (Functional Decomposition) شده و یوزکیس‌ها را به جای عملکردهای کلان و کاربردی، به توابع کوچکِ کدنویسی شکسته است.

• راهنما: به حفظ سطح انتزاع یوزکیس‌ها برای فهم مشترک بیزینس و فنی نگاه کنید.

سوال ۷۴

• سوال: نمودار استقرار (Deployment Diagram) در UML چه هدفی را دنبال می‌کند و خروجی آن به کار چه تیمی می‌آید؟

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

• راهنما: به نقشه‌برداری فیزیکی نرم‌افزار بر روی سخت‌افزارهای واقعی فکر کنید.

سوال ۷۵

• سوال: تفاوت نمادگذاری بین جریان داده (Data Flow) و جریان فرآیند کاری (Control Flow) در ابزارهای مدل‌سازی چیست؟

• پاسخ مورد انتظار: جریان داده انتقال بسته‌های اطلاعاتی را نشان می‌دهد (مثل ارسال فاکتور)، در حالی که جریان کنترل نشان می‌دهد بعد از اتمام یک اقدام، کدام اقدام بعدی باید آغاز شود بدون اینکه لزوماً داده‌ای جابجا شود.

• راهنما: به تفاوت «حرکت محتوا» در برابر «حرکت توالی کارها» توجه کنید.

سوال ۷۶

• سوال: در مدل‌سازی فرآیندهای کسب‌وکار با استاندارد BPMN، کاربرد لِین‌ها (Lanes) در یک استخر (Pool) چیست؟

• پاسخ مورد انتظار: لِین‌ها تفکیک‌کننده‌ی وظایف و مسئولیت‌های نقش‌ها یا دپارتمان‌های مختلف درون یک سازمان واحد هستند و مشخص می‌کنند هر فعالیت توسط چه کسی انجام می‌شود.

• راهنما: به تقسیم خطوط افقی یا عمودی نمودار بر اساس جایگاه‌های سازمانی نگاه کنید.

سوال ۷۷

• سوال: دروازه منطقی انحصاری (Exclusive Gateway - XOR) در مدل‌سازی فرآیندها چه رفتاری را نشان می‌دهد؟

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

• راهنما: به انشعاب‌های تک‌مسیره بر اساس بله/خیرهای منطقی توجه کنید.

سوال ۷۸

• سوال: چرا نمودار حالت (State Diagram) برای سیستم‌های گردش کار (Workflow Systems) حیاتی است؟

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

• راهنما: به کنترل رفتارهای سیستم بر اساس وضعیت‌های تاریخی موجودیت‌ها فکر کنید.

سوال ۷۹

• سوال: مفهوم «رویداد تایمر» (Timer Event) در مدل‌سازی فرآیندها چیست و یک نمونه از کاربرد آن را بیان کنید.

• پاسخ مورد انتظار: رویدادی است که پس از سپری شدن یک زمان مشخص یا در یک تاریخ معین به طور خودکار ماشه فرآیند را می‌کشد؛ مثل: «اگر مشتری تا ۴۸ ساعت فاکتور را پرداخت نکرد، سفارش را خودکار لغو کن».

• راهنما: به نقش زمان به عنوان عامل محرک و بدون دخالت انسان نگاه کنید.

سوال ۸۰

• سوال: اصطلاح «تحلیل ساختاریافته» (Structured Analysis) چه تفاوتی با «تحلیل شیءگرا» (Object-Oriented Analysis) در حوزه مدل‌سازی دارد؟

• پاسخ مورد انتظار: تحلیل ساختاریافته سیستم را به صورت مجموعه‌ای از فرآیندها و داده‌های مجزا می‌بیند (تمرکز بر DFD)، در حالی که تحلیل شیءگرا داده و فرآیند را در قالب موجودیت‌های واحدی به نام «شیء» ترکیب می‌کند (تمرکز بر UML).

• راهنما: به تفاوت نگاه فرآیندمحور در مقابل نگاه موجودیت‌محور توجه کنید.

مبحث ۵: تحلیل داده‌ها و ساختار اطلاعاتی (Data Analysis & Information Architecture)

سوال ۸۱

• سوال: در نمودار ارتباط موجودیت‌ها (ERD)، منظور از درجه‌ی ارتباط (Cardinality) چیست؟

• پاسخ مورد انتظار: مشخص می‌کند که چند نمونه از یک موجودیت می‌تواند با چند نمونه از موجودیت دیگر در ارتباط باشد؛ که شامل انواع یک‌به‌یک (1:1)، یک‌به‌چند (1:N) و چند‌به‌چند (M:N) است.

• راهنما: به تعیین سقف و کف روابط عددی بین ساختارهای داده نگاه کنید.

سوال ۸۲

• سوال: چرا روابط چندبه‌چند (M:N) در فاز طراحی منطقی پایگاه‌داده باید شکسته شوند و راهکار تحلیل‌گر چیست / ؟

• پاسخ مورد انتظار: چون پایگاه‌داده‌های رابطه‌ای امکان پیاده‌سازی مستقیم این رابطه را ندارند. تحلیل‌گر با معرفی یک «موجودیت واسط» (Associative Entity) آن را به دو رابطه‌ی یک‌به‌چند تبدیل می‌کند.

• راهنما: به تبدیل جدول پیوند برای ذخیره‌سازی کلیدهای خارجی دبل فکر کنید.

سوال ۸۳

• سوال: مفهوم کلید اصلی (Primary Key) و کلید خارجی (Foreign Key) و نقش آن‌ها در یکپارچگی مرجع (Referential Integrity) چیست؟

• پاسخ مورد انتظار: کلید اصلی شناسه منحصربه‌فرد هر ردیف در یک جدول است. کلید خارجی فیلدی در جدول دوم است که به کلید اصلی جدول اول اشاره می‌کند و مانع از ثبت داده‌های بی‌مرجع و یتیم در سیستم می‌شود.

• راهنما: به برقراری زنجیره پیوند و اصالت داده‌ها بین جداول توجه کنید.

سوال ۸۴

• سوال: تفاوت بین موجودیت قوی (Strong Entity) و موجودیت ضعیف (Weak Entity) در مدل‌سازی داده‌ها چیست؟

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

• راهنما: به وابستگی هویتی و چرخه عمر داده‌های فرعی به اصلی نگاه کنید.

سوال ۸۵

• سوال: نرم‌افزار در فرم اول نرمال (1NF) باید چه شرط پایه‌ای را پاس کند؟

• پاسخ مورد انتظار: تمام فیلدهای جدول باید حاوی مقادیر اتمیک (تک‌مقداری و غیرقابل تقسیم) باشند و هیچ گروه تکرار شونده یا فیلدی با چند مقدار همزمان (مثل فیلد شماره تلفن‌ها در یک سلول) وجود نداشته باشد.

• راهنما: به یکپارچه‌سازی و سلول‌های تک‌مقداری در ساختار دیتابیس توجه کنید.

سوال ۸۶

• سوال: شرط ورود یک جدول به فرم دوم نرمال (2NF) چیست و چه مشکلی را حل می‌کند؟

• پاسخ مورد انتظار: جدول باید ابتدا در 1NF باشد و هیچ فیلد غیرکلیدی نباید وابستگی جزئی به بخشی از کلید اصلی ترکیبی داشته باشد (وابستگی کامل تابعی). این کار مانع از افزونگی داده‌ها می‌شود.

• راهنما: به مستقل کردن فیلدها از تکه‌های کلیدهای ترکیبی فکر کنید.

سوال ۸۷

• سوال: مفهوم وابستگی انتقالی (Transitive Dependency) در فرم سوم نرمال (3NF) چیست؟

• پاسخ مورد انتظار: وضعیتی است که در آن یک فیلد غیرکلیدی، واسطه و وابسته به یک فیلد غیرکلیدی دیگر است و آن فیلد دوم به کلید اصلی وصل است. در 3NF باید این روابط واسطه‌ای حذف و به جدول مستقل منتقل شوند.

• راهنما: به قطع دسترسی‌های غیرمستقیم فیلدها به کلید اصلی نگاه کنید.

سوال ۸۸

• سوال: منظور از افزونگی داده‌ها (Data Redundancy) چیست و چه خطراتی برای تراکنش‌های سیستم دارد؟

• پاسخ مورد انتظار: ذخیره‌سازی تکراری یک داده‌ی واحد در چندین جای مختلف دیتابیس. خطرات آن شامل هدر رفتن فضا و ایجاد تضاد اطلاعاتی در زمان به‌روزرسانی است (تغییر در یک جا و جا ماندن در جای دیگر).

• راهنما: به چالش عدم یکپارچگی داده‌ها در زمان ویرایش فکر کنید.

سوال ۸۹

• سوال: تفاوت کاربردی بین دیتابیس‌های رابطه‌ای (SQL) و غیررابطه‌ای (NoSQL) از دیدگاه تحلیل‌گر سیستم چیست؟

• پاسخ مورد انتظار: دیتابیس‌های SQL دارای اسکیمای صلب و مناسب برای تراکنش‌های پیچیده مالی و یکپارچه هستند؛ دیتابیس‌های NoSQL بدون اسکیما، بسیار مقیاس‌پذیر و مناسب برای داده‌های حجیم، بدون ساختار یا مستندات پویا هستند.

• راهنما: به بده‌بستان بین نظم ساختاری و انعطاف‌پذیری حجم داده‌ها توجه کنید.

سوال ۹۰

• سوال: مفهوم انبار داده (Data Warehouse) چیست و چه تفاوتی با پایگاه‌داده عملیاتی (OLTP) دارد؟

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

• راهنما: به تفاوت سیستم‌های «ثبت‌کننده تراکنش» در برابر سیستم‌های «تحلیل‌گر داده» نگاه کنید.

سوال ۹۱

• سوال: فیلد پویا یا مشتق‌شده (Derived Attribute) در تحلیل داده‌ها چیست و آیا باید در دیتابیس ذخیره شود؟

• پاسخ مورد انتظار: فیلدی است که مقدار آن از روی سایر داده‌ها قابل محاسبه است (مثل سن از روی تاریخ تولد). معمولاً برای جلوگیری از تضاد داده‌ای ذخیره نمی‌شود و در زمان اجرا محاسبه می‌گردد، مگر برای بهینه‌سازی کارایی در لودهای سنگین.

• راهنما: به فرمول‌محور بودن داده‌ها و عدم نیاز به ذخیره‌سازی فیزیکی فکر کنید.

سوال ۹۲

• سوال: مفهوم شاخص‌گذاری (Indexing) در دیتابیس چیست و تحلیل‌گر چه نیازمندی را برای آن تعیین می‌کند؟

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

• راهنما: به بده‌بستان بین سرعت خواندن داده در برابر سرعت نوشتن داده نگاه کنید.

سوال ۹۳

• سوال: تفاوت بین یک ویژگی چندمقداری (Multi-valued Attribute) و یک ویژگی ترکیبی (Composite Attribute) در ERD چیست؟

• پاسخ مورد انتظار: ویژگی چندمقداری می‌تواند چند مقدار همزمان داشته باشد (مثل مهارت‌های یک کارمند)، اما ویژگی ترکیبی از چند بخش مجزا تشکیل شده که با هم معنا پیدا می‌کنند (مثل آدرس شامل استان، شهر و کوچه).

• راهنما: به تفاوت تکثر مقادیر در برابر تکه‌تکه بودن یک مفهوم واحد توجه کنید.

سوال ۹۴

• سوال: تحلیل‌گر سیستم چگونه امنیت داده‌های حساس (مثل گذرواژه‌ها) را در لایه‌ی مستندات داده‌ای تضمین می‌کند؟

• پاسخ مورد انتظار: با درج الزام اجباری برای استفاده از الگوهای رمزنگاری یک‌طرفه (Hashing همراه با Salt) در مستندات دیکشنری داده، به طوری که حتی مدیران دیتابیس هم به پسورد واقعی دسترسی نداشته باشند.

• راهنما: به تفاوت رمزنگاری‌های قابل بازگشت با هک‌های یک‌طرفه امنیتی نگاه کنید.

سوال ۹۵

• سوال: مفهوم «پاک‌سازی داده‌ها» (Data Cleansing) در فاز پیش از مهاجرت به سیستم جدید به چه معناست؟

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

• راهنما: به آماده‌سازی کیفیت محتوا قبل از جابجایی ساختاری پایگاه‌های داده فکر کنید.

سوال ۹۶

• سوال: منظور از اقلام داده‌ای تهی (Null Values) چیست و تحلیل‌گر چطور فیلدهای اجباری را در سیستم مشخص می‌کند؟

• پاسخ مورد انتظار: مقدار Null یعنی داده‌ای وجود ندارد یا ناشناخته است. تحلیل‌گر با استفاده از قید NOT NULL در دیکشنری داده، فیلدهای حیاتی و اجباری بیزینس (مثل شماره همراه در ثبت نام) را فیکس می‌کند.

• راهنما: به تمایز میان فضای خالی (Blank) و عدم وجود هویتی داده (Null) توجه کنید.

سوال ۹۷

• سوال: مفهوم لایه‌ی دسترسی به داده (DAL) در مستندات معماری منطقی سیستم چیست؟

• پاسخ مورد انتظار: لایه‌ای که کدهای برنامه‌نویسی را از دستورات مستقیم دیتابیس جدا می‌کند. این کار باعث می‌شود اگر نوع دیتابیس در آینده تغییر کرد (مثلاً از اوراکل به پستگرس)، کدهای اصلی بیزینس نیازی به بازنویسی نداشته باشند.

• راهنما: به اصل استقلال منطق نرم‌افزار از موتورهای ذخیره‌سازی داده نگاه کنید.

سوال ۹۸

• سوال: در سیستم‌های توزیع‌شده، مفهوم «پیدایش جزیره‌ای داده‌ها» چیست و چگونه در فاز تحلیل از آن پیشگیری می‌شود؟

• پاسخ مورد انتظار: زمانی رخ می‌دهد که بخش‌های مختلف سیستم بدون هماهنگی، نسخه‌های متفاوتی از یک داده را ذخیره کنند. پیشگیری از آن با تعریف یک سیستم مرجع (Master Data Management) و مکانیزم‌های سینک آنی انجام می‌شود.

• راهنما: به حفظ یکپارچگی اطلاعات در سیستم‌های چندتکه فکر کنید.

سوال ۹۹

• سوال: نقش ابزارهای ORM (Object-Relational Mapping) از دیدگاه هماهنگی مدل‌های تحلیلی و پیاده‌سازی چیست؟

• پاسخ مورد انتظار: ابزاری است که کلاس‌های شیءگرا در مدل تحلیل (UML) را به طور خودکار به جداول رابطه‌ای دیتابیس (ERD) نگاشت می‌کند و پل ارتباطی بین تفکر شیءگرا و ساختار بانک اطلاعاتی است.

• راهنما: به ترجمه کدهای برنامه به زبان جداول دیتابیس نگاه کنید.

سوال ۱۰۰

• سوال: مفهوم داده‌های غیرساختاریافته (Unstructured Data) چیست و سیستم برای مدیریت آن‌ها به چه ساختاری نیاز دارد؟

• پاسخ مورد انتظار: داده‌هایی که فرمت یا جدول‌بندی مشخصی ندارند، مثل فایل‌های ویدیویی، تصاویر، یا صداهای ضبط‌شده. سیستم برای این موارد به جای جداول سنتی، به سیستم‌های ذخیره‌سازی فایل (Object Storage) یا دیتابیس‌های سندی نیاز دارد.

• راهنما: به تفاوت ذخیره اعداد و متون در برابر فایل‌های چندرسانه‌ای غول‌پیکر توجه کنید.

مبحث ۶: طراحی رابط کاربری و سناریونویسی سیستم (UI Design & Use Case Specification)

سوال ۱۰۱

• سوال: چرا در نگارش سناریوی یوزکیس (Use Case Specification)، توصیف اقدامات باید به زبان بیزینس باشد و نه کدهای فرانت‌اند؟

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

• راهنما: به تمرکز بر «منطق تعامل کاربر با سیستم» به جای ابزارهای برنامه‌نویسی فکر کنید.

سوال ۱۰۲

• سوال: مفهوم «جریان جایگزین» (Alternative Flow) در سناریوی یوزکیس چه تفاوتی با «جریان استثنا» (Exception Flow) دارد؟

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

• راهنما: به تفاوت «رسیدن به هدف از راه دیگر» در برابر «شکست و خروج از فرآیند» نگاه کنید.

سوال ۱۰۳

• سوال: پیش‌شرط (Pre-condition) در مستند یوزکیس چه کاربردی دارد و سیستم قبل از اجرای سناریو چه وظیفه‌ای دارد؟

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

• راهنما: به گیت‌های ورودی فرآیندها برای تضمین صحت وضعیت سیستم توجه کنید.

سوال ۱۰۴

• سوال: مفهوم پس‌شرط (Post-condition) در یوزکیس چیست و چرا برای تیم تضمین کیفیت (QA) اهمیت حیاتی دارد؟

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

• راهنما: به بررسی تغییرات نهایی سیستم پس از خروج کاربر نگاه کنید.

سوال ۱۰۵

• سوال: در طراحی رابط کاربری، اصل «تأیید اقدامات مخرب» (Destructive Action Confirmation) چیست و تحلیل‌گر چگونه آن را پیاده می‌کند؟

• پاسخ مورد انتظار: الزامی است که سیستم در زمان انجام کارهای غیرقابل بازگشت (مثل حذف یک پروژه)، یک لایه‌ی هشدار صریح (Pop-up Modal) به کاربر نشان دهد و تاییدیه مجدد (یا حتی تایپ کلمه‌ی حذف) را طلب کند تا جلوی خطاهای سهوی گرفته شود.

• راهنما: به ایجاد ترمزهای ایمنی در مسیر رفتارهای اشتباه کاربران فکر کنید.

سوال ۱۰۶

• سوال: مفهوم افوردنس (Affordance) یا «قابلیت دسترسی ادراکی» در طراحی صفحات سیستم به چه معناست؟

• پاسخ مورد انتظار: ظاهر یک المان باید کارکرد آن را داد بزند؛ یعنی دکمه باید شبیه چیزی باشد که می‌توان روی آن کلیک کرد، و متن ساده نباید ظاهری شبیه به لینک‌های قابل کلیک داشته باشد تا کاربر دچار خطای ادراکی نشود.

• راهنما: به راهنمایی بصری پنهان در فرم و شکل المان‌های رابط کاربری توجه کنید.

سوال ۱۰۷

• سوال: قانون گشتالت در خصوص «اصل مجاورت» (Law of Proximity) چه کاربردی در طراحی فرم‌های پیچیده سیستمی دارد؟

• پاسخ مورد انتظار: المان‌ها یا فیلدهایی که از نظر منطقی به هم وابسته‌اند (مثل فیلدهای آدرس) باید در یک کادر مجزا و نزدیک به هم قرار گیرند تا ذهن کاربر آن‌ها را به عنوان یک واحد منسجم دسته‌بندی کند.

• راهنما: به گروه‌بندی بصری اطلاعات برای کاهش خستگی ذهنی کاربران نگاه کنید.

سوال ۱۰۸

• سوال: مفهوم «بار شناختی» (Cognitive Load) در UI چیست و تحلیل‌گر چگونه آن را در فرآیند ثبت اطلاعات کاهش می‌دهد؟

• پاسخ مورد انتظار: میزان حجم پردازش ذهنی است که برای درک یک صفحه به کاربر تحمیل می‌شود. تحلیل‌گر با شکستن فرم‌های طولانی به فرآیندهای چندگام‌پذیر (Wizards)، پنهان کردن فیلدهای اختیاری و استفاده از مقادیر پیش‌فرض هوشمند، این بار را کم می‌کند.

• راهنما: به ساده‌سازی صفحات برای تسهیل تصمیم‌گیری سریع کاربران فکر کنید.

سوال ۱۰۹

• سوال: چرا در طراحی سیستم‌های اداری و پنل‌های درون‌سازمانی، کارایی و سرعت کیبورد (Keyboard Navigation) بر زیبایی گرافیکی ارجحیت دارد؟

• پاسخ مورد انتظار: چون اپراتورهای سازمانی روزانه صدها فرم را ثبت می‌کنند و جابجایی مداوم دست بین موس و کیبورد سرعت آن‌ها را به شدت کاهش می‌دهد. سیستم باید امکان حرکت بین تمام فیلدها را با دکمه Tab و ثبت با Enter فراهم کند.

• راهنما: به بهینه‌سازی سرعت عملیاتی کاربران حرفه‌ای در دپارتمان‌های شلوغ نگاه کنید.

سوال ۱۱۰

• سوال: مفهوم «رابط کاربری واکنش‌گرا» (Responsive UI) چه الزاماتی را در فاز مستندسازی سناریوها ایجاد می‌کند؟

• پاسخ مورد انتظار: تحلیل‌گر باید مشخص کند که چیدمان المان‌ها، منوها و جداول بزرگ داده در دسکتاپ، چگونه در صفحات کوچک موبایل شکسته، خلاصه یا پنهان می‌شوند بدون اینکه کارکرد اصلی بیزینس از دست برود.

• راهنما: به انعطاف‌پذیری نمایش اطلاعات در ابعاد مختلف نمایشگرها توجه کنید.

سوال ۱۱۱

• سوال: چرا در زمان طراحی پیام‌های خطای سیستم، نباید از کدهای خطای خام دیتابیس (مثل SQL Error 504) استفاده کرد؟

• پاسخ مورد انتظار: اولاً باعث سردرگمی و ترس کاربران غیرفنی می‌شود؛ ثانیاً اطلاعات ساختاری دیتابیس را لو می‌دهد که یک گپ امنیتی است. پیام باید ساده، راهنما و حاوی یک کد پیگیری عمومی باشد.

• راهنما: به حفظ امنیت سیستم و رعایت حریم درک کاربران نگاه کنید.

سوال ۱۱۲

• سوال: مفهوم «دکمه‌های فراخوان به اقدام» (CTA - Call to Action) چیست و تحلیل‌گر چه استانداردی برای آن‌ها در صفحات اصلی ست می‌کند؟

• پاسخ مورد انتظار: دکمه‌های اصلی که هدف نهایی صفحه را محقق می‌کنند (مثل ثبت نهایی خرید). این دکمه‌ها باید دارای رنگ متمایز، اندازه‌ی بزرگ‌تر و در موقعیت‌های دیدرسِ بدون نیاز به اسکرول (Above the Fold) قرار گیرند.

• راهنما: به هدایت ناخودآگاه چشم کاربر به سمت اهداف تجاری صفحه فکر کنید.

سوال ۱۱۳

• سوال: تکنیک «نقشه‌ی سفر کاربر» (User Journey Map) چه کمکی به طراحی سناریوهای سیستم می‌کند؟

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

• راهنما: به شبیه‌سازی قدم‌به‌قدم رفتارهای انسانی در مواجهه با نرم‌افزار نگاه کنید.

سوال ۱۱۴

• سوال: مفهوم «اعتبارسنجی در لحظه» (Inline Validation) در فرم‌های ورودی چیست و چه مزیتی دارد؟

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

• راهنما: به بازخورد سریع سیستم به رفتارهای کاربر در حین ثبت داده توجه کنید.

سوال ۱۱۵

• سوال: در سناریوی یوزکیس، بخش «جریان‌های موازی» (Concurrently Flows) به چه معناست؟

• پاسخ مورد انتظار: توصیف حالاتی که در آن دو فرآیند می‌توانند به طور همزمان جلو بروند بدون اینکه لزوماً یکی منتظر پایان دیگری بماند؛ مثل فرآیند دانلود یک گزارش سنگین در حین ادامه‌ی گشت‌وگذار در منوهای سیستم.

• راهنما: به رفتارهای چندوظیفه‌ای نرم‌افزار در لایه‌ی کاربری نگاه کنید.

سوال ۱۱۶

• سوال: قانون میلر (Miller's Law) در روانشناسی رابط کاربری چه محدودیتی را برای تعداد آیتم‌های منوهای اصلی سیستم تعیین می‌کند؟

• پاسخ مورد انتظار: این قانون می‌گوید ذهن انسان به طور متوسط می‌تواند $7 \pm 2$ آیتم را در حافظه کوتاه‌مدت خود نگه دارد؛ بنابراین منوهای اصلی سیستم نباید بیش از این تعداد گزینه‌ی همسطح داشته باشند و گزینه‌های اضافه باید در دسته‌های فرعی قفل شوند.

• راهنما: به محدودیت‌های پردازش حافظه انسان در مواجهه با شلوغی صفحات توجه کنید.

سوال ۱۱۷

• سوال: مفهوم «وایرفریم تعاملی» (Interactive Prototype) چیست و چه تفاوتی با طرح گرافیکی نهایی (UI Mockup) دارد؟

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

• راهنما: به تمرکز بر تست «جریان حرکت کاربر» قبل از نهایی کردن طرح‌های هنری نگاه کنید.

سوال ۱۱۸

• سوال: تحلیل‌گر سیستم چگونه وضعیت‌های خالی (Empty States) را در صفحات داشبورد مدل‌سازی می‌کند؟

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

• راهنما: به زنده نگه داشتن تعامل سیستم با کاربران تازه‌وارد فکر کنید.

سوال ۱۱۹

• سوال: اصطلاح Breadcrumb (نشانگر مسیر) در سیستم‌های با عمق صفحات زیاد چه کاربردی برای کاربر دارد؟

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

• راهنما: به جلوگیری از گم شدن کاربران در منوهای تو در تو توجه کنید.

سوال ۱۲۰

• سوال: مفهوم «بومی‌سازی فرهنگی» (Cultural Localization) در طراحی سیستم‌های بین‌المللی فراتر از ترجمه متن شامل چه فاکتورهایی است؟

• پاسخ مورد انتظار: تغییر فرمت‌های نمایش تاریخ (شمسی/میلادی)، واحدهای پولی، ساختار نمایش نام و فامیل، نمادها و رنگ‌ها (که ممکن است در یک فرهنگ معنای متفاوتی داشته باشند) و چیدمان راست‌چین یا چپ‌چین کل ساختار صفحه.

• راهنما: به هماهنگی کامل روانشناسی نرم‌افزار با بافت جامعه هدف نگاه کنید.

مبحث ۷: متدولوژی‌های توسعه و چرخه‌ی حیات نرم‌افزار (SDLC & Methodologies)

سوال ۱۲۱

·         سوال: تفاوت بنیادین بین مدل آبشاری (Waterfall) و متدولوژی‌های چابک (Agile) در مواجهه با «تغییر نیازمندی‌ها» چیست؟

·         پاسخ مورد انتظار: در مدل آبشاری، نیازمندی‌ها در ابتدا فیکس می‌شوند و تغییر آن‌ها در اواسط پروژه بسیار هزینه‌بر و گاهی غیرممکن است؛ اما در Agile، تغییر به عنوان یک واقعیت پذیرفته شده و سیستم در قالب بازه‌های زمانی کوتاه (اسپرینت) انعطاف‌پذیری بالایی برای جذب تغییرات دارد.

·         راهنما: به تفاوت ساختار صلب و خطی در برابر ساختار چرخه‌ای و سازگارپذیر فکر کنید.

سوال ۱۲۲

·         سوال: مفهوم «حداقل محصول پذیرفتنی» (MVP) در متدولوژی‌های چابک چیست و چه کمکی به تحلیل‌گر می‌کند؟

·         پاسخ مورد انتظار: نسخه‌ای از محصول که فقط دارای ویژگی‌های حیاتی برای رفع نیاز اصلی کاربر و بقای بیزینس است. این کار به تحلیل‌گر کمک می‌کند تا بازخورد واقعی کاربران را سریع‌تر بگیرد و فرضیات تحلیلی خود را در بازار واقعی بسنجد.

·         راهنما: به راه‌اندازی سریع با کمترین امکانات برای اعتبارسنجی ایده نگاه کنید.

سوال ۱۲۳

·         سوال: در فریم‌ورک اسکرام (Scrum)، تفاوت نقش مالک محصول (Product Owner) با تحلیل‌گر سیستم در چیست؟

·         پاسخ مورد انتظار: مالک محصول متمرکز بر «چه چیزی» باید ساخته شود و اولویت‌بندی ارزش‌های تجاری است؛ اما تحلیل‌گر سیستم بیشتر روی «چگونه» کارکردن سیستم، جزئیات فنی، کشف گپ‌ها و ترجمه آن به زبان فنی تمرکز دارد.

·         راهنما: به مرز بین نگاه تجاری/مدیریتی در برابر نگاه ساختاری/سیستمی توجه کنید.

سوال ۱۲۴

·         سوال: مفهوم «بدهی فنی» (Technical Debt) در چرخه‌ی حیات پروژه چیست و تحلیل‌گر چگونه به ایجاد آن چراغ سبز نشان می‌دهد؟

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

·         راهنما: به بده‌بستان بین سرعت عرضه به بازار و کیفیت ساختار داخلی نرم‌افزار نگاه کنید.

سوال ۱۲۵

·         سوال: در متدولوژی اسکرام، مستند «بک‌لاگ محصول» (Product Backlog) چیست و لزوم پویایی آن چطور توجیه می‌شود؟

·         پاسخ مورد انتظار: لیستی اولویت‌بندی‌شده از تمام ویژگی‌ها، نیازمندی‌ها، باگ‌ها و کارهایی که باید روی محصول انجام شود. پویا بودن آن به این دلیل است که با تغییرات بازار، بازخورد کاربران و نیازهای جدید بیزینس، این لیست مدام آپدیت و جابجا می‌شود.

·         راهنما: به زنده بودن و تغییر مداوم لیست کارهای آینده‌ی پروژه فکر کنید.

سوال ۱۲۶

·         سوال: مدل حلزونی یا مارپیچ (Spiral Model) در SDLC چه زمانی کاربرد دارد و مشخصه اصلی آن چیست؟

·         پاسخ مورد انتظار: برای پروژه‌های بسیار بزرگ، گران‌قیمت و حساس کاربرد دارد. مشخصه اصلی آن «تحلیل مدام ریسک» در هر چرخه و تکرار فازهای طراحی و نمونه‌سازی قبل از ورود به فاز کدنویسی انبوه است.

·         راهنما: به تمرکز ویژه بر شناسایی و مهار ریسک‌ها در چرخه‌های تکرارشونده توجه کنید.

سوال ۱۲۷

·         سوال: مفهوم Definition of Done (DoD) در متدولوژی‌های چابک چیست و چرا تحلیل‌گر در تدوین آن نقش دارد؟

·         پاسخ مورد انتظار: یک لیست چک‌مرجع مشترک است که نشان می‌دهد یک نیازمندی به طور کامل کامل شده است (مثلاً: تست شده، کد ریویو شده و مستنداتش آپدیت شده). تحلیل‌گر برای تضمین اینکه نیازمندی‌های بیزینس کاملاً پاس شده‌اند، در نوشتن این معیارها مشارکت می‌کند.

·         راهنما: به توافق جمعی تیم بر سر تعریف کلمه‌ی «تمام شد» نگاه کنید.

سوال ۱۲۸

·         سوال: متدولوژی کانبان (Kanban) چه تفاوتی با اسکرام دارد و تمرکز اصلی آن روی چیست؟

·         پاسخ مورد انتظار: کانبان برخلاف اسکرام اسپرینت‌های زمان‌بندی‌شده صلب ندارد و یک جریان مداوم از کارهاست. تمرکز اصلی آن روی تصویرسازی فرآیند کار و «محدود کردن کار در جریان» (WIP Limit) برای پیدا کردن گلوگاه‌های تولید است.

·         راهنما: به تفاوت مدیریت مبتنی بر زمان (اسپرینت) در برابر مدیریت مبتنی بر جریان کار توجه کنید.

سوال ۱۲۹

·         سوال: چرا در مدل توسعه سنتی (Waterfall)، فاز تحویل محصول به مشتری بالاترین نرخ ریسک و شکست را دارد؟

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

·         راهنما: به خطر دوری طولانی‌مدت از مشتری در طول فرآیند تولید فکر کنید.

سوال ۱۳۰

·         سوال: مفهوم اسپایک (Spike) در متدولوژی‌های چابک چیست و تحلیل‌گر چه زمانی آن را پیشنهاد می‌دهد؟

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

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

مبحث ۸: فرآیندهای تست، کنترل کیفیت و صحه‌گذاری (Testing & Quality Assurance)

سوال ۱۳۱

·         سوال: تفاوت بین دو مفهوم Verification (تایید اصالت) و Validation (صحه‌گذاری) در کنترل کیفیت سیستم چیست؟

·         پاسخ مورد انتظار: مفهوم Verification بررسی می‌کند که آیا سیستم طبق مستندات و مشخصات فنی درست ساخته شده است یا خیر (آیا محصول را درست ساختیم؟). اما Validation بررسی می‌کند که آیا محصول ساخته‌شده واقعاً نیاز کاربر و بیزینس را رفع می‌کند (آیا محصولِ درستی ساختیم؟).

·         راهنما: به تفاوت مطابقت با کاغذ در برابر مطابقت با نیاز واقعی کاربر توجه کنید.

سوال ۱۳۲

·         سوال: تست جعبه سیاه (Black-Box Testing) چیست و تحلیل‌گر چطور بر اساس سناریوهای یوزکیس آن را طراحی می‌کند؟

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

·         راهنما: به ارزیابی رفتار بیرونی سیستم بدون درگیر شدن با کدهای پشت صحنه نگاه کنید.

سوال ۱۳۳

·         سوال: تست جعبه سفید (White-Box Testing) چه تفاوتی با جعبه سیاه دارد و مسئولیت اجرای آن با کیست؟

·         پاسخ مورد انتظار: در تست جعبه سفید، ساختار داخلی، خطوط کد، حلقه‌ها و مسیرهای منطقی برنامه به طور دقیق بررسی و تست می‌شوند. مسئولیت اجرای آن بر عهده توسعه‌دهندگان (Developers) است و نیاز به دانش کدنویسی دارد.

·         راهنما: به جراحی و کالبدشکافی کدهای داخلی نرم‌افزار برای کشف باگ‌ها فکر کنید.

سوال ۱۳۴

·         سوال: مفهوم «تست رگرسیون» (Regression Testing) چیست و چرا پس از هر تغییر یا توسعه جدید الزامی است؟

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

·         راهنما: به ضرب‌المثل «ابرویش را درست کردیم، چشمش را کور نکنیم» در دنیای نرم‌افزار توجه کنید.

سوال ۱۳۵

·         سوال: تست پذیرش کاربر (UAT - User Acceptance Testing) در چه مرحله‌ای انجام می‌شود و هدف آن چیست؟

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

·         راهنما: به تست رانندگی نهایی خریدار خودرو قبل از امضای قرارداد نگاه کنید.

سوال ۱۳۶

·         سوال: تکنیک «تحلیل مقادیر مرزی» (Boundary Value Analysis) در نوشتن تست‌کیس‌ها چیست؟

·         پاسخ مورد انتظار: تکنیکی که تمرکزش روی تست نقاط مرزی شرط‌هاست؛ چون بیشترین باگ‌ها در مرزها رخ می‌دهند (مثلاً اگر شرط سن بین ۱۸ تا ۶۵ است، فیلد را با اعداد ۱۷، ۱۸، ۱۹ و ۶۴، ۶۵، ۶۶ تست می‌کنند تا رفتارهای سیستم را بسنجند).

·         راهنما: به لغزنده بودن مرزهای منطقی در کدهای شرطی برنامه‌نویسان فکر کنید.

سوال ۱۳۷

·         سوال: تست یکپارچه‌سازی (Integration Testing) چه زمانی انجام می‌شود و چه چیزی را هدف قرار می‌دهد؟

·         پاسخ مورد انتظار: پس از اتمام تست‌های واحد (Unit Tests). هدف این تست ارزیابی نحوه تعامل، ارتباط و ردوبدل شدن درست داده‌ها بین ماژول‌های مختلف سیستم یا بین سیستم ما و سیستم‌های بانکی/خارجی است.

·         راهنما: به تست هماهنگی اعضای ارکستر پس از تمرین‌های انفرادی نگاه کنید.

سوال ۱۳۸

·         سوال: تفاوت بین تست بار (Load Testing) و تست استرس (Stress Testing) در ارزیابی کارایی سیستم چیست؟

·         پاسخ مورد انتظار: تست بار بررسی رفتار سیستم تحت حجم کارِ مورد انتظار و نرمال است (مثلاً حضور ۱۰۰۰ کاربر همزمان)؛ اما تست استرس افزایش بار تا مرز شکستن سیستم است تا ببینند نقطه سقوط سیستم کجاست و چطور بازیابی می‌شود.

·         راهنما: به تفاوت تحمل وزن استاندارد در برابر تست زیر بار له شدن نگاه کنید.

سوال ۱۳۹

·         سوال: مفهوم «باگ تحلیلی» (Analysis Defect) چیست و چرا هزینه‌ی رفع آن در فاز عملیات چندین برابر فاز طراحی است؟

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

·         راهنما: به خشت اولی که معمار کج می‌نهد و تا ثریا دیوار کج می‌رود توجه کنید.

سوال ۱۴۰

·         سوال: تست دود (Smoke Testing) در فرآیند استقرار نرم‌افزار به چه معناست؟

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

·         راهنما: به روشن کردن دستگاه و بررسی اینکه آیا از آن دود بلند می‌شود یا خیر فکر کنید.

مبحث ۹: معماری سیستم، یکپارچه‌سازی و تعاملات (Architecture & Integration)

سوال ۱۴۱

·         سوال: تفاوت اصلی معماری یکپارچه (Monolithic Architecture) با معماری میکروسرویس (Microservices) در تحلیل سیستم چیست؟

·         پاسخ مورد انتظار: در معماری مونولیت، تمام بخش‌های سیستم (مالی، انبار، کاربران) در یک بدنه و پایگاه داده واحد قفل شده‌اند؛ اما در میکروسرویس، سیستم به سرویس‌های مستقل، کوچک و مجزا شکسته می‌شود که هر کدام دیتابیس و منطق خود را دارند و از طریق API با هم حرف می‌زنند.

·         راهنما: به تفاوت یک کارخانه عظیم تک‌دپارتمانی در برابر مجموعه‌ای از کارگاه‌های تخصصی مستقل نگاه کنید.

سوال ۱۴۲

·         سوال: وب‌سرویس RESTful چیست و چرا تحلیل‌گران از آن برای پروتکل ارتباطی سیستم‌ها استفاده می‌کنند؟

·         پاسخ مورد انتظار: یک سبک معماری شبکه برای تبادل داده که از متدهای استاندارد HTTP (مثل GET, POST, PUT, DELETE) و فرمت سبک JSON استفاده می‌کند. محبوبیت آن به خاطر سادگی، مستقل بودن از زبان برنامه‌نویسی و سرعت بالاست.

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

سوال ۱۴۳

·         سوال: نقش API Gateway در معماری سیستم‌های مدرن و توزیع‌شده چیست؟

·         پاسخ مورد انتظار: به عنوان یک درگاه و پلیس مرکزی در ورودی سیستم عمل می‌کند که تمام درخواست‌های کاربران را می‌گیرد و آن‌ها را به میکروسرویس مربوطه هدایت می‌کند، کارهای احراز هویت، مانیتورینگ و کنترل ترافیک را هم یکجا انجام می‌دهد.

·         راهنما: به نقش هتلدار یا پذیرش مرکزی یک مجتمع بزرگ اداری توجه کنید.

سوال ۱۴۴

·         سوال: مفهوم «معماری رویدادمحور» (Event-Driven Architecture) چیست و چه زمانی تحلیل‌گر آن را ترجیح می‌دهد؟

·         پاسخ مورد انتظار: معماری‌ای که در آن اجزای سیستم بر اساس تولید و مصرف «رویدادها» (مثل: رویدادِ ثبت سفارش) کار می‌کنند. زمانی ترجیح داده می‌شود که سیستم‌ها باید کاملاً مستقل از هم (Loosely Coupled) باشند و پردازش‌ها به صورت ناهمگام انجام شوند.

·         راهنما: به سیستم‌های خبررسانی خودکار بر اساس اتفاقات رخ‌داده در محیط نگاه کنید.

سوال ۱۴۵

·         سوال: چالش «پایداری نهایی داده‌ها» (Eventual Consistency) در سیستم‌های توزیع‌شده به چه معناست؟

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

·         راهنما: به تاخیر زمانی هماهنگ شدن شعب یک بانک با مرکز توجه کنید.

سوال ۱۴۶

·         سوال: وب‌سرویس SOAP چه تفاوتی با REST دارد و چه زمانی تحلیل‌گر همچنان به استفاده از SOAP رای می‌دهد؟

·         پاسخ مورد انتظار: پروتکل SOAP ساختاری صلب‌تر، مبتنی بر XML دارد و پهنای باند بیشتری مصرف می‌کند، اما به دلیل استانداردهای امنیتی فوق‌العاده سخت‌گیرانه (WS-Security) و تراکنش‌های بانکی پیشرفته، در سیستم‌های مالی و بانکی قدیمی کماکان ترجیح داده می‌شود.

·         راهنما: به تفاوت یک خودروی زرهی سنگین و قدیمی در برابر یک خودروی اسپرت و چابک نگاه کنید.

سوال ۱۴۷

·         سوال: واسط‌های پیام‌رسان (Message Brokers) مانند RabbitMQ یا Kafka چه مشکلی را در یکپارچه‌سازی سیستم‌ها حل می‌کنند؟

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

·         راهنما: به نقش صندوق پستی امن که نامه‌ها را تا زمان آمدن گیرنده نگه می‌دارد فکر کنید.

سوال ۱۴۸

·         سوال: مفهوم Webhook چیست و چه تفاوتی با تکنیک Polling (نظرسنجی مداوم) دارد؟

·         پاسخ مورد انتظار: در Polling سیستم ما مدام و هر چند ثانیه از سرور مقصد می‌پرسد «آیا داده جدید آمد؟» که ترافیک را هدر می‌دهد. در Webhook، ما یک آدرس به سرور مقصد می‌دهیم و می‌گوییم «هر زمان داده جدید آمد، خودت زنگ ما را بزن و بگو».

·         راهنما: به تفاوت زنگ زدن مدام به رستوران برای آماده شدن غذا در برابر تماس خودِ رستوران پس از آماده شدن غذا نگاه کنید.

سوال ۱۴۹

·         سوال: نقش مستند ساختار داده (Data Mapping) در پروژه‌های یکپارچه‌سازی (Integration) دو سیستم مجزا چیست؟

·         پاسخ مورد انتظار: مشخص می‌کند فیلدهای سیستم مبدا چگونه به فیلدهای سیستم مقصد تبدیل شوند؛ به عنوان مثال فیلد User_Id در سیستم اول دقیقاً معادل فیلد CustomerNo در سیستم دوم است تا در زمان انتقال، داده‌ها جابجا ننشینند.

·         راهنما: به جدول مترجم لغات میان دو زبان مختلف برای یک کاسه کردن مفاهیم نگاه کنید.

سوال ۱۵۰

·         سوال: مفهوم لایه‌ی میان‌افزار (Middleware) در معماری نرم‌افزار چیست؟

·         پاسخ مورد انتظار: نرم‌افزار یا لایه‌ای از کد که مثل چسب عمل می‌کند و خدماتی فراتر از سیستم‌عامل را به برنامه‌ها ارائه می‌دهد؛ مثل لایه‌ای که وظیفه‌اش گرفتن درخواست‌ها، بررسی توکن امنیتی کاربر و سپس اجازه دادن برای رسیدن به کدهای اصلی است.

·         راهنما: به تونل‌های رابط یا لایه‌های پنهان خدمات‌رسان میان برنامه‌ها توجه کنید.

مبحث ۱۰: مستندسازی نهایی، نگهداری و ارزیابی سیستم (Documentation & Evaluation)

سوال ۱۵۱

·         سوال: سند «مشخصات نیازمندهای نرم‌افزار» (SRS) چیست و چه کسانی امضاکنندگان نهایی آن هستند؟

·         پاسخ مورد انتظار: سند جامع و رسمی پروژه که شامل تمام نیازمندی‌های عملکردی، غیرعملکردی، فرآیندها و محدودیت‌های سیستم است. امضاکنندگان نهایی آن مدیر پروژه، تحلیل‌گر سیستم، نماینده فنی و کارفرما (مشتری) هستند که حکم قرارداد رسمی را دارد.

·         راهنما: به کتاب قانون و مرجع نهایی تعهدات کل تیم پروژه نگاه کنید.

سوال ۱۵۲

·         سوال: ماتریس ردیابی نیازمندی‌ها (RTM) چیست و چطور جلوی «انحراف پروژه» (Scope Creep) را می‌گیرد؟

·         پاسخ مورد انتظار: جدولی است که هر نیازمند‌ی را به بیزینس‌کیس اولیه، کلاس طراحی، خط کد و در نهایت تست‌کیس مربوطه متصل می‌کند. با این کار مشخص می‌شود هیچ ویژگی اضافه‌ای (بدون هماهنگی) به کد تزریق نشده و هیچ نیازمندی‌ای هم جا نیفتاده است.

·         راهنما: به زنجیره ردیابی اصالت هر خط کد از روی نیازمندی‌های مصوب فکر کنید.

سوال ۱۵۳

·         سوال: تفاوت بین نگهداری اصلاحی (Corrective Maintenance) و نگهداری تطبیقی (Adaptive Maintenance) پس از تحویل سیستم چیست؟

·         پاسخ مورد انتظار: نگهداری اصلاحی یعنی برطرف کردن باگ‌ها و خطاهای ناگهانی که در فاز عملیات کشف می‌شوند؛ اما نگهداری تطبیقی یعنی آپدیت کردن سیستم برای سازگاری با تغییرات محیطی (مثل تغییر قوانین مالیاتی کشور یا ارتقای نسخه سیستم‌عامل سرور).

·         راهنما: به تفاوت تعمیر قطعه خراب در برابر تنظیم موتور برای سازگاری با سوخت جدید نگاه کنید.

سوال ۱۵۴

·         سوال: مفهوم «مهندسی مجدد» (Re-engineering) چه زمانی مطرح می‌شود و تفاوت آن با نگهداری معمولی سیستم چیست؟

·         پاسخ مورد انتظار: زمانی که سیستم قدیمی (Legacy) دیگر کشش تغییرات را ندارد و تکنولوژی آن منسوخ شده است. در نگهداری، کدهای موجود تعمیر می‌شوند؛ اما در مهندسی مجدد، سیستم از ابتدا تحلیل، بازطراحی و با معماری مدرن نوسازی می‌شود.

·         راهنما: به تفاوت کوبیدن و از نو ساختن یک خانه فرسوده در برابر گچ‌کاری و رنگ‌آمیزی آن نگاه کنید.

سوال ۱۵۵

·         سوال: بررسی لوکالایزیشن و «مستندات آموزش کاربر» (User Manual) چه نقشی در کاهش هزینه‌های پشتیبانی سیستم دارد؟

·         پاسخ مورد انتظار: هرچه مستندات راهنمای کاربر، فیلم‌های آموزشی و بخش سوالات متداول (FAQ) دقیق‌تر و شفاف‌تر باشند، کاربران مشکلات ابتدایی خود را خودشان حل می‌کنند و بار تیکت‌های ورودی به دپارتمان پشتیبانی به شدت کاهش می‌یابد.

·         راهنما: به توانمندسازی کاربر برای حل مستقل چالش‌ها به کمک دفترچه‌های راهنما توجه کنید.

سوال ۱۵۶

·         سوال: فرآیند «ارزیابی پس از پیاده‌سازی» (Post-Implementation Review) به چه منظوری انجام می‌شود؟

·         پاسخ مورد انتظار: ارزیابی‌ای که چند ماه پس از لانچ سیستم انجام می‌شود تا بررسی کنند آیا پروژه به اهداف مالی و بیزینسی تعیین‌شده رسیده است، کاربران چقدر رضایت دارند و چه درس‌آموخته‌هایی (Lessons Learned) برای پروژه‌های بعدی وجود دارد.

·         راهنما: به نگاه به پشت سر و سنجش عیار واقعی موفقیت پروژه در دنیای واقعی فکر کنید.

سوال ۱۵۷

·         سوال: مفهوم «پوسیدگی نرم‌افزار» (Software Rot) چیست و چرا سیستم‌ها بدون تغییر هم کیفیت خود را از دست می‌دهند؟

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

·         راهنما: به فرسودگی ناشی از تغییرات دنیای بیرون، حتی در صورت ثابت ماندن کدهای داخل نگاه کنید.

سوال ۱۵۸

·         سوال: مدیریت پیکربندی (Configuration Management) در فاز تحویل و نگهداری سیستم چه وظیفه‌ای دارد؟

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

·         راهنما: به شناسنامه‌دار کردن دقیق تمام اجزا و نسخه‌های فعال سیستم توجه کنید.

سوال ۱۵۹

·         سوال: تحلیل‌گر سیستم چگونه شاخص کلیدی عملکرد (KPI) برای سنجش موفقیت فنی سیستم تعریف می‌کند؟

·         پاسخ مورد انتظار: با تعریف معیارهای عددی قابل اندازه‌گیری؛ مانند: «کاهش زمان پردازش سفارش به زیر ۳ ثانیه»، «نرخ پایداری سیستم (Uptime) بالای ۹۹.۹ درصد» یا «کاهش نرخ خطاهای سرور به زیر ۰.۵ درصد».

·         راهنما: به تبدیل آرزوهای کیفی به خط‌کش‌ها و آمارهای عددی دقیق فکر کنید.

سوال ۱۶۰

·         سوال: چرا «امحای سیستم» (System Retirement/Decommissioning) یک فاز رسمی در SDLC است و چه الزاماتی دارد؟

·         پاسخ مورد انتظار: چون خارج کردن یک سیستم قدیمی از مدار بدون برنامه، می‌تواند بیزینس را فلج کند. الزامات آن شامل انتقال امن تمام داده‌های تاریخی به سیستم جدید، خاموش کردن سرورها برای کاهش هزینه و حفظ آرشیو جهت مسائل قانونی آینده است.

·         راهنما: به فرآیند بازنشستگی و خاکسپاری امن و محترمانه یک سیستم قدیمی بدون آسیب به سازمان نگاه کنید.

ادامه‌ی مبحث ۷: متدولوژی‌های توسعه و چرخه‌ی حیات نرم‌افزار (سوالات ۱۶۱ تا ۱۷۰)

سوال ۱۶۱

·         سوال: مفهوم «برنامه‌نویسی مفرط» (Extreme Programming - XP) به عنوان یک متدولوژی چابک، چه تمرکزی روی کیفیت کد دارد و تکنیک Pair Programming در آن چیست؟

·         پاسخ مورد انتظار: تمرکز شدید روی اصول مهندسی نرم‌افزار و بازخوردهای بسیار کوتاه. تکنیک Pair Programming یعنی دو برنامه‌نویس پای یک سیستم می‌نشینند؛ یکی کد می‌نویسد (Driver) و دیگری همزمان کد را بازبینی، خطایابی و هدایت می‌کند (Navigator) که باعث کاهش چشمگیر باگ‌ها می‌شود.

·         راهنما: به ارتقای کیفیت کد از طریق نظارت دوچشمی و همزمان در لحظه تولید فکر کنید.

سوال ۱۶۲

·         سوال: اصطلاح «توسعه مبتنی بر تست» (Test-Driven Development - TDD) در چرخه حیات نرم‌افزار به چه معناست و چه تغییری در ترتیب سنتی کارها ایجاد می‌کند؟

·         پاسخ مورد انتظار: در TDD، برنامه‌نویس قبل از نوشتن خودِ کد برنامه، ابتدا تستِ آن را می‌نویسد (که در ابتدا فیل می‌شود)، سپس کمترین کد ممکن را برای پاس شدن تست می‌نویسد و در نهایت کد را بازنویسی و تمیز (Refactor) می‌کند. این کار روند سنتی «کدنویسی و سپس تست» را کاملاً معکوس می‌کند.

·         راهنما: به اولویت داشتن طراحی تست بر پیاده‌سازی خودِ منطق برنامه توجه کنید.

سوال ۱۳۶ -> (تصحیح شماره‌گذاری برای فایل ورد شما: سوال ۱۶۳)

·         سوال: فاز «کشف و استخراج اولیه» (Discovery Phase) در ابتدای چرخه SDLC چه تفاوتی با فاز تحلیل جزئی دارد؟

·         پاسخ مورد انتظار: فاز کشف بر شناخت اتمسفر کلی، همسویی با اهداف کلان تجاری، امکان‌پذیری اولیه و شناخت ذینفعان تمرکز دارد و خروجی آن پروپوزال یا منشور پروژه است؛ در حالی که فاز تحلیل جزئی، وارد جزئیات فرم‌ها، فیلدها، قوانین دیتابیس و یوزکیس‌ها می‌شود.

·         راهنما: به تفاوت نگاه هلیکوپتری ابتدای پروژه در برابر کالبدشکافی جزئیات سیستم نگاه کنید.

سوال ۱۶۴

·         سوال: مفهوم «مدل V» (V-Model) در چرخه‌ی حیات نرم‌افزار چگونه فازهای تحلیل و طراحی را به فازهای تست متناظر متصل می‌کند؟

·         پاسخ مورد انتظار: این مدل نشان می‌دهد که هر فاز توسعه، یک فاز تست قرینه دارد؛ مثلاً نیازمندی‌های بیزینس با تست پذیرش (UAT)، تحلیل سیستم با تست سیستم، و طراحی معماری با تست یکپارچه‌سازی متناظر هستند و تست‌ها همزمان با تحلیل طراحی می‌شوند.

·         راهنما: به همگامی و موازی بودن لایه‌های نگارش نیازمندی با لایه‌های طراحی تست‌ها فکر کنید.

سوال ۱۶۵

·         سوال: نقش فرآیند «بازبینی معماری» (Architecture Review) در اواسط چرخه حیات سیستم چیست؟

·         پاسخ مورد انتظار: بررسی اینکه آیا کدهای نوشته شده و ساختار دیتابیس هنوز با اصول معماری کلان و نیازمندی‌های غیرعملکردی (مثل امنیت و سرعت) همخوانی دارند یا تیم به دلیل عجله دچار انحراف ساختاری شده است.

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

سوال ۱۶۶

·         سوال: در فریم‌ورک‌های چابک، مفهوم Velocity (سرعت تیم) چگونه محاسبه می‌شود و چه کاربردی در برنامه‌ریزی‌های آینده دارد؟

·         پاسخ مورد انتظار: میانگین تعداد استوری‌پوینت‌هایی (حجم کارهایی) که تیم توسعه در طول یک اسپرینت به طور کامل (طبق DoD) تحویل می‌دهد. کاربرد آن، پیش‌بینی واقع‌بینانه حجم کارهای قابل انجام در اسپرینت‌های آینده است.

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

سوال ۱۶۷

·         سوال: چرا متدولوژی‌های تکرارشونده (Iterative) ریسک کلان پروژه‌های مبهم را نسبت به مدل‌های خطی کاهش می‌دهند؟

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

·         راهنما: به ارزش گرفتن بازخوردهای سریع و مداوم از کارفرمای پروژه نگاه کنید.

سوال ۱۶۸

·         سوال: چالش «تغییر فرآیندهای سازمانی» (Business Process Re-engineering) در هنگام استقرار یک نرم‌افزار بزرگ (مثل ERP) در سازمان‌های سنتی چیست؟

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

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

سوال ۱۶۹

·         سوال: مفهوم «یکپارچه‌سازی مداوم» (CI/CD) در چرخه مدرن نرم‌افزار چه کمکی به کاهش خطاهای فاز تحویل می‌کند؟

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

·         راهنما: به حذف خطاهای انسانی در فرآیند دستی کامپایل و آپلود کدهای جدید نگاه کنید.

سوال ۱۷۰

·         سوال: در اسکرام، جلسه «بازنگری اسپرینت» (Sprint Retrospective) چه تفاوتی با جلسه دمو (Sprint Review) دارد؟

·         پاسخ مورد انتظار: جلسه دمو (Review) متمرکز بر خودِ «محصول» است و ویژگی‌های ساخته شده را به مشتری نشان می‌دهند؛ اما جلسه رترو (Retrospective) متمرکز بر «فرآیندها و افراد» است تا ببینند چطور می‌توانند در اسپرینت بعدی مشکلات ارتباطی و کاری تیم را حل کنند.

·         راهنما: به تفاوت ارزیابی «چه چیزی ساختیم» در برابر ارزیابی «چگونه با هم کار کردیم» توجه کنید.

ادامه‌ی مبحث ۸: فرآیندهای تست، کنترل کیفیت و صحه‌گذاری (سوالات ۱۷۱ تا ۱۸۰)

سوال ۱۷۱

·         سوال: تکنیک «تست بخش‌بندی معادل» (Equivalence Partitioning) در طراحی تست‌کیس‌ها چیست؟

·         پاسخ مورد انتظار: تقسیم ورودی‌های سیستم به دسته‌هایی که رفتار سیستم برای اعضای هر دسته یکسان است. به جای تست کردن تک‌تک اعداد، از هر دسته فقط یک نماینده انتخاب و تست می‌شود تا در زمان صرفه‌جویی شود (مثال: دسته‌ی اعداد منفی، دسته‌ی اعداد مثبت).

·         راهنما: به گروه‌بندی هوشمندانه ورودی‌ها برای کاهش تعداد تست‌کیس‌های تکراری فکر کنید.

سوال ۱۷۲

·         سوال: مفهوم «تست رگرسیون خودکار» (Automated Regression Testing) چیست و چرا بدون اتوماسیون، این تست شکست می‌خورد؟

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

·         راهنما: به لزوم استفاده از ابزارها برای اجرای سریع هزاران تست قدیمی در چند دقیقه نگاه کنید.

سوال ۱۷۳

·         سوال: تست نفوذ (Penetration Testing) چیست و در چه لایه‌ای از تحلیل سیستم‌های تحت وب باید به آن پرداخته شود؟

·         پاسخ مورد انتظار: شبیه‌سازی حملات سایبری واقعی توسط متخصصان امنیت برای کشف آسیب‌پذیری‌های سیستم. این تست در لایه نیازمندی‌های غیرعملکردی امنیتی تحلیل می‌شود و باید سناریوهای مقابله با حملاتی مثل SQL Injection در آن دیده شود.

·         راهنما: به هک کردن اخلاقی سیستم خودی برای پیدا کردن سوراخ‌های امنیتی قبل از هکرهای واقعی توجه کنید.

سوال ۱۷۴

·         سوال: منظور از «محیط تست پایداری» (Staging Environment) چیست و چرا نباید تست‌های نهایی را روی سرور توسعه (Development) انجام داد؟

·         پاسخ مورد انتظار: محیط استیجینگ کپی کاملاً برابری از سرور عملیاتی (Production) از نظر سخت‌افزار، دیتابیس و شبکه است. سرور توسعه مدام در حال تغییر و ناپایدار است و معیارهای سنجش سرعت و رفتار واقعی سیستم در آن معتبر نیستند.

·         راهنما: به لزوم وجود یک آزمایشگاه کاملاً ایزوله و مشابه با دنیای واقعی برای تست آخر نگاه کنید.

سوال ۱۷۵

·         سوال: چالش باگ‌های کیهانی یا «باگ‌های غیرقابل بازتولید» (Heisenbugs) در فاز تست چیست و راهکار تحلیل‌گر برای حل آن چیست؟

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

·         راهنما: به اهمیت ابزارهای لاگ‌نویسی پیشرفته برای شکار باگ‌های فرار و نوسانی توجه کنید.

سوال ۱۷۶

·         سوال: مفهوم «پوشش کد» (Code Coverage) در معیارهای تست چیست و آیا پوشش ۱۰۰ درصدی تضمین‌کننده کیفیت مطلق است؟

·         پاسخ مورد انتظار: شاخصی که نشان می‌دهد چند درصد از خطوط کد برنامه توسط تست‌های نوشته شده اجرا و ارزیابی شده‌اند. خیر، پوشش ۱۰۰ درصدی لزوماً به معنی کیفیت مطلق نیست؛ زیرا ممکن است تست‌ها خطوط را اجرا کنند اما سناریوهای منطقی غلط یا نیازمندی‌های جاافتاده بیزینس را نسنجند.

·         راهنما: به تفاوت اجرای خطوط کد در برابر سنجش صحتِ منطق بیزینس نگاه کنید.

سوال ۱۷۷

·         سوال: تست آلفا (Alpha Testing) و تست بتا (Beta Testing) چه تفاوت‌هایی با یکدیگر دارند؟

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

·         راهنما: به تفاوت تست توسط افراد خودی سازمان در برابر تست توسط کاربران غریبه در بازار توجه کنید.

سوال ۱۷۸

·         سوال: مفهوم تست منفی (Negative Testing) در ارزیابی فرم‌های ورودی چیست؟

·         پاسخ مورد انتظار: تست سیستم با داده‌های عمدی خراب، نامعتبر یا خارج از محدوده، تا مطمئن شویم سیستم به جای کرش کردن یا قبول داده‌ی غلط، با متانت خطا را مدیریت کرده و پیام راهنمای درست به کاربر نشان می‌دهد (مثال: وارد کردن متن در فیلد مبلغ).

·         راهنما: به سنجش میزان مقاومت و رفتار عاقلانه سیستم در مواجهه با حماقت‌ها یا اشتباهات کاربران نگاه کنید.

سوال ۱۷۹

·         سوال: در سیستم‌های توزیع‌شده، «تست قطع ارتباط» (Chaos Engineering/Disconnect Test) به چه منظور انجام می‌شود؟

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

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

سوال ۱۸۰

·         سوال: چرا فرآیند «بازخوانی اسناد تحلیلی» (Requirements Walkthrough) خود یک لایه تست و کنترل کیفیت محسوب می‌شود؟

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

·         راهنما: به پیشگیری از تولید باگ به کمک اصلاح به موقع متن نیازمندی‌ها نگاه کنید.

ادامه‌ی مبحث ۹: معماری سیستم، یکپارچه‌سازی و تعاملات (سوالات ۱۸۱ تا ۱۹۰)

سوال ۱۸۱

·         سوال: الگوی معماری MVC (Model-View-Controller) چگونه وظایف را در یک سیستم نرم‌افزاری تفکیک می‌کند؟

·         پاسخ مورد انتظار: مدل (Model) مسئول مدیریت داده‌ها و قوانین بیزینس است؛ ویو (View) مسئول نمایش لایه ظاهری به کاربر است؛ و کنترلر (Controller) واسطی است که ورودی کاربر را گرفته، مدل را آپدیت کرده و ویو مناسب را بازمی‌گرداند. این کار مانع از قفل شدن کدها در هم می‌شود.

·         راهنما: به اصل تفکیک داده، ظاهر و موتور فرماندهی سیستم توجه کنید.

سوال ۱۸۲

·         سوال: چالش «وابستگی شدید» (Tight Coupling) در تعامل بین سیستم‌ها چیست و چرا یک تحلیل‌گر باید از آن فرار کند؟

·         پاسخ مورد انتظار: وضعیتی که در آن دو سیستم چنان به جزئیات داخلی هم وابسته هستند که تغییر در یکی، باعث شکست و خرابی فوری در دیگری می‌شود. راهکار فرار از آن، استفاده از رابط‌های استاندارد (APIs) و معماری‌های ناهمگام (Loose Coupling) است.

·         راهنما: به خطر متصل کردن زنجیروار و صلب اجزای نرم‌افزاری به یکدیگر فکر کنید.

سوال ۱۸۳

·         سوال: مفهوم «معماری سرویس‌گرا» (SOA) چیست و چه تفاوتی با میکروسرویس‌های مدرن دارد؟

·         پاسخ مورد انتظار: در SOA سیستم‌های بزرگ سازمان از طریق یک اتوبوس پیام مرکزی (ESB) سرویس‌های خود را به هم به اشتراک می‌گذارند که همچنان تا حدی وابسته به آن اتوبوس مرکزی هستند؛ اما میکروسرویس‌ها بسیار ریزدانه‌تر و کاملاً مستقل از هرگونه هسته مرکزی عمل می‌کنند.

·         راهنما: به تفاوت سیستم ارتباطی مبتنی بر سانترال مرکزی در برابر تلفن‌های همراه مستقل نگاه کنید.

سوال ۱۸۴

·         سوال: پروتکل OAuth 2.0 چه نقشی در یکپارچه‌سازی امنیتی سیستم‌های تعاملی دارد؟

·         پاسخ مورد انتظار: پروتکلی استاندارد برای صدور مجوز (Authorization) است که به یک سیستم اجازه می‌دهد بدون نیاز به گرفتن رمز عبور کاربر، به طور امن به بخش محدودی از اطلاعات او در سیستم دیگر دسترسی داشته باشد (مثل: ورود به سایت با اکانت گوگل).

·         راهنما: به مکانیزم کلید موقت یا ژتون ورود بدون لو رفتن پسورد اصلی کاربر نگاه کنید.

سوال ۱۸۵

·         سوال: مفهوم کش کردن (Caching) در معماری سیستم چیست و تحلیل‌گر چه زمانی استفاده از آن را در مستندات اجباری می‌کند؟

·         پاسخ مورد انتظار: ذخیره موقت داده‌های پرکاربرد و کم‌تغییر (مثل لیست استان‌ها) در یک حافظه بسیار سریع (مثل RAM سرور). زمانی اجباری می‌شود که لود دیتابیس اصلی سنگین است و می‌خواهیم سرعت پاسخ‌دهی سیستم را به شدت بالا ببریم.

·         راهنما: به گذاشتن اقلام پرمصرف دمِ دست برای جلوگیری از رفت‌وآمدهای مکرر به انبار اصلی دیتابیس توجه کنید.

سوال ۱۸۶

·         سوال: مفهوم توازن بار (Load Balancing) در لایه زیرساخت سیستم چیست و چطور به پایداری نرم‌افزار کمک می‌کند؟

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

·         راهنما: به نقش تقسیم‌کننده صف مسافران بین گیت‌های مختلف فرودگاه نگاه کنید.

سوال ۱۸۷

·         سوال: در طراحی فرآیندهای ادغام، مفهوم ETL (Extract, Transform, Load) در جابجایی داده‌ها به چه معناست؟

·         پاسخ مورد انتظار: فرآیند سه مرحله‌ای انتقال داده: ابتدا داده‌ها از منابع مختلف استخراج می‌شوند (Extract)، سپس طبق قوانین سیستم جدید تمیزکاری، فیلتر و دگرگون می‌شوند (Transform) و در نهایت در انبار داده مقصد بنشینند (Load).

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

سوال ۱۸۸

·         سوال: چالش «مهاجرت داده‌ها» (Data Migration) در زمان جایگزینی سیستم قدیمی با سیستم جدید حاوی چه ریسک‌هایی است؟

·         پاسخ مورد انتظار: ریسک از دست رفتن داده‌های تاریخی، تضاد فرمت‌های اطلاعاتی (مثلا عدم همخوانی فیلد تاریخ)، ثبت داده‌های تکراری و قطعی طولانی‌مدت سیستم در زمان انتقال. راهکار آن، نوشتن اسکریپت‌های تست و اجرای پایلوت مهاجرت است.

·         راهنما: به عملیات حساس اسباب‌کشی و چیدمان داده‌های قدیمی در قفسه‌های جدید دیتابیس نگاه کنید.

سوال ۱۸۹

·         سوال: مفهوم Statefulness (وابستگی به وضعیت) در برابر Statelessness (عدم وابستگی به وضعیت) در طراحی وب‌سرویس‌ها چیست؟

·         پاسخ مورد انتظار: در سیستم Stateful، سرور اطلاعات جلسات قبلی کاربر را در حافظه خود نگه می‌دارد و به آن وابسته است؛ اما در سیستم Stateless، هر درخواست کاربر کاملاً مستقل است و تمام اطلاعات لازم برای پردازش (مثل توکن امنیتی) را همراه خود دارد که مقاومت سیستم را بالا می‌برد.

·         راهنما: به مستقل بودن درخواست‌ها از یکدیگر برای تسهیل تکثیر سرورها نگاه کنید.

سوال ۱۹۰

·         سوال: نقش سیستم‌های کنترل نسخه (مثل Git) در هماهنگی کدهای معماری و پیاده‌سازی چیست؟

·         پاسخ مورد انتظار: به برنامه‌نویسان اجازه می‌دهد همزمان روی بخش‌های مختلف سیستم کار کنند، تغییرات را ادغام کنند، تاریخچه تغییرات هر خط کد را نگه دارند و در صورت بروز فاجعه فنی، سیستم را سریعاً به آخرین نسخه سالم (Rollback) برگردانند.

·         راهنما: به ماشین زمان کدهای پروژه و مدیریت هماهنگی تغییرات موازی تیم فنی نگاه کنید.

ادامه‌ی مبحث ۱۰: مستندسازی نهایی، نگهداری و ارزیابی سیستم (سوالات ۱۹۱ تا ۲۰۰)

سوال ۱۹۱

·         سوال: مفهوم «بررسی آمادگی عملیاتی» (Operational Readiness Review - ORR) قبل از تحویل قطعی سیستم چیست؟

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

·         راهنما: به بررسی همه‌جانبه‌ی کل سازمان (فنی و انسانی) قبل از بالا کشیدن پرچم لانچ نهایی نگاه کنید.

سوال ۱۹۲

·         سوال: در فاز نگهداری سیستم، تفاوت بین نگهداری پیشگیرانه (Preventive Maintenance) و نگهداری تکاملی (Perfective Maintenance) چیست؟

·         پاسخ مورد انتظار: نگهداری پیشگیرانه یعنی اصلاح کدهای ضعیف برای جلوگیری از بروز باگ‌های احتمالی آینده (کاهش ریسک)؛ اما نگهداری تکاملی یعنی اضافه کردن امکانات و آپشن‌های جدید به سیستم بنا به درخواست و تکامل نیازهای کاربران.

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

سوال ۱۹۳

·         سوال: چرا مستندسازی «معماری اطلاعات» (Information Architecture) برای نگهداری طولانی‌مدت سیستم‌های محتوایی حیاتی است؟

·         پاسخ مورد انتظار: چون ساختار دسته‌بندی، برچسب‌گذاری و ناوبری کل اطلاعات سیستم را شفاف می‌کند. بدون آن، به مرور زمان سیستم دچار شلختگی محتوایی شده و توسعه منوها یا سرچ سایت عملاً غیرممکن یا به شدت پیچیده می‌شود.

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

سوال ۱۹۴

·         سوال: مفهوم توافق‌نامه سطح خدمات (SLA - Service Level Agreement) چیست و تحلیل‌گر چه بندهایی را در آن برای فاز پشتیبانی فیکس می‌کند؟

·         پاسخ مورد انتظار: قراردادی بین تیم پشتیبانی نرم‌افزار و مشتری که کیفیت خدمات را تضمین می‌کند. فاکتورهای کلیدی آن: حداکثر زمان پاسخ به تیکت‌های بحرانی (مثلا زیر ۳۰ دقیقه)، درصد بالا بودن سایت (Uptime) و جریمه‌های مالی در صورت نقض تعهدات است.

·         راهنما: به سند رسمی تعهدات سرعت و کیفیت تیم پشتیبانی در برابر خسارت‌های احتمالی مشتری نگاه کنید.

سوال ۱۹۵

·         سوال: چالش «سیستم‌های میرا یا قدیمی» (Legacy Systems) در فاز ارزیابی چیست و چرا سازمان‌ها به راحتی آن‌ها را کنار نمی‌گذارند؟

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

·         راهنما: به چالش جراحی قلب باز سازمان برای تعویض سیستم‌های قدیمیِ حیاتی اما فرسوده نگاه کنید.

سوال ۱۹۶

·         سوال: اصطلاح «درخواست تغییر» (Change Request - CR) چیست و فرآیند ارزیابی آن در کمیته کنترل تغییرات (CCB) چگونه است؟

·         پاسخ مورد انتظار: سندی رسمی برای تقاضای تغییر در محدوده مصوب پروژه. کمیته CCB ابتدا اثرات این تغییر را بر بودجه، زمان‌بندی، معماری دیتابیس و ریسک‌های پروژه ارزیابی می‌کند و تنها در صورت تایید ارزش تجاری به تیم توسعه ابلاغ می‌شود.

·         راهنما: به فیلتر کردن و بررسی حساب‌شده درخواست‌های جدید کارفرما برای جلوگیری از متلاشی شدن ددلاین پروژه نگاه کنید.

سوال ۱۹۷

·         سوال: مفهوم «برنامه بازیابی از حادثه» (Disaster Recovery Plan - DRP) چیست و تحلیل‌گر چه فرضیاتی را در آن مستند می‌کند؟

·         پاسخ مورد انتظار: دستورالعمل قدم‌به‌قدم فنی برای زمانی که یک فاجعه بزرگ (مثل آتش‌سوزی دیتاسنتر یا حمله هکری گسترده) رخ می‌دهد. تحلیل‌گر فرضیات مربوط به محل سرورهای پشتیبان، نحوه بازگردانی سریع داده‌ها و دپارتمان‌های مسئول را مستند می‌کند.

·         راهنما: به نقشه فرار و زنده کردن مجدد دیتابیس سیستم در صورت وقوع زلزله فنی نگاه کنید.

سوال ۱۹۸

·         سوال: چرا مستند کردن «تصمیمات کلیدی معماری» (Architecture Decision Records - ADR) در طول چرخه نگهداری سیستم ارزش طلا را دارد؟

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

·         راهنما: به ثبت مستند دلایل منطقی پشت انتخاب‌های فنی برای آگاهی آیندگان نگاه کنید.

سوال ۱۹۹

·         سوال: فرآیند «ارزیابی رضایت کاربران» (User Satisfaction Metrics) پس از استقرار نرم‌افزار با چه شاخص‌هایی سنجیده می‌شود؟

·         پاسخ مورد انتظار: با شاخص‌هایی مانند CSAT (امتیاز رضایت مشتری)، NPS (شاخص خالص ترویج‌کنندگان) و CES (شاخص میزان تلاش کاربر برای انجام یک کار در سیستم) که نشان‌دهنده میزان موفقیت واقعی نرم‌افزار در جلب رضایت انسان‌هاست.

·         راهنما: به استفاده از نظرسنجی‌ها و آمارهای رفتاری برای سنجش محبوبیت واقعی سیستم نگاه کنید.

سوال ۲۰۰

·         سوال: آخرین گام در فرآیند «بستن پروژه» (Project Close-out) چیست و چه فایده‌ای برای سازمان‌های نرم‌افزاری دارد؟

·         پاسخ مورد انتظار: استخراج و مستندسازی «درس‌آموخته‌ها» (Lessons Learned)؛ یعنی ثبت رسمی اینکه چه کارهایی عالی پیش رفت و چه اشتباهاتی در تحلیل، تخمین زمان یا پیاده‌سازی رخ داد تا سازمان در پروژه‌های بعدی دوباره همان چاه‌ها نیفتد.

·         راهنما: به آرشیو کردن تجربیات تلخ و شیرین پروژه برای هوشمندتر شدن تیم در کارهای آینده نگاه کنید.