Инструкция программисту по работе с программным продуктом

УФИМСКИЙ ГОСУДАРСТВЕННЫЙ
АВИАЦИОННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

КАФЕДРА ВЫЧИСЛИТЕЛЬНОЙ
МАТЕМАТИКИ И КИБЕРНЕТИКИ

Прикладное
программное обеспечение для учета
заявок и контроля их исполнения на
примере ООО «Интегрированная транспортная
сеть».

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

Листов
14

УФА
2013

  1. Аннотация

Приводится
руководство программиста программного
обеспечения для учета заявок и контроля
их исполнения на примере ООО «Интегрированная
транспортная сеть».

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

В
руководстве программиста рассматриваются
назначение, характеристики, условия,
необходимые для выполнения программы

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

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

  1. 2. Условия, необходимые для выполнения программы

Для
работы программного продукта необходима
следующая программно-аппаратная
конфигурация:

  • Windows
    7,Windows Server 2003 Service Pack 2,Windows Server 2008,Windows
    Server 2008 R2,Windows Vista, Windows Vista Service Pack 1,Windows
    XP Service Pack 2,Windows XP Service Pack 3;

  • 32-разрядные
    системы: компьютер, оборудованный
    процессором Intel
    или совместимым процессором с тактовой
    частотой 1 ГГц или выше (рекомендуется
    2 ГГц или выше, поддерживается только
    один процессор);

  • 64-разрядные
    системы: процессор с тактовой частотой
    1,4 ГГц или выше (рекомендуется 2 ГГц или
    выше, поддерживается только один
    процессор);

  • минимальный
    объем ОЗУ 512 МБ (рекомендуется 1 ГБ или
    более);

  • 1
    ГБ свободного места на диске;

  • наличие
    СУБД:
    MS SQL
    2008;

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

  2. 3.1.
    Режим работы программы

Диалоговый.
Web-интерфейс
в браузере (с поддержкой HTML5).

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

Проверка
правильности работы программы
осуществляется при выполнении конкретных
примеров. Программа
выдает сообщение при вводе некорректных
данных (Рис. 2.20):

Рис. 2.20.
Некорректный ввод номера телефона

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

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

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

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

  • Запустить
    программу на ПК, с поддержкой Microsoft
    .NET
    Framework
    (или на удаленном сервере), если он еще
    не запущен;

  • Откройте
    ваш любимый браузер (на пример chrome,
    internet
    explorer,
    mozilla
    firefox);

  • Введите
    в адресную строку IP-адрес
    сервера, с заранее определенным портом;

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

  • Начать
    работу
    с клиентами.

Не
авторизованный (не зарегистрированный)
пользователь не может просматривать
какую либо вкладку.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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


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


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

Время на прочтение
8 мин

Количество просмотров 14K

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

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

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

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

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

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

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

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

Это гусь Гоша и его постоянно отвлекают техническими вопросами

Это гусь Гоша и его постоянно отвлекают техническими вопросами

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

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

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

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

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

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

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

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

Да и, согласитесь, вам просто приятно читать документацию, в которой всё понятно описано и легко искать информацию. Если у вас есть примеры, делитесь в комментариях.


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

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

Результаты:

  • 5 баллов: у вас хорошая документация, автор вами гордится!

  • 0–4 балла: есть что доработать — переходите к практическим шагам.

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

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

Удачно: позвать на встречу или созвон эксперта из команды (обычно это тимлид или старший разработчик) и вычитать с ним весь материал полностью, не поверхностно.

Неудачно: скинуть материал эксперту и попросить его самого удалить лишнее.

Если плохо выполнить этот шаг, вы потратите много времени зря в будущем. Проверено мной.

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

Неудачные варианты

Удачные варианты

«Пушка», «долбилка» и «стрелялка»;
Почему: кажется, что это разные термины, возникает путаница. Не найдётся по Ctrl+F.

«Пушка»

Почему: все коллеги в Ozon знают этот термин.

«СronJob’ы», «кроны» и «джобы»;
Почему: неясно, составляющие это друг друга или одно и то же. Не найдётся по Ctrl+F.

«CronJob»

Почему: все коллеги знают этот термин, он цельный.

«Фэктори» и «фабрика», «эккаунт» и «аккаунт», «экшен» и «действие»
Почему: будьте осторожны с англицизмами. Не используйте их, если есть подходящий термин на русском языке. Не найдётся по Ctrl+F.

«Фабрика», «аккаунт» и «действие»

Почему: популярные, понятные всем термины на русском языке.

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


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

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

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

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

Если не договориться «на берегу», документация всегда превращается в хаос:

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

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

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

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

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

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

  • нет архива;

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

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

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

  1. Черновик статьи создавайте в папке для черновиков.

  2. Не добавляйте статью в список публичных, пока не допишете.

  3. Чтобы перенести статью в список публичных:

  • отправьте её в чат команды;

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

  • решите с командой, в какой раздел её перенести.

  1. Статью можно переносить.

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


Шаг 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
3
3 01-1

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

Программа

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

643.02069436.41NNN01
33 01-1

Листов 6


АННОТАЦИЯ

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

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

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

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

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

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

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

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


СОДЕРЖАНИЕ

стр.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5 Сообщения 5

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

6 Дополнительные материалы 5

6.1 Примеры 5

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

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

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

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


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 Иллюстрации

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

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

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


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

Пример руководства программиста по одной из ранее сданных систем

СИСТЕМА УПРАВЛЕНИЯ ДЛЯ УЧАСТКА СБОРКИ И НАСТРОЙКИ ДВДТ

АННОТАЦИЯ

В данном руководстве содержится информация, описывающая прикладное программное обеспечение для участка сборки и настройки ДВДТ – участок ДВДТ (далее по тексту – участок). Документ содержит информацию о доступе к функциям системы управления MasterScada (далее по тексту – СУ), структуре программы, методики записи и просмотра произошедших событий.

СОДЕРЖАНИЕ

1             НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ ПРОГРАММЫ           5

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

1.2          Аппаратные средства  6

2             ХАРАКТЕРИСТИКА ПРОГРАММЫ          7

2.1          Структура SQL базы данных    7

2.2          Программные секции 10

2.3          Структура программного обеспечения            14

3             ОБРАЩЕНИЕ К ПРОГРАММЕ   16

4             ВХОДНЫЕ И ВЫХОДНЫЕ ДАННЫЕ        16

5             СООБЩЕНИЯ    17

ПЕРЕЧЕНЬ ТЕРМИНОВ И ОПРЕДЕЛЕНИЙ           18

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ          19

ПЕРЕЧЕНЬ РИСУНКОВ 20

ПЕРЕЧЕНЬ ТАБЛИЦ       21

ПЕРЕЧЕНЬ ССЫЛОЧНЫХ ДОКУМЕНТОВ              22

ЛИСТ РЕГИСТРАЦИИ ИЗМЕНЕНИЙ       23

1             НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ ПРОГРАММЫ

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

Стенд предназначен для испытаний определённого вида оборудования на разных участках. ПО обеспечивает настройку на следующих участках:

— настройка температуры;

— настройки давления;

— настройки скорости ветра;

— настройки влажности;

— настройки ДВДТ;

— сдачи ПСИ.

ПО реализует следующие функции:

— получение и обработка сигналов ввода-вывода с корзины ввода-вывода;

— приём и фильтрация входных дискретных сигналов от вероятного «дребезга» контактов;

— приём и обработка входных аналоговых сигналов;

— контроль выхода сигнала за допустимые границы (недостоверность сигнала);

— масштабирование аналогового сигнала;

— генерация пороговых нарушений с функцией гистерезиса;

— выдача дискретных команд на оборудование (управляющие воздействия);

— реализация алгоритмов управления системой;

— реализация алгоритмов защит;

— обмен данными со смежными системами по протоколу Modbus TCP;

— диагностика модулей контроллера на наличие ошибок, и формирование сообщений для АРМ о состоянии оборудования контроллера;

— мониторинг аварийных ситуаций оборудования системы.

ПО реализует следующие функции:

— вывод на экран видеокадра текущего состояния участка;

— отображение состояний оборудования;

— управление механизмами установки;

— ведение архива собранных событий;

— отображение аварийных ситуаций;

— ведение хронологии аварийных событий.

1.2          Аппаратные средства

В состав технических средств системы входят следующие аппаратные и программные компоненты:

— Электронный модуль давления Метран-518 предназначен для точного измерения и непрерывного преобразования значений абсолютного и избыточного давления, разрежения, давления-разрежения при поверке и калибровке различных приборов давления;

— Камера ТБК-500;

— Контроллеры PACE5000 и РАСЕ1000;

— Мультиметр Метран-514МПП

Персональный компьютер ПЭВМ

— процессор не хуже Intel i7 2,7 ГГц

— слоты расширения на материнской плате, не менее: 5 слотов 1x PCI-E 2.0, 1 слот 16x PCI-E 3.0

— память не менее 16 Гб DDR4-2133/2400

— дисковая подсистема: корзина на 2 диска, 2,5” SSD не менее 240GB (для системы и программ), 3.5” HDD SATA не менее 1 Tb (для данных);

— оптический привод DVD±RW в комплекте;

— порты: 4 x USB 3.0; 6 x USB 2.0, VGA, DVI, 1x LAN (RJ-45, Ethernet 10/100/1000), 4x RS232, 4x CAN 2.0

— блок питания, не менее 600 Вт;

— рабочая температура от +5º до +40ºС (промышленное исполнение);

— поддержка работы с двумя мониторами одновременно.

Установлено лицензионное ПО: Microsoft Windows Server 2012,

В слоты расширения ПК установлены и подключены интерфейсные платы RS 232 CAN; соединители плат должны выведены на заднюю панель ПК

В состав ПК входит: системный блок, монитор 24-27” со входами DVI и VGA, клавиатура, манипулятор «мышь»

Дополнительно: коммутатор Ethernet.

2             ХАРАКТЕРИСТИКА ПРОГРАММЫ

2.1          Структура SQL базы данных

Потребность в СУРБД Microsoft SQL Server у пользователей ПО MasterScada может возникнуть только в тех случаях, когда предполагается использовать оперативные журналы или SQL базу данных телеметрии.

SQL база данных состоит из таблиц. Поля БД — это столбцы таблицы, а записи БД — это строки таблицы. Каждая БД изначально содержит таблицы:

— CONFORMS

— CORETABLE

— EQUIPMENT

— HISTORY

— MAGS

— NEXTNUMS

— PERSONS

— REFS

— SQLTOKENS

— USERFORMS.

Таблица CORETABLE состоит из наиболее распространенных полей, которые характерны почти для любого оперативного журнала:

— RECID                 — уникальный идентификатор записи;

— FULLPATH        — принадлежность записи конкретному журналу (путь в дереве журналов);

— DATACREATE — дата/время создания записи;

— DATE1, DATE2                — вспомогательные даты/времени общего назначения (например, обнаружения и устранения дефекта);

— OBJECT              — оборудование, к которому относится запись;

— COMMENT      — произвольный комментарий (например, описание дефекта);

— STATE                — состояние записи (например, обнаружен/устранен).

Каждая запись имеет свой жизненный цикл, который ведется в таблице HISTORY. Там фиксируются факты создания записи (кто, когда создал, редактировал, подписывал или отзывал подпись).

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

Рисунок 1 – Модель данных БД. Связи по внешнему ключу

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

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

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

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

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

Любое поле журнала, относящееся к целому типу, может быть привязано к справочнику, т.е. таблице, в которой числу сопоставлена его текстовая расшифровка. В каждой записи БД присутствует поле STATE, к которому обязательно должен быть привязан справочник состояния записи.

