Как разработать руководство программиста

Составление
руководства системного программиста
— цель третьей части второй лабораторной
работы. Также руководство системного
программиста является пятым разделом
курсовой работы.

Требования
к оформлению руководства системного
программиста излагаются в ГОСТ 19.503-79
«Руководство системного программиста.
Требования к содержанию и оформлению».

5.1 Гост 19.503-79

Настоящий
стандарт устанавливает требования к
содержанию и оформлению программного
документа «Руководство системного
программиста», определенного ГОСТ
19.101-77.

Стандарт
полностью соответствует CТ
СЭВ 2094-80.

5.1.1 Общие положения

1.1.
Структуру и оформление документа
устанавливают в соответствии с ГОСТ
19.105-78.

1.2.
Руководство системного программиста
должно содержать следующие разделы:

– общие
сведения о программе;

– структура
программы;

– настройка
программы;

– проверка
программы;

– дополнительные
возможности;

– сообщения
системному программисту.

В
зависимости от особенностей документа
допускается объединять отдельные
разделы или вводить новые. В обоснованных
случаях допускается раздел «Дополнительные
возможности» не приводить, а в наименованиях
разделов опускать слово «программа»
или заменять его наименованием программы.

5.1.2 Содержание разделов

2.1.
В разделе «Общие сведения о программе»
должны быть указаны назначение и функции
программы и сведения о технических и
программных средствах, обеспечивающих
выполнение данной программы.

2.2.
В разделе «Структура программы» должны
быть приведены сведения о структуре
программы, ее составных частях, о связях
между составными частями и о связях с
другими программами.

2.3.
В разделе «Настройка программы» должно
быть приведено описание действий по
настройке программы на условиях
конкретного применения (настройка на
состав технических средств, выбор
функций и др.). При необходимости приводят
поясняющие примеры.

2.4.
В разделе «Проверка программы» должно
быть приведено описание способов
проверки, позволяющих дать общее
заключение о работоспособности программы
(контрольные примеры, методы прогона,
результаты).

2.5.
В разделе «Дополнительные возможности»
должно быть приведено описание
дополнительных разделов функциональных
возможностей программы и способов их
выбора.

2.6.
В разделе «Сообщения системному
программисту» должны быть указаны
тексты сообщений, выдаваемых в ходе
выполнения настройки, проверки программы,
а также в ходе выполнения программы,
описание их содержания и действий,
которые необходимо предпринять по этим
сообщениям.

2.7.
В приложении к руководству системного
программиста могут быть приведены
дополнительные материалы (примеры,
иллюстрации, таблицы, графики и т.п.).

5.2 Пример

5.2.1 Общие сведения о программе

Программа
«Автоматизированное рабочее место
читателя» предназначена для обеспечения
простого и удобного доступа удаленных
пользователей к ресурсам различных
информационных служб. Удаленными
пользователями могут являться любые
пользователи HTTP-сервера, на базе
которого функционирует программа.
Ресурсами информационных служб могут
являться различные удаленные базы
данных (библиографические, полнотекстовые,
базы данных запросов на доставку
документов, тезаурусы), доступные по
протоколу ISO 23950. Таким образом, программа
является промежуточным звеном многозвенной
информационной системы, обеспечивающим
пользователей следующими возможностями:

• поиск
  библиографической, полнотекстовой
  информации, информации о заказах,
  сведений о местонахождении и доступности
  документа в удаленных базах данных с
  возможностями устранения дублетности,
  навигации по поисковым индексам и
  автоматического расширения запроса с
  использованием тезаурусов и авторитетных
  файлов;

• заказ
  документа (копии) по найденному
  библиографическому описанию;

• проверка
  статуса заказа;

• вывод
  списка документов, полученных во
  временное пользование.

Другими
словами, программа является Z39.50-клиентом
с Web-интерфейсом пользователя. Поэтому
для работы с программой пользователю
необходимы
лишь Web-агент (Netscape
Navigator,
MS
Internet
Explorer,
Lynx
и т.п.) и надежная связь с HTTP-сервером,
на котором выполняется программа.

