Назвати цілі і завдання програмної інженерії.

Базові поняття SWEBOK

Інститут інженерів електроніки та електротехніки та американське об’єднання комп’ютерних фахівців створив міжнародний факультет, що в свою чергу створив ядро занань SWEBOK. Ці зання поділились на 10 областей. Кожна область мала загальну схему опису. Вона включає методи, засоби та інструменти підтримки інженерної діяльності. Це ядро знань є основою проектування ПЗ. Області знань:

I. Основи програмних вимог

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

Вимоги виділяють:

1) Програмні(вимоги до процесу, до ОС, до платформи)

2) Функціональні (вони задають призначення системи)

3) Нефункціональні (задають умови виконання ПЗ)

4) Системні (вимоги до програмної системи)

Розділи області знань: інженерія вимог, виявлення вимог, аналіз вимог, специфікація вимог, управління вимогами.

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

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

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

III. Конструювання ПЗ

Це створення працюючого ПЗ із залеченням методів верифікації, кодування та тестування компонентів.

IV. Тестування ПЗ

Це процес перевірки роботи програми в динаміці, заснований на виконанні набору тестових даних.

V. Супровід ПЗ

Це сукупність дій із зазначенням (забезпеченням) роботи ПЗ, а також по внесенню змін у разі виявлення помилок.

VI. Управління конфігурацією

Це дисципліна ідентифікації компонентів системи, визначення функціональних і фізичних характеристик системи.

VII. Управління інженерією ПЗ

Керівництво роботами команди розробників ПЗ в процесі виконання плану роботи. Визначення критеріїв і оцінка якості з використанням методів управління, планування і контрольних робіт.

VIII. Процес інженерії РЗ

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

IX. Методи і засоби інженерії ПЗ

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

X. Якість ПЗ

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

2. Описати обгрунтувати потребу побудови діаграми потоків даних. Ким була запропонована?

Діаграма потоків даних дозволяє специфікувати як функції, так і дані, як обробляються. Вони показують потік даних від джерела до користувача через процеси, які кожен раз уточнюються поки не будуть елементарними. Ця діаграма вперше була запропонована у 1975 році Барданом, а в 79 році уточнена Гейном-Рессарсоном. На основі цих діаграм побудовані методології Йордана де Марка, Гейна-Сарсона. В основі методології лежить або підсистема, накопичувач даних або потік даних.

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

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

Накопичувач даних або сховище – абстрактний пристрій дле зберігання інформації.

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

Приклад діаграми потоків даних:

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

1) Якщо процес можна описати алгоритмом

2) Якщо процес виконує єдину логічну функцію перетворення вхідних даних у вихідні.

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

 

 

Назвати цілі і завдання програмної інженерії.

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

Головне завдання «Програмної інженеріїї» як інженерної дисципліни — здобуття теоретичних і професійно-практичних компетенцій в області технологій розробки програмних систем.

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

 

Переваги

ñ Можливість раннього виявлення помилок ще на етапах проектування.

ñ На кожному етапі підтримується цілісність проекту і проміжного продукту. В результаті текучість кадрів не складає проблеми, проект можна заморозити і відновити на будь-якому етапі.

ñ Можливість розділення роботи - різні етапи можуть виконуватися різними людьми.

ñ Можливе зручне планування і управління процесом, прогнозування термінів і витрат на реалізацію.

Недоліки

ñ Ідеальна схема недосяжна в реальному житті.

ñ Схема погано узгоджена з продовженням розробки і розширенням проекту.

ñ Розроблена в 70-і роки, коли процес виправлення коду був трудомістким, а можливості обчислювальних машин — обмеженими.

ñ Не дозволяє виділити абстракції, організувати доступ до спільних даних, розпаралеліти обчислювальні процеси, тощо

 

 

 

26. Обгрунтувати, для чого потрібні концептуальні моделі наочної області? Поясните методику їх побудови.

Концептуальна модель найбільш повно відповідає потребам проектування баз знань і побудована на низці принципів. Є дві великі області понять в концептуальній моделі. Обидві вони побудовані за принципом ієрархічного дерева. Перша область - це дерево типів даних, друга - дерево даних. Дерево типів описує структуру даних дерева даних, тому без дерева типів немає ніякої логічної цілісності дерева даних. Тепер дамо основні визначення концептуальної моделі.

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

 

 

27. Пояснити ітераційну («спіральну») модель ЖЦ ПЗ. Хто її запропонував?

Спіральна модель (86—90-ті роки) — загострює увагу на

початкових етапах ЖЦ: аналізі вимог, проектуванні специфікацій, попередньому й детальному проектуванні. На цих етапах перевіряється і обґрунтовується реалізованість технічних рішень створенням прототипів.

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

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

відміною спіральної моделіє можливість багаторазового повернення до стадії формулювання вимог до розробки з будь-якої стадії робіт, якщо виявиться необхідність внесення змін.

На рис. 2.2 подано зображення спіральної моделі розробки, в якій кожний виток спіралі відповідає одній з версій розробки. На кожній стадії розроблення аналізується потреба змін, а внесення змін на будь-якій стадії обов’язково починається з внесення змін до попередньо зафіксованих вимог.

