Содержание

Слайд 2

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

ЛЕКЦІЯ 2. ОСОБЛИВОСТІ ПРОЕКТУВАННЯ АПЗ
1. Проектування та його

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ЛЕКЦІЯ 2. ОСОБЛИВОСТІ ПРОЕКТУВАННЯ АПЗ 1. Проектування та його
особливості
Проектування - процес створення проекту архітектури, прототипу, прообразу майбутнього об'єкта, стану та способів його виготовлення. У проектуванні застосовують системний підхід, який полягає у встановлені структури системи, типу зв'язків, визначені атрибутів, аналізуванні впливів зовнішнього середовища.
Проектування  - це комплекс робіт який складається з пошуку, досліджень, розрахунків та розрахування з метою отримання опису достатнього для створення нового об'єкту або виробу, його реконструкції, модернізації, що відповідає заданим вимогам.
У техніці - розробка проектної, конструкторської та іншої технічної документації, призначеної для забезпечення будівництва, створення нових видів та зразків.
В процесі проектування виконуються технічні та економічні розрахунки, схеми, графіки, пояснювальні записки, кошториси, калькуляції та описи.

Слайд 3

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

ТЕХНІЧНЕ ЗАВДАННЯ (ТЗ)
Проект (від лат. Projectus -

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ТЕХНІЧНЕ ЗАВДАННЯ (ТЗ) Проект (від лат. Projectus - кинутий
кинутий вперед) - це обмежена в часі, ресурсах та вимогах якості унікальна сукупність процесів, направлена на створення нової архітектури.
В залежності від сфери здійснення проекту виділяють кілька типів проектів:
- технічний проект - направлений на створення нового продукту;
організаційний проект - направлений на створення або реорганізацію організації;
соціальний проект - направлений на отримання певного соціального ефекту.
В залежності від масштабу виділяють наступні типи проектів:
малі проекти, мають бюджет до 0.5 млн евро;
середні проекти, мають бюджет до 0.5 млрд евро;
мегапроекти, мають бюджет більше 0.5 млрд евро.

Слайд 4

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Слайд 5




АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Проекти також поділяються залежно до

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Проекти також поділяються залежно до часу реалізації: короткострокові; довгострокові).
часу реалізації:
короткострокові;
довгострокові).
За країнами учасників проекту:
національні;
міжнародні.
Проекти можуть бути об'єднані в:
програму проектів для досягнення єдиного результату;
портфель проектів організації для ефективнішого управління, портфель проектів може включати також програми.
Досягнення мети проекту вимагає отримання результатів, що відповідають певним заздалегідь вимогам, у тому числі обмеження на отримання результатів, таких як час, гроші і ресурси.
Вигоди від реалізації проекту - грошове вираження сукупної вартості всіх товарів, послуг і інших вигод, що виникають як результат капіталовкладень у даний проект.

Слайд 6

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Слайд 7

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Слайд 8




АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Стадії проектування (цикл розробки ПЗ)
1.

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Стадії проектування (цикл розробки ПЗ) 1. Аналіз вимог -
Аналіз вимог - починається із стадії аналізу, під час якого учасники процесу обговорюють вимоги, що висуваються до кінцевого продукту.
Мета ціє стадії – визначення детальних вимог до системи. Окрім того, необхідно впевнитися в тому, що всі учасники вірно зрозуміли поставлені задачі і те, як саме кожна вимога буде реалізована на практиці.
Таким чином, цей етап передбачає збір вимог до програмного забезпечення, що розробляється, їх систематизацію, документування, аналіз, а також виявлення ти вирішення протиріч.

Слайд 9

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

