Главная страница
Навигация по странице:

  • Модель ЖЦ ПЗ включає в собі

  • Моделі життєвого циклу ПО . Водопадна (каскадна, послідовна) модель

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

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

  • Методології розробки ПЗ

  • Лекція № 2

  • конспект лекцій (ТСПП). Конспект лекцій з дисципліни 07 технологія створення програмних продуктів напряму 050101 Компютерні науки


    Скачать 14.87 Mb.
    НазваниеКонспект лекцій з дисципліни 07 технологія створення програмних продуктів напряму 050101 Компютерні науки
    Анкорконспект лекцій (ТСПП).docx
    Дата15.12.2017
    Размер14.87 Mb.
    Формат файлаdocx
    Имя файлаконспект лекцій (ТСПП).docx
    ТипКонспект
    #11579
    страница3 из 62
    1   2   3   4   5   6   7   8   9   ...   62

    Основні процеси життєвого циклу програмного продукту.


    Стандарт ISO / IEC 12207 / і його застосування

    Стандарт ISO / IEC 12207:1995 "Information Technology - Software Life Cycle Processes" є основним нормативним документом, який регламентує склад процесів життєвого циклу ПЗ. Він визначає структуру життєвого циклу, що містить процеси, дії і завдання, які повинні бути виконані під година створення ПЗ.

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

    Основні:

    • Придбання (дії і завдання замовника, що здобуває ПО)

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

    • Розробка (дії і завдання, що виконуються розробником: створення ПО, оформлення проектної та експлуатаційної документації, підготовка тестових та навчальних матеріалів і т. д.)

    • Експлуатація (дії і завдання оператора - організації, що експлуатує систему)

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



    1.3. Допоміжні основні процеси (що підтримують) процеси життєвого циклу програмного продукту


    Допоміжні

    • Документування (формалізований опис інформації, створеної протягом ЖЦ ПО)

    • Управління конфігурацією (застосування адміністративних і технічних процедур на всьому протязі ЖЦ ПО для визначення стану компонентів ПЗ, управління його модифікаціями).

    • Забезпечення якості (забезпечення гарантій того, що ІС і процеси її ЖЦ відповідають заданим вимогам та затвердженим планам)

    • Верифікація (визначення того, що програмні продукти, які є результатами певної дії, повністю задовольняють вимогам або умовам, обумовленим попередніми діями)

    • Атестація (визначення повноти відповідності заданих вимог і створеної системи їх конкретному функціональному призначенню)

    • Спільна оцінка (оцінка стану робіт за проектом: контроль планування та управління ресурсами, персоналом, апаратурою, інструментальними засобами)

    • Аудит (визначення відповідності вимогам, планам і умів договору)

    • Дозвіл проблем (аналіз і рішення проблем, незалежно від їх походження чи джерела, які виявлені в ході розробки, експлуатації, супроводу або інших процесів)



    1.4. Організаційні процеси життєвого циклу програмного продукту


    Організаційні

    • Управління (дії і завдання, які можуть виконуватися будь-якою стороною, що управляє своїми процесами)

    • Створення інфраструктури (вибір та супровід технології, стандартів та інструментальних засобів, вибір і установка апаратних і програмних засобів, що використовуються для розробки, експлуатації чи супроводу ПО)

    • Удосконалення (оцінка, вимір, контроль та вдосконалення процесів ЖЦ)

    • Навчання (початкове навчання і чимдалі постійне підвищення кваліфікації персоналу)

    Кожен процес включає ряд дій. Наприклад, процес придбання охоплює наступні дії:

    1. Ініціювання придбання

    2. Підготовка заявочних пропозицій

    3. Підготовка та коригування договору

    4. Нагляд за діяльністю постачальника

    5. Приймання та завершення робіт

    Кожна дія включає ряд завдань. Наприклад, підготовка заявочних пропозицій повинна передбачати:

    1. Формування вимог до системи

    2. Формування списку програмних продуктів

    3. Встановлення умів і догод

    4. Опис технічних обмежень (середовище функціонування системи і т. д.)



    1.5. Взаємозв'язок між процесами життєвого циклу програмного продукту


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

    Стандарт ДСТУ ISO / IEC 12207-99 не пропонує конкретну модель життєвого циклу. Його положення є загальними для будь-яких моделей життєвого циклу, методів і технологій створення ІС. Він описує структуру процесів життєвого циклу, не конкретизуючи, як реалізувати або виконати дії і завдання, включені в ці процеси.

    Модель ЖЦ ПЗ включає в собі:

    • Стадії;

    • Результати виконання робіт на кожній стадії;

    • Ключові події - точки завершення робіт і прийняття рішень.

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

    На кожній стадії можуть виконуватися декілька процесів, визначених у стандарті ДСТУ ISO / IEC 12207-99, і навпаки, один і тій же процес може виконуватися на різних стадіях. Співвідношення між процесами і стадіями також визначається використовуваної моделлю життєвого циклу ПЗ.

    Моделі життєвого циклу ПО. Водопадна (каскадна, послідовна) модель

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

    Етапи проекту відповідно до каскадної моделлю:

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

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

    • Реалізація;

    • Тестування;

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

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

    Переваги:

    • Повна і узгоджена документація на шкірному етапі;

    • Легко визначити терміни і витрати на проект.

    Недоліки:

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

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

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

    Альтернативою послідовної моделі є так звана модель ітеративної і інкрементального розробки ( англ. iterative and incremental development, IID ), Що отримала також від Т. Гілба в 70 - і рр. назву еволюційної моделі. Також цю модель називають ітеративної модель інкрементальний моделлю.

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

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

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

    Різні варіанти ітераційного підходу реалізовані в більшості сучасних методологій розробки ( RUP, MSF, XP).

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

    Спіральна модель ( англ. spiral model ) Була розроблена в середині 1980-х років Баррі Боем. Вона заснована на класичному циклі Демінга PDCA (plan - do - check - act). При використанні цієї моделі ПО створюється в кілька ітерацій (витків спіралі) методом прототипування.

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

    На кожній ітерації оцінюються :

    • ризик перевищення термінів і вартості проекту;

    • необхідність виконання ще однієї ітерації;

    • ступінь повноти і точності розуміння вимог до системи;

    • доцільність припинення проекту.

    Важливо розуміти, що спіральна модель є не альтернативою еволюційної моделі (моделі IID), а спеціально опрацьованим варіантом. На шкода, нерідко спіральну модель або помилково використовують як синонім еволюційної моделі взагалі, або (не менш помилково) згадують як абсолютно самостійну модель поряд з IID.

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

    • Дефіцит фахівців.

    • Нереалістичні терміни і бюджет.

    • Реалізація невідповідної функціональності.

    • Розробка неправильного користувальницького інтерфейсу.

    • Перфекціонізм, непотрібна оптимізація і відточування деталей.

    • Безперервний потік змін.

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

    • Недоліки в роботах, виконуваних зовнішніми (по відношенню до проекту) ресурсами.

    • Недостатня продуктивність одержуваної системи.

    • Розрив у кваліфікації фахівців різних областей.

    У сьогоднішній спіральної моделі визначено такий загальний набір контрольних точок :

    • Concept of Operations (COO) - концепція (використання) системи;

    • Life Cycle Objectives (LCO) - цілі та зміст життєвого циклу;

    • Life Cycle Architecture (LCA) - архітектура життєвого циклу; тут же можливо говорити про готовність концептуальної архітектури цільової програмної системи;

    • Initial Operational Capability (IOC) - деручи версія створюваного продукту, придатна для дослідної експлуатації;

    • Final Operational Capability (FOC) - готовий продукт, розгорнутий (встановлений і налаштований) для реальної експлуатації.

    Методології розробки ПЗ

    Rational Unified Process (RUP).

    Microsoft Solutions Framework (MSF). Включає 4 фази: аналіз, проектування, розробка, стабілізація, припускає використання об' єктно - орієнтованого моделювання.

    Екстремальне програмування ( англ. Extreme Programming, XP ). У основі методології командна робота, ефективна комунікація між замовником і виконавцем протягом усього проекту з розробки ІС. Розробка ведеться з використанням послідовно доопрацьовано прототипів.

    Література

    1. Зелковиц М., Шоу А., Гэннон Дж. Принципы разработки программного обеспечения: Пер. с англ.— М.: Мир, 1982 — 368 с., ил.

    2. Іващук В.В. Курс лекцій «Засоби мультимедіа в нових інформаційних технологіях» Національний університет харчових технологій.-К.: НУХТ, 2011. – 77 с.

    3. Когутяк М.І., Дранчук М.М., Когуч Я.Р., Шавранський М.В., Лещій Р.М. Автоматизація неперервних технологічних процесів в нафтовій та газовій промисловості: Навчальний посібник.–Івано-Франківськ: Факел, 2006.–385с.

    4. Конспект лекцій з дисципліни “Системи технологій” : к. т. н., доц. Фесенко М.С. Алчевськ ДонДТУ 2006, 70 стр.

    5. Кухнюк Н.В., викладач Технічного коледжу. Інтерактивний комплекс. з дисципліни “Автоматизація технологічних процесів”. 2008, 227 ст.

    6. Ларман Крэг. Применение UML и шаблонов проектирования. 2-е издание.: Пер. с англ. – М. Вильямс, 2004-624 с.:ил.

    7. Проць, О.А. Данилюк, Т.Б. Лобур. Автоматизація неперервних технологічних процесів. Навчальний посібник для технічних спеціальностей вищих навчальних закладів. – Тернопіль: ТДТУ ім. І.Пулюя, 2008. – 239 с.

    8. С.В.Шаповал, Н.Г.Морковська. Конспект лекцій з курсу „Системи технологій” Харків. ХНАМГ, 2005.- 70 с.

    9. Microsoft Corporation Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD/Пер. с англ. -2-е издание. Русская Редакция, 2002 – 736 стр., ил.

    10. Гагарина Л. Г., Кокорева Е. В., Виснадул Б. Д. Технология разработки программного обеспечения: учебное пособие / под ред. Л. Г Гагариной. — М.: ИД «ФОРУМ»: ИНФРА-М, 2008. — 400 с.: ил. — (Высшее образование).

    11. Галіцин В.К., Сидоренко Ю.Т., Потапенко С.Д. Технологія програмування і створення програмних продуктів: Навч. посіб. — К.: КНЕУ, 2009. — 372 с.

    12. Гужва В. М. Інформаційні системи і технології на підприємствах: Навч. посібник. — К.: КНЕУ, 2001. — 400 c.


    Лекція № 2
    1   2   3   4   5   6   7   8   9   ...   62


    написать администратору сайта