Модель швидкої розробки додатків RAD

Стратегії конструювання ПЗ. Інкрементна модель

1. Одноразовий підхід або водоспадна стратегія – лінійна послідовність етапів конструювання ПЗ. Прикладом являється КЖЦ.

2. Інкрементна стратегія – на початку процесу визначаються всі вимоги користувача та системні.

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

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

Інкрементна модель – це класичний приклад інкрементної стратегії, поєднує елементи водоспадної стратегії та макетування.

Розробка ПЗ – це послідовність інкрементів кожний з яких складається з:

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

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

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

2. Характеристики стратегії конструювання ПЗ.

(Rapid Application Development). Компонентно-орієнтована модель конструювання ПЗ. Моделі якості процесів конструювання ПЗ.

2. (Rapid Application Development). Компонентно-орієнтована модель конструювання ПЗ.

Якщо вимоги повністю визначені, а проектна область обмежена, то група розробників створює функціональну систему за 60-90 днів (викор. Компонентно-орієнтовне конструювання).

1. Бізнес моделювання – визначається інформаційний потік між функціями. Шукається відповідь на наступні запитання:

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

3. Моделювання обробки – визначаються перетворення об’єктів даних які забезпечують реалізацію функцій. Створюються описи обробки для додавання модифікації та видалення об’єктів даних.

4. Генерація додатку – RAD працює з програмними компонентами, які використовуються повторно або створює програмні компоненти, які будуть використовуватися повторно. Використовується утіліти автоматизації.

5. Тестування та поєднання – тестуються всі нові елементи.

Кожна функція ПЗ адресується кожній групі розробників, вона повинна бути завершена максимум за 90 днів.

1. Для великих проектів потрібні суттєві людські ресурси.

2. RAD застосовується лише для тих додатків, які можуть розбиватися на складові частини – модулі.

3. RAD не застосовується в умовах високих технічних ризиків, тобто при використанні нової технології.

2. Компонентно-орієнтована модель конструювання ПЗ

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

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

Переваги моделі (у порівнянні з спіральною моделлю):

2. Зменшення вартості програмної розробки до 70%.

3. Збільшення в 1,5 рази продуктивності розробки.

1. Відсутня достатня статистика ефективності моделі.

3. Труднощі контролю та керування часом розробки.

Найбільш відомі наступні моделі стандартів:

1) ISO 9001:2000 орієнтована на процеси розробки в будь-яких областях людської діяльності.

2) ISO/IEC 15504 спеціалізується на процесах програмної розробки, має високий рівень деталізації. Об’єм приблизно 500 сторінок.

3) СMM (Capability Maturity Module) модель зрілості процесу конструювання ПЗ.

Модель СMM орієнтована: на побудови системи постійного покращення процесів. В ній зафіксовані 5 рівнів зрілості та передбачений поетапний підхід до вдосконалення процесів.

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

2. Повторюваний рівень – для переходу на цей рівень треба ввести формальні процедури для виконання основних елементів процесу конструювання. Результати відповідають заданим вимогам та стандартам.

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

3. Визначений рівень – вимагає щоб всі елементи процесу були стандартизовані та задокументовані.

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

4. Керуючий рівень – в компанії приймаються кількісні показники якості процесу та ПП.

Основна відмінність від третього рівня: більш об’єктивна кількісна оцінка процесу та ПП.

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

Основна відмінність від четвертого рівня: технологія створення та супроводу ПП постійно покращується.

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

5. Переваги моделі (у порівнянні з спіральною моделлю).

UML - це стандарт, який підтримується групою по об’єктному програмуванню OMG (це громадська організація, яка була заснована 11 провідними компаніями по розробці ПЗ «з метою створення ринку компонентного ПЗ шляхом прискорення ведення стандартних об’єктних рішень»).

Стандарт UML постійно переглядається та вдосконалюється

1. Діаграми однозначні та добре задокументовані

2. Зберігається інтелектуальна власність архітектури системи.

3. Новим співробітникам простіше приєднуватися до проекту.

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

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

3. Опис мовою UML повинен підтримувати таке визначення моделей. яке не залежить від конкретних мов програмування та засобів проектування програмних систем (ПС).

4. Опис мовою UML повинен включати бази для розуміння загальних особливостей ООАП (об'єктно-орієнтований аналіз і проектування).

5. Заохочувати в розвиток ринку об’єктних інструментальних засобів.

6. Сприяти розповсюджуванню об’єктних технологій та відповідних понять ООАП.

7. Інтегрувати в себе найновіші та найкращі досягнення практики ООАП.

Живите по правилу: МАЛО ЛИ ЧТО НА СВЕТЕ СУЩЕСТВУЕТ? Я неслучайно подчеркиваю, что место в голове ограничено, а информации вокруг много, и что ваше право...

Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...

Система охраняемых территорий в США Изучение особо охраняемых природных территорий(ООПТ) США представляет особый интерес по многим причинам...

Что делает отдел по эксплуатации и сопровождению ИС? Отвечает за сохранность данных (расписания копирования, копирование и пр.)...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: