Ім'я файлу: Л1.pdf
Розширення: pdf
Розмір: 138кб.
Дата: 05.04.2021
скачати

ЛЕКЦІЯ 1. ДОКУМЕНТАЦІЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ.
Конструювання ПЗ – створення ПЗ з конструкцій (блоків, операторів,
функцій) і його перевірка методами верифікації і тестування. До інструментів конструювання ПЗ віднесені мови конструювання, програмні методи й
інструментальні системи (компілятори, СКБД, генератори звітів, системи керування версіями, конфігурацією, тестуванням й ін.). До формальних засобів опису процесу конструювання ПЗ, взаємозв'язків між людиною і
комп'ютером з урахуванням середовища оточення віднесені структурні
діаграми Джексона.
Область знань «Конструювання ПЗ (Software Construction)» містить у собі такі розділи:
– зниження складності (Reduction in Complexity),
– попередження відхилень відстилю (Anticipation of Diversity),
– структуризація перевірок (Structuring for Validation),
– використання стандартів (Use of External Standards).
Базову складову професійної діяльності фахівців в галузі програмної
інженерії формують вміння та навички конструювання програмного забезпечення. До складу обов’язкового обсягу практичних навичок фахівця напряму «Програмна інженерія» повинні входити поняття про методи ефективного та оптимального кодування алгоритмів .
Програміст повинен генерувати не просто будь-який код, який працює, а
і обов’язково володіти якісним стилем програмування, методами документування, застосовувати методи мінімізації коду, проводити ефективний пошук помилок, зокрема не явних на етапі відладки та вміти якісно тестувати власний програмний продукт.

1. ОСНОВНІ ТЕОРЕТИЧНІ ВІДОМОСТІ КОНСТРУЮВАННЯ
ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ.
Термін КПЗ описує детальне створення робочої програмної системи за допомогою комбінації кодування, верифікації, модульного тестування,
інтеграційного тестування і налагодження.Процес конструювання сильно пов'язаний з проектуванням
і тестуванням тому конструювання відштовхується від результатів проектування, а тестування означає роботу з результатами конструювання. Досить складно визначити межу між цими складовими тому вони всі пов'язані в один комплекс життєвого циклу ПЗ.
У процесі розробки ПЗ виникають такі задачі, які пов'язані з конструюванням:перевірка виконання умов, необхідних для успішного конструювання:

визначення способів подальшого тестування коду;

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

створення та присвоєння імен змінних та іменованих констант;

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

блочне тестування, інтеграційне тестування і відлагодження власного коду;

взаємний огляд коду та низькорівневих програмних структур членами групи;

"шліфування" коду шляхом його ретельного форматування та коментування;

інтеграція програмних компонентів, створених окремо;

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

Визначення проблеми
Розробка вимог
Детальне проектування
Корективна підтримка
Інтеграція
Кодування та відлагодження
Планування конструювання
Unit-тестування
Інтеграційне тестування
Архітектура програмного забезпечення
Системне тестування
Рис.1.1 Конструювання серед процесів побудови програмного забезпечення
Процеси конструювання зображені всередині сірого еліпсу. Головними компонентами конструювання є кодування та відлагодження, однак воно включає і детальне проектування, блочне тестування, інтеграційне тестування та інші процеси.
Іноді конструювання називають "кодуванням" або "програмуванням".
Кодування в даному випадку видається не найкращим терміном, так як воно має на увазі механічну трансляцію розробленого плану в команди мови програмування, тоді як конструювання є зовсім не механічним процесом і
часто пов’язане з творчістю та аналізом. Сенс слів "конструювання" та "програмування" досить близький.
Дана область знань пов'язана з іншими областями. Найбільш сильний зв'язок
існує з проектуванням
(SoftwareDesign)
і тестуванням
(SoftwareTesting). Причиною цього є те, що сам по собі процес конструювання програмного забезпечення зачіпає важливі аспекти діяльності
з проектування й тестування. Крім того, конструювання відштовхується від результатів проектування, а тестування (у будь-якій своїй формі) передбачає
роботу з результатами конструювання. Хоча ряд операцій з проектування детального дизайну може відбуватися до стадії конструювання, великий обсяг такого роду проектних робіт відбувається паралельно з
конструюванням або як його частина. Це є сутність зв'язку з областю знань "Проектування програмного забезпечення".
У свою чергу, протягом всієї діяльності з конструювання, інженери використовують модульне і інтеграційне тестування. Таким чином пов'язана дана галузь знань з "Тестуванням програмного забезпечення".
У процесі конструювання звичайно створюється більша частина активів програмного проекту - конфігураційних елементів (configurationitems). Тому в реальних проектах просто неможливо розглядати діяльність по конструюванню у відриві від галузі знань "конфігураційного управління"
(SoftwareConfigurationManagement).
Так як конструювання неможливе без використання відповідного
інструментарію і, ймовірно, дана діяльність є найбільш інструментально- насиченою, важливу роль у конструюванні грає область знань "Інструменти і
методи програмної інженерії" (SoftwareEngineeringToolsandMethods).
Безумовно, питання забезпечення якості значимі для всіх галузей знань і
етапів життєвого циклу. У той же час, код є основним результуючим елементом програмного проекту. Таким чином, явно напрошується і
присутній зв'язок обговорюваних питань з областю знань "Якість програмного забезпечення" (SoftwareQuality).
З пов'язаних дисциплін програмної інженерії (Related Disciplines of
Software Engineering) найбільш тісний і природний зв'язок даної галузі знань
існує з комп'ютерними науками (computerscience). Саме в них, звичайно,
розглядаються питання побудови та використання алгоритмів і практик кодування. Нарешті, конструювання стосується і управління проектами
(projectmanagement), причому, в тій мірі, наскільки діяльність з управління конструюванням важлива для досягнення результатів конструювання.

