مقاله پژوهشی: تکنیک های مهندسی مجدد و روش های آن

مقاله پژوهشی: تکنیک مهندسی مجدد و روش های آن
مترجم: مصطفی محمدخانی طبسی و احمد قنبری دستک

چکیده:

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

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

 2. چکیده 

مهندسی مجدد و الگوهای مهندسی مجدد از مفاهیم نسبتا جدیدی است که در ابتدا برای تاثیر گذاشتن بر جامعه ی مهندسی نرم افزار شروع شد. با تغییر منابع با هدف تجدید سازمان از سیستم های قدیمی به سوی تمرکز بر پیشرفت نرم افزار جدید، تجارت قادر خواهد بود زمان و منابع با ارزش زیادی را ذخیره نماید. اگرچه مزایای این رویکرد به وضوح دیده می شود اما برخی مشکلات از جمله بی تجربگی و کمبود ابزار مناسب، مهندسی مجدد سیستم را کمی مشکل می کند.
سیستم های قدیمی، سیستم های نرم افزاری هستند که برای پشتیبانی از فرآیند تجارت ضروری می باشند و به دلیل اینکه همین سیستم ها باید در عملیات نگه داشته شوند، شرکت ها به آن ها تکیه می کنند. استراتژی های تکامل نرم افزار شامل نگهداری، جایگزینی، تکامل معماری آن و مهندسی مجدد برنامه می باشد.
مهندسی مجدد برنامه، دوباره اجرا کردن سیستم های قدیمی برای افزایش قابلیت نگهداری است. مهندسی مجدد به صورت مستندسازی مجدد سیستم، سازماندهی، ساختارمند کردن مجدد سیستم، ترجمه ی سیستم به زبان برنامه نویسی مدرن، اصلاح کردن و به روز کردن ساختار است. از دیدگاه فنی، مهندسی مجدد برنامه ها، ممکن است به صورت راه حل درجه دوم برای تکمیل مسائل سیستم به کار رود و امکان آن وجود ندارد که از بنیان، زبان برنامه نویسی سیستم را تغییر داد. بنابراین سیستم های قدیمی مانند Java یا C++ را نمی توان برنامه نویسی مجدد کرد. زیرا عاملیت نرم افزار تغییر ناپذیر است و محدودیت ذاتی در سیستم نگهداری می شود.

 