Кроме обычных справочников, предусмотрен специальный вид справочника — справочник оборудования. Этот справочник представляет собой иерархическую структуру и отображается в виде дерева. Такой подход связан с тем, что одинаковое оборудование может располагаться на разных объектах. В данном справочнике предусмотрено хранение кодов оборудования согласно требованиям ОДУ. Справочник оборудования может быть привязан только к полю строкового типа.

Для каждого журнала могут быть созданы формы просмотра списком нескольких записей, просмотра/редактирования одной записи и печатных документов (отчет). Форма редактирования должна представлять собою максимально детализированное представление записи, именно с ее помощью (и только через нее) осуществляется редактирование записи. В случае если на данном уровне дерева какая-либо из форм не задана, берется форма из вышестоящего уровня. Все указанные формы обязательно должны быть созданы для всех журналов первого уровня! Формы и отчеты создаются в конфигураторе БД при помощи дизайнера форм и дизайнера отчетов.

2.2          Программные секции

Приложение содержит:

— конфигурацию аппаратных и программных средств;

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

— набор функциональных блоков, разработанных в рамках проекта KPC;

— базу данных переменных контроллера;

— анимационные таблицы.

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

Таблица 2.1 – Программные секции

Внутри секций используются следующие подпрограммы (функциональные блоки), которые приведены в таблице 2.2.

Таблица 2.2 – Функциональные блоки

Параметры сигналов блоков приведены в таблице 2.3.

Таблица 2.3 – Параметры сигналов блока

Разъём                Контакт               Наименование               Параметры

X1           1             I вх.       Токовый вход датчика температуры. I вх. не более 400 мкА.

                2                             Пустой вывод. Не использовать.

                3                             Пустой вывод. Не использовать.

                4             +12В      Выход напряжения питания датчика температуры 12±0,25 В относительно «Общ.12В» Ток нагрузки не более 400 мкА.

X3           1             +12В      Выход напряжения питания +12±0,25 В относительно «Общ.12В» Ток нагрузки не более 400 мкА.

                2             +7В        Выход напряжения питания +7±0,25 В относительно «Общ.» Ток нагрузки не более 300 мА.

                3             -7В         Выход напряжения питания -7±0,25 В относительно «Общ.» Ток нагрузки не более 50 мА.

                4             Общ.     Нулевой потенциал блока.

                5             Общ.     Нулевой потенциал блока.

                6             Общ.     Нулевой потенциал блока.

                7             CAN_L Линия цифровой сети передачи данных CAN-L. Параметры согласно ISO11898

                8             CAN_H Линия цифровой сети передачи данных CAN-Н. Параметры согласно ISO11898

X2           1             GND      Нулевой потенциал блока.

                2             RESET    Сигнал интерфейса JTAG.

                3             TMS       Сигнал интерфейса JTAG.

                4             TCK        Сигнал интерфейса JTAG.

                5             TDI         Сигнал интерфейса JTAG.

                6             TRST      Сигнал интерфейса JTAG.

                7                            

                8             3,3В       Напряжение питания 3,3В. Ток нагрузки не более 10 мА.

2.3          Структура программного обеспечения

Структура ПО представлена на рисунке 2.

Рисунок 2 – Структура ПО

Приложение содержит:

— таблицы настроечных параметров системных функций панели;

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

— перечень видеокадров системы;

— перечень всплывающих окон в системе

— базу данных переменных тэгов панели.

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

Таблица 2.4 – Перечень скриптов

3             ОБРАЩЕНИЕ К ПРОГРАММЕ

Программа при работе на объекте сконфигурирована на автоматический запуск при включении стенда. Состояние программного обеспечения отображается на экране монитора и светодиодных индикаторах приборов стенда.

Настройка параметров прикладного программного обеспечения операторской панели настраивается с ПК.

При этом настраиваются:

— таймеры нарушений работы стенда;

— уставки времени дискретных выходных сигналов;

— шкала входного аналогового сигнала температуры;

— шкала входного аналогового сигнала давления;

— шкала входного аналогового сигнала влажности;

— шкала входного аналогового сигнала скорости ветра;

— время цикла приложения;

