І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації - страница 7

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 

управління

забезпечення

гортання;

тування ПЗ;

 

ризиками;

інструментами;

підтримка експлу-

інтеграція і тес-

 

управління ресур-

забезпечення

атації;

тування

 

сами і графіком

середовища

надання послуг;

системи;

 

робіт;

для роботи

оцінка вдоволеності

супровід сис-

 

управління під-

 

замовників

теми і ПЗ

 

рядниками

 

 

У стандарті ISO 15504 запроваджується нова класифікація процесів:

1)   основні процеси:

а)   CUS: замовник-постачальник;

б)  ENG: інженерні;

2)   допоміжні процеси: а) SUP: допоміжні;

3)   організаційні процеси:

а)   MAN: управлінські;

б)  ORG: організаційні.

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

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

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

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

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

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

 

9.2.5. Стандарти зрілості можливостей організації,

розроблені SEI

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

рівні зрілості організації (maturity levels);

ключові області процесу (key process areas);

ключові практики (key practices).

Найчастіше під моделлю СММ мають на увазі саме модель рівнів зрілості. Професіоналізм організації визначається за допомогою зрілості процесу, використовуваного цією організацією. У стандарті виділяються п'ять рівнів зрілості процесу, які встановлюють ступінь готовності організації виконати великий проект.

Рівні зрілості. СММ описує різні ступені зрілості процесів в організаціях, визначаючи п'ять рівнів організацій:

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

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

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

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

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

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

До першого рівня не висуваються жодні вимоги.

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

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

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

Організації п'ятого рівня зрілості повинні додатково підтримувати управління змінами процесу, управління змінами використовуваних технологій і запобігання дефектам.

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

зобов'язання (commitments to perform);

можливості (abilities to perform);діяльності (activities performed); вимірювання (measurements and analysis); перевірки (verifying implementations).

Наприклад, управління вимогами пов'язане з наступними практиками:

зобов'язання - проекти повинні відповідати певній політиці організації щодо управління вимогами;

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

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

вимірювання - проводиться періодичне визначення статусу вимог і статусу діяльності щодо управління ними;

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

Модель CMMI. На зміну моделі СММ, що зараз вважається застарілою, була розроблена модель CMMI. Ця модель є результатом інтеграції моделей СММ для продуктів і процесів, а також для розробки ПЗ і розробки програмно-апаратних систем. Основні зміни порівняно із СММ наступні. Зроблені два виклади моделі - безперервне й поетапне. Перший призначений для полегшення міграції від підтримки американського галузевого стандарту EIA/AIS 713 і поступового вдосконалення процесів за рахунок впровадження різних практик. Другий призначений для полег-шення міграції від підтримки СММ і порівневого розгляду практик, що вводяться.

Елементи моделі розподіляють на три види:

обов'язкові (required);

такі, що рекомендуються (expected);

інформативні (informative).

Тип елемента чітко позначається в моделі.

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

загальні (generic);специфічні (specific).

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

Деякі рівні зрілості отримали інші назви. Другий рівень був названий керованим (managed), а четвертий - керованим на основі метрик (quantitatively managed).

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

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

управління процесом, яке включає вироблення й підтримку процесу (3), контроль за дотриманням процесу (3), навчання (3), вимірювання показників процесу (4), впровадження інновацій (5);

управління проектом, яке включає планування проектів (2), кон­троль за ходом проекту (2), управління угодами з постачальниками (2), інтегроване управління проектами (3), управління ризиками (3), побудову команд (3), управління постачальниками (3) і вимірювання показників результативності і ходу проекту (4);

технічні, які включають формування вимог (3), управління вимогами (2), вироблення технічних рішень (3), інтеграцію продуктів (3), верифікацію (3) і валідацію (3);

підтримки включають управління конфігурацією (2), забезпечення якості продуктів і процесів (2), проведення вимірювань і аналіз їх результатів (2), управління оточенням (3), аналіз і ухвалення рішень (3), аналіз, вирішення і запобігання проблемам (5).

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

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

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

 

9.3. Традиційні моделі життєвого циклу програмного забезпечення

 

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

забезпечення

 

Модель життєвого циклу програмного забезпечення (Software

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

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

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

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 


Похожие статьи

І О Ушакова - Соціальні мережі як засіб впливу на взаємовідносини з клієнтами

І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Практикум з навчальної дисципліни основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Робоча програма навчальної дисципліни Проектування інформаційних систем

І О Ушакова - Робоча програма навчальної дисципліни системний аналіз для студентів напряму підготовки 6 050101 комп'ютерні науки