Т.С.П.П / Махинации с ТСПП / ТСПП / Іспит / опорные конспекты / Лекція 3 у оп

Лекція 3:

Тема: Методологія RAD. Основні принципи методології RAD. Структурний підхід до проектування ІС. Суть структурного підходу до проектування ІС.

План:

1. Методологія RAD.

2. Життєвий цикл ПЗ за методологією RAD

• фаза аналізу і планування вимог;

• фаза проектування;

• фаза побудови;

• фаза впровадження.

3. Суть структурного підходу до проектування ПЗ.

4. Принципи структурного програмування.

Одним з можливих підходів до розробки ПЗ в рамках спіральної моделі ЖЦ є та, що набула останнім часом широкого поширення методологія швидкої розробки застосувань RAD (Rapid Application Development). Під цим терміном розуміється процес розробки ПЗ, що містить 3 елементи:

• невелику команду програмістів (від 2 до 10 чоловік);

• короткий, але такий, що виконує виробничий графік (від 2 до 6 міс.);

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

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

Життєвий цикл ПЗ за методологією RAD складається з чотирьох фаз:

• фаза аналізу і планування вимог;

• фаза проектування;

• фаза побудови;

• фаза впровадження.

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

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

Після детального визначення складу процесів оцінюється кількість функціональних елементів системи, що розробляється, і ухвалюється рішення про розділення ІС на підсистеми, реалізації, що піддаються, однією командою розробників за прийнятний для RAD-проектів час - порядку 60 - 90 днів. З використанням CASE-засобів проект розподіляється між різними командами (ділиться функціональна модель). Результатом даної фази повинні бути:

• загальна інформаційна модель системи;

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

• точно визначені за допомогою CASE-засобів інтерфейси між підсистемами, що автономно розробляються;

• побудовані прототипи екранів, звітів, діалогів.

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

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

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

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

• проводиться аналіз використання даних;

• проводиться фізичне проектування бази даних;

• визначаються вимоги до апаратних ресурсів;

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

• завершується розробка документації проекту.

Результатом фази є готова система, що задовольняє всім узгодженим вимогам.

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

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

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

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

Основні принципи методології RAD:

• розробка приложеня ітераціями;

• необов'язковість повного завершення робіт на кожному з етапів життєвого циклу;

• обов'язкове залучення користувачів до процесу розробки ІС;

• необхідне застосування CASE-засобів, що забезпечують цілісність проекту;

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

• необхідне використання генераторів коду;

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

• тестування і розвиток проекту, здійснювані одночасно з розробкою;

• ведення розробки нечисленною добре керованою командою професіоналів;

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

Структурний підхід

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

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

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

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

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

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

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

• принцип несуперечності - полягає в обґрунтованості і узгодженості елементів;

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

Питання:

1. Життєвий цикл ПЗ за методологією RAD.

2. В чому полягають переваги та недоліки методології RAD.

3. Навести приклади застосування методології RAD.

4. В чому полягає суть структурного підходу до розробки ІС

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

6. Засоби, які використовуються в структурному аналізі.

Література:

1. 1. Левин В.И.История информационных технологий. Издательство: Интернет-университет информационных технологий - ИНТУИТ.ру », БИНОМ. Лаборатория знаний ». Серия: Основы информационных технологий », 2007 - 336 стр.

2. Галатенко В.А., Основы информационной безопасности. Издательство: Интернет-университет информационных технологий - ИНТУИТ.ру » Серия: Основы информационных технологий »,2008 - 208 стр.

3. Терехов А.Н. Технология программирования, БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2007

4. Скопин И.Н. Интернет-университет информационных технологий - ИНТУИТ.ру, 2004

5. Котляров В.П. Основы тестирования программного обеспечения. Интернет-университет информационных технологий - ИНТУИТ.ру, 2006

6. http://www.ergeal.ru/txt/archive/cs/oop/glava1.htm#32.

7. Н. Н. Непейвода. Стили и методы программирования. Курс лекций. Учебное пособие

8. Коноплева И.А., Хохлова О.А., Денисов А.В. Информационные технологии

9. Брайан У. Керниган, Практика программирования

10. Левин В.И .История информационных технологий. Издательство: Интернет-университет информационных технологий - ИНТУИТ.ру », БИНОМ. Лаборатория знаний ». Серия: Основы информационных технологий », 2007 - 336 стр.

11. Галатенко В.А., Основы информационной безопасности. Издательство: Интернет-университет информационных технологий - ИНТУИТ.ру » Серия: Основы информационных технологий »,2008 - 208 стр.

12. Терехов А.Н. Технология программирования, БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2007

13. Скопин И.Н. Интернет-университет информационных технологий - ИНТУИТ.ру, 2004 .

3