Дневник it-аналитика

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

2017-06-27T14:02:00.000+04:00

Цель статьи — определить, какие стандарты ГОСТ серии 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. Настоящая статья содержит личные выводы автора, основанные на результатах проведенного анализа. Если Вы не согласны с выводами автора — прокомментируйте статью. Вы можете использовать результаты анализа на свой страх и риск. При перепечатке статьи ссылка на первоисточник обязательна.

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

2016-12-28T22:00:00.000+04:00

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

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

1. Перед началом работы с документом создаю артефакты:

Сам файл ворд-документа с именем, составленным по шаблону: "ГГГГ-ММ-ДД ТипДокумента. НазваниеДокумента.docx", где ГГГГ-ММ-ДД — текущая дата.
Rar-архив, дублирующий имя документа, но без указания даты. См. рисунок ниже.

2. В течение текущего рабочего дня документ имеет назначенное имя.

3. В следующий день работы над документом выполняю действия:

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

Корректирую название документа — ставлю текущую дату — и работаю уже с новой версией документа. Например, вчера работал с "2016-12-21 РП. АРМ Администратора ЛК.docx" — он уже в архиве, сегодня — с документом "2016-12-22 РП. АРМ Администратора ЛК.docx". Простая и надежная поддержка версионности. Если кто-то корректирует версию документа в течение рабочего дня — промежуточную версию обозначаю путем добавления в имя файла инициалов рецензента, например, "2016-12-22 РП. АРМ Администратора ЛК - АС.docx".

Просто и удобно. Минимум путаницы, если постоянно следовать процессу и, что особо важно, внедрить его во взаимодействие с Заказчиком.

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

Вопросы, замечания?

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

2016-03-11T15:08:00.000+04:00

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

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

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

2016-01-18T19:30:00.000+04:00

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

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

2015-11-06T14:55:00.000+04:00

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

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

2015-04-02T22:03:00.000+04:00

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

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

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

2015-03-03T09:18:00.000+04:00

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

Однако, возможности у системы действительно богатые.

Адаптация жизненного цикла пожеланий и задач под потребности команды

2015-02-24T19:24:00.000+04:00

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

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

Как правильно оформлять технические документы

2014-11-26T19:37:00.000+04:00

Хорошее руководство по оформлению документов в MS Word (и не только для тех, кто только начинает работать с документацией).

Организация работы с требованиями и документацией в TFS

2014-11-14T11:35:00.000+04:00

Пополняю свою коллекцию публикаций на тему организации работы с требованиями и проектной документацией интересной презентацией от Александра Шамрай.

Особенно выделю моменты с трассировками разделов документации на проектные артефакты.

Организация работы с требованиями и документацией в TFS from Александр Шамрай

Варианты использования (use cases) в документах ГОСТ 34

2013-10-04T15:21:00.000+04:00

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

Что же было интересного обнаружено в ходе разработки документации? А вот что. На стадии технического проекта формируется документ "Описание автоматизируемых функций". В нём есть раздел "3.2 Описание процесса выполнения функций". Как думаете, что могло бы быть помещено в него?

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

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

Если есть другие мысли на эту тему, готов их обсудить.

ЛАФ-2013: запись доклада

2013-09-10T21:32:00.000+04:00

Не так давно коллеги-организаторы фестиваля ЛАФ-2013 опубликовали видеозаписи докладов. Мой дебютный доклад на тему "Организация, учет и совместное использование проектной документации" можно посмотреть ниже.

ЛАФ-2013: Организация, учет и совместное использование проектной документации

2013-07-03T22:15:00.000+04:00

Опубликовал на сервисе slideshare презентацию своего доклада, с которым выступил на недавней конференции аналитиков ЛАФ-2013. Впечатлениями о конференции поделюсь позже.

Итоговая презентация и доклад сформированы на основе статей, написанных за 2012 год:

Статья "SharePoint Workspace для совместной работы с документами".
Статья "Как настроить совместную работу DEVPROM и SharePoint?".
Статья "Опыт организации процесса управления документацией на проекте".

О создании хранилища типовой документации

2013-06-19T19:18:00.000+04:00

На "Software People" размещена довольно-таки интересная статья, в которой изложены мысли по реализации хранилища типовой документации.

Авторы: Алексей Киселев, Екатерина Душечкина.

Связанная статья: "Опыт организации процесса управления документацией на проекте"

Отзыв на книгу "Требования для программного обеспечения: рекомендации по сбору и документированию" (Илья Корнипаев)

