Главная

Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






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


У стандарті ISO 12207 описано п'ять основних процесів життєвого циклу програмного забезпечення :

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

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

· процес розробки визначає дії підприємства-розробника, яка розробляє принцип побудови програмного виробу і програмний продукт;

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

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

Окрім основних, стандарт ISO 12207 обумовлює 8 допоміжних процесів, які є невід'ємною частиною усього життєвого циклу програмного виробу і забезпечують належну якість проекту програмного забезпечення.

До допоміжних процесів відносяться:

· процес рішення проблем;

· процес документування;

· процес управління конфігурацією;

· процес забезпечення якості;

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

· процес атестації;

· процес спільної оцінки;

· процес аудиту.

У стандарті ISO 12207 також визначаються чотири організаційні процеси:

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

· процес створення інфраструктури;

· процес удосконалення;

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

Примітка

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

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

Особливості стандарту ISO 12207

Усе сказане вище дозволяє сформулювати наступні особливості стандарту ISO 12207.

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

примітка

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

· Стандарт ISO 12207 забезпечує максимальну міру адаптивності. Безліч процесів і завдань сконструйована так, що можлива їх адаптація відповідно до конкретних проектів інформаційних систем. Ця адаптація зводиться до виключення процесів, видів діяльності і завдань, непридатних в конкретному проекті.

Примітка

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

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

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

· Міра обов'язковості даного стандарту наступна: після рішення організації про застосування ISO 12207 як умова торговельних стосунків являється її відповідальність за вказівку мінімального набору необхідних процесів і завдань, які забезпечують узгодженість з цим стандартом.

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

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

· розглядається сфера застосування системи для визначення вимог, що пред'являються до системи;

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

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

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

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

· зовнішні зв'язки (інтерфейси) з одиницею програмного забезпечення;

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

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

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

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

· визначення даних і вимог до бази даних;

· настановні і приймальні вимоги програмного продукту, що поставляється, в місцях функціонування і супроводу (експлуатації);

· документацію користувача;

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

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

Примітка

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

Хоча стандарт не наказує конкретної моделі життєвого циклу або методу розробки, він визначає, що сторони-учасники при використанні стандарту відповідальні за наступне:

· вибір моделі життєвого циклу для проекту, що розробляється;

· адаптацію процесів і завдань стандарту до цієї моделі;

· вибір і застосування методів розробки програмного забезпечення;

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

 

 

Стандарти комплексу ГОСТ 34

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

Комплекс розрахований на взаємодію замовника і розробника. Аналогічно ISO 12207, в нім передбачено, що замовник може розробляти автоматизовану систему для себе сам (наприклад, створивши для цього спеціалізований підрозділ). Проте формулювання ГОСТ 34 не орієнтовані на таке явне і у відомому сенсі симетричне віддзеркалення дій обох сторін, як це зроблено в ISO 12207. Оскільки ГОСТ 34 в основному приділяє увагу змісту проектних документів, розподіл дій між сторонами зазвичай проводиться виходячи з цього зміст.

Загальна структура

З усіх існуючих груп документів грунтуватимемося тільки на групі 0 "Загальних станів" і групі 6 "Створення, функціонування і розвиток автоматизованої системи". Найбільш популярними можна рахувати стандарти ГОСТ 34.601-90 (стадії створення автоматизованої системи), ГОСТ 34.602-89 (технічне завдання на створення автоматизованої системи) і методичні вказівки РД 50-34.698-90 (вимоги до змісту документів). Стандарти передбачають стадії і етапи виконання робіт із створення автоматизованої системи, але не передбачають крізних процесів в явному виді.

Згідно ГОСТ 34, розробка автоматизованої системи розбивається на наступні етапи і стадії.

· Етап формування вимог до автоматизованої системи. Складається з наступних стадій:

o обстеження об'єкту і обгрунтування необхідності розробки автоматизованої системи;

o формування вимог замовника до автоматизованої системи;

o розробка звіту про виконану роботу і заявки на розробку технічного завдання.

· Розробка концепції :

o вивчення об'єкту;

o проведення необхідних науково-дослідних робіт;

o розробка варіантів концепції автоматизованої системи, що задовольняє вимогам замовника;

o розробка звіту про виконану роботу.

· Розробка і затвердження технічного завдання на розробку автоматизованої системи.

· Розробка ескізного проекту автоматизованої системи :

o розробка попередніх проектних рішень по усій системі в цілому і по її окремих складових;

o розробка документації.

· Розробка технічного проекту :

o розробка проектних рішень по усій системі і по її частинах;

o розробка документації на автоматизовану систему і на підсистеми, що входять до її складу;

o розробка і оформлення документації на постачання виробів для комплектування автоматизованої системи і/або технічних вимог на їх розробку;

o розробка завдань на проектування в суміжних частинах проекту об'єкту автоматизації.

· Розробка технічної документації :

o розробка робочої документації на систему і її частини;

o розробка і/або адаптація програмного забезпечення.

