مالکیت کد، SLA و پشتیبانی نرمافزار چگونه روشن میشوند؟
مالکیت نرمافزار فقط یک جمله درباره کد نیست؛ داده، مخزن، طراحی، دامنه، حساب زیرساخت، کلیدها، مستندات و حق تغییر باید جداگانه تعیین شوند. SLA نیز بدون ساعت خدمت، شدت رخداد، زمان پاسخ، زمان بازیابی و مسیر تشدید قابل سنجش نیست. پشتیبانی پایدار از تحویل مستمر دانش و آزمون بازیابی شروع میشود.
چه زمانی بررسی این مسیر جدی میشود؟
این نشانهها ضرورت خرید یا ساخت را اثبات نمیکنند؛ فقط مشخص میکنند کدام فرضها باید با داده و سناریوی واقعی بررسی شوند.
مالکیت حقوقی
مالک و حق استفاده، تغییر، انتقال و بازتوزیع هر دارایی باید با استثناهای کدباز و اجزای ثالث نوشته شود.
کنترل عملی
دسترسی واقعی به مخزن، دامنه، زیرساخت، پایگاه داده، مانیتورینگ، حسابها و تاریخچه تغییر لازم است.
تداوم خدمت
پشتیبان، بازیابی، آسیبپذیری، رخداد، نگهداری و خروج باید نقش، آزمون و شواهد دورهای داشته باشند.
در قرارداد چه چیزی باید قابل سنجش باشد؟
این جدول مشاوره حقوقی نیست؛ فهرستی عملی برای تبدیل عبارتهای کلی به اقلام قابل تحویل و آزمون است.
| موضوع | حداقل باید روشن شود | شاهد قابل بررسی | خطر ابهام |
|---|---|---|---|
| کد و وابستگی | مالکیت، مجوز، اجزای ثالث و حق تغییر | مخزن، SBOM یا فهرست وابستگی و مجوزها | قفلشدن یا منع تغییر |
| داده | مالک، محل، قالب خروج و زمان حذف | خروج نمونه و آزمون بازیابی | داده ناقص یا غیرقابل استفاده |
| زیرساخت | مالک حساب، دسترسی و هزینهها | فهرست حساب و نقشهای مجاز | وابستگی به حساب شخصی فروشنده |
| SLA | ساعت، شدت، پاسخ، بازیابی و تشدید | گزارش رخداد و اندازهگیری زمان | وعده مبهم بدون قابلیت مطالبه |
| خروج | مهلت، همکاری، اقلام و معیار پایان | تمرین تحویل به تیم دوم | توقف عملیات در پایان همکاری |
این تصمیم چگونه به اجرای کنترلشده میرسد؟
هر مرحله باید خروجی قابل مشاهده و شرط ادامه داشته باشد تا ابهام به انتهای پروژه منتقل نشود.
- ثبت داراییها کد، داده، طراحی، دامنه، حساب، کلید، مستند و مؤلفه ثالث فهرست میشوند.
- تعیین مالک و دسترسی مالک حقوقی، مدیر حساب و دسترسی روزمره هر دارایی جدا ثبت میشود.
- تعریف شدت رخداد اثر کسبوکاری، دامنه کاربران و توقف عملیات، شدت را تعیین میکنند.
- نوشتن هدف خدمت ساعت پوشش، پاسخ، اقدام، بازیابی، ارتباط و استثناها قابل اندازهگیری میشوند.
- آزمون تداوم بازگردانی پشتیبان، استقرار نسخه و پاسخ به آسیبپذیری دورهای تمرین میشوند.
- تمرین خروج پیش از پایان همکاری، تیم دوم با مستندات موجود یک تحویل یا استقرار را اجرا میکند.
چه عبارتهایی هنوز تعهد محسوب نمیشوند؟
واژههای کلی تا زمانی که دامنه، معیار و شاهد ندارند، اختلاف را کم نمیکنند.
- «مالکیت کامل» بدون فهرست دارایی و استثنا
- «پشتیبانی ۲۴/۷» بدون کانال، شدت و زمان پاسخ
- «داده قابل خروج» بدون قالب و آزمون نمونه
- «تحویل مستندات» بدون نام، نسخه و معیار کفایت
منابع و مسیرهای مرتبط کداماند؟
منابع بیرونی برای تعریف دامنه و معیارهای فنی استفاده شدهاند؛ پیشنهاد هر پروژه باید با داده و شرایط همان سازمان سنجیده شود.
برای انتخاب این مسیر چه معیارهایی مهماند؟
سه پرسش زیر دامنه، داده و تداوم تصمیم را پیش از قرارداد روشن میکنند.
| معیار | پرسش بررسی |
|---|---|
| کنترل | سازمان به کدام دارایی، حساب و تاریخچه باید دسترسی مستقیم داشته باشد؟ |
| خدمت | برای هر شدت رخداد چه ساعت، پاسخ، اقدام و تشدیدی لازم است؟ |
| خروج | تیم دیگری چگونه کد، داده، زیرساخت و دانش را بدون توقف تحویل میگیرد؟ |
چه زمانی این صفحه پاسخ شما نیست؟
اگر هنوز میان خرید و ساخت در سطح عمومی تصمیم نگرفتهاید یا موضوع شما دامنه دیگری دارد، ابتدا قیمت و مدل همکاری پروژه را ببینید.
پرسشهای متداول این صفحه کداماند؟
پاسخهای کوتاه زیر مرز تصمیم، اجرا و تعهد را روشن میکنند.
مالکیت کد با مالکیت داده یکی است؟
خیر. مالکیت و حق استفاده کد، داده، طراحی، مستندات و اجزای ثالث موضوعهای جدا هستند و باید جدا نوشته شوند.
SLA فقط زمان رفع خطاست؟
خیر. دامنه خدمت، ساعات پوشش، شدت رخداد، زمان پاسخ، هدف بازیابی، مسئول ارتباط، استثناها و گزارش نیز لازماند.
تحویل مخزن برای خروج کافی است؟
نه. محیط ساخت، وابستگی، حساب زیرساخت، کلید، داده، روش استقرار، مانیتورینگ، پشتیبان و دانش عملیاتی نیز باید قابل انتقال باشند.
پشتیبانی از چه زمانی طراحی میشود؟
از ابتدای معماری؛ ثبت رویداد، مشاهدهپذیری، نسخهبندی، پشتیبان، بازیابی و پاسخ به آسیبپذیری را نمیتوان به پایان پروژه موکول کرد.
آخرین بهروزرسانی: