при реінжинірингу
Як правило стверджується, що "легше розробити новий програмний продукт". Це пов'язано з наступними проблемами:
1. Звичайному програмісту складно розібратися в чужому вихідному коді
2. Реінжиніринг частіше всього дорожче розробки нового програмного забезпечення, тому що потрібно прибрати обмеження попередніх версій, але при цьому залишити сумісність з попередніми версіями
3. Реінжиніринг НЕ може зробити програміст низької і середньої кваліфікації. Навіть професіонали часто не можуть якісно реалізувати його. Тому потрібна робота програмістів з великим досвідом переробки програм і знанням різних технологій.
У той же час, якщо спочатку програма володіла суворої і ясною архітектурою, то провести реінжиніринг буде на порядок простіше. Тому при проектуванні як правило аналізується, що вигідніше провести реінжиніринг або розробити програмний продукт "з нуля".
В
Управління вимогами
В
Вимоги до ПС
Вимога - це характеристика або умова, якому повинна задовольняти ПС. p> Функціональні вимоги визначають дії, які повинна виконувати ПС, без обліку фізичних обмежень. Тим самим вони визначають поведінку системи при введення і виведення. Процес виявлення функціональних вимог вельми складний і трудомісткий. Це пояснюється такими причинами:
В· таких вимог до системи зазвичай багато,
В· замовник не завжди здатний чітко сформулювати, чого він хоче від системи,
В· вимоги в підсумковому документі мають бути викладені так, щоб вони однаково розумілися замовником і виконавцем і не допускали неоднозначності,
В· між функціональними вимогами можуть бути різні залежності, що ускладнюють керування ними в разі необхідності внесення змін.
Для подолання цих труднощів застосовується моделювання вимог. Модель вимог дозволяє, по-перше, встановити ієрархію вимог, що сприяє кращому розумінню людиною, по-друге, дає наочне графічне подання вимог і залежностей між ними, в третіх дозволяє зв'язати графічну форму представлення з текстовою, забезпечуючи людини повної інформацією.
Нефункціональні вимоги не описують поведінку програмної системи, але описують її атрибути або атрибути оточення. Нефункціональні вимоги не потрібно включати в модель вимог, але вони повинні бути точно сформульовані. Зазвичай нефункціональних вимог не буває багато, проте вони кардинальним чином впливають на вибір архітектури системи.
Управління вимогами - це досить складний і розтягнутий у часі процес. Він триває протягом більшої частини життєвого циклу, оскільки зміни можуть вноситися як під час розробки, так і після здачі системи на етапі дослідної експлуатації і при супроводі. Причини цього полягають у тому, що вимоги:
В· неочевидні,
В· виходять з багатьох джерел,
В· важко формулюються (мова неоднозначний),
В· складаються з безлічі різних деталей,
В· нерівнозначні,
В· пов'язані один з іншому,
В· лежать не тільки в функціональної області.
В· можуть змінюватися протягом розробки і при супроводі.
Цілі аналізу та моделювання вимог
Цілями аналізу і моделювання вимог є:
В· досягнення угоди між розробниками, замовниками і користувачами про те, що повинна робити ПС;
В· досягнення кращого розуміння розробниками того, що повинна робити система;
В· обмеження системної функціональності;
В· створення базису для планування розробки проекту;
В· визначення користувача інтерфейсу;
В· складання специфікації вимог.
Ролі
В· Системний аналітик - фахівець організації-розробника, який очолює і координує роботи з виявлення та моделюванню вимог.
В· Дизайнер ВІ - спеціаліст організації-розробника, який деталізує і уточнює моделі вимог.
В· Зацікавлені особи - люди, що мають інформацію.
В· Експерт - представник замовника, який бере участь у розробці моделі вимог.
В· Дизайнер користувальницького інтерфейсу - фахівець організації-розробника, який створює прототип інтерфейсу користувача ПС.
Артефакти
Для досягнення поставлених цілей передбачається створення наступних документів:
В· Попереднє угода - текстовий документ, який описує, що буде включено в ПС і що вирішено виключити, тобто, він обмежує системну функціональність. У ньому відбиваються побажання зацікавлених осіб, а також вказуються основні нефункціональні вимоги (наприклад, описується платформа реалізації, точність обчислень, час відгуку).
В· Модель вимог служить для досягнення угоди між замовником і розробниками, даючи можливість замовнику переконатися в тому, що система буде робити те, що вони очікують, а розробникам створити те, що потрібно. Модель вимог дозволяє, по-перше, встановити ієрархію вимог, що сприяє кращому розумінню людиною, по-друге, дає наочне графічне представлення вимог і...
