ویونیکس / مهندسی نرم‌افزار
توسعهٔ نرم‌افزار برای نیازهای سازمان شما
طراحی و توسعهٔ اپلیکیشن وب، API و اتصال سامانه‌ها؛ یا اصلاح نرم‌افزار موجود، با در نظر گرفتن تست، انتشار و نیازهای نگه‌داری.
تعیین نیاز و محدودهٔ نرم‌افزار
نیاز کاربر و فرایند کاری را مشخص کنید
ابتدا مشخص می‌کنیم کاربر چه کاری باید انجام دهد، نرم‌افزار فعلی کجا مشکل ایجاد می‌کند و به چه داده‌ها یا سرویس‌هایی وابسته است. بر این اساس، محدودهٔ برنامه و رفتار قابل بررسی آن تعیین می‌شود؛ فناوری بعد از شناخت نیاز و محدودیت‌های تیم انتخاب می‌شود.
ساخت نرم‌افزار جدید
گردش کار، نقش کاربران، حالت‌های رابط کاربری و مدل اصلی داده پیش از توسعهٔ فرانت‌اند و بک‌اند مشخص می‌شوند. سناریوهای مهم پذیرش نیز از ابتدا در محدودهٔ کار قرار می‌گیرند.
اصلاح نرم‌افزار موجود یا اتصال سامانه‌ها
معماری، وابستگی‌ها، تست‌ها و روش استقرار بررسی می‌شوند. اگر لازم باشد بخش‌های منتخب بازآرایی یا جایگزین می‌شوند؛ با توجه به حفظ رفتارهای ضروری و قراردادهای ارتباطی که سامانه‌های دیگر به آن‌ها وابسته‌اند.
نمونهٔ ارتباط بخش‌های یک اپلیکیشن
ثبت یک درخواست فقط به فرم صفحه محدود نیست
رابط کاربری
ورود اطلاعات، اعتبارسنجی، انتظار و خطا باید برای کاربر روشن باشند. دسترسی با صفحه‌کلید و بازخورد قابل فهم در طراحی در نظر گرفته می‌شوند.
برنامه و API
ساختار ورودی و پاسخ، کنترل دسترسی، قواعد کسب‌وکار و روش رسیدگی به خطاها مشخص و پیاده‌سازی می‌شوند.
داده و سرویس‌های وابسته
تغییرات داده و فراخوانی سرویس‌های دیگر باید قابل پیگیری باشند. روش تلاش مجدد، درخواست تکراری و قطع سرویس وابسته از قبل تعیین می‌شود.
این بخش فقط یک نمونه است. معماری و تست‌ها برای برنامهٔ واقعی انتخاب می‌شوند و الگوی ثابت برای همهٔ پروژه‌ها نیستند.
کیفیت با تغییرات قابل بازبینی حفظ می‌شود
تغییرات کد باید قابل فهم و بازبینی باشند. وابستگی‌ها بررسی و برای رفتارهای تغییرکرده تست مناسب اضافه می‌شود. تست واحد، تست اتصال اجزا و بررسی مسیر کاربر هدف‌های متفاوتی دارند؛ ترکیب آن‌ها با توجه به ریسک و محدودهٔ پروژه انتخاب می‌شود.
نوسازی با توجه به بخش‌های قابل استفاده
نرم‌افزار قدیمی همیشه به بازنویسی کامل نیاز ندارد. بخش‌های مشکل‌ساز در نگه‌داری یا انتشار شناسایی می‌شوند، محدودیت‌های سازگاری مشخص می‌شوند و یک محدودهٔ قابل کنترل با بررسی رفتارهای ضروری تغییر می‌کند.
از کد تا سرویس قابل نگه‌داری
انتشار نرم‌افزار و رسیدگی به خطاها را روشن کنید
خودکارسازی انتشار و مدیریت محیط‌ها
فرایند CI/CD بر اساس برنامه طراحی می‌شود: ساخت قابل تکرار، بررسی‌های مرتبط، تنظیمات کنترل‌شده و روش مشخص استقرار و بازگشت. محیط‌ها و اطلاعات محرمانه به‌درستی جدا می‌شوند. خودکارسازی باید به بازبینی و بازیابی کمک کند، نه این‌که تغییرات را پنهان کند.
لاگ، سلامت سرویس و مسئول پیگیری
رسیدگی مناسب به خطا، شاخص‌های سلامت و منابع اجرایی در نظر گرفته می‌شوند. مشخص می‌کنیم چه اطلاعاتی بدون افشای دادهٔ خصوصی یا اسرار در لاگ ثبت شود، مسئول پیگیری خرابی چه کسی باشد و تیم چگونه مشکل را بازتولید یا عیب‌یابی کند.
محدوده، پذیرش و تحویل
پیش از پیاده‌سازی، خروجی‌ها، معیار بررسی و مسئولیت‌ها مشخص می‌شوند. در تحویل، کد و منابع استقرار باید همراه با راهنمای قابل استفاده در اختیار تیم نگه‌داری قرار بگیرند.
آیا می‌توان نرم‌افزار موجود را اصلاح کرد؟
می‌توان روی مشکلات مشخص معماری، اتصال سرویس‌ها، تست یا انتشار کار کرد. ابتدا اطلاعات کافی و دسترسی مجاز برای بررسی کد، وابستگی‌ها و استقرار لازم است. محدودهٔ قابل اجرا پس از این بررسی تعیین می‌شود.
نتیجهٔ کار چگونه بررسی می‌شود؟
سناریوهای کاربردی توافق‌شده، تست‌های مرتبط و بررسی استقرار مبنای ارزیابی هستند. محدودیت‌ها و موارد باز نیز ثبت می‌شوند. موفق‌بودن ساخت برنامه به‌تنهایی عملکرد مسیر کاربر یا اتصال به سرویس خارجی را ثابت نمی‌کند.
پشتیبانی پس از تحویل چگونه تعیین می‌شود؟
نگه‌داری و پشتیبانی مستمر به محدودهٔ سرویس، مسئولیت‌ها و پوشش توافق‌شده نیاز دارد. این موارد با معرفی خدمات توسعه به‌صورت خودکار تعهد نمی‌شوند و باید همراه با شرایط تحویل و مسئولیت انتشار مشخص شوند.
برای شروع، شرح کلی فرایند، نرم‌افزار موجود و تغییر مورد نظر را آماده کنید. اطلاعات محرمانهٔ کد، دسترسی‌ها و دادهٔ خصوصی را در فرم عمومی تماس ننویسید.