— IP и Modbus адреса приборов стенда.

4             ВХОДНЫЕ И ВЫХОДНЫЕ ДАННЫЕ

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

Выходными данными системы является информация, передаваемая на объект управления (стенд) из ПК через устройство связи с объектом. Информация выводится в АРМ оператора в виде экранных форм.

5             СООБЩЕНИЯ

Сообщения, передаваемые по интерфейсу АРМ-стенд, приведены в таблице 5.1.

Таблица 5.1 – Перечень событий, выводимых в журнале событий

№ п/п Наименования события

1             Выбрана вкладка блока №1

2             Выбрана вкладка блока №2

3             Выбрана вкладка блока №3

4             Выбрана вкладка блока №4

5             Индикатор питание +7 В

6             Индикатор питание -7 В

7             Индикатор питание +12 В

8             ПК подключен к стенду

9             Нажата кнопка включения блока №1

10           Нажата кнопка включения блока №2

11           Нажата кнопка включения блока №3

12           Нажата кнопка включения блока №4

13           Индикатор включения блока №1

14           Индикатор включения блока №2

15           Индикатор включения блока №3

16           Индикатор включения блока №4

17           Нажата кнопка включения камеры

18           Индикатор включения камеры

19           Резерв

20           Повышенное напряжение между фазами

21           Индикатор отключения камеры

22           Команда на включение камеры

23           Команда на задание скорости ветра

24           Команда на отключение блока №1

25           Команда на отключение блока №2

26           Команда на отключение блока №3

27           Команда на отключение блока №4

ПЕРЕЧЕНЬ ТЕРМИНОВ И ОПРЕДЕЛЕНИЙ

Автоматизированная система (АС) – система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.

База данных (БД) – представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины (ЭВМ).

Система управления базами данных (СУБД) – совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием БД.

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

Прикладная программа – Программа, предназначенная для решения задачи или класса задач в определенной области применения системы обработки информации.

MasterScada – программный пакет для проектирования систем диспетчерского управления и сбора данных (Scada).

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

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ

SCADA (Supervisory Control and Data Acquisition System) – система диспетчерского управления и сбора данных

АС          – автоматизированная система;

БД          – база данных;

ПК          – персональный компьютер;

ПО         – программное обеспечение;

СУ          – система управления;

СУБД    – система управления базами данных.

ПЕРЕЧЕНЬ РИСУНКОВ

Рисунок 1 – Модель данных БД. Связи по внешнему ключу 8

Рисунок 2 – Структура ПО         13

ПЕРЕЧЕНЬ ТАБЛИЦ

Таблица 2.1 – Программные секции   10

Таблица 2.2 – Функциональные блоки             12

Таблица 2.3 – Параметры сигналов блока       12

Таблица 2.4 – Перечень скриптов        15

Таблица 5.1 – Перечень событий, выводимых в журнале событий 17

ПЕРЕЧЕНЬ ССЫЛОЧНЫХ ДОКУМЕНТОВ

№ п/п Нормативный документ

1             ГОСТ 19781-90 ЕСПД. Термины и определения.

2             ГОСТ 19.105-78. ЕСПД. Общие требования к программным документам.

3             ГОСТ 19.402-78. ЕСПД. Описание программы.

4             ГОСТ 19.504-79. ЕСПД. Руководство программиста. Требования к содержанию и оформлению.

5             ГОСТ 19.701-90. ЕСПД. Схемы алгоритмов, программ, данных и систем. Обозначения условные и правила выполнения

ЛИСТ РЕГИСТРАЦИИ ИЗМЕНЕНИЙ

#Руководствопрограммиста, #описаниеПЛК, #ПТС, #интерфейс

Понравилась статья? Поделить с друзьями:
  • Инструкция пылесоса samsung 1800w twin
  • Инструкция режима труда и отдыха водителей дальнобойщиков
  • Инструкция программатор электроника 21 10 инструкция
  • Инструкция пульта шерхан логикар 4
  • Инструкция противопожарной безопасности на азс