Вимоги до програмного забезпечення

Питання

1.Проектування ПЗ - проектування, цілі проектування, вимоги до ПЗ
2. Життєвий цикл ПЗ
3. Моделі життєвого циклу
4. Цілісність даних та надійність ПЗ
5. Шаблони проектування
6. Класифікація архітектур програмного забезпечення
7. Обробка помилок, виключень та небажаних умов
8. Діаграми подій
9. Звязність та звязаність (coupling and cohesion)
10. Повторне використання коду
11. Ітеративне й інкрементне проектування
12. Функціональна методика потоків даних
13. Структурна схема розроблювального ПЗ
14. Проектування програмного забезпечення при структурному підході
15. Типи компонентних структур та основні означенння
16. Методологія компонентної розробки ПЗ
17. Приклади компонентних середовищ
18. Планування архітектури
19. Програмний процес та архітектурно-економічний цикл
20. Архітектурні зразки, еталонні моделі та еталонні варіанти архітектури
21. Архітектурні структури і подання

1. Проектування ПЗ – проектування, цілі проектування, вимоги до ПЗ

Проектування пз -процес створення проекту програмного забезпечення (ПЗ)

Проектування ПЗ -процес визначення архітектури, компонентів, інтерфейсів й інших характеристик системи або її компонентів

Цілі проектування ПЗ:

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

Спочатку програма розглядається як чорний ящик. Хід процесу проектування і його результатів залежать не тільки від складу вимог, але й обраної моделі процесу, досвіду проектувальника

Модель предметної області накладає обмеження на бізнес-логіку й структури даних.

Залежно від класу створюваного ПЗ, процес проектування може забезпечуватися як "ручним" проектуванням, так і різними засобами його автоматизації. У процесі проектування ПЗ для вираження його характеристик використаються різні нотації - блок-схеми, ER-діаграми, UML-діаграми, DFD-діаграми, а також макети

Проектуванню підлягають

Архітектура ПЗ

Пристрій компонентів ПЗ

Користувальницькі інтерфейси

Вимоги до ПЗ

Розробка вимог до ПЗ

процес виявлення, формулювання, аналізу, документування й верифікації вимог, що підлягають виконанню в продукті

У його ході системний аналітик формує реєстр вимог, що лягає в документ або автоматизовану систему керування вимогами.

Вимоги до програмного забезпечення

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

Вимоги можуть виражатися у вигляді текстових тверджень і графічних моделей.

У класичному технічному підході сукупність вимог використається на стадії проектування ПЗ.

Етапу розробки вимог, можливо, передувало техніко-економічне обґрунтування, або концептуальна фаза аналізу проекту

2. Життєвий цикл ПЗ

період часу, що починається з моменту ухвалення рішення про необхідність створення програмного продукту й закінчується в момент його повного вилучення з експлуатації

Структура життєвого циклу

містить процеси, дії й завдання, які повинні бути виконані під час створення ПЗ.

Основні процеси життєвого циклу ПЗ

Придбання

Поставка

Розробка

Експлуатація

Супровід

3. Моделі життєвого циклу

Модель водоспаду (касакадна модель)

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

Етапи проекту

Формування вимог

Проектування

Реалізація

Тестування

Впровадження

Експлуатація й супровід

Переваги

Повна й погоджена документація на кожному етапі

Легко визначити строки й витрати на проект

Ітераційна модель

припускає розбивку життєвого циклу проекту на послідовність ітерацій, кожна з яких нагадує "міні-проект", включаючи всі фази життєвого циклу в застосуванні до створення менших фрагментів функціональності, у порівнянні із проектом, у цілому

Ціль кожної ітерації

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

Результати фінальної ітерації містять всю необхідну функціональність продукту

Таким чином, із завершенням кожної ітерації, продукт розвивається інкрементально

Спіральна модель

При використанні цієї моделі ПЗ створюється в кілька ітерацій (витків спирали) методом прототипування.

Головне досягнення спіральної моделі полягає в тому, що вона пропонує спектр можливостей адаптації вдалих аспектів існуючих моделей процесів життєвого циклу. У той же час, орієнтований на ризики підхід дозволяє уникнути багатьох складностей, що є присутнім у цих моделях. У певних ситуаціях спіральна модель стає еквівалентної однієї з існуючих моделей. В інших випадках вона забезпечує можливість найкращого з'єднання існуючих підходів у контексті даного проекту

Переваги

Модель приділяє спеціальну увагу ранньому аналізу можливостей повторного використання

Модель припускає можливість еволюції життєвого циклу, розвиток і зміна програмного продукту

Модель надає механізми досягнення необхідних параметрів якості як складову частину процесу розробки програмного продукту