Программа
может функционировать на любых технических
средствах под управлением любой
операционной системы, отвечающей
стандарту ISO/IEC
9945-1 (POSIX)
и спецификациям X/Open
CAE
specifications,
Issue
4, July
1992 (XPG4).
Обязательными требованиями для выполнения
программы являются поддержка стека
протоколов TCP/IP и наличие HTTP-сервера,
поддерживающего CGI.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Если кроме использования и настройки, программное обеспечение предоставляет возможность написания, редактирования или использования программного кода. Какой документ необходим в этом случае?

Назначение руководства программиста

Руководство программиста относится к эксплуатационно-технической документации и требуется в тех случаях, когда система тем или иным образом предоставляет возможность написания, редактирования или использования программного кода.

Примерами могут служить:

– библиотека функций;

– платформа или среда для разработки ПО;

– ПО с открытым кодом.

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

– назначение, структуру входных и выходных данных программных функций;

– возможности по созданию программного кода, особенности его интерпретации и компиляции;

– синтаксические особенности используемого языка программирования;

– возможные правила и ограничения при работе с программным кодом;

– различные инструкции по работе с программой.

Список возможных тем этим не ограничивается, все зависит от особенностей конкретной системы. Надо сказать, что руководство программиста бывает очень полезно и для разработчиков системы, являясь справочником по текущей реализации логики работы ПО.

Состав типового руководства программиста

В соответствии с требованиями ГОСТ руководство программиста должно содержать следующие разделы:

– Назначение и условия применения программы, где указывают область применения ПО и технические требования, необходимые для его работы.

– Характеристика программы, где описывают режим работы программы, показатели скорости ее работы и другие важные для использования характеристики.

– Обращение к программе, где указывают способы и параметры запуска программы;

– Входные и выходные данные, где описывают формат, способ организации и другие требования к входным и выходным данным;

– Сообщения, где приводят тексты сообщений, выдаваемых программой в различных ситуациях и действия, которые необходимо при этом предпринять.

Различные примеры, иллюстрации и таблицы целесообразно приводить в приложениях к документу.

Стандарты для руководства программиста

ГОСТы регламентируют и этот документ, в данном случае это ГОСТ 19.504. В соответствии с ним определяется структура и содержание Руководства программиста.

Стоимость разработки руководства программиста

Наименование документа	Наименование стандарта	Стоимость разработки
Руководство программиста на ПО	ГОСТ 19.504	от 100 тыс. р.

Работа по созданию руководства программиста требует высокой квалификации специалиста и знаний в области программирования, однако, для профессиональных разработчиков такая работа обычно представляется скучной и нудной, к тому же, требует умения грамотно формулировать и доступно доносить материал. Специалисты ТехРайтКонсалт обладают большим опытом в обеих областях, что позволяет нам создавать документы по доступной цене и точно в срок!

Возможно, вас также заинтересует:

– разработка руководства администратора;
– создание руководства пользователя;
– разработка руководства оператора.

---

Разработка руководства программиста

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

Когда требуется руководство программиста?

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

Руководство программиста должно составляться грамотным профессионалом, знакомым со спецификой работы конкретного программного продукта и правилами составления подобных документов, регламентируемых по ГОСТ 19.504-79.

Структура документа

Требования к заполнению руководств программиста установлены соответствующим государственным стандартом. Структура такого документа должна включать в себя:
Предназначение и условия эксплуатации программного продукта.
Основные характеристики программы.
Методы обращения к программному продукту.
Основная входная и выходная информация.
Сообщения.

На данный момент руководство программистов включает также различные схемы — схемы баз данных, диаграммы классов, графы вызова функций.

Оформите заявку и задавайте все интересующие вас вопросы по телефону
+7(499)755-74-33 e-mail Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. или через форму заказа.

Составляем документацию разработчика пошагово без диет и тренировок

Недостаточно просто написать инструкции — важно, как, в каком порядке и где вы их разместите. 

Привет! Это Теодора — технический писатель Платформы, жизненно важного департамента Ozon. Документация для нас имеет большое значение, потому что вся компания пользуется нашими разработками: 

• инфраструктурой as a service;

• фреймворками и библиотеками на Go, C#, TypeScript;

• трейсингом, мониторингом, логированием, нагрузочным тестированием;

