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

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

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

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

 

29. Обгрунтуйте вимоги, щодо рівня зрілості організацій — розробників ПЗ. Розробники ПЗ прийшли до висновку, що їх основні проблеми лежать у нездатності ефективно керувати процесом розробки ПЗ. Навіть найкращі методи та інструменти не можуть бути раціонально використані в рамках недисциплінованого, хаотичного проекту. Якість програмного продукту залишається непередбачуваним, тому що немає об'єктивного базису для його досягнення. Змінити ситуацію можна тільки в результаті створення інфраструктури для підтримки процесу ефективної програмної інженерії та супроводу.

Для побудови такої інфраструктури організації-розробники повинні мати:

а) засоби оцінювання їх здатності успішно виконувати технологічний процес розробки ПЗ;

б) керівництва щодо поліпшення можливостей свого ТП.

для оцінювання й удосконалення процесу програмної інженерії застосовується модель зрілості CMM яку розроблено Інститутом програмної інженерії SEI (Software Engineering Institute) США. Ця модель встановлює рівні готовності організації-розробника ПЗ створювати задовільно, середньо, добре і дуже добре програмну продукцію. Поняття рівня готовності визначається наявністю в організації необхідних ресурсів (людських, програмних, технічних і фінансових), стандартів і методик, а також здатністю колективу створювати програмні продукти. Модель СММ має п'ять рівнів. Перший і другий рівні фіксують недостатню готовність виконувати розробку продукту. Третій – п'ятий рівні характеризують певний ступінь готовності, зрілості і здатності фахівців (а, значить, і організації) виготовляти, відповідно, середній, гарний і відмінний продукт. Чим вище рівень зрілості, тим більше вимог ставиться до процесу програмної інженерії, придатного для виконання цілей і задач утворення продукту, що задовольняє користувача

 

Описати, які діаграми UML застосовують для опису поведінки програмного забезпечення, що проектуємо?

До діаграм які ми застосовуємо для опису поведінки ПЗ відносимо:

• Діяльності
• Станів
• Прецедентів

Діаграма діяльності — в UML, візуальне представлення графу діяльностей. Граф діяльностей є різновидом графу станів скінченного автомату, вершинами якого є певні дії, а переходи відбуваються по завершеню дій.

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

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

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

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

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

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

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

Перерахувати дев’ять найкращих навиків, рекомендованих методикою SPMN.

Навичка 1. Формальне управління ризиками. Будь-який проект з розробки ПЗ - ризикований. Але відсутність процедури управління ризиками в компанії - мабуть, найпоказовіша ознака прийдешньої невдачі проекту.

 

Навичка 2. Угоди про інтерфейси - для користувача, внутрішніх (міжмодульних) і зовнішніх (для стикування з іншими компонентами і додатками).

 

Навичка 3. Формальні перевірки проекту.

 

Навичка 4. Управління проектом на основі метрик.

Навичка 5. Якість продукту має контролюватися на детальному рівні.

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

Навичка 7. Щоб домогтися високої якості, треба відстежувати причини виникнення помилок.

 

Навичка 8. Конфігураційне управління.

 

Навичка 9. Управління персоналом.