در 4 مقاله گذشته از موضوع بازمهندسی نرم‌افزارهای اتوماسیون اداری در ابتدا به دلایل و چرایی نیاز به بازمهندسی پرداختیم.
سپس چالش‌های نرم‌افزاری بعد از گذشت مدت طولانی از عمر آنها را بررسی و در ادامه چگونگی تدوین نقشه راه برای رفع این مشکلات را بیان کردیم. در این مقاله نیز به فرایند بازمهندسی در حال انجام بر روی نرم‌افزارهای اتوماسیون اداری دیدگاه در نقشه راه بازمهندسی، می‌پردازیم.
مهندسی معکوس
با گذشت 15 سال از عمر یک نرم‌افزار، بسیاری از این عملیات‌ها و در نتیجه آن بسیاری از رفتارهای نرم‌افزاری پیچیده می‌شود. در واقع هر چه از عمر یک نرم‌افزار می‌گذرد، تعاریف و قواعد و قوانین عملیات‌های نرم‌افزاری بیشتر از تعاریف اولیه خود دور می‌شود؛ بنابراین نیاز است که پیش از تغییر عملیات‌های یک ماژول، مجموعه تعاریف و رفتارهای فعلی نرم‌افزار به درستی شناخته و مشخص شود. شناسایی رفتارهاینرم‌افزار از این جهت اهمیت دارند که در فرایند بازمهندسی باید مشخص شود برای هر رفتاری از نرم‌افزار چه اتفاقی می‌افتد. برخی از رفتارها باید باقی بمانند، برخی تغییر رفتار روی آنها اتفاق می‌افتد و برخی رفتارهای منسوخ شده باید از مدار پشتیبانی، خارج شوند. از این رو در فاز مهندسی معکوس نیاز است تا موجودیت‌ها، عملیات‌ها و رفتارهای نرم‌افزاری به صورت دقیقی مشخص شوند. کد منبع، اصلی‌ترین مرجع رفتار هر نرم‌افزارست. این کدها بعد از پردازش خود، نرم‌افزار را تولید می‌کنند. مهندسی معکوس، فرآیند تهیه رفتارها و قابلیت‌های پشتیبانی شده توسط نرم‌افزار از روی کدهای منبع آنست. در این فرایند با خواندن کدهای منبع نرم‌افزار توسط کارشناسان خُبره، ابتدا مجموعه‌ای از مستندات رفتارهای نرم‌افزار در سطوح پایین طراحی به دست می‌آید و سپس با تحلیل آنها قابلیت‌هایی که نرم‌افزار از آنها پشتیبانی می‌کند، مشخص می‌شوند.
بازتعریف
با شروع بازمهندسی یک ماژول مجموعه‌ای از فعالیت‌ها برای بازتعریف آن روی می‌دهد. در حالیکه تیم تولید در حال مهندسی معکوس ماژول است سایر تیم های راهکار، جمع‌آوری اطلاعات درباره نیازمندی‌های جدید بر روی ماژول در حال بازمهندسی را انجام می‌دهند این نیازمندی‌ها شامل موارد زیر می‌شوند:
– به ازای هر ماژول، مجموعه‌ای از قابلیت‌های جدید وجود دارد که پیش از این توسط مشتریان درخواست شده‌اند. این قابلیت‌ها می‌توانند در بازمهندسی نرم‌افزارها بررسی و برای پیاده‌سازی برنامه‌ریزی شوند.
– کمبودهایی توسط مالکان محصول بر روی ماژول تشخیص داده می‌شوند.
– با بررسی و دریافت بازخورد از مشتریان، نیازمندی‌های آنها تشخیص داده می‌شوند.
– با بررسی بر روی فرهنگ رفتاری سازمان‌های مشتری تغییرات بر روی ماژول مورد نظر، شناسایی می‌شوند.
بعد از جمع‌آوری اطلاعات از منابع مختلف این اطلاعات همراه با داده‌های مهندسی معکوس تجمیع و به کمیته بازتعریف ارسال می‌شوند. در این کمیته با بررسی اطلاعات، تعریف جدید از ماژول و قابلیت‌های آن مشخص می شوند. در واقع به صورت تشبیهی می‌توان فاز بازتعریف را به عملیات مغز تشبیه کرد. مهمترین فازی که در آن تغییر رفتارهای سیستم ( به عنوان یکی از اصلی‌ترین اهداف بازمهندسی نرم‌افزارهای اتوماسیون اداری) در آن تعریف می‌شود. بر اساس این تعاریف، قابلیت‌های جدید نیز به ماژول اضافه می‌شود. در این مرحله که آن را به فاز بازتعریف یک ماژول می‌شناسیم ماهیت وجودی یک ماژول به سوال گذاشته و سعی می شود با فرهنگ‌های جدید ایجاد شده در شبکه‌های مجازی (به عنوان پرکاربردترین ابزار در حال استفاده) از نو تعریف شود. پیام‌رسان‌ها در صنعت انتقال اطلاعات پیشرو هستند و معنای پیام همانی شده است که در کانال‌های پیام‌رسان یا در گروه‌های همکاران به اشتراک گذاشته می‌شود. ارجاع زدن همان Mention کردن فرد مخاطب و ارتباط ساده و مستقل دونفر در گروه‌های همکاری شده است. در فاز بازتعریف، تضمین کننده رفتارهای ماژول با فرهنگ جدید است و اصل ساده‌سازی را نیز با خود به ارمغان می‌آورد.
نیازسنجی مجدد
بعد از بازتعریف و دریافت تاییدیه‌های لازم برای اجرایی کردن آن، تیم تولید به سراغ ذینفعان عضو باز تعریف می‌رود و عملیات سریعی از فاز نیاز سنجی را انجام می‌دهد. در این فاز با انجام تکنیک‌های تخصصی نیازسنجی موجودیت‌های جدید، کاربری مربوط به قابلیت آنها هر چه سریعتر بدست می‌آید. در کنار آن، اختلافات قابلیتی بین ماژول پیش از بازتعریف و پس از آن نیز با مقایسه مستندات مهندسی معکوس در کنار تعریف جدید ارائه شده از ماژول) به دست می‌آید تا بر اساس میزان تغییرات برای ادامه عملیات بازمهندسی پیش‌بینی‌های لازم صورت بگیرد. بعد از تولید این مستندات تیم محصول نیاز سنجی را برای بررسی کیفی و تضمین کیفیت نیازسنجی انجام شده در اختیار کارشناسان ارشد راهکار قرار می‌دهد و این افراد با بازنگری، باگ‌ها و اشکالات احتمالی را بیابند و با رفع آنها در زمان باز طراحی مجدد ماژول‌ها خللی وارد نشود.
بازطراحی
بعد از پایان نیازسنجی نوبت به بازطراحی ماژول می‌رسد. نیازهای یافت شده در نیازسنجی در ابتدا تبدیل به داستان‌های کاربری می‌شوند. سپس اولویت بندی شده و بر اساس آن، طراحی می‌شوند. داستان‌های کاربری هر یک به صورت جداگانه در اختیار تیم UX قرار می‌گیرد تا بر اساس مفاهیم تجربه کاربری طراحی صفحات کاربری آن انجام شود و Sketch اولیه از طرح‌ها بدست بیاید. به صورت موازی تیم تست به منظور آشنایی با مفاهیم و تولید موردهای تست، به تیم تولید ملحق می‌شود و اطلاعات لازم را دریافت و به ساخت ایده‌های تست و قابلیت‌ها و کنترل سناریوهای اصلی و فرعی اقدام می‌کند. تیم تولید نیز به طراحی بخش‌های مختلف بر اساس داستان‌های کاربری و Sketch بدست آمده بر مبنای معماری زاگرس اقدام می‌کند.
با توجه به اینکه معماری زاگرس، چابکی و انعطاف‌پذیری خوبی به نرم‌افزارها در محیط طراحی داده است کارشناسان تیم تولید با دستی بازتر و با سرعت بیشتر، پیچیدگی‌های نرم‌افزاری را طراحی می‌کنند. در این طراحی علاوه بر عملیات‌های طراحی معمول (تهیه نمودار کلاس و تهیه نمودار توالی عملیات‌های یک عملیات و …) که به صورت افزایشی بر اساس داستان‌های کاربری صورت می‌گیرد 2 مسئله مهم نیز در طراحی مد نظر قرار می‌گیرند. اول اینکه بر اساس تغییرات یا تعریف مجدد جداول دیتابیسی، داده‌های قبل از بازمهندسی به داده‌هایی که مورد استفاده ماژول بعد از بازمهندسی است، تبدیل می‌شوند و دیگر اینکه نقشه راهی برای تبدیل کد های موجود به کل‌های نهایی بدست می‌آورند.
پیاده‌سازی
کارشناسان تیم تولید بر اساس داستان‌های کاربری تعریف شده و طراحی صورت گرفته به پیاده‌سازی قابلیت‌های مختلف اقدام می‌کنند. آنها برای هر قابلیت ابتدا کدهای قبلی را از بین برده یا ریفکتور می‌کنند و سپس کدهای جدید را بر اساس معماری زاگرس پیاده سازی می‌کنند. در نهایت بر اساس سناریوهای اصلی و فرعی، مجموعه ای از تست‌های واحد تولید می‌شود تا کیفیت کد تولید شده تضمین شود. بعد از پیاده‌سازی داستان کاربری کدهای نوشته شده به صورت کامل در اختیار کارشناسان فنی قرار می‌گیرد تا بازنگری شوند. آنها سعی می‌کنند تا جای ممکن با خواندن کد، باگ‌ها و رفتارهای اشتباه مربوط به پیاده‌سازی داستان را تشخیص واطلاع دهند. در زمانی که کد به اندازه کافی به اصطلاح تمیز شد مجوز لازم برای قرارگرفتن کد در روند تولید نسخه را صادر می‌کنند و کد به عنوان بخشی از نرم‌افزار در نسخه دیدگاه قرار می‌گیرد.
تست
بعد از این مراحل، نوبت به تست جامع داستان کاربری پیاده‌سازی شده، می رسد. کارشناسان تست که در زمان بازطراحی ماژول شروع به تولید موردهای تست کرده بودند اکنون می‌توانند تست‌های جامع خود را برای تمامی سناریوهای اصلی و فرعی داستان کاربری اجرا کنند. این افراد شروع به تست داستان کاربری می‌کنند و باگ‌های یافت شده را به تیم تولید اعلام می‌کند. این باگ‌ها در انباره باگ‌های تیم تولید قرار می‌گیرد و در تکرارهای متوالی پیش از تحویل داستان کاربری به مشتریان، توسط تیم تولید رفع می‌شوند. در انتهای این فاز، داستان‌های کاربری‌ای بر روی نرم‌افزار بوجود می‌آیند که آماده تحویل به مشتری هستند و تا حد ممکن خطاهای آن تشخیص و رفع شده‌اند.
استقرار و دریافت بازخورد
وقتی قابلیت‌ها با باز مهندسی انجام شده به مرور در اختیار مشتریان قرار می‌گیرند به این معنی است که فاز بازمهندسی برای ماژول تحویل داده شده به پایان رسیده و فاز توسعه و نگهداشت آن آغاز شده است. در زمان استقرار قابلیت‌های جدید به مشتری آموز‌ش‌های لازم برای بهره‌برداری حداکثری از قابلیت‌های جدید و تولید ارزش افزوده‌های بیشتر داده می‌شود و پس از گذشت مدتی بازخوردهای لازم از مشتری دریافت می‌شوند. این بازخوردها برای توسعه ماژول جدید و رفع اشکالات و نواقص آن ضروریست. به این ترتیب با این توالی از فازهای بازمهندسی ماژول‌های نرم‌افزارهای مختلف بازمهندسی می‌شود تا نرم‌افزارهای اتوماسیون اداری دیدگاه همچون گذشته در مفاهیم، قابلیت‌ها و به روز بودن با فرهنگ‌های جدید، پیشرو باشند. تاکنون ما توانسته‌ایم این فرایند را برای ماژول‌های اعلامیه، اندیکاتور و پیام از مجموعه ماژول‌های نرم‌افزار مکاتبات آغاز کنیم که در این رابطه، ماژول اعلامیه بعد از بازمهندسی تبدیل به تابلوی اعلانات شد که در سمینار سالانه چارگون در سال 96 رونمایی شد. امیدواریم با تحویل مرحله به مرحله ماژول‌های بازمهندسی شده به مشتریان علاوه بر افزایش بهره‌وری در فرآیندهای کاری مشتریان لذت استفاده از فرهنگ‌های جدید خلق شده طی این سال‌ها را بیش از پیش به کاربران بزرگ دیدگاه، بچشانیم.
قسمت آخر