Українські рефератиучбові матеріали на українській мові

RefBaza.com.ua пропонує студентам та абітурієнтам найбільшу базу з рефератів! Також ви можете ділитися своїми рефератами для поповнення бази.

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

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

Зміст

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. Обмеження на сумісність. Необхідно розглядати кілька аспектів сумісності:

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

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


Схожі реферати

Статистика

[1] 2 3