3. تاریخچه ی مفاهیم مهندسی مجدد
در اوایل سال های انقلاب اطلاعاتی از طرف جوامع نیازی به مهندسی مجدد بیان نشده بود. در عوض، توجه جوامع به سوی کشف راه های جدید برای ساختن نرم افزارها و سخت افزارهای جدید بود. نکته ی حائز اهمیت این بود که جوامع چگونه پیشرفت سیستم جدید را که با سرعت فزاینده آشکار می شد و انتشار پیدا می کرد، اداره می کردند. تقریبا به سیستم های قدیمی که کم کم منسوخ می شدند هیچ توجهی نمی شد. به علاوه تجارت ها به سرعت در حال تغییر بودند و همراه با این تغییرات به نرم افزارهای اطلاعاتی مناسب نیاز شد که این دوران به عنوان ” کمبود نرم افزار” شناخته می شد. زیرا نرم افزارها در حال ارتقا بودند ولی برای رفع نیازهای تجارت کافی نبود.
در اوایل دهه ی 90، تمرکز به سرعت از پیشرفت نرم افزار جدید به مهندسی مجدد سیستم های قدیمی تغییر یافت ( سیستم ها به مدت زیادی برای نگهداری و تعمیرات رشد کردند ). در حقیقت در این زمان توجه زیادی به مهندسی مجدد شد و برحسب روش شناسی مهندسی مجدد پیشرفته و الگوهای آن، تجارت یکپارچه و ساختارهای آن، به رسمیت شناخته شد. مهندسی مجدد کلمه ی روز بود و مشاور مهندسی مجدد، به یک رشته تبدیل شد [ BPR 99 ].
اما اعتقادی که مشاوران به مهندسی مجدد تجارت و نرم افزارهایش داشتند، به این آسانی هم نبود. بالغ بر نیمی از فرآیند مهندسی مجدد در آن زمان منجر به شکست شد. خیلی از آن ها به خاطر عدم تجربه و فقدان مشارکت خریدار و مشتری بود. این شکست ها هزینه های سنگینی به شرکت ها تحمیل کرد و پیشرفت سریع مهندسی مجدد را با وجود علاقه به توسعه ی مهندسی مجدد به پایان رسانید [ BPR 99 ].
هنوز حدود 80 درصد هزینه های بودجه ی سیستم اطلاعاتی تجارت مربوط به نگهداری سیستم های قدیمی می شود. به این معنی که فقط 20 درصد کل هزینه، مربوط به توسعه ی سیستم جدید است. این نشان می دهد که مهندسی مجدد، سازماندهی مجدد و طراحی مجدد سیستم ( یا تجارت ) بسیار مهم است. اگر این هزینه ها کم شود سود زیادی برای کاربران نرم افزار به دست خواهد آمد. این حقیقت به بازگشت به جامعه ی فعال تحقیق مهندسی مجدد کمک می کند و همان طور که وارد قرن بیست و یکم می شویم، مشاهده می کنیم که مهندسی مجدد دوباره در حال پیشروی به سمت مهندسی نرم افزار است.
به هر حال از نقطه نظر تجارت، مهندسی مجدد نرم افزار ممکن است تنها روش برای ابقای سیستم های قدیمی باشد تا این سیستم ها بتوانند به وظایفشان عمل کنند. بنابراین ممکن است این رویکرد برای تطبیق با رویکردهای دیگر سیستم بسیار گران و مخاطره آمیز باشد.

برای فهم بیشتر این موضوع، باید تخمین تقریبی از مسئله سیستم قدیمی بزنیم:
مقدار کد در سیستم های قدیمی بی اندازه است. در سال 1990 حدود 120 بیلیون سطر از کد مبدا در جهان وجود داشت [ Ulrich,1990 ]. اهداف این سیستم ها در COBOL که یک زبان برنامه نویسی خوب برای پردازش داده های تجارت می باشد، نوشته شده است. همین طور FORTRAN که زبانی برای برنامه نویسی علمی یا ریاضی است. اگرچه خیلی از این برنامه ها جایگزین شده اند اما بیشتر این برنامه ها هنوز در وظیفه ی خود باقی هستند. در ضمن پس از سال 1990 افزایش چشمگیری در استفاده از کامپیوتر برای فرآیند تجارت مشاهده شده است.
نگهداری از سیستم های قدیمی پرهزینه است. بنابراین مهندسی مجدد این سیستم ها عمر مفید آن ها را افزایش می دهد. مهندسی مجدد، ساختار سیستم را بهبود می بخشد، سیستم جدید را مستند و فهم آن را آسان می کند.