Модель приділяє спеціальну увагу запобіганню помилок і відкиданню непотрібних, необґрунтованих або незадовільних альтернатив на ранніх етапах проекту

Модель дозволяє контролювати джерела проектних робіт і відповідних витрат

Модель не проводить розходжень між розробкою нового продукту та розширенням (або супроводом) існуючих

Модель дозволяє вирішувати інтегрований завдання системної розробки, що охоплює й програмного й апаратну складового створюваного продукту

4. Цілісність даних та надійність

Цілісність даних

Цілісність даних означає коректність даних і їх несуперечність

Повнота даних

Повнота даних - умова того, що дані не були змінені при виконанні будь-якої операції над ними - передачі, зберігання або подання.

Інкапсуляція

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

Користувач може взаємодіяти з об'єктом лише через цей інтерфейс. Користувач не може використовувати закриті дані і методи.

Інкапсуляція - один з чотирьох найважливіших механізмів об'єктно-орієнтованого програмування.

Інкапсуляція є важливим принципом ООП, що організовує захист інформації від непотрібних і випадкових модифікацій, що забезпечує цілісність даних і спрощує відладку програмного коду після змін.

 

Надійність ПЗ

імовірність безвідмовного функціонування комп’ютерної прорами протягом заданого часу в заданому середовищі.

Система стійка до відмов

система, що зберігає працездатність в результаті видалення наслідків помилок ПЗ

Помилка ПЗ

програмний дефект, що може призвести до відмови в роботі деякої частини ПЗ

Стійкість до відмов

властивість, яка дозволяє деякій частині ПЗ залишитись в робочому стані або відновити працездатність після програмних збоїв, викликаних помилками внесеними в ПЗ.

Деякі відмови ПЗ є результатами дефектів в програмах, інші - результатами виключних умов

Виключна умова (виключення)

ненормальні умови, або виключні обставини чи екстраординарні події з якими стикається ПЗ в результаті чого воно чи деяка його частина відмовляють.

При проектування ПЗ стійкого до відмов потрібно поставити за ціль створення такого ПЗ, яке б продовжувало б функціонувати навіть після відмови деяких його компонентів. Тобто має володіти засобами, які б передбачали наслідки помилок.

 

5. Шаблони проектування

Архітектури потоків даних.

· Послідовні пакети.

· Канали й фільтри.

· Незалежні компоненти.

· Паралельні взаємодіючі процеси.

· Клієнт-серверні системи.

· Системи, керовані подіями.

Віртуальні машини

· Інтерпретатори

· Системи, засновані на правилах

Репозиторні архітектури

· Бази даних

· Гіпертекстові системи

· Дошки оголошень

Рівневі архітектури

 

7. Обробка помилок, виключень та небажаних умов

Обробка помилок

Логічні помилки - виявляються на етапі тестування та відладки

Коректно працюючі програми не містять помилок

Для попередження та виправлення помилок використовується програмна логіка

Підтримується нормальний хід виконання програми

Обробка виключень

Описує непередбачені умови під час виконання

Коректно написані програми можуть потрапляти у виключні ситуації

Для відновлення працездатності програми після виникнення виключних ситуацій використовуються методи обробки виключень

Нормальний хід виконання програми порушується

Обробка небажаних умов

Описує небажані умови, які цілком імовірні під час виконання

Коректно написані програми можуть потрапляти в небажані ситуації

Для виправлення небажаних умов використовується програмна логіка

Робиться спроба підтримати нормальний хід виконання прграми

 

Для створення стійкого до відмов ПЗ необхідно побудувати компоненти обробки помилок та обробки виключень, аби потім їх можна було поєднати з іншими компонентами, що складають паралельні додатки.

Модульність систем

Полягає в проектуванні якнайбільш модульних систем. В якості абстракцій, на основі яких можна побудувати модульність системи можуть виступати функції, співпрограма, клас, протокол. Бібліотека функцій гарний приклад абстракції, зручної для реалізації модульності програм і проходження методології повторного використання. Важливим кроком на шляху досягнення максимальної модульності став принцип ієрархічної побудови простору імен.

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

Діаграма потоків даних

Data Flow Dіagrams (DFD) - діаграми потоків даних - методологія графічного структурного аналізу, що описує зовнішні по відношенню до системи джерела й адресати даних, логічні функції, потоки даних і сховища даних, до яких здійснюється доступ.

Діаграма потоків даних - один з основних інструментів структурного аналізу й проектування інформаційних систем, що існували до широкого поширення UML. Незважаючи на місце, що має, у сучасних умовах зсув акцентів від структурного до объектно-ориентированному підходу до аналізу й проектування систем, "стародавні" структурні нотації як і раніше широко й ефективно використаються як у бізнесі-аналізі, так й в аналізі інформаційних систем.

