12. Методології розробки пз . Характеристика методології dsdm.

Метод розробки динамічних систем (Dynamic Systems Development Method, DSDM) - це головним чином методика розробки програмного забезпечення, що базується на концепції швидкої розробки додатків (Rapid Application Development, RAD). У 2007 році DSDM став основним підходом до управління проектом і розробки додатків[джерело не вказано 121 день]. DSDM - це ітеративний і інкрементний підхід, який надає особливого значення тривалого участі в процесі користувача/споживача. Мета методу - здати готовий проект вчасно і вкластися в бюджет, але в той же час регулюючи зміни вимог до проекту під час його розробки. DSDM входить в сімейство гнучкої методології розробки програмного забезпечення, а також розробок, що не входять у сферу інформаційних технологій.

13. Методології розробки ПЗ . Характеристика методології RAD. RAD припускає, що розробка ПЗ здійснюється невеликою командою розробників за термін близько трьох-чотирьох місяців шляхом використання інкрементного прототипування із застосуванням інструментальних засобів візуального моделювання та розробки. Технологія RAD передбачає активне залучення замовника вже на ранніх стадіях - обстеження організації, вироблення вимог до системи. Причини популярності RAD випливають з тих переваг, які забезпечує ця технологія.  Найбільш істотними з них є:  · Висока швидкість розробки;  · Низька вартість;  · Висока якість.  Остання із зазначених властивостей увазі повне виконання вимог замовника як функціональних, так і нефункціональних, з урахуванням їх можливих змін в період розробки системи, а також отримання якісної документації, що забезпечує зручність експлуатації та супроводу системи. Це означає, що додаткові витрати на супровід відразу після поставки будуть значно менше. Таким чином, повний час від початку розробки до отримання прийнятного продукту при використанні цього методу значно скорочується.  Основні принципи RAD · Інструментарій має бути націлений на мінімізацію часу розробки.  · Створення прототипу для уточнення вимог замовника.  · Циклічність розробки: кожна нова версія продукту грунтується на оцінці результату роботи попередньої версії замовником.  · Мінімізація часу розробки версії, за рахунок перенесення вже готових модулів і додавання функціональності в нову версію.  · Команда розробників повинна тісно співробітничати, кожен учасник повинен бути готовий виконувати декілька обов'язків.  · Управління проектом повинне мінімізувати тривалість циклу розробки.

14. Поняття архітектури програмного забезпечення. Принципи проектування.

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

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

Проектуванню зазвичай підлягають:

• Архітектура програмного забезпечення

• Компоненти ПЗ

• Користувацькі інтерфейси

В процесі проектування ПЗ застосовують різні моделі — блок-схеми, ER-діаграми, DFD тощо.

15. Якість архітектури. Особливості повторного використання коду.  Однією з характерних рис інженерної діяльності є використання готових рішень або деталей.  Компонентне розроблення (component development) - це метод побудови програмного забезпечення з конструкцій за каталогом - як композиції готових компонент. Йдеться не лише про порції програмного коду або програмні модулі. Повторне використання, ревикористання (reuse) - це використання для нових розробок будь-яких порцій формалізованих знань, здобутих під час реалізації завершених розробок програмних систем. Накопичений досвід розроблення систем програмного забезпечення може бути зафіксовано в різних формах, починаючи від конкретних параметризованих програмних модулів і кінчаючи програмними архітектурами та середовищами. Далі будемо називати повторно використовуваними компонентами (ПВК) елементи знань про минулий досвід розроблення систем програмування, якщо: а) їх можуть використовувати не лише їхні розробники; б) їх можна адаптувати для створення нових систем.

16. Архітектура CMF-системи. Стандарти і єдина архітектура інформаційних технологій. Існують добре вивчені і перевірені варіанти вирішення архітектурних проблем. Ці варіанти рішення носять назву «шаблони проектування» (Design Patterns).  Шаблони проектування існують для всіх основних типів завдань, що виконуються CMF-системою. Рішення цих завдань вимагають продуманої стандартизації (зрозуміло, в рамках проекту). Таких завдань декілька: • Обробка запиту ІС 1); • Організація предметної області ІВ; • Організація подання ІС; • Організація допоміжних підсистем; Обробка запиту Підсистема обробки запиту зіставляє запит клієнта з дією, що виконується системою. Запити до системи можуть бути досить «різношерстими». Самі механізми зіставлення і їх дії можуть змінюватися під час супроводження проекту. Ці вимоги диктують розробникам CMF-системи необхідність створення зручного механізму аналізу та обробки запитів.  Організація предметної області У кожної інформаційної системи є предметна область. Це набір термінів, об'єктів і правил, якими оперує додаток. Організація предметної області, одна з найскладніших завдань, яка сьогодні стоїть перед розробниками. У переважній більшості випадків функціонування предметної області забезпечують реляційні бази даних і об'єктно-орієнтовані технології відображення.  Організація подання Уявлення - це підсистема відображення даних. З її допомогою логіка предметної області відокремлюється від логіки відображення даних. Уявлення - це найстабільніша частина інформаційної системи. Відображення даних може мінятися дуже часто, на відміну від самих даних і методів їх обробки. Тому framework-система повинна надати зручні та гнучкі механізми роботи з логікою відображення. Для вирішення цього завдання використовуються шаблонні системи , чиє завдання полягає у відділенні логіки відображення і укладання її в окремі файли (шаблони відображення), які можна редагувати окремо від усіх інших частин системи. Завдяки цьому, роботу над проектом можна ефективно розпаралелити (Організація предметної області → програміст + адміністратор БД, Організація подання → верстальник + дизайнер).