• инструментами для работы с базами данных и аналитикой;

• виртуализацией и контейнеризацией.

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

Дисклеймер: в этой статье упор сделан на содержание, структуру и формат. Сугубо гуманитарные вещи вроде орфографии и пунктуации обсуждать не будем — они на вашей совести.

Зачем вам документация

Документация — один из вариантов коммуникации. Обычно к ней прибегают, когда личное общение не решает проблему. Например, когда вы физически не успеваете до всех донести информацию, а кроме вас, это сделать никто не может.

Плюсы хорошей документации:

• увеличивается bus-фактор: знание распространяется между большим числом людей, и его сложнее потерять;

• команда не отвлекается на ответы на одни и те же вопросы и занимается своей работой;

• коллеги быстро находят ответы (в том числе через Ctrl+F), решают проблемы и разбираются в технологии: как следствие, увеличиваются их продуктивность и доход компании;

• для внешней документации: разгружает сотрудников техподдержки.

---

Хорошая ли у вас документация?

Пройдите маленький тест и посчитайте набранные баллы:

Результаты:

У всех разные ситуации с документацией, поэтому алгоритм действий может различаться для каждого конкретного случая. В статье описаны десять шагов, но не все из них подойдут именно вам. Например, если у вас вообще нет документации, вам не нужно выполнять шаг про удаление неактуального.

Не торопитесь переходить к действиям — сначала налейте чай и просто прочитайте статью.

---

Шаг 1. Соберите всю информацию

Давайте посмотрим, какой материал у вас уже есть. Для этого соберите все описания вашей технологии из разных источников:

• старая документация;

• личные страницы — ваши и коллег (например, в Confluence);

• ответы в чатах;

• репозитории (например, в GitLab);

• Word и другие текстовые редакторы;

• ссылки в закладках браузера.

На будущее: никогда не дублируйте инструкции в разных ресурсах, так их будет сложнее поддерживать: 

• легче обновить одну, чем две;

• одну из версий точно забудут обновить — и она будет вводить в заблуждение; как назло всегда будут находить именно её.

---

Шаг 2. Выбросите мусор

Одна актуальная статья лучше десяти устаревших.

Проверено: если у вас в документации найдут устаревшие сведения, никто не будет читать дальше — спросят у вас лично.

Самый важный шаг перед написанием документации — это избавление от устаревшей информации. Перечитайте всё, что собрали, и удалите неактуальные статьи, разделы и предложения. 

Под «избавлением» имеется в виду одно из двух:

• добавление в архив — предпочтительно;

• безвозвратное удаление.

Если после этого вообще ничего не осталось, это нормально.

Если вы детально не знаете начинку описываемой технологии

После такой «чистки» обычно очень легко дышится — будто камень с шеи снял.

---

Шаг 3. Найдите частые вопросы и сценарии

Наша новая задача — определить, что нужно задокументировать или актуализировать в первую очередь. Обычно это выясняется так:

1. Вы перечитываете все вопросы в чате за последний месяц, выписываете их на отдельную страницу (не удаляйте её) и считаете их количество. 

2. Читаете комментарии с вопросами под инструкциями, если есть.

3. Опрашиваете аудиторию. Обычно это либо пост в публичном чате, либо вопросы знакомому коллеге лично. Формы с опросами, как правило, неэффективны, поскольку собирают мало ответов.

4. Продумываете популярные сценарии с командой, ведь лучше вас продукт никто не знает.

Вначале выпишите вопросы и сценарии, а потом начинайте писать для них тексты.

Если вашей разработкой пока никто не пользовался, будьте готовы собрать обратную связь после релиза и дописать то, что было неясно.

---

Шаг 4. Поделите на разделы

Цель — наметить примерный план будущей базы знаний. Он может дополняться, когда появятся новые данные, но пока нужно сделать «скелет» для всего остального. 

Структура нужна, чтобы пользователю было понятно, в каком разделе искать нужную информацию. Это особенно актуально, если в вашей документации много страниц.

Добавить их все сплошным списком вразнобой — провальный вариант. Ctrl+F тут тоже не всегда поможет, потому что, например, вы пишете в названии страницы «кубер», а ваш читатель ищет «Kubernetes» или «k8s», ничего не находит — и идёт к вам в личку.

