چک لیست تدوین RFP خرید سامانه LMS دانشگاهی (۲۵ بند فنی)

پیش از برگزاری مناقصه خرید سامانه LMS، این ۲۵ شاخص فنی (از API گلستان تا گواهی افتا) را در RFP لحاظ کنید. دانلود چک‌لیست استاندارد و مشاوره رایگان! (

راهنمای تدوین RFP برای خرید سامانه LMS دانشگاهی؛ ۲۵ شاخص فنی که باید در مناقصه بیاورید

بزرگ‌ترین دروغ در بازار نرم‌افزارهای آموزشی ایران، یک کلمه است: «بله، داریم!»

شما به عنوان مدیر فناوری اطلاعات یا عضو کمیسیون مناقصات دانشگاه، جدولی با عنوان «قابلیت برگزاری آزمون»، «امکان اتصال به سیستم آموزش» و «امنیت بالا» طراحی می‌کنید. شرکت‌های شرکت‌کننده در مناقصه هم جلوی تمام ردیف‌ها تیک سبز می‌زنند و پایین‌ترین قیمت را در پاکت مالی می‌گذارند. قرارداد بسته می‌شود، اما روز اول امتحانات پایان‌ترم که ۳۰۰۰ دانشجو راس ساعت ۸ صبح دکمه شروع آزمون را می‌زنند، سرور با خطای 502 Bad Gateway قفل می‌کند. یک ماه بعد هم که درخواست اتصال خودکار به سامانه گلستان را می‌دهید، فروشنده یک پیش‌فاکتور چندصد میلیون تومانی تحت عنوان «هزینه توسعه سفارشی وب‌سرویس» روی میزتان می‌گذارد!

مقصر اصلی، فروشنده نیست؛ باگ در سند استعلام فنی یا همان RFP (Request for Proposal) دانشگاه است. وقتی معیارهای فنی را به جای اعداد و پروتکل‌های مهندسی، با کلمات کلی توصیف می‌کنید، راه را برای سیستم‌های شکننده و هزینه‌های پنهان باز گذاشته‌اید. فرآیند خرید سامانه lms برای یک دانشگاه، خرید یک نرم‌افزار اداری ساده نیست؛ معماری یک زیرساخت بحرانی است.

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

چرا RFPهای سنتی در مناقصات خرید LMS دانشگاهی شکست می‌خورند؟

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

1. تمرکز بر پوسته به جای هسته (UI vs Architecture): در استعلام‌ها ده‌ها بند درباره رنگ قالب و فونت پرسیده می‌شود، اما هیچ شرطی برای نحوه مدیریت صف (Queueing) در دیتابیس هنگام هجوم همزمان کاربران وجود ندارد.
2. ابهام در مالکیت و لایسنس: مرز بین اجاره اشتراکی (SaaS) و مالکیت دائمی روی سرور دانشگاه مشخص نمی‌شود. دانشگاه بعد از یک سال متوجه می‌شود که دیتابیس نمرات و سوابق علمی‌اش در سرورهای یک شرکت ثالث گروگان گرفته شده است.
3. نادیده گرفتن اکوسیستم بومی آموزش عالی ایران: یک سامانه خارجی یا متن‌باز مثل Moodle شاید روی کاغذ عالی باشد، اما وقتی نتواند بدون فایل اکسل با سامانه گلستان، سما یا هم‌آوا حرف بزند، کارشناسان آموزش کل را در ایام حذف و اضافه فلج می‌کند.

برای بستن این حفره‌ها، در ادامه ۲۵ شاخص فنی را در ۵ دسته استراتژیک مرور می‌کنیم که باید عیناً در جدول الزامات فنی مناقصه کپی کنید.

دسته اول: الزامات معماری استقرار، مالکیت داده و مدل لایسنس (حاکمیت داده)

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

۱. آیا باید استقرار اختصاصی (On-Premise) را در RFP الزام کنیم یا سرویس ابری؟

سرویس‌های ابری و اشتراکی (SaaS) در نگاه اول ارزان به نظر می‌رسند، اما منابع پردازشی (CPU و RAM) شما با ده‌ها آموزشگاه دیگر به اشتراک گذاشته می‌شود. در سند RFP خود صراحتاً قید کنید که سامانه باید قابلیت استقرار اختصاصی (On-Premise) روی سرورهای دیتاسنتر داخلی دانشگاه (ویندوز یا لینوکس) را داشته باشد. این الزام دو دستاورد فوری دارد:

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

۲. چطور تله مالی «جریمه افزایش کاربر» را در اسناد مناقصه خنثی کنیم؟

بسیاری از شرکت‌ها قیمت اولیه پایینی می‌دهند، اما لایسنس را به تعداد کاربر فعال (Active User) محدود می‌کنند. با پذیرش ورودی‌های جدید مهر و بهمن، دانشگاه مجبور به پرداخت فاکتورهای تصاعدی می‌شود. در RFP الزام کنید که مدل مالی باید مبتنی بر هزینه سرمایه‌ای یک‌بار پرداخت (CapEx) و ارائه لایسنس دائمی با کاربر، درس و استاد نامحدود باشد؛ نه هزینه جاری بی‌پایان (OpEx) که هر ترم بودجه دانشگاه را تهدید کند.

شاخص‌های ۱ تا ۵ برای درج در RFP (بخش معماری و لایسنس):

• شاخص ۱: استقرار کامل سامانه و پایگاه داده روی سرورهای داخلی دانشگاه (On-Premise) با دسترسی کامل ادمین فاوا.
• شاخص ۲: ارائه لایسنس دائمی بدون محدودیت در تعداد دانشجو، استاد، مدیر و تعریف نیم‌سال تحصیلی.
• شاخص ۳: پشتیبانی از معماری چندمرکزی (Multi-Tenant) برای مدیریت مستقل دانشکده‌ها، پردیس‌ها و مراکز دوره‌های آزاد با پنل و دامنه مجزا از روی یک هسته مرکزی.
• شاخص ۴: کارکرد ۱۰۰٪ ماژول‌ها در بستر شبکه ملی اطلاعات (اینترانت داخلی) بدون وابستگی به سرویس‌های تحریم‌پذیر خارجی.
• شاخص ۵: تضمین حقوقی و فنی عدم قفل‌گذاری روی جداول دیتابیس در صورت تمایل دانشگاه به استخراج خام اطلاعات در آینده.

دسته دوم: شاخص‌های پایداری سرور و مهار پیک ترافیک در امتحانات (High-Concurrency)

تفاوت یک نرم‌افزار واقعی با یک اسکریپت آزمایشگاهی، ساعت ۸ صبح روز امتحانات عمومی مشخص می‌شود. شما نباید در RFP بنویسید «سامانه باید سرعت خوبی داشته باشد»؛ بلکه باید معماری تحمل بار را مطالبه کنید.

۳. چه مکانیزم فنی مانع از بروز خطای 502 در آزمون‌های همزمان می‌شود؟

وقتی چند هزار دانشجو در یک ثانیه وارد آزمون می‌شوند یا دکمه ثبت پاسخ را می‌زنند، اگر درخواست‌ها مستقیماً به سمت دیتابیس شلیک شوند، پایگاه داده دچار قفل‌شدگی (Deadlock) شده و مصرف پردازنده به ۱۰۰٪ می‌رسد. استاندارد مهندسی برای حل این بحران، استفاده از معماری صف‌بندی (Queueing) و مدیریت حافظه نهان در لایه میانی است. در معماری سامانه ریلاین، دقیقاً بر اساس همین استاندارد، کوئری‌های همزمان در صف‌های میلی‌ثانیه‌ای مدیریت می‌شوند که نتیجه آن کاهش ۴۰ درصدی بار پردازشی (CPU Optimization) سرور و به صفر رسیدن خطای 502 در آزمون‌های سراسری و پایان‌ترم است.

شاخص‌های ۶ تا ۱۰ برای درج در RFP (بخش پایداری و عملکرد):

• شاخص ۶: تضمین فنی تحمل بار حداقل ۲۰,۰۰۰ کاربر فعال و بیش از ۲,۰۰۰ تا ۵,۰۰۰ کاربر همزمان (CCU) در لحظه شروع آزمون بدون افت سرعت.
• شاخص ۷: بهینه‌سازی مصرف منابع سرور و مهار بار پردازنده (CPU) تا ۴۰٪ در ساعات اوج ترافیک از طریق مکانیزم صف‌بندی درخواست‌ها.
• شاخص ۸: پشتیبانی از توزیع بار (Load Balancing) بین چندین سرور کاربردی و سرورهای ویدیوکنفرانس به صورت همزمان.
• شاخص ۹: الزام به اجرای تست فشار و استرس (Load & Stress Testing) شبیه‌سازی‌شده در حضور تیم IT دانشگاه پیش از تحویل قطعی.
• شاخص ۱۰: مدیریت هوشمند سهمیه فضا (Quota Management) و محدودسازی فرمت و حجم آپلود فایل اساتید و دانشجویان برای جلوگیری از پر شدن ناگهانی هارد سرور.

دسته سوم: استانداردهای یکپارچگی و API؛ پایان اکسل‌بازی با سامانه گلستان و سما

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

۴. مشخصات وب‌سرویس (API) استاندارد در RFP دانشگاهی چیست؟

بسیاری از فروشندگان ادعا می‌کنند وب‌سرویس دارند، اما پس از عقد قرارداد می‌گویند: «ما داکیومنت می‌دهیم، تیم برنامه‌نویسی خودتان وصل کند، یا هزینه جداگانه بدهید تا ما بنویسیم!» در RFP خود شرط کنید که فروشنده موظف است ارتباط از طریق RESTful API استاندارد با سامانه‌های جامع دانشگاهی (گلستان، سما، هم‌آوا یا سیدا) را به صورت بومی و بدون دریافت هزینه مازاد تحت عنوان توسعه سفارشی تحویل دهد. در زیرساخت ریلاین، این تبادل داده (شامل ایجاد خودکار پروفایل استاد و دانشجو، تخصیص دروس، اعمال آنی تغییرات حذف و اضافه) انجام می‌شود.

شاخص‌های ۱۱ تا ۱۵ برای درج در RFP (بخش یکپارچگی و وب‌سرویس):

• شاخص ۱۱: اتصال مستقیم و بومی از طریق RESTful API به سامانه آموزشی دانشگاه (گلستان، سما، هم‌آوا) .
• شاخص ۱۲: تعهد کتبی به عدم مطالبه هزینه‌های پنهان و مازاد تحت عنوان «توسعه سفارشی API» برای اتصال به سامانه‌های مرجع دانشگاه.
• شاخص ۱۳: اتصال بومی و تک‌کلیکی (Single Sign-On / SSO) به موتورهای کلاس زنده Adobe Connect و BigBlueButton بدون نیاز به وارد کردن مجدد نام کاربری و رمز عبور توسط استاد یا دانشجو.
• شاخص ۱۴: قابلیت پخش مستقیم جلسات ضبط‌شده ادوب کانکت و بیگ‌بلو‌باتن در مرورگر موبایل و دسکتاپ بدون نیاز به نصب نرم‌افزار جانبی یا فلش‌پلیر منسوخ‌شده.
• شاخص ۱۵: یکپارچگی با پنل‌های پیامکی، ایمیل سازمانی و پیام‌رسان‌های بومی برای بازیابی خودکار رمز عبور (کاهش ۹۰ درصدی تیکت‌های پشتیبانی IT) و اطلاع‌رسانی ددلاین‌ها.

جدول مقایسه‌ای استراتژیک: اسناد RFP سنتی در برابر استاندارد مهندسی ریلاین

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

شاخص ارزیابی در مناقصه	رویکرد سنتی / سامانه‌های اشتراکی و متن‌باز خام	استاندارد مهندسی در معماری اختصاصی ریلاین	تاثیر مستقیم بر بودجه و عملیات دانشگاه
مدل لایسنس و مالکیت	اجاره سالانه (OpEx) یا محدودیت به ازای کاربر فعال	استقرار On-Premise با لایسنس دائمی و نامحدود (CapEx)	حذف جریمه‌های مالی افزایش دانشجو و مالکیت ۱۰۰٪ دیتابیس
ارتباط با گلستان و سما	انتقال دستی با فایل اکسل یا دریافت هزینه نجومی توسعه API	اتصال  RESTful API	به صفر رسیدن خطای انسانی در حذف‌واضافه
رفتار سرور در پیک امتحانات	درگیری ۱۰۰٪ پردازنده، قفل شدن دیتابیس و خطای 502	مهار ۴۰٪ بار CPU با مدیریت صف و تضمین آپتایم	حذف استرس دانشجویان و حفظ اعتبار علمی دانشگاه در امتحانات
امنیت و ممیزی حراست	فاقد گواهی معتبر؛ آسیب‌پذیر در برابر نفوذ و دستکاری نمره	دارای گواهی تست نفوذ آپا (صنعتی اصفهان) و تاییدیه افتا	عبور سریع از ممیزی‌های حراست فاوا و پدافند غیرعامل
داوری اعتراضات امتحانی	ثبت کلی زمان ورود؛ ناتوانی در اثبات ادعای قطع اینترنت دانشجو	لاگ‌گیری ‌ثانیه‌ای کلیک‌ها، آی‌پی	پایان مشاجرات بین استاد و دانشجو در شورای آموزشی

دسته چهارم: الزامات امنیتی افتا، تست نفوذ آپا و موتور آزمون ضدتقلب

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

۵. چرا گواهی تست نفوذ آپا و افتا باید خط قرمز RFP شما باشد؟

ادعای «سیستم ما امن است» در مناقصات هیچ ارزش حقوقی ندارد. در RFP الزام کنید که شرکت ارائه‌دهنده باید گواهی رسمی تست نفوذپذیری (Penetration Test) از مراکز آپای دانشگاهی معتبر و تاییدیه امنیتی افتا را پیش از عقد قرارداد ارائه دهد. سامانه مدیریت یادگیری ریلاین با در اختیار داشتن گواهی رسمی تست نفوذ از مرکز آپای دانشگاه صنعتی اصفهان و تاییدیه‌های امنیتی مربوطه، خیال مدیران IT را از بابت حملات SQL Injection، XSS و دسترسی‌های غیرمجاز کاملاً راحت کرده است.

۶. چطور با لاگ‌گیری ‌ثانیه‌ای به اعتراضات امتحانی دانشجویان پایان دهیم؟

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

1. ذخیره خودکار لحظه‌ای (Auto-Save): به محض کلیک دانشجو روی هر گزینه، پاسخ در دیتابیس ثبت شود تا با قطع اینترنت یا بسته شدن مرورگر، هیچ داده‌ای از بین نرود.
2. لاگ‌گیری ریزدانه (Granular Logging): ثبت ‌ثانیه‌ای تمام رخدادها شامل لحظه ورود، آدرس IP، نوع مرورگر، ثانیه کلیک روی هر سوال، تغییر گزینه از الف به ب، . با این گزارش در پنل ادمین ریلاین، مدیر آموزش در ۳۰ ثانیه مستندات دقیق را جلوی دانشجو می‌گذارد و به هرگونه ابهام پایان می‌دهد.

شاخص‌های ۱۶ تا ۲۰ برای درج در RFP (بخش امنیت و موتور آزمون):

• شاخص ۱۶: ارائه مستندات فیزیکی گواهی تست نفوذ از مرکز آپا (نظیر آپای دانشگاه صنعتی اصفهان) و انطباق با الزامات امنیتی افتا.
• شاخص ۱۷: ثبت لاگ ‌ثانیه‌ای رفتار دانشجو در آزمون (کلیک‌ها، تغییر گزینه‌ها، آی‌پی و نوسانات شبکه) همراه با مکانیزم Auto-Save.
• شاخص ۱۸: مکانیزم‌های ضدتقلب شامل تصادفی‌سازی ترتیب سوالات و گزینه‌ها برای هر دانشجو، محدودسازی زمان به ازای هر سوال .
• شاخص ۱۹: پشتیبانی کامل موتور آزمون‌ساز و تکالیف از ویرایشگر فرمول‌نویسی ریاضی، شیمی و مهندسی به همراه قابلیت آپلود سریع تصویر پاسخ تشریحی با دوربین موبایل.
• شاخص ۲۰: صدور خودکار گواهینامه پایان دوره (ویژه مرکز آموزش‌های آزاد دانشگاه) مجهز به  QR Code ضدجعل و قابل استعلام آنلاین.

دسته پنجم: تجربه یادگیری (LXD)، معماری Mobile-First و اتوماسیون کارگزینی اساتید

نرم‌افزاری که امن و پایدار باشد اما استاد ۶۵ ساله دانشگاه نتواند بدون کمک کارشناس IT در آن درس تعریف کند، یک پروژه شکست‌خورده است. در لایه آخر RFP، باید شاخص‌های طراحی تجربه یادگیری (LXD) و اتوماسیون اداری را لحاظ کنید.

۷. چرا معماری Mobile-First و حذف بار شناختی برای دانشگاه حیاتی است؟

آمارهای ترافیک شبکه دانشگاه‌ها نشان می‌دهد که بیش از ۷۰ تا ۸۰ درصد دانشجویان با گوشی موبایل وارد سایت LMS می‌شوند. اگر سامانه شما صرفاً یک سایت دسکتاپ قدیمی باشد که روی گوشی ریز نمایش داده می‌شود، نرخ ریزش و نارضایتی به اوج می‌رسد. طراحی سامانه باید بر اساس معماری Mobile-First و بدون بار شناختی (Cognitive Load) باشد؛ به طوری که استاد و دانشجو با حداکثر ۳ کلیک به کلاس زنده، تکلیف یا آزمون برسند. علاوه بر این، برای دوره‌های مهارتی و تکمیلی، پشتیبانی بومی از استاندارد SCORM، ویدیوهای تعاملی (توقف ویدیو در دقایق مشخص و پرسش از دانشجو برای سنجش تمرکز) و ارزیابی اثربخشی بر اساس مدل کرک‌پاتریک، دانشگاه را به یک سازمان یادگیرنده مدرن تبدیل می‌کند.

شاخص‌های ۲۱ تا ۲۵ برای درج در RFP (بخش LXD و اتوماسیون آموزشی):

• شاخص ۲۱: رابط کاربری واکنش‌گرا با معماری Mobile-First بدون نیاز به نصب اپلیکیشن‌های سنگین روی اندروید و آیفون.
• شاخص ۲۲: ثبت خودکار و دقیقه‌ای حضور و غیاب اساتید و دانشجویان در کلاس‌های آنلاین به همراه ماژول تعریف جلسات جبرانی بدون تداخل؛ جهت محاسبه اتوماتیک ساعات حق‌التدریس کارگزینی.
• شاخص ۲۳: پشتیبانی بومی از بسته‌های استاندارد SCORM، پخش استریم ویدیوهای تعاملی و قابلیت تعریف مسیر یادگیری شرطی (قفل بودن فصل بعد تا کسب نمره قبولی فصل قبل).
• شاخص ۲۴: ماژول دیجیتال ارزشیابی اساتید در پایان ترم با قابلیت وزن‌دهی سوالات و استخراج نمودارهای تحلیلی کیفیت تدریس.
• شاخص ۲۵: سیستم تیکتینگ و پشتیبانی داخلی سلسله‌مراتبی برای پاسخگویی مستند به درخواست‌های دانشجویان و حذف مراجعات حضوری به آموزش کل.

بخش کاربردی: فرمول امتیازدهی فنی (Scoring Matrix) برای کمیسیون مناقصات

برای اینکه فردا صبح در جلسه کمیسیون فنی و مالی دانشگاه، ارزیابی شرکت‌ها را از حالت سلیقه‌ای خارج کنید، از «فرمول وزن‌دهی ۱۰۰ امتیازی» زیر استفاده کنید. هر شرکتی که زیر ۷۵ امتیاز بیاورد، حتی اگر ارزان‌ترین قیمت را داده باشد، نباید به مرحله بازگشایی پاکت مالی راه پیدا کند:

1. تست عملی استقرار On-Premise و لایسنس دائمی نامحدود (۲۵ امتیاز): (ارائه لایسنس اجاره‌ای یا محدودیت کاربر = ۰ امتیاز).
2. دموی زنده اتصال API دوطرفه به گلستان/سما بدون هزینه توسعه (۲۵ امتیاز): (ادعای اتصال با فایل اکسل یا درخواست هزینه برنامه‌نویسی جداگانه = ۰ امتیاز).
3. ارائه گواهی فیزیکی تست نفوذ آپا و تاییدیه افتا (۲۰ امتیاز): (نداشتن گواهی معتبر رسمی = حذف مستقیم امنیتی).
4. معماری مهار بار CPU، تست استرس آزمون همزمان و لاگ‌گیری ثانیه‌ای (۲۰ امتیاز): (مشاهده پنل لاگ کلیک‌ها و معماری صف در جلسه دمو).
5. اتصال SSO به کلاس زنده (ادوب کانکت/بیگ‌بلو‌باتن) و رابط Mobile-First (۱۰ امتیاز): (تست ورود با یک کلیک از طریق گوشی موبایل در جلسه).

سوالات متداول مدیران فناوری اطلاعات و تدارکات (FAQ)

۱. آیا در RFP مناقصه، سفارشی‌سازی سامانه متن‌باز Moodle را بپذیریم یا سامانه بومی اختصاصی بخریم؟

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

۲. چه بند حقوقی برای تضمین پایداری سرور در روز امتحان در قرارداد SLA بیاوریم؟

در توافقنامه سطح خدمات (SLA) پیوست RFP، بند «تضمین آپتایم ۹۹.۹٪ در ساعات پیک امتحانات پایان‌ترم» را به همراه جریمه خسارت در صورت بروز خطای 502 (ناشی از معماری نرم‌افزار در ترافیک توافق‌شده) درج کنید و تحویل قطعی را منوط به عبور موفق از تست استرس (Stress Test) نمایید.

۳. اگر دانشگاه در آینده بخواهد مرکز آموزش‌های آزاد و مهارت‌آموزی راه‌اندازی کند، آیا باید LMS جداگانه بخرد؟

خیر؛ اگر در RFP امروز خود شاخص «معماری چندمرکزی (Multi-Tenant) و درگاه فروش دوره» را لحاظ کنید، سامانه ریلاین به شما امکان می‌دهد روی همان سرور، یک پورتال مستقل با درگاه پرداخت بانکی و صدور گواهینامه QR Code برای دوره‌های آزاد ایجاد کرده و برای دانشگاه درآمدزایی کنید.

۴. انتقال سوابق از LMS قبلی دانشگاه به سامانه جدید چقدر زمان می‌برد؟

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