2. Проектування.
На стадії проектування (яка також називається стадією дизайну та

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 2. Проектування. На стадії проектування (яка також називається стадією
архітектури) програмісти та системні архітектори, керуючись вимогами, розробляють високорівневий дизайн системи.
Різноманітні технічні питання, які виникають в процесі проектування, обговорюються зі всіма зацікавленими сторонами, включаючи замовника. Визначаються технології, які будуть використовуватися в проекті, завантаженість команди, обмеження, часові рамки та бюджет. Відповідно з уточненими вимогами обираються максимально відповідні проектні рішення.
Затверджений дизайн системи визначає перелік програмних компонентів, які необхідно розробити, взаємодію з третіми сторонами, функціональні характеристики програми, бази даних, які необхідно викристовувати та багато іншого.

Слайд 10

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Дизайн, як правило, фіксується окремим документом – дизайн-специфікацією (Design Specification

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Дизайн, як правило, фіксується окремим документом – дизайн-специфікацією (Design
Document, DSD).
На цьому етапі спрощення процесу візуалізації використовуються як так звані нотації – схематичні зображення системи, що розробляється. Основі нотації:
– Блок-схеми;
– ER-діаграми;
– UML-діаграми;
– Макети – наприклад, намальований в фотошопі прототип сайту.

Слайд 11




АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Розробка та програмування
Після того як вимоги і

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Розробка та програмування Після того як вимоги і дизайн
дизайн продукту затверджені, відбувається перехід до наступної стадії життєвого циклу – безпосередньої розробки. Тут починається написання програмістами коду програми відповідно до визначених раніше вимог.
Системні адміністратори налаштовують програмне оточення, front-end програмісти розробляють користувальницький інтерфейс програми і логіку її взаємодії з сервером.
Окрім того, програмісти пишуть Unit-тести для перевірки правильності роботи коду кожного компонента системи, проводять рев’ю написаного коду, створюють білди і розгортають готове ПЗ в програмному середовищі. Цей цикл повторюється до тих пір, поки всі вимоги не будуть реалізовані.

Слайд 12




АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Програмування передбачає чотири основні стадії:
1) Розробка алгоритмів – фактично,

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Програмування передбачає чотири основні стадії: 1) Розробка алгоритмів –
створення логіки роботи програми;
2) Написання джерела коду;
3) Компіляція – перетворення в машинний код;
4) Тестування та відладка – мова йде, головним чином, про юніт-тестування.

Слайд 13

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

4. Документація
Цей етап виділяють достатньо умовно, оскільки, як ми бачили,

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 4. Документація Цей етап виділяють достатньо умовно, оскільки, як
ті чи інші документи створюються на всіх стадіях життєвого циклу програми.
Всього існує чотири рівня документації:
– Архітектурна (проектна) - документи, що описують моделі, методології, інструменти та засоби розробки, обрані для даного проекту.
– Технічна – вся документація, що супроводжує розробку. Сюди входять різноманітні документи, що пояснюють розробку системи на рівні окремих модулів (HTML-документи).

Слайд 14

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

– Користувацька – включає довідникові та пояснюючі матеріали, необхідні кінцевому користувачу

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ – Користувацька – включає довідникові та пояснюючі матеріали, необхідні
для роботи з системою (Readme та Userguide, розділ довідки по програмі).
– Маркетингова – включає рекламні матеріали, які супроводжують випуск продукту. Її мета – в яскравій формі презентувати функціональність та конкурентні переваги продукту.

Слайд 15




АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

5. Тестування.
Тестувальники займаються пошуком дефектів у програмному

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 5. Тестування. Тестувальники займаються пошуком дефектів у програмному забезпеченні
забезпеченні і порівнюють описану у вимогах поведінку системи з реальною. У фазі тестування виявляються пропущені при розробці баги. При виявленні дефекту, тестувальник складає звіт про помилку, який передається розробникам. Останні його виправляють, після чого тестування повторюється – але цього разу для того, щоб переконатися, що проблема була виправлена, і саме виправлення не стало причиною появи нових дефектів в продукті.
Тестування повторюється до тих пір, поки не будуть досягнуті критерії його закінчення.

Слайд 16

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