Целевая аудитория

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

Подумайте, какие люди будут её читать. Например:

• только ваша команда;

• другие команды, им нужна одна функциональность;

• другие команды, им нужна разная функциональность;

• и ваша команда, и другие команды.

Внешние команды не должны видеть странички «Черновик to do», «[убрать в архив] 2 декабря». Держите их в отдельной папке для черновиков.

Например, если ваша аудитория — продуктовые разработчики и команда мониторинга критичных сервисов, которые ищут в документации абсолютно разные вещи, разделите её соответствующим образом.

---

Шаг 5. Составьте словарь терминов

Одна сущность — один термин.

Договоритесь с командой, как вы что будете называть. Иногда один и тот же термин в разных компаниях используют по-разному, и это путает людей.

Термины должны легко находиться через Ctrl+F.

Если у вас в команде есть авторские разработки, названия которых придумали вы сами, заведите словарь терминов с пояснениями. Это особенно актуально, если статей много и неудобно в каждую добавлять расшифровки. Людям будет в разы проще вникнуть в вашу разработку: оставляете везде ссылку на словарь и радуетесь жизни.

---

Шаг 6. Утвердите правила для команды

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

• нет структуры — статьи добавляют куда попало;

• никто не убирает устаревшую информацию;

• команда не всегда знает, что у неё есть в документации;

• много заброшенных статей;

• много пустых статей из 2016 с пометкой «to do»;

• перемешаны внутренние черновики и внешняя документация;

• нет архива;

• ведётся на русском, английском, латинском и древнегреческом.

Донесите до команды, что документация — это ваш общий продукт и от её качества зависит эффективность: ваша и других команд.

Пример правил по созданию новых страниц:

Советую почитать о методике совместного ведения документации.

---

Шаг 7. Напишите тексты

Лучший способ научиться писать хорошие инструкции — это отдавать их на вычитку. Желательно — редактору. Если его нет — любому коллеге. Я не о проверке пунктуации, а о том, понятно ли написана статья, полная ли в ней информация.

Некоторые советы могут показаться сложными, но в них описаны базовые вещи.

• Освойте инструменты форматирования там, где вы ведёте документацию. Примеры: макросы Confluence, синтаксис Markdown и HTML.

  

• Укажите, для кого страница и что в ней описано, — тогда человек сразу поймёт, нужно ли ему это читать.

• Не пишите сплошные тексты — делите их на логические абзацы и разделы. При грамотной вёрстке легче сходу найти ответ.

• Добавляйте оглавление. Его цель — дать читателю возможность быстро понять, в какую часть текста ему нужно переместиться. Если оно получилось на сто пунктов, сократите его или разбейте статью на несколько.

• Оформите разводящую страницу. Это главная страница с основной информацией и разделами по темам. Она нужна, чтобы читатель быстро понял, где искать необходимую инструкцию.
  Пример Ozon Docs
  Пример Yandex Cloud
  Пример Amazon EC2

• Соблюдайте форматирование — не пишите весь текст в заголовке или жирным шрифтом, не создавайте таблицу в таблице, не убирайте весь текст под каты.

• Добавляйте ссылки на другие инструкции и сервисы, если они упоминаются в тексте. Это сильно экономит время читателей. Может, они найдут устаревший дубль из шага 1.

• Избегайте канцеляризмов — они утяжеляют тексты: «для того чтобы в данном процессе осуществить определённую функциональность».

• Выделяйте в тексте важное, но не превращайте его в одни сплошные плашки.

• Укажите контакты команды, чтобы читатели знали, к кому обращаться.

---

Шаг 8. Добавьте FAQ

FAQ — страница с часто задаваемыми вопросами и ответами на них. 

Многие технические писатели считают наличие FAQ признаком плохой структуры документации. Я же советую добавить эту страницу, потому что она может спасти ситуацию, если у вас не очень удачная разводящая страница.

Используйте список из шага 3, если он есть.

FAQ — это не полноценная инструкция. Не дублируйте тексты и не делайте ответы очень подробными. 

