33. Пояснити п’ять рівнів технологічної зрілості моделі смм.
П’ять рівнів технологічної зрілості СММ
Початковий. Найпримітивніший статус організації. Організація здатна розробляти ПЗ. Організація не має явно усвідомленого процесу, і якість продукту цілком визначається індивідуальними здібностями розробників. Один проявляє ініціативу і команда слід його вказівкам. Успіх одного проекту не гарантує успіх іншого. При завершенні проекту не фіксуються дані про трудовитратах, розклад і якості.
Повторюваний. В деякій мірі відстежується процес. Робляться записи по трудових витратах і планах. Функціональність кожного проекту описана в письмовій формі. У середині 99-го лише 20% організацій мали 2-й рівень або вище.
Встановлений. Мають певний, документований і встановлений процес роботи, що не залежить від окремих особистостей. Тобто вводяться узгоджені проф. стандарти, а розробники їх виконують. Такі організації в змозі достатньо надійно передбачати витрати на проекти, аналогічні виконаним раніше.
Керований. Можуть точно передбачити терміни і вартість робіт. Є база даних накопичених вимірів. Але немає змін при появі нових технологій і парадигм.
Оптимізований. Є постійно діюча процедура пошуку і освоєння нових і поліпшених методів та інструментів.
34 Показати, як описують операції для діаграми послідовностей?
На діаграмах послідовностей буде показано обмін повідомленнями (тобто виклик методів) між декількома об’єктами у окремій обмеженій часом ситуації. Об’єкти є екземплярами класів. Основний наголос на діаграмах послідовностей робиться на порядок і моментах часу, у які повідомлення надсилаються об’єктам.
На діаграмах послідовностей об’єкти буде показано вертикальними штриховими лініями з назвою об’єкта над ними. Вісь часу також має вертикальний напрямок, її спрямовано вниз, повідомлення, які надсилаються від одного об’єкта до іншого, буде позначено стрілками з назвами операції і параметрів.
Основні операції :
Стрілка від одного життя до іншого. Показує взаємодія об'єктів.
Синхронне повідомлення позначається зафарбованою стрілкою, асинхронне - незакрашенним. У нотації до 2.0, асинхронні повідомлення позначалися "спиляним" знизу наконечником стрілки. Повернення показується пунктирною стрілкою, у зворотному напрямку.
35. Перерахувати основні положення технології rad? Які програмні системи не можна розробляти з використанням цієї технології?
Основні положення RAD можна сформулювати наступним чином: - Робота ведеться групами. Типовий склад групи - керівник, аналітик, два програміста, технічний письменник. Розробка проекту виконується в умовах тісної взаємодії між розробниками і Замовником. - Розробка базується на моделях. Моделювання дозволяє оцінити проект і виконати його декомпозицію на складові частини, кожна з яких може розроблятися окремої RAD-групою. - Ітераційне прототипування. Розробка системи і пред'явлення її замовнику здійснюється у вигляді послідовності розвиваються прототипів. Будь-який з прототипів реалізує певну частину функціональності, необхідної від кінцевого продукту.
- RAD група завжди працює тільки над одним прототипом. Це забезпечує єдність цілей, кращу наблюдаемость і керованість процесом розробки, що в підсумку підвищує якість кінцевого продукту. Відповідно використовувані інструментальні засоби повинні забезпечувати групову розробку і конфігураційне управління проектом. - Якщо проект складний, то для нього може бути виділено декілька RAD груп. Великі системи розбиваються на підсистеми.Кожна підсистема розробляється незалежною групою. Ключ успіху - правильне розбиття системи на підсистеми. Команди повинні використовувати загальні стандарти. Обов'язково фінальне тестування повної системи. - Обов'язкове використання інструментальних засобів, що автоматизують процес розробки, і методик їхнього використання, наслідком чого є скорочення термінів розробки і підвищення якості кінцевого продукту. Принципи RAD застосовуються не тільки при реалізації, але й поширюються на всі етапи життєвого циклу, зокрема на етап обстеження організації, побудови вимог, аналіз і дизайн.
Програмні проети неможна розробляти наприклад, в проектах, де вимоги до програмного продукту чітко визначені і не повинні змінюватися, залучення замовника впроцес розробки не потрібно і більш ефективною може бути ієрархічна розробка (каскадний метод). Те ж стосується проекті ПО, складність яких визначається необхідністю реалізації складних алгоритмів, а роль і обсяг користувацького інтерфейсу невеликий.