6. Впровадження та супровід
Коли програма протестована і в ній більше

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 6. Впровадження та супровід Коли програма протестована і в
не залишилося серйозних дефектів, приходить час релізу і передачі її кінцевим користувачам. Після випуску нової версії програми в роботу включається відділ технічної підтримки. Його співробітники забезпечують зворотній зв’язок з користувачами, їх консультування та підтримку. Крім того, команда технічної підтримки допомагає збирати та систематизувати різні метрики – показники роботи програми в реальних умовах.

Слайд 17

КАФЕДРА
ІПЗ

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

ТЕХНІЧНЕ ЗАВДАННЯ (ТЗ)
- (англ. statement of

КАФЕДРА ІПЗ АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ТЕХНІЧНЕ ЗАВДАННЯ (ТЗ) - (англ. statement of
work; SOW) - документ, що встановлює основне призначення, показники якості, техніко-економічні та спеціальні вимоги до виробу, обсягу, стадії розроблення та складу конструкторської документації.
При розробці технічного завдання використовуються наступні інформаційні матеріали:
- науково-технічна інформація;
патентна інформація;
характеристика ринку збуту;
- характеристика виробництва (технічна оснащеність, кваліфікація кадрів, технологічна дисципліна), на якому виріб планується виготовляти.
При розробці технічного завдання на вироби підвищеної складності попередньо проробляється так званий аванпроект, який дозволяє попередньо поглиблено пропрацювати комплекс питань, що визначають необхідність та доцільність створення такого виробу. Розробка аванпроекту повинна гарантувати можливість створення продукції, що відповідає за техніко-економічними показниками світовому рівню.

Слайд 18

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Згідно з чинними стандартами ТЗ повинно включати в себе

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Згідно з чинними стандартами ТЗ повинно включати в себе
такі відомості про об'єкт розробки:
1. Найменування об'єкта розробки, та область застосування.
- повне найменування об'єкта та умовне позначення;
- шифр теми або шифр (номер) договору;
- перелік документів, на підставі яких створюється проект, ким і коли затверджені ці документи;
- планові терміни початку та закінчення робіт із створення об'єкта.
2. Підстава для розробки та назва проектної організації:
- найменування підприємств розробника і замовника системи та їхні реквізити;
- перелік юридичних та фінансових документів, на підставі яких створюється система, ким і коли затверджені ці документи;
- відомості про джерела та порядок фінансування робіт.

Слайд 19




АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

3. Мета розробки.
4. Джерела розробки. Тут повинні

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 3. Мета розробки. 4. Джерела розробки. Тут повинні бути
бути перераховані документи та інформаційні матеріали (техніко-економічне обґрунтування, інформаційні посилання на вітчизняні і зарубіжні аналоги та ін.), на підставі яких розроблялося ТЗ і які мають бути використані при створенні системи.
5. Технічні вимоги, які включають:
- склад об'єкта та вимоги до його конструктивного виконання;
- показники призначення та економічного використання матеріалів;
вимоги до надійності;
моги безпеки при роботі обладнання;
- вимоги до складових частин продукції і експлуатаційних матеріалів;
- вимоги патентної чистоти;
- вимоги експлуатації, вимоги до технічного обслуговування і ремонту;
- вимоги до категорії якості.

Слайд 20

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

6. Економічні показники:
- гранична ціна;
- економічний ефект;
термін окупності витрат

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 6. Економічні показники: - гранична ціна; - економічний ефект;
на розробку
і освоєння об'єкта;
допустима річна потреба в об'єкті
проектування .
7. Порядок контролю і приймання об'єкта:
- види, склад, обсяг і методи випробувань системи та її складових частин (види випробувань відповідно до чинних норм, які поширюються на систему, що розробляється);
- загальні вимоги до приймання робіт (продукції) за стадіями (перелік учасників, місце і терміни проведення), порядок узгодження і затвердження приймальної документації;
- статус приймальної комісії.

Слайд 21

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

ЕКСКІЗНИЙ ПРОЕКТ
Ескізний проект (англ. Preliminary design) - проектна конструкторська

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ЕКСКІЗНИЙ ПРОЕКТ Ескізний проект (англ. Preliminary design) - проектна
документація, яка містить принципові конструктивні рішення і дає загальне уявлення про будову та принцип дії виробу, а також дані, що визначають його відповідність призначенню.
Ескізний проект розробляють з метою встановлення принципових (конструктивних, схемних) рішень виробу, що дають загальне уявлення про принцип роботи або будову виробу, коли це доцільно зробити до розробки технічного проекту чи робочої документації.
На стадії розробки ескізного проекту розглядають варіанти виробу і (або) його складових частин. Ескізний проект може розроблятися і без розгляду на цій стадії різних варіантів.
У комплект документів ескізного проекту включають конструкторські документи, згідно з ДСТУ передбачені технічним завданням і протоколом розгляду технічної пропозиції.

Слайд 22

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Слайд 23




АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

При розробці ескізного проекту виконують роботи,

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ При розробці ескізного проекту виконують роботи, необхідні для реалізації
необхідні для реалізації поставлених до виробу вимог і дозволяють встановити принципові рішення. Перелік необхідних робіт визначається розробником в залежності від характеру і призначення виробу. У загальному випадку при розробці ескізного проекту проводять наступні роботи:
- виконання варіантів можливих рішень,;
- виготовлення і випробування макетів і (або) розробка та аналіз електронних макетів з метою перевірки принципів роботи виробу його складових частин;
- розробку та обґрунтування технічних рішень, спрямованих на забезпечення показників надійності, установлених технічним завданням та технічною пропозицією;
- оцінку виробу;

Слайд 24

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

перевірку варіантів на патентну частоту і конкурентоспроможність, оформлення заявок на

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ перевірку варіантів на патентну частоту і конкурентоспроможність, оформлення заявок
винаходи;
- перевірку відповідності варіантів вимогам техніки безпеки;
- порівняльну оцінку розглянутих варіантів;
вибір оптимального варіанту (варіантів) виробу, обґрунтування вибору, прийняття принципових рішень;
підтвердження пропонованих до виробу вимог (технічних характеристик, показників якості тощо), установлених технічним завданням і технічною пропозицією, і визначення техніко-економічних характеристик і показників, не встановлених технічним завданням і технічною пропозицією;
виявлення на основі прийнятих принципових рішень нових виробів і матеріалів, які повинні бути розроблені іншими підприємствами (організаціями), розроблення технічних вимог до цих виробів і матеріалів.

Слайд 25

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

ТЕХНІЧНИЙ ПРОЕКТ
Технічний проект - стадія розробки виробу і проектна

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ТЕХНІЧНИЙ ПРОЕКТ Технічний проект - стадія розробки виробу і
конструкторська документація, яка містить остаточне технічне рішення і дає повне уявлення про будову розроблюваного виробу або стадія створення автоматизованої системи.
Технічний проект розробляється на підставі затвердженого завдання на проектування та техніко-економічного обґрунтування.
Основні етапи виконання робіт при розробці технічного проекту:
- розробка конструкторської документації технічного проекту з присвоєнням документам літери «Т».
- виготовлення та випробування макетів (за необхідності).
- розгляд та затвердження технічного проекту.

Слайд 27

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

2. Життєвий цикл АПЗ
Проект може бути розбитий як

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ 2. Життєвий цикл АПЗ Проект може бути розбитий як
на підпроекти, так і на фази.
Сукупність фаз являє собою життєвий цикл проекту, який має 5 фаз:
- ініціація (англ. Initiating);
планування (англ. Planning);
виконання (англ. Executing);
контроль і моніторинг (англ. Controlling and Monitoring);
завершення (англ. Closing).
Життєвий цикл АПЗ - період часу, який починається з моменту прийняття рішення про необхідність створення певної архітектури і закінчується в момент її повного вилучення з експлуатації

Слайд 28

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Життєвий цикл програмного забезпечення (також має назву цикл розробки) –

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Життєвий цикл програмного забезпечення (також має назву цикл розробки)
це умовна схема, що включає в себе окремі етапи, які є стадіями розвитку процесу створення ПЗ. При цьому, на кожному етапі виконуються різні дії.
Мета використання моделі життєвого циклу – створити ефективний, економічно вигідний та якісний програмний продукт.

Слайд 29

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Стадія - частина процесу створення АПЗ, обмежена певними часовими

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Стадія - частина процесу створення АПЗ, обмежена певними часовими
рамками і закінчується випуском конкретного продукту, що визначається заданими для даної стадії вимогами.
Виділяють наступні стадії:
1) Початкова стадія - встановлюється область застосування системи і визначаються граничні умови. На початковій стадії ідентифікуються всі функціональні можливості системи і проводиться опис найбільш істотних з них.
2) Стадія уточнення - проводиться аналіз прикладної області, розробляється архітектурна основа інформаційної системи.
3) Стадія конструювання - розробляється закінчений виріб, готове до передачі користувачеві.
По закінченні цієї стадії визначається працездатність розробленого програмного забезпечення.
4) Стадія передачі в експлуатацію.

Слайд 30




АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

Модель життєвого циклу АПЗ - структура,

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Модель життєвого циклу АПЗ - структура, що визначає послідовність
що визначає послідовність виконання та взаємозв'язку процесів, дій і завдань протягом життєвого циклу. Модель життєвого циклу залежить від специфіки, масштабу і складності проекту та специфіки умов, в яких система створюється і функціонує.
Модель ЖЦ АПЗ включає в себе:
- стадії;
- результати виконання робіт на кожній стадії;
- ключові події - точки завершення робіт і прийняття рішень.

Слайд 31

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

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

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ В даний час відомі і використовуються наступні моделі життєвого
циклу:
Каскадна модель (водоспад) - передбачає послідовне виконання всіх етапів проекту в чітко фіксованому порядку. Перехід на наступний етап означає повне завершення робіт на попередньому етапі.
При моделюванні за принципом «водоспаду» робота над проектом рухається лінійно і послідовно. Перевагою такого підходу є простота його реалізації, недоліком — накопичення можливих на ранніх етапах помилок до моменту закінчення проекту і, як наслідок, зростання ризику провалу проекту, збільшення вартості проекту.

Слайд 32

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ


Поетапна модель з проміжним контролем - розробка ІС

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Поетапна модель з проміжним контролем - розробка ІС ведеться
ведеться ітерациями з циклами зворотного зв'язку між етапами.
Ітеративний підхід (англ. Iteration - повторення) - виконання робіт паралельно з безперервним аналізом отриманих результатів і коригуванням попередніх етапів роботи.
Проект при цьому підході в кожній фазі розвитку проходить повторюваний цикл: Планування - Виконання - Контроль і оцінка (англ. plan-do-check-act cycle).

