1.0

۲۱/۱۲/۱۴۰۱

انتشار لیست تحویل‌دادنی‌های فنی همراه با توضیح، نحوه و شرایط و زمان تحویل

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

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

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

• این سند باید با محوریت کارفرما و در حین انعقاد قرارداد تنظیم شود. بنابراین در قالب‌های Word و PDF تولید شده و پیوست قرارداد می‌گردد. 
• بهتر است از روی این سند ابزار مدیریت سرویس (مثل JIRA Service Desk) پیکربندی شود و به صورت خودکار جرائم را محاسبه نماید. 
• قالب پیشنهادی چکاپ ندارد! (لینک تکمیل شود)

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

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

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

• مخازن داده مختلف برای انواع داده را معرفی می‌نماید. داده‌های سیستم ممکن است در پایگاه‌‌ه‌داده‌های رابطه‌ای، NoSql‌ها، Object Storeها و ... ذخیره شده باشند.  
• مدل داده هر مخزن را با جزییات توضیح می‌دهد، به شکلی که بتوان از این مستندات برای ایجاد گزارش مدیریتی و یا مهاجرت داده احتمالی به سیستم‌های دیگر استفاده نمود.  

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

• نسخه اول باید قبل از اولین نصب تحویل شده باشد. 
• حداقل باید در هر فاز نسخه به‌روز تحویل گردد. 

• سند «نمای استقرار فیزیکی» به اطلاعات دقیق و فیزیکی سرورها و سرویس‌ها اشاره دارد. 
• در نمای استقرار مفهومی (جزئی از سند معماری) به پردازه‌ها، ماموریت و ارتباطات هر یک از آن‌ها اشاره می‌شود ولی به تعداد و آدرس دقیق سرورها/سرویس‌ها اشاره نمی‌شود.
  • مثلا در نمای استقرار مفهومی گفته می‌شود که یک کلاستر Cassandra‌ داریم و کارکرد و ارتباطات آن تشریح می‌گردد. در عوض در نمای استقرار فیزیکی هر یک از نودهای کلاستر کاساندرا با ذکر آدرس مشخص می‌شوند.  
• بدیهی است به تکرار اطلاعات مندرج در نمای استقرار مفهومی از جمله معرفی پردازه‌ها در این سند نیازی نیست. نام‌گذاری آیتم‌ها در این سند باید به گونه‌ای باشد که به اطلاعات مربوطه از نمای استقرار مفهومی قابل احصاء باشد.

• سند «نمای استقرار فیزیکی» محرمانگی بالاتری نسبت به نمای استقراری مفهومی دارد و باید در یک بستر حفاظت‌شده‌تر نگهداری گردد.
• «نمای استقرار فیزیکی» می‌تواند در قالب یک فایل اکسل نگهداری شود. 
• رایج است که «پوستر نمای استقرار فیزیکی» در NOC نصب شود. 
• در صورت وجود این اقلام اطلاعاتی در CMDB یا Configuration Management Database می‌توان از این سند چشم‌پوشی کرد.

• نسخه اول باید قبل از اولین نصب تحویل شده باشد. 
• با هر تغییر در نمای استقرار فیزیکی به‌روز می‌شود.

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

منظور از کد تنها کدِ منبع ماژول‌های توسعه‌داده‌شده نیست. با توجه به فراگیر شدن رویکردهای x as a code (هم‌چون infra-structure as a code یا config as a code و ...) همه کدهایی که به نوعی در زمان کامپایل، تست، نصب یا اجرا نقش ایفا می‌کنند را شامل می‌شود. 

برخی از مصادیق کد:

• کد منبع ماژول‌های توسعه‌داده‌شده
• اسکریپت‌های ساخت/به‌روزرسانی جداول و تنظیمات پایگاه‌داده
• پایپ‌لاین‌های CI/CD
• تست‌های واحد و یکپارچه‌سازی
• اسکریپت‌های تست بار و سایر ویژگی‌های کیفی 
• فایل‌های مرتبط با خودکارسازی نصب، راه‌اندازی و پیکربندی سرورها اعم از انواع پیکربندی‌های کوبرنتیس یا ابزارهای همچون ansible و غیره
• پیکربندی و تنظیمات میان‌افزارها مثل تنظیمات وب‌سرور (nginx) و پایگاه‌داده

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

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

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

• سند «برنامه امور جاری پشتیبانی» بهتر است روی دانش‌نامه کارفرما قرار گیرد. در صورت عدم وجود دانش‌نامه، در قالب‌های Word و PDF تحویل می‌شود.
• گزارش انجام این امور می‌تواند در ابزار مدیریت سرویس (مثل Jira) ثبت شود. به این صورت که برای انجام هر کدام، یک Task ثبت شده و گزارش انجام آن‌ها ذیل آن Task یادداشت می‌شود.

• نسخه اول «برنامه امور جاری پشتیبانی» باید قبل از اولین نصب تحویل شده باشد. 

