روشهای طراحی وب اپلیکیشن اختصاصی و نرم افزار تحت وب
انتخاب روش اجرا برای طراحی وب اپلیکیشن اختصاصی و نرم افزار تحت وب زمانی قابل دفاع است که گزینهها با نیاز واقعی پروژه مقایسه شوند؛ نه فقط با نام فناوری. معیارهایی مثل ورود امن، انجام Workflow اصلی، مشاهده وضعیت و تکمیل اقدام، رکوردهای عملیاتی، نقشها، وضعیتها، تاریخچه و گزارشها و نحوه نگهداری آینده باید در یک ماتریس مشترک سنجیده شوند.
روش اجرای طراحی وب اپلیکیشن اختصاصی و نرم افزار تحت وب زمانی درست انتخاب میشود که با شیوه استفاده واقعی کاربر عملیاتی سامانه هماهنگ باشد. گزینه مناسب باید مسیر کاربر از ورود تا تکمیل Workflow اصلی را بدون میانبُرهای دائمی پوشش دهد و در عین حال مدیریت رکوردهای عملیاتی، نقشها، وضعیتها، تاریخچه و گزارشها و فرایندهای احراز هویت، Permission، Workflow، API، Notification و گزارشگیری را برای تیم داخلی قابل نگهداری نگه دارد.
برای بررسی تخصصیتر این موضوع، صفحه طراحی اپلیکیشن جزئیات مرتبط با این نیاز را بهصورت متمرکز پوشش میدهد.
سه مسیر رایج برای اجرای طراحی وب اپلیکیشن اختصاصی و نرم افزار تحت وب
در بسیاری از پروژهها انتخاب بین راهکار آماده، CMS توسعهپذیر و توسعه اختصاصی مطرح میشود. هیچکدام ذاتاً بهتر نیستند؛ گزینه مناسب باید کمترین Workaround را برای نیازهای اصلی ایجاد کند.
راهکار آماده یا SaaS
برای Scope استاندارد میتواند سریعتر باشد، اما باید محدودیت شخصیسازی، Export داده، هزینه دورهای و وابستگی به سرویسدهنده بررسی شود. اگر فرایند انجام اقدام و مشاهده وضعیت به Flow خاصی نیاز دارد، مطمئن شوید راهکار آماده آن را بدون دور زدن محدودیت پوشش میدهد.
CMS یا پلتفرم توسعهپذیر
وقتی بخش بزرگی از نیاز استاندارد است ولی کنترل بیشتری روی محتوا و توسعه لازم دارید، CMS میتواند تعادل مناسبی ایجاد کند. کیفیت معماری افزونهها، امنیت، بهروزرسانی و مدیریت رکوردهای عملیاتی، نقشها، وضعیتها، تاریخچه و گزارشها در این مدل مهم است.
توسعه اختصاصی
برای Workflow، مدل داده یا تجربهای که با ابزار آماده همراستا نیست، توسعه اختصاصی انعطاف بیشتری میدهد؛ اما تست، مستندسازی و نگهداری باید جدیتر تعریف شوند. اختصاصی بودن زمانی ارزش دارد که مسئله واقعی آن را توجیه کند.
معیارهای مقایسه را یکسان نگه دارید
| معیار | سؤال تصمیم |
|---|---|
| تناسب با کاربر | آیا چرخه استفاده از سامانه تا تکمیل عملیات بدون Workaround اجرا میشود؟ |
| داده | رکوردهای عملیاتی، نقشها، وضعیتها، تاریخچه و گزارشها چگونه مدیریت، Export و بهروزرسانی میشود؟ |
| Integration | API، احراز هویت و محدودیت سرویسها روشن است؟ |
| رشد | نسخه بعدی بدون بازنویسی کامل قابل توسعه است؟ |
| مالکیت | Source، داده و دسترسیها در پایان پروژه چه وضعیتی دارند؟ |
چه زمانی روش اجرا را عوض کنیم؟
اگر گزینه انتخابی نیازمند مجموعهای از Workaroundهای دائمی است، داده را قفل میکند یا برای قابلیت اصلی پروژه به توسعه شکننده وابسته است، بهتر است قبل از شروع توسعه مسیر دیگری بررسی شود. هزینه تغییر معماری در مرحله تصمیم کمتر از تغییر بعد از ورود داده و کاربر واقعی است.
قبل از انتخاب نهایی یک Proof کوچک بسازید
برای نقاط پرریسک لازم نیست کل پروژه را بسازید. یک نمونه محدود از Flow اصلی، ساختار داده یا اتصال مهم میتواند نشان دهد گزینه انتخابی با واقعیت پروژه سازگار است یا نه. اگر احراز هویت، Permission، Workflow، API، Notification و گزارشگیری به چند سیستم یا نقش وابسته است، Proof باید همان بخش پرریسک را آزمایش کند، نه یک صفحه نمایشی ساده را.
نتیجه Proof را مستند کنید: چه چیزی بدون تغییر کار کرد، کجا محدودیت دیده شد، چه فرضی هنوز باز است و چه تصمیمی باید قبل از توسعه اصلی گرفته شود. این مستند کمک میکند انتخاب فناوری از سلیقه تیم جدا شود و به شواهد پروژه تکیه کند.
در قرارداد یا Scope چه چیزهایی درباره روش اجرا روشن باشد؟
مالکیت Source و داده، دسترسی به Repository و حسابها، مسئولیت سرویسهای ثالث، محدوده Updateها، نحوه تحویل مستندات و شرایط مهاجرت آینده را روشن کنید. یک معماری مناسب فقط در روز Launch خوب نیست؛ باید در نگهداری، توسعه نسخه بعد و تغییر تیم فنی نیز قابل مدیریت بماند.
جمعبندی
روش اجرای طراحی وب اپلیکیشن اختصاصی و نرم افزار تحت وب باید نتیجه تحلیل Scope باشد. اگر بین چند گزینه مردد هستید، ابتدا نیازهای غیرقابل مذاکره را از موارد مطلوب جدا کنید و سپس هزینه مالکیت، ریسک و توسعه آینده را مقایسه کنید. برای تعریف Scope اصلی میتوانید به طراحی وب اپلیکیشن اختصاصی و نرم افزار تحت وب برگردید.