Слайд 33




АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

V-подібна модель (V-model)
Суть цієї моделі полягає в

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ V-подібна модель (V-model) Суть цієї моделі полягає в тому,
тому, що процеси на всіх етапах контролюються, щоб переконатися в можливості переходу на наступний рівень. Вже на стадії написання вимог починається процес тестування.

Слайд 34

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ


Даний підхід дозволяє боротися з невизначеністю, знімаючи її етап

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Даний підхід дозволяє боротися з невизначеністю, знімаючи її етап
за етапом, і перевіряти правильність технічного, маркетингового або будь-якого іншого рішення на ранніх стадіях.

Слайд 35

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ


Переваги ітеративного підходу:
- зниження впливу серйозних ризиків на ранніх

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Переваги ітеративного підходу: - зниження впливу серйозних ризиків на
стадіях проекту, що веде до мінімізації витрат на їх усунення;
організація ефективного зворотного зв'язку проектної команди зі споживачем, що збільшує вірогідність створення продукту, який реально відповідає їх потребам;
акцент зусиль на найбільш важливі та критичні напрямки проекту;
безперервне ітеративний тестування, що дозволяє оцінити успішність всього проекту в цілому;
раннє виявлення конфліктів між вимогами, моделями і реалізацією проекту;
більш рівномірне завантаження учасників проекту;
ефективне використання накопиченого досвіду;
реальна оцінка поточного стану проекту і, як наслідок, більша впевненість замовників і безпосередніх учасників в його успішному завершенні.