Ри с.1.2. Область знань «Конструювання програмного забезпечення»
З іншого боку, з видів діяльності, що проходять в процесі розробки програмного забезпечення, до конструювання не відносяться: керування процесом розробки, виробки вимог, розробка високорівневої архітектури програми, проектування інтерфейсу користувача, тестування системи і її
супроводження – для кожного з цих пунктів є своя наука.
Фундаментальні основи конструювання програмного забезпечення включають:

Мінімізація складності

Очікування змін


Конструювання з можливістю перевірки

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

Огляд, оцінка коду (codereview)

Модульне тестування (unit-testing)

Структурування коду для
і спільно з застосуванням автоматизованих засобів тестування (automatedtesting)

Обмежене застосування складних або важких для розуміння мовних структур.
Стандарти, які безпосередньо застосовуються при конструюванні,
включають:

Комунікаційні методи (наприклад, стандарти форматів документів і
оформлення вмісту)

Мови програмування і відповідні стилі кодування (наприклад,
JavaLanguageSpecification, що є частиною стандартної документації
JDK - JavaDevelopmentKit і JavaStyleGuide, що пропонує загальний стиль кодування для мови програмування Java)

Платформи (наприклад, стандарти програмних інтерфейсів для викликів функцій операційного середовища, такі як прикладні
програмні інтерфейси платформи
Windows
-
Win32
API,
ApplicationProgrammingInterface або
.NETFrameworkSDK,
SoftwareDevelopmentKit)