4. مقدمه ی کوتاهی درباره ی مهندسی مجدد
مهندسی مجدد، آزمون مدل و کاربرد سیستم قدیمی موجود را به یکدیگر ربط می دهد و تکنیک های مختلفی را برای طراحی مجدد سیستم به کار می گیرد. هدف از این کار، استفاده ی مناسب و بهتر از قبل نرم افزار است. البته این کار، فرآیند آسانی نیست زیرا به روز کردن و اضافه کردن عامل جدید ممکن است باعث عدم صحت و درستی و همین طور به روزآوری مستندات سیستم شود. به خصوص اگر سیستم به مردم تفویض نشود، مهارتی در راه تفکر مهندسی مجدد به وجود نمی آید که در نهایت سیستم توانایی ترمیم سریع و کارآیی خود را در صورت بروز خرابی از دست می دهد.
کارگروه مهندسی مجدد باید توانایی دیدن جنگل انبوه را داشته باشد تا بتواند سیستم را توصیف کند. تصمیم، باید با دقت هر چه تمام تر گرفته شود. زیرا فرآیند مهندسی مجدد در مورد نگهداری آخرین کاربرها و مصرف کنندگان موجود، نیازمندی های آینده و حالت گذار از سیستم قدیمی به سیستم جدید صحبت می کند. اگر سیستم یکپارچه دوباره طراحی شود، دیگر نیازی به فرآیند مهندسی مجدد نخواهد بود. ولی فرآیند ضعیف نرم افزاری مهندسی مجدد همراه با تولیدات نهایی به آموزش مصرف کنندگان از دست رفته نیاز دارد.
تلاش در جنبه های بنیادی مهندسی مجدد مانند نگهداری، مشتری مداری، کارکردی کردن و دیگر نیازمندی ها هر اندازه هم که کوچک باشد سودمند است. این موضوع الگوی مهمی را در مهندسی مجدد بیان می کند: ” تغییر، اما به مقدار اندک ممکن “.

 

مهندسی مجدد سیستم نرم افزاری برای تکامل سیستم دو مزیت کلیدی نسبت به رویکردهای اصلی دیگر دارد:
1- ریسک کم: در توسعه ی مجدد ریسک زیادی نهفته است که برای یک سازمان ضروری است. خطاها ممکن است در تشخیص سیستم، مسائل توسعه یافته و … روی دهد.

2- هزینه ی کاهش یافته: هزینه ی مهندسی مجدد نشان از کم بودن نسبت به هزینه ی توسعه ی سیستم جدید است. اولریچ [ Ulrich,1990 ] مثالی از سیستم تجاری که برای اجرای آن 50 میلیون دلار هزینه شد نقل می کند. این سیستم با 12 میلیون دلار مهندسی مجدد شد. این ارقام بیان کننده ی کاهش 4 برابری مهندسی مجدد در قبال دوباره نوشتن سیستم است.
عبارت مهندسی مجدد با مهندسی مجدد فرآیند تجارت آمیخته شده است [ Hammer,1990 ]. مهندسی مجدد فرآیند تجارت به طراحی مجدد فرآیندهای تجارت برای کاهش شماری از فعالیت های زائد و تکراری و بهبود کارآیی فرآیند توجه دارد که معمولا متکی بر مقدمه یا افزایش پشتیبانی بر مبنای کامپیوتر برای پردازش است. فرآیند مهندسی مجدد اغلب یک محرک برای تکامل نرم افزار است. چون سیستم های قدیمی ممکن است وابستگی های مجازی را با فرآیندهای موجود ترکیب کنند. پس قبل از اینکه فرایند مهندسی مجدد اجرا شود، باید آن ها را کشف کرد و از بین برد. بنابراین وقتی مقیاس تغییرات توسط مهندسی مجدد فرآیند تجارت توانایی تطبیق با نگهداری برنامه ی نرمال را ندارد، نیاز به مهندسی مجدد نرم افزار در شرکت بیش از پیش آشکارتر می شود.
تمایز بین مهندسی مجدد و توسعه ی نرم افزار جدید نقطه ی شروعی برای پیشرفت است که این نقطه ی شروع با ویژگی های سیستم قدیمی به عنوان یکی از ویژگی های سیستم جدید می باشد.
چیکوفسکی و کراس [ ‍Chikofsky and Cross,1990 ] توسعه ی متعارف و قراردادی را مهندسی پیشرو نامیدند تا آن را از مهندسی مجدد نرم افزار تمیز بدهند. این تمایز در شکل 2 نشان داده شده است. مهندسی پیشرو با ویژگی های سیستم شروع می شود و طراحی و پیاده سازی سیستم جدید را درگیر می کند ولی مهندسی مجدد با سیستم موجود شروع می کند. فعالیت های مربوط به این فرآیند عبارتند از:
1- ترجمه ی کد مبدا: برنامه از زبان برنامه نویسی قدیمی به نسخه های مدرن به همان زبان یا زبان های دیگر تبدیل می شود.
2- مهندسی معکوس: برنامه تجزیه و تحلیل می شود و اطلاعات برای مستندسازی استخراج می گردند.
3- بهبود ساختار برنامه: کنترل ساختار برنامه برای سهولت خواندن و فهمیدن تجزیه و تحلیل و اصلاح می شود.
4- پیمانه بندی برنامه: قسمت های مرتبط برنامه با هم گروه بندی و قسمت های زائد حذف می شوند.
5- مهندسی مجدد داده ها: داده ها توسط برنامه ی تغییر یافته برای انعکاس تغییرات برنامه پردازش می شوند.

 

