21297

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

Лекция

Информатика, кибернетика и программирование

Життєвий цикл програмного забезпечення Одним з базових понять методології проектування ІВ є поняття життєвого циклу її програмного забезпечення ЖЦ ПЗ. Структура ЖЦ ПЗ за стандартом ISO IEC базується на трьох групах процесів: основні процеси ЖЦ ПЗ придбання поставка розробка експлуатація супровід; допоміжні процеси які забезпечують виконання основних процесів документування управління конфігурацією атестація оцінка аудит рішення проблем; організаційні процеси управління проектами створення інфраструктури проекту...

Украинкский

2013-08-02

1.58 MB

70 чел.

Лекція 2. Життєвий цикл програмного забезпечення.

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

  Одним з базових понять методології проектування ІВ є поняття життєвого циклу її програмного забезпечення (ЖЦ ПЗ).

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

  Основним нормативним документом, що регламентує життєвий цикл ПЗ, є міжнародний стандарт ISO / IEC 12207 (ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electrotechnical Commission - Міжнародна комісія по електротехніці). Він визначає структуру ЖЦ, що містить процеси, дії та завдання, які повинні бути виконані під час створення ПЗ.

  Структура ЖЦ ПЗ за стандартом ISO / IEC базується на трьох групах процесів:

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

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

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

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

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

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

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

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

  До теперішнього часу найбільше поширення одержали наступні дві основні моделі ЖЦ:

  •  каскадна модель;
  •  спіральна модель.

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

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

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

Рис. 1.1 Каскадна схема розробки ПЗ

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

  Проте, в процесі використання цього підходу виявився ряд його недоліків, викликаних перш за все тим, що реальний процес створення ПЗ ніколи повністю не вкладався в таку жорстку схему. У процесі створення ПЗ постійно виникала потреба в поверненні до попередніх етапах і уточнення або перегляд раніше прийнятих рішень. У результаті реальний процес створення ПЗ брав наступний вигляд (рис. 1.2):

Рис. 1.2 Реальний процес розробки програмного забезпечення по каскадної схемою

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

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

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

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

Рис 1.3 Спіральна модель ЖЦ

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

  Існують деякі інші види моделей, які можна розглядати як «Проміжні» між каскадної і спіральної моделями. Ці моделі використовують окремі переваги каскадної і спіральної моделей і досягають успіху для певних типів завдань.

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

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

Рис 1.4 Ітераційна модель ЖЦ

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

V-подібна модель

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

Рис 1.5 V-подібна модель ЖЦ

  Крім планів, на ранніх етапах розробляються також і тести, які будуть виконуватися при завершенні паралельних етапів.

Інкрементное (покрокова) модель

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

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

Модель швидкого прототипування

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

Рис 1.6 Модель швидкого прототипування ЖЦ

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

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

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

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

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

  •  Microsoft Solution Framework (MSF) [МАЙКРОСОФТ Солюшн Фреймворк] - розробка фірми Microsoft, призначена для вирішення широкого кола завдань. Дана технологія настроюється на вирішення завдань будь-якої складності колективом будь-який чисельності.
  •  Rational Unified Process (RUP) [РЕЙШІНАЛ ЮНІФАЙД ПРОЦЕС] - розробка фірми Rational, довгий час успішно займалася створенням CASE-засобів, що застосовуються на різних етапах життєвого циклу продукту від аналізу до тестування і документування. Аналогічно MSF, RUP універсальна, масштабованості і настроюється на застосування в конкретних умовах.
  •  Extreme Programming (XP) [ЕКСТРІМ програмінг] - активно розвивається останнім часом технологія, призначена для рішення щодо невеликих завдань, відносно невеликими колективами професійних розробників в умовах жорстко обмеженого часу.

  Розглянемо ці технології більш докладно.