Фахівці відзначають такі переваги спіральної моделі:

• накопичення і повторне використання програмних засобів, моделей і

прототипів;

• орієнтація на розвиток і модифікацію системи в ході її проектування;

• аналіз ризику і витрат у процесі проектування.

Діаграма станів

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

• Готовність
• Очікування
• Робота
• Зупинка

а подіями, які можуть спричинити зміну стану об’єкта можуть бути

• Створення об’єкта
• Об’єкт отримує повідомлення «очікувати»
• Клієнт надсилає запит на з’єднання мережею
• Клієнт перериває запит
• Запит виконано і перервано
• Об’єкт отримує повідомлення «зупинка»
• Тощо

Діаграма прецедентів — в UML, діаграма, на якій зображено відношення між акторами та прецедентами в системі.Також, перекладається як діаграма варіантів використання. Прецеденти є основним засобом визначення необхідної поведінки системи. Як правило, вони використовуються для описання вимог до системи, тобто, що має робити система. Основними поняттями, пов'язаними з прецедентами є актори, прецеденти (варіанти використання), та суб'єкт. Суб'єкт — це система, що розглядається і до якої відносяться прецеденти. Користувачі та будь-які інші системи, що можуть взаємодіяти із суб'єктом, представлено як акторів. Актори завжди представляють сутності, що знаходяться за межами системи. Поведінка суб'єкта описується одним або більше прецедентами, що визначаються відповідно до потреб акторів. Строго кажучи, термін «прецедент» означає тип прецедента. Екземпляр прецедента означає існування поведінки, що відповідає вимогам типу прецедента. Часто, такі екземпляри описуються специфікаціями взаємодії. Діаграма прецедентів є графом, що складається з множини акторів, прецедентів (варіантів використання) обмежених границею системи (прямокутник), асоціацій між акторами та прецедентами, відношень серед прецедентів, та відношень узагальнення між акторами. Діаграми прецедентів відображають елементи моделі варіантів використання

Чим вони відрізняються?

Типи програмних продуктів:

А)Системні

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

Б)Прикладні

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

В) Гібридні

Це поєднання системних і прикладних програмних продуктів.

Базові поняття SWEBOK

Інститут інженерів електроніки та електротехніки та американське об’єднання комп’ютерних фахівців створив міжнародний факультет, що в свою чергу створив ядро занань SWEBOK. Ці зання поділились на 10 областей. Кожна область мала загальну схему опису. Вона включає методи, засоби та інструменти підтримки інженерної діяльності. Це ядро знань є основою проектування ПЗ. Області знань:

I. Основи програмних вимог

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

Вимоги виділяють:

1) Програмні(вимоги до процесу, до ОС, до платформи)

2) Функціональні (вони задають призначення системи)

3) Нефункціональні (задають умови виконання ПЗ)

4) Системні (вимоги до програмної системи)

Розділи області знань: інженерія вимог, виявлення вимог, аналіз вимог, специфікація вимог, управління вимогами.

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

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

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

III. Конструювання ПЗ

Це створення працюючого ПЗ із залеченням методів верифікації, кодування та тестування компонентів.

IV. Тестування ПЗ

Це процес перевірки роботи програми в динаміці, заснований на виконанні набору тестових даних.

V. Супровід ПЗ

Це сукупність дій із зазначенням (забезпеченням) роботи ПЗ, а також по внесенню змін у разі виявлення помилок.

VI. Управління конфігурацією

Це дисципліна ідентифікації компонентів системи, визначення функціональних і фізичних характеристик системи.

VII. Управління інженерією ПЗ

Керівництво роботами команди розробників ПЗ в процесі виконання плану роботи. Визначення критеріїв і оцінка якості з використанням методів управління, планування і контрольних робіт.

VIII. Процес інженерії РЗ

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

IX. Методи і засоби інженерії ПЗ

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

X. Якість ПЗ

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

2. Описати обгрунтувати потребу побудови діаграми потоків даних. Ким була запропонована?

Діаграма потоків даних дозволяє специфікувати як функції, так і дані, як обробляються. Вони показують потік даних від джерела до користувача через процеси, які кожен раз уточнюються поки не будуть елементарними. Ця діаграма вперше була запропонована у 1975 році Барданом, а в 79 році уточнена Гейном-Рессарсоном. На основі цих діаграм побудовані методології Йордана де Марка, Гейна-Сарсона. В основі методології лежить або підсистема, накопичувач даних або потік даних.

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

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

Накопичувач даних або сховище – абстрактний пристрій дле зберігання інформації.

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

Приклад діаграми потоків даних:

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

1) Якщо процес можна описати алгоритмом

2) Якщо процес виконує єдину логічну функцію перетворення вхідних даних у вихідні.

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

 

 

Назвати цілі і завдання програмної інженерії.

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

Головне завдання «Програмної інженеріїї» як інженерної дисципліни — здобуття теоретичних і професійно-практичних компетенцій в області технологій розробки програмних систем.

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