Всем привет!

Мы, Денис Бесков (beskov) и Илья Поляк (ilyap1) начинаем публикацию цикла статей, посвящённых процессу проектирования веб-сервисов. Цикл построен вокруг 3-хуровневого процесса, в котором явным образом выделяются уровни анализа и проектирования:

1. Бизнеса
2. Продукта
3. Технологий

Здесь, на хабре, достаточно хорошо освещается тема проектирования на уровне технологий. Мы хотим показать взаимосвязь этого уровня, видов работ и проектных решений с вышестоящими уровнями на примере сквозного демо-кейса — проектирования веб-сервиса бронирования билетов в кино, в разработке которого участвовал пару лет назад один из авторов.

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

1. Какими способами можно описывать требования к ПО?
2. Какие из требований к системе обязательно необходимо включать в ТЗ, а без каких можно обойтись?
3. Какие могут быть варианты при выборе форматов описания требований?
4. Как зависит выбор вида описания требований от параметров (продолжительности, рисков и др.) проекта?
5. Какого рода решения помогают принять соответствующие виды требований?

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

I. Бизнес-контекст

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

Издательский дом «Афиша» был основан в апреле 1999 года и сегодня является владельцем нескольких ведущих журналов и сайтов о развлечениях. Компания издает журнал «Афиша», выходящий в трех версиях, — для Москвы, Петербурга и 20 других городов России. Аудитория одного номера журнала составляет около 1 миллиона человек. Сайт «Афиши» ежемесячно посещают порядка 3,2 млн человек.

С целью расширения функционала сайта, развития портала и подготовки к продаже билетов на киносеансы было принято решение рассмотреть возможность запуска сервиса бронирования билетов, который бы работал следующим образом: «Афиша» вступает в партнерские отношения с сетью кинотеатров N и предоставляет зарегистрированным пользователям сайта возможность осуществлять он-лайн бронирование билетов на киносеансы данной сети. В свою очередь, компания N размещает на территории своих кинотеатров рекламные объявления, содержащие ссылку на сайт afisha.ru. Объявления могут размещаться в любом виде: на плакатах, на билетах, в виде логотипа на любых информационных материалах.

После того как стало понятно, в какой ситуации мы находимся и кто является основными агентами, необходимо описать бизнес-процессы, которые требуют автоматизации или изменения. Это поможет понять, что и в какой последовательности происходит, в применении к данному кейсу — как в общем происходит покупка билета и бронирование?

III. Описание процесса в графической форме

В виде диаграмм бизнес-процесс можно описывать с помощью различных нотаций: ARIS — VAD и EPC, IDEF0, BPMN и др. Нотаций много, у каждой есть свои достоинства и недостатки, в рамках этой статьи эта тема не затрагивается.

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

Посещение кинотеатра без предварительного бронирования билетов (в нотации VAD)

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

IV. Описание предметной области

Законодательные ограничения

— Зрителю должно быть больше 14 лет (для сделкоспособности).
— Необходимо дополнительное пользовательское соглашение, в котором пользователю будет необходимо дать согласие на использование его персональных данных.
— В соглашении также должно быть указано, что услуга бронирования предоставляется безвозмездно.

Словарь терминов

Диаграмма сущностей

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

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

V. Анализ бизнес-проблем

Проблемы, их владельцы и причины

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

1. Проблема.
2. На кого воздействует.
3. Результатом чего является.
4. Выигрыш от новой системы.
5. Приоритет.

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

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

Между разработчиками ПО и пользователями ситуации непонимания имеют место достаточно часто. Пользователь хочет получить эффективный инструмент для решения тех или иных задач, к тому же простой в освоении и удобный в использовании, но имеет весьма приблизительное представление о специфике работы программиста. Программист же зачастую имеет весьма и весьма приблизительное представление о круге задач, с которыми имеет дело пользователь. То, что разработчику кажется блестяще реализованным, конечному пользователю может показаться неудобным. На вещи, которые представляются вполне очевидными пользователю, программист может вообще не обратить внимания. (Подробный анализ этих проблем см., например, в книге Дэвида Платта с провокационным, но выразительным названием «Софт — отстой! И что с этим делать?»). Как избежать ситуаций непонимания и помочь программисту и пользователю найти общий язык? (Данная тема уже не раз становилась предметом исследования представителей самых разных областей знаний — программистов, психологов, специалистов в области эргономики. Подробный и интересный обзор литературы по теме — здесь)

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

Поиск подходящего инструмента прототипирования (об этом мы достаточно подробно написали в предыдущем посте) занял у нас довольно много времени и… окончился ничем. Нам так и не удалось найти инструмент, который в полной мере покрывал бы все наши потребности. Похоже, что программы для прототипирования, полностью отвечающей всем нашим представлениям и пожеланиям, в природе просто не существовало… Единичные кандидаты были близки к победе, но в любом из них был какой-нибудь неприятный и неприемлемый для нас «нюанс», который не позволял честно и без кривляния душой сказать: «Это именно то, что мы искали». Конечно, можно было закрыть глаза и пойти на компромисы, но это не наш путь. Недосказанность — это то, чего мы очень не любим.

На этой почве мы приняли не самое лёгкое решение попробовать собственноручно воплотить все наши идеи в жизнь и создать свой инструмент прототипирования. Подспорьем для разработки нашего собственного продукта стали также результаты анализа перспектив рынка инструментов прототипирования: существовало решений немного и покрывали они не все требования IT-компаний (по крайней мере — нашей компании, ну а мы, стоит ли сомневаться, далеко не единственные в своём роде). Ещё одним ощутимым толчком являлась перспектива выпустить первый российский полноценный инструмент прототипирования. Вобщем, плюсов мы насчитали больше, чем минусов.