Модель Microsoft Solution Framework

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

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

  Модель життєвого циклу MSF орієнтована на «віхи» (milestones) - ключові точки проекту, що характеризують досягнення якого-небудь істотного результату.

  Цей результат може бути оцінений і проаналізований, що має на увазі відповідь на питання: «А чи досягли ми цілей, поставлених на цьому кроці?». У моделі передбачається наявність основних віх (завершення головних фаз моделі) та проміжних, що відображають внутрішні етапи головних фаз.

  Основними фазами моделі MSF є:

  •  Створення загальної картини додатки (Envisioning). На цьому етапі вирішуються такі основні завдання: оцінка існуючої ситуації; визначення складу команди, структури проекту, бізнес-цілей, вимог і профілів користувачів; розробка концепції вирішення і оцінка ризику. Встановлюються дві проміжні віхи: «Організований кістяк команди» і «Створена загальна картина рішення».
  •  Планування (Panning). Включає планування та проектування продукту. На основі аналізу вимог розробляється проект і основні архітектурні рішення, функціональні специфікації системи, плани та календарні графіки, середовища для розробки, тестування і пілотної експлуатації. Етап складається з трьох стадій: концептуальне, логічне та фізичне проектування. На стадії концептуального проектування завдання розглядається з точки зору користувача і бізнес-вимог і закінчується визначенням набору сценаріїв використання системи. При проектуванні завдання розглядається з точки зору проектної команди, рішення представляється у вигляді набору сервісів. І вже на стадії фізичного проектування завдання розглядається з точки зору програмістів, уточнюються технології, що використовуються і інтерфейси.
  •  Розробка (Developing). Створюється варіант вирішення проблеми, у вигляді коду та документації чергового прототипу, включаючи специфікації та сценарії тестування. Основна віха етапу - «Остаточне затвердження області дії проекту». Продукт готовий до зовнішнього тестування та стабілізації. Крім того, замовники, користувачі, співробітники служби підтримки та супроводу, а також ключові учасники проекту можуть попередньо оцінити продукт і вказати всі недоліки, які потрібно усунути до його постачання.
  •  Стабілізація (Stabilizing). Підготовка до випуску остаточної версії продукту, доведення його до заданого рівня якості. Тут виконується комплекс робіт з тестування (виявлення та усунення дефектів), перевіряється сценарій розгортання продукту. Коли рішення стає досить стійким, проводиться його пілотна експлуатація в тестовій середовищі із залученням користувачів і застосуванням реальних сценаріїв роботи.
  •  Розгортання (Deploying). Виконується установка рішення і необхідних компонентів оточення, проводиться його стабілізація в промислових умовах і передача проекту в руки групи супроводу. Крім того, аналізується проект в цілому на предмет рівня задоволеності замовника.

Модель Rational Unified Process

  Модель життєвого циклу RUP є досить складною, детально проробленої Ітеративний-інкрементний моделлю з елементами каскадної моделі. У моделі RUP виділяються 4 основні фази, 9 видів діяльності (процесів). Крім того, в моделі описується ряд практик, які слід застосовувати чи керуватися для успішного виконання проекту. RUP орієнтований на поетапне моделювання створюваного продукту за допомогою мови UML.

  Основними фазами RUP є:

  •  Фаза початку проекту (Inception). Визначаються основні цілі проекту, бюджет проекту, основні засоби його виконання - технології, інструменти, ключовою персонал, складаються попередні плани проекту. Основна мета цієї фази - досягти компромісу між усіма зацікавленими особами стосовно завдань проекту.
  •  Фаза уточнення (Elaboration). Основна мета цієї фази - на базі основних, найбільш істотних вимог розробити стабільну базову архітектуру продукту, яка дозволяє вирішувати поставлені перед системою завдання і в подальшому використовується як основа розробки системи.
  •  Фаза побудови / конструювання (Construction). Основна мета цієї фази - детальне прояснення вимог і розробка системи, що задовольняє їм, на основі спроектованої раніше архітектури.
  •  Фаза впровадження (Transition). Мета фази - зробити систему повністю доступною кінцевим користувачам. Тут відбувається остаточне розгортання системи в її робочому середовищі, підгонка дрібних деталей під потреби користувачів.

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

  Основні процеси RUP діляться на п'ять робочих і чотири підтримують. До робітників діяльності відносяться:

  •  Моделювання предметної області (бізнес-моделювання). Цілі цієї діяльності - зрозуміти бізнес-контекст, в якому повинна буде працювати система (і переконатися, що всі зацікавлені особи розуміють його однаково), зрозуміти можливі проблеми, оцінити можливі їх рішення і їх наслідки для бізнесу організації, в якій буде працювати система.
  •  Визначення вимог (Requirements). Цілі - зрозуміти, що має робити система, визначити межі системи і основу для планування проекту та оцінок ресурсовитрат в ньому.
  •  Аналіз і проектування (Analysis and Design). Вироблення архітектури системи на основі ключових вимог, створення проектної моделі, представленої у вигляді діаграм UML, що описують продукт з різних точок зору.
  •  Реалізація (Implementation). Розробка вихідного коду, компонент системи, тестування і інтегрування компонент.
  •  Тестування (Test). Загальна оцінка дефектів продукту, його якість в цілому; оцінка ступеня відповідності вихідним вимогам.

  Підтримучими діяльність є:

  •  Розгортання (Deployment). Цілі - розгорнути систему в її робочому оточенні та оцінити її працездатність.
  •  Управління конфігураціями і змінами (Configuration and Change Management). Визначення елементів, що підлягають зберіганню і правил побудови з них узгоджених конфігурацій, підтримку цілісності поточного стану системи, перевірка узгодженості вносяться.
  •  Управління проектом (Project Management). Включає планування, управління персоналом, забезпечення зв'язків з іншими зацікавленими особами, управління ризиками, відстеження поточного стану проекту.
  •  Управління середовищем проекту (Environment). Налаштування процесу під конкретний проект, вибір і зміна технологій та інструментів, що використовуються у проекті.