عوامل مهمی که بر افزایش هزینه های مهندسی مجدد تاثیر دارند عبارتند از:
1- کیفیت نرم افزار مهندسی مجدد شده: کیفیت پایین نرم افزار و مستندات مرتبط با آن.
2- ابزار در دسترس: اگر برای مکانیزه کردن بیشتر تغییرات برنامه از ابزار موردی و ویژه ی آن قسمت استفاده شود.
3- گسترش داده های تبدیلی مورد نیاز: اگر مهندسی مجدد نیاز به تبدیل و تغییر بخش اعظمی از داده ها داشته باشد.
4- دسترسی به کارمندان متخصص و خبره: اگر کارمند برای نگهداری سیستم مسئولیت پذیر نباشد.
شایان ذکر است که مهم ترین زیان مهندسی مجدد نرم افزار محدودیت کاربردی آن است که از طریق مهندسی مجدد بهبود می یابد.
ترجمه ی کد مبدا
ساده ترین شکل مهندسی مجدد، ترجمه ی برنامه است. یعنی کد مبدا در یک زبان برنامه نویسی به صورت خودکار به کد مبدا در زبان برنامه نویسی دیگری ترجمه می شود. اما ساختار و سازماندهی برنامه تغییر نمی پذیرد. زبان هدف ممکن است زبان روزآمدی از زبان اصلی باشد. مانند: COBOL-74 به COBOL-85 . یا ممکن است ترجمه ای از زبان کاملا متفاوتی باشد. مانند: FORTRAN به C++ .
ترجمه ی سطح مبدا به دلایل زیر لازم است:
1- به روز بودن پایگاه سخت افزاری: سازمان ممکن است در پی تغییر استانداردهای پایگاه سخت افزاری خود باشد. کامپایلرهای زبان اصلی ممکن است برای سخت افزار جدید قابل استفاده نباشند.
2- فقدان مهارت کارمند: سازمان ممکن است برای نگهداری از زبان اصلی با فقدان کارمند آموزش دیده مواجه
باشد.
3- تغییرات خطی مشی سازمانی: یک سازمان برای حداقل کردن هزینه های پشتیبانی نرم افزار ممکن است زبان خاصی را استاندارد کند. زیرا نگهداری از نسخه های قدیمی کامپایلرها خیلی گران است.
4- فقدان پشتیبانی نرم افزار: تهیه کننده ی کامپایلر زبان ممکن است از تجارت کناره گیری یا تولید آن محصول را متوقف کرده باشد.
برای به دست آوردن دیدگاه جامعی از سیستم های قدیمی باید بخش هایی که فرآیند مهندسی مجدد را تعریف می کند بازگو کرد: مهندسی معکوس به استخراج عناصر و اطلاعات سیستم موجود، تجزیه و تحلیل و طراحی مجدد بستگی دارد. این مرحله داده ها را برای شناسایی جنبه های آن می گیرد. چون ممکن است بخش هایی از آن نیاز به جایگزینی یا طراحی مجدد داشته باشند.

 

 

 

 

 

 

