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

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

• Confluence в жизни аналитика — Часть 1.
• Confluence в жизни аналитика — Часть 2.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Word 2010: не отображается структура документа в панели навигации (проблема и её решение)

Товарищи, знаете ли Вы, что в MS Word 2010 текст со стилем "Заголовок", помещенный внутрь таблицы (в строке таблице), отображается в оглавлении, но не отображается в панели навигации?.. Я наблюдал нечто подобное.

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

Оказалось, что Заказчик предоставил ТЗ, которое было сформировано в виде одной большой таблицы с прозрачными границами. Таблица была наполнена текстом.

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

Нашли один выход для работы с этим документом — использовать неудобный функционал закладок Word 2010.

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

Как и обещал ранее на форуме uml2.ru, делюсь с Вами своим опытом организации процесса управления документацией на длительном проекте по разработке системы для одного из крупнейших операторов мобильной связи. Вся проектная документация - это ТЗ и всякого рода руководства на задачи по разработке новой функциональности описанной выше системы.

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

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

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

1. Организовать единый реестр всей проектной документации, которой за время моего начала работы аналитиком накопилось немало.
2. Обобщить все проектные документы на каком-либо едином ресурсе.
3. Составить регламент работы с документацией и управления ею на проекте.

На реализацию идеи у меня ушло ровно 2 дня. Теперь все вопросы относительно работы с документами решаются довольно-таки оперативно - путём использования реестра и ссылки на регламент.

Для организации процесса я использовал то, что, как говорится, “рядом, и грех не воспользоваться”. Так как компания, в которой я работаю, специализируется, ко всему прочему, на разработке продуктов на платформе SharePoint, был выбран именно портал SharePoint. Была создана, структурирована и актуализирована единая библиотека проектной документации, распределены права доступа между участниками проекта на уровне папок и на уровне отдельных документов. Реестр документации, который также помещён в общую библиотеку, представляет собой... обычный файл MS Excel, в котором в качестве столбцов выступают необходимые мне атрибуты документа.

Теперь все последние версии документов (в т. ч. регламент и реестр), а также полезные проектные сведения лежат в одном месте, доступ к ним предоставлен только участникам проекта, а правила работы описаны в регламенте. Участники могут (в зависимости от прав) как читать, так и править документ коллективно. Стоит отметить, что при изменении документа поддерживается его версионность. А передавать по почте файлы теперь точно не нужно (раньше было только так).

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

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

Баг MS Word: удаление пробелов между словами

Где-то с месяц назад совместно с московским коллегой работал над документом, спецификацией. Я был автором документа и работал в MS Word 2010, коллега рецензировал документ с помощью MS Word 2007. Общими усилиями был выявлен баг текстового процессора: если открыть документ, созданный в Word 2010 и затем сохранённый в формате *.docx, в более ранней версии – Microsoft Word 2007, MS Word удаляет пробелы между некоторыми словами документа. То же самое происходит, если открыть тот же документ в 2010-м Ворде после добавления пробелов, работая с Word 2007.

Пример смотрите на рисунке ниже.

Так получалось, что я коллеге отсылал отредактированный документ формата .*docx. Коллега документ рецензировал, а также расставлял удаленные Word-ом пробелы и заново присылал мне. Когда уже я открывал документ, видел следующую картину: пробелы между словами снова пропали и мне приходилось их расставлять заново (хорошо ещё, что приложение осуществляет выделение ошибки красной волнистой линией, иначе было бы совсем тяжко).

Решили проблему тем, что начали обмениваться документами в формате *.doc.

Описание аналогичной проблемы нашёл на сайте Microsoft (http://social.technet.microsoft.com/Forums/ru-RU/msoclientru/thread/41c82dd6-4cd0-4784-9302-5ce31d177205/), однако на момент публикации записи не было возможности ознакомиться с содержанием ссылки, так как контент был не доступен по неизвестным причинам.

Полезное ТЗ по ГОСТ серии 34

До недавнего момента о том, что такое ГОСТ серии 34 я только слышал. Хотя нет, пару раз ради интереса всё-таки читал ГОСТ 34.602-89 под названием "Техническое задание на создание автоматизированной системы" и даже пытался его как-то адаптировать под некий универсальный шаблон ТЗ, который я мог бы использовать постоянно, не придумывая каждый раз чего-то нового, а лишь исключая ненужные разделы из него. Но "адаптации" успехом так и не увенчались.

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

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

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

• Статья С.А. Нужненко "Разработка полезного ТЗ по ГОСТ 34.602", содержащая множество практических сведений, а также ссылки на тематические статьи.
• Конечно же, сам стандарт на полезном сайте rugost.com с примерами заполнения некоторых разделов.

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

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

Как говорится, я пока в поисках... в поисках оптимального варианта изложения требований. Надеюсь, когда-нибудь я его найду. Или он меня найдёт :)

Стили в WORD 2010 - это удобно!

Для тех, кто не использует при подготовке технической документации стили MS Office Word, посвящается...

Конечно же, уверен, что среди IT-специалистов таких - абсолютный минимум. Но всё же. За мой недолговременный период работы уже пришлось столкнуться с "особенностями" подготовки документации. То, как это делают некоторые люди, просто удивляет. Иногда задаю себе вопрос: "Зачем же так усложнять себе жизнь?"

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

• режима разметки,
• ражима чтения,
• режима веб-документа,
• режима структуры,
• режима черновика.

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

Используем руководство пользователя для выявления требований

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

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

После первоначального ознакомления с документацией:

1. Смотрим оглавление справки, "видим" компоненты системы. Таким образом, получаем высокоуровневое представление о системе - функциональные области системы.
2. Руководство пользователя - это всегда какая-либо последовательность действий пользователя для достижения определённой цели. Значит, есть уже почти готовые варианты использования. Остаётся только доработать их!
3. Что касается пользовательского интерфейса, то, как правило, справочные документы пользователя уже имеют готовые скриншоты экранных форм. Дело за малым - остаётся спроектировать интерфейс, опираясь на аналоги.
4. В итоге, необходимо актуализировать требования к разрабатываемому продукту, добавив либо новые, либо изменив существующие требования в соответствии с необходимой функциональностью.

Оригинал статьи: http://grigorash.ru/archives/85