Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Основні поняття та проблеми розробки ПЗ↑ Стр 1 из 6Следующая ⇒ Содержание книги
Похожие статьи вашей тематики
Поиск на нашем сайте
Лекція №1 Інженерія вимог до ПЗ Вимоги до ПЗ – сукупність властивостей, які повинно мати ПЗ. Призначені для адекватного визначення функцій, умов і обмежень виконання ПЗ, а також обсягів даних, технічного забезпечення і середовища його виконання. Вимоги відбивають потреби людей (замовників, користувачів, розробників), зацікавлених у створенні ПЗ. Замовник і розробник спільно виявляють вимоги, аналізують, переглядають, визначають необхідні обмеження і умови, а також описують їх. Розрізняють вимоги до продукту і до процесу, а також функціональні, не функціональні і системні вимоги. Вимоги до продукту і до процесу визначають умови виконання і режими роботи ПЗ в операційному середовищі, обмеження на структуру і пам'ять комп'ютерів та принципи взаємодії програм. Функціональні вимоги визначають призначення і функції системи, а не функціональні – умови стосовно виконання ПЗ, його переносності і доступу до даних. Системні вимоги описують вимоги до програмної системи, яка складається з взаємозалежних програмних і апаратних підсистем і різних застосувань. Вимоги можуть бути кількісні (наприклад, кількість оброблених запитів на секунду, середній показник помилок і т.п.). Значна частина вимог стосується атрибутів якості: безвідмовність, надійність і ін., а також захисту і безпеки як ПЗ, так і даних. Область знань «Вимоги до ПЗ (Software Requirements)» складається з таких розділів: – інженерія вимог (Requirement Engineering), – виявлення вимог (Requirement Elicitation), – аналіз вимог (Requirement Analysis), – специфікація вимог (Requirement Specification). – валідація вимог (Requirement validation), Розділ 1 29 – керування вимогами (Requirement Management). Інженерія вимог до ПЗ – це дисципліна аналізу і документування вимог до ПЗ, що полягає в перетворенні запропонованих замовником вимог до системи на опис вимог до ПЗ і їх валідації. Інженерія базується на моделі процесу визначення вимог і діяльності осіб, що забезпечують керування і формування вимог, а також на методах досягнення показників якості. Модель процесу визначення вимог – це схема процесів ЖЦ, що виконуються від початку проекту і доти, поки не будуть визначені і погоджені вимоги. Таким процесом може бути маркетинг і перевірка виконання вимог у даному проекті. Керування вимогами до ПЗ полягає в контролі за виконанням вимог і плануванні використання ресурсів (людських, програмних, технічних, часових, вартісних) у процесі розроблення проміжних робочих продуктів на процесах ЖЦ і продукту в цілому. Якість і процес поліпшення вимог – це процес формулювання характеристик і атрибутів якості (надійність, реактивність і ін.), які повинно мати ПЗ, методи їх досягнення на процесах ЖЦ і оцінювання отриманих результатів. Виявлення вимог – це процес витягування інформації з різних джерел (договорів, матеріалів аналітиків з декомпозиції задач і функцій системи й ін.), проведення технічних заходів (співбесід, збирання пропозицій і ін.) для формування окремих вимог до продукту і до процесу розроблення. Вимоги погоджуються з замовником. Аналіз вимог – процес вивчення потреб і цілей користувачів, класифікація і перетворення їх на вимоги до системи, апаратури і ПЗ, встановлення і вирішення конфліктів між вимогами, визначення пріоритетів, меж системи і принципів взаємодії із середовищем функціонування. Специфікація вимог до ПЗ – процес формалізованого опису функціональних і нефункціональних вимог, вимог до характеристик якості відповідно до стандарту якості ISO/IEC 9126, які будуть відпрацьовуватися на процесах ЖЦ ПЗ. У специфікації вимог відбивається структура ПЗ, вимоги до функцій, якості і документації, а також задається архітектура системи і ПЗ, алгоритми, логіка керування і структура даних. Специфікуються також системні вимоги, нефункціональні вимоги і вимоги до взаємодії з іншими компонентами і платформами (БД, СКБД, маршаллінг даних, мережа й ін.). Валідація вимог – це перевірка викладених у специфікації вимог, що виконується для того, щоб шляхом відстеження джерел вимог переконатися, що вони визначають саме дану систему. Замовник і розробник ПЗ проводять експертизу сформованого варіанта вимог для того, щоб розробник міг далі продовжувати проектування ПЗ. Один з методів валідації – прототипування, тобто швидке відпрацьовування окремих вимог на конкретному інструменті і дослідження масштабів зміни вимог, вимірювання обсягу функціональності і вартості, а також створення моделей оцінки зрілості вимог. Верифікація вимог – це процес перевірки правильності специфікацій вимог щодо їх відповідності потребам, несуперечності, повноти і можливості реалізації, а також узгодженості зі стандартами. Як результат перевірки вимог складається погоджений вихідний документ, що встановлює повноту і коректність вимог до ПЗ, а також можливість продовження його проектування. Керування вимогами – це керування процесами формування вимог на всіх процесах ЖЦ, а також змінами й атрибутами вимог, проведення моніторингу – відновлення джерела вимог. Керування змінами виникає після того, як ПЗ починає працювати в заданому середовищі і виявляє помилки щодо трактування вимог, невиконання деякої окремої вимоги тощо. Невід'ємною складовою процесу керування є трасування вимог для відстеження правильності встановлення і реалізації вимог до системи і ПЗ на процесах ЖЦ, а також зворотний процес відстеження в отриманому продукті реалізованих вимог. Для уточнення деяких вимог або додавання нової вимоги складається план зміни вимог, що погоджується із замовником. Внесені зміни спричиняють і зміни в створеному продукті або в окремих його компонентах. Проектування ПЗ Проектування ПЗ – це процес визначення архітектури, набору компонентів, їх інтерфейсів, інших характеристик системи і кінцевого складу програмного продукту. Область знань «Проектування ПЗ (Software Design)» складається з таких розділів: ‒ базові концепції проектування ПЗ (Software Design Basic Concepts), ‒ ключові питання проектування ПЗ (Key Issue in Software Design), ‒ структура й архітектура ПЗ (Software Structure and Architecture), ‒ аналіз і оцінка якості проектування ПЗ (Software Design Quality Analysis and Evaluation), ‒ нотації проектування ПЗ (Software Design Notations), ‒ стратегія і методи проектування ПЗ (Software Design Strategies and Methods). Базова концепція проектування ПЗ – це методологія проектування архітектури за допомогою різних методів (об'єктного, компонентного й ін.), процеси ЖЦ (стандарт ISO/IEC 12207) і техніки – декомпозиція, абстракція, інкапсуляція й ін. На початкових стадіях проектування предметна область декомпозується на окремі об'єкти (при об’єктно-орієнтованому проектуванні) або на компоненти (при компонентному проектуванні). Для подання архітектури програмного забезпечення вибираються відповідні артефакти (нотації, діаграми, блок-схеми і методи). Ключові питання проектування – це декомпозиція програм на функціональні компоненти для незалежного і одночасного їхнього виконання, розподіл компонентів у середовищі функціонування і їх взаємодія між собою, забезпечення якості і живучості системи й ін. Проектування архітектури ПЗ проводиться архітектурним стилем, заснованим на визначенні основних елементів структури – підсистем, компонентів, об'єктів і зв'язків між ними. Архітектура проекту – високорівневе подання структури системи і специфікація її компонентів. Архітектура визначає логіку системи через окремі компоненти системи настільки детально, наскільки це необхідно для написання коду, а також визначає зв'язки між компонентами. Існують і інші види подання структур, засновані на проектуванні зразків, шаблонів, сімейств програм і каркасів програм. Один з інструментів проектування архітектури – патерн (шаблон). Це типовий конструктивний елемент ПЗ, що задає взаємодію об'єктів (компонентів) проектованої системи, а також ролі і відповідальності виконавців. Основна мова опису – UML. Патерн може бути структурним, що містить у собі структуру типової композиції з об'єктів і класів, об'єктів, зв'язків і ін.; поведінковим, що визначає схеми взаємодії класів об'єктів і їх поведінку, задається діаграмами діяльності, взаємодії, потоків керування й ін.; погоджувальним, що відображає типові схеми розподілу ролей екземплярів об'єктів і способи динамічної генерації структур об'єктів і класів. Аналіз та оцінювання якості проектування ПЗ – це заходи щодо аналізу сформульованих у вимогах атрибутів якості, функцій, структури ПЗ, з перевірки якості результатів проектування за допомогою метрик (функціональних, структурних і ін.) і методів моделювання і прототипування. Нотації проектування дозволяють представити опис об'єкта (елемента) ПЗ і його структуру, а також поведінку системи за цим об’єктом. Існує два типи нотацій: структурна, поведінкова, та множина їх різних представлень. Структурні нотації – це структурне, блок-схемне або текстове подання аспектів проектування структури ПЗ з об'єктів, компонентів, їх інтерфейсів і взаємозв'язків. До нотацій відносять формальні мови специфікацій і проектування: ADL (Architecture Description Language), UML (Unified Modeling Language), ERD (Entity–Relation Diagrams), IDL (Interface Description Language) тощо. Нотації містять у собі мовний опис архітектури й інтерфейсу, діаграм класів і об'єктів, діаграм сутність–зв'язок, конфігурації компонентів, схем розгортання, а також структурні діаграми, що задають у наочному вигляді оператори циклу, розгалуження, вибору і послідовності. Поведінкові нотації відбивають динамічний аспект роботи системи та її компонентів. Ними можуть бути діаграми потоків даних (Data Flow), діяльності (Activity), кооперації (Colloboration), послідовності (Sequence), таблиці прийняття рішень (Decision Tables), передумови і постумови (Pre-Post Conditions), формальні мови специфікації (Z, VDM, RAISE) і проектування. Стратегія і методи проектування ПЗ. До стратегій відносять: проектування вгору, вниз, абстрагування, використання каркасів і ін. Методи є функціонально- орієнтовані, структурні, які базуються на структурному аналізі, структурних картах, діаграмах потоків даних й ін. Вони орієнтовані на ідентифікацію функцій і їх уточнення знизу-вгору, після цього уточнюються діаграми потоків даних і проводиться опис процесів. В об’єктно-орієнтованому проектуванні ключову роль відіграє наслідування, поліморфізм й інкапсуляція, а також абстрактні структури даних і відображення об'єктів. Підходи, орієнтовані на структури даних, базуються на методі Джексона і використовуються для подання вхідних і вихідних даних структурними діаграмами. Метод UML призначений для опису сценаріїв роботи проекту у наочному діаграмному вигляді. Компонентне проектування ґрунтується на використанні готових компонентів (reuse) з визначеними інтерфейсами і їх інтеграції в конфігурацію, як основи розгортання компонентної системи для її функціонування в операційному середовищі. Формальні методи опису програм ґрунтуються на специфікаціях, аксіомах, описах деяких попередніх умов, твердженнях і постумовах, що визначають заключну умову одержання програмою правильного результату. Специфікація функцій і даних, якими ці функції оперують, а також умови і твердження – основа доведення правильності програми. Тестування ПЗ Тестування ПЗ – це процес перевірки готової програми в статиці (перегляди, інспекції, налагодження вихідного коду) і в динаміці (прогін на наборі тестових даних) з метою перевірки різних шляхів виконання програми і порівняння отриманих результатів із заздалегідь заданими. Існує дві форми перевірки коду – модульна й інтеграційна. Спочатку використовують стандарти (IEEE 829:1996 і IEEE 1008:1987) з перевірки і тестування модулів. Потім проводиться інтеграційне тестування модулів системи і їх інтерфейсів у динаміці виконання. Під час різних видів перевірок збираються дані про помилки, дефекти, відмови тощо і оформляється відповідна документація (таблиці типів помилок, частоти і часу виявлення відмов і ін.). Зібрані дані використовуються при оцінюванні характеристик якості готового ПЗ, наприклад, надійності. Область знань «Тестування ПЗ (Software Testing)» містить у собі такі розділи: – основні концепції і визначення тестування (Testing Basic Concepts and definitions), – рівні тестування (Test Levels), – техніки тестування (Test Techniques), – метрики тестування (Test Related Measures), – керування процесом тестування (Managing the Test Process). Дана область знань SWEBOK визначає методи перевірки правильності ПЗ: верифікація, валідація, тестування. Наводяться типи, рівні і техніки тестування ПЗ, методи планування процесу тестування, розроблення тестових наборів даних для прогону ПЗ в режимі випробування модулів або системи в цілому і наступною оцінкою результатів тестування. Основна концепція тестування – це базові терміни, ключові проблеми і їхній зв'язок з іншими областями знань. Тестування визначається як процес перевірки правильності програми в динаміці її виконання за тестовими даними. При тестуванні виявляються недоліки: відмови (faults) і дефекти (defects) як причини порушення роботи програми, збої (failures) як небажані ситуації, помилки (errors) як наслідки збоїв і ін. Базове поняття тестування – тест, що виконується в заданих умовах і за наборами даних. Тестування вважається успішним, якщо знайдено дефект або помилка, і вони відразу усуваються. Ступінь тестованості визначається критерієм покриття системи тестами, перевірки всіх можливих шляхів виконання програм і імовірності припущення стосовно того, що може з'явитися збій або помилкова ситуація в системі. Рівні тестування: – тестування окремих елементів – це перевірка окремих, ізольованих і незалежних одна від одної частин ПЗ; – інтеграційне тестування орієнтоване на перевірку зв'язків і взаємодії компонентів (інтерфейсів), що можуть розміщуватися на різних архітектурних платформах розподіленого середовища; – тестування системи – це перевірка правильності функціонування системи, пошук і виявлення відмов і дефектів у системі і їхнє усунення. При цьому контролюється виконання сформульованих не функціональних вимог (безпека та ін.) у системі, правильність подання і здійснення зовнішніх інтерфейсів системи з зовнішнім середовищем. На всіх рівнях тестування застосовуються методи: – функціонального тестування, які забезпечують перевірку реалізації функцій, що визначені у вимогах, а також правильності їх виконання; – регресійного тестування, що орієнтоване на повторне вибіркове тестування системи або її компонентів після внесення в них змін на тих самих тестах, що і до модифікації; – тестування ефективності – це перевірка продуктивності, пропускної здатності, максимального обсягу даних і системних обмежень відповідно до вимог; – стрес-тестування – це перевірка поведінки системи при максимально припустимому навантаженні або в разі його перевищення; – альфа- і бета-тестування – це тестування системи (альфа) групою тестувальників організації-розробника і тестування системи «зовнішніми» користувачами (бета); – конфігураційного тестування – перевірка структури й ідентифікації системи, а також роботи системи на різних конфігураціях апаратури й устаткування. Тестуванню підлягають також перевірка реалізації вимог і забезпечення параметрів настроювання і розміщення компонентів ПЗ на заданій кількості і типах комп'ютерів і середовища. Техніки тестування базуються на певних теоретичних і практичних положеннях щодо проектування (компонентного, об'єктно-орієнтованого, сервісного і т.п.), а також на таких даних: – інформація про структуру ПЗ або системи в документації («біла скринька» ); – підбір тестових наборів даних для перевірки правильності роботи компонентів і системи в цілому без знання їх структури («чорна скринька»); – аналіз граничних значень, таблиць прийняття рішень, потоків даних, статистики відмов і ін.; – блок-схеми побудови програм і складання наборів тестів для покриття системи цими тестами; – виявлені і зафіксовані в таблицях системи дефекти, перед- і постумови виконання, структурні характеристики системи (кількість модулів, обсяг даних тощо). Метрики тестування. Для вимірювання результатів тестування ПЗ й оцінки якості використовуються метрики. Вимір як частина планування і розробки тестів базується на розмірі програм, їх структурі і кількості виявлених помилок і дефектів. Метрики тестування – це вимірювання процесу планування, проектування і тестування, а також результатів тестування на основі таксономії відмов і дефектів, покриття границь тестування, перевірки потоків даних і ін. Процес тестування документується і, відповідно до стандарту IEEE 829:1995, містить у собі опис тестових документів, їх зв'язку між собою і з задачами тестування. Без документації на процес тестування неможливо провести сертифікацію продукту за моделями зрілості, зокрема, моделлю СММ [11]. Після завершення тестування оцінюється вартість і ризики ПЗ, викликані збоями або недостатньо надійною роботою системи. Вартість тестування – одне з обмежень, на основі якого приймається рішення про його припинення або продовження. Керування тестуванням: – планування процесу тестування (складання планів, тестів, наборів даних) і оцінювання показників якості готового продукту; – проведення тестування компонентів повторного використання і патернів як основних об'єктів складання ПЗ; – генерація необхідних тестових сценаріїв, що відповідають середовищу виконання ПЗ; – верифікація правильності реалізації системи і валідація реалізації вимог до ПЗ; – збирання даних про відмови, помилки і виявлені непередбачені ситуації при виконанні програмного продукту; – підготовка звітів за результатами тестування й оцінка характеристик системи. Відповідно до стандарту ISO/IEC 12207 тестування ПЗ розглядається як невід'ємна частина ЖЦ. Супровід ПЗ Супровід ПЗ – сукупність дій із забезпечення його роботи, внесення змін при виявленні помилок, адаптації ПЗ до нового середовища функціонування, а також підвищення продуктивності або поліпшення деяких характеристик ПЗ. У зв'язку з вирішенням так званої проблеми 2000 року (пов’язаної з кодуванням дат у новому тисячолітті, зокрема, у двохсимвольному форматі) супроводження почав розглядатися, як більш важливий процес, що здійснюють розробники. Після змін система має вирішувати ті самі задачі, а також мати план перенесення інформації в інші БД. Супровід відповідно до стандартів ISO/IEC 12207 і ISO/IEC 14764 проводиться з метою виконання і модифікації програмного продукту в процесі експлуатації за умови збереження його цілісності. Область знань «Супровід ПЗ (Software Maintenance)» складається з таких розділів: – основні концепції (Basic Concepts), – процес супроводження (Process Maintenance), – ключові питання супроводу ПЗ (key Issue in Software Maintenance), – техніки супроводу (Techniques for Maintenance). Супровід розглядається з точки зору задоволення вимог споживача у готовому ПЗ, коректності його виконання, процесів навчання й оперативного обліку його процесу. Основні концепції – це базові визначення і термінологія, підходи до еволюції і супроводу ПЗ, до оцінки вартості супроводу тощо. До основних концепцій можна віднести ЖЦ ПЗ (стандарт ISO/IEC 12207) і складання документації. Головне призначення цієї області знань полягає у виконанні готової програмної системи, фіксації помилок, що виникають при виконанні, дослідженні їх причин, аналізі необхідності модифікації системи з метою усунення помилок, оцінці вартості робіт із проведення змін функцій і системи в цілому. Розглядаються проблеми, пов'язані з ускладненістю продукту при великій кількості змін, і методи її подолання. Процес супроводження містить у собі моделі процесу супроводу і планування діяльності людей, що проводять запуск ПЗ, перевірку правильності його виконання і внесення в нього змін. Цей процес згідно з стандартом ISO/IEC 14764 проводиться шляхом: – коригування, тобто зміни продукту для усунення виявлених помилок або нереалізованих задач; – адаптації, тобто настроювання продукту в умовах експлуатації, що змінилися, або в новому середовищі виконання; – поліпшення, тобто еволюційної зміни продукту для підвищення продуктивності або рівня супроводу; – перевірки ПЗ, пошуку і виправлення помилок при експлуатації системи. Ключові питання супроводу ПЗ – це управлінські, вимірювальні і вартісні. Суть управлінських питань – контроль ПЗ при модифікації й удосконалюванні функцій і недопущення зниження продуктивності системи. Питання вимірювання пов'язане з оцінкою характеристик системи після її модифікації, а також повторного тестування для оцінки показників якості. Вартісні питання пов'язані з оцінкою витрат на супровід залежно від його типу, кваліфікації персоналу, платформи й ін. Техніка супроводу (цей розділ називають також еволюцією ПЗ). Відомий фахівець в області ПЗ Дж. Леман (1970 р.) запропонував розглядати супровід як еволюційну розробку програмних систем, оскільки здана в експлуатацію система не завжди цілком завершена, її треба змінювати протягом терміну експлуатації. Внаслідок змін система стає більш складною і погано керованою. У зв'язку з цим виникає проблема зменшення її складності. До технологій еволюції ПЗ відносять реінженерію, реверсну інженерію і рефакторинг. Реінженерія – це удосконалення застарілого ПЗ шляхом його реорганізації або реструктуризації, а також перепрограмування окремих елементів або настроювання параметрів на іншу платформу, середовище виконання зі збереженням зручності його супроводу. Реверсна інженерія полягає у відновленні специфікації (графів викликів, потоків даних і ін.) за отриманим кодом системи для її аналізу на більш високому рівні. Відновлюється ідентифікація компонентів і зв'язків між ними для забезпечення перепрограмування системи на нову платформу. Найчастіше реверсна інженерія застосовується після того, як у код ПЗ було внесено багато змін і воно стало некерованим або змінилася платформа комп'ютера. Рефакторинг – це реорганізація коду для поліпшення характеристик і показників якості об’єктно-орієнтованих і компонентних програм без зміни їх поведінки. Цей процес реалізується шляхом поступової зміни окремих операцій над текстами, інтерфейсами, середовищем програмування і виконання ПЗ, а також настроювання або внесення змін в інструментальні засоби підтримки ПЗ. Якщо при зміні зберігається формат існуючої системи, то рефакторинг – один з варіантів реверсної інженерії.
Керування конфігурацією Керування конфігурацією – це ідентифікація компонентів системи, визначення функціональних, фізичних характеристик системи, апаратного і програмного забезпечення для контролю виконання, внесення змін і трасування конфігурації. Процес керування визначено як один з допоміжних процесів ЖЦ (ISO/IEC 12207), виконуваний технічним і адміністративним менеджментом проекту. При цьому складаються звіти про зміни, внесені у конфігурацію, і ступінь їхньої реалізації, а також проводиться перевірка відповідності внесених змін заданим вимогам. Конфігурація системи – це склад функцій, програмного і технічного забезпечення системи, можливі їх комбінації залежно від наявності устаткування, загальносистемних засобів і вимог до продукту. Конфігурація ПЗ складається з набору функціональних і технічних характеристик ПЗ, заданих у технічній документації і реалізованих у готовому продукті. Це сполучення різних елементів продукту з заданими процедурами збирання компонентів і настроювання на середовище. Вхідними елементами конфігурації є графік розробки, проектна документація, вихідний виконуваний код, бібліотека компонентів, інструкції з установки і розгортання системи. Область знань «Керування конфігурацією ПЗ (Software Configuration Management – SCM)» складається з таких розділів: – керування процесом конфігурації (Management of SMC Process), – ідентифікація конфігурації ПЗ (Software Configuration Identification), – контроль конфігурації ПЗ (Software Configuration Control), – облік статусу (поведінка або стани) конфігурації ПЗ (Software Configuration Status Accounting), – аудит конфігурації ПЗ (Software Configuration Auditing), – керування версіями ПЗ і доставкою (Software Release Management and Delivery). Керування процесом конфігурації. Це діяльність з контролю еволюції і цілісності продукту при ідентифікації, змінах і забезпеченні звітною інформацією, що стосується конфігурації. Вона містить у собі: – систематичне відстеження внесених змін в окремі складові частини конфігурації, виконання аудита змін і автоматизованого контролю за внесенням змін у конфігурацію системи або в ПЗ; – підтримку цілісності конфігурації, її аудит і забезпечення внесення змін в елементи конфігурації; – ревізію конфігурації з метою перевірки наявності розроблених програмних або апаратних засобів і узгодження версії конфігурації з заданими вимогами; – трасування змін у конфігурації на процесах супроводу й експлуатації ПЗ. Ідентифікація конфігурації ПЗ полягає в документуванні функціональних і фізичних характеристик елементів конфігурації, а також в оформленні технічної документація на елементи конфігурації. Контроль конфігурації ПЗ – це роботи з координації, затвердження або відкидання реалізованих змін в елементах конфігурації після ідентифікації, а також з аналізу вхідних компонентів конфігурації. Облік статусу або стану конфігурації ПЗ – комплекс заходів для визначення ступеня зміни конфігурації, а також правильності внесених змін у систему при супроводі. Інформація і кількісні показники накопичуються у відповідній БД і використовуються при складанні звітності, оцінюванні якості і виконанні процесів ЖЦ. Аудит конфігурації – це діяльність, що виконується для оцінки відповідності продукту і процесів стандартам, інструкціям, планам і процедурам. Аудит визначає Розділ 1 39 ступінь задоволення конфігурації функціональним і фізичним (апаратним) характеристикам системи. Керування версіями ПЗ – це відстеження наявної версії компонентів конфігурації; складання компонентів; створення нових версій системи на основі існуючих шляхом внесення змін у конфігурацію; узгодження версії продукту з вимогами і проведеними змінами на процесах ЖЦ; забезпечення оперативного доступу до інформації про елементи конфігурації і системи, до яких вони належать. Дане керування містить у собі такі основні поняття. Базис (baseline) – формально позначений набір елементів ПЗ, зафіксований на процесах ЖЦ. Бібліотека ПЗ – колекція об'єктів ПЗ і документації, призначена для полегшення процесу розроблення, використання і супроводження. Складання ПЗ – об'єднання коректних елементів і конфігураційних даних у єдину виконувану програму.
3.Методи та інструменти інженерії програмного забезпечення Методи забезпечують проектування, реалізацію і виконання ПЗ. Вони накладають деякі обмеження на інженерію ПЗ у зв'язку з особливостями застосування їхніх нотацій і процедур, а також забезпечують оцінку і перевірку процесів і продуктів. Інструменти забезпечують програмну підтримку окремих методів інженерії ПЗ для автоматизованого виконання задач процесів ЖЦ. Область знань «Методи та інструменти інженерії ПЗ (Software Engineering Tools and Methods)» складається з розділів: – інструменти інженерії ПЗ (Software Engineering Tools), – методи інженерії ПЗ (Software Engineering Methods). Методи інженерії ПЗ – це евристичні методи (heuristic methods), формальні методи (formal methods) і методи прототипування (prototyping methods). Евристичні методи містять у собі: структурні методи, засновані на функціональній парадигмі; методи, орієнтовані на структури даних, якими маніпулює ПЗ; об’єктно-орієнтовані методи, що розглядають предметну область як колекцію об'єктів; методи, орієнтовані на конкретну область застосування, наприклад, на системи реального часу, безпеки та ін. Формальні методи засновані на формальних специфікаціях, аналізі, доведенні і верифікації програм. Специфікація записується мовою, синтаксис і семантика якої визначені формально і засновані на математичних концепціях (алгебрі, теорії множин, логіці). Розрізняються наступні категорії формальних методів: – мови і нотації специфікації (specification languages and notations), орієнтовані на модель, властивості і поведінку; – уточнення специфікації (refinement specification) шляхом трансформації в кінцевий результат, близький до кінцевого програмного продукту, що виконується; – методи верифікації/доведення (verification/proving properties), що використовують твердження (теореми), перед- і постумови, формально описуються і застосовуються для встановлення правильності специфікації програм. Методи доведення застосовувалися в основному в теоретичних експериментах. Понад 25 років їх застосування було обмежено через трудомісткість і економічну невигідність. У 2005 р. проблема верифікації знову набула актуальності у запропонованому новому міжнародному проекті «Цілісний автоматизований набір інструментів для перевірки коректності ПС» (Т. Хоар, «Открытые системы», 2006, № 6), який поставив наступні перспективні задачі: – розробка єдиної теорії побудови й аналізу програм; – побудова багатостороннього інтегрованого набору інструментів верифікації на усіх виробничих процесах – розроблення формальних специфікацій, їх доведення і перевірка правильності, генерація програм і тестових прикладів, уточнення, аналіз і оцінка; – створення репозитарію формальних специфікацій, верифікованих програмних об'єктів різних типів і видів. Формальні методи верифікації будуть охоплювати всі аспекти створення і перевірки правильності програм. Це приведе до створення потужної верифікованої виробничої основи і сприятиме значному зменшенню помилок у ПЗ (стосовно доведення і верифікації). Методи прототипування (Prototyping Methods) засновані на використанні прототипу ПЗ для моделювання на ньому завдань нової системи і базуються на: – стилях прототипування, що уособлюють тривалість використання прототипів, наприклад, стиль створення тимчасово використовуваних прототипів (throw away), – моделях еволюційного прототипування – перетворення прототипу в кінцевий продукт і розроблення специфікацій, відповідно до якої він виконується; – техніках оцінки/дослідження (evaluation) результатів прототипування. Інструменти інженерії ПЗ забезпечують автоматизовану підтримку процесів розроблення ПЗ і містять у собі множину інструментів, що охоплюють усі процеси ЖЦ. Інструменти роботи з вимогами (Software Requirements Tools) – це: – інструменти розробки (Requirement Development) і керування вимогами (Requirement Management), орієнтовані на аналіз, збирання, специфікування і перевірку вимог; – інструменти трасування вимог (Requirement traceability tools) є невід'ємною частиною роботи з вимогами, їх функціональний зміст залежить від складності проектів і рівня зрілості процесів. Інструменти проектування (Software Design Tools) – це інструменти для створення ПЗ із застосуванням базових нотацій (структурної SADT/IDEF, моделювання UML і т.п.). Інструменти конструювання ПЗ (Software Construction Tools) – це інструменти для трансляції і об’єднання програм. До них належать: – редактори програм (program editors) і програми редагування загального призначення; – компілятори і генератори коду (compilers and code generators) як самостійні засоби об'єднання програмних компонентів в інтегрованому середовищі для одержання вихідного продукту з використанням препроцесорів, складальників, завантажників і ін.; – інтерпретатори (interpreters), які забезпечують контрольоване виконання програм за їх описом. Намітилася тенденція злиття інтерпретаторів і компіляторів (наприклад, Java, в.NET); – відлагоджувачі (debuggers), призначені для перевірки правильності опису вихідних програм і усунення помилок; – інтегроване середовище розробки (IDE – integrated development environment) та бібліотеки компонентів (libraries components), що є утворюють середовище виконання процесу розроблення ПС; – програмні платформи (Java, J2EE і Microsoft.NET) і платформи для розподілених обчислень (CORBA і WebServices, тощо). Інструменти тестування (Software Testing Tools) – це: – генератори тестів (test generators), що допомагають у розробці сценаріїв тестування; – засоби виконання тестів (test execution frameworks), які забезпечують виконання тестових сценаріїв і відслідковують поведінку об'єктів тестування; – інструменти оцінки тестів (test evaluation tools), які підтримують оцінювання результатів виконання тестів і ступеня відповідності поведінки тестованого об'єкта очікуваній поведінки; – засоби керування тестами (test management tools), які забезпечують інженерне керування процесом тестування ПЗ; – інструменти аналізу продуктивності (performance analysis tools), кількісної її оцінки та оцінки поводження програм у процесі виконання. Інструменти супроводу (Software Maintenance Tools) містять у собі: – інструменти полегшення розуміння (comprehension tools) програм, наприклад, різні засоби візуалізації; – інструменти реінженерії (reengineering tools) підтримують діяльність з перетворення програм і зворотної інженерії (reverse engineering) для відновлення (артефактів, специфікації, архітектури) застарілого ПЗ або генерації нового продукту. Інструменти конфігураційного керування (Software Configuration Management Tools) – це: – інструменти відстеження (tracking) дефектів; – інструменти керування версіями; – інструменти керування складанням, випуском версії (конфігурації) продукту та його інсталяції. Інструменти керування інженерною діяльністю (Software Engineering Management Tools) поділяються на: – інструменти планування і відстеження ходу проектів, кількісної оцінки зусиль і вартості робіт у проекті (наприклад, Microsoft Project 2003); – інструменти керування ризиками, які використовуються для ідентифікації, моніторингу ризиків і оцінки нанесеного ушкодження; – інструменти кількісної оцінки властивостей ПЗ шляхом вимірювань і розрахунків остаточного значення надійності і якості. Інструменти підтримки процесів (Software Engineering Process Tools) розділені на: – інструменти моделювання та опису моделей ПЗ (наприклад, UML і його інструменти); – інструменти керування програмними проектами (наприклад, Microsoft Project); – інструменти керування конфігурацією для підтримки версій і всіх артефактів проекту. Інструменти забезпечення якості (Software Quality Tools) діляться на дві категорій: – інструменти інспектування для підтримки перегляду (review) і аудиту; – інструменти статичного аналізу артефактів, даних, потоків робіт і перевірки їх властивостей на відповідність показникам. Додаткові аспекти інструментального забезпечення (Miscellaneous Tool Issues) стосуються: – техніки інтеграції інструментів (платформ, представлень, процесів, даних) для їх природного сполучення в інтегрованому середовищі; – метаінструментів для генерації інших інструментів для ПЗ; Востаннє редаговано: П’ятниця, 18 березня 2016, 10:14. Версія: 2. Опубліковано: Понеділок, 15 лютого 2016, 15:30. Лекція №4 Відношення між сценаріями. Між сценаріями відношення задаються стрілками з вказівкою назви типу відносин. Для сценаріїв можна задавати два типи відношення: 1) відношення «розширює» означають, що функція одного сценарію є доповненням до функції іншого і використовується при наявності декількох варіантів одного й того самого сценарію (рис. 4.2).
Рис. 4.2. Приклад відношення «розширює»
Інваріантна частина сценарію зображується у вигляді головного сценарію, а окремі варіанти – як розширення. При цьому головний сценарій є стійким, не змінюється при розширенні варіантів функцій і не залежить ві
|
||||
Последнее изменение этой страницы: 2016-12-14; просмотров: 1290; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.15.225.188 (0.012 с.) |