Тема 6. Вивчення інформаційного і програмного забезпечення конкретної задачі. Питання для самостійного вивчення

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

МЕТОДИЧНІ РЕКОМЕНДАЦІЇ

Провести аналіз задачі яку винесено на індивідуальне завдання.

Підібрати необхідне програмне та технічне забезпечення для вирішення поставленої задачі.

Описати принципи використання підібраного програмного забезпечення для вирішення задач.

Тема 7. Розробка програм для удосконалення або модифікації конкретної задачі. Питання для самостійного вивчення

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

Реалізувати розроблені алгоритми та написати програмний код. Детально розкрити кожен ключовий блок програми з детальним описом команд які використані.

МЕТОДИЧНІ РЕКОМЕНДАЦІЇ

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

Технічні документи – узагальнююче назва документів (графічних і текстових), у яких зафіксована технічна думку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

програми.

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

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

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

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

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

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

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

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

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

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

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

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

Нижче наведена загальна структура документа "Зовнішня специфікація", зрозгорнутими коментарями в тих пунктах, які стосуються технічноїсторони справи 1. ОПИС ПРОГРАМНОГО ВИРОБИ 1.1. Найменування і шифри ПЗ (повне найменування, скороченінайменування, шифри ПЗ та проекту). 1.2. Короткий опис ПЗ (включаючи відомості про авторське право, ієрархіюдокументів, із зазначенням документів вищіх рівнів). 1.3. Результуючі компоненти ПЗ (оформляється у вигляді таблиці або іншийформи і включає в себе, перелік специфікацій, іншої документації ікомпонентів програмного забезпечення).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Документація із супроводження програмного засобу (systemdocumentation) описує програмний засіб з точки зору її розробки.

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

Документація із супроводження програмного засобу можна розбити на двагрупи: 1. документація, яка визначає будову програм і структур даних ПС ітехнологію їх розробки; 2. документацію, що допомагає вносити зміни в програмний засіб. Документація першої групи містить підсумкові документи кожноготехнологічного етапу розробки програмного засобу. Вона включаєнаступні документи: Зовнішнє опис програмного засобу (Requirements document). Опис архітектури програмного засобу (description of the systemarchitecture), включаючи зовнішню специфікацію кожної її програми. Для кожної програми програмного засобу - опис її модульноїструктури, включаючи зовнішню специфікацію кожного включеного до неї модуля. Для кожного модуля - його специфікація і опис його будови (designdescription).

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

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

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

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

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

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

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