چرخه عمر توسعه نرم افزار در اودو

قبل از اینکه جلوتر بریم توصیه میکنم اگه یادداشت قبلی رو نخوندی یه نگاه بهش بندازی تا متوجه بشی توی یه پروژه دقیقا کی چی کاره ست؟

چرخه عمر توسعه نرم افزار (Software Development Life Cycle | SDLC​) یعنی مسیر کامل یه تغییر یا قابلیت؛ از وقتی که فقط یه نیاز خام هست، تا وقتی که وارد محیط واقعی میشه و بعدا نگهداری میشه.

توی اودو این موضوع یه مقدار حساس تره، چون معمولا با یه سیستم آماده طرفیم. یعنی قرار نیست برای هر نیاز سریع بریم سمت کدنویسی. اول باید بفهمیم خود اودو با قابلیت استاندارد (Standard Feature​)، پیکربندی (Configuration​) یا ماژول آماده میتونه جواب بده یا نه.

نقش تحلیلگر سیستم (System Analyst | SA​) اینه که نیاز مبهم کسب و کار رو تبدیل کنه به چیزی که تیم فنی بتونه درست بسازه و تیم تست بتونه درست بررسی کنه.

فاز ۱. برنامه ریزی و تحلیل نیازمندی ها؛ اول بفهم، بعد طراحی کن

برنامه ریزی و تحلیل نیازمندی ها (Planning & Requirements Analysis​) یعنی دقیق بفهمیم چی میخوان، چرا میخوان و روی کجای سیستم اثر میذاره.

مثلا مدیر فروش میگه:

وقتی سفارش فروش تایید شد، برای تیم مالی یک فعالیت ساخته بشه.

اینجا تحلیلگر نباید سریع بگه «اوکی، توسعه میدیم». باید سوال های درست بپرسه:

• این فعالیت برای همه سفارش ها ساخته میشه یا فقط سفارش های اعتباری؟
• مسئول فعالیت کیه؟
• تاریخ سررسید چطور تعیین میشه؟
• اگه مشتری بدهی معوق داشت چی؟
• این کار با فعالیت خودکار (Automated Action​) حل میشه یا توسعه سفارشی (Custom Development​) میخواد؟
  

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

نکته اصلی اینه: اگه تحلیلگر نیاز رو دقیق نفهمه، هم مستندات غلط میشه، هم توسعه، هم تست.

فاز ۲. طراحی سیستم؛ ساختار داده و منطق سیستم

در طراحی سیستم (System Design​)، تحلیلگر کمک می کنه مشخص بشه داده ها کجا ذخیره میشن و سیستم طبق چه قوانینی رفتار می کنه.

ساختار داده (Data Structure​) یعنی چه اطلاعاتی لازم داریم. توی اودو این یعنی مدل ها (Models​) و فیلدها (Fields​).

مثلا برای کنترل اعتبار مشتری روی سفارش فروش، باید ببینیم:

• فیلد جدید روی مدل سفارش فروش (sale.order​) لازمه یا نه؟
• نوع فیلد چیه؟ بولین (Boolean​)، انتخابی (Selection​)، عددی (Float​) یا رابطه ای (Many2one​)؟
• این فیلد باید ذخیره بشه یا محاسباتی باشه؟
• روی گزارش، فاکتور یا فرایند انبار اثر داره یا نه؟

منطق سیستم (System Logic​) یعنی قانون رفتار سیستم. مثلا:

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

نکته مهم: توی اودو هر فیلد یا قانون جدید میتونه روی چند ماژول اثر بذاره. پس ساده طراحی کن، ولی سطحی نه.

فاز ۳. پیاده سازی و کدنویسی؛ تحلیلگر کد نمی زنه، ولی کنار تیم می مونه

در فاز پیاده سازی و کدنویسی (Implementation & Coding​)، توسعه دهنده ها طبق طراحی شروع به ساختن تغییرات می کنن. نقش تحلیلگر سیستم اینجا تموم نمیشه.

تحلیلگر باید کنار تیم فنی بمونه تا ابهام ها سریع حل بشن. مثلا توسعه دهنده می پرسه:

اگه مشتری هم بدهی معوق داشت، هم سفارش نقدی ثبت کرد، باز هم سفارش باید متوقف بشه؟

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

توی اودو مخصوصا باید حواس جمع باشه که توسعه روی محیط تست (Staging/Test Environment​) انجام بشه، نه مستقیم روی محیط عملیاتی (Production​).

فاز ۴. تست؛ فقط اینکه صفحه باز میشه کافی نیست

فاز تست (Testing​) یعنی مطمئن بشیم چیزی که ساخته شده، با نیازمندی اولیه همخوانه و چیزی رو خراب نکرده.

در اودو تست باید فقط محدود به یه فرم یا یه دکمه نباشه. چون فرایندها به هم وصلن.

مثلا اگه تغییر اساسی روی سفارش فروش دادیم، باید این مسیرها هم بررسی بشن:

• ایجاد پیش فاکتور یا سفارش فروش
• تایید سفارش
• رزرو موجودی
• تحویل کالا
• صدور فاکتور
• ثبت پرداخت
• اثر روی گزارش فروش و حسابداری

معیار پذیرش (Acceptance Criteria​) اینجا خیلی کمک می کنه. تحلیلگر باید چک کنه خروجی با چیزی که مستند شده یکی هست یا نه.

اشتباه پرتکرار اینه که فقط سناریوی خوشحال (Happy Path​) تست میشه؛ یعنی حالتی که همه چیز درست و عادی پیش میره. ولی حالت های خطا، قطع شدن فرایند، دسترسی نداشتن کاربر، کمبود موجودی یا خطای پرداخت هم باید دیده بشن.

فاز ۵ و ۶. استقرار و نگهداری؛ کار بعد از تحویل تازه شروع میشه

فاز ۵ استقرار (Deployment​) هست. یعنی تغییرات وارد محیط واقعی و عملیاتی (Production​) میشن و کاربر نهایی ازش استفاده می کنه.

ولی بعد از استقرار، فاز 6 که نگهداری و پشتیبانی (Maintenance & Support​) هست شروع میشه. اینجا بازخورد کاربر، خطاهای واقعی، نیازهای جدید و بهبودها وارد چرخه میشن.

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

بعد چرخه دوباره برمی گرده به تحلیل:

• مشکل دقیقا کجاست؟
• پرداخت در درگاه موفق بوده یا نه؟
• پاسخ درگاه به اودو رسیده یا نه؟
• تراکنش در مدل پرداخت (Payment Transaction​) ثبت شده؟
• فاکتور به درستی به پرداخت وصل شده؟
• اگه اینترنت کاربر قطع شد، سیستم باید چه رفتاری داشته باشه؟

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

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

خلاصه اینکه چرخه عمر توسعه نرم افزار (SDLC​) یعنی از نیاز خام برسیم به راه حل قابل اجرا، قابل تست و قابل نگهداری. تحلیلگر سیستم باید نیاز رو شفاف کنه، امکان سنجی کنه، ساختار داده و منطق سیستم رو درست طراحی کنه، کنار تیم توسعه بمونه، خروجی رو با معیار پذیرش تست کنه و بعد از استقرار هم بازخوردها رو دوباره وارد چرخه تحلیل کنه.

توی اودو تحلیل خوب یعنی کمتر کد زدن، درست تر طراحی کردن و خراب نکردن فرایندهای استاندارد سیستم.