Модель Extreme Programming (XP)

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

  Основними фазами моделі можна вважати:

  •  «вкидання» архітектури, на якому створюється бачення продукту, приймаються основні рішення з архітектури й застосовуваних технологій. Результатом початкового етапу є метафора системи, яка в досить простому та зрозумілому вигляді повинна описувати основний механізм роботи системи.
  •  Історії використання (User Story) - етап збору вимог, що записується на спеціальних картках у вигляді сценаріїв виконання окремих функцій. Історії використання є вимогами для планування чергової версії та одночасної розробки приймальних тестів (Acceptance tests) для її перевірки.
  •  Планування версії. Проводиться на зборах за участю замовника шляхом вибору User Stories, які увійдуть в наступну версію. Одночасно приймаються рішення, пов'язані з реалізацією версії. Мета планування - отримання оцінок того, що і як можна зробити за декілька тижнів створення наступної версії продукту.
  •  Розробка проводиться відповідно до плану і включає тільки ті функції, які були відібрані на етапі планування.
  •  Тестування проводиться за участю замовника, який бере участь у складанні тестів.
  •  Випуск релізу - розроблена версія передається замовнику для використання або бета-тестування.

  Особливості моделі життєвого циклу XP прояснюють наступні принципи цього методу. Перш за все, це принципи «живий» розробки ПЗ:

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

  Крім того, в XP є кілька правил (технік), що характеризують особливостімоделі його життєвого циклу:

  •  Живе планування (planning game) - як можна швидше визначити обсяг робіт, який потрібно зробити до наступної версії ПЗ. Рішення приймається на основі, в першу чергу, бізнес-пріоритетів замовника і, по-другу, технічних оцінок. Плани змінюються, як тільки вони починають розходитися з дійсністю або побажань замовника.
  •  Часта зміна версій (small releases) - перша працююча версія повинна з'явитися як можна швидше, і тут же має розпочати використовуватися. Наступні версії підготовляються через досить короткі проміжки часу.
  •  Прості проектні рішення (simple design) - у кожен момент часу система повинна бути сконструйована так просто, наскільки це можливо. Нові функції додаються тільки після ясною прохання про це. Вся зайва складність видаляється, як тільки виявляється.
  •  Розробка на основі тестування (test-driven development) - спочатку пишуться тести, потім реалізуються модулі так, щоб тести спрацьовували. Замовники заздалегідь пишуть тести, що демонструють основні можливості системи, щоб можна було побачити, що система дійсно запрацювала.
  •  Постійна переробка (refactoring) - системи для усунення зайвої складності, збільшення зрозумілості коду, підвищення його гнучкості. При цьому перевага віддається елегантним і гнучким рішенням, в порівнянні з просто дають потрібний результат.
  •  Постійна інтеграція (continuous integration) - система збирається і проходить інтеграційне тестування як можна частіше, по кілька разів на день, кожного разу, коли пара програмістів закінчує реалізацію черговий функції.

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

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

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

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

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


 

А также другие работы, которые могут Вас заинтересовать

2043. Бенкет-фуршет: особливості сервірування та обслуговування 26 KB
  Для сервування столу використовують столовий посуд і набори, загальна кількість яких залежить від чисельності гостей і нормативу на одного гостя.
2044. Обслуговування учасників конференцій, фестивалів, форумів 18.01 KB
  Учасники вказаних заходів обслуговуються харчуванням за місцем роботи і проживання. У перервах між засіданнями може працювати буфет-фуршет, організований за місцем проведення засідання.
2045. Призначення санітарно-технічної та інженерно-технічної служб 38.03 KB
  Основним призначенням санітарно-технічної та інженерно-технічної служб підприємства готельного господарства є створення та підтримка умов для безперервного функціонування будівель та обладнання готельного підприємства, своєчасне проведення всіх видів ремонту та профілактичних заходів з метою запобігання збоїв у роботі всіх служб підприємства.
2046. Вимоги до коридорів, холів, їх оформлення 25.76 KB
  Основною вимогою до коридорів є відсутність будь-яких меблів і денне та штучне освітлення, що сприяє швидкому орієнтуванню у них споживачів готельних послуг.
2047. Кондиціонування. Ліфти 24.33 KB
  Вентиляція приміщень (провітрювання) є природною і функціонує за рахунок проникнення в приміщення повітря через відкриті вікна, кватирки, щілини в конструкціях будинків і щілі будівельних матеріалів.
2048. Утримання та прибирання прилеглої території 16.56 KB
  Для здійснення контролю санітарно-екологічного стану навколишньої території за конкретним підприємством готельного господарства закріплюється певна площа.
2049. Основні прибиральні роботи в зимовий період 16.34 KB
  Щоденно прибирають бруд, сніг з доріжок, бордюрів, тротуарів і під'їзних автошляхів. Садівники прочищають доріжки у парках. У цей період необхідно періодично перевіряти стан багатолітніх насаджень.
2050. Основні прибиральні роботи навесні 16.41 KB
  Навесні прибирають сміття, що залишилось після остаточного танення снігу, проводять дрібний ремонт шляхів, тротуарів і доріжок. Особливої уваги потребують каналізаційні колодязі та місця з талою водою під час розтавання снігу.
2051. Основні прибиральні роботи в літній період 16.41 KB
  На початку літа клумби очищають від відцвілих рослин та прикрашають літніми сортами. Декоративні кущі періодично розчищають, підтримуючи задану форму.