دانلود رایگان ترجمه مقاله فرآیند مهندسی مجدد و الگوهای آن

مقاله انگلیسی رایگان

ترجمه فارسی رایگان 

بخشی از ترجمه فارسی:

چکیده:

هدف از اين مقاله شرح فرآيند مهندسي مجدد نرم افزار براي بهبود نگهداري از سيستم نرم افزاري مي باشد. پس از خواندن اين مقاله شما مي توانيد:  نقش مؤثر مهندسي مجدد در تكامل سيستم نرم افزاري را درك كنيد.  فعاليت هايي نظير مهندسي معكوس و تجديد ساختار برنامه كه در فرآيند مهندسي مجدد نرم افزار نقش دارند، درك كنيد.  تفاوت هاي بين نرم افزار و همين طور دليل گران بودن و زمان بر بودن فرآيند مهندسي مجدد داده ها را درك كنيد.

۱٫ مقدمه

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

۲٫ چكيده

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

۳٫ تاريخچه ي

مفاهيم مهندسي مجدد در اوايل سال هاي انقالب اطالعاتي از طرف جوامع نيازي به مهندسي مجدد بيان نشده بود. در عوض، توجه جوامع به سوي كشف راه هاي جديد براي ساختن نرم افزارها و سخت افزارهاي جديد بود. نكته ي حائز اهميت اين بود كه جوامع چگونه پيشرفت سيستم جديد را كه با سرعت فزاينده آشكار مي شد و انتشار پيدا مي كرد، اداره مي كردند. تقريبا به سيستم هاي قديمي كه كم كم منسوخ مي شدند هيچ توجهي نمي شد. به عالوه تجارت ها به سرعت در حال تغيير بودند و همراه با اين تغييرات به نرم افزارهاي اطالعاتي مناسب نياز شد كه اين دوران به عنوان ” كمبود نرم افزار” شناخته مي شد. زيرا نرم افزارها در حال ارتقا بودند ولي براي رفع نيازهاي تجارت كافي نبود. در اوايل دهه ي ۰۹، تمركز به سرعت از پيشرفت نرم افزار جديد به مهندسي مجدد سيستم هاي قديمي تغيير يافت ) سيستم ها به مدت زيادي براي نگهداري و تعميرات رشد كردند (. در حقيقت در اين زمان توجه زيادي به مهندسي مجدد شد و برحسب روش شناسي مهندسي مجدد پيشرفته و الگوهاي آن، تجارت يكپارچه و ساختارهاي آن، به رسميت شناخته شد. مهندسي مجدد كلمه ي روز بود و مشاور مهندسي مجدد، به يك رشته تبديل شد ] .] BPR 99 اما اعتقادي كه مشاوران به مهندسي مجدد تجارت و نرم افزارهايش داشتند، به اين آساني هم نبود. بالغ بر نيمي از فرآيند مهندسي مجدد در آن زمان منجر به شكست شد. خيلي از آن ها به خاطر عدم تجربه و فقدان مشاركت خريدار و مشتري بود. اين شكست ها هزينه هاي سنگيني به شركت ها تحميل كرد و پيشرفت سريع مهندسي مجدد را با وجود عالقه به توسعه ي مهندسي مجدد به پايان رسانيد ] BPR 99 [. هنوز حدود ۰۹ درصد هزينه هاي بودجه ي سيستم اطالعاتي تجارت مربوط به نگهداري سيستم هاي قديمي مي شود. به اين معني كه فقط ۲۹ درصد كل هزينه، مربوط به توسعه ي سيستم جديد است. اين نشان مي دهد كه مهندسي مجدد، سازماندهي مجدد و طراحي مجدد سيستم ) يا تجارت ( بسيار مهم است. اگر اين هزينه ها كم شود سود زيادي براي كاربران نرم افزار به دست خواهد آمد. اين حقيقت به بازگشت به جامعه ي فعال تحقيق مهندسي مجدد كمك مي كند و همان طور كه وارد قرن بيست و يكم مي شويم، مشاهده مي كنيم كه مهندسي مجدد دوباره در حال پيشروي به سمت مهندسي نرم افزار است. به هر حال از نقطه نظر تجارت، مهندسي مجدد نرم افزار ممكن است تنها روش براي ابقاي سيستم هاي قديمي باشد تا اين سيستم ها بتوانند به وظايفشان عمل كنند. بنابراين ممكن است اين رويكرد براي تطبيق با رويكردهاي ۲ ديگر سيستم بسيار گران و مخاطره آميز باشد.

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

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

بخشی از مقاله انگلیسی:

۱٫ PREFACE We have made a report about reengineering and reengineering patterns. The report is part of the course Object Oriented Programming fk at Mälardalen University. At the beginning, when we choosed the subject reengineering patterns, we did not have any specific knowledge about what it actually meant. We started to search for information at the Internet, but it wasn’t so much information there as we had hoped, most of the information were similar or not the kind of information that we were looking for. Finally, we located some sites that were of interest to us in our work. When we had read some articles and publications we started to understand what reengineering and reenginering patters really is. By discussing with each other in the group we found specific areas that we thought were particulary interesting. Now, when we knew a little bit more about reengineering and reegnineering patterns, we decided to begin writing our report. Because the time of the project have been limited and that it has been hard to find information it was difficult to pass the deadline. But even if we think it has been quite hard we also think that we have learned a lot about the concept of reengineering. 2. ABSTRACT Reengineering and Reengineering patterns is a relatively new concept that has begun to make an impact on the software engineering sociaty. By shifting resources towards the restructuring of old legacy software systems rather than focusing on new software development the businesses would and have been able to save precious time and resources. Even though the benefits of this approach is clear, the difficulties that follows with the concept, together with inexperience and the lacking of appropriate tools make the reengineering of software systems a difficult but interesting subject. 3. THE HISTORY OF THE REENGINEERING CONCEPT In early years of the information revolution the need for reengineering was not acknowledged by the wider community. Instead, attention was directed towards the discovery of new ways of creating both better hardware and better software. Methodologies that were concerned with how to engineer the development of new systems where published, cheered and disposed in an ever increasing rate. Almost no attention were given to the old systems that were getting more and more outdated. In addition, the businesses where changing rapidly and with them came the need for appropriate information software. This became known as ‘software shortage’; since there always seemed like newly devoloped software where not good enough to accommodate the business needs. Then, in the early 90’s the focus of system devolopment changed very rapidly from the development of new software to the reengineering of old ‘legacy’ systems (systems developed over time and in need of maintainance). The fact is, that so much attention where given to reengineering that entire businesses where cought up in the excitement and had their entire business structure reorganized according to the newly developed reengineering methodologies and patterns that had emerged. Reengineering was the word of the day and the reengineering consultants where having a field day [BPR 99]. But soon it became appearant that the reengineering of both business and it’s software where not as easy as the consultants had first believed. Over half of the reengineering processes of the time failed, mostly due to inexperience and lack of customer involvement. With these failures followed huge costs for the companies and soon the reengineering boom was over, and with it the interest in reengineering devolopment [BPR 99]. Still, almost 80% of a business information system budget costs comes from the maintainance of old legacy systems. That means only 20% of the total cost can be related to the development of new systems [SR]. This shows that reengineering, the reorganization and redesign of a system (or business), is very important; since if these costs can be reduced, much will be gained for the software user. This fact has contributed to the return of an active reengineering research community, and as we enter the 21st century we see that reengineering is once again marching forward into the frontlines of software engineering.