2013-06-13T20:33:00.001+04:00

Недавно коллеги привезли с конференции "Analyst Days 2013" новую книгу по требованиям от Ильи Корнипаева — "Требования для программного обеспечения: рекомендации по сбору и документированию". Несколько дней потребовалось, чтобы освоить материал.

Что сразу привлекло в книге — ее практическая направленность и довольно-таки сжатый объем (всего 118 страниц). Тем не менее, эти 118 страниц дают первоначальное представление о работе IT-аналитика в полной мере и могут начинающим специалистам в кратчайшие сроки определить имеющиеся и необходимые навыки, а также принять решение о целесообразности построения карьеры в области ИТ-анализа.

Что самое интересное, во введении сразу же приведены основные правила, которых стоит придерживаться во избежание ошибок:

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

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

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

Способ прототипирования в Excel с использованием VBA. Ранее я слышал о таком применении Excel, но не видел, и, тем более, не применял на практике (только прототипы в MS Visio). Теперь хочу изучить VBA и попробовать данный способ на одном из проектов.
Способ выбора представителя со стороны заинтересованных лиц. Это должен быть человек, обладающий и знаниями, и умениями, т.е. тот человек, которому руководство доверяет обучение новичков.
Главный вопрос аналитика — "Зачем?" (для связи требований от ЗЛ с их целями).

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

Считаю, что для входа в профессию ИТ-аналитика и принятия решения о целесообразности построения карьеры в области ИТ-анализа данная книга — то, что нужно. После неё можно читать уже и более объемную книгу "Путь аналитика" (Перерва, Иванова), а потом — все основные зарубежные аналитические книги (Карл Вигерс, Алистер Коберн, Дин Леффигуэлл и т.п.).

ЛАФ-2013: зарегистрировал свой доклад

2013-05-30T20:12:00.000+04:00

Вчера на сайте Летнего аналитического фестиваля (ЛАФ) зарегистрировал-таки заявку с темой "Организация, учет и совместное использование проектной документации". В 20-минутном докладе поделюсь своим опытом организации, учета и совместного использования проектной документации.

О чем хочу рассказать:

Где хранилась, как и кем разрабатывалась документация, каким образом осуществлялся обмен между проектной командой (без аналитика)?
Что изменилось после того, как в команду пришел аналитик?
Используемые приемы (примеры)
Используемые инструменты (примеры)
Совместная работа ресурса хранения документации и системы управления проектами (пример реализации)
Интересные наблюдения и предложения

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

Спасибо за внимание.

Трассировка: от определения проблемы к требованию

2013-05-24T22:27:00.000+04:00

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

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

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

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

Оптимизация работы с MS Word: вкладки Office Tabs

2013-05-20T21:38:00.000+04:00

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

Совсем недавно обнаружил одну полезную и, что самое интересное, бесплатную (для персонального и некоммерческого использования) программу Office Tabs, которая позволяет работать с открытыми документами Word как с вкладками браузера. Скачать программу можно по ссылке.

Из минусов — диалоговое окно, которое периодически появляется после установки приложения и предлагает приобрести платную версию.

SharePoint Workspace для совместной работы с документами

2013-02-21T21:37:00.001+04:00

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

Эта статья посвящена инструменту SharePoint Workspace для совместной работы с документами, расположенными на сайте SharePoint.

Условия использования инструмента:

Развернутый сайт SharePoint с установленной библиотекой документов.
Приложение Microsoft SharePoint Workspace, установленное на локальной машине.

Как было раньше. Ранее на сайте SharePoint хранились последние версии документов, а разработка осуществлялась на локальной машине в отдельных папках. Каждый раз приходилось сопоставлять документ, который находится на сервере, с документом, который хранится локально. Иногда возникала путаница. Если документ редактировался прямо с сервера SharePoint, приходилось выполнять поиск и извлечение через браузер, что было не всегда удобно. Кстати, были замечены трудности и при перемещении документа из одной папки в другую с помощью браузера, а также при отправке документа по e-mail.

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

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

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

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

Аналитик работает с документацией на сервере SharePoint (либо через браузер, либо через приложение SharePoint Workspace). Ссылку на рабочий документ отправляет на e-mail коллегам. Если создана история/задача в Devprom, отправляется и ссылка на эту задачу. SharePoint и Devprom интегрированы между собой посредством ссылок.

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

