На головну

ДОКУМЕНТАЦІЯ В ЖИТТЄВОМУ ЦИКЛІ СКЛАДНИХ програмних засобів | Проблеми організації документування складних програмних засобів | Формування вимог до документації складних програмних засобів | Управління фахівцями при документуванні програмних засобів | Документообіг в життєвому циклі проектів програмних засобів | Документи попередніх вимог, специфікацій і ресурсів для розробки програмного засобу | Документи процесів проектування і вибору характеристик якості програмного засобу | Документи процесів розробки і програмування компонентів програмних засобів | Документи верифікації та тестування компонентів програмних засобів | Документи кваліфікаційного тестування, випробувань і оцінювання якості програмних засобів |

© um.co.ua - учбові матеріали та реферати

Стандарти, що регламентують експлуатаційну документацію програмних засобів

  1. Fixed assets turnover - Коефіцієнт оборотності основних засобів, раз
  2. I. Засоби, що діють на холінергічні синапси
  3. II. Засоби, що діють на адренергічні синапси
  4. III. Головна причина передчасної старості, випадання і посивіння волосся: засіб збереження молодості і краси
  5. III.1.3) Засоби доведення кримінального обвинувачення.
  6. KALLOS ПРОФЕСІЙНА СЕРІЯ ЗАСОБІВ ДЛЯ ВОЛОССЯ
  7. KALLOS ПРОФЕСІЙНА СЕРІЯ ЗАСОБІВ ДЛЯ ВОЛОССЯ

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

Користувачі таких ПС можна розділити на дві великі групи, кожна з яких повинна бути забезпечена комплектної експлуатаційної документації:

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

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

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

- Консультація розробників програм і даних про особливості застосування операційної системи і системи управління базою даних (СКБД);

- Планування використання пам'яті і продуктивності обчислювальної системи в робочому режимі застосування ПС;

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

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

- Управління, коригування та облік зовнішнього середовища при реконфігурації конкретного ПС;

- Оперативне управління, облік і розподіл ресурсів системи і компонентів ПС;

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

- Захист і відновлення інформації баз даних при дефектах і викривлення;

- Збір статистики про функціонування системи обробки інформації та ПС.

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

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

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

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

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

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

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

- Візуалізації і безпосередньої взаємодії користувачів з різними типами терміналів;

- Інтерфейсів програмних засобів і баз даних, що забезпечують візуалізацію, з операційною системою;

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

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

Основу сучасного призначеного для користувача інтерфейсу з ПС складають набори текстових і графічних елементів і дій над ними, що подаються як меню і системи вікон для маніпулювання з зображеннями. Основні особливості сучасного інтерфейсу з користувачами полягають у наступному [4, 16, 19]:

-наявність механізмів управління вікнами;

-використання готових графічних символів (ікон) для відображення керованих об'єктів;

-безпосереднє маніпулювання графічними об'єктами і вікнами за допомогою «миші»;

-об'ектно- і проблемно-орієнтоване проектування діалогових систем.

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

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

-відповідність між елементами інтерфейсів користувача (екранними формами) і типовими процедурами;

-послідовність допустимих операцій і переходи між екранними формами;

-форми ідентифікації помилкових дій і / або ситуацій;

-форми вхідних і вихідних документів.

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

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

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

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

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

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

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

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

СтандартISO 15910 є найбільш сучасним нормативним документом, який регламентує процеси створення експлуатаційної документації для користувачів складних програмних засобів. Метою стандарту є стимулювання розробників програмних засобів до методичного використанню процесу документування. Він побудований за традиційною схемою стандартів ISO і перші сім розділів є вступними, а також визначають термінологію. Основне, функціональний зміст стандарту зосереджено в 8-му розділі - Вимоги до документування ПС. У розділі 8.1 - Процеси документування програмних засобів представлена ??загальна схема процесів і їх взаємодія. Викладена детальна структура плану документування, орієнтованого на розробників документів, і процедури контролю реалізації плану (рис.2.2). Огляди - опису документів, рекомендується готувати у вигляді двох послідовно уточнюють і деталізують редакцій з остаточної коректурою і перевіркою їх адекватності шляхом тестування.

малюнок 2

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

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

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

Процес документування повинен бути виконаний в два етапи в послідовності, представленої на рис. 3.

малюнок 3

Поетапні роботи виконуються не одночасно. На окремих етапах роботи можуть проводитися паралельно. Можливі ітерації робіт показані пунктирними лініями. Мінімальний склад документації визначається замовником (наприклад, з використанням ISO12207 або ISO 6592), Що має бути враховано документатор при розробці плану документування.

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