5. مهندسی معکوس
5.1- مقدمه
مهندسی معکوس در ابتدا برای تجزیه و تحلیل سخت افزار و پی بردن به مراحل طراحی آن به کار برده شد. اما امروزه در نرم افزار نیز کاربرد دارد. مهندسی معکوس عموما به دنبال بازیافت اطلاعات از سطوح پایین تا سطوح بالای یک مسئله می باشد. مانند یافتن طراحی اطلاعات از کد مبدا.
مهندسی معکوس چیزی شبیه به مهندسی مجدد نیست. هدف مهندسی معکوس نتیجه گرفتن طرح یا ویژگی های سیستم از کد مبداش است. هدف مهندسی مجدد تولید جدید و سیستم قابل نگهداری است در صورتی که مهندسی معکوس بخشی از فرآیند مهندسی مجدد است. مهندسی معکوس در حین فرآیند مهندسی مجدد برای بهبود طراحی برنامه استفاده می شود. مهندسان نیز از مهندسی معکوس قبل از سازماندهی مجدد ساختار سیستم برای درک بیشتر برنامه بهره می گیرند.
به هر صورت مهندسی معکوس همیشه از مهندسی مجدد تبعیت نمی کند:
1- چون طراحی و ویژگی های سیستم به عنوان ورودی شرایط جایگزینی در برنامه را دارا هستند، مهندسی معکوس می شوند.
2- طراحی ها و ویژگی هایی از سیستم که در نگهداری برنامه نقش دارند مهندسی معکوس می شوند. بنابراین لازم نیست دوباره کاری شود و کد مبدا سیستم را مهندسی مجدد کرد.
فرآیند مهندسی معکوس با مرحله ی تجزیه و تحلیل آغاز می شود. در این مرحله سیستم از طریق استفاده از ابزارهای خودکار برای کشف ساختارش تجزیه و تحلیل می شود. مهندسان اطلاعاتی را به سیستم کد مبدا و مدل ساختاری اش اضافه و اطلاعات زائد را حذف می کنند. سپس این اطلاعات به عنوان گراف مستقیم که به کد مبدا برنامه متصل است، نگهداری می شود. جست و جوگران منبع اطلاعاتی برای مقایسه ی ساختار گراف و کد استفاده می شوند. مستند کردن انواع برنامه، نمودارهای ساختار داده و ماتریس ها می توانند از گراف جهت دار تولید شوند. ماتریس ها، هویت در سیستم را نشان می دهند. فرآیند تولید سند به عنوان یکی از فرآیندهای تکراری در طراحی اطلاعات برای پالایش بیشتر اطلاعات که در مخزن سیستم نگهداری می شود، به کار می رود.
ابزارهای فهم برنامه در پشتیبانی از فرآیند مهندسی معکوس استفاده می شود که معمولا نماهای متفاوتی از سیستم را نشان می دهد. به عنوان مثال آن ها به کاربران اجازه می دهند تعریفی از داده ها ارائه دهند. چنین مثال هایی توسط کلیولند [ Cleveland,1989 ]، امان و کک [ Oman and Cook,1990 ] و نینگ و همکاران در سال
1994 مطرح شده است.
بعد از مستندسازی طراحی سیستم اطلاعات بیشتری برای طراحی مجدد ویژگی های سیستم به منبع اطلاعات افزوده می شود.
5.2- مزایا
مهندسی معکوس به معنی بازیافت اطلاعاتی است که سال ها از دست رفته بودند. بازیافت اطلاعات از سیستم های نرم افزاری قدیمی حائز اهمیت است. به خصوص اگر سیستم ها توسط افرادی که با سیستم آشنایی ندارند، نگهداری می شود.
در نرم افزارهای قابل استفاده ی مجدد یکی از نکات مهم، تعریف و توسعه ی عناصر قابل استفاده ی مجدد مانند اهداف، اجزای نرم افزار و بخش های مستندکردن سیستم است. با مهندسی معکوس تهیه ی انواع مستند سازی سیستم و شناخت اجزای قابل استفاده ی دوباره در سیستم میسر است. اهداف اصلی مهندسی معکوس چگونگی بهبود سیستم، حداقل کردن هزینه و مصرف و تسهیل استفاده ی مجدد از برنامه و نرم افزار است.
5.3- مسائل
در ذیل چند مسئله بیان شده است که باید در حین استفاده از مهندسی معکوس حل شوند:
اولین مسئله این است که شاید کد مبدا بسیار اندک ساختارمند شود، مشخصات از بین رفته دوباره طراحی شود یا ناقص بماند و یا مستند کردن سیستم منسوخ باشد. مسائل دیگر ترکیبی از این مدل ها و پیچیدگی ها می باشند.
وقتی سیستمی به وسیله ی اصول متناقض توسعه یافت، به طور حتم کار کردن با آن سیستم مشکل است. ابزار مؤثری برای پشتیبانی از فرآیند مهندسی معکوس وجود دارند اما همه ی آن ها قادر به استخراج اطلاعات کافی از منابع موجود و قابل دسترس نیستند ( مانند کد مبدا ). بنابراین بهترین راه برای پاسخ به این مسائل ترکیب ابزار کمکی اتوماتیک و حمایت تخصص انسانی می باشد.

 

