تحویل نرم افزار اختصاصی زمانی روشن می شود که کارفرما بتواند کار اصلی کسب وکار را با نسخه مشخصی از محصول انجام دهد و بداند بعد از تحویل، مسئول هر بخش کیست. بازشدن صفحه ورود یا نمایش چند فرم، تمام این مسیر را پوشش نمی دهد. این چک لیست به شما کمک می کند جلسه تحویل را با سناریو، سند و نتیجه قابل پیگیری برگزار کنید.
مبنای پذیرش باید نیازهای مورد توافق پروژه باشد. اگر هنوز خروجی ها دقیق نشده اند، ابتدا شرح نیاز پروژه نرم افزار را کامل کنید. نمونه های این مطلب پیشنهادی اند و باید با نوع محصول و توافق شما تطبیق داده شوند.
1. نسخه و محیط مورد بررسی را مشخص کنید
در صورت جلسه بنویسید کدام نسخه، در چه محیطی و در چه تاریخی بررسی شده است. محیط آزمایشی با محیط عملیاتی تفاوت دارد؛ موفقیت در یکی به تنهایی عملکرد دیگری را ثابت نمی کند. اگر پیامک، درگاه یا نرم افزار حسابداری متصل است، وضعیت اتصال و محدوده آزمون هر کدام را جدا ثبت کنید.
برای یک سامانه ثبت سفارش، سناریو می تواند این باشد: کاربر مجاز سفارش می سازد، مسئول مربوط آن را تأیید می کند، وضعیت تغییر می کند و گزارش مدیریتی قابل تطبیق است. داده آزمایشی باید قابل تشخیص باشد تا با درخواست مشتری واقعی اشتباه نشود. آزمون دارای پرداخت، ارسال پیام یا تغییر موجودی را فقط با هماهنگی مسئول همان سرویس اجرا کنید.
2. نیازها را به سناریوی پذیرش تبدیل کنید
برای هر قابلیت سه چیز بنویسید: پیش شرط، اقدام و نتیجه مورد انتظار. مثلاً «کاربر شعبه الف وارد شده است؛ سفارش شعبه ب را جست وجو می کند؛ سامانه مطابق سطح دسترسی توافق شده آن را نمایش نمی دهد.» این سناریو به اندازه بررسی ثبت موفق سفارش اهمیت دارد.
- مسیر موفق: عملیات عادی با داده معتبر انجام شود.
- ورودی نامعتبر: داده ناقص یا اشتباه، پیام قابل فهم ایجاد کند و نتیجه نادرست ذخیره نشود.
- مجوزها: هر نقش فقط اطلاعات و عملیات مجاز خود را ببیند.
- تکرار عملیات: دوبار کلیک یا ارسال دوباره، رفتار تعریف شده داشته باشد.
- قطع سرویس: هنگام در دسترس نبودن سرویس بیرونی، وضعیت و راه پیگیری روشن بماند.
به جای عبارت «گزارش درست باشد»، یک نمونه داده کوچک با جمع مورد انتظار آماده کنید. اگر گزارش تعداد سفارش های تکمیل شده را نشان می دهد، تعریف «تکمیل شده»، محدوده تاریخ و وضعیت سفارش لغوشده را از قبل تعیین کنید.
3. بسته تحویل فنی را فهرست کنید
موارد تحویلی باید با قرارداد سازگار باشند. در پروژه ای که تحویل سورس کد جزو توافق است، نسخه منبع، تاریخ یا شناسه نسخه، وابستگی ها و راهنمای ساخت باید مشخص باشند. سورس بدون توضیح روش اجرا ممکن است برای تیم نگهدارنده بعدی کافی نباشد. در محصول دارای مجوز یا سرویس اشتراکی، حدود استفاده و دسترسی را جدا روشن کنید.
- راهنمای نصب و انتشار، پیش نیازها و ترتیب تنظیم سرویس های لازم.
- فهرست تنظیمات موردنیاز، بدون قرارگرفتن رمز و کلید واقعی در مستندات عمومی یا مخزن کد.
- ساختار پایگاه داده و روش تغییر نسخه آن، متناسب با توافق پروژه.
- راهنمای کاربری نقش های اصلی و آموزش عملیات پرتکرار.
- فهرست سرویس های بیرونی، مالک حساب، زمان تمدید و راه ارتباط با پشتیبان.
4. مالکیت حساب و تحویل رمز را جدا مدیریت کنید
مالک دامنه، میزبانی، مخزن کد و سرویس های متصل را ثبت کنید. نام حساب، نقش مسئول و روش بازیابی دسترسی باید معلوم باشد. رمزها را در صورت جلسه عمومی، تصویر یا پیام گروهی ننویسید؛ انتقال آن ها باید از مسیر امن مورد توافق انجام شود. بعد از تحویل نیز دسترسی افراد بر اساس نقش و نیاز واقعی بازبینی شود.
تحویل همه حساب ها به یک فرد بدون تعیین جانشین، پیگیری بعدی را دشوار می کند. برای هر سامانه یک مسئول سازمانی و روش بازیابی مشخص کنید. فهرست دسترسی ها با فهرست رمزها یکی نیست؛ سند تحویل می تواند وجود و مالکیت دسترسی را تأیید کند، بدون اینکه اطلاعات محرمانه را افشا کند.
5. نسخه پشتیبان را با بازیابی آزمایشی ارزیابی کنید
وجود یک فایل پشتیبان، موفقیت بازیابی را ثابت نمی کند. بخواهید روش تهیه، محل نگهداری، مدت نگهداری و مسئول کنترل نسخه ها مشخص شود. بازیابی نمونه باید در محیط جدا و مورد تأیید انجام شود تا اطلاعات عملیاتی بازنویسی نشوند.
پس از بازیابی، فقط بالا آمدن برنامه را نبینید؛ چند رکورد نمونه، فایل پیوست و گزارش مرتبط را هم کنترل کنید. زمان بازیابی مشاهده شده و داده ای که ممکن است بین دو پشتیبان از دست برود را ثبت کنید. این اعداد باید از آزمون و سیاست واقعی تیم بیایند، نه از یک قول عمومی.
6. ایرادها و مسئولیت بعد از تحویل را روشن بنویسید
هر ایراد یک شناسه، شرح، روش بازتولید و مسئول پیگیری داشته باشد. مواردی مثل توقف مسیر اصلی یا دسترسی نامجاز، با تغییر متن یک دکمه در یک سطح قرار نمی گیرند. تعریف شدت و شرط پذیرش را طرفین توافق کنند؛ برای موارد باز، زمان بررسی مجدد و اثر آن بر تحویل روشن باشد.
در صورت جلسه نهایی، نسخه تأییدشده، سناریوهای اجراشده، موارد اجرا نشده، آموزش های تحویل شده و فهرست مسائل باز را ثبت کنید. رفع ایراد با افزودن قابلیت جدید دو دامنه متفاوت دارد و لازم است روش درخواست تغییر مشخص باشد. برای ادامه همکاری، دامنه پشتیبانی و نگهداری نرم افزار را بررسی کنید.
این چک لیست در مرحله انتخاب شرکت برنامه نویسی در شیراز هم مفید است: از تیم درباره روش تحویل و پذیرش سؤال کنید. برای بررسی نیاز اتوماسیون سازمان خود می توانید خدمات نرم افزار و اتوماسیون کسب وکار را ببینید و سناریوی پروژه را برای گلجام بفرستید.