Оптимальный вариант — краткий ответ со ссылкой на полную инструкцию. Например, «Да, это возможно. Подробнее в статье “Как создать N”».

Для продвинутых идеалистов:

Вопросы можно сгруппировать по темам — так их будет проще найти. Такие страницы FAQ обычно очень нравятся разработчикам, но это не принципиально, потому что обычно вопросы ищут с помощью Ctrl+F.

---

Шаг 9. Продумайте, как вашу документацию будут находить

Чтобы ваши труды не пропали даром, вашу документацию должно быть легко найти. 

Подумайте, куда ваши коллеги чаще обращаются за помощью:

• к вам в личку: закрепите ссылку на документацию у себя в профиле на корпоративном портале;

• в ваш чат: закрепите ссылку в шапке, закреплённом сообщении, сделайте так, чтобы каждому вступившему ссылку отправлял бот;

• в поиск Confluence: удалите устаревшую информацию, если ещё этого не сделали, чтобы она не всплывала, понятно называйте статьи.

Уведомите аудиторию, что у вас появилась документация, вы за ней следите и обращаться нужно именно туда. 

---

Шаг 10. Проанализируйте результат

Лучший источник для анализа — ваша аудитория. 

Есть несколько способов понять, решает ли проблемы ваша документация.

Что обычно делаю я:

• Считаю количество запросов в чатах. 

• Провожу мини-исследование среди читателей: готовлю открытые вопросы, спрашиваю, долго ли они искали информацию, что именно они искали, нашли ли ответы на свои вопросы.

• Изучаю статистику просмотров в Confluence и Grafana: если за месяц никто не обратился к документации, нужна ли она?

Сама не практикую, но отличная идея:

• Добавить фичу «Оцените статью». Такие макросы точно есть в Confluence.

Если на этом этапе не всё гладко — это нормально, просто будьте готовы что-то дописать, поменять местонахождение статьи.

---

Итог

Наверное, достаточно информации за раз. Посоветуйтесь с командой, решите, нужна ли вам документация, есть ли ресурсы для её разработки и поддержки.

И помните, что документация — ваш общий продукт. 

Буду рада ответить на ваши вопросы. Делитесь мнением и историями в комментариях.

«Шифрование
данных»

Программа

Руководство программиста

643.02069436.41NNN—01
33 01-1

Листов 6

---

АННОТАЦИЯ

Приводится руководство
программиста программы «Шифрование
данных».

Программа предназначена
для шифрования и дешифрования данных,
с применением алгоритма шифрования
«Шифр-Гост 28147-89».

Ограничения программы: программа
аварийно завершается при загрузке
файлов с размером более 500 МБ.

Условия эксплуатации программы:

возможность применения в локальной
сети;

на персональных компьютерах
с процессором не ниже 300МГц, минимум
оперативной памяти 16 MБ и операционная
система не ниже Windows 95.

Распространяется на дискетах.

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

---

СОДЕРЖАНИЕ

стр.

---

1 Назначение и условия применения
программы

1.1 Назначение программы

Описываемая программа предназначена
для шифрования и дешифрования
данных, хранящихся в файлах.

1.2 Функции программы

• Функция
  открытия и чтения файла “LoadFile”
  вызывается путем нажатия
  Файл->Открыть и
  загрузка данных из файла при выборе
  файла в диалоговом окне.
  

• При нажатии Шифрование->Зашифровать
  программа вызывает процедуру “Coding”,
  которая зашифровывает данные и выводит
  результат в окно для ввода текста.

• При выборе в меню
  Шифрование->Расшифровать
  – программа вызывает процедуру
  “Recoding”,
  которая расшифровывает данные с выводом
  в результата в текстовое окно.

• Запись данных в файл
  происходит путем нажатия Файл->Сохранить
  — вызове функции
  “SaveFile”и
  выборе в диалоговом окне документа для
  записи данных.

1.3 Использование оперативной памяти

Количество необходимой оперативной
памяти определяется размером обрабатываемых
данных, плюс к этому 1 МБ для загрузки
самой программы и создания всех
необходимых переменных и структур.

1.4 Требования к программному обеспечению

Операционная система Windows95
и выше.

2.1 Средства проверки правильности
выполнения программы

