Федеральне агентство з освіти
Державна освітня установа вищої професійної освіти
В«Казанський державний технологічний університет В»
Нижньокамський хіміко-технологічний інститут
Реферат на тему:
В«Реінжиніринг програмного забезпечення В»
Виконав: Нагімова Д.І.
Перевірила: Хурматулліна С.А.
Нижньокамськ 2010
Зміст
Введення
Визначення і етапи реінжинірингу
Цілі і завдання реінжинірингу
Проблеми при реінжинірингу
Управління вимогами
Процес
Аналіз та проектування
Реалізація
Тестування
Процеси підтримки
Переваги та недоліки компанії-розробника перед окремим розробником
Чому компанії-розробники не люблять реінжиніринг
Рентабельність реінжинірингу
Список використаної літератури
Введення
Комп'ютер без програмного забезпечення - купа металу, яку до того ж не можна здати на металобрухт. Купивши навіть самий швидкодіючий комп'ютер, підприємство не вирішує основної проблеми - автоматизація підприємства. Для цього потрібні програми.
Різноманітність програмного забезпечення куди більше, ніж технічних рішень. Так як вони вирішують самі різні завдання, починаючи від зв'язку з обладнанням (драйвера) і закінчуючи автоматизацією бухгалтерського обліку або 3-х мірними іграми.
Однак навіть при такому великому розмаїтті програмних рішень може виявитися, що немає повністю задовольняє програмного рішення.
Для вирішення даної проблеми підприємство, як правило, знаходить програміста, який намагається реалізувати дану програму. Проходить час, програма впроваджується на підприємстві і з нею починає працювати велика кількість персоналу. Звикнувши до програмі, співробітники вже не уявляють себе без такого зручного інструменту, як програма. Проходить ще час, а програміст бере і звільняється, йде на іншу роботу або взагалі їде за кордон (або вмирає) і більше продовжувати і підтримувати проект не може. В результаті, підприємство стикається з великою проблемою: є програма, з якою звик працювати персонал і подібної на ринку не знайти, але немає її подальшого вдосконалення і підтримки. Дана програма починає різко застарівати. Спочатку, в ній, виявляється, немає якихось можливостей, які потрібні стали після звільнення програміста, а потім - вона не може ефективно працювати із сучасним обладнанням або взагалі, починає "Гальмувати" через велику кількість введеної інформації.
Проходить ще небагато часу - від півроку до 2-х років і виявляється, що на даній програмі більше не можна працювати, так як вона "глючить", "гальмує" і взагалі перестає працювати ...
Зіткнувшись з даною проблемою, підприємство починає шукати нового програміста або компанію, яка здатна привести дану програму до задовольняючому підприємство увазі. Однак, як виявляється не все так просто ... Виявляється, велика кількість програмістів, які хоч що-небудь вміють зробити виїхало за кордон. А на ринку залишилися ті, хто виїхати не зміг або кому не було в цьому потреби. Підприємству дуже пощастить, якщо воно одразу знайде грамотного і відповідального програміста. Як правило, доведеться перебрати 2-3 людини, перш, ніж вони знайдуть гідну кандидатуру. Однак, грамотні програмісти дешево не коштують і постійно хочуть перспектив. Тому, якщо ви не швидко розвивається програмне підприємство, та ще не так вже й багато платите, то прийде момент, що даний програміст піде теж. І знову починається все знову: 2-3 безвідповідальних програміста, потім один професійний і відповідальний, який 2-3 місяці буде вникати в курс справи і через 2-3 роки піде ...
Ось, чому, підприємства, які працюють довго і успішно на ринку, в результаті приходять до висновку, що для подальшого вдосконалення програм необхідно найняти компанію-розробник.
Визначення та етапи реінжинірингу
Реінжиніринг програмного забезпечення - процес створення нової функціональності або усунення помилок, шляхом революційної зміни, але використовуючи вже наявне в експлуатації програмне забезпечення. Процес реінжинірингу описаний Chikofsky і Кросом в їхній праці 1990 року, як В«The examination and alteration of a system to reconstitute it in a new form В». Висловлюючись менш формально, реінжиніринг є зміною системи програмного забезпечення після проведення зворотного інжинірингу.
Реінжиніринг програмного забезпечення, можна розділити на кілька етапів:
Початкова фаза. Почати процес реінжинірингу слід з визначення того, що Тобто по існуючій системі (вихідні тести, БД, описи і т. д.). При цьому фіксується поточний стан успадкованої системи (всі зміни, що вносяться до неї після цього моменту, при виконанні реінжинірингу не враховуються). Якщо є можливість виконується розгортання наследуемой ПС у розробника.
Визначення системних архітектур. Роботи з опису архітектур починаються фактично на початковому етапі, коли визначається склад обладнання та стандартне програмне забезпечення (ПЗ), необхідні для інсталяції і запуску існуючої зафіксованої системи. Тим самим фактично визначаються архітектури БД, обладнання та стандартного ПЗ, телекомунікацій. Все архітектури представляються в нотації UML і при необхідності доповнюються текстовими описами. Поостренние архітектурні моделі в процесі реінжинірингу будуть уточнюватися і доповнюватися.
Автоматичний реінжиніринг. Автоматичний реінжиніринг здійснюється за допомогою інструментальних засобів візуального моделювання. Його виконання дозволяє побудувати моделі, які можуть бути прийняті як вихідні. Автоматичного реінжинірингу піддається як бізнес логіка (якщо є вихідні коди на об'єктно-орієнтованому або об'єктно-базувалися мовою), так і БД.
Автоматичний реінжиніринг бізнес логіки може бути виконаний тільки в випадку, коли є (повністю або частково) вихідні тексти програм. В результаті автоматичного реінжинірингу кодів створюються діаграми класів і діаграми компонент UML.
Реінжиніринг БД виконується за допомогою інструментальних засобів проектування БД. Результатом є реляційна модель даних, яка може графічно відображатися цим засобом. Отримана реляційна модель може за розсудом розробників переведена в діаграму класів UML шляхом використання застосовуваного інструментального засобу розробки БД або програмних мостів із засобами візуального ГО моделювання.
Редагування діаграм моделей. Моделі, отримані автоматично, вельми складно читати і аналізувати, оскільки елементи моделі розміщуються без обліку наочності діаграм. Тому побудовані моделі повинні бути відредаговані. У процесі редагування не слід виконувати змістовні перетворення (видаляти або додавати елементи моделі). Головною метою редагування на цьому етапі є досягнення наочності діаграм. Для цього використовується переміщення елементів діаграм. У процесі редагування можуть вноситися коментарі до елементів моделі. Наприклад, можна прокоментувати призначення окремих класів. Коментарі заносяться в поля специфікацій елементів моделей.
Якщо діаграма містить занадто багато елементів, то аналізувати її складно. Спробуйте проаналізувати діаграму, що містить більше 100 класів! Тому доцільно розбити таку діаграму на кілька окремих діаграм, залишаючи в кожній приблизно по 7 - 10 елементів.
Метод підвищення наочності діаграм добре відомий. Це ієрархічна реструктуризація. Засобом її здійснення в UML є пакети. Складні ПС зазвичай включають кілька підсистем , що мають різне цільове призначення і функціональність. Тому на верхньому рівні ієрархії можна показати пакети - підсистеми. Кожен з таких пакетів повинен отримати ім'я, що відображає суть відповідної підсистеми. На цьому рівні можна також показати пакети класів, які є загальними для всієї системи і використовувані підсис...
