قرارداد توسعهٔ نرم‌افزار: تحویل‌دادنی‌ها و معیار پذیرش را چطور بنویسیم؟
7 min read
راهنمای فنی (نه حقوقی) برای پیوست قرارداد توسعهٔ نرم‌افزار: فهرست تحویل‌دادنی با شاهد تحویل، معیار پذیرش قابل‌آزمون، شدت اشکال و روند پذیرش.
قرارداد توسعهٔ نرم‌افزار برای اینکه جلوی دعوای «تمام شد یا نه» را بگیرد، دو چیز را باید مکتوب و قابل‌آزمون کند: فهرست دقیق تحویل‌دادنی‌ها (کد، مستندات، دسترسی‌ها، محیط‌ها) و معیارهای پذیرش هر قابلیت و هر مرحله. این مقاله یک راهنمای فنی و عملی است، نه مشاورهٔ حقوقی: متن بندها، ضمانت‌ها، جریمه‌ها و مالکیت فکری را باید با وکیل و بر اساس قوانین روز ایران تنظیم کنید؛ اینجا فقط می‌گوییم از نظر مهندسی چه چیزهایی باید در پیوست‌های فنی آن بیاید.
سه اصطلاحی که اغلب با هم قاطی می‌شوند
- تحویل‌دادنی (deliverable): چیزی که باید به شما داده شود؛ مثلاً مخزن کد، سند راه‌اندازی یا نسخهٔ مستقرشده.
- معیار پذیرش (acceptance criteria): شرط‌هایی که سیستم باید داشته باشد تا کاربر، مشتری یا نهاد مجاز آن را بپذیرد. این تعریف در واژه‌نامهٔ ISTQB آمده است (نسخه‌ای که ما از یک بازنشر واژه‌نامه خواندیم؛ تعریف نسخه‌های مختلف ممکن است فرق کند).
- تعریف «انجام‌شده» (Definition of Done): استاندارد کیفی داخلی تیم سازنده. راهنمای Scrum آن را توصیف رسمی وضعیتی می‌داند که یک Increment وقتی به معیارهای کیفی لازم برای محصول رسیده باشد دارد و می‌گوید کاری که به آن نرسد جزو Increment حساب نمی‌شود.
تفاوت عملی: Definition of Done می‌گوید کار از نظر تیم فنی چقدر کامل است (مثلاً بازبینی و تست شده)؛ معیار پذیرش می‌گوید رفتار قابلیت از نظر کسب‌وکار چه باید باشد. هر دو لازم‌اند و جای هم را نمی‌گیرند. برای اینکه ورودی‌ها آماده باشد، پیش از قرارداد برنامه‌ریزی پروژه پیش از نوشتن کد را ببینید.
فهرست تحویل‌دادنی‌ها: «نرم‌افزار» کافی نیست
نوشتن «تحویل نرم‌افزار» در قرارداد، ابهام می‌سازد. جدول زیر الگوی پیشنهادی (توصیهٔ عملی نویسنده) برای پیوست فنی است؛ برای هر ردیف مشخص کنید در روز تحویل چه چیزی نشان داده می‌شود.
| تحویل‌دادنی | شاهد در روز تحویل |
|---|---|
| کد منبع کامل با تاریخچهٔ تغییرات در مخزنی که مالک آن شماست | دسترسی مدیر به مخزن و فهرست شاخه‌ها و برچسب نسخهٔ تحویلی |
| دستور ساخت و اجرا | یک نفر خارج از تیم سازنده نرم‌افزار را از صفر روی محیط آزمایشی بالا بیاورد |
| فهرست متغیرهای پیکربندی (فقط نام و توضیح، نه مقدار راز) | سند پیکربندی و محل امن نگه‌داری رازها که به شما منتقل شده |
| طرح دیتابیس و اسکریپت‌های مهاجرت | اجرای مهاجرت روی دیتابیس خالی و دیدن همان ساختار |
| مستندات API و راهنمای فنی | نمونه درخواست‌ها که با سند هماهنگ جواب می‌دهد |
| فهرست کتابخانه‌ها و سرویس‌های شخص ثالث و لایسنس آنها | فهرست مکتوب؛ بررسی حقوقی با شما |
| دسترسی مدیر به سرویس‌ها (میزبانی، دامنه، پیامک، درگاه) به نام شما | ورود با حساب خودتان و ثبت فهرست دسترسی‌ها |
| آزمون‌های خودکار و گزارش اجرای آنها (در صورت توافق) | اجرای مجموعه آزمون و گزارش خروجی |
| راهنمای کاربر یا جلسهٔ آموزش | صورت‌جلسهٔ آموزش یا سند تحویل‌شده |
| روش پشتیبان‌گیری و بازیابی | یک بار بازیابی نمونه روی محیط آزمایشی |
برای مستندات، Documentation چیست و چرا پروژه‌های حرفه‌ای بدون آن آسیب‌پذیر می‌شوند نشان می‌دهد چه چیزی ارزش نوشتن دارد. و برای اینکه بدانید «آمادهٔ استقرار» از نظر فنی چه معنایی دارد، چه چیزی یک محصول نرم‌افزاری را Production-Ready می‌کند مرجع خوبی است.
نوشتن معیار پذیرش قابل‌آزمون
معیار پذیرش خوب به‌جای توصیف روش پیاده‌سازی، می‌گوید چه کسی در چه شرایطی چه کاری انجام می‌دهد و چه نتیجه‌ای باید ببیند. قالب Given-When-Then که Martin Fowler توضیح داده، سناریو را به سه بخش می‌شکند: حالت اولیه (Given)، رفتار موردنظر (When) و تغییری که انتظار دارید (Then). مثال زیر کاملاً فرضی است:
قابلیت: دریافت گزارش سفارش‌ها (مثال فرضی)
سناریو: کارشناس مالی گزارش همان شعبه را می‌گیرد
با فرض اینکه کارشناس مالی شعبهٔ الف وارد شده و دو سفارش برای شعبهٔ الف و یک سفارش برای شعبهٔ ب ثبت شده است
وقتی گزارش سفارش‌ها را درخواست کند
آنگاه فقط دو سفارش شعبهٔ الف را ببیند و سفارش شعبهٔ ب نمایش داده نشود| عبارت مبهم | معیار قابل‌آزمون (نمونه) |
|---|---|
| سامانه ایمن باشد | کاربری بدون نقش مدیر نتواند صفحهٔ مدیریت را باز کند و پاسخ «دسترسی ممنوع» بگیرد |
| گزارش سریع باشد | در محیط آزمایشی و با دادهٔ توافق‌شده، زمان نمایش گزارش از مقدار توافقی بیشتر نشود (عدد را خودتان با پروژه تعیین می‌کنید) |
| فرم کاربرپسند باشد | کاربر با ورودی نامعتبر پیام خطای مشخص روی همان فیلد ببیند و داده‌اش پاک نشود |
روند پذیرش: چه کسی، کجا، با چه مهلتی؟
در واژه‌نامهٔ ISTQB، تست پذیرش کاربر (UAT) تست پذیرشی است که کاربران آینده در محیطی عملیاتی یا شبیه‌سازی‌شده انجام می‌دهند و بر نیازها و خواست‌های کاربر تمرکز دارد. برای پیوست پذیرش این‌ها را مکتوب کنید:
- نسخه‌ای که آزموده می‌شود (شمارهٔ نسخه یا برچسب) و محیط و داده‌ای که با آن آزموده می‌شود.
- چه کسی از طرف شما آزمون می‌کند و چه کسی تصمیم نهایی را می‌گیرد.
- مهلت بررسی و اعلام اشکال‌ها پس از هر تحویل.
- دسته‌بندی شدت اشکال‌ها و اثر هر دسته بر پذیرش.
- قالب صورت‌جلسهٔ پذیرش: سناریوهای موفق و ناموفق، موارد باز، مسئول و موعد.
| شدت | مثال | اثر بر پذیرش |
|---|---|---|
| مسدودکننده | ورود کار نمی‌کند یا داده از بین می‌رود | پذیرش انجام نمی‌شود |
| بالا | یک جریان مهم بدون راه جایگزین خطا می‌دهد | باید پیش از پذیرش رفع شود یا در پذیرش مشروط ثبت شود |
| متوسط | اختلال محدود با راه جایگزین | در دورهٔ رفع اشکال برطرف شود |
| پایین | ایراد ظاهری | مانع پذیرش نیست و در فهرست ثبت می‌شود |
اگر داده‌های واقعی حساس‌اند، برای آزمون از داده‌ی ناشناس‌شده یا محیط جداگانه استفاده کنید. این‌ها توصیهٔ مهندسی‌اند؛ اثر حقوقی «پذیرش مشروط» و «پذیرش ضمنی در صورت سکوت» را باید وکیل تعیین کند.
امنیت در پذیرش: دو نمونه برای گفت‌وگو
پروژهٔ OWASP در «Secure Software Contract Annex» می‌نویسد بیشتر قراردادها دربارهٔ امنیت ساکت‌اند و طرفین اغلب برداشت‌های متفاوتی از آنچه توافق شده دارند. این سند خودش را فقط راهنما می‌داند و توصیه می‌کند حتماً با وکیل مشورت شود. نمونه‌ای از بند پذیرش در آن می‌گوید نرم‌افزار تا وقتی «بستهٔ گواهی» (certification package) کامل و همهٔ مسائل امنیتی رفع نشده پذیرفته‌شده حساب نمی‌شود، و نمونهٔ دیگری به کارفرما حق می‌دهد تا ۶۰ روز پس از تحویل نرم‌افزار را برای ایرادهای امنیتی بازبینی کند. این‌ها نمونه‌هایی از یک سند پیشنهادی‌اند، نه استاندارد عمومی؛ همان سند می‌گوید سطح سخت‌گیری باید با اهمیت نرم‌افزار متناسب باشد و تصمیم دربارهٔ اینکه هزینه با کیست را عمداً باز گذاشته است. از آن به‌عنوان فهرست پرسش برای مذاکره استفاده کنید، نه متن آماده.
اشتباه‌هایی که در پیوست‌ها زیاد دیده می‌شود
- نوشتن «تحویل نرم‌افزار» بدون فهرست کد، مستندات و دسترسی‌ها.
- معیار پذیرش که فقط صفت دارد («سریع»، «ایمن») و عدد یا سناریو ندارد.
- نداشتن دسته‌بندی شدت اشکال؛ نتیجه این است که هر ایرادی بتواند پذیرش را متوقف کند یا اشکال جدی «جزئی» جا زده شود.
- نبود مهلت بررسی؛ هر طرف می‌تواند تصمیم را معلق نگه دارد.
- مشخص‌نبودن اینکه تغییر درخواستی با اشکال چه فرقی دارد.
چک‌لیست پیش از امضا و در روز تحویل
- پیوست فنی هر تحویل‌دادنی را با شاهد تحویل نوشته است.
- هر قابلیت اصلی دست‌کم یک معیار پذیرش قابل‌آزمون دارد.
- نسخه، محیط، داده و مسئولان آزمون مشخص‌اند.
- شدت اشکال‌ها و اثرشان بر پذیرش تعریف شده است.
- مهلت بررسی و فرمت صورت‌جلسه روشن است.
- مخزن و حساب‌ها به نام شما هستند و در روز تحویل ورود آزمایش می‌شود.
- بندهای حقوقی توسط وکیل بازبینی شده‌اند.
اگر می‌خواهید پیش از نوشتن قرارداد، نیازها و محدودیت‌های پروژه‌تان را مرور کنید، می‌توانید آنها را در صفحهٔ شروع پروژه بنویسید؛ طبق توضیح خود صفحه، ارسال فرم تعهدی برای شروع پروژه ایجاد نمی‌کند.
منابع و مراجع
- Acceptance Criteria — ISTQB Glossary (بازنشر وب‌سایت istqb-glossary.page).
- User Acceptance Testing — ISTQB Glossary (بازنشر وب‌سایت istqb-glossary.page).
- The Scrum Guide — Ken Schwaber و Jeff Sutherland، نسخهٔ نوامبر ۲۰۲۰.
- Given When Then — Martin Fowler، ۲۱ اوت ۲۰۱۳.
- Secure Software Contract Annex — OWASP Foundation (نویسنده: Jeff Williams).
Author
SE
Soheil Ebrahimpour is the founder of FutureForge. He works on product design, architecture, and getting custom software into production.
Related notes
If you are unsure about architecture or the build path, we can talk about the project.
Describe the problem and the constraints. If there is a fit, we will schedule a conversation.