- Конкретної експлуатаційної середовища та її характеристики;

- Основних компонентів системи і зв'язків між ними;

- Зовнішніх інтерфейсів системи;

- Можливостей і функцій системи;

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

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

- Рівнів і циклів технічного обслуговування;

- Форм реєстрації виявлених дефектів;

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

- Концепцію поставки нової або модифікованої версії, експлуатаційний сценарій;

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

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

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

- До робочої копії програмного засобу (при необхідності);

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

- До типових користувачам (по можливості) для аналізу аудиторії і тестування на практичність.

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

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

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

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

- Специфікацію стилю документів;

- Визначення аудиторії і кваліфікації користувачів;

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

- Зміст (план-проспект) документації, з оцінкою її посторінкового обсягу, і відповідні уточнення для інших машинних носіїв документів;

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

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

- Рівні (грифи) секретності і конфіденційності (при необхідності);

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

- Методи і засоби виробництва (тиражування) і використовувані версії програмних засобів;

- Структуру колективу розробників документів і, можливо, плану вибору даної структури;

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

- Метод передачі документатор інформації про зміни програмного засобу в процесі його розробки;

- Плани контролю змін і супроводу документації;

- Плани перевірки документації після її створення;

- Календарне планування (графіки) за контрольними точками, включаючи (за необхідності):

 * Затвердження плану документування;

 * Підготовку, перевірку і коригування проекту кожного

документа;

 * Тестування на практичність;

 * Підготовку оригіналів шаблонів;

 * Роздруківку, переплетення і поширення документації.

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

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

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

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

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

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

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

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

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

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

- Етапи життєвого циклу розробки, на яких повинно проводитися тестування;

- Цілі тестування;

- Використовувані показники (наприклад, час реакції завдань);

- Середовище тестування;

за ними;

число і вид залучених користувачів;

процес опису результатів тестування і рекомендацій

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

- Процес доведення результатів тестування до всього персоналу розробників документів і замовника;

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

- Процес визначення необхідності подальшого тестування.

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

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

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

- Функціональні зміни даної версії - зміни функції ПС, внесені при розробці документації і відображені в опублікованій документації;

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

- Зміни ПС після публікації зміни конкретних функцій програмного засобу після видання документації;

- Зміни документа після публікації - зміни в опублікованій Документації, обумовлені змінами ПС або виявленням помилок в даній документації.

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

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

- Найменування документа і номер версії або дата були вказані в колонтитулі конкретного документа;

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

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

У стандарті ISO 15910 представлені рекомендації по створенню і застосуванню електронної документації, довідкової та діалогової інформації. У специфікації документації можуть бути вказані один або декілька з наступних типів довідкової інформації:

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

- Розширена довідка - інформація про поточний екран або вікні, включаючи її призначення і необхідний режим використання;

- Довідка про клавішах - про застосування клавіатури, функціональне призначення клавіш і їх найменування (позначення);

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

- Термінологічна довідка - визначення конкретних елементів, зв'язків з конкретною тематикою і розшифровка означень і скорочень.

У специфікації стилю електронної документації можуть бути вказані один або декілька з наступних типів діалогової, оперативної документації:

- Інструкції або рекомендації користувача - описують процедури щодо застосування продукту;

- Командні довідки - визначають синтаксис, результати і цільове призначення кожної команди (тільки для команд управління системою);

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

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

У стандарті ISO 15910 представлено вісім додатків, що містять приклади і розширюють деякі концепції базової частини стандарту:

Додаток А. Перехресні посилання з стандартом ISO 12207.

Додаток В. Використання цього стандарту в договорі і практичне застосування цього стандарту.

Додаток С. Зразок плану документування. документація користувача для системи АВС:

З 1. Вступ

С.2. Область застосування і обмеження

С.3. Оформлення і стиль опису

С.4. аудиторія

С. 5. Проект змісту документації

С. 6. Номенклатура поставки

С.7. Авторські права

С. 8. Транспортування

С.9. Процес розробки та контроль

С. 10. Тиражування

С.11. проектанти

С.12. ресурси

С.13. Тестування на практичність

С.14. Графік робіт

Додаток D. Відносини між аудиторіями, виданими завданнями, паперової та діалогової документацією.

Додаток Е. Рекомендації з написання англійською мовою документації, яка підлягає подальшого перекладу.

Додаток Е. Оцінка ресурсів для проекту документації.

Додаток G. Оцінка плану документування.

Додаток Н. Зразок специфікації стилю.

