- •Класифікація моделей систем. Роль інструментальної моделі у проектуванні програмного забезпечення.
- •Сучасні підходи до імітаційного моделювання, їх застосування у галузі «Програмна інженерія». Дискретно-подієве та агентне моделювання.
- •Компоненты системы дискретно-событийного моделирования
- •Список событий
- •Мета та задачі програмного проекту, вимоги до пз. Роль вимог у створенні надійного (відмовостійкого) програмного забезпечення.
- •Модель програмного забезпечення, етапи та особливості побудови моделі.
- •Модель зрілості процесів організації, модель cmmі, способи та методи cmmі у вдосконаленні бізнес-процесів розробки пз.
- •Моделі розробки програмного забезпечення. Модель водоспаду та ітеративна модель, застосування елементів даних моделей у сучасних методологіях розробки пз.
- •Моделі розробки програмного забезпечення. Методологія rup – загальна модель. Конус операційних маршрутів програмного проекту.
- •Моделі розробки програмного забезпечення. Методологія OpenUp.
- •Моделі розробки програмного забезпечення. Методології Microsoft Solutions Framework (msf), етапи управління великими програмними проектами.
- •Моделі розробки програмного забезпечення. Методологія fdd, Extreme Programming (xp).
- •Архітектура програмного проекту, керована моделями. Концепція mda.
- •Складові Model Driven Architecture, їх призначення.
- •Моделі розробки програмного забезпечення. Гнучкі методології розробки пз (Agile software development). Методологія Scrum. Ідея ефективного планування робочого навантаження учасників проекту.
- •Роли в скрам-процессе[править | править вики-текст]
- •Основные роли (Core roles) в методологии скрам («Свиньи»)[править | править вики-текст]
- •Дополнительные роли (Ancillary roles) в методологии скрам («Куры»)[править | править вики-текст]
- •Гнучка методологія розробки програмного забезпечення (Agile software development). Основні ідеї Agile.
- •Класифікація програмних проектів за управлінням.
- •Теорія систем. Дослідження рівноважних і нерівноважних систем. Важливість сучасного підходу, що використовується в теорії систем, для програмних проектів.
- •Теорія систем.
- •Теорія процесів. Формальний опис процесів. Специфікація процесу.
- •Теорія процесів. Поняття процесу, основні операції на процесах. Моделювання процесів.
- •Абстрактна та структурна теорії автоматів, їх особливості та приклади застосування.
- •Абстрактний автомат, визначення. Класифікація абстрактних автоматів.
- •Цифровий автомат, загальна структура та способи опису.
- •Динамічне моделювання паралельних програмних систем. Мережа Петрі, загальне визначення.
- •Класифікація мереж Петрі, основні інтерпретації, їх коротка характеристика.
- •Синхронні та асинхронні паралельні процеси, особливості їх моделювання.
- •Паралельний алгоритм, його відмінність від послідовного алгоритму. Моделювання паралельних алгоритмів.
- •Основні елементи мереж Петрі. Способи представлення мереж Петрі.
- •Динамічне та квазідинамічне моделювання програмних систем з паралелізмом. Методологія Business Process Modeling (на основі стандартів idef).
- •Цілі моделювання бізнес-процесів[ред. • ред. Код]
- •Використання[ред. • ред. Код]
- •Історія[ред. • ред. Код]
- •Зовнішнє проектування програмних систем. Принцип концептуальної цілісності.
- •Моделювання програмних систем. Uml-діаграми. Еволюція моделі програмної системи.
- •Нотація[ред. • ред. Код]
- •Діаграми Хареля[ред. • ред. Код]
- •Група uml-діаграм для побудови та уточнення архітектури програмної системи.
- •Докладніше[ред. • ред. Код]
- •Деталізоване проектування пс. Діаграми бізнес-класів та класів.
- •Зв'язки[ред. • ред. Код]
- •Асоціації[ред. • ред. Код]
- •Агрегація[ред. • ред. Код]
- •Композиція[ред. • ред. Код]
- •Відмінності між композицією і агрегацією[ред. • ред. Код]
- •Наслідування
- •Група uml-діаграм для опису поведінки програмної системи.
- •Група uml-діаграм для відображення взаємодії програмних компонентів проектованої системи.
- •Опис[ред. • ред. Код]
- •Метод Model Checking. Загальна характеристика методу.
- •Инструменты[править | править вики-текст]
- •Метод Model Checking. Темпоральні логіки.
- •Приклад[ред. • ред. Код]
- •Темпоральні логіки[ред. • ред. Код]
- •Структури Кріпке. Загальний алгоритм роботи.
- •Формальное определение[править | править вики-текст]
- •Model Checking. Алгоритм методу для ltl та ctl.
- •Середовище Simulink. Формування та імітація функціонування динамічних систем.
Моделі розробки програмного забезпечення. Модель водоспаду та ітеративна модель, застосування елементів даних моделей у сучасних методологіях розробки пз.
Модель водоспаду (waterfall model) (каскадна модель) – одна з найдавніших моделей розробки ПЗ. Вперше модель була описана у 1970 році. Вона передбачає послідовне виконання наступних етапів:
Розробка вимог (requirements): збір бізнес-вимог замовника та їх перетворення у функціональні вимоги до програмного продукту.
Аналіз та дизайн (analysis and design): розробка моделі предметної області (domain model), специфікація проекту, проектування схеми бази даних, об‘єктної моделі, користувацького інтерфейсу і т.і.
Реалізація (implementation): створення продукту за специфікаціям, що розроблені на попередньому етапі.
Тестування (testing): передбачає перевірку відповідності функціональності програмного продукту потребам користувача (validation), а також пошук дефектів в реалізації ПЗ.
Розгортування (deployment): навчання користувачів, інсталяція системи, перевід її у промислову експлуатацію.
Модель водоспаду (waterfall model)
Завжди погано, якщо у процесі розробки виявляється критична для всього проекту помилка, але ще гірше, якщо вона виявляється у вже розвернутому додатку. У модель водоспаду автори прагнули, наскільки можливо, виявити подібні помилки на етапі розробки вимог. Однак така модель показала себе не найкращим чином у проектах з нечіткими вимогами, чи вимогами, що змінюються по ходу розробки. Також існують й інші, не зовсім очевидні мінуси. Наприклад, складно керувати ризиками деяких типів (таких, як ризики, що пов‘язані з використанням нових технологій чи ризики некоректного визначення вимог). Такі ризики можуть проявити себе тільки на етапі реалізації (якщо не на тестуванні), коли число можливих шляхів виправлення ситуації набагато менше, ніж на початку проекту.
Ця модель не здатна гарантувати необхідну швидкість відгуку і внесення відповідних змін у відповідь на змінювані потреби користувачів, для яких програмна система є одним з інструментів виконання бізнес-функцій. Таким чином, модель водоспаду може застосовуватися [1] для розробки складних систем зі строго визначеною функціональністю, наприклад, програмного забезпечення для супутників чи медичного обладнання, але при реалізації бізнес-додатків її використання вкрай нераціональне.
Тому була розроблена інша модель, що основана на системі водоспаду – ітеративна модель розробки ПЗ.
Ітеративна модель розробки стала еволюційним розвитком моделі водоспаду. ЇЇ реалізація складається з серії повторюваних ітерацій (їх число залежить від конкретного проекту), кожна з яких фактично є повноцінним міні-проектом з фазами визначення вимог, аналізу, дизайну та ін. В результаті чергової ітерації продукт набуває нової функціональності чи покращує раніше розроблені елементи у існуючій функціональності. Повний набор вимог, зафіксований границями проекту, виявляється реалізованим після завершення фінальної ітерації.
В залежності від вимог проекту, після кожної ітерації ви можете отримати або не дієздатний модуль додатку, або вузькоспеціалізовану, але робочу програму. На отриманні локальних робочих версій спрямована кожна ітерація
Така система розробки дозволяє мінімізувати можливі ризики, що пов‘язані з впровадженням нових технологій, поточною зміною вимог до проекту, просто неякісним кодом.
Одним з процесів, що використовує у своїй основі ітеративну модель розробки, є Rational Unified Process (RUP).