Інструменти (не в термінах середовищ розробки, але можливих засобів конструювання - наприклад, UML як один зі стандартів для визначення нотацій для діаграм, що представляють структура коду і
його елементів або деяких аспектів поведінки коду).
Конструювання залежить від зовнішніх стандартів, пов'язаних з мовами програмування, використовуваним
інструментальним забезпеченням,
технічними інтерфейсами і взаємним впливом конструювання програмного забезпечення та інших галузей знань програмної інженерії (в тому числі,
пов'язаних дисциплін, наприклад, управління проектами). Стандарти створюються різними органами, наприклад, консорціумом OMG
-
ObjectManagementGroup
(зокрема. Стандарти CORBA, UML, MDA,),
міжнародними організаціями з стандартизації такими, як ISO/IEC, IEEE,
TMF, виробниками платформ, операційних середовищ і т.д. (Наприклад,
Microsoft, SunMicrosystems, CISCO, NOKIA), виробниками інструментів,
систем управління базами даних і т.п. (Borland, IBM, Microsoft, Sun, Oracle,
Розуміння цього факту дозволяє визначити достатній і повний набір стандартів, які застосовуються у проектній команді або організації в цілому.
Кожна програмна система протягом свого існування проходить з певною послідовністю фази або стадії від задуму до його втілення в програми,
експлуатацію та вилучення. Така послідовність фаз називається життєвим циклом розробки (Software life cycle processes). На кожній фазі відбувається певна сукупність процесів, кожен з яких породжує певний продукт,
використовуючи певні ресурси.
Усі продукти всіх процесів програмної інженерії являють собою певні
описи

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

Головними ресурсами програмної
інженерії, які визначають ефективність її розробок, є час і вартість цих розробок.
Різновиди діяльності, котрі становлять процеси життєвого циклу програмної системи, зафіксовано в міжнародному стандарті ISO/IEC 12207 :
1995—0801 : Informational Technology – Software life cycle processes.
Згідно з наведеним стандартом, усі процеси поділено на три групи:

головні процеси;

допоміжні процеси;

організаційні процеси.
До головних процесів віднесено такі:

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

процес розроблення, який означає дії організації

розробника програмного продукту;

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

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

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

інженерія вимог до системи;

проектування;

кодування й тестування.
До допоміжних процесів віднесено ті, що так чи інакше забезпечують якість продукту.
Терміном якість продукту позначено сукупність
властивостей, які зумовлюють можливість задоволення потреб замовника,
котрий сформулював їх у формі вимог на розробку.
До організаційних процесів віднесено менеджмент розробки, створення структури організації, навчання персоналу, визначення відповідальності
кожного з учасників процесів життєвого циклу розробки.
Стандарт ISO/IEC 12207:1995 - 0801: Informational Technology – Software life cycle processes є головним чинником визначення змісту діяльності у сфері
програмної інженерії, і всі знання, яких потребують професіонали з програмної інженерії, формулюються стосовно процесів, визначених цим стандартом.
Зупинимося докладніше на процесах розробки програмного забезпечення, які в сукупності мають забезпечити шлях від усвідомлення потреб замовника до передавання йому готового продукту. На цьому шляху виділяють низку характерних робіт:

Визначення вимог. Збір та аналіз вимог замовника виконавцем і подання
їх у нотації, яка є зрозумілою як для замовника, так і для виконавця.

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

Реалізація. Перетворення проектних рішень на програмну систему, яка реалізує такі рішення.

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

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

Базовими вітчизняними нормативними документами в галузі програмної
інженерії є:

ДСТУ 2873-94. Системи обробки інформації. Програмування. Терміни та визначення.

ДСТУ 2941-94. Системи оброблення інформації. Розроблення систем.
Терміни та визначення.

ДСТУ
4302:2004.
Інформаційні технології.
Настанови щодо документування комп’ютерних програм.

ДСТУ ISO/IEC 12119:2003. Інформаційні технології. Пакети програм тестування і вимоги до якості.

ДСТУ ISO/IEC 14764:2002. Інформаційні технології. Супроводження програмного забезпечення.

ДСТУ ISO/IEC 90003:2006. Програмна інженерія. Настанови щодо застосування ІSO 9001:2000 до програмного забезпечення (ІSO/ІЕС
90003:2004, IDT)

ДСТУ ISO/IEC TR 12182:2004. Інформаційні технології. Класифікація програмних засобів (ISO/IEC TR 12182:1998, IDT)

ДСТУ ISO/IEC 14598-1:2004. Інформаційні технології. Оцінювання програмного продукту. Частина 1. Загальний огляд (ISO/IEC 14598-1:1999,
IDT)

ДСТУ ISO/IEC 15288:2005. Інформаційні технології. Процеси життєвого циклу системи (ISO/IEC 15288:2002, IDT)

ДСТУ ISO/IEC 15939:2008. Інженерія систем і програмних засобів.
Процес вимірювання.

ДСТУ 3327-96. Методика випробування процесорів мов програмування.
Загальні вимоги.

ДСТУ
ISO/IEC
TR
14369:2003.Інформаційні технології.
Мови програмування, їхнє середовище та системний інтерфейс. Настанова щодо підготовки незалежних від мов специфікацій послуг.


ДСТУ 4072:2001. Інформаційні технології. Мови програмування, їхнє
середовище та системний інтерфейс. Настанова щодо підготовки незалежних від мов виклик процедур.

ДСТУ ISO/IEC 2382-15:2005. Інформаційні технології. Словник термінів.
Частина 15. Мови програмування (ISO/IEC 2382-15:1999, IDT)

ДСТУ3008-95. "Документація. Звіти у сфері науки і техніки Структура і
правила оформлення". К.: Держстандарт України,1995. – 75 с.

ГОСТ 2.106-96. Единая система конструкторской документации.
Текстовые документы. Изд. Офиц – К.: Госстандарт Украины, 1998. – 47 с.

ГОСТ 2.109-73 ЕСКД. Основные требования к чертежам – М., 1978.

ГОСТ 2.105-95. Единая система конструкторской документации. Общие требования к текстовым документам. Изд. Офиц – К.: Госстандарт
Украины, 1996.

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

При розробці ПЗ створюється і використовується великий обсяг різноманітної документації. Вона необхідна як:

Засіб передачі інформації між розробниками ПЗ

Засіб управління розробкою ПЗ

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

Документи управління розробкою ПЗ.

Документи, що входять до складу ПЗ.
Документи управління розробкою ПЗ (software process documentation)
керують і протоколюють процеси розробки і супроводу ПЗ, забезпечуючи зв'язки всередині колективу розробників ПЗ і між колективом розроблювачів
і менеджерами ПЗ (software managers) особами, які керують розробкою ПЗ.
Ці документи можуть бути наступних типів:

Плани, оцінки, розклади. Ці документи створюються менеджерами для прогнозування і управління процесами розробки і супроводу
ПЗ.

Звіти про використання ресурсів у процесі розробки. Створюються менеджерами.

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

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


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

у всякому разі, вони повинні бути перевірені (протестовані) на

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

Користувацька документація ПЗ (К-документація).

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

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

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

Керівництво з управління ПЗ. Призначено для адміністраторів ПЗ.
Воно повинно описувати повідомлення, що генеруються, коли ПЗ
взаємодіє з іншими системами,
і
як повинен реагувати адміністратор на ці повідомлення.
Крім того,
якщо
ПЗ
використовує
системну апаратуру, цей документ може пояснювати, як супроводжувати цю апаратуру.
Розробка документації користувача починається відразу після створення зовнішнього опису. (ГОСТ 2.119-73. Єдина система конструкторської
документації.
Ескізний проект.
ГОСТ
2.120-73.
Єдина система конструкторської документації. Технічний проект).
Якість цієї документації може істотно визначати успіх ПЗ. Вона повинна бути досить проста і зручна для користувача (в іншому випадку це ПЗ,
взагалі, не варто було створювати). Тому, хоча чорнові варіанти (начерки)
користувача документів створюються основними розробниками ПЗ, до створення їх остаточних варіантів часто залучаються професійні технічні
письменники. Крім того, для забезпечення якості документації користувача розроблено ряд стандартів, в яких пропонується порядок розробки цієї
документації,
формулюються вимоги до кожного виду користувача документів і визначаються їх структура та зміст.
Документація по супроводженню програмних засобів. Документація по супроводженню ПЗ (system documentation) описує ПЗ з точки зору її
розробки. Ця документація необхідна, якщо ПЗ припускає вивчення того, як воно влаштоване (сконструйована), і модернізацію його програм. Як уже зазначалося, супровід це триваюча розробка. Тому в разі потреби модернізації ПЗ до цієї роботи залучається спеціальна команда розробників- супровідників.
Цій команді
доведеться мати справу з
такою ж
документацією, яка визначала діяльність команди первісних (основних)
розробників ПЗ, з тією лише різницею, що ця документація для команди розробників-супровідників буде, як правило, чужою (вона створювалася
іншою командою).
Щоб зрозуміти будову і процес розробки модернізованого ПЗ, команда розробників-супровідників повинна вивчити цю документацію, а потім внести в неї необхідні зміни, повторюючи в значній мірі технологічні
процеси, за допомогою яких створювалося первинне ПЗ.
Документацію по супроводженню ПЗ можна розбити на дві групи:

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

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

2. Для кожного модуля його специфікація і опис його будови (design description).
3. Тексти модулів вибраною мовою програмування (program source code listings)
ГОСТ
19.401-78.
Єдина система програмної
документації. Текст програми, вимоги до змісту та оформлення.
4. Документи встановлення достовірності ПЗ (validation documents),
які описують, як встановлювалася достовірність кожної програми
ПЗ і як інформація про встановлення достовірності пов'язувалася з вимогами до ПЗ.
Документи встановлення достовірності ПЗ включають, перш за все,
документацію по тестуванню (схема тестування і опис комплекту тестів), але можуть включати і результати інших видів перевірки ПЗ, наприклад, докази властивостей програм. Для забезпечення прийнятної якості цієї документації
корисно слідувати загальноприйнятим рекомендаціям і стандартам.
Документація другої групи містить
Керівництво по супроводженню ПЗ (system maintenance guide), яке описує особливості реалізації ПЗ (зокрема, труднощі, які довелося долати) і
як враховані можливості розвитку ПЗ в його будові (конструкції). У ньому також фіксуються, які частини ПЗ є апаратно і програмно залежними.
Загальна проблема супроводу ПЗ забезпечити, щоб всі його операції
йшли послідовно (залишалися узгодженими), коли ПЗ змінюється. Щоб цьому зарадити, зв'язки і залежності між документами і їх частинами повинні
бути відображені в керівництві по супроводженню, і зафіксовані в базі даних управління конфігурацією.

скачати

© Усі права захищені
написати до нас