• در این سند کلیه اقدامات لازم در راستای تضمین کیفیت محصول و سرویس در محیط توسعه و عملیات مورد اشاره قرار می‌گیرد. لازم به تاکید است این سند خود تعیین‌کننده ضرورت تحویل‌دادنی‌های دیگر از جمله موارد آزمون (Test Case) و ... باشد. 
• بخش مهمی از این سند به مرور برنامه آزمون پرداخته و به جایگاه آزمون در فرایند توسعه اشاره می‌کند. در این بخش، برنامه تیم برای ایجاد آزمون‌های کارکردی در سطوح مختلف، روال انجام تست ویژگی‌های کیفی و زمان اجرای تست‌ها و فواصل ارائه گزارشات تست و آستانه‌های قابل قبول پرداخته می‌شود. 
• ساز و کارهای مدیریت دانش، مانیتورینگ و  مدیریت لاگ از دیگر بخش‌های مهم این سند هستند. 

• بهتر است روی دانش‌نامه کارفرما قرار گیرد. در صورت عدم وجود دانش‌نامه، در قالب‌های Word و PDF تحویل می‌شود.

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

• تست کارکردهای سامانه باید حتی‌الامکان به صورت خودکار انجام گردد. موارد تست باید در پایپ‌لاین CI/CD قرار گیرند و با هر کامیت و به‌ویژه قبل از هر نصب اجرا شوند. نتایج تست با مراجعه به نتایج اجرای پایپ‌لاین قابل مشاهده است. 
• در صورت نیاز محدود به تست‌های دستی، نتایج تست باید در یک کانال ارتباطی مناسب به اشتراک گذاشته شده و نواقص در ابزار مدیریت پروژه issue شود. 
• در صورت نیاز گسترده به تست دستی، لازم است از ابزارهای مدیریت تست (Test Management Tools)  مانند TestLink استفاده شود. 

• نتایج تست‌های خودکار در خروجی پایپ‌لاین قرار می‌گیرد. 
• نتایج تست‌های دستی محدود در یک کانال مخصوص در ابزار ارتباطی تیم پروژه (مثل Slack یا Teams) گزارش می‌شود. 
• نتایج تست‌های دستی گسترده باید در ابزار مدیریت تست تحویل شود. 

• نتایج تست‌های خودکار، با هر اجرای پایپ‌لاین CI/CD تولید می‌شود. 
• تست‌های دستی باید قبل از هر نصب و همچنین به صورت دوره‌ای اجرا و گزارش شوند. 

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

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

• بهتر است روی دانش‌نامه کارفرما قرار گیرد. در صورت عدم وجود دانش‌نامه، در قالب‌های Word و PDF تحویل می‌شود.

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

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

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

• با هر ارتقای سیستم به‌روزرسانی شده و قابلیت‌های جدید یا تغییر یافته را پوشش می‌دهد. 

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

• بهتر است روی دانش‌نامه کارفرما قرار گیرد. در صورت عدم وجود دانش‌نامه، در قالب‌های Word و PDF تحویل می‌شود.

• نسخه اول باید قبل از اولین نصب تحویل شده باشد. 
• با اضافه شدن مخازن داده جدید یا تغییر برنامهِ پشتیبان‌گیری، این سند به‌روز می‌شود.

• بهتر است مستندسازی در قالب استانداردهای رایج همچون Swagger در اختیار مصرف‌کنندگان قرار گیرد. 
• برای تشریح روایی‌تر API از دانش‌نامه کارفرما یا قالب Word کمک می‌گیریم. 
• در صورتی که سازمان مجهز به ابزار API Management بوده و این ابزار از Developer Portal پشتیبانی نماید، این مستندات از طریق این پرتال به مصرف‌کنندگان ارائه می‌شود. 

• نسخه اول باید قبل از اولین نصب تحویل شده باشد. 
• با هر تغییر در API قبل از نصب نسخه جدید یا همزمان با نصب تحویل می‌گردد.  

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

• با توجه به ماهیت تکاملی و تعاملی این سند، اکیدا توصیه می‌شود روی دانش‌نامه کارفرما قرار گیرد. در صورت عدم وجود دانش‌نامه، در قالب‌های Word و PDF تحویل و تکمیل می‌شود.
• باید در فرایند مدیریت Incident (که قاعدتا توسط ابزار مدیریت سرویس، مدیریت می‌شود) مرحله‌ای برای چک کردن ضرورت تکمیل این سند در نظر گرفته شود. 

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

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

• بهتر است روی دانش‌نامه کارفرما قرار گیرد. در صورت عدم وجود دانش‌نامه، در قالب‌های Word و PDF تحویل می‌شود.

• نسخه اول باید قبل از اولین نصب تحویل شده باشد. 
• با تغییر وظایف نیروی انسانی در فرایند نصب به‌روزرسانی می‌گردد. 

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

• به ازای هر نصبی که انجام می‌شود، باید تگ متناظر در مخزن کد پروژه و نسخه متناظر در ابزار مدیریت پروژه ثبت شده باشد. با فرض اینکه هر تغییری که روی کد انجام می‌شود، دارای Issue در ابزار مدیریت پروژه می‌باشد و مشخص است یک Issue در چه نسخه یا نسخی انجام شده (یعنی برای ایشوها Fix Versions تعیین می‌شود) «مدیران پروژه» و «تیم عملیات و پشتیبانی» از روی ابزار مدیریت پروژه به Release Note مورد نیاز خود دسترسی خواهند داشت. 
• اطلاع‌رسانی در مورد تغییرات نسخ جدید به کاربران و راهبران بهتر است از داخل خود سامانه انجام گردد. این اطلاع‌رسانی تنها در صورتی ضرورت دارد که ایشان از نصب نسخه جدید متاثر شوند. 

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

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

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