Сдам Сам

ПОЛЕЗНОЕ


КАТЕГОРИИ







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





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

План

1. Стратегії конструювання ПЗ.

2. Інкрементна модель

Теорія:

1.Стратегії конструювання ПЗ.

Існує 3 стадії:

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

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

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

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

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

Стратегія конструювання ПЗ
1 –на початку визначені всі вимоги 2 – багато циклів конструювання 3 – проміжне ПЗ розповсюджується.  
3

Водоспадна так ні Ні
Інкрементна так ні Ні
Еволюційна ні так Так

 

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

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

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

1. Аналіз.

2. Проектування.

3. Кодування.

4. Тестування.

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

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

Приклад:

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



 

Контрольні запитання:

1. Три стадії стратегій конструювання ПЗ.

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

3. Що таке інкрементна модель?

4. Розробка ПЗ.

 

 

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

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

План

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

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

3. Моделі якості процесів конструювання ПЗ.

 

Теорія:

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

(Rapid Application Development)

RAD - це приклад інкрементної стратегії.

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

Етапи RAD моделі:

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

- яка інформація керує процесом;

- яка інформація генерується;

- хто її генерує;

- де інформація застосовується;

- хто обробляє інформацію.

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

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

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

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

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

Недоліки та обмеження:

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

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

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

 

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

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

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

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

1.Зменшення на 30% часу розробки ПП.

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

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

Недоліки моделі:

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

2.Підвищені вимоги до замовника.

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

 

3. Моделі якості процесів конструювання ПЗ

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

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

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

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

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

Рівні зрілості СMM :

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

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

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

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

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

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

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

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

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

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

 

Контрольні запитання:

1. Що таке RAD?

2. Етапи RAD моделі.

3. Недоліки та обмеження.

4. Що таке КОМ?

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

6. Недоліки моделі.

7. Найбільш відомі моделі стандартів.

8. На що орієнтована модель СMM?

9. Рівні зрілості СMM.

10. Відмінності між рівнями.

 

Мова UML.

План

 

1. Мова UML.

2. Види діаграм.

3. Призначення мови UML.

 

Теорія:

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

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

Переваги використання UML:

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

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

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

Види діаграм:

1.Діаграма варіантів використання USE case d-m

2.Діаграма класів Class d-m

3.Діаграма поведінки Behavior d-m

Діаграма станів Statechart d-m

Діаграма діяльності Activity d-m

Діаграма взаємодії Interaction d-m

а) Діаграма послідовності Sequnce d-m

б) Діаграма кооперації Collaboration d-m

4. Діаграма діаграма реалізації Implementation d-m

4.1. Діаграма компонентів Component d-m

4.2. Діаграма розгортування Deployment d-m.

Призначення мови UML:

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

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

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

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

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

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

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

 

Контрольні запитання:

  1. Що таке UML?
  2. Переваги використання UML.
  3. Призначення мови UML.

 

 









Что будет с Землей, если ось ее сместится на 6666 км? Что будет с Землей? - задался я вопросом...

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

ЧТО ТАКОЕ УВЕРЕННОЕ ПОВЕДЕНИЕ В МЕЖЛИЧНОСТНЫХ ОТНОШЕНИЯХ? Исторически существует три основных модели различий, существующих между...

Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем...





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


©2015- 2021 zdamsam.ru Размещенные материалы защищены законодательством РФ.