Реінжиніринг програмного забезпечення

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Федеральне агентство з освіти

Державна освітня установа вищої професійної освіти

«Казанський державний технологічний університет»

Нижньокамський хіміко-технологічний інститут

Реферат на тему:

«Реінжиніринг програмного забезпечення»

Виконав: Нагімова Д.І.

Перевірила: Хурматулліна С.А.

Нижньокамськ 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 є пакети. Складні ПС зазвичай включають кілька підсистем, що мають різне цільове призначення і функціональність. Тому на верхньому рівні ієрархії можна показати пакети - підсистеми. Кожен з таких пакетів повинен отримати ім'я, що відображає суть відповідної підсистеми. На цьому рівні можна також показати пакети класів, які є загальними для всієї системи і використовуються підсистемами. На початковій стадії реструктуризації логічної моделі можна ввести пакет верхнього рівня, куди містяться класи, які важко віднести до якого-небудь іншого пакету. У будь-якій ПС є користувальницький інтерфейс, зв'язок з БД, управління, обробка, класи даних. Такого типу пакети можна запровадити в кожній підсистемі на наступному рівні ієрархії.

Побудова функціональної моделі. Модель функціонування описується за допомогою діаграм ВІ і деталізують їх діаграм послідовностей і діяльностей. Джерелом для її побудови є працююча успадковується система і які проводяться з нею експерименти. На цьому етапі особливо ефективно залучення до робіт з реінжинірингу експерта організації замовника (див. статтю «RUP. Загальні відомості»). З його допомогою можна швидше і точніше визначити склад акторів успадковане системи та основні ВІ. Експерт замовника може словесно описати, хто використовує систему і що вона повинна робити для користувачів кожного типу. Він може також інформувати, з якими іншими системами взаємодіє успадковується ПС, які роботи здійснюються періодично. Всі ці відомості будуть сприяти більш точного розуміння функціональності системи розробниками.

Визначення акторів. Для знаходження акторів слід шукати відповіді на наступні питання:

  • Хто є безпосередніми користувачами системи? Необхідно при відповіді на дане питання вказувати ролі, а не конкретних людей, які виконують ці ролі.

  • З яким зовнішнім устаткуванням або програмами здійснює взаємодію система?

  • Чи виконує система роботи, що активізуються настанням конкретного часу або закінченням певних періодів часу (при позитивній відповіді одним з акторів є таймер)?

Відповіді на поставлені запитання можна отримати або шляхом опитування експертів замовника, або з документації на систему, або (якщо таких немає) шляхом запуску системи і аналізу екранних форм або меню.

Акторам слід присвоїти імена, що відображають їх ролі в роботі з системою.

Визначення варіантів використання. Визначення ВІ виконується на основі аналізу екранів працюючої системи. Спочатку визначаються пакети ВІ. Для цього слід знайти всі первинні екрани і для кожного з них в моделі на головний діаграмі ВІ завести окремий пакет. Таким чином, на цій діаграмі буде пакет акторів і кілька пакетів ВІ.

Далі виконується деталізація побудованих пакетів ВІ на основі аналізу екранних форм. Рекомендовані правила:

  • якщо екран містить меню, то це пакет ВІ. При цьому кожен рядок меню - це або подпакетах, або окремий ВІ;

  • якщо основний екран - форма, то це окремий ВІ.

Визначення взаємодій акторів і ВИ. Оскільки дуже важливо показати, як актори співвідносяться з ВІ, після знаходження ВІ визначається, які актори взаємодіють з системою в цьому варіанті. У модель включаються асоціації. Вони мають напрямків, які відповідають напрямках передачі інформації між акторами і ВИ.

Розподіл по пакетах. Якщо число акторів або ВІ занадто велике, то для спрощення підтримки моделі ВІ доцільно розділити їх по пакетах. Це також спрощує розуміння моделі і розподіл відповідальності шляхом призначення розробників, відповідальних за пакети ВІ. Можна використовувати наступні критерії упаковки ВІ в один пакет:

  • якщо вони взаємодіють з одним актором;

  • мають один з одним відносини включення чи розширення (див. статтю «Варіанти використання системи. Use case діаграми»).

Можуть бути й інші способи забезпечення наочності моделі, важливо лише мати чітку стратегію розбиття на пакети.

Побудова навігації екранів. Одночасно з виділенням ВІ будується навігація екранів успадковане системи у вигляді діаграми класів UML. Кожен екран показується в моделі як окремий клас, в якому полях відповідають атрибути, функціональним кнопкам - операції, а кнопкам меню - однойменні відносини.

Деталізація функціональності. Деталізація функціональності є побудова сценаріїв реалізації ВІ, представлених в моделі ВІ. Вона виконується за допомогою діаграм послідовностей і діаграм діяльностей UML. Вибір виду діаграм в кожному конкретному випадку залежить від того, що переважає в даному ВІ - логіка виконання або передачі даних. У першому випадку переважно застосовувати діаграми діяльностей, де легко показувати розгалуження і паралельну обробку, у другому - діаграми послідовностей.

Деталізація потрібно особливо для тих варіантів використання, в яких важлива послідовність дій, враховується стан системи, є розгалужена логіка виконання. Доцільно деталізувати виконання ВІ, що визначають основну функціональність системи. Якщо замовник висловлює побажання щодо того, що з успадкованою системи має бути збережено в новій ПС, то саме ці ВІ повинні бути деталізовані.

Деталізація здійснюється на основі аналізу вихідних кодів. За текстів програм виявляються розгалуження, вирази, цикли. Це дозволяє відновити алгоритми, представивши їх у вигляді діаграм діяльностей або діаграм станів. Інший шлях - це проведення експериментів з працюючої успадковане системою. Варіювання вхідних даних і аналіз реакції системи на ці дані робить можливим виявлення розгалужень і обмежень. Можна також висувати і перевіряти гіпотези про алгоритми обчислень.

Моделі, побудовані в результаті реінжинірингу, є основою для визначення вимог до проектованої ПС, а також для побудови логічної і функціональної моделей нової системи.

Цілі і завдання реінжинірингу

Цілі реінжинірингу

Цілі проведення реінжинірингу полягають у наступному:

  • отримання уяви про склад існуючої системи;

  • моделювання існуючої системи;

  • визначення фрагментів програмного коду, які можуть бути використані в розробляється новій системі;

  • визначення успадкованих даних.

Завдання реінжинірингу

Завдання, які вирішуються при реінжинірингу, включають:

  • визначення системних архітектур;

  • визначення акторів існуючої системи;

  • визначення функціональності існуючої системи;

  • визначення логічної структури системи;

  • відновлення реляційної моделі даних.

Порядок вирішення цих завдань принципово відрізняється від порядку дій, які виконуються при розробці нових проектів. Логічна архітектура системи визначена її реалізацією, зокрема, структурою каталогів, розміщенням файлів по каталогах, розподілом завдань між сервером і клієнтськими місцями. Крім того, частина моделей системи може бути отримана автоматично за допомогою інструментальних засобів. Таким чином, не функціональне опис системи служить основою для виявлення класів і відносин між ними, а навпаки, попередньо отримані діаграми класів можуть істотно полегшити опис поведінки системи.

Проблеми при реінжинірингу

Як правило стверджується, що "легше розробити новий програмний продукт". Це пов'язано з наступними проблемами:

  1. Звичайному програмісту складно розібратися в чужому вихідному коді

  2. Реінжиніринг найчастіше дорожче розробки нового програмного забезпечення, тому що потрібно прибрати обмеження попередніх версій, але при цьому залишити сумісність з попередніми версіями

  3. Реінжиніринг не може зробити програміст низької та середньої кваліфікації. Навіть професіонали часто не можуть якісно реалізувати його. Тому потрібна робота програмістів з великим досвідом переробки програм і знанням різних технологій.

У той же час, якщо спочатку програма мала суворої і ясною архітектурою, то провести реінжиніринг буде на порядок простіше. Тому при проектуванні як правило аналізується, що вигідніше провести реінжиніринг або розробити програмний продукт "з нуля".

Управління вимогами

Вимоги до ПС

Вимога - це характеристика чи умова, якому повинна задовольняти ПС.

Функціональні вимоги визначають дії, які повинна виконувати ПС, без урахування фізичних обмежень. Тим самим вони визначають поведінку системи при введення і виведення. Процес виявлення функціональних вимог досить складний і трудомісткий. Це пояснюється наступними причинами:

  • таких вимог до системи зазвичай багато,

  • замовник не завжди здатен чітко сформулювати, чого він хоче від системи,

  • вимоги в підсумковому документі повинні бути викладені так, щоб вони однаково розумілися замовником і виконавцем і не допускали неоднозначності,

  • між функціональними вимогами можуть бути різні залежності, що ускладнюють керування ними в разі необхідності внесення змін.

Для подолання цих труднощів застосовується моделювання вимог. Модель вимог дозволяє, по-перше, встановити ієрархію вимог, що сприяє кращому розумінню людиною, по-друге, дає наочне графічне представлення вимог і залежностей між ними, в третіх дозволяє зв'язати графічну форму представлення з текстовою, забезпечуючи людини повною інформацією.

Нефункціональні вимоги не описують поведінку програмної системи, але описують її атрибути або атрибути оточення. Нефункціональні вимоги не потрібно включати в модель вимог, але вони повинні бути точно сформульовані. Зазвичай нефункціональних вимог не буває багато, проте вони кардинальним чином впливають на вибір архітектури системи.