Простой и понятный интерфейс.
Возможность локальной работы с последующей синхронизацией с сервером SharePoint.
Возможность перетаскивания файла методом Drag&Drop как в SharePoint Workspace для синхронизации с сервером, так и из SharePoint Workspace для отправки, например, по e-mail.
Поиск на основе стандартного проводника Windows.
Функция "Копировать в виде ссылки". Например, вы можете копировать наименование файла в виде ссылки для отправки по e-mail.
Другие причины использования приложения: http://office.microsoft.com/ru-ru/sharepoint-workspace/HA101631747.aspx.

Тематические статьи:

Как настроить совместную работу DEVPROM и SharePoint?

2012-12-15T20:30:00.000+04:00

Предисловие. Как только я пришел в свой первый проект в роли аналитика (это было более двух лет назад), вся документация хранилась хаотично, а обмен производился путем почтовой пересылки файлов. Конечно, сразу же была поставлена вполне очевидная задача — организовать единое место хранения всей проектной документации и исключить любую пересылку doc-файлов через e-mail. Как наверное Вы помните, эта задача была решена с помощью узла SharePoint — об этом я писал в феврале текущего года.

Удобное использование документации с узла SharePoint в проектной деятельности стало моей следующей задачей. Да, обмениваться ссылками на актуальные документы через почту (в нашем случае MS Outlook) очень удобно и правильно. Но я посчитал, что этого будет мало. Таким образом, возникла очередная идея — выполнить своего рода интеграцию узла проектной документации с системой управления проектами. Уже более полугода мы используем систему управления проектами DEVPROM. Хотя и DEVPROM обладает функциональностью хранения файлов, мне он не пришелся по душе из-за явного преимущества и, можно сказать, привычности использования SharePoint.

На вопрос в службу техподдержки с предложением реализовать в DEVPROM некий функционал SharePoint (хранение версий документов, коллективное редактирование) я получил ответ наподобие "зачем в системе управления проектами функционал версионности и коллективного редактирования? Вы же используйте для этих целей SharePoint — вот и продолжайте его использовать далее". В итоге после этого ответа и возникла идея настройки совместной работы узла проектных документов с DEVPROM.

Итак, что мы сделали для того, чтобы Devprom стал "понимать" SharePoint. Об этом читайте в документе.

Что ж, думаю, есть основания считать реализованную задачу интеграцией, как бы это громко не звучало :)

Материал для начинающих бизнес/системных аналитиков

2012-11-09T21:00:00.000+04:00

Наталья Свешникова, системный аналитик из компании "Лаборатория Касперского" поделилась целой серией лекций об аналитике, оформленных в виде презентаций. Целевая аудитория — специалисты, начинающие свой путь в ИТ-анализе.

Лекции доступны в блогах сообщества системных аналитиков по ссылке.

В дополнение к данным лекциям я бы еще порекомендовал почитать эту книгу.

Немного о контекстных диаграммах...

2012-09-13T22:00:00.000+04:00

В последнее время довольно-таки активно читаю статьи с англоязычного ресурса http://www.modernanalyst.com.

Некоторые новшества и хитрости создания контекстных диаграмм были обнаружены в статье "Putting Systems Analysis “Into Context” using the Context Diagram".

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

"Простые правила написания чего-либо"

2012-09-03T20:00:00.000+04:00

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

Строки особенно актуальны для тех, кто имеет дело с формированием документации.

Итак, "простые правила написания чего-либо":

Придерживайся темы.
Пиши кратко.
Думай до, в процессе и после.
Если можешь не писать, не пиши.
Комментируй, только когда тебя об этом специально попросят.

И будет Счастье.

Спасибо автору!

Перевод статьи "Use Cases and Business Rules: Can They Work Together?"

2012-08-31T18:30:00.000+04:00

Над переводом статьи "Use Cases and Business Rules: Can They Work Together?" я трудился еще года два назад, когда готовил материал для аналитического интернет-журнала "Analyze IT". Но четвертому выпуску так и не суждено было выйти, а держать полезный материал у себя в закромах — явно не мой принцип.

Поэтому приглашаю Вас к прочтению статьи "Варианты использования и бизнес-правила: могут ли они работать совместно друг с другом?". Кстати, данный перевод был использован Александром Байкиным в докладе "Бизнес-правила и дополнительные требования в вариантах использования (use cases)" на конференции ReqLabs 2012.

Практика: Разбиение требований в agile-проектах

2012-08-29T21:00:00.000+04:00

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

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