inductrix

Обидчивый гороскоп via Нострадамус</lj>
Интересное: Comic strip

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

Так уж получилось, что основной "видимый" :wink: продукт, который генерят аналиты это документы.

Обращаете ли Вы внимание на оформление документов?

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

Внешнее - это то, что видно сразу читателю. Т.е. разделы, подразделы, заголовки, таблицы, списки, нумерация, картинки и т.д. Все что, облегчает восприятие информации для читателя, в первую очередь. По себе знаю, что читать неструктурированный текст очень сложно. Пока писала, всплыл вопрос: Можно ли переборщить с внешним оформлением, как считаете (крайности, типа 7 цветов радуги не в счет)?
Кстати, внешнее оформление иногда помогает выцепить интересные штуки в требованиях, которые не лежат на поверхности, хотя может это только у меня работает :)

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

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

Ситуации с RMS не рассматриваем, только доки.

Для того, чтобы оценить, нужно выбрать подход в написании спеки. Я, например, часто пользуюсь такой формулой: (([кол-ко сценариев использования]*X*1.5)+Y), где X - время, которое у меня уходит на описание 1-го сценария использования и связанных с ним форм/страниц/списков/системных сообщений/правил; 1.5 - коэффициент, учитывающий риски и то, что я ошиблась в подсчете кол-ва сценариев; Y- время на сбор требований (сессии сбора требований, фиксирование результатов сессий, подготовка к сессиям и т.п.), анализ результатов сбора требований, сессии по проектированию с тех. специалистами и т.п.
В каждом отедельном случае в самом начале я стараюсь провести планирование и по шагам расписать, что мне нужно сделать для того, чтобы выдать спеку, часто с детализацией до 2 часов.

Поделюсь своими мыслями, выводами и наблюдениями по поводу спецификаций требований к SharePoint (далее SP) проектам.

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

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

Модели процессов (as is и/или to be). Из этих моделей далее можно вычленить варианты использования, MS SP workflows (рабочие процессы), сущности и артефакты предметной области, и участки для доработок.

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

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


Уровень и степень детализации моделей зависят от размера системы, специфики и требований заказчика, размера и состава команды, настроения и погоды за окном :oops: Далее эти модели могут существовать сами по себе или быть включены в различные документы (project vision and scope, SDD, BRR, URD, SRS,..), что опять же зависит от конкретных условий проекта. Про трассирование требований (а модели отражают требования) думаю все помнят.

На этапе проектирования системы создаются дополнительные модели (не только графические), а так же уточняются и расширяются существующие:

Прототип. Мне нравиться делать прототип сразу на SP, а для доработок делать мокапы в Balsamiq, например, или вставлять текстовое описание на страницы SP (для воркфлоу, например).

Presentation Layer Site Map. Старая добрая карта сайта: сайт коллекции-сайты-страницы-вебпарты.

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

Информационная матрица. Я делаю excel-файл, в который вношу данные по сущностям и их атрибутам. А затем определяю, какими типами полей эти атрибуты будут реализованы (в SP есть ограниченный набор типов полей, который можно расширять своими, но это не рекомендуют делать, т.к. при обновлениях от MS они могут сломаться). Далее указываю обязательность, уникальность, отображение/скрытие. Соотношу поля с контент типами, сайт колонками, списками и библиотеками, указываю порядок полей. В общем, получается достаточно большая матрица, но используя различные сортировки, фильтрации и другие excel-прелести ей очень удобно пользоваться и поддерживать ее в актуальном состоянии.

Permission матрица. Матрица прав доступа на уровни системы (сайт коллекции, сайты, списки, библиотеки, документы, записи в списках, папки, страницы): по вертикали - уровни, по горизонтали - группы пользователей, на пересечении - уровень доступа. Уровни доступа указываю в терминах SP.

Описание вариантов использования. Я стараюсь по минимуму описывать OOB варианты использования, обычно вставляю копии экранов и получается нечто вроде руководства пользователя. Но совсем не описывать у меня пока получалось не часто, это возможно только, если все члены команды и заказчик хорошо знакомы с возможностями SP. Степень детализации вариантов использования, которые требуют доработки, зависит от вшивости заказчика и уровня команды (для джедаев иногда приходиться писать очень формально и подробно).

Описание функциональных требований. Структура данного описания практически полностью дублирует Site Settings страницу на SP сайт коллекции. В таком варианте удобно настраивать новые сайты руками. Для каждого сайта в сайт коллекции (включая top-level сайт) описываются все секции, которые могут быть переопределены на Site Settings странице, причем если какое-то свойство не переопределяется, то я это так и пишу. Веб страницы (которые между прочим хранятся в отдельных библиотеках на productivity уровне) я описываю как обычные веб страницы гипотетического сайта :wink: .