Создание собственного инструмента прототипирования началось не с чистого листа, а на основе… впрочем, историю создания нашего инструмента опишу ниже.

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

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

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

Мне давно хотелось в простой и доступной форме рассказать о построении интеллектуальных транспортных систем. Потому что мне кажется, что эта тема недостаточно хорошо раскрыта на русском языке, а российских специалистов в этой области можно пересчитать по пальцам. Себя я к числу этих специалистов пока отнести не могу, так как только начал разбираться в проблеме. Но именно поэтому мне интересно об этом писать. Я хочу рассказать о том, как живет отрасль сейчас, какие вообще существуют технологии и средства решения транспортных проблем, какие нюансы и интересные особенности есть в этой сфере. Я хочу написать то, что мне самому так хотелось прочитать хотя бы год назад, когда вокруг не было совсем ничего. Если вам что-то покажется наивным или совершенно очевидным, не судите строго. Для меня эта наивность — хлеб и соль. Только эта наивность, помноженная на богатую фантазию помогает строить в воображении детальную модель будущего. Которая при некоторых познаниях в UML и BPML превращается в проектную документацию.

Раз уж нам с вами предстоит пройти некоторый путь вместе, позвольте представиться. Меня зовут Алексей. По специальности я инженер-системотехник, профессиональный сисадмин. Окончил профильный ВУЗ в 1999 году, 6 лет работал системным инженером, потом 3 года специализировался в менеджменте в области ИТ, а потом нашел себя в роли бизнес-аналитика.

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

Надо сказать, коллеги, что эта работа — просто рай для любителей игры Sim City и Transport Tycoon. Где еще вам представиться возможность построить транспортную систему целого города? И не на экране компьютера, а живьем.

Конечно, не все в этой отрасли радужно и прекрасно. Особенно в нашей стране. Далее о проблемах.

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

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

Введение

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

Как бы то ни было, неплохо бы разобраться в том, что же собой представляют ИТС и для чего они предназначены. Опустим транспортную и политическую составляющие и сосредоточимся на «Айтишной». Разберем на самом высоком уровне архитектуру ИТС и коротко пробежимся по основным ее блокам. Заодно системным архитекторам будет любопытно узнать, как вообще строится архитектура систем масштаба страны.

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

Американский стандарт интеллектуальных транспортных систем U.S. Dot ITS описывает весь комплекс автоматизированных систем управления транспортом. Стандарт настолько масштабен, что втиснуть его описание в один или даже два поста нереально. Так как большинство описанных в нем систем для нас недостижимое светлое будущее, то и делать этого не стоит. А вот что стоит сделать — это рассмотреть то, как он устроен изнутри, какие находки сделали неизвестные американские (ой ли?) ИТ-специалисты, проделавшие весьма значительный объем работы за счет налогоплательщиков.

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

В предыдущих сериях...

В предыдущих статьях цикла мы в деталях описали процесс поиска подходящего нам инструмента прототипирования и историю создания собственного инструмента – GUI Machine.

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

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

Вступление

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

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

Приветствую!

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

Давайте сразу определимся. Я не буду вам затуманивать голову умными словами и буду говорить как есть. Ваше дело верить или нет, это уже другой вопрос, комментарии открыты для дискуссий. И еще — мои слова не нужно воспринимать как истину в последней инстанции. Это не более чем мое личное мнение и мой личный взгляд на вещи. У вас он может быть другим.

И еще одна маленькая ремарка — да, я знаю что хабр — это ИТ ресурс. Да, это статья про ИТ. Технологии управления так же относятся к ИТ. Более того, принимаемые решения в области управления всегда прямо влияют на ИТ структуру компании, поэтому важно знать и понимать, что же такое консалтинг. Хотя бы просто чтоб уметь держать оборону перед начальством :)

А теперь поехали.

В прошлый раз в статье "АСУДД: Что висит над дорогой?" мы бегло прошлись по «железу», которое устанавливается на транспортных магистралях: по типам детекторов транспортного потока, светодиодным табло и дорожным контроллерам.

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

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

Бывает, пользователь заказывает сделать для него нечто непонятное и странное. Решать подобное желание пользователя можно двумя путями:

1. либо помочь заказчику сформулировать его желание поконкретнее и чётче, и затем просто это воплотить, доверившись невербализованной интуиции просящего
2. либо разобрать желание глубже и выяснить, что оно — производное одного или несколько других желаний, одна часть из которых обычно оказывается желаниями уже исполненными (просто заказчик этого не знает), вторая — неоправданными (и это удаётся продемонстрировать пользователю в процессе дополнительного обучения), а третья — более внятными и конкретными, с существенно более чёткими обоснованиями и задачами для реализации понятной дополнительной функциональности.

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

В песочнице уже писал эту тему, только там, к сожалению, не вышли картинки, поэтому повторяю )
Компании сегодня развиты фрагментарно, цели бизнеса, процессы, результаты зачастую мало связаны между собой. Бизнес работает по инерции, мало кто задумывается над высокоуровневым пониманием своей компании. Но когда приходит время автоматизации — внедрить CRM или даже ERP систему всё таки нужно начинать с самого верха. Автоматизация часто выступает в качестве толчка к выстраиванию целостной системы.
Предлагаю чек-лист для проверки готовности компании к автоматизации:
1. Стратегия
2. Бизнес-модель
3. Социальная архитектура
4. Бизнес-процессы
5. Техническая архитектура
6. Результаты