Стандарт IЕЕЕ 1063-1987 (Підтверджено в 1993 р) відображає загальні вимоги до користувальницької документації на програмні засоби широкого застосування. Стандарт визначає мінімальні вимоги до структури та змісту комплекту документів для користувачів програмних продуктів. Стандарт орієнтований на документи, що застосовуються при інсталяції, експлуатації та постачання ПС будь-якого розміру і призначення, але без зміни і супроводу програм. Він не застосуємо для технологічної документації, використовуваної при проектуванні, розробці, тестуванні, випробуваннях і супроводі ПС, а також для оформлення комерційних пакетів прикладних програм. Використання стандарту не повинно перешкоджати застосуванню більш суворих і широких вимог до документів, а також власних стандартів підприємства по стилю викладу документів.

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

- Потенційних користувачів і технології їх взаємодії з документами;

- Комплектації і орієнтації кожного документа на певну сферу застосування;

- Способів використання документів:

 * Інструктивних для навчання застосуванню і основних операцій по експлуатації, діагностиці та інсталяції ПС;

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

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

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

- Титульного аркуша, який оформлюється за правилами підприємства з урахуванням вимог замовника;

- Обмеження на застосування документа і вказівки на авторські права на програмний продукт і призначений для користувача документ;

- Гарантії та зобов'язання за контрактом, а також умови відмови від них;

- Структура і перелік розділів документа;

- Перелік ілюстрацій (малюнків, таблиць і схем) з зазначенням сторінки тексту опису, де вони використовуються;

- Передмова:

 * Передбачуваний рівень кваліфікації і попереднє навчання користувачів;

 * Апаратна і операційне середовище, якій відповідає застосування даної версії ПС і документа;

 * Призначення документа;

 * Стилістичні особливості опису;

 * Взаємодія з іншими документами;

 * Звітність про дефекти.

Основне опис «тіло» документа:

- Навчально-методична частина:

 * Теоретичні основи даного комплексу програм;

 * Оцінити потреби і функції;

 * Технічні та адміністративні операції для запуску

задач;

 * Застереження і попередження;

 * Метод вирішення кожного завдання, їх взаємодія і обмеження;

- Довідково-рекомендує частина - конкретні рекомендації та детальні інструкції по застосуванню даного ПС:

 * Вихідні дані, необхідні для коректного функціонування програм;

 * Інформація дав їх контролю;

 * Рекомендації як призупинити виконання і провести рестарт програм;

 * Реєстрація закінчення виконання програми;

 * Склад результатів;

- Попередження про можливі помилки і дефекти освоєння і застосування;

- Додатки - детальні відомості про формати вихідних і результуючих даних, структурі файлів і екранів;

- Бібліографія;

- Глосарій;

- Індекс.

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

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

Загальні відомості: Вступ; обмеження; галузь застосування; визначення; посилання.

Призначена для користувача документація - Інструкція з експлуатації повинна містити опис, в якому міститься вся інформація, необхідна користувачеві для установки, запуску і застосування ПС. Зазвичай ця документація являє собою одне або декілька посібників, укладених разом з носіями ПС всередині упаковки, В результаті користувачі не можуть ознайомитися з детальним керівництвом до тих пір, поки пакет не куплений. Склад користувальницької документації розділ 1 стандарту представлений в п. 7.10.

Опис цілей і сфери застосування публікується на зовнішній упаковці пакета ПС. Його завданням є дати можливість майбутньому покупцеві оцінити придатність ПС до своїх за потребами. Структура цієї інформації представлена ??в розділі 2 даного стандарту (див. Ст. 7.10).

У Радянському Союзі в 70-і роки була розроблена Єдина Система Програмної документації (ЕСПД) в складі групи стандартів ГОСТ 19. ХХХ. Більшість цих стандартів застаріло, не відповідає сучасним вимогам і їх застосування не доцільно. Більш якісно стандартизація документування програм і даних відображена в деяких стандартах з автоматизованих систем ГОСТ 34. ХХХ, Затверджених в кінці 80-х років. В даний час найбільш корисно освоїти і використовувати деякі їх фрагменти, які можна віднести до документування програм і даних, з стандартів:

ГОСТ 34.201-89 Інформаційна технологія. Види, комплектність і позначення документів при створенні автоматизованих систем;

ГОСТ 34.602-90 - Інформаційна технологія. Технічне завдання на створення автоматизованих систем;

РД 50-34.698-90 Методичні вказівки. Інформаційна технологія. Автоматизовані системи. Вимоги до змісту документів.

 



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