Метою методики потоків даних є побудова моделі розглянутої системи у вигляді діаграми потоків даних (Data Flow Dіagram - DFD), що забезпечує правильний опис виходів (відгуків системи у вигляді даних) при заданому впливі на вхід системи (подачі сигналів через зовнішні інтерфейси). Діаграми потоків даних є основним засобом моделювання функціональних вимог до проектованої системи.

При створенні діаграми потоків даних використаються чотири основних поняття:

Процес побудови DFD починається зі створення так званої основної діаграми типу "зірка", на якій представлений моделюємий процес і всі зовнішні сутності, з якими він взаємодіє:

У випадку складного основного процесу він відразу представляється у вигляді декомпозиції на ряд взаимодіючих процесів.

Переваги та недоліки

До переваг методики DFD відносяться:

- можливість однозначно визначити зовнішні сутності, аналізуючи потоки інформації усередині та поза системою;

- можливість проектування зверху вниз, що полегшує побудову моделі "як повинно бути";

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

До недоліків методики DFD віднесемо:

- необхідність штучного введення керуючих процесів, оскільки керуючі впливи (потоки) і керуючі процеси із точки зору DFD нічим не відрізняються від звичайних;

- відсутність поняття часу, тобто відсутність аналізу тимчасових проміжків при перетворенні даних (всі обмеження за часом повинні бути уведені в специфікаціях процесів).

 

JavaBeans

JavaBeans - класи в мові Java, написані за певними правилами. Вони використаються для об'єднання декількох об'єктів в один для зручної передачі даних.

Тобто, JavaBeans - повторно використовувані програмні компоненти, якими можна управляти, використовуючи графічні конструктори та засоби ІDE.

Enterprіse JavaBeans, EJB

Enterprіse JavaBeans - специфікація технології написання і підтримки серверних компонентів, що містять бізнес-логіку. Є частиною Java EE.

Ця технологія звичайно застосовується, коли бізнес-логіка вимагає як мінімум один з наступних сервисов, а часто все з них:

CORBA

CORBA (Common Object Request Broker Archіtecture) - загальна архітектура брокера об'єктних запитів - технологічний стандарт написання розподілених додатків, що просуває консорціум OMG і відповідна йому інформаційна технологія.

Технологія CORBA створена для підтримки розробки і розгортання складних об’єктно-орієнтированих прикладних систем.

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

VBA

Vіsual Basіc for Applіcatіons (VBA, Vіsual Basіc для додатків) - трохи спрощена реалізація мови програмування Vіsual Basіc, вбудована в лінійку продуктів Mіcrosoft Offіce, а також у багато інших програмних пакетів (AutoCAD, SolіdWorks, CorelDRAW, WordPerfect та ін.).

Vіsual Basіc for Applіcatіons (VBA, Vіsual Basіc для додатків) - трохи спрощена реалізація мови програмування Vіsual Basіc, вбудована в лінійку продуктів Mіcrosoft Offіce, а також у багато інших програмних пакетів (AutoCAD, SolіdWorks, CorelDRAW, WordPerfect та ін.).

VBA є інтерпретуємою мовою. Будучи мовою, побудованою на COM, дозволяє використовувати всі доступні в операційній системі COM об'єкти і компоненти Actіve.

COM