6. تجزیه و تحلیل و طراحی مجدد
6.1- مقدمه
دومین مرحله از فرآیند مهندسی مجدد، تجزیه و تحلیل و طراحی مجدد است. این مرحله ارتباط نزدیکی با تجزیه و تحلیل و مراحل طراحی پروژه های مهندسی نرم افزار دارد. سیستم قدیمی از قبل ساختار طراحی و ویژگی های مربوط به خود را برای طراحی سیستم جدید دارد.
6.2- تجزیه و تحلیل
هدف این قسمت، تجزیه و تحلیل سیستم قدیمی به عنوان بخش بسیار مهمی از فرآیند مهندسی مجدد می باشد. زیرا بدون تجزیه و تحلیل مناسب و در نتیجه درک مناسب نرم افزار قادر نخواهیم بود پروژه ی خود را با استفاده از نتایج رضایت بخش کامل کنیم و به اتمام برسانیم. برون یابی نیاز فروشنده و / یا نیاز مصرف کننده برای ارائه ی تصویر شفافی از تولید نهایی، سود و … ضروری است. کارگروه مهندسی مجدد با شناسایی این نیازها و وضع مجدد مقررات مشخص شده کار را آغاز می کند. به کار بردن مقررات صحیح به علت هزینه بر بودن هر قدم در حلقه ی مهندسی مجدد حائز اهمیت است [ FAMOOS99 ].
همچنین بعضی پروژه ها در مهندسی مجدد سود کافی ندارند. خیلی از روش های استفاده شده در پروژه های مهندسی مجدد در مقابل سودآوری، هزینه زا هستند که طبق گفته ی برخی منابع این هزینه ها باید در طی فرآیند وجود داشته باشند. البته در بخش روش شناسی استاندارد بیشتر صحبت خواهد شد [ FAMOOS99 ] [ RM ].
6.3- طراحی مجدد
طراحی مجدد، کاربرد نتایج تجزیه و تحلیل شده بر طرح موجود است تا با افزایش عناصر جدید طرح، تغییرات کارکردی سیستم را یکپارچه کند. طراحی مجدد مشاع زیادی در مرحله ی طراحی پروژه ی مهندسی نرم افزار دارد. تفاوت وضعیت ها در طراحی سیستم مهندسی تجدید یافته باید با طراحی قدیمی عناصر دقت نظر شود و این که چگونه این عناصر بر تغییرات طرح مؤثر خواهند بود.
در بعضی موارد طراحی مجدد به دلیل تضاد بین ساختار جدید طرح و طرح موجود مشکل است. اگر اثبات طرح ها خیلی ناسازگار باشد، چه طرح را به کلی تغییر دهید و چه رویکرد دیگری به کار گیرید، طرح شکست می خورد و بر عکس اگر طرح ها مناسب یکدیگر باشند، کاربرد نرم افزار جدید آسان می شود و زمان تحویل نرم افزار کوتاه خواهد شد. در این صورت طراحی سیستم جدید باید با دقت کافی به خصوص در مرحله ی تجزیه و تحلیل انجام شود.
کارگروه باید در جهت حداقل کردن تغییرات گام بردارد. چون تغییرات ممکن است از طریق عوامل محیطی برای نرم افزار ناسازگاری به وجود بیاورد. در نتیجه به روز کردن سیستم ها بسیار مهم است. چنین طراحی هزینه را برای فروشنده افزایش خواهد داد و برای تجارت در بلند مدت هزینه را به سوی ضرر سوق می دهد. دلیل دیگر برای محدود کردن تغییرات در دیدگاه ما نهفته است. کاربر نهایی، رقیبی برای تغییرات نیستند. زمان آموزش بلند مدت، به سرعت علایق کاربر را در استفاده از نرم افزار کاهش می دهد. و حتی ممکن است باعث ترک سیستم شود ( شاید به سوی استفاده از نوع قدیمی اش ).

