Data Science Visualization Course

 

Advertisements

Проведение бизнес анализа для создания системы “Управление школой”

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

Данная статья описывает один из вариантов проведения бизнес анализа для проектирования и разработки системы управления школьным образованием. Материал публикуется в учебных целях, для начинающих бизнес аналитиков и консультантов, вовлеченных в процесс создания и доработок ИТ продуктов.

Шаг 1. Домашнее задание

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

Итак, правило для хорошего аналитика:

(!) Выполните свое домашнее задание. Изучите домен Заказчика.

На данном этапе можно (и нужно) выполнить такие действия:

  1. Изучить предметную область, ее термины и типовые процессы.
  2. Изучить решения конкурентов, сделать сравнительную таблицу возможностей
  3. Предположить самому, какие задачи потребуется решить
  4. Подготовиться к встрече по выяснению требований

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

  1. Решение будет разрабатываться для одного Заказчика или предполагается, что оно должно быть типовым и в будущем будет предлагаться и другим клиентам. Если это так, то требования к анализу следует повысить, так как такая система должна быть более гибкой и настраиваемой.
  2. Сколько человек будет вообще работать с таким продуктом? Порядок цифр лучше понимать сразу, чтобы определить для себя уровень значимости системы (и стоимость ошибок аналитика 🙂 )

Шаг 1. Выявление бизнес требований

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

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

Тут аналитику пригодится знание такой области знаний как Стратегический анализ, который детально описан в BABOK 3.0, который собственно и пришел на смену стандарту 2.0, и одна из причин – более детальная проработка именно области стратегического анализа.

Итого, следующий совет для хорошего аналитика:

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

Для упрощения начального понимания, можно использовать технику Mind Map и сделать модель, в которой описать тезисы из проведенного стратегического анализа, и потом уже более детальные требования к решению. Модель Mind Map хороша тем, что позволяет легко следовать базовой логике – вначале выяснить бизнес требования, потом детальные требования к решению и только потом думать про возможную архитектуру системы. Модель конечно же на верхнем уровне можно использовать потом и для других проектов. Вот начальный вариант карты:

Global MM

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

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

Strategy Analysis

 

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

Контекст

Шаг 2. Выявление требований пользователей

В классике бизнес анализа и сбора требований пользователей, которая замечательно расписана как в BABOK 3.0 так и работах таких аналитиков, как Карл Вигерс (“Разработка требований к ПО“) можно получить много информации и советов, но пару замечаний из собственной практики я себе все же позволю:

  1. Не рассчитывайте на то, что заинтересованные лица расскажут Вам все пожелания к системе, и вам останется только задокументировать их письменно. В реальной жизни Заказчик предоставит нам список проблем, пожеланий, предложений. Это будет информация, которую аналитик должен конкретизировать, переосмыслить и привести к единому виду, упорядочить и задокументировать.
  2. Подвергайте внутреннему сомнению требования Заказчиков, докопайтесь до истиной причины каждого требования, проверьте, насколько это поможет решить проблемы, собранные на этапе стратегического анализа. то поможет отфильтровать ненужные требования и уменьшить скоп работ.
  3. Пишите просто, на языке Заказчика, но избегая сленга. Специальные термины затем необходимо собрать в одну таблицу, это позволит коллегам в будущем понимать ваши документы. Заказчик должен читать ваши документы, ему должно быть понятно. Задача аналитика в том, чтобы написать требования так, чтобы они были понятны и Заказчику и Разработчикам одновременно.
  4. Помните, требования не должны содержать решения. Решение предоставит архитектор, нужно дать ему свободу для маневра. Требование “Предоставить ученикам личный сайт для просмотра учебных материалов” диктует определенное архитектурное решение. Возможно, разработчик решит использовать просто веб страницу, или отдельное приложение. Требование “Предоставить ученику сервис в виде личного кабинета для доступа к учебным материалам”  даст большую свободу системному архитектору.
  5. Выявляйте, думайте, слушайте и сами предлагайте решения, обсуждайте это с Заказчиком. Проявляйте фантазию. Помните, аналитик – немножко изобретатель, ведь мы предлагаем то, чего еще нет. Такая часть нашего мышления крайне важна. Но вовремя умейте и остановиться, выбрав только главное и приоритетное. Скоп нужно держать.

