طراحی نرم افزار اختصاصی و ساخت سامانه تحت وب با لاراول

پاسخ کوتاه: نرم افزار اختصاصی یعنی سامانه ای که دقیقا برای جریان کار خود شما ساخته می شود، نه نرم افزاری که شما مجبورید کارتان را با آن هماهنگ کنید. سفارش ساخت سامانهٔ اختصاصی با لاراول در کد یاس از یک جلسهٔ نیازسنجی شروع می شود، با دامنهٔ کار نوشته شده و فهرست معیار پذیرش ادامه پیدا می کند، مرحله به مرحله ساخته می شود و بعد از تست پذیرش تحویل داده می شود. ساخت سامانهٔ اختصاصی از ۱۵۰ میلیون تومان شروع می شود و زمان تحویل آن ۲ تا ۴ ماه است؛ سورس کد و همهٔ دسترسی ها به نام خودتان تحویل داده می شود.

این صفحه همان چیزی است که پشت عبارت های «طراحی نرم افزار اختصاصی» و «برنامه نویسی اختصاصی» نشسته است: چه زمانی ساخت سامانه جواب می دهد و کجا جواب نمی دهد، پنج مرحلهٔ کار و زمان هر مرحله، سازوکار قیمت، معیار پذیرش هر نسخه، و کدی که واقعا نوشته و تحویل داده می شود. ته صفحه یک چک لیست شش پرسشی هست که می توانید جوابشان را پیش از جلسهٔ اول آماده کنید.

نرم افزار اختصاصی برای چه کسب و کاری جواب می دهد و کجا جواب نمی دهد

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

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

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

یک نکته از سنجش خودمان: برای همین خوشه، ۱۵ صفحهٔ فارسی که در جستجوی عبارت «طراحی نرم افزار اختصاصی» و همسایه هایش بالا می آیند واکشی و از HTML خام شمرده شد. هیچ کدام یک بلوک کد نداشت، هیچ کدام نگفته بود قبولی نسخه چطور اثبات می شود، و هیچ کدام محدودهٔ کار خود را با عدد و جدول نشان نداده بود. در ادامه همین صفحه، همان سه چیز را با مثال آورده ایم.

از سفارش تا تحویل؛ پنج مرحله و زمان هر مرحله

پروژه بدون مرحلهٔ بندی، پروژهٔ بی پایان است. کار ما پنج مرحله دارد و هر مرحله یک خروجی قابل تحویل دارد که شما آن را می بینید و تایید می کنید. زمان ها بازه هستند، چون به تعداد جریان های کاری بستگی دارند:

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

هزینهٔ ساخت نرم افزار اختصاصی از چه چیزی ساخته می شود

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

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

معیار پذیرش: قبولی هر نسخه چطور اثبات می شود

در پروژهٔ نرم افزاری، دعوای آخر همیشه سر یک جمله است: «این همان چیزی است که خواستیم؟» راه جلوگیری از این دعوا، نوشتن معیار پذیرش پیش از شروع ساخت است. معیار پذیرش یعنی هر بند دامنهٔ کار به یک جملهٔ قابل آزمون تبدیل شود: چه کسی، چه کاری را انجام می دهد، و سیستم چه پاسخی باید بدهد. بعد همان جمله ها به تست تبدیل می شوند. نمونهٔ زیر یک تست واقعی از پروژه ای است که در آن فاکتور فقط برای صاحب خودش قابل دیدن است:

it('only the invoice owner can see it', function () {
    $owner = User::factory()->create();
    $other = User::factory()->create();
    $invoice = Invoice::factory()->for($owner)->create();

    $this->actingAs($owner)
        ->get("/api/invoices/{$invoice->id}")
        ->assertOk();

    $this->actingAs($other)
        ->get("/api/invoices/{$invoice->id}")
        ->assertForbidden();
});

اجرای این تست یک دستور است: php artisan test. تفاوت این روش با لیست کردن خواسته ها در یک فایل متنی این است که تست خودش اثبات می کند کار می کند یا نه. هر ردیف معیار پذیرش، یک تست دارد؛ در گزارش تست پذیرش هر ردیف سبز یا قرمز می شود و تحویل نسخهٔ نهایی به سبز شدن همان ردیف ها گره خورده است.

زیرساخت فنی و کدی که تحویل می گیرید

این بخش برای کسی نوشته شده که می خواهد بداند پشت پرده چه خبر است؛ اگر فنی نیستید می توانید از این بخش بگذرید و سراغ بخش تحویل بروید. سامانه ها با لاراول و MySQL ساخته می شوند و رابط کاربری با Vue و Inertia. کار از ساخت مدل و جدول شروع می شود:

php artisan make:model Invoice -m
php artisan make:model Customer -m
php artisan make:job SendInvoice

هر جدول با مایگریشن ساخته می شود، یعنی ساختار دیتابیس هم مثل کد نسخه بندی شده است و روی هر سروری با یک دستور دوباره ساخته می شود:

public function up(): void
{
    Schema::create('invoices', function (Blueprint $table) {
        $table->id();
        $table->foreignId('customer_id')->constrained()->cascadeOnDelete();
        $table->unsignedBigInteger('total_rial');
        $table->string('status')->default('draft');
        $table->timestamp('issued_at')->nullable();
        $table->timestamps();
    });
}

class Invoice extends Model
{
    protected $fillable = ['customer_id', 'total_rial', 'status', 'issued_at'];

    protected $casts = ['issued_at' => 'datetime'];

    public function customer(): BelongsTo
    {
        return $this->belongsTo(Customer::class);
    }
}

