Анализ и проектирование систем *

Есть такая клёвая простенькая программа для телефона: Remote Volume Control. Делает одну простую вещь — даёт крутить громкость на компьютере (PC). Удобно: включил кино, упал в гамак и когда вдруг возникла необходимость — подкручиваешь громкость.

Вдруг в какой-то чудесный день программа просто молча перестала работать. Никаких обновлений не было, настройки сети не менялись… Как-то я вот не привык чтобы программы вдруг ломались и переставали работать сами по себе.

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

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

В этой статье я попытаюсь поделиться своим опытом в проектировании пользовательской бизнес-логики. Это явно не претендует на полноценный ликбез, т.к. я всего лишь вспоминаю то, через что прошёл лично я, какие ошибки я допустил, и как мне их удалось (или не удалось) исправить в будущем. Наверняка, опытные системные архитекторы уже все проходили и знают, однако надеюсь, что некоторые советы таки будут полезны.
Мы использовали (и используем) клиентскую часть на WPF/Silverlight, WCF сервисы и СУБД Oracle, Postrges, MsSQL. Код написан по MVVM, использована Prism для модульности и навигации. Не могу точно сказать, какие из тезисов подойдут для других платформ и языков.

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

Итак, поехали.

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

За 3 года существования летнего аналитического фестиваля мы накопили большое количество записей интересных выступлений. И сегодня хотим поделиться с вами подборкой:

1. Предпроектные работы

• Юрий Веденин. Как написать хорошее коммерческое предложение
• Константин Быченков. Цели проекта: Что? Зачем? Как?

2. Выявление требований

• Илья Корнипаев. Креативные техники сбора требований
• Ирина Левенец. Бесконтактное обследование
• Юрий Веденин. Анализ пользователей

Кратко об авторе исходной статьи: Адам Босворт (Adam Bosworth) начал карьеру в Borland, где работал над системой электронных таблиц Quattro. Перейдя в Microsoft он занимал различные руководящие должности, включая пост главного руководителя группы WebData, занятой созданием и продвижением XML. Кроме этого он занимался Access и движком Internet Explorer 4.0 с кодовым именем Trident. Уйдя из Microsoft Адам вошел в число сооснователей Crossgain, после ряда поглощений их основной продукт превратился в Oracle Workshop for WebLogic. В 2004-2007 годах Босворт занимал пост вице-президента по разработке продуктов в Google, где занимался Google Docs и руководил разработкой Google Health (закрыта с 1 января 2012, когда-то о ней писали на хабре). После ухода из Google он основал стартап Keas, использующий элементы социальных сетей и игр для улучшения здоровья.

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

К собственному удивлению и в какой-то степени боли, я успел поучаствовать в разработке нескольких стандартов. Один из них использовался для обмена данными между базами данных и пользовательскими приложениями вроде электронных таблиц или Access. Он назывался ODBC и отлично показал себя, несмотря на некоторые затруднения в начале. Другим был стандарт того, что сейчас называется AJAX, создания сложных, интерактивных веб-страниц вроде Gmail. Наверное самым важным был XML. Это все успехи. Были и провалы. Особенно хорошо я помню OLE DB, которым мы хотели заменить/вытеснить ODBC. Одним из балансировавших на грани успеха и провала был/является XML Schema. В результате всех этих усилий я выучил несколько уроков, которыми постараюсь поделиться с вами. Каковы они?

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

Данный пост является размышлением на тему максимально эффективного использования простаивающих ресурсов корпоративной сети.

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

Сеть полна предупреждений и предостерегающих повествований об использовании подобного подхода. Есть ужасающие истории о потере данных, исчерпании памяти или людях неспособных эффективно управлять данными в Redis, вы, возможно, интересуетесь «О чём вы вообще думаете?». Так вот, наш рассказ, почему мы всё же решили использовать Redis и как мы преодолели все эти проблемы.

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

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

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

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

Последний раз я писал статью о проектировании в 2011 году. Тогда я собирался написать гораздо больше, но подумал: «Методика есть, но она не проверена временем, клиентами и проектами. Какого беса я буду писать о ней?». И не стал. Прошло два года, за которые мы с командой спроектировали полсотни разных проектов: корпоративные сайты и каталоги товаров, личные кабинеты, системы управления, сервисы, посадочные страницы, мобильные приложения. Многое поменялось: у меня есть статистика, данные по конверсии, отзывы пользователей и клиентов, сделано и исправлено много ошибок в методике и процессе. Теперь можно и написать.

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

