هزینه نرم‌افزار اختصاصی

هزینه طراحی نرم‌افزار اختصاصی چگونه محاسبه می‌شود؟

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

تیم محصول در حال برآورد هزینه نرم‌افزار اختصاصی بر اساس ماژول‌ها و زمان‌بندی

انتشار: · آخرین به‌روزرسانی:

نویسنده: تحریریه پیکا با کمک هوش مصنوعی — پژوهش، نگارش و ویرایش فارسی

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

چه عواملی هزینه را تعیین می‌کنند؟

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

هزینه نسخه اول با هزینه مالکیت فرق دارد

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

دو نگاه به بودجه

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

چطور پیش از تحلیل، بودجه را کنترل کنیم؟

  1. مسئله را به یک جریان قابل‌اندازه‌گیری محدود کنید

    به‌جای «اتوماسیون کل شرکت»، یک فرایند، کاربران و نتیجه مورد انتظار را مشخص کنید.

  2. نسخه اول را بر اساس ریسک انتخاب کنید

    قابلیت‌هایی را جلو بیندازید که فرض اصلی کسب‌وکار یا یکپارچه‌سازی دشوار را زودتر آزمایش می‌کنند.

  3. اقلام خارج از دامنه را مکتوب کنید

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

  4. برای تغییر ذخیره بودجه بگذارید

    در پروژه اکتشافی، بخشی از بودجه باید برای یافته‌های واقعی مرحله تحلیل محفوظ بماند.

برای دریافت برآورد چه اطلاعاتی آماده کنیم؟

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

پرسش‌های پرتکرار

آیا بدون جلسه تحلیل می‌توان قیمت قطعی داد؟

برای دامنه کوچک و استاندارد شاید؛ اما برای سامانه سازمانی، عدد قطعی بدون شناخت استثناها و اتصال‌ها معمولاً یا حاشیه ریسک زیادی دارد یا بعداً با تغییر دامنه اصلاح می‌شود.

قرارداد ثابت بهتر است یا زمان و مواد؟

برای دامنه روشن، قرارداد ثابت قابل‌پیش‌بینی‌تر است. برای مسئله اکتشافی، مرحله کشف با قیمت ثابت و توسعه مرحله‌ای معمولاً ریسک کمتری از ثابت‌کردن زودهنگام کل پروژه دارد.

چرا انتقال داده جداگانه برآورد می‌شود؟

چون کیفیت، تکرار، ناسازگاری و نبود شناسه مشترک در داده قدیمی فقط پس از نمونه‌برداری مشخص می‌شود و می‌تواند از یک import ساده تا پروژه پاک‌سازی مستقل متغیر باشد.

برآورد سناریویی به‌جای قیمت تک‌عددی

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

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

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

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

پرسش‌های پرتکرار

چه زمانی برآورد اولیه باید بازنگری شود؟

پس از روشن‌شدن معماری، دسترسی به داده واقعی، آزمون اتصال‌های پرریسک و هر تغییر مهم دامنه یا معیار کیفیت.

منابع

  1. ISO/IEC 25010 — مدل کیفیت محصول نرم‌افزاری
  2. FinOps Foundation — FinOps Framework

مطالب مرتبط