Ниже пример структуры начальной организации требований, с использованием той же техники Mind Map:

Bus Analysis

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

Иногда для понимания можно применить трассировку требований, хотя на больших списках это приведет к плохой читаемости карты:

User Req

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

Больше рисуйте. Заказчики в основном визуалы. Читать списки и документы, особенно на начальных этапах анализа никто не любит. Изучите UML, это не так сложно как кажется.

Диаграмма сценариев использования системы может выглядеть примерно так:

Learning.Use Cases

 

Шаг 3. Разработка функциональных и нефункциональных требований к ПО

В наши дни существует множество мнений, что гибкая методология – лучше прощу и быстрее, что достаточно собрать требования пользователей и разработчики смогут выполнить свою работу. Я хотел бы сделать такой комментарий в связи с этим: не зависимо от нас и от методологии, функциональные требования, равно как и нефункциональные существуют, и аналитик просто может переложить на плечи разработчика формирование этих типов требований. Однако такой подход требует более высокой квалификации от команды разработчиков, но не всегда это возможно. Если Вашего участия как аналитика на этом этапе достаточно, и бюджет проекта ограничен, то конечно можно все так и оставить, но хороший аналитик, мне кажется, должен уметь проанализировать требования пользователей и уметь составить из них те функциональные требования, которые позволят пользователям сделать в системе  то, о чем согласовано с аналитиком в виде  сценариев использования (Use Cases).

Опять же на начальном этапе анализа нам может пригодиться все те же карта Mind Map для формирования и фиксации функциональных требований на основе пользовательских требований:

ИтогИтогоMindMap.Learning.FR2

 

Несколько слов по поводу нефункциональных требований – что это такое вообще? Все просто – все требования, которые мыв не можем отнести к функциональным, являются нефункциональными. Требования к быстродействию, удобству, безопасности – яркие тому примеры.

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

Статья в работе. Продолжение следует…

В следующих разделах (информация в процессе подготовки и редактирования):

Шаг 4. Дизайн системы

  • Модель сущностей

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

Мои комментарии следующие:

  1. Аналитик обязан понимать предменую область, с которой он работает;
  2. Аналитик является связующим звеном между разработчиками и Заказчиком, модель сущностей дает разработчикам очень четкое понимание о рамках и структуре информации, которая должна храниться и обрабатываться в будущей системе.
  3. Диаграмма сущностей – самый быстрый способ понять назначение и рамки системы.
  4. Диаграмма сущностей показывает не только возможности системы, но  и ее ограничения, что также очень важно для понимания и оценки новых требований.

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

Итак, как же выглядит диаграмма сущностей для конкретной ситемы “Управление школой”? В рамках озвученных потребностей пример такой диаграммы показан на рисунке ниже:

ERD

  • Прототипы пользовательского интерфейса
  • Модели бизнес процессов
  • Модель артефактов

Шаг 5. Оценка, приоретизация и прочие атрибуты качественных требований

Шаг 6. Управление требованиями

  • Использование инструмента Excel
  • Использование системы управления требованиями Microsoft Team Foundation Services

Для демонстрации текущего кейса, для читателей создан бесплатный ресурс по адресу: https://almdemoua.visualstudio.com/

Ссылка для получения доступа: заполните свой e-mail 

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

TFS Learning 01

Шаг 7. Внедрение и поддержка системы

 

SMART Talks 78: SharePoint overview

Доклад, в ходе которого были продемонстрированы базовыу возможности SharePoint Online для построения портала компании средствами UI.

 

Tool for compare Feature availability across SharePoint Online plans

Often design sharepoint solutions for customers, it is necessary to consider what features are available in their subscription, and which are not. For this purpose, I have developed a simple tool – Excel file, which helps me to compare features.

https://bgpoint.sharepoint.com/_layouts/15/WopiFrame.aspx?guestaccesstoken=waMB4hIMxvWAc1tukN5wB3c1vpDVu02XTjG8rok6%2Fh0%3D&docid=01d5cdeb77530454b932ed2b71599e23c&action=view

features

Office 365 – New look for SharePoint sites

Microsoft has started rolling out Changes for Office 365 SharePoint sites with the new updated UI. These changes reflect what was announced in the Future of SharePoint conference on 4th May 2016. Some of the known changes are – The ‘Sites‘ page is now the ‘SharePoint home’ and the “Sites” tile in Office 365 App launcher is “SharePoint” tile.

