Реферати

Реферат: Документування програмного забезпечення

Система місцевого самоврядування в Росії (XV-XVII вв.). Інститут місцевого самоврядування в Російській державі, історія його формування і розвитку. Реформи місцевого самоврядування в Росії в період кінця XV - початку XVII вв. Аналіз причин уведення губного і земського керування, компетенція установ.

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

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

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

Шартрский собор. Історія створення собору як приклад готичної архітектури.

Коледж Інформатики і Обчислювальної Техніки

Факультет програмування

РЕФЕРАТ

Дисципліна: технологія програмування.

Тема: документування програмного забезпечення.

Виконав студент:

Таллинн

2003

Зміст

1. Документування програмного забезпечення.

1.1 Технічне завдання.

1.2 Зовнішні і внутрішні мови специфікації.

1.3 Керівництво користувача.

1.4 Керівництво програміста.

Документування програмного забезпечення

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

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

Технічне завдання

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

Технічне завдання на розробку ПО повинно включати наступні розділи:

вступ;

основи для розробки;

призначення розробки;

вимоги до програми;

вимоги до програмної документації;

техніко-економічні показники;

стадії і етапи розробки;

порядок контролю і приймання;

додатки.

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

У розділі "Введення" вказується найменування, коротка характеристика області застосування ПО.

У розділі "Основи для розробки" вказується:

документ (документи), на основу яких ведеться розробка;

організація, що затвердила документ, і дата твердження;

найменування (умовне позначення) теми розробки.

У розділі Призначення розробки повинне бути вказане функціональне і експлуатаційне призначення ПО.

Наприклад, UML - як універсальна мова моделювання. Може використовуватися і для постановки технічного завдання.

Зовнішні і внутрішні мови специфікації

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

Угода про вимоги;

Зовнішня специфікація;

Внутрішня специфікація.

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

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

1. ОПИС ПРОГРАМНОГО ВИРОБУ

1.1. Найменування і шифри ПО (повне найменування, скорочені найменування, шифри ПО і проекту).

1.2. Короткий опис ПО (включаючи відомості про авторське право, ієрархію документів, з вказівкою документів вищестоящих рівнів).

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

2. ЦІЛІ

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

3. СТРАТЕГІЯ

3.1. Угоди відносно представлення матеріалу.

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

3.1.2. Термінологія (особливо специфічна для даного виробу).

3.1.3. Синтаксис (приводяться, якщо необхідно, синтаксичні правила для подальшого опису вимог).

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

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

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

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

3.3.n.1. Внешние ограничения.

3.3.n.1.1. Стандарти (список промислових стандартів, що використовуються і власних стандартів підприємства).

3.3.n.1.2. Ограничения на совместимость. Необхідно розглядати декілька аспектів сумісності:

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

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

виробами-компаньйонами (т. е. що відносяться до тієї ж групи коштів і що є альтернативою);

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

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

3.3.n.1.4. Аппаратние ограничения. Приводиться перелік пристроїв, необхідних для роботи ПО (з вказівкою мінімальної, оптимальної і максимальної конфігурації). Вказуються все діючі обмеження на обладнання, наприклад, фізичні характеристики термінала або вимога заборони використання звукового сигнального пристрою.

3.3.n.2. Внешние характеристики.

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

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

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

3.3.n.2.3. Входи. Опис подібно п. 3.3.2.1

3.3.n.3. Ергономические характеристики.

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

У розділі Надійність (ця властивість програми розуміється тут як здібність до відновлення нормальної роботи при помилках і збоях в роботі обладнання) розглядаються наступні питання:

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

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

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

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

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

4. МАТЕРІАЛИ (, що ВИКОРИСТОВУЮТЬСЯ в т. ч. довідкові)

5. ПЕРЕДАЧА ЗАМОВНИКУ І ВВЕДЕННЯ В ДІЮ

Керівництво користувача

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

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

У зв'язку з цим потрібно розрізнювати дві категорії користувачів: ординарних користувачів програми і адміністраторів. Ординарний користувач програми (end-user) використовує програму для рішення своїх задач (в своїй предметній області). Це може бути інженер, що проектує технічний пристрій, або касир, що продає залізничні квитки за допомогою даної програми. Він може і не знати багатьох деталей роботи комп'ютера або принципів програмування. Адміністратор программни (system administrator) управляє використанням програми ординарними користувачами і здійснює супровід програмного засобу, не пов'язаний з модифікацією програм. Наприклад, він може регулювати права доступу до програми між ординарними користувачами, підтримувати зв'язок з постачальниками програми або виконувати певні дії, щоб підтримувати програму в робочому стані, якщо воно включене як частина в іншу систему.

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

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

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

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

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

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

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

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

Керівництво програміста

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

Документація по супроводу програмного засобу можна розбити на дві групи:

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

2. документацію, що допомагає вносити зміни в програмний засіб.

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

Зовнішній опис програмного засобу (Requirements document).

Опис архітектури програмного засобу (description of the system architecture), включаючи зовнішню специфікацію кожної її програми.

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

Для кожного модуля - його специфікація і опис його будови (design description).

Тексти модулів на вибраній мові програмування (program source code listings).

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

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

Документація другої групи містить

Керівництво по супроводу програмного засобу (system maintenance guide), який описує відомі проблеми разом з програмним засобом, описує, які частини системи є апаратно- і програмно-залежними, і як розвиток програмного засобу прийнятий в розрахунок в його будові (конструкції).

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

Вигляд експлуатаційного документа

Зміст експлуатаційного документа

Відомість експлуатаційних документів

Перелік експлуатаційних документів на програму.

Формуляр

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

Опис застосування

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

Керівництво системного програміста

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

Керівництво програміста

Зведення для експлуатації програми.

Керівництво оператора

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

Опис мови

Опис синтаксису і семантики мови.

Керівництво по технічному обслуговуванню

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

1. http://www.ergeal.ru/archive/cs/tp/ - Технологія програмування, конспект лекцій ВМіК МГУ, кафедра системного програмування

2.http://www.aanet.ru/~web_k46/textbooks/st d_pro/face.htm - Богдана Д. В., Путілов В. А., Фільчаков В. В. Стандартізация процесів забезпечення якості програмного забезпечення. - Апатити, КФ ПетрГУ, 1997.