МАРК РЕГНЕРУС ДОСЛІДЖЕННЯ: Наскільки відрізняються діти, які виросли в одностатевих союзах
РЕЗОЛЮЦІЯ: Громадського обговорення навчальної програми статевого виховання ЧОМУ ФОНД ОЛЕНИ ПІНЧУК І МОЗ УКРАЇНИ ПРОПАГУЮТЬ "СЕКСУАЛЬНІ УРОКИ" ЕКЗИСТЕНЦІЙНО-ПСИХОЛОГІЧНІ ОСНОВИ ПОРУШЕННЯ СТАТЕВОЇ ІДЕНТИЧНОСТІ ПІДЛІТКІВ Батьківський, громадянський рух в Україні закликає МОН зупинити тотальну сексуалізацію дітей і підлітків Відкрите звернення Міністру освіти й науки України - Гриневич Лілії Михайлівні Представництво українського жіноцтва в ООН: низький рівень культури спілкування в соціальних мережах Гендерна антидискримінаційна експертиза може зробити нас моральними рабами ЛІВИЙ МАРКСИЗМ У НОВИХ ПІДРУЧНИКАХ ДЛЯ ШКОЛЯРІВ ВІДКРИТА ЗАЯВА на підтримку позиції Ганни Турчинової та права кожної людини на свободу думки, світогляду та вираження поглядів
Контакти
Тлумачний словник Авто Автоматизація Архітектура Астрономія Аудит Біологія Будівництво Бухгалтерія Винахідництво Виробництво Військова справа Генетика Географія Геологія Господарство Держава Дім Екологія Економетрика Економіка Електроніка Журналістика та ЗМІ Зв'язок Іноземні мови Інформатика Історія Комп'ютери Креслення Кулінарія Культура Лексикологія Література Логіка Маркетинг Математика Машинобудування Медицина Менеджмент Метали і Зварювання Механіка Мистецтво Музика Населення Освіта Охорона безпеки життя Охорона Праці Педагогіка Політика Право Програмування Промисловість Психологія Радіо Регилия Соціологія Спорт Стандартизація Технології Торгівля Туризм Фізика Фізіологія Філософія Фінанси Хімія Юриспунденкция |
|
|||||||
МОДЕЛІ ЖИТТЄВОГО ЦИКЛУ ПЗСтандарт ISO/EEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ. Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт ISO/IEC 12207 описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії і завдання, включені в ці процеси. Під моделлю ЖЦ розуміється структура, що визначає послідовність виконання і взаємозв'язки процесів, дій і завдань упродовж ЖЦ. Модель ЖЦ залежить від специфіки ІС і специфіки умов, в яких система створюється і функціонує. До теперішнього часу найбільше поширення отримали наступні дві основні моделі ЖЦ : каскадна модель (1970 - 1985 рр.) і спіральна модель (1986 - 1990 рр.). У спочатку існуючих однорідних ІС додатки були єдиним цілим. Для розробки такого типу додатків застосовувався каскадний спосіб. Його основний характеристикою являється розбиття усієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершена робота на поточному (мал. 1.1). Кожен етап завершується випуском повного комплекту документації, достатньою для того, щоб розробка могла бути продовженою іншою командою розробників. Переваги застосування каскадного способу полягають в наступному: • на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти; • виконувані в логічній послідовності етапи робіт дозволяють планувати терміни завершення усіх робіт і відповідні витрати. Каскадний підхід добре зарекомендував себе при побудові ІС, для яких на самому початку розробки можна достатньо точно і повно сформулювати усі вимоги, з тим щоб надати розробникам свободу реалізувати їх технічно якнайкраще. У цю категорію потрапляють складні розрахункові системи, системи реального часу та ін. Мал. 1.1. Схема каскадного процесу розробки ПЗ В той же час цей підхід має ряд недоліків, викликаних передусім тим, що реальний процес створення ПЗ ніколи повністю не укладався в таку жорстку схему, постійно виникала потреба в поверненні до попередніх етапів і уточненні або перегляді раніше прийнятих рішень. У результаті реальний процес створення ПЗ набирав вигляду, представлений на мал. 1.2. Зображену на мал. 1.2 схему часто відносять до окремої моделі, так званої «моделі з проміжним контролем», в якій міжетапні коригування забезпечують велику надійність в порівнянні з каскадною моделлю, хоча і збільшують увесь період розробки. Основним недоліком каскадного підходу є значне запізнювання з отриманням результатів. Узгодження результатів з користувачами робиться тільки в точках, плануємих після завершення кожного етапу робіт, вимоги до ІС «заморожені» у вигляді технічного завдання на увесь час її створення. Таким чином, користувачі можуть внести свої зауваження тільки після того, як робота над системою буде повністю завершена. У разі неточного викладу вимог або їх зміни впродовж тривалого періоду створення ПЗ користувачі получають систему, що не задовольняє їх потребам. Моделі (як функціональні, так і інформаційні) об'єкту, що автоматизується, можуть застаріти одночасно з їх твердженням. Мал. 1.2. Схема реального процесу розробки ПЗ Для подолання перерахованих проблем була запропонована спіральна модель ЖЦ (мал. 1.3), в якій робиться упор на початкові етапи ЖЦ : аналіз і проектування. На цих етапах та, що реалізовується технічних рішень перевіряється шляхом створення прототипів. Кожен виток спіралі відповідає створенню фрагмента або версії ПЗ, на нім уточнюються цілі і характеристики проекту, визначається його якість і плануються роботи наступного витка спіралі. Таким чином поглиблюються і послідовно конкретизуються деталі проекту і в результаті вибирається обґрунтований варіант, який доводиться до реалізації. Розробка ітераціями відбиває об'єктивно існуючий спіральний цикл створення системи. Неповне завершення робіт на кожному етапі дозволяє переходити на наступний етап, не дотримуючись повного завершення роботи на поточному. При ітеративному способі розробки незавершену роботу можна буде виконати на наступній ітерації. Головне ж завдання - якнайшвидше показати користувачам системи працездатний продукт, тим самим активізуючи процес уточнення і доповнення вимог. Мал. 1.2. Схема спіральної моделі процесу розробки ПЗ Основна проблема спірального циклу - визначення моменту переходу на наступний етап. Для її вирішення необхідно ввести тимчасові обмеження на кожного з етапів життєвого циклу. Перехід здійснюється відповідно до плану, навіть якщо не уся запланована робота закінчена. План складається на ос-нове статистичних даних, отриманих в попередніх проектах, і особистого досвіду розробників. Читайте також:
|
||||||||
|