7. مهندسی پیشرو
7.1- مقدمه
مهندسی پیشرو شبیه به فرآیند مهندسی نرم افزار است. این نوع مهندسی در طراحی جدید که در طی فاز طراحی و تجزیه و تحلیل از طراحی سطح بالا به سمت طراحی سطح پایین و پیاده سازی آن حرکت می کند، کاربرد دارد.
گام های مهندسی پیشرو عبارتند از [ BPSARLSS94 ]:
7.2- پیمانه بندی برنامه
فرایندی برای تقسیم بندی اطلاعات است و برای ساخت گروه های طبقاتی با کارکرد مشابه و تولید عناصر قابل استفاده ی مجدد به کار می رود. نتایج پیمانه بندی، اندازه ی برنامه و پیچیدگی آن را کاهش می دهد که در نتیجه به معنی نگهداری و پشتیبانی آسان تر از برنامه است.
در تعریفی دیگر، پیمانه بندی برنامه، فرآیند سازماندهی مجدد برنامه است که بخش های آن برنامه با یکدیگر جمع و به عنوان یک مدل ارائه می شوند. برای مثال در یک برنامه که داده های زلزله نگار را پردازش می کند، همه ی عملیات های به هم پیوسته با هم جمع می شوند و خروجی آن که به صورت نمایش هندسی داده ها است، اجرا می شود.
انواع پیمانه که در طی فرآیند پیمانه بندی شکل می گیرند، عبارتند از:
? چکیده های داده ها: از به هم پیوستن مؤلفه های فرآیند به وجود آمده اند.
? پیمانه های سخت افزاری: این پیمانه ها به چکیده های داده ها بستگی دارند و همه ی توابعی را که برای کنترل دستگاه سخت افزاری نیاز است، جمع آوری می کنند.
? پیمانه های کارکردی: پیمانه هایی هستند که توابع مشابه هم که وظایف یکسانی را انجام می دهند، جمع آوری می کنند.
? پیمانه های پشتیبانی فرآیند: پیمانه هایی هستند که همه ی توابع مورد نیاز برای پشتیبانی از فرآیند تجارت خاصی را گروه بندی می کنند.
پیمانه بندی برنامه ها معمولا با ویرایش کدها صورت می پذیرد. برای پیمانه بندی برنامه باید ارتباط بین اجزا و نقش اجزا را شناخت. جست و جو و تجسم ابزار در پیمانه بندی مفید است ولی مکانیزه کردن کامل این فرآیند غیر
ممکن است.
بازیافت چکیده های داده ها
بسیاری از سیستم های قدیمی برای ذخیره کردن فضای حافظه به استفاده از جدول ( فهرست ) سهام و نواحی داده های مشترک روی می آورند. اطلاعات در این نواحی در دسترس است و ممکن است توسط بخش های دیگر سیستم به روش متفاوت استفاده شود. تغییر دادن در این نواحی پرهزینه است. زیرا هزینه ی تغییر تجزیه و تحلیل، همه ی استفاده ی داده ها را تحت الشعاع قرار می دهد. برای کاهش هزینه ی تغییر فرآیند پیمانه بندی بر شناسایی چکیده های داده ها متمرکز می شود.
گام هایی که در تبدیل داده های کلی به انواع چکیده ها مؤثرند عبارتند از:
1- تجزیه و تحلیل کردن نواحی مشترک داده ها برای شناسایی چکیده ی داده های منطقی: حالتی است که چندین چکیده در یک ناحیه ی داده با هم ترکیب می شوند و باید پس از شناسایی به طور منطقی بازسازی شوند.
2- خلق نوعی هدف برای هر کدام از چکیده ها: اگر زبان برنامه نویسی امکاناتی برای مخفی سازی داده ها نداشته باشد، شبیه سازی چکیده ی داده ها با فراهم آوری توابع برای روزآمد کردن و در دسترس قرار دادن همه ی بخش های داده امکان پذیر نیست.
3- استفاده از برنامه ی جست و جوی سیستم یا مولد اجرای متقابل برای پیدا کردن همه ی مراجع مربوط به داده ها
به نظر این فرآیند زمان بر ولی آسان است. در نسخه های قدیمی تر زبان ها مانند FORTRAN که امکانات محدودی برای بازسازی داده ها دارد، برنامه نویسان استراتژی های مدیریت داده های پیچیده را طراحی می کنند.
7.3- پیاده سازی
در حین پیاده سازی برنامه طبقه بندی ها نباید نه زیاد بزرگ و نه زیاد کوچک باشند. یکی از اصول پیاده سازی این است که طبقه بندی باید به صورت تک مفهومه پیاده سازی شود. اگر طبقه بندی به صورت چند مفهومه پیاده سازی شود، احتمالا مقادیر همبستگی پایینی خواهد داشت. زیرا این مفاهیم باید به صورت جداگانه پیاده سازی شوند. اما اگر طبقه بندی به صورت تک مفهومه پیاده سازی نشود، به معنی این است که مفهوم بین چندین طبقه به کار رفته است و احتمالا به شدت به هم پیوسته اند [ FAMOOS99 ].
مهندسی پیشرو باید طراحی سطح پایین را طوری طراحی کند که همبستگی و رابطه ی متقابل سیستم در یک سطح نگه داشته شود تا قادر به استفاده ی مجدد و ترمیم سریع باشد.

7.4- آزمایش
آزمایش برای پیدا کردن اشتباهاتی که در طول اجرای برنامه ممکن است رخ دهد، ایجاد شده است و همین طور چیزهایی که در سیستم کار می کنند، بهبود می بخشد ( بهینه سازی ). بعضی از قسمت های آزمون برای بخش هایی که بنیادی و اساسی هستند به صورت پیشرفته برنامه ریزی می شوند. چنین قسمت هایی از آزمون معمولا در طول مراحل طراحی مجدد یا مهندسی پیشرو پیاده سازی و اجرا می شوند.
آزمون اشخاص در آزمون برنامه نیز استفاده می شود. کسانی که برنامه را آزمون می کنند تجربه های متفاوتی از کار کردن با انواع نرم افزارها به دست می آورند و به نتایج متفاوتی می رسند. این نتایج در بهبود وجه اشتراک کاربر استفاده می شوند و اشتباهاتی که مهندسان در تست عمومی، آن ها را پیدا نکرده اند، آشکار می کنند.