Как выглядят переводы? Это документ, оформленный на другом сайте, других страницах, но который повторяет последовательность мыслей автора и структуру его текста. Бывает, что авторский текст меняется, особенно часто это случается в документации — основном профессиональном применении переводов, с которыми приходится встречаться программистам и другим пользователям технической продукции. Если привязать перевод к исходному коду статьи, документации или книги так, чтобы скрипт показа перевода следовал по структуре, проверял изменения и отмечал непереведённое, то становится очень легко следить за изменениями текстов и переводить изменения. Новые версии текстов не становятся слишком отличными от старых и прежние переводы остаются частично работать. Перевод сам будет следить за своей актуальностью. Все прочие тексты будут представлять собой просто слепки, имеющие меньшую ценность, чем созданный и поддерживаемый таким способом перевод. Да, за их состоянием скрипт или сервер может следить, чтобы вовремя сообщить держателям слепков об устаревании. Слепки полезны не только как источник контента владельцам сторонних ресурсов, но нужны пользователям для работы в оффлайне или в составе пользовательских программ. Но более ценным будет всё же перевод, привязанный к структуре и оформлению оригинала. Он же поможет следить не за копией сайта, а за самим оригинальным сайтом в случае работы с документацией.

Эту статью я хочу посвятить временами нелегкой, но увлекательной профессии ИТ-аналитика. На Хабре не так много материалов по данной дисциплине. К примеру, по управлению проектами – на порядок больше. Но выложенные недавно две статьи (раз и два), похоже, вызвали интерес, посему я тоже хотел бы внести свой скромный вклад. Сам работаю более 8 лет в роли аналитика, так что постараюсь не потратить Ваше время зря.
Не стану пересказывать теорию (ее можно почерпнуть в замечательной книге Вигерса или в BABOK). Мне бы хотелось сосредоточиться на практической стороне вопроса – описать выжимку из «боевого» опыта, как своего, так и некоторых других людей, с которыми мне посчастливилось работать.

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

Стадию создания или разработки требований условно можно разделить на 4 этапа.

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

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

В ноябре 2012 в МГТУ им. Баумана мы, Школа системного анализа,
провели открытое событие «Введение в профессию системного аналитика».

Наконец стала доступна первая часть видео, выступление
Сергея Нужненко на тему «В чём заключается работа системного аналитика»:

1. Мифы о задачах и ответственности. Смежные роли (5 минут): vimeo.com/61652862​

2. Риски и неопределённость. Место и задачи в проектном цикле (18 минут): vimeo.com/61968936

3. Окружение, предмет и модель работы. Типовые процессы (10 минут): vimeo.com/62449309

4. Аналитический цикл работы с информацией. Модальная логика (12 минут): vimeo.com/64330992

Взаимодействие с системами, которые реагируют на запросы пользователя быстро (в течение 100 мс), ощущается тем же пользователем, как более плавное и естественное, чем взаимодействие с системами, которые реагируют долго. Развитие Интернета и возникновение датацентр-масштабных вычислительных систем (warehouse-scale computing systems) дало возможность появлению появлению веб-сервисов, обладающих высокой скоростью реакции и в тоже время, обрабатывающих терабайтные массивы данных, расположенные на тысячах серверов. Например, поисковая система Google обновляет результаты выдачи в ответ запроса одновременно с тем, как пользователь печатает, при этом система предсказывает наиболее вероятный запрос, основываясь на напечатанном префиксе, и осуществляет поиск и отображение результатов за десятки милисекунд. Устройствам дополненной реальности (таким как, например, Google Glass), которые только-только начали выходить на рынок, понадобятся веб-сервисы с еще более высокой скоростью реакции, дабы гарантировать естественность взаимодействия.

4-6 июня 2013 года в Москве международный эксперт д-р Питер Хрущка проведет 3-х дневный мастер-класс «Архитектура ПО». Данный мастер-класс является базовым курсом для подготовки к международной сертификации iSAQB.

Справка:
Доктор Питер Хрущка – учредитель Atlantic Systems Guild, международной известной группы экспертов (www.systemsguild.com), в которую входят Том ДеМарко и Тим Листер. Входит в редакционный совет IT журналов, в том числе учредитель и член Международного Совета по Разработке Требований (IREB) и Международного Совета по Квалификации Архитектуры Программного обеспечения (ISAQB). Основатель Agile-сообщества в Германии. Один из разработчиков шаблона архитектурной документации систем ARC42. Первопроходец в области инструментов моделирования для структурных и объектно-ориентированных методологий. Частый спикер на IT конференциях, консультант, среди его клиентов многие компании из списка Fortune 500. Автор многочисленных статей и 9 книг по программной инженерии и человеческому фактору, в том числе соавтор знаменитой «Балдеющие от адреналина и зомбированные шаблонами».

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

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

Дополнительная информация и регистрация на сайте careerlab.ru/education/guru-academy/hruschka/sem1

Со времени моей последней публикации на тему ИТС прошло уже больше года. Самое время продолжить прерванный разговор. Сегодня мы затронем тему правильного понимания предмета ИТС. Проблема понимания предмета неразрывно связана с пониманием роли и места автоматизации вообще, не только в области транспорта. Топтаться будем возле определения ИТС, от которого потянутся довольно любопытные логические связки. Затронем тему моделирования транспортных потоков и концептуальную роль ИТС в управлении транспортными потоками. Чтиво получилось совсем не развлекательное. Но так как на Хабре (да и вообще в рунете) царит тишина на данную тему (если не считать случайных опусов всяких «гуманитариев»), приходится нести тяжкое бремя просвещения и аккуратно излагать базовые вещи.

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

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

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

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