• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Міжнародний стандарт ISO/IEC 12207

Перша редакція ISO 12207 розроблена в 1995 р. об'єднаним технічним комітетом ISO/IES ITC1 "Інформаційні технології, підкомітет SC7, програмування програмного забезпечення".

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

Він охоплює ЖЦ від концептуалазації ідеї до завершення ЖЦ. Згідно зі стандартом:

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

На відміну від Oracle CDM стандарт ISO 12207 в однаковій мірі призначений для регулювання двосторонніх відносин між замовником (покупцем) і розробником (постачальником). Він може застосовуватись і у випадку, коли обидві сторони належать одній організації.

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

У порівнянні з CDM процеси є більш крупними, узагальненими. Власне один процес з ISO рівнозначний усім процесам CDM: придбання, поставка, розробка і т.інш.

Описано 5 основних (базових) процесів:

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

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

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

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

5. Процес супроводу. Визначає дії персоналу супроводу. Який забезпечує супровід програмного продукту, що включає:

- управління модифікаціями;

- підтримку його поточного стану та функціональної придатності;

- інсталяцію та вилучення програмного виробу з обчислювальної системи.

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

Допоміжні процеси:

1. вирішення проблем;

2. документування;

3. управління конфігурацією;

4. забезпечення якості;

Цей процес використовує результати наступних процесів групи забезпечення якості:

5. процес верифікації;

6. процес атестації;

7. перевірка відповідності спільної оцінки (об'єднаних оглядів);

8. процес аудиту (ревізії).

Описані 4 організаційні процеси:

1. процес управління;

2. процес створення інфраструктури (визначає дії по створенню інфраструктури, яка підтримує процеси ЖЦ);

3. процес удосконалення процесів ЖЦ;

4. процес навчання.

До них примикає особливий процес адаптації, який визначає дії, необхідні для адаптації стандартів до умов конкретного проекту. Будь-яких етапів, фаз, стадій не передбачено. Це якраз і підвищує ступінь адаптивності. У табл.4.3 наведена схема взаємозв'язку процесів ISO.

Таблиця 4.3 Схема взаємозв'язку процесів ISO

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

Приклади:

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

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

3). Процес Супроводження може вимагати розвитку системи і ПЗ, яке виконується у процесі Розробки.

Такий підхід дозволяє реалізувати будь-яку модель ЖЦ.

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

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

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

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

Наприклад, при проведенні аналізу вимог до систем, передбачається, що:

1). розглядається область застосування систем для визначення вимог до неї;

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

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

Далі наведено 11 класів характеристик якості, які пізніше використовуються при гарантуванні якості:

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

2. зовнішні зв'язки (інтерфейси);

3. вимоги кваліфікації;

4. специфікації надійності, включно специфікації, пов'язані з методами функціонування і супроводу, взаємодії з зовнішнім середовищем та вірогідністю травм персоналу;

5. специфікації захищеності, включно специфікації, пов'язані з дотриманням точності інформації;

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

7. визначення даних та вимог бази даних;

8. вимоги до установки та прийомки ПП, що поставляється в місцях функціонування та супроводу;

9. документація користувача;

10. робота користувача і вимоги виконання;

11. вимоги сервісу користувача.

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

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

Стандарт містить мало описів про проектування БД, що можна вважати виправданням, оскільки різні системи і різні прикладні комплекси ПЗ можуть не тільки використовувати специфічні БД, а і не використовувати БД зовсім. В таблиці 4.4 зображена порівняльна характеристика процесів CDM та ISO 12207.

Таблиця 4.4 Порівняльна характеристика CDM та ISO 12207

З вище сказаного можна зробити такі висновки:

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

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

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

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

3. Використання ISO 12207:

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

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

в). слід зазначити, що побудова профілів ЖЦ проекту на основі ISO 12207 зазначеним чином може зробити проектні роботи більш дорогими. Вартість виросте також через проведення дій з гарантування якості. На перший погляд - це непотрібні ускладнення і ризики в проектуванні АС, яке і без того відносить до діяльності з підвищеним ризиком. Однак, і замовником і розробником доцільно врахувати наступне:

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

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

Питання для самоконтролю:

1. За якими ознаками класифікують стандарти?

2. Які основні особливості класифікації стандартів?

3. Яке призначення методики Oracle CDM (Custom Development Method)?

4. Які моделі ЖЦ підтримує методика Oracle CDM?

5. З яких етапів формується загальна класична структура ЖЦ за методикою Oracle CDM?

6. З яких фаз формується модель ЖЦ Fast Track ("прискорена розробка")за методикою Oracle CDM?

7. Який поділ проекту передбачає «полегшена модель»?

8. Назвіть основні процеси, що розглядаються в CDM?

9. Яке призначення методики Oracle PJM (Project Development Method)?

10. Які основні процеси розглядаються в PJM?

11. Як можна представити взаємозв'язок фаз та процесів в PJM?

12. Яке призначення міжнародного стандарту ISO/IEC 12207?

13. Яка концепція у основі міжнародного стандарту ISO/IEC 12207?

14. Які основні процеси визначає стандарт ISO/IEC 12207?

15. Які допоміжні процеси визначає стандарт ISO/IEC 12207?

16. Опишіть взаємозв'язок процесів ISO?

17. Які відмінності існують між різними стандартами?

Читайте також:

1. ISO 15504. Призначення і структура стандарту
2. O міжнародний.
3. Американський стандартний код для обміну інформацією ASCII.
4. Антимонопольное регулирование. Стандартизация, единство измерений,
5. Баові поняття стандарту з типів даних
6. Британські стандарти новин.
7. Будова СВА. Стандарти практичного застосування.
8. Ведучий теленовин: стандарти професіоналізму
9. Вибір зовнішніх ринків фірмою і методи виходу на міжнародний ринок.
10. Вибір та застосування стандартів
11. Вивчення географії на рівні стандарту
12. Видавнича та пропагандистська діяльність Держстандарту

Переглядів: 5478