Софтуерни технологии



страница27/106
Дата11.05.2023
Размер2.27 Mb.
#117653
ТипАнализ
1   ...   23   24   25   26   27   28   29   30   ...   106
Softuerni Texnologii
Свързани:
empty doc
5.3. Документиране
Разработването и използването на всяка софтуерна система е свързано със
създаването на множество документи, които са с различно предназначение,
67

структура и съдържание [6]. Най-общо тези документи могат да бъдат класифи-
цирани в две групи:
а) документи, свързани с процеса на създаване на софтуер — планове, гра-
фици, отчети, стандарти, протоколи от заседания, разменяни съобщения и др.
Тази документация зависи от стила на управление на проектите и се регла-
ментира от действащи в конкретната софтуерна организация вътрешни правила
и стандарти. Те определят каква е структурата на всеки документ, кой и кога го
създава, какви са процедурите за утвърждаване, използване и променяне, къде
и колко дълго се съхранява.
б) документи, описващи създадения програмен продукт
В зависимост от предназначението си тази документация може да бъде съп-
ровождаща или експлоатационна.
Предназначението на съпровождащата документация е да осигури ин-
формацията, необходима за разучаване и за внасяне на изменения в програми-
те. Тя може да включва:

  • описание на функционалните и нефункционални изисквания към ПП;

  • описание на архитектурата на софтуерната система — от какви основ-
    ни компоненти се състои и какви са връзките между тях;

  • за всяка компонента — описание на спецификациите и на детайлния

проект;

  • първичен текст на програмата. В някои организации има стандарт за
    т. нар. вътрешно документиране на програмите чрез коментари.

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

Предназначението на експлоатационната документация е да осигури ин-
формацията, необходима за използването на софтуерната система от крайни пот-
ребители или администратори, което отговарят за функционирането на системата.
Документацията за администратора се състои от:

  • инструкция за инсталиране. Тя съдържа указания, как да се инсталира|
    системата в конкретна потребителска среда и какви са техническите изисква
    ния към хардуерната конфигурация.

  • ръководство за администратора. То описва връзките с други системи,'
    обяснява извежданите съобщения и възможни действия при получаването им,
    определя същността и начина на извършване на някои сервизни функции, като
    архивиране, възстановяване на системата след срив, преконфигуриране и др.

От изключително значение е и документацията за крайния потребител. Съ-
ществуват различни стандарти за съдържанието на потребителската документа
ция — например стандарт ANSI/IEEE Std 1063-1987. Потребителската доку
ментация може да се състои от две части — обучаваща и справочна. Обучава
щата част е предназначена за начинаещи потребители, а справочната — за пот
ребители с по-голям опит, които се нуждаят от информация за възможностите
на системата. Справочната част обикновено представя основните функции, под
редени по определен начин за бързо търсене — например по азбучен ред.
Стилът на изложение зависи от някои характеристики на потенциалните
потребители, като образование, квалификация, ниво на компютърна грамот-
ност и др. Ако в изискванията към системата има и описани характеристики на
потребителя, то те трябва да се вземат предвид.
68
Могат да бъдат формулирани следните изисквания към потребителската
документация:
а) Правилност. Трябва да има пълно съответствие между функционира-
нето на програмната система и описанието й в документацията. След всяка но-
ва версия трябва да се обновява и документацията, като се проверяват и изло-
жените примери, така че потребителят да не бъде насочван погрешно.
б) Пълнота и структурираност. Да има подробно съдържание и дори
каква последователност на четене да се следва от потребителите с различна ква-
лификация и опит.
в) Стилът на изложение да е ясен, недвусмислен и съобразен с термино-
логията в съответната област на приложение. Да се избягват тривиалните обяс-
нения и примери.
г) Ръководството за потребителя да бъде относително затворена систе-
ма, съдържаща необходимата и достатъчна информация. Да се избягват слож-
ните препратки дори с цената на повтаряне на информация. Да няма препратки
към труднодостъпни източници.
Всяка организация трябва да определи свои вътрешни стандарти за начина
на създаване на документацията и за самата документация — от кои документи
ще се състои и как ще се идентифицират те, каква да е структурата и съдържа-
нието на всеки документ, какви правила при оформянето на документите ще се
спазват (обща структура на документите, начин на оформление на страниците,
номерация, използвани шрифтове, цветове и др.), каква ще е процедурата за
внасяне на изменения.
В България съществуват стандарти от серията БДС ЕСПО. Те имат номера
БДС 19.ХХХ-УУ, където XXX е номерът на стандарта, а УУ — годината на
създаването му. Тези стандарти са от периода 1978—1980 година и са морално
остарели.
Съществуват автоматизирани средства, подпомагащи съставянето, офор-
мянето и отпечатването на различните видове документи. Освен намаляване на
времето и усилията за документиране преимущество на използването на такива
средства е възможността за поддържане на пълно съответствие между послед-
ното състояние на софтуерната система и всички описващи я документи.
Литература

  1. Манева, Н. Основни тенденции при разработването на средства за тестване на програми.
    АИТ и АС, №3,1987, с. 77—84.

  2. Sneed, H., К. Kirchoff. PRUFFSTAND — A Testbed for Systematic Software Components.
    Proc. INFOTECH State of the Art Conf. on Software Testing, 1978, London.

  3. Thomas, P., Practical Software Maintenance. NY Wiley, 1997.

  4. James, M., Software maintenance. NY Prentice Hall, 1983.

  5. Belady, L., M. Lehman. An Introduction to Growth Dynamics, m W. Freinberger (ed.) Statistical
    Computer Performance Evaluation, Academic Press, 1972.

  6. Guidelines for the documentation of software in industrial computer systems (publ. by IEEE)
    1987.

69



Сподели с приятели:
1   ...   23   24   25   26   27   28   29   30   ...   106




©obuch.info 2024
отнасят до администрацията

    Начална страница