If you have signed-up for the First release in your tenant, you should see the message in your Office 365 Admin center now.
Advertisement

Below, let’s look at what has changed in terms of UI, and how it looks now.

Tile or App in App Launcher

The “Sites” tile becomes the “SharePoint” tile. Clicking into the SharePoint Home displays the recent sites and portals you are most active in and following, recommended sites per the Office Graph, plus company-wide sites promoted by your company.

SharePoint App

Site Home

The ‘Sites’ page is now the new “SharePoint home”.

Old Sites Home
Sites Home Office 365 - old

New Sites Home

office 365 sites home page

LINKS on New Sites Home Page
If you had custom promoted sites in classic view of the SharePoint Sites page, the Links section of the SharePoint home page is pre-populated with those sites.

office 365 new site links

 

NOTE : The pre-population of promoted sites in the Links list happens only once when the first user visits the new SharePoint home page. If you go back to classic view and change the promoted sites, the changes will not be reflected in the Links list on the SharePoint home page.

Creating New Site

From the SharePoint home, you, too, can create new sites – simple and fast. There has been huge improvements in the time it takes to create a site (targeting seconds to create), the flow & integrated value so that it naturally leads to the creation of an Office 365 Group in Azure Activity Directory (AAD), as well as establishing compliance controls for site classification.

Old Create Site
Create a new Site Office 365 - old

New Create Site

Create new Site - SharePoint UI Office 365

See more Sites by selecting See all

See all Sites Page - Sites and Workspaces

All Sites Page.

All sites - New Office 365 UI

Site Contents Page (View all Site Content)

New Site Contents Page

The new look for SharePoint Team sites is still pending.

source: http://www.learningsharepoint.com/2016/06/02/office-365-new-look-for-sharepoint-sites-and-what-has-changed/

What is the difference between Windows CTP, Beta, RC, RTM, RTW, SPs and Preview?

Below are difference between Windows CTP, Beta, RC, RTM, RTW, SPs and Preview
CTP (Community Technology Preview):
CTP means Community Technology Preview. It means you can use it but it’s not the final version of a software and things may change when product is finally released. It’s generally an incomplete preview of a new technology in progress. These usually come out before beta and are a way to gather feedback from the community during the development of a product. This is similar to an Alpha release per Jeff’s hierarchy, except that at Microsoft, Features are present to varying degrees and customer can get an idea of where the release is going.
Beta
The software is complete enough for external testing. Beta software is usually feature complete, but may have known limitations or bugs. Betas are either closed (private) and limited to a specific set of users, or they can be open to the general public. Features are mostly implemented but still have rough edges. Quality is fair at this point. The higher number beta, the higher the quality
RC (Release Candidate)
Product believes it’s ready to ship. One last chance for customers to provide feedback and find major blocking issues.
RTM (Release to Manufacturing)
Product is complete and ready to be shipped to customers. RTM stands for “Released to Manufacturing” and is a throwback to the days when software was mostly released as CDs. When a project went “Gold”, it was released to manufacturing who then burned a bunch of CDs and packaged them up to be put on store shelves. True, this still goes on today believe it or not, but this mode of delivery is on the decline for certain types of software.
RTW Release
RTW is a related term that stands for “Released to Web” which is more descriptive of how software is actually shipped these days. For example, while we like to use the term RTM internally out of habit, ASP.NET MVC will actually be RTW.
SPs (Service Pack)
SPs are service packs. It means product updates and bug fixes for that release. While R2 refers to Release 2, and it generally includes enhancements that cannot be included as part of service packs. A Service Pack (or SP) is simply an RTM (or RTW) release of fixes and/or improvements to some software. It used to be that SPs rarely included new features, but it seems to be the norm now that they do. Service Packs tend to include all the hotfixes and patches released since the product originally was released, which is convenient for the end user in not having to install every fix individually.
Technical Preview
The Windows Technical Preview (TP) is an evaluation copy for enterprise users. Basically, it’s an early test version. Businesses are given the chance to try it out, see how it fits into their routines and provide Microsoft with feedback. Ideally, Microsoft will integrate the collected data into a final product that meets the needs.