Правильность работы программы можно
проверить только лишь экспериментально.
Наилучший способ, моделирование реальной
работы, с контролем полученных результатов.

2.2 Функционирование программы после
сбоев

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

3.1 Способы вызова программы с различных
носителей данных

Программа может вызываться с любых
носителей.

3.2 Входные точки в программу

Исполняемым файлом программы является
файл «CodingGost.exe«.

3.3 Способы передачи управления и
параметров данных

Передача параметров производится в
режиме диалога программы с пользователем.

3.4 Обращение к программе – приложению

С помощью программ файл — менеджеров
зайти в каталог, в который установлена
программа и запустить файл «CodingGost.exe».

4.1 Формат, характер и организация входных
данных

Загрузка данных в виде текста или файла
любого формата для (рас)зашифровывания.

4.2 Формат, характер и организация выходных
данных

Cохранение (рас)зашифрованных
данных в файл любого формата, либо
простым отражением в текстовом поле.

5.1 Сообщения программисту и действия
по ним

№ п/п	Сообщение	Описание	Действия
1	2	3	4
1.	“Отсутствуют данные для обработки!”	Системное окно сообщения с информацией, о том, что файл не открыт.	Загрузить файл.
2.	“Не задан ключ!”	Системное окно сообщения с информацией, о том, что ключ не задан.	Ввести ключ для шифрования в соответствующее поле.

---

6.1 Примеры

Производится
открытие файлов путем
нажатия Файл->Открыть и
загрузка данных из файла при выборе
файла в диалоговом окне.

Возможен ввод текста для шифрования в
окно и его загрузка из него.

При нажатии Шифрование->Зашифровать
программа зашифровывает данные и выводит
результат в окно для ввода текста.

При выборе в меню Шифрование->Расшифровать
– происходит расшифровка данных с
выводом в результата в текстовое окно.

Запись данных в файл происходит путем
нажатия Файл->Сохранить и выборе
в диалоговом окне документа для записи
данных.

Можно изменить параметры шифрования –
ключ шифрования, “S
— блоки”.

6.2 Иллюстрации

Основная форма

Окно ввода
(отображения) Ключ Окно
вывода (отображения)

Главное меню
Строка состояния
процесса

---

Документ оформляется в соответствии с правилами предусмотренными ГОСТ 19.105, ГОСТ 19.106 и другими стандартами Единой системы программной документации (ЕСПД).

Введение стандартов в процесс создания программного изделия направлено на достижение следующих результатов:

— упрощение процесса разработки программы, а значит, и улучшение таких показателей, как надежность и стоимость.

— облегчение чтения и понимания программ сторонними лицами, что ведет к снижению числа ошибок, упрощает использование и эксплуатацию, документированностъ, мобильность и т.д.

Производство программ регулируется Единой системой программной документации (ЕСПД). В стандартах ЕСПД установлены требования, регламентирующие разработку, производство, тиражирование, сопровождение программ, что обеспечивает возможность:

а) унификации программных изделий для взаимообмена программами и применения ранее созданных программ в новых разработках;

б) снижение трудоемкости и повышения эффективности разработки, сопровождения, изготовления и эксплуатации программных изделий;

в) автоматизации изготовления и хранения программной документации.

В данном дипломном проекте разрабатывались три вида документов -«Программа и методика испытаний» и два эксплуатационных документа — «Руководство программиста» и «Руководство оператора».

Документы могут разрабатываться как на весь комплекс, так и на отдельные модули. В данном дипломном проекте программная документация разрабатывалась на весь комплекс.

Хотя ЕСПД предусматривает разработку порядка и методики испытания на стадии «Рабочий проект», работа по подготовке и проведению

испытаний фактически начинается уже на стадии «Техническое задание», когда намечается порядок контроля и приемки, и ее целесообразно вести в течение всего процесса проектирования программы.

Эксплуатационные документы разрабатывались на стадии разработки программы.

Руководство программиста

Документ «Руководство программиста» разрабатывается в соответствии с ГОСТ 19.504-79.

Руководство программиста должно содержать следующие разделы:

· назначение и условия применения программы;

· характеристики программы;

· обращение к программе;

