- •Класифікація моделей систем. Роль інструментальної моделі у проектуванні програмного забезпечення.
- •Сучасні підходи до імітаційного моделювання, їх застосування у галузі «Програмна інженерія». Дискретно-подієве та агентне моделювання.
- •Компоненты системы дискретно-событийного моделирования
- •Список событий
- •Мета та задачі програмного проекту, вимоги до пз. Роль вимог у створенні надійного (відмовостійкого) програмного забезпечення.
- •Модель програмного забезпечення, етапи та особливості побудови моделі.
- •Модель зрілості процесів організації, модель 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. Формування та імітація функціонування динамічних систем.
Модель зрілості процесів організації, модель cmmі, способи та методи cmmі у вдосконаленні бізнес-процесів розробки пз.
На понятті зрілості організації будується модель CMM. Вона визначає 5 рівнів [1]:
Початковий рівень. Процеси початкового рівня зрілості, характеризуються хаотичністю, реактивністю, непередбачуваністю. На підприємстві початкового рівня організації не існує стабільних умов для створення якісного ПЗ. Результат будь-якого проекту цілком і повністю залежить від особистих якостей менеджера та досвіду програмістів, причому успіх в одному проекті може бути повторений тільки у випадку призначення тих же менеджерів і програмістів на наступний проект.
Повторюваний рівень. Для його впровадження в компанії мають бути впроваджені технології управління проектами. При цьому планування та управління проектами ґрунтується на накопиченому досвіді, існують стандарти на розроблюване ПЗ (причому забезпечується виконання цих стандартів) і існує спеціальна група забезпечення якості. Процеси керовані, вони плануються, виконуються, вимірюються і контролюються. Однак процеси все ж мають деяку долю реактивності в своїй суті.
Визначений рівень. Він характеризується тим, що стандартний процес створення і супроводу ПЗ задокументований (включно й розробка ПЗ, та управління проектами). Встановлені стандарти в межах організації. На даному етапі процеси описані не на рівні окремого проекту, а на рівні всієї організації. Мається на увазі, що в процесі стандартизації проходить перехід на найбільш ефективні практики і технології. Починаючи з цього рівня, організація перестає залежати від якостей конкретних розробників, і процес не має тенденції скочуватись на рівень нижче в стресових ситуаціях.
Керований рівень. У організації встановлюються кількісні показники якості – як на програмні продукти, так і на процес в цілому. Таким чином, більш досконале управління проектами досягається за рахунок зменшення відхилень різних показників проекту. При цьому осмисленні варіації в продуктивності процесу можна відрізнити від випадкових варіацій, особливо у добре освоєних областях.
Оптимізуючий рівень характеризується тим, що заходи з вдосконалення застосовуються не тільки до існуючих процесів, але і для оцінки ефективності введення нових технологій. Основною задачею всієї організації на цьому рівні є постійне вдосконалення існуючих процесів. При цьому вдосконалення процесів в ідеалі має допомагати попереджувати можливі помилки чи дефекти. Крім того, мають проводитися роботи по зменшенню вартості розробки програмного забезпечення.
Capability Maturity Model Integration (CMMI) – модель зрілості можливостей створення ПЗ. CMMI - набір моделей (методологій) вдосконалення процесів в організаціях різних розмірів і видів діяльності. CMMI вміщує набір рекомендацій у вигляді практик, реалізація яких, за думкою розробників моделі, дозволяє реалізувати цілі, необхідні для повної реалізації певних областей діяльності.
Набір моделей CMMI включає три моделі: CMMI for Development (CMMI-DEV), CMMI for Services (CMMI-SVC) та CMMI for Acquisition (CMMI-ACQ). Найбільш відомою є модель CMMI for Development, що орієнтована на організації, які займаються розробкою програмного забезпечення, апаратного забезпечення, а також комплексних систем.
Структура CMMI моделі
На верхньому рівні знаходяться чотири процесні категорії:
управління процесами,
управління проектами,
розробка,
супровід.
Кожна категорія включає кілька процесних областей.
Концептуальна модель CMMI дає кілька тривіальних рекомендацій з обрання сукупності процесних областей для включення їх у CMMI-модель, але залишає остаточне рішення за організацією. На ділі, щоб прийняти таке рішення, потрібно достатньо глибоко проаналізувати всі процесні області та їх взаємозв'язки.
Процесна область – складний об’єкт, пов'язаний з іншими компонентами CMMI-моделі
Структурно CMMI-модель організована схоже на модель SPICE. Об’єкт верхнього рівня у CMMI-моделі - процесна область. Специфічні практики - “цеглинки", з яких складаються специфічні для даної процесної області процеси. Взагалі, у різних процесних областей специфічні практики різні. В ідеалі для досягнення специфічної цілі (цілей) процесної області необхідно, щоб всі специфічні практики існували, були стійкими, стабільними, ефективними, і це буде значити, що в даній процесній області організація досягла досконалості. В реальності, однак, справа може виглядати інакше: частина практик може бути відсутня, частина – виникати та щезати, частина - працювати неефективно і т.і. Для того, щоб якось структурувати можливі ситуації, вводяться рівні розвинутості й пов'язуються вони з процесними областями через практики
Перелік специфічних практик:
Продвинуті практики:
Розділення у CMMI-моделі загальних та специфічних цілей і практик забезпечує ще один вимір при аналізі процесів і означає, що поняття рівня розвинутості не пов'язане з процесними областями, а характеризує здатність організації (в різних областях ці здатності можуть бути різними). Таким чином, задача розробки нової CMMI-моделі спрощується – достатньо тільки обрати процесні області, а повний опис рівнів розвинутості отримаємо автоматично.
Наповнення, тобто точний опис специфічних та загальних цілей і практик складає основний зміст концептуальної моделі CMMI. Для цього у модель вводяться субпрактики, описи типових результатів, а також неформальні описи взаємозв'язків практик різних процесних областей.
При побудові конкретної CMMI-моделі за допомогою концептуальної моделі необхідно дотримуватись певних обмежень. При недотриманні цих обмежень отримані модель неможна вважати коректно виведеною з концептуальної моделі. Ці обмеження достатньо прості:
потрібно обрати представлення для CMMI-моделі (неперервне* чи східчасте**);
загальні та специфічні цілі, у том вигляді, як вони представлені у концептуальній моделі, мають бути включені у CMMI-модель. При цьому принциповим є тільки назви цілей, конкретний зміст може бути звужений чи розширений;
загальні та специфічні практики з концептуальної моделі, чи розумні варіанти їх мають бути присутні в моделі; конкретний зміст практик може відрізнятися від того, що наведено у концептуальній моделі;
субпрактики, типові результати, різноманітні коментарі й додаткові відомості можуть відрізнятися від наведених у концептуальній моделі.
Представлення для CMMI-моделі
Різниця між моделями – у їх призначенні.
Модель з неперервним представленням призначена для виявлення та аналізу порядку виконання дій по вдосконаленню процесних областей (і в кінцевому підсумку організації в цілому). Вона використовується для внутрішніх цілей організації і включає профілі розвинутості процесів.
Модель зі східчастим представленням підказує шляхи вдосконалення управлінських практик в організації й призначена в основному для порівняння з іншими організаціями, а також для переходу від SW-CMM до CMMI. Фактично ця модель зрілості організації, аналогічна тій, що була запропонована у CMM.
Ще одне важливе зауваження у зв'язку з CMMI стосується стандартного виробничого процесу організації (СВПО), з яким ми зустрічалися у CMM. У CMMI замість такого процесу введено множину стандартних процесів організації. Сенс його такий, як і СВПО у CMM, але тепер в число стандартних входять не тільки виробничі, але й інші процеси: "множина стандартних процесів організації вміщує визначення процесів, що керують всіма активностями”