Слайд 36




АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ


Спіральна модель - на кожному витку

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Спіральна модель - на кожному витку спіралі виконується створення
спіралі виконується створення чергової версії продукту, уточнюються вимоги проекту, визначається його якість, і плануються роботи наступного витка.
Особливу увагу приділяється початковим етапам розробки - аналізу та проектуванню, де реалізація тих чи інших технічних рішень перевіряється і обгрунтовується за допомогою створення прототипів (макетування).

Слайд 37

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ


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

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Усі етапи життєвого циклу при спіральної моделі йдуть витками,
на кожному з яких відбуваються проектування, кодування, дизайн, тестування і т. д.

Слайд 38




АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ


В спіральній моделі розглядається залежність

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ В спіральній моделі розглядається залежність ефективності проекту від його
ефективності проекту від його вартості з часом. На кожному витку спіралі виконується створення чергової версії продукту, уточнюються вимоги проекту, визначається його якість і плануються роботи наступного витка.
Модель застосовують в сферах, що дозволяють постійне оновлення продукту проекту, наприклад — при розробці програмного забезпечення.

Слайд 39

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ


Інкрементна модель
Принцип, що лежить в основі інкрементной моделі, має

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Інкрементна модель Принцип, що лежить в основі інкрементной моделі,
на увазі розширення можливостей, добудовування модулів і функцій програми. Буквальний переклад слова інкремент: «збільшення на один».
Це «збільшення на один» застосовується в тому числі для позначення версій продукту.

Слайд 40




АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ


Інкрементна модель (Incremental model)
Відповідно до інкрементної

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Інкрементна модель (Incremental model) Відповідно до інкрементної моделі (англ.
моделі (англ. Increment - збільшення, прирощення) програмне забезпечення розробляється з лінійною послідовністю стадій, але в кілька інкрементів (версій). Таким чином поліпшення продукту проходить заплановано весь час, поки життєвий цикл розробки ПЗ не завершиться.
Вимоги до системи визначаються на самому початку роботи, після чого процес розробки проводиться у вигляді послідовності версій, кожна з яких є закінченим і працездатним продуктом.

Слайд 41

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ


Гнучка модель (Agile model)
Являє собою сукупність різних підходів до

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Гнучка модель (Agile model) Являє собою сукупність різних підходів
розробки ПЗ. Включає серії підходів до розробки програмного забезпечення, орієнтованого на використання ітеративної розробки (в Scrum ітерації називаються спринтами), динамічне формування вимог і забезпечення їхньої реалізації в результаті постійної взаємодії всередині самоорганізованих робочих груп, що складаються з фахівців різного профілю. Однією з основних ідей Agile є взаємодія всередині команди і з замовником напряму.

Слайд 42




АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ


Скрам (Scrum)
Скрам - це гнучка модель

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Скрам (Scrum) Скрам - це гнучка модель розробки ПЗ,
розробки ПЗ, в якій робиться акцент на якісному контролі процесу розробки.
Ролі в методології (Scrum Master, Product Owner, Team) дозволяють чітко розподілити обов'язки в процесі розробки. За успіх Scrum в проєкті відповідає Scrum Master і є сполучною ланкою між менеджментом і командою. За розробку продукту відповідає Product Owner, який також ставить завдання і приймає остаточні рішення для команди.

Слайд 43

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

ЗАПИТАННЯ?

АРХІТЕКТУРА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ ЗАПИТАННЯ?
Имя файла: Lection-2.pptx
Количество просмотров: 29
Количество скачиваний: 0