В теме 9 ответов, и 4 участника, последнее обновление сделано пользователем 
Юлия Шамрей 13 г, 8 мес. назад.
-
Сообщения
-
Как показала вчерашняя встреча, аналитик и SharePoint — тема для многих актуальная и интересная (и достойная отдельной ветки на форуме). В общем предлагаю здесь собирать best practices, полезные ссылки, примеры артефактов и все то, что может пригодиться аналитикам при работе с такими проектами.Думаю, можно выделить следующие категории проектов на базе MS SharePoint, важные с точки зрения работы с требованиями:
·Проекты, которые реализуются исключительно на готовых компонентах SharePoint (т.н. OOB Features = Out Of the Box Features). На таких проектах разработчики практически не привлекаются — все требования реализуются силами консультантов/аналитиков и администраторов. Ситуация меняется, если у команды, которая реализует проект, нет доступа к окружению заказчика. Тогда необходимо либо писать подробные инструкции, либо привлекать разработчиков для создания инсталляторов. Так же, имеет смысл привлекать разработчиков в случае миграции контента между версиями приложений, хотя существуют готовые решения для миграции, но они не всегда подходят. Например, для миграции колонок типа Managed Metadata Field необходимо писать свои миграторы, т.к. еще нет готовых.
·Проекты, в ходе которых необходимо изменение/дополнение поведения/вида/UI готовых компонентов SharePoint. Тут, понятно, разработчики привлекаются сразу после сбора требований и активно участвуют в проекте. А в проекте присутствуют все классические фазы — разработка, тестирование, баг фиксинг и т.д.Важные задачи аналитика, на мой взгляд, на SharePoint проектах:
·На этапе сбора требований, определить — подходит ли платформа SharePoint для проекта или нет. Т.е., фактически, соотнести требования с возможностями, которые есть в платформе. Я, например, сталкивалась, достаточно часто, с ситуацией, когда сначала выбирают технологию, а затем собирают требования. В таких ситуациях процент доработок бывает неоправданно высок, а значит дорог. В общем, если после сбора требований оказывается, что многое нужно дорабатывать, то лучше поискать другую платформу/решение. Важно только, чтобы процент доработок оценивали люди, которые реально знают платформу и хорошо знакомы с требованиями.
·Собрать те требования, которые важны для настройки/доработки платформы, а не только для пользователей/заказчика.
·Управлять scope creep. В случае с SharePoint scope creep часто создают сами разработчики, т.к. иногда, как не парадоксально это звучит, разработчики плохо знают OOB возможности платформы и сразу кидаются в бой, т.е. писать все с нуля.Essence, спасибо за информацию, хотелось бы еще получить рекомендации, где можно доступно почитать о готовых компонентах SharePoint и возможно о каких-то особенностях работы с ними с точки зрения аналитика.
И еще интересно, чем отличаются спецификации на таких проектах от "обычных".Есть хорошая книга Scott Jamison, Mauro Cardarelli, Susan Hanley "Essential SharePoint 2010: Overview, Governance, and Planning (Addison-Wesley Microsoft Technology Series)"
Еще есть вот такая очень познавательная на мой взгляд презентация.
По поводу спек, это отдельный хороший вопрос. Я позже напишу подробнее.Поделюсь своими мыслями, выводами и наблюдениями по поводу спецификаций требований к SharePoint (далее SP) проектам.На этапе сбора требований я стараюсь сразу упорядочивать требования и создаю графические модели (мне с ними удобно работать и проще согласовывать с заинтересованными лицами). Далее опишу виды моделей, которые затем будут удобны с точки зрения SP:
Data Flow модель. Эта модель фиксирует границы системы. С ее помощью можно определить, нужно ли будет реализовывать какие-либо коннекторы к внешним сущностям по отношению к системе и оговорить этот момент с техническими специалистами и разработчиками, ведь платформа может налагать существенные ограничения.
Модели процессов (as is и/или to be). Из этих моделей далее можно вычленить варианты использования, MS SP workflows (рабочие процессы), сущности и артефакты предметной области, и участки для доработок.
Модель предметной области. С помощью данной модели можно спроектировать архитектуру системы, создать описание информационной структуры системы (списки, библиотеки, колонки, контент типы, свойства колонок и т.д.) и выявить участки для доработок.
Модель вариантов использования. Данная модель определяет будущие группы пользователей, права доступа, наследование прав доступа, опять таки участки для доработки. И естественно сами варианты использования
, с помощью этой модели можно относительно точно определить процент доработок.Уровень и степень детализации моделей зависят от размера системы, специфики и требований заказчика, размера и состава команды, настроения и погоды за окном
Далее эти модели могут существовать сами по себе или быть включены в различные документы (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 уровне) я описываю как обычные веб страницы гипотетического сайта
.Естественно между всеми этими моделями существуют трассируемость, которую нужно поддерживать. Модели, по возможности/необходимости включаются в документы.
А так же данный набор используется не на каждом проекте, а по мере необходимости. Например, если проект полностью на OOB, то многое не делаю.Еще удобно на этапе сбора требований составить себе эдакий чек лист о чем нужно спросить из того, что важно для конфигурации SP: брендинг, права доступа, группы пользователей, информационная структура, события для воркфлоу, структура сайт коллекций, кто будет администрировать, каков процесс доставки на прод, пройтись по лимитам SP (если они актуальны для проекта), …
Спасибо за развернутый ответ !Essence, большое спасибо!
Очень ценная информацияДумаю, те, кто так или иначе знаком с SharePoint, в большинстве своем не довольны SP UI и Usability. Действительно, SP UI и Usability достаточно специфичны и, порой, очень отличаются от привычных Web UI и Usability. Можно конечно спорить что лучше, но это отдельный топик. Мне кажется, что больше всего времени и бюджетов проектов уходит на доведение SP UI и Usability до привычных пользователю. Возможно, коллеги смогут подтвердить мою теорию.Естественно есть 2 пути:
· Попробовать изменить UX — провести хорошие и достаточные End-User тренинги, попробовать объяснить преимущества SP и т.д.
·Доработать UI и Usability. Далее приведу примеры доработанных сайтов. Пример сайта, который реализован на SP 2007. И еще один. Насколько видите, эти сайты на SP 2007, в SP 2010 появилось Ribbon меню — на самом деле спорное решение с точки зрения Usability. Однако есть возможность просто выключить его и многие этим успешно пользуются. Я долго привыкала к нему, и привыкнув, теперь ценю его возможности.
И для затравки. 4 из 10 лучших интранет решений по мнению Якоба Нильсена за 2010 год реализованы на SP.
А вот неплохая презентация на тему трудностей реализации интернет сайтов на SP и возможных решений.
Примеры интранет-сайтов на SP:Галерея готовых шаблонов сайтов для SP 2010:http://www.techsolutions.net/Blog/tabid/65/EntryId/18/Fab-40-for-Sharepoint-Foundation.aspx
Вы должны авторизироваться для ответа в этой теме.