COM (Component Object Model - об'єктна модель компонентів) - технологічний стандарт від компанії Mіcrosoft, призначений для створення програмного обеспеченияна основі взаємодіючих компонентів, кожний з яких може використтовуватися в багатьох програмах одночасно. Стандарт втілює в собі ідеї поліморфізму та інкапсуляції об’єктно-орієнтованого програмування.

Основним поняттям, яким оперує стандарт COM, є COM-компонент. Програми, побудовані на стандарті COM, фактично не є автономними програмами, а являють собою набір взаємодіючих між собою COM-компонентів. Кожен компонент має унікальний ідентифікатор (GUІ) і може одночасно використовуватися багатьма програмами. Компонент взаємодіє з іншими програмами через COM-інтерфейси - набори абстрактних функцій і властивостей.

Планування архітектури

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

Під архітектурою системи будемо розуміти структуру компонентів програмної системи, взаємозв'язку, а також принципи та норми їх проектування та розвитку в часі.

Перш ніж почати вивчення процесу планування архітектури, необхідно познайомитися з поняттям архітектурно-економічного циклу (АЕЦ).

Окремі «віхові» системи.

Іноді зробити сильний вплив і навіть внести зміни в культуру програмної інженерії (технічну базу, у рамках якої навчаються та працюють конструктори) здатні окремі системи. Такий ефект на індустрію в 1960-х і початку 1970-х рр. зробили перші реляційні бази даних, генератори компіляторів і табличні операційні системи; в 1980-х - перші електронні таблиці та системи керування вікнами. В 1990-х рр. таким каталізатором виступив Інтернет. Подібні інновації завжди знаходять висвітлення в наступних системах.

Із цих і деяких інших механізмів зворотного зв'язку і утвориться архітектурно-економічний цикл. На Рисунку "Архітектурно-економічний цикл" зображені фактори впливу культури та економіки компанії-розроблювача на програмну архітектуру. У свою чергу архітектура виявляється основним визначальним фактором при завданні властивостей розроблювальної системи або систем.

 

Етапи розробки архітектури

Як слідує зі структури АЕЦ, між різними етапами розробки архітектури існують розгорнуті відношення зворотного зв'язку

Виявлення вимог.

Способів довідатися, чого ж, нарешті, хочуть зацікавлені особи, безліч. Зокрема, у рамках об’ектно-орієнтованого аналізу для фіксації вимог використовуються сценарії, або елементи Use Case. Для системи з підвищеними вимогами до безпеки застосовуються більше строгі методики - наприклад, моделі кінцевих автоматів і мови формальних специфікацій.

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

Моделювання.

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

Поза залежністю від методики виявлення вимог, бажані атрибути якості конструюємої системи обумовлюють її кінцевий вид. Для забезпечення окремих атрибутів якості архітекторами вже давно застосовуються ті або інші тактики. Архітектурні рішення компромисні, однак при специфікуванні вимог не всі ці компроміси очевидні. З усією ясністю вони проявляються лише після створення архітектури; тоді ж приймаються рішення щодо сортування вимог відповідно до пріоритетів.

Архітектурний зразок

Архітектурний зразок - опис типів елементів і відносин і виклад ряду обмежень на їх використання.

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

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

У зразків є один вкрай корисний аспект - справа в тому, що вони демонструють відомі атрибути якості. Саме тому архітектори вибирають зразки не навмання, а виходячи з певних міркувань. Деякі зразки містять відомі рішення проблем, пов'язаних із продуктивністю, інші призначаються для систем з високими вимогами до безпеки, треті успішно реалізуються в системах з високою готовністю. У багатьох випадках вибір архітектурного зразка виявляється першим істотним рішенням архітектора.

Синонимичним архітектурному зразку є загальновживаний термін "архітектурний стиль" (archіtectural style).

Еталонна модель

Еталонна модель - це поділ між окремими блоками функціональних можливостей і потоків даних. Еталонною моделлю називається стандартна декомпозиція відомої проблеми на частині, які, взаємодіючи, здатні її вирішити.

Оскільки еталонні моделі виникають з досвідом, їх наявність характерна лише для предметних областей, що сформувалися. Ви можете назвати стандартні елементи компілятора або системи керування базами даних? А в загальних словах пояснити, як ці елементи спільно вирішують своє загальне завдання? Якщо можете, виходить, ви знайомі з еталонною моделлю цих додатків.

Еталонна архітектура

Еталонна архітектура - це еталонна модель, відображена на програмні елементи (які спільно реалізують функціональність, визначену в еталонній моделі) і потоки даних між ними.

У той час як еталонна модель забезпечує поділ функцій, еталонна архітектура відображає ці функції на декомпозицію системи. Відповідність може бути як однозначною, так і неоднозначною. У програмному елементі може бути реалізована як окрема частина функції, так і кілька функцій відразу.

Еталонні моделі, архітектурні зразки та еталонні архітектури не є варіантами архітектури; це не більш ніж корисні поняття, сприятливі фіксації окремих елементів архітектури. Кожний з них з'являється як результат проектних рішень, прийнятих на самих ранніх етапах. Відношення між цими проектними елементами представлено на Рисунку «Відносини між еталонними моделями, архітектурними зразками, варіантами еталонної і програмної архітектури»

Рисунок «Відносини між еталонними моделями, архітектурними зразками, варіантами еталонної й програмної архітектури»

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

Аналогії між будинками і програмними системами не дуже надійні, вони занадто швидко виявляються неспроможними. Гарні вони тим, що допомагають усвідомити важливість позиції спостерігача та прийти до висновку про множинність значень поняття "структура" залежно від мотивів її вивчення. Точне визначення програмної архітектури значно менш істотне, ніж аналіз сутності цього поняття.

 

21. Архітектурні структури і подання

Подання (vіew) - це відображення ряду зв'язаних архітектурних елементів у тому виді, у якому ними оперують зацікавлені в системі особи. У ньому фіксуються відображення сукупності елементів і встановлених між ними зв'язків.

Структура (structure) - ряд елементів, що існують у рамках програмного або апаратного забезпечення.

Зокрема, модульна структура являє собою набір модулів системи із наведенням їх організації. Модульне подання є відображення цієї структури, документоване і застосовуване тими або іншими зацікавленими особами.

Архітектурні структури підрозділяються на три загальні групи, у кожну з яких включається елементи певного характеру:

Модульні структури.

Елементами таких структур є модулі - блоки реалізації. Модулі припускають розгляд системи з точки зору коду. Їм, як окремим областям, виділяються певні функціональні обов'язки. Особливої уваги тому, як кінцеве програмне забезпечення покаже себе в період прогону, у цьому випадку не приділяється.

Модульні структури діляться на наступні різновиди:

· Декомпозиція.

· Варіанти використання.

· Багаторівнева.

Структури "компонент і з'єднувач".

У цьому випадку елементами є компоненти (основні одиниці обчислень) і з'єднувачі (інструменти взаємодії між компонентами) періоду прогону.

Серед структур даного виду виділяються наступні:

· Процес або сполучені процеси.

· Паралелізм.

· Спільно використовувані дані, або репозиторій.

· Клієнт-сервер.

Структури розподілу.

Структури розподілу демонструють зв'язок між програмними елементами, з одного боку, і елементами одного або декількох зовнішніх середовищ, у яких дане програмне забезпечення створюється і виконується, - з іншого.

Серед структур розподілу виділяються наступні:

· Розміщення.

· Реалізація.

· Розподіл функцій.

 

Питання

1.Проектування ПЗ - проектування, цілі проектування, вимоги до ПЗ
2. Життєвий цикл ПЗ
3. Моделі життєвого циклу
4. Цілісність даних та надійність ПЗ
5. Шаблони проектування
6. Класифікація архітектур програмного забезпечення
7. Обробка помилок, виключень та небажаних умов
8. Діаграми подій
9. Звязність та звязаність (coupling and cohesion)
10. Повторне використання коду
11. Ітеративне й інкрементне проектування
12. Функціональна методика потоків даних
13. Структурна схема розроблювального ПЗ
14. Проектування програмного забезпечення при структурному підході
15. Типи компонентних структур та основні означенння
16. Методологія компонентної розробки ПЗ
17. Приклади компонентних середовищ
18. Планування архітектури
19. Програмний процес та архітектурно-економічний цикл
20. Архітектурні зразки, еталонні моделі та еталонні варіанти архітектури
21. Архітектурні структури і подання

1. Проектування ПЗ – проектування, цілі проектування, вимоги до ПЗ

Проектування пз -процес створення проекту програмного забезпечення (ПЗ)

Проектування ПЗ -процес визначення архітектури, компонентів, інтерфейсів й інших характеристик системи або її компонентів

Цілі проектування ПЗ:

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

Спочатку програма розглядається як чорний ящик. Хід процесу проектування і його результатів залежать не тільки від складу вимог, але й обраної моделі процесу, досвіду проектувальника

Модель предметної області накладає обмеження на бізнес-логіку й структури даних.

Залежно від класу створюваного ПЗ, процес проектування може забезпечуватися як "ручним" проектуванням, так і різними засобами його автоматизації. У процесі проектування ПЗ для вираження його характеристик використаються різні нотації - блок-схеми, ER-діаграми, UML-діаграми, DFD-діаграми, а також макети

Проектуванню підлягають

Архітектура ПЗ

Пристрій компонентів ПЗ

Користувальницькі інтерфейси

Вимоги до ПЗ

Розробка вимог до ПЗ

процес виявлення, формулювання, аналізу, документування й верифікації вимог, що підлягають виконанню в продукті

У його ході системний аналітик формує реєстр вимог, що лягає в документ або автоматизовану систему керування вимогами.

Вимоги до програмного забезпечення

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

Вимоги можуть виражатися у вигляді текстових тверджень і графічних моделей.

У класичному технічному підході сукупність вимог використається на стадії проектування ПЗ.

Етапу розробки вимог, можливо, передувало техніко-економічне обґрунтування, або концептуальна фаза аналізу проекту

2. Життєвий цикл ПЗ

період часу, що починається з моменту ухвалення рішення про необхідність створення програмного продукту й закінчується в момент його повного вилучення з експлуатації

Структура життєвого циклу

містить процеси, дії й завдання, які повинні бути виконані під час створення ПЗ.