Управління вимогами - це досить складний і розтягнутий у часі процес. Він триває протягом більшої частини життєвого циклу, оскільки зміни можуть вноситися як під час розробки, так і після здачі системи на етапі дослідної експлуатації і при супроводі. Причини цього полягають у тому, що вимоги:

  • неочевидні,

  • виходять з багатьох джерел,

  • важко формулюються (мову неоднозначний),

  • складаються з безлічі різних деталей,

  • нерівнозначні,

  • пов'язані один з одним,

  • лежать не лише у функціональному області.

  • можуть змінюватися протягом розробки і при супроводі.

    Цілі аналізу і моделювання вимог

    Цілями аналізу і моделювання вимог є:

    • досягнення угоди між розробниками, замовниками і користувачами про те, що повинна робити ПС;

    • досягнення кращого розуміння розробниками того, що повинна робити система;

    • обмеження системної функціональності;

    • створення базису для планування розробки проекту;

    • визначення користувальницького інтерфейсу;

    • складання специфікації вимог.

    Ролі

    • Системний аналітик - фахівець організації-розробника, який очолює і координує роботи з виявлення та моделювання вимог.

    • Розробник ВІ - фахівець організації-розробника, який деталізує і уточнює моделі вимог.

    • Зацікавлені особи - люди, що надають інформацію.

    • Експерт - представник замовника, який бере участь у розробці моделі вимог.

    • Розробник користувальницького інтерфейсу - фахівець організації-розробника, який створює прототип інтерфейсу ПС.

    Артефакти

    Для досягнення поставлених цілей передбачається створення таких документів:

    • Попередня угода - текстовий документ, який описує, що буде включено в ПС і що вирішено виключити, тобто, він обмежує системну функціональність. У ньому відбиваються побажання зацікавлених осіб, а також вказуються основні нефункціональні вимоги (наприклад, описується платформа реалізації, точність обчислень, час відгуку).

    • Модель вимог служить для досягнення угоди між замовником і розробниками, даючи можливість замовнику переконатися в тому, що система буде робити те, що вони очікують, а розробникам створити те, що потрібно. Модель вимог дозволяє, по-перше, встановити ієрархію вимог, що сприяє кращому розумінню людиною, по-друге, дає наочне графічне представлення вимог і залежностей між ними, в третіх дозволяє зв'язати графічну форму представлення з текстовою. Модель включає акторів і ВИ, показує, як система взаємодіє з акторами і що вона робить в кожному ВІ.

    • Специфікація вимог (Software Requirements Specification) - основний документ, який використовується при проектуванні та розробці ПС. Вона включає в себе модель вимог і додаткові специфікації, які представляють собою текстовий опис вимог до кінцевого продукту, але не до процесу його розробки і не містять деталей реалізації вимог.

    • Прототип інтерфейсу забезпечує візуальне представлення інтерфейсу користувача з ПС.

    • Глосарій - текстовий документ, що містить визначення основних понять і термінів, які повинні однаково розумітися замовником та розробником. Джерелами даних для створення перерахованих артефактів можуть, зокрема, служити артефакти, створені при бізнес-аналізі (див. статтю «RUP. Обстеження організації (бізнес-аналіз)».

    Процес

    У процесі аналізу і моделювання вимог можна виділити декілька основних етапів (див. рис.1).

    Рис.1 Технологічний процес управління вимогами.

    Початок аналізу.

    Спочатку слід визначити коло зацікавлених осіб. Якщо проводився бізнес-аналіз, то вони вже відомі. Збираються побажання зацікавлених осіб до майбутньої ПС. Ці побажання аналізуються, визначаються основні властивості і межі ПС, досягаються угоди про те, які проблеми мають бути вирішені.

    Результати. Повинен бути складений документ «Попередня угода», який буде відправною точкою для виконання всіх подальших робіт. На цьому етапі починається створення глосарію. Якщо глосарій був створений при бізнес-аналізі, то він використовується як відправною документ. Оскільки тут мова йде про виявлення вимог до ПС, в глосарій можуть включатися терміни, пов'язані з реалізації (наприклад, броузер, сервер та ін.) Визначення цих термінів повинні сприяти кращому розумінню системи зацікавленими особами.

    Побудова моделі вимог

    Ця робота передбачає виявлення акторів, ВІ та взаємодій між ними. Якщо було проведено обстеження організації, то як джерело для визначення акторів і ВИ може служити бізнес-модель.

    Якщо число ВІ занадто велике, то для спрощення читаності і підтримки моделі доцільно розділити їх по пакетах. Це також спрощує розуміння моделі і розподіл відповідальності шляхом призначення розробників, відповідальних за пакети ВІ. Пакети дозволяють організувати ієрархію вимог. Верхній рівень ієрархії зазвичай визначається, виходячи з основних видів діяльності організації. Якщо був виконаний бізнес-аналіз, то основні види діяльності вже представлені в бізнес-моделі у вигляді пакетів, і вони можуть бути просто скопійовані в модель вимог. Пакетів верхнього рівня не повинно бути багато. Доцільно виділити пакет адміністрування і пакет допоміжних дій, і 2 - 4 пакети, основних видів діяльності. У свою чергу, пакети верхнього рівня можуть включати пакети наступного рівня і т. д.

    Коли ви окресліть вихідну модель вимог, ви повинні уважно перевірити, що вона покриває всі заявки зацікавлених осіб, представлені в документі «Попередня угода».

    Деталізація моделі вимог

    Цілі даної діяльності:

    • витяг з ВІ характерних фрагментів, які можуть розглядатися як окремі абстрактні ВІ. Прикладами таких частин можуть бути спільні фрагменти, необов'язкові фрагменти і виключення;

    • виявлення нових абстрактних акторів, які грають ролі, колективні кількома акторами;

    • реструктуризація моделі вимог;

    • детальний опис потоків подій для ВІ;

    • завдання пріоритетів ВІ.

    Коли ви просунетеся досить далеко, ви можете захотіти переглянути вихідну модель, оскільки існує тенденція вводити на перших порах дуже багато акторів. Слід пам'ятати, що будь-яка модифікація акторів може викликати суттєві зміни у системному інтерфейсі і поведінці.

    Деталізація ВІ передбачає розробку діаграм послідовностей, кооперацій або діяльностей, що описують виконання основної і допоміжних робіт у конкретному ВІ.

    Визначення пріоритетів означає, що всі ВІ ранжуються на критичні, важливі і допоміжні. Критичні ВІ, представляють основну системну функціональність або мають істотне архітектурне значення. Важливі ВІ визначають такі системні функції, як збір статистики, складання звітів, контроль і функціональне тестування. Якщо вони не реалізовані, то система може виконувати своє призначення, але зі значно гіршою якістю сервісу. Допоміжні ВІ визначають зручність використання ПС.

    Складання додаткових специфікацій

    Додаткові специфікації представляють собою текстові описи вимог. Вони доповнюють модель вимог і поряд з нею включаються в підсумковий документ - специфікацію вимог до ПС. Слід чітко розуміти, що кожен ВІ є деякий ієрархічне вимога до ПС. Дуже важливо, щоб між моделлю вимог і описом вимог у специфікації було точну відповідність. Якщо ВІ простий, то в специфікації він описується як окремий функціональний вимогу. У більш складних випадках ВІ може бути розбитий на декілька більш простих варіантів (на діаграмах це можна зробити за допомогою пакетів, ввівши ще один рівень ієрархії, у специфікації - ввести наступний рівень нумерації).

    Проектування користувальницького інтерфейсу

    Цей процес виконується для того щоб замовник міг більш точно уявити собі роботу і можливості майбутньої ПС і видати свої зауваження й уточнення вимог. Залежно від складності проекту і рівня підготовленості замовника результати цих робіт можуть бути представлені в різних формах:

    • програмна реалізація, що відтворює точний вид екранних вікон;

    • альбом екранних форм;

    • модель навігації екранів у вигляді діаграм класів із зазначенням атрибутів - полів і операцій - кнопок.

    Створення специфікації вимог

    Специфікація вимог створюється на основі моделі вимог та додаткових специфікацій. Вона затверджується керівництвом замовника та розробника і служить основним відправним документом для проектування і розробки. Зокрема, модель вимог, що входить до неї, в подальшому буде розвинена в модель аналізу та дизайну.

    Аналіз та проектування

    Мета і завдання аналізу та проектування

    Мета процесу аналізу і проектування полягає в розробці технічних інструкцій, розпорядчих, як реалізувати ПС, що задовольняє сформульованим вимогам. Для цього слід добре зрозуміти вимоги до ПС і перетворити їх у проект системи, вибравши правильну стратегію реалізації. На ранніх стадіях процесу має бути створена стійка архітектура, на основі якої можна спроектувати ПС, легку для розуміння, побудови і розгортання. Архітектура повинна бути узгоджена з середовищем реалізації з метою задоволення вимог до продуктивності, стійкості, безпеки, розширюваності і тестованості.

    До числа вирішуваних завдань при цьому відносяться:

    • розробка точної архітектури розподіленої програмної системи;

    • перетворення моделі вимог в модель проектну розроблюваної системи;

    • адаптація проекту системи до середовища реалізації з метою підвищення продуктивності розробки;

      • вибір механізмів реалізації та визначення обмежень на реалізацію;

      • розробка компонентної структури;

      • розподіл компонентів по вузлах.

      Головним завданням аналізу є перетворення вимог у форму, зрозумілу розробнику, тобто, визначення підсистем, компонентів і класів, за допомогою яких реалізується необхідну поведінку ПС. В основі такого перетворення лежать ВІ, створені при визначенні вимог до ПС. При цьому розглядаються тільки функціональні вимоги і ігноруються нефункціональні.

      Проектування - це уточнення результатів аналізу, спрямоване на оптимізацію з урахуванням обмежень, накладених нефункціональними вимогами, середовищем реалізації і т. д.

      Ролі

      Системний архітектор - керує роботами по аналізу і проектування ПС. Він визначає загальну структуру кожного архітектурного подання (див. статтю «RUP. Загальні відомості»), декомпозицію уявлень, угруповання елементів і інтерфейси між групами.

      Розробник - проектує класи і відносини між ними Він визначає, як узгоджувати класи з середовищем реалізації.

      Розробник БД - відповідає за проектування бази даних ПС.

      Артефакти

      У процесі аналізу і проектування створюються такі документи:

      Модель проектування - це основна модель ПС. Вона описує підсистеми, пакети, компоненти, інтерфейси і класи, а також їх взаємодії, що забезпечують необхідну поведінку ПС.

      Документ «Архітектура ПС», в якому зібрані різні архітектурні подання ПС.

      Модель даних - це опис структури даних, що зберігаються в БД (наприклад, реляційна модель даних).

      Технологічний процес

      Спрощена схема діяльностей, виконуваних в окремій ітерації процесу аналізу і проектування, наведена на рис.2. Виконання деяких діяльностей залежить від фази розробки, що показано у вигляді коментарів на діаграмі діяльностей.

      Рис.2 Діаграма діяльностей, що описує процес аналізу та проектування

      Визначення потенційної архітектури. Дана діяльність включає архітектурний аналіз та аналіз ВІ. Визначається початковий набір архітектурно значимих елементів і механізмів реалізації, виконується початкове розбиття на рівні, визначається структура системи, вибираються ВІ, які будуть реалізовуватися в першій ітерації фази розвитку проекту. У результаті створюється ескіз архітектури ПС. На основі аналізу архітектурно значущих ВІ визначаються основні класи, які включаються в модель аналізу. У модель аналізу включаються діаграми, що описують взаємодію основних класів.

      Уточнення архітектури. Діяльність включає визначення механізмів проектування, елементів проекту, об'єднання існуючих елементів проекту, опис архітектури реального часу (якщо проектована ПС відноситься до цього класу). В результаті виконання цих робіт досягаються наступні цілі:

      • Забезпечується перехід від аналізу до проектування шляхом визначення з елементів і механізмів аналізу елементів і механізмів проектування;

      • Підтримується цілісність і несуперечність архітектури шляхом інтеграції нових елементів проекту, визначених в поточній ітерації, з вже існуючими та повторного використання доступних елементів проекту.

      • Здійснюється плавний перехід від проектування до реалізації;

      Аналіз поведінки. Ця діяльність включає аналіз ВІ, визначення елементів проекту і огляд проекту. Ця діяльність має на меті перетворення описів поведінки у вигляді ВІ в набір елементів проекту (класи, відносини, операції та ін.)

      Проектування компонентів. Цілі даної діяльності полягають у:

      • Визначенні та уточненні елементів проекту шляхом докладного опису того, як ці елементи реалізують необхідну поведінку.

      • Визначенні та уточненні реалізації ВІ на основі нових елементів проекту.

      • Контроль і рецензуванні проекту по мірі його розвитку.

      Проектуються ВІ, підсистеми, класи та компоненти ПС. Точно визначення інтерфейсів компонентів та їх реалізація.

      Проектування БД. Дана діяльність виконується для проектів, що використовують бази даних. Вона включає:

      • Визначення персистентних (постійно зберігаються) класів;

      • Проектування структури БД для зберігання таких класів;

      • Визначення механізмів і стратегій збереження і доступу до збережених даними, що задовольняють вимогам до продуктивності і надійності ПС.

      Аналіз і проектування пов'язує управління вимогами і реалізацію. У цьому технологічному процесі створюється модель проектування. Одне з її уявлень - логічна модель - відбиває декомпозицію ПС в набір логічних елементів (класи, підсистеми, взаємодії). Процедурне уявлення відображає ці елементи в процеси і підпроцеси системи. Представлення розгортання відображає ці процеси в набір вузлів обчислювального комплексу, на яких вони виконуються.

      Реалізація

      Цілі процесу реалізації

      Основні цілі процесу можна сформулювати наступним чином:

      • Визначити структуру коду у вигляді рівнів;

      • Реалізувати компоненти, класи та об'єкти;

      • Провести блокове тестування компонент;

      • Інтегрувати розробки, виконані окремими розробниками, в єдину виконувану систему.

      У процес реалізації не включено тестування всієї ПС, для якого в RUP передбачений окремий процес (див. наступну статтю).

      Особливості процесу реалізації

      RUP припускає поелементну інтеграцію протягом всього життєвого циклу. Це означає, що коди пишуться невеликими блоками, після чого вони об'єднуються в єдине ціле шляхом поступового додавання блоків. Це спрощує процес локалізації помилок. Передбачено два рівні інтеграції - інтеграція результатів роботи групи розробників у підсистему та інтеграція підсистем в ПС. Інтеграція відбувається в кожній ітерації відповідно до плану ітерації, де визначені ВІ, що проектуються і реалізуються в цій ітерації. Таким чином, план ітерації визначає класи, які будуть реалізовані в цій ітерації.

      У фазі конструювання створюється еволюційний прототип системи, який з часом розвивається в кінцеву ПС. Це прототип використовується для демонстрації фрагментів ПС замовнику і керівництву. За результатами подання прототипу можна отримати зауваження, які дозволяють уточнити, змінити або доповнити вимоги до ПС. RUP декларує можливість створення, крім еволюційних, поведінкових одноразових прототипів для проведення певних досліджень, що стосуються функціональних можливостей системи.

      У RUP декларується необхідність відповідності моделі та програмного коду. При цьому допускається можливість зміни коду з подальшою переробкою моделі, яка забезпечувала б необхідну відповідність. Для цієї мети використовують інструментальні засоби, що включають можливості автоматичного реінжинірингу Методика реінжинірингу представлена ​​в статті «Реінжиніринг програмних систем».

      Ролі

      Конструктор (кодер) розробляє компоненти й класи, виконує блокове тестування.

      Системний інтегратор виконує інтеграцію елементів в програмні конструкції (систему та підсистеми).

      Архітектора визначається структуру реалізації (організацію рівнів і підсистем).

      Рецензент коду перевіряє якість програмного коду і його відповідність стандартам проекту.

      Артефакти

      Підсистема реалізації - це набір компонентів та інших підсистем реалізації, використовуваних для утворення моделі реалізації. Це поняття дозволяє ієрархічно представити модель реалізації.

      Компонент частина програмного коду (див. статтю «Компонентно-базована розробка»).

      План інтеграції документ, що визначає порядок реалізації компонентів і підсистем.

      Процес

      Створення моделі реалізації. Ця діяльність виконується у фазі розвитку. Метою її є побудова моделі реалізації, яка дозволить найкращим чином виконати розробку та кодування. При цьому кінцевий продукт буде створюватися за допомогою послідовно укрупнюються прототипів.

      Планування ітерації. Для кожної ітерації треба визначити, які підсистеми повинні бути реалізовані в цій ітерації і порядок їх інтегрування. За яку підсистему відповідає конкретний конструктор, що визначає порядок реалізації класів.

      Реалізація компонентів. Виконується написання вихідного коду програм, їх компіляція, формування виконуваного коду і блочне тестування. Блокове тестування виконує сам кодіровщік. Це, по суті, автономна налагодження розроблених програм. При виявленні помилок у вихідний код вносяться зміни, після чого зазначені дії повторюються. Після завершення блокового тестування перевіряється якість вихідного коду і його відповідність прийнятим стандартам проекту.

      Інтеграція підсистем. Якщо підсистема розробляється групою виконавців, виконується інтеграція компонентів, розроблених усіма членами групи. Інтеграція підсистеми завершується створенням набору програмних конструкцій підсистеми, кожна з яких тестується окремо.

      Інтеграція системи. Виконується інтеграція системи шляхом послідовного додавання до неї нових підсистем, створених в рамках поточної ітерації. Інтеграція підсистеми завершується створенням набору програмних конструкцій підсистеми, кожна з яких тестується окремо. Для тестування системи в RUP передбачений окремий процес.

      Тестування

      Тестування - це процес, що дозволяє оцінити якість виробленого продукту. Якісний програмний продукт повинен відповідати пропонованим до нього вимогам як функціональним, так і нефункціональним. ПС повинна реалізовувати всі необхідні ВІ і не мати дефектів - відмінностей реально існуючих властивостей або поведінки від необхідних. Крім того, ПС повинна мати властивості надійності (мають бути відсутні зависання, аварійні відмови тощо), безпеки, забезпечувати потрібну продуктивність, бути зручною в експлуатації, розширюваної і т. д. Таким чином, тестування являє собою процес аналізу ПС, спрямований на виявлення дефектів і на оцінку властивостей ПC.

      Цілі процесу тестування

      Метою тестування є оцінка якості програмного продукту шляхом

      • Перевірки взаємодії компонентів;

      • Перевірки правильності інтеграції компонентів;

      • Перевірки точності реалізації всіх вимог і виявлення дефектів.

      Особливості процесу тестування у RUP

      Тестування - це ітеративний процес, що виконується у всіх фазах життєвого циклу. Робота над тестами починається з самого початкового етапу виявлення вимог до майбутнього продукту і тісно інтегрується з поточними завданнями. На кожну ітерацію визначається мета тестування та методи її досягнення. В кінці кожної ітерації визначається, наскільки ця мета досягнута, чи потрібні додаткові випробування, чи не слід змінити принципи та інструменти тестування.

      Кожен знайдений дефект реєструється в базі даних проекту з описом ситуації, в якій він знайдений. Аналітик визначає, чи дійсно це дефект і чи не є він повтором виявленого раніше дефекту. Знайденому дефекту присвоюється пріоритет, що визначає важливість виправлення. Конструктор, відповідальний за розробку підсистеми, компоненти або класу, або інший виконавець, призначений керівником, приступає до усунення дефекту. Порядок виправлення дефектів регулюється їхніми пріоритетами. Тестувальник повторює виконання тестів і переконується (або не переконується) в усуненні дефекту.

      Ролі

      Розробник тестів відповідає за планування, розробку і реалізацію тестів. Він створює план і модель тестування, методики випробувань (див. нижче) і виконує оцінку результатів тестування.

      Тестувальник (випробувач) відповідає за виконання системного тестування. У його обов'язки входить налагодження та виконання тестів, оцінки виконання тесту, відновлення після помилок, реєстрація виявлених дефектів.

      Артефакти

      У процесі тестування створюються такі документи:

      План тестування - документ, що визначає стратегію тестування в кожній ітерації. Він містить опис цілей і задач тестування в поточній ітерації, а також стратегій, які будуть використовуватися. У плані зазначається, які будуть потрібні ресурси, і наводиться перелік тестів.

      Модель тестування - це уявлення того, що і як буде тестуватися. Модель включає набір контрольних завдань, методик випробування, сценаріїв випробувань та очікуваних результатів (test cases), тестових скриптів та описів взаємодій тестів.

      • Контрольна завдання - набір тестових даних, умов виконання тестів і очікуваних результатів.

      • Методика випробувань - документ, що містить вказівки щодо налаштування та виконання контрольних завдань, а також з оцінки одержуваних результатів.

      • Сценарій тестування - це спрощений опис тесту, включаючи вихідні дані, умови та послідовності виконання дій та очікувані результати.

      • Тестовий скрипт є програмою, що виконується при автоматичному тестуванні за допомогою інструментальних засобів тестування.

      • Опис взаємодії тестів являє собою діаграму послідовностей або кооперацій, яка відображатиме упорядкований у часі потік повідомлень між компонентами тестів і об'єктом тестування.

      Результати тестування і дані, отримані в процесі виконання тестів.

      Модель робочої навантаження використовується для моделювання зовнішніх функцій, виконуваних кінцевими користувачами, обсягів цих функцій і навантаження, створюваної цими функціями. Модель призначається для проведення навантажувального і / або стресового тестування, що імітує роботу системи в реальних умовах.

      Дефекти - це описи виявлених при проведенні тестування фактів невідповідності системи пропонованим вимогам. Вони являють собою вид запитів на внесення змін.

      Процес

      Роботи з тестування виконуються в кожній ітерації у всіх фазах, але цілі й завдання в різних фазах проекту істотно різні.

      Фаза входження в проект. У цій фазі виконується підготовка до тестування. Вона включає:

      • Створення плану тестування, що містить вимоги до тестів і стратегії тестування. Може створюватися єдиний план для всіх видів тестування (функціональне, навантаження і т. д.) або окремі плани для кожного виду.

      • Аналіз обсягу тестування.

      • Формулювання критеріїв якості та завершення тестування.

      • Установку та підготовки до роботи інструментальних засобів тестування.

      • Формулювання вимог до проекту розробки ПС, що визначаються потребами тестування.

      Фаза розвитку. У ітераціях цієї фази починається побудова моделі тестування і пов'язаних з нею артефактів. Оскільки в цій фазі вже присутня модель ВІ можна починати проектувати сценарії тестування. У той же час недоцільно виконання тестів, оскільки зазвичай в цій фазі ще не існує завершених фрагментів ПС. Виконуються наступні діяльності:

      • Створення плану тестування для кожної ітерації.

      • Розробка сценаріїв тестування.

      • Створення заготовок тестових скриптів.

      • Розробка контрольних завдань.

      • Розробка методики випробувань.

      • Розробка моделі робочого навантаження.

      Фаза конструювання. У цій фазі з'являються завершені фрагменти систем і прототипи, які повинні тестуватися. При цьому практично в кожній ітерації перевіряються всі модулі (як раніше розроблені і протестовані, так і нові, додані до поточної ітерації). Тести, застосовані в попередніх ітераціях, використовуються і на подальших для регресійного тестування, тобто для перевірки того, що раніше реалізована функціональність системи збереглася в новій ітерації. Виконуються наступні діяльності:

      • Створення плану тестування для кожної ітерації.

      • Уточнення та доповнення моделі тестування.

      • Виконання тестів.

      • Опис виявлених дефектів.

      • Опис результатів тестування.

      • Оцінка результатів тестування.

      За результатами тестування вносяться зміни в програмний код з метою усунення виявлених дефектів, після чого тестування виконується повторно.

      Фаза розгортання. У ітераціях цієї фази виконується тестування всієї ПС як програмного продукту. Виконувані діяльності аналогічні деятельностям попередньої фази. Виявлення дефектів визначає необхідність внесення змін і повторного тестування. Ітераційний процес повторюється до тих пір, поки не будуть виконані критерії завершення тестування.

      Оцінка результатів тестування проводиться на основі метрик тестування, дозволяють визначити якість тестованої ПС і самого процесу тестування.

      Інструментальна підтримка

      Оскільки ітераційний процес тестування передбачає багаторазове повторення тестів, ручне тестування стає неефективним і не дозволяє ретельно оцінити якість програмного продукту. Особливо це стосується навантажувального і стресового тестування, де потрібно моделювати робоче навантаження і накопичується значний обсяг даних. Вихід полягає у застосуванні інструментальних засобів, що підтримують автоматизацію складання і виконання тестів.

      Процеси підтримки

      RUP передбачає три процеси підтримки:

      • Управління проектом;

      • Управління конфігурацією;

      • Управління середовищем.

      Управління проектом. Цілі

      Основною метою процесу управління проектом є забезпечення керівництва проектом, спрямоване на успішну здачу програмного продукту. RUP акцентує увагу на плануванні життєвого циклу та окремих ітерацій, управлінні ризиками, спостережливості ходу проекту та метриках проекту.

      Планування передбачає створінь двох видів планів:

      • План фаз - великомасштабний план проекту, що показує основні віхи життєвого циклу (дати завершення великих етапів - фаз, випуску еволюційних прототипів і т. д.) і необхідні ресурси. Він створюється на початку фази дослідження та оновлюється по мірі необхідності.

      • План ітерацій створюється для кожної ітерації і призначається для визначення і розподілу завдань між учасниками проекту.

      Ризиком будемо називати все те, що може стояти на шляху до успіху проекту і на даний момент є невідомим або невизначеним. Головна ідея управління ризиками полягає в тому, що не потрібно пасивно чекати, поки ризик стане проблемою, але потрібно завчасно визначати лінію поведінки. Управління ризиками означає визначення та оцінку ризиків, прийняття лінії поведінки, спрямованої на усунення, зниження ймовірності ризику, а також вибір дій на випадок реалізації ризику.

      Для контролю та управління проектом використовуються вимірювання. Вони проводяться для того щоб встановити, наскільки віддалене поточний стан проекту від поставленої мети, спланувати роботи і визначити, як можна підвищити ефективність процесу.

      Управління проектом. Діяльності

      Відкриття нового проекту. Ця діяльність виконується тільки в першій ітерації. Здійснюється ініціалізація проекту, визначаються і оцінюються ризики, розробляється бізнес-план. Мета - переклад проекту в стадію, коли можливе прийняття рішення про продовження або про відмову від проекту.

      Оцінка області дії проекту і ризиків. Метою є перегляд та уточнення можливостей і характеристик проекту, а також пов'язаних з ним ризиків.

      Створення плану розробки ПС. Створюється план розробки ПС, що включає перелік ризиків, плани вимірювань, управління ризиками, вирішення проблем, прийняття продукту. Визначається структура і ресурси проекту. Розробляється план фаз проекту.

      Планування ітерації. Розробляється план чергової ітерації, уточнюється і коректується бізнес-план і план розробки ПС. План ітерації докладно описує, що має відбутися за час ітерації. Він визначає виконавців і виконувані ними роботи. При створенні плану ітерації необхідно:

      • Сформуліровть об'єктивні критерії успіху ітерації. Вони будуть використовуватися при її оцінці;

      • Визначити конкретні, вимірні артефакти, які потрібно розробити або змінити, а також виконуються для цього роботи;

      • Використовувати типову итерационную декомпозицію робіт для реальних дій, які повинні бути зроблені;

      • Використовувати кошторис при визначенні тривалості та обсягу робіт для кожного виду діяльності, утримуючи всі значення в межах бюджету.

      Спостереження і контроль. Ця діяльність включає розподіл робіт і створення графіка робіт, спостереження за станом проекту, обробку виключних ситуацій, та створення звіту про стан. Виконується обробка запропонованих змін і включення їх у графік робіт поточної або наступних ітерацій, здійснюється спостереження за активними ризиками, дається оцінка прогресу і якості проекту. У RUP постійно виконуються оцінки стану проекту є основою для вирішення різних проблем і управління ризиками проекту. Якщо команда розробників виявила проблему, призначається співробітник, відповідальний за її вирішення, і визначається дата, коли проблема повинна бути дозволена. Хід процесу повинен регулярно контролюватися, а оновлення повинні виконуватися в міру необхідності.

      Управління итерацией. Метою цієї діяльності є отримання достатніх для виконання ітерації ресурсів, поділ необхідних робіт, оцінка результатів ітерації.

      Завершення фази. Виконуються роботи, завершальні виконання фази. Даються відповіді на такі основні питання:

      • Чи вирішені всі основні проблеми попередньої ітерації?

      • Чи відомо стан усіх основних артефактів (див. нижче управління конфігурацією)?

      • Розглянуто чи всі проблеми розгортання?

      При задовільному стані проекту видається дозвіл на перехід до наступної фази.

      Завершення проекту. Керівник проекту готує проект до завершення. Готується заключна оцінка стану. При успішній здачі проекту замовник отримує програмний продукт у користування. Вивільняють ресурси можуть бути перерозподілені (використані в інших проектах).

      Управління конфігурацією і змінами. Цілі

      Метою управління конфігурацією і змінами є підтримка цілісності артефактів з урахуванням можливості внесення до них змін відповідно до запитів на зміни. Цей допоміжний процес поширюється на весь життєвий цикл програмного продукту і складається з трьох окремих процесів.

      Управління конфігурацією (Configuration management).

      Процес управління конфігурацією (КК) пов'язаний з визначенням артефактів, залежностей між ними і конфігурацій, що є несуперечливими множинами взаємопов'язаних артефактів. Сюди ж належать питання розподілу робочих середовищ між учасниками проекту з метою запобігання непотрібного дублювання документів. КК декларує, що всі артефакти підпорядковуються версионном управління. У міру розвитку проекту в кожного артефакту з'являються безліч версій. Всі вони зберігаються в архіві проекту, причому ведеться історія змін, в якій вказується причини і цілі створення кожної версії кожного артефакту. Записану в архів проекту версію не можна змінити, можна лише створити нову версію. Крім того, знання про залежності між артефактами дозволяють точно повторювати дії при створенні наборів артефактів (наприклад, при складанні програми з окремих файлів). Створення версій та зв'язків підтримується за допомогою інструментальних засобів КК.

      КК дозволяє:

      • виключити можливість втрати артефактів,

      • забезпечити можливість «повернення назад» у випадках, коли прийняті рішення і отримані при їх реалізації версії артефактів не влаштовують замовника або розробників проекту,

      • гарантувати точне повторення дій над групою пов'язаних артефактів у ітераціях,

      • уникати дублювання артефактів і пов'язаної з цим можливості привнесення додаткових дефектів,

      • підтримувати наблюдаемость ходу виконання робіт за проектом шляхом надання потрібної інформації.

      Управління внесенням змін

      Діяльності цього процесу спрямовані на збір і збереження запитів на внесення змін, що поставляються як учасниками розробки ПС, так і зовнішніми сторонами. Запити на внесення змін можуть з'являтися з різних причин (виправлення дефекту, поліпшення параметра якості продукту, наприклад, продуктивності, завдання додаткових вимог і т. д.) Кожен запит на внесення змін зберігається в базі даних проекту і може перебувати в різних станах в залежності від ходу виконання робіт за цим запитом (новий, зареєстрований, прийнятий, завершений і ін.) Стани запитів змінюються учасниками проекту відповідно до виділених правами. Під час роботи з запитом до нього додається інформація (наприклад, спочатку це може бути тільки опис дефекту, потім додається результати аналізу, вказуються уражені артефакти, призначається виконавець). Із запитом може бути пов'язаний пріоритет, що дозволяє визначити порядок виконання робіт за запитами на зміни.

      Управління станом і вимірами

      Цей процес пов'язаний з управлінням проектом і спрямований на надання інформації, корисної для оцінки:

      • Стани, прогресу, загальних тенденцій та якості продукту;

      • Витрат і витрат;

      • Проблемних областей, що вимагають уваги;

      • Того, що зроблено і що необхідно зробити.

      Вся необхідна інформація знаходиться в базі даних та архіві проекту. Керівник робіт оцінює стан справ шляхом безпосереднього перегляду запитів, історії версій артефактів або на основі аналізу різних звітів, що формуються інструментальним засобом КК. Аналіз дозволяє керівнику оцінити наявні ресурси і прийняти необхідні управлінські рішення.

      Діяльності

      Планування конфігурації проекту і управління змінами. Описуються всі види діяльності, пов'язані з КК, які треба виконати. Описується процес контролю над змінами.

      Створення середовища КК. Метою цієї діяльності є створення робочого середовища, в якій будуть доступні всі артефакти, буде забезпечена розробка, інтеграція і архівування продукту.

      Створення робочої середовища виконавців. У межах своєї робочої середовища виконавець отримує доступ до артефактів проекту, має можливість вносити до них зміни і пропонувати внесення змін у проект в цілому. Зміни, зроблені окремими виконавцями, направляються у робоче середовище інтеграції.

      Управління версіями. При записі артефакту в архів проекту формується його нова версія. Управління версіями передбачає обов'язкове зазначення причин і цілей створення версії. При виборі артефакту з архіву можна вказати конкретну версію.

      Управління запитами на внесення змін. Метою цієї діяльності є забезпечення послідовного внесення змін до проекту та інформування про стан продукту, його зміни і про вплив змін на вартість і терміни виконання проекту.

      Спостереження за станом конфігурації. Спостережуваність процесу розробки забезпечується шляхом доступу керівництва проекту до збережених артефактів і запитам на зміни, а також шляхом надання звітів про стан конфігурації. При цьому інструментальні засоби, що підтримують управління конфігурацією і змінами, можуть виконувати необхідні виміри. Наприклад, можна показати відсоток завершених запитів, кількість відкритих запитів високого пріоритету і т. д.

      Управління середовищем. Цілі

      Багато видів діяльностей, передбачені RUP, можуть бути автоматизовані за допомогою інструментальних засобів, що дозволить уникнути найбільш трудомістких, напружених і схильних до помилок аспектів розробки ПС.

      Мета процесу управління середовищем - процедурна та інструментальна підтримка організації, що розробляє ПС. Вона включає:

      • Вибір і придбання інструментальних засобів;

      • Налаштування інструментальних засобів під вимоги організації-розробника;

      • Конфігурування процесу;

      • Удосконалення процесу;

      • Створення технічних служб підтримки.

      Ролі та артефакти

      Основним виконавцем процесу є технолог. У його обов'язки входить конфігурування процесу перед запуском проекту та удосконалення процесу в ході проектних робіт. Підтримка апаратної і програмної середовища розробки лягає на плечі системного адміністратора.

      Головним створюваним артефактом є план розробки, що описує процес, який використовується в даному проекті. У ньому вказується, які артефакти, які дозволяються за RUP, будуть використовуватися в проекті і яким чином.

      Діяльності

      Підготовка середовища до реалізації проекту. Виконується оцінка поточного стану організації-розробника та наявної інструментальної підтримки. Створюється попередній план розробки. Складається перелік інструментальних засобів, які передбачається використовувати при розробці. Складається перелік шаблонів для виробництва основних артефактів.

      Підготовка середовища до ітерації. Виробляється доповнення і уточнення плану розробки, виконується підготовка та налаштування інструментальних засобів, які будуть використовуватися в ітерації. Складається набір шаблонів для артефактів, що створюються в ітерації. Здійснюється підготовка співробітників до використання інструментальних засобів.

      Підготовка керівних директив. Для кожного основного технологічного процесу готується набір директив на основі аналізу проблем і дефектів попередніх ітерацій.

      Переваги та недоліки компанії-розробника перед окремим розробником

      Тепер, перерахуємо переваги та недоліки компанії-розробника перед окремим розробником.

      Переваги компанії-розробника перед окремим розробником:

      • Компанія може "тягнути" великі і дуже великі проекти. Окремий ж розробник великий проект може не осилити фізично.

      • У компанії, як правило, працює група людей з різною освітою, тим самим доповнюючи і розвиваючи знання один-одного. У компанії-розробника переплітаються знання людей різних шкіл. Окремий ж розробник вариться у своєму соку. Основне джерело знань у нього - книги та Інтернет.

      • Стандартизація вихідного тексту в компанії значно вище, ніж у окремого розробника, тому що в компанії працює група розробників.

      • Технічно, компанії вище оснащені, ніж один розробник.

      • Джерел інформації у компанії більше, ніж у окремого розробника. А це відбивається на результаті - розробляється програмі.

      • У компанії значно вище досвід роботи з різними проектами, ніж в окремої людини.

      • У компаніях більше напрямів розвитку програмних засобів.

      • Компанія може надати комплексний підхід при наявності фахівців різних напрямків.

      • Все, що витрачається за договором з компанією йде на витрати. У той час, як окремий програміст найчастіше працює на зарплату.

      • Швидкість розробки компанії вище, ніж в однієї людини, тому що можна підключати до проекту декількох чоловік.

      • Розробляючи програмний продукт, компанія тестує його і пише документацію. Окремий ж розробник часто лінується це робити. А якщо не лінується і намагається писати документацію або тестувати, то розвиток програмного продукту тимчасово припиняється (на час написання документації або тестування).

      • Компанія не звільниться.

      • Компанія не помре і її не переїде автобус.

      • Компанія не захворіє і з цієї причини не призупинить підтримку.

      • У компанії завжди будуть люди, які зможуть продовжити справу.

      • Компанія бере на себе головний біль з пошуку високо-кваліфікованих і відповідальних програмістів.

      • Компанія стежить за технологіями та тенденціями розвитку програмного забезпечення.

      Недоліки компанії-розробника перед окремим розробником:

      • окремий розробник обходиться дешевше, тому що у нього немає необхідності орендувати повішення, платити комунальні платежі, немає необхідності в рекламі та в інших витратах, присутніх у будь-якому підприємстві. Компанії ж необхідно оплачувати орендні платежі, податки, комунальні платежі, зарплату (а в програмістів вона ну дуже велика) і т.д.

      • програміст-одинак ​​легше йде на поступки підприємству, тому що сам відповідає за свій добробут. Компанія-розробник не може дозволити собі піти часто на поступки на шкоду компанії, так як це призведе до її банкрутства.

      • окремий розробник може постійно бути присутнім на заданому підприємстві, працюючи на ньому, як співробітник, а компанія не може такого дозволити. Навіть надаючи людини для обслуговування підприємства, компанія час від часу повинна викликати його до офісу, навчати.

      Чому компанії-розробники не люблять реінжиніринг

      Не багато компаній реально займається реинжинирингом програм. Якщо Ви замовите реінжиніринг, то найвірогідніше Вам скажуть: <легше розробити новий програмний продукт> і підуть саме цим шляхом. У результаті Ви отримаєте іншу програму, яка може, вирішить ті проблеми, які були, але яка вже, можливо, буде володіти новими проблемами ... І не обов'язково програмного рішення ...

      Чому ж так не охоче компанії беруться за реінжиніринг?

      Ось вони причини:

      • Програмісти не люблять розбиратися в чужому вихідному тексті. Це все одно, що розбиратися в каракулі, написаних іншою людиною (і часто лівою ногою).

      • Реінжиніринг найчастіше дорожче розробки нового програмного забезпечення. Оскільки потрібно переламати обмеження попередніх версій, але при цьому дотримуватися сумісність за зростанням версій. Тобто Надати можливість конвертувати дані зі старих версій у нову.

      • Реінжиніринг не може зробити програміст низької та середньої кваліфікації. Навіть професіонали часто не можуть якість реалізувати його. Для грамотного реінжиніринг потрібні експерти - програмісти з великим досвідом переробки програм і знанням різних технологій.

      • Виправляти чужу програму - велика відповідальність, тому що можна не помітити або не зрозуміти призначення якихось алгоритмів, реалізованих попереднім програмістом.

      • Програмісту може знадобитися розбиратися з технологіями, з якими він не працює, але які використовуються в програмі.

      Рентабельність реінжинірингу

      Найчастіше, реінжиніринг програм обходиться дорожче, ніж розробка програми. Причиною цього є те, що потрібно дотримуватися сумісність нової версії зі старої або ж реалізовувати конвертер старих даних в нові, а так само необхідність обходити обмеження, нав'язані попередніми версіями програм.

      Розглянемо два приклади реінжинірингу з життя.

      1-й приклад: На одному великому підприємстві з великою кількістю філій працювала програма, розроблена штатним програмістом. На деякому етапі, даний програміст не зміг продовжувати роботу. У результаті, на підприємстві було 2 версії програми: одна стара версія, що працює на BDE і одна нова, але не до кінця працює і доступ до даних в якій був зовсім інший: компоненти прямого доступу. Стару версію намагалися встановити на філіях, але без успішно, а в центральному офісі вона працювала з великими помилками. Через що, виникали великі черги із замовників і в результаті, компанія зазнавала великих збитків. Програма була розроблена на Delphi, з використанням сервера бази даних Interbase 6. Таблиць в програмі було 10-11 штук, а збережених процедур і тригерів практично не використовувалося.

      Завдання: Розробити нову версію програми в якій би були реалізовані нові потреби компанії, виправлені помилки, що виникають у центральному офісі та на філіях і яка б змогла працювати на філіях. Так само важливо, щоб програма швидко працювала і не створювалася черга із замовників. Передбачити значно більший сервіс, ніж є в даній програмі, а в подальшому забезпечити систему безпеки на належному рівні програми і обмін даними між філіями.

      Рішення: Технологія побудови первинного додатку повністю задовольняє всім поточним і майбутнім потребам, тому змінювати ні засіб розробки, ні базу даних немає необхідності. Таблиць у проекті не багато, форм теж, тому, можна спробувати не створювати програму заново (особливо, враховуючи, що програма вже працює), а взятися за реінжиніринг програми. Вихідний текст програми написаний порівняно грамотно (хоча і було багато зауважень), тому повністю переписувати текст не довелося.

      У даному проекті реінжиніринг пройшов цілком успішно. І програма пішла на подальший розвиток.

      2-й приклад: Один інститут більш 10 років розробляв програму розрахунку, CAD-систему. Програма була написана одним інженером, який сам вивчив Delphi і написав програму, взявши алгоритми з програми на Fortran. У якості бази даних використовувалися dbf-файли. Вихідний текст програми написаний дуже погано, без форматування, без найменування компонент людськими назвами (назви, часто взагалі не змінювалися і залишалися такими, як призначав Delphi). Крім того, система складалася з низки dll (на кожну форму), вихідний текст яких знаходився в різних каталогах, а файли юнітів називалися однаково. Проекти креслень зберігалися в окремих каталогах окремих баз даних.

      Завдання: Привести програму до комерційного виду. Організувати систему захисту від копіювання. Організувати систему безпеки на сучасному рівні. Переробити базу даних на Firebird. Організувати можливість імпорту / експорту інформації. Збільшити можливості графічного редактора (наприклад, відкат змін). А так само багато що інше такого ж типу.

      Рішення: Оригінальний текст довелося повністю переформатувати. Проекти об'єднувати в один exe-файл, а однакові юніти видаляти. Довелося побудувати схему бази даних. У результаті виявилося, що база даних надлишкова, а структура безграмотно складена. Систему від копіювання організували. Але переклад в Firebird виявився практично не можливим, економічно не вигідним. Програма постійно збоїла. Надійність її була дуже низька.

      У результаті вийшов приблизно такий графік рентабельності обслуговування + розробки програми (по вертикалі - у тисячах $, по горизонталі - у кількості комп'ютерів, що реально працюють з програмою):

      З графіка бачимо, що на початковому етапі, реінжиніринг програми обходиться дешевше. Але, в процесі експлуатації, підприємство почало б втрачати величезні гроші з-за поганої роботи програми.

      Дана система не працювала ніде. Тому ми порахували, що в даному випадку повна переробка програми виявилася б більш вигідною в результаті, ніж реінжиніринг програми.

      Переробка програми стоїть на початковому етапі значно більше, але в результаті виходить стабільно працюючий програмний продукт і з значно більш дешевим обслуговуванням.

      Список використаної літератури

      1. []

      2. [Http://www.newlinestudio.ru/ArticleReengirinPO.php]

      3. [Http://www.codenet.ru/progr/other/reengineering.php]

      4. [Http://ru.wikipedia.org]

      45


      Посилання (links):
    • http://www.newlinestudio.ru/ArticleReengirinPO.php
    • http://www.codenet.ru/progr/other/reengineering.php
  • Додати в блог або на сайт

    Цей текст може містити помилки.

    Програмування, комп'ютери, інформатика і кібернетика | Реферат
    170.4кб. | скачати


    Схожі роботи:
    Легалізація програмного забезпечення
    Розробка програмного забезпечення
    Обслуговування програмного забезпечення
    Верифікація програмного забезпечення
    Верифікація програмного забезпечення
    Надійність програмного забезпечення
    Обслуговування програмного забезпечення
    Розвиток програмного забезпечення
    Захист програмного забезпечення
    © Усі права захищені
    написати до нас