вторник, 27 июня 2017 г.

ГОСТ 2 (ЕСКД) при разработке ИТ-документации

Цель статьи — определить, какие стандарты ГОСТ серии 2 могут использоваться при разработке ИТ-документации.

Для ИТ-решений существуют отдельные стандарты (ГОСТ 19, ГОСТ 34), но иногда возможно применение Единой системы конструкторской документации (ЕСКД). ЕСКД — это комплекс стандартов, устанавливающий взаимосвязанные правила, требования и нормы по разработке, оформлению и обращению конструкторской документации, разрабатываемой и применяемой на всех стадиях жизненного цикла изделия.

Изделие согласно ГОСТ 2.101-2016 — предмет или набор предметов производства, подлежащих изготовлению в организации (на предприятии) по конструкторской документации. Изделиями могут быть: устройства, средства, машины, агрегаты, аппараты, приспособления, оборудование, установки, инструменты, механизмы, системы и пр. В ГОСТ 2.001-2013 указано, что ЕСКД распространяется на изделия машиностроения и приборостроения, при этом область распространения отдельных стандартов может быть расширена, что должно быть оговорено во введении к ним. Грубо обобщая, можно сделать вывод, что под изделием мы вправе понимать и любое ИТ-решение как систему.

Несмотря на то, что в практике документирования ИТ-решений ЕСКД применяется в основном к документации на технические средства (компьютеры, периферийные устройства и т.п.), стандарты ГОСТ серии 2 из таблицы ниже, на наш взгляд, допустимо применять и при ИТ-документировании, т.е. документировании ИТ-решений.

Стандарт
Чем интересен стандарт
ГОСТ 2.051-2013 Электронные документы. Общие положения
Устанавливает общие требования к выполнению электронных конструкторских документов изделий всех отраслей промышленности. Раскрывается понятие интерактивного электронного документа.
ГОСТ 2.105-95 Общие требования к текстовым документам
Определяет требования к оформлению текстовых документов. В т.ч. в документе приведены инструкции по разработке титульного листа и листа утверждения. На стандарт также ведут ссылки из ГОСТ 34.602-89 (Техническое задание на создание автоматизированной системы).
ГОСТ 2.503-2013 Правила внесения изменений
Есть указания по структуре, расположению и правилам заполнения листа регистрации изменений.
ГОСТ 2.601-2013 Эксплуатационные документы
Устанавливает виды, комплектность и общие требования к выполнению эксплуатационных документов — конструкторских документов, которые отдельно или в совокупности с другими документами определяют правила эксплуатации изделия и/или отражают сведения, удостоверяющие гарантированные изготовителем значения основных параметров и характеристик (свойств) изделия, гарантии и сведения по его эксплуатации в течение установленного срока службы.
ГОСТ 2.610-2006 Правила выполнения ЭД
Стандарт устанавливает правила выполнения эксплуатационных документов из ГОСТ 2.601-2013, в т.ч. интерактивных электронных документов.
ГОСТ 2.711-82 Схемы деления изделия на составные части
Описывает правила выполнения схемы деления изделия на составные части (правила декомпозиции).
В следующих статьях проанализируем стандарты серии ГОСТ 19 и 34.
Спасибо за внимание.

P.S. Настоящая статья содержит личные выводы автора, основанные на результатах проведенного анализа. Если Вы не согласны с выводами автора — прокомментируйте статью. Вы можете использовать результаты анализа на свой страх и риск. При перепечатке статьи ссылка на первоисточник обязательна.

среда, 28 декабря 2016 г.

Безопасная работа с документами

Решил начать публикацию кратких статей-лайфхаков, которые постоянно использую в своей работе. Итак, лайфхак №1, который я назвал "Безопасная работа с документами".

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

    1. Перед началом работы с документом создаю артефакты:
    • Сам файл ворд-документа с именем, составленным по шаблону: "ГГГГ-ММ-ДД ТипДокумента. НазваниеДокумента.docx", где ГГГГ-ММ-ДД — текущая дата.
    • Rar-архив, дублирующий имя документа, но без указания даты. См. рисунок ниже.
    2. В течение текущего рабочего дня документ имеет назначенное имя.
    3. В следующий день работы над документом выполняю действия:
    • Текущий файл документа копирую в созданный rar-архив, в котором копится все то, что уже есть в документе. При необходимости архив можно будет удалить.
    • Корректирую название документа — ставлю текущую дату — и работаю уже с новой версией документа. Например, вчера работал с "2016-12-21 РП. АРМ Администратора ЛК.docx" — он уже в архиве, сегодня — с документом "2016-12-22 РП. АРМ Администратора ЛК.docx". Простая и надежная поддержка версионности. Если кто-то корректирует версию документа в течение рабочего дня — промежуточную версию обозначаю путем добавления в имя файла инициалов рецензента, например, "2016-12-22 РП. АРМ Администратора ЛК - АС.docx".
    Просто и удобно. Минимум путаницы, если постоянно следовать процессу и, что особо важно, внедрить его во взаимодействие с Заказчиком.

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

    пятница, 11 марта 2016 г.

    Разработка документации пользователя программного продукта (Ю.В. Кагарлицкий) — отзыв на книгу

    Как понятно рассказать пользователю о программном продукте? Эта тема мне давно интересна. С целью развития навыков изучил книгу Ю.В. Кагарлицкого "Разработка документации пользователя программного продукта (методика и стиль изложения)".

    В процессе чтения для себя отмечал важные факты, которые привожу ниже. Может быть, найдете для себя что-то новое и ценное.

    понедельник, 18 января 2016 г.

    Девпром: опыт внедрения процесса контроля качества

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

    пятница, 6 ноября 2015 г.

    О работе с требованиями и документами

    Наконец-то завершил написание статьи об опыте работы с требованиями и документами в системе управления проектами "Девпром" на примере одного проекта. Прочитать полностью статью вы сможете по ссылке ниже.

    четверг, 2 апреля 2015 г.

    Про планирование релизов

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

    Оригинал статьи доступен для просмотра и обсуждения по ссылке.

    вторник, 3 марта 2015 г.

    Atlassian Confluence в работе аналитика

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