Естественно между всеми этими моделями существуют трассируемость, которую нужно поддерживать. Модели, по возможности/необходимости включаются в документы.
А так же данный набор используется не на каждом проекте, а по мере необходимости. Например, если проект полностью на OOB, то многое не делаю.

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

Мои размышлизмы на тему...

Системное требование - это определение необходимого (требуемого) состояния, в котором должны находиться система (аппарат, продукт) и окружающие ее среда или контекст. Вот такое определение я себе придумала, посоветовавшись с господами Jackson и Neil Maiden.

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

Пример из жизни может быть такой.

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

Системные требования:
1. Документ при сканировании должен быть расположен определенным образом, чтобы у сканирующего и распознающего модуля была возможность выполнить свою функцию.
2. Метаданные документа должны располагаться в определенном месте на документе.
3. Если в ходе распознавания произошла ошибка, и система не может определить целевую папку, то документ должен быть сохранен в промежуточной папке для последующей ручной обработки. Хотя вот это требование может быть и функциональным, если пользователь его озвучил аля "Хочу, чтобы все документы, сканирование и распознавание которых произошло с ошибкой складывались в одно место".
4. Ну и вплоть до брутального. Для того, чтобы документ был корректно сохранен в хранилище, пользователь должен инициализировать процесс сканирования и распознавания документа, и убедиться в его успешном завершении.

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

Думаю, можно выделить следующие категории проектов на базе MS SharePoint, важные с точки зрения работы с требованиями:

• Проекты, которые реализуются исключительно на готовых компонентах SharePoint (т.н. OOB Features = Out Of the Box Features). На таких проектах разработчики практически не привлекаются - все требования реализуются силами консультантов/аналитиков и администраторов. Ситуация меняется, если у команды, которая реализует проект, нет доступа к окружению заказчика. Тогда необходимо либо писать подробные инструкции, либо привлекать разработчиков для создания инсталляторов. Так же, имеет смысл привлекать разработчиков в случае миграции контента между версиями приложений, хотя существуют готовые решения для миграции, но они не всегда подходят. Например, для миграции колонок типа Managed Metadata Field необходимо писать свои миграторы, т.к. еще нет готовых.
• Проекты, в ходе которых необходимо изменение/дополнение поведения/вида/UI готовых компонентов SharePoint. Тут, понятно, разработчики привлекаются сразу после сбора требований и активно участвуют в проекте. А в проекте присутствуют все классические фазы - разработка, тестирование, баг фиксинг и т.д.

Важные задачи аналитика, на мой взгляд, на SharePoint проектах:

• На этапе сбора требований, определить - подходит ли платформа SharePoint для проекта или нет. Т.е., фактически, соотнести требования с возможностями, которые есть в платформе. Я, например, сталкивалась, достаточно часто, с ситуацией, когда сначала выбирают технологию, а затем собирают требования. В таких ситуациях процент доработок бывает неоправданно высок, а значит дорог. В общем, если после сбора требований оказывается, что многое нужно дорабатывать, то лучше поискать другую платформу/решение. Важно только, чтобы процент доработок оценивали люди, которые реально знают платформу и хорошо знакомы с требованиями.
• Собрать те требования, которые важны для настройки/доработки платформы, а не только для пользователей/заказчика.
• Управлять scope creep. В случае с SharePoint scope creep часто создают сами разработчики, т.к. иногда, как не парадоксально это звучит, разработчики плохо знают OOB возможности платформы и сразу кидаются в бой, т.е. писать все с нуля.

Новый тренинг по управлению временем:
http://melamory-me.livejournal.com/428746.html
Я хочу участвовать

Были давеча на проводах Старого Нового Года в Белой Веже. Пошли вообщем-то по двум причинам: мужу нужно было встретить знакомого по делам и хотели посмотреть на группу "Разбитае Сердца Пацана" в жизни.

Так группа эта была в самом конце культурной программы, то пришлось прослушать ее целиком.

Началось все с "Akana NHS".  Вот вроде все красиво и качественно, но не цепляет. Все таки я предпочитаю слушать джаз отдельно, а обрядовые этнические песни отдельно. Голос у Руси сильнейший, а вот стилист группе явно требуется.

Потом было что-то несуразное "Кумалентре".

Затем была "Маланка Orchestra". Завадная цыганщина, но не более.

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

У РСП клевой был одна песня, по которой снят клип. Другие песни так себе. А вот подтанцовка жгла.

Вообще все вместе напоминало цирк уродов.

Хех... понеслась.
А Нина Ричи хороша стерва.