· Введення розробленої системи в дію:

o підготовка об'єкту автоматизації;

o підготовка персоналу;

o комплектація автоматизованої системи програмними і технічними засобами;

o монтажні роботи;

o пуско-налагоджувальні роботи;

o попередні випробування;

o дослідна експлуатація;

o приймальні випробування.

· Супровід:

o виконання робіт відповідно до гарантійних зобов'язань;

o післягарантійне обслуговування.

У ГОСТ 34 приводиться опис змісту документів, що розробляються на кожному з етапів.

Особливості

Основними особливостями комплексу стандартів ГОСТ 34 являються наступні:

· Основною метою розробки комплексу нормативних документів ГОСТ 34 було вирішення протиріч, що виникають при інтеграції систем внаслідок неузгодженості нормативно-технічної документації. Комплекс стандартів ГОСТ 34 ближчий до схем конкретних методик, чим до стандартів типу ISO 12207.

· Міра адаптивності стандарту ГОСТ 34 визначається наступними можливостями:

o можливістю відмовитися від етапу ескізного проектування і об'єднувати

o етапи розробки технічного проекту і робочої документації;

o можливістю відмовлятися від деяких стадій розробки, а також об'єднувати більшість документів і їх розділів;

o можливістю вводити додаткові документи, розділи документів і роботи;

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

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

· Незважаючи на досить велику гнучкість формування життєвого циклу, зумовлені документами ГОСТ 34 етапи і стадії розробки на практиці орієнтують розробників на каскадну схему життєвого циклу.

· Документи ГОСТ 34 визначають єдину термінологію і цілком розумно класифікують роботи із створення автоматизованої системи і документи, що розробляються в результаті цих робіт. Завдяки ГОСТ 34 спрощується інтеграція різних систем і підвищується якість систем, отриманих в результаті інтеграції.

· Забезпечення якості згодне ГОСТ 34 визначається в технічному завданні на автоматизовану систему і проводиться на будь-яких наступних етапах і з будь-якою мірою незалежності експертизи. У послідовності етапів розробки ці експертизи розташовуються дещо пізніше, ніж в ISO 12207.

· Міра обов'язковості ГОСТ 34: повна обов'язковість відсутня, матеріали ГОСТ 34, по суті, є методичною підтримкою. Причому ця підтримка значною мірою орієнтована на замовника: в стандарті є набір вимог до змісту технічного завдання і проведення випробувань розробленої системи.

· Ключовим документом взаємодії сторін є технічне завдання (ТЗ) на створення автоматизованої системи. ТЗ є основним початковим документом для створення автоматизованої системи її приймання, воно визначає найважливіші точки взаємодії замовника і розробника.

Примітка

Технічне Завдання Розробляється Організацією-розробником (По Гост 34.602-89); Але Формально Технічне Завдання Видає Розробникові Замовник (По Рд 50-680-88).

Згідно ГОСТ 34, автоматизована система складається з програмно-технічних, програмно-методичних комплексів і окремих компонентів організаційного, технічного, програмного і інформаційного забезпечення. Документи комплексу ГОСТ 34 визначають автоматизовану систему таким чином:

· "організаційно-технічна система, що забезпечує вироблення рішень на основі автоматизації інформаційних процесів в різних сферах діяльності (управління, проектування, виробництво і т. д.) або їх поєднаннях" - РД 50-680-88;

· "система, що складається з персоналу і комплексу засобів автоматизації його діяльності, реалізовує інформаційну технологію виконання встановлених функцій" - ГОСТ 34.003-90.

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

Висновки

· Жоден з розглянутих стандартів не є універсальним, таким, що описує усі види дій і завдань; виконуваних в конкретних проектах. Така ситуація, ймовірно, об'єктивно неминуча для будь-яких досить конкретних стандартів і фірмових методик.

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

· ГОСТ 34 досить повно і фундаментально визначає.

ü систему як об'єкт створення або розвитку;

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

ü види забезпечення системи, які, загалом, узгоджуються з вимогами ISO 12207 до системи і програмного забезпечення.

Матеріали ГОСТ 34 майже так само, як і ISO 12207, а може бути, ще чіткіше визначають, що автоматизована система - це в першу чергу люди, які виконують свої функції за допомогою інформаційних техно-логий.

· ГОСТ 34 завдяки своїй комплексній орієнтації на систему і забезпеченню єдиної термінології дозволяє уникнути ситуацій, в яких розробники різних професій (наприклад, фінансові аналітики і проектувальники баз даних) "говорять на різних мовах", від чого у результаті страждають цілісність і глибина опрацювання проекту.

· ГОСТ- 34 і CDM в першу чергу орієнтовані на дії із створення і підтримки систем ISO 12207 - на придбання і експлуатацію систем (при цьому розробка є процесом, логічно витікаючим з придбання).

 



Последнее изменение этой страницы: 2016-06-09

headinsider.info. Все права принадлежат авторам данных материалов.