مسیرهای API با توکن محافظت می شوند، تا هر درخواست روی دادهٔ درست بنشیند. این همان لایه ای است که در گزارش تست پذیرش با تست های امنیتی هم بررسی می شود:

Route::middleware('auth:sanctum')->group(function () {
    Route::get('/invoices', [InvoiceController::class, 'index']);
    Route::get('/invoices/{invoice}', [InvoiceController::class, 'show']);
    Route::post('/invoices', [InvoiceController::class, 'store']);
});

کارهای سنگین در پس زمینه اجرا می شوند تا کاربر پشت صفحه منتظر نماند؛ فرستادن فاکتور، ارسال پیامک و ساخت گزارش های بزرگ از صف رد می شوند:

class SendInvoice implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    public function __construct(public Invoice $invoice) {}

    public function handle(): void
    {
        $this->invoice->customer->notify(new InvoiceIssued($this->invoice));
    }
}

$invoices = Invoice::query()
    ->selectRaw('customer_id, COUNT(*) as count, SUM(total_rial) as sum_rial')
    ->whereBetween('issued_at', [$from, $to])
    ->groupBy('customer_id')
    ->orderByDesc('sum_rial')
    ->paginate(20);

حاصل این ساختار سه چیز است: ساختار دیتابیس قابل بازسازی، دسترسی ها کنترل شده، و گزارش ها با یک کوئری خوانده می شوند نه با شمارش دستی. هر سه مورد در تحویل، بخشی از همان سورس کدی هستند که به شما داده می شود.

تست خودکار و CI: پیش از هر تحویل چه چیزی کنترل می شود

در سنجش ۱۵ صفحهٔ رقیب، هیچ صفحه ای از تست خودکار حرفی نزده بود. تفاوت عملی اش این است که بدون تست، هر تغییر کوچک می تواند سامانه را بشکند و کسی هم متوجه نشود تا وقتی کاربر گزارش بدهد. برای همین در این پروژه ها یک خط لولهٔ ساده هست که با هر تغییر اجرا می شود:

name: tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: shivammathur/setup-php@v2
        with:
          php-version: '8.3'
      - run: composer install --no-interaction
      - run: cp .env.example .env && php artisan key:generate
      - run: php artisan test

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

تحویل پروژه شامل چه چیزهایی است

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

اگر لازم بود بخشی از ستون سمت راست هم انجام شود، جداگانه بررسی و قیمت گذاری می شود؛ سکوت دربارهٔ آن ها به این معنا نیست که در پروژه آمده اند.

نمونه کارهای زندهٔ ما

در سنجش همان ۱۵ صفحه، تنها ۵ صفحه لینکی به کار واقعی مشتری داشتند. معیار تأییدپذیری در شیراز همین است: لینک به چیزی که هست و می توانید خودتان بازش کنید. چهار سامانه و سایت زیر را ما ساخته ایم و همین حالا زنده هستند:

• سامانهٔ مشاوره و انتخاب رشتهٔ صدیق — sedigh.org: پنل دانش آموز، پنل مدیریت و وبلاگ دسته بندی شده برای راهنمای انتخاب رشته و معرفی رشته های دانشگاهی
• درمانگاه دندانپزشکی حکمت — hekmatdental.com: معرفی خدمات و تیم، رزرو نوبت آنلاین، گالری و بخش خیریه با پیگیری درخواست
• فروشگاه کتاب یکی یه دونه — yekiyedoneh.com: فروشگاه اینترنتی کتاب با سبد خرید و دسته بندی موضوعی
• فروشگاه پوشاک پردیس مزون — mezonpardis.ir: فروشگاه اینترنتی پوشاک با سبد خرید، پیگیری سفارش و مجله مد

فهرست کوتاه چهار پروژهٔ دیگر و مشخصات شان را در بخش نمونه کارهای ما در صفحهٔ اصلی ببینید. اگر خواستید، در جلسهٔ اول همین چهار مورد را باز می کنیم و می گوییم هر کدام چه چیزی دارد و چه چیزی ندارد.

چه چیزی نمی سازیم (خارج از محدوده)

همان مرزی که در جدول تحویل آمد، اینجا صریح تر می گوییم تا وقت شما تلف نشود. این کارها در پروژه های کد یاس انجام نمی شود:

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

نوشتن این فهرست به نفع شماست: پروژه هایی که در محدودهٔ درست تعریف شوند، دیر نمی رسند و بودجه شان از کنترل خارج نمی شود.

جلسهٔ اول چه چیزی لازم دارد

پیش از هر پیشنهاد قیمتی، یک جلسهٔ کوتاه لازم است. اگر جواب این شش پرسش را پیش از جلسه آماده کنید، همان جلسه برای برآورد کافی است و جلسهٔ دوم به بعد برای جزئیات می ماند:

• کاربران و نقش ها: چه کسانی وارد سامانه می شوند و هر کدام چه کاری انجام می دهند؟
• سه جریان اصلی کار: پرتکرارترین کارهایی که هر روز در مجموعه انجام می شود چیست؟
• دادهٔ امروز کجاست: اطلاعات فعلی در اکسل، دفتر یا ابزار دیگری است؟
• اتصال های لازم: به کدام سرویس ها باید وصل شود؛ هر کدام مستندات API دارند؟
• معیار قبولی نسخهٔ اول: نسخهٔ اول باید کدام کار را انجام بدهد تا به کار شما بیاید؟
• محدودیت ها: محدودیت امنیتی، قراردادی یا زمانی خاصی وجود دارد؟

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