· входные и выходные данные;

· сообщения.

В разделе «Назначение и условия применения программы» должны быть указаны назначение и функции, выполняемые программой, условия, необходимые для выполнения программы (объем оперативной памяти, требования к составу и параметрам периферийных устройств, требования к программному обеспечению и т. п.).

В разделе «Характеристики программы» должно быть приведено описание основных характеристик и особенностей программы (временные характеристики, режим работы, средства контроля правильности выполнения и самовосстанавливаемости программы и т.д.).

В разделе «Обращение к программе» должно быть приведено описание процедур вызова программы (способы передачи управления и параметров данных и др.),

В разделе «Входные и выходные данные» должно быть приведено описание организации используемой входной и выходной информации и, при необходимости, ее кодирования.

В разделе «Сообщения» должны быть указаны тексты сообщений, выдаваемых программисту или оператору в ходе выполнения программы, описание их содержания и действия, которые необходимо предпринять по этим сообщениям.

Документ «Руководство программиста» приведен ниже.

Руководство программиста

1. Назначение и условия применения программы

Программа предназначена для имитационного моделирования процессов или объектов описанных в задании лабораторных работ по дисциплине «Компьютерное моделирование».

Для запуска данной программы необходимы следующие условия:

Минимальный состав программных средств:

· операционная система Windows XP/Vista/7;

· среда программирования GPSS World Student Version 5.2.2.

Минимальный состав аппаратных средств:

· персональный компьютер на базе процессора с частотой не менее 1 ГГц;

· ОЗУ не менее 256 Мб;

· 10 Мб свободного места на жёстком диске;

· видеокарта и монитор, поддерживающие разрешение 800Ч600 или выше;

· клавиатура, мышь.

2. Характеристики программы

Программное обеспечение создано с помощью среды программирования GPSS World Student Version 5.2.2, языка моделирования GPSS World и предназначено для работы под управлением операционной системы Windows XP/Vista/7.

3. Обращение к программе

Для запуска приложения необходимо в меню установленных программ выбрать GPSS World Student Version.

После запуска приложения из строки меню выбрать File->New, из открывшегося списка выбрать Model и нажать Ok, при этом создастся новая модель и откроется поле ввода текста программы «Untitled Model 1.gps» (рис. 24).

Рисунок 24. Поле ввода текста программы

В этом окне необходимо написать код программы соответствующий заранее разработанному алгоритму. Для создания выполняемой модели необходимо из строки меню выбрать Command->Create Simulation, после этого если нет ошибок то сформируется журнал «Untitled Model 1.1.sim»(рис. 25).

Рисунок 25. Журнал

Если же в программе найдены ошибки, то они отображаются в данном журнале.

Для запуска программы необходимо из строки меню выбрать Command->START, в открывшемся диалоговом окне Start Command команде START задаются аргументы, после нажатия на Ok происходит выполнение программы и формирование отчета «Untitled Model 1.1.1.gpr»(рис. 26).

Рисунок 26. Отчет

4. Входные и выходные данные

Входные и выходные данные используют:

1) окно ввода текста программы;

2) окно выдачи сообщений (журнал);

3) окно отчета работы программы;

4) окно сохранения;

5) окна открытия;

1) Входными данными являются текст программы написанный на языке GPSS World. Выходные данные — результаты проверки данного текста на ошибки и результаты его выполнения.

2) Входными данными являются результаты проверки текста введенной программы на ошибки. Выходные данные — найденные ошибки с номерами строк и их описанием, или сообщение об удачной проверке и отсутствию ошибок.

3) Входными данными являются результаты выполнения текста программы. Выходные данные — полный отчет о моделировании данной системы сгенерированный стандартными операторами языка.

4) Входными данными являются текст программы, журнал сообщений или отчет работы программы. Выходные данные — тестовый файл с заданным именем и соответствующим расширением.

5) Входными данными являются тестовый файл с заданным именем и соответствующим расширением сохраненный ранее. Выходные данные — текст программы, журнал сообщений или отчет работы программы.

5. Сообщения программисту

Специальных сообщений программисту в программе не предусмотрено. Возможны только сообщения операционной системы о поврежденных или некорректных файлах.