قرارداد توسعهٔ نرم‌افزار: تحویل‌دادنی‌ها و معیار پذیرش را چطور بنویسیم؟

قرارداد توسعهٔ نرم‌افزار برای اینکه جلوی دعوای «تمام شد یا نه» را بگیرد، دو چیز را باید مکتوب و قابل‌آزمون کند: فهرست دقیق تحویل‌دادنی‌ها (کد، مستندات، دسترسی‌ها، محیط‌ها) و معیارهای پذیرش هر قابلیت و هر مرحله. این مقاله یک راهنمای فنی و عملی است، نه مشاورهٔ حقوقی: متن بندها، ضمانت‌ها، جریمه‌ها و مالکیت فکری را باید با وکیل و بر اساس قوانین روز ایران تنظیم کنید؛ اینجا فقط می‌گوییم از نظر مهندسی چه چیزهایی باید در پیوست‌های فنی آن بیاید.

سه اصطلاحی که اغلب با هم قاطی می‌شوند

• تحویل‌دادنی (deliverable): چیزی که باید به شما داده شود؛ مثلاً مخزن کد، سند راه‌اندازی یا نسخهٔ مستقرشده.
• معیار پذیرش (acceptance criteria): شرط‌هایی که سیستم باید داشته باشد تا کاربر، مشتری یا نهاد مجاز آن را بپذیرد. این تعریف در واژه‌نامهٔ ISTQB آمده است (نسخه‌ای که ما از یک بازنشر واژه‌نامه خواندیم؛ تعریف نسخه‌های مختلف ممکن است فرق کند).
• تعریف «انجام‌شده» (Definition of Done): استاندارد کیفی داخلی تیم سازنده. راهنمای Scrum آن را توصیف رسمی وضعیتی می‌داند که یک Increment وقتی به معیارهای کیفی لازم برای محصول رسیده باشد دارد و می‌گوید کاری که به آن نرسد جزو Increment حساب نمی‌شود.

تفاوت عملی: Definition of Done می‌گوید کار از نظر تیم فنی چقدر کامل است (مثلاً بازبینی و تست شده)؛ معیار پذیرش می‌گوید رفتار قابلیت از نظر کسب‌وکار چه باید باشد. هر دو لازم‌اند و جای هم را نمی‌گیرند. برای اینکه ورودی‌ها آماده باشد، پیش از قرارداد برنامه‌ریزی پروژه پیش از نوشتن کد را ببینید.

فهرست تحویل‌دادنی‌ها: «نرم‌افزار» کافی نیست

نوشتن «تحویل نرم‌افزار» در قرارداد، ابهام می‌سازد. جدول زیر الگوی پیشنهادی (توصیهٔ عملی نویسنده) برای پیوست فنی است؛ برای هر ردیف مشخص کنید در روز تحویل چه چیزی نشان داده می‌شود.

برای مستندات، Documentation چیست و چرا پروژه‌های حرفه‌ای بدون آن آسیب‌پذیر می‌شوند نشان می‌دهد چه چیزی ارزش نوشتن دارد. و برای اینکه بدانید «آمادهٔ استقرار» از نظر فنی چه معنایی دارد، چه چیزی یک محصول نرم‌افزاری را Production-Ready می‌کند مرجع خوبی است.

نوشتن معیار پذیرش قابل‌آزمون

معیار پذیرش خوب به‌جای توصیف روش پیاده‌سازی، می‌گوید چه کسی در چه شرایطی چه کاری انجام می‌دهد و چه نتیجه‌ای باید ببیند. قالب Given-When-Then که Martin Fowler توضیح داده، سناریو را به سه بخش می‌شکند: حالت اولیه (Given)، رفتار موردنظر (When) و تغییری که انتظار دارید (Then). مثال زیر کاملاً فرضی است:

قابلیت: دریافت گزارش سفارش‌ها (مثال فرضی)
سناریو: کارشناس مالی گزارش همان شعبه را می‌گیرد
  با فرض اینکه کارشناس مالی شعبهٔ الف وارد شده و دو سفارش برای شعبهٔ الف و یک سفارش برای شعبهٔ ب ثبت شده است
  وقتی گزارش سفارش‌ها را درخواست کند
  آنگاه فقط دو سفارش شعبهٔ الف را ببیند و سفارش شعبهٔ ب نمایش داده نشود

روند پذیرش: چه کسی، کجا، با چه مهلتی؟

در واژه‌نامهٔ ISTQB، تست پذیرش کاربر (UAT) تست پذیرشی است که کاربران آینده در محیطی عملیاتی یا شبیه‌سازی‌شده انجام می‌دهند و بر نیازها و خواست‌های کاربر تمرکز دارد. برای پیوست پذیرش این‌ها را مکتوب کنید:

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

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

امنیت در پذیرش: دو نمونه برای گفت‌وگو

پروژهٔ OWASP در «Secure Software Contract Annex» می‌نویسد بیشتر قراردادها دربارهٔ امنیت ساکت‌اند و طرفین اغلب برداشت‌های متفاوتی از آنچه توافق شده دارند. این سند خودش را فقط راهنما می‌داند و توصیه می‌کند حتماً با وکیل مشورت شود. نمونه‌ای از بند پذیرش در آن می‌گوید نرم‌افزار تا وقتی «بستهٔ گواهی» (certification package) کامل و همهٔ مسائل امنیتی رفع نشده پذیرفته‌شده حساب نمی‌شود، و نمونهٔ دیگری به کارفرما حق می‌دهد تا ۶۰ روز پس از تحویل نرم‌افزار را برای ایرادهای امنیتی بازبینی کند. این‌ها نمونه‌هایی از یک سند پیشنهادی‌اند، نه استاندارد عمومی؛ همان سند می‌گوید سطح سخت‌گیری باید با اهمیت نرم‌افزار متناسب باشد و تصمیم دربارهٔ اینکه هزینه با کیست را عمداً باز گذاشته است. از آن به‌عنوان فهرست پرسش برای مذاکره استفاده کنید، نه متن آماده.

اشتباه‌هایی که در پیوست‌ها زیاد دیده می‌شود

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

چک‌لیست پیش از امضا و در روز تحویل

1. پیوست فنی هر تحویل‌دادنی را با شاهد تحویل نوشته است.
2. هر قابلیت اصلی دست‌کم یک معیار پذیرش قابل‌آزمون دارد.
3. نسخه، محیط، داده و مسئولان آزمون مشخص‌اند.
4. شدت اشکال‌ها و اثرشان بر پذیرش تعریف شده است.
5. مهلت بررسی و فرمت صورت‌جلسه روشن است.
6. مخزن و حساب‌ها به نام شما هستند و در روز تحویل ورود آزمایش می‌شود.
7. بندهای حقوقی توسط وکیل بازبینی شده‌اند.

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

منابع و مراجع

• 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).