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

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

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

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

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

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

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

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

Не секрет что для успешного внедрения любой системы документооборота необходимо произвести несколько логичных шагов, в данном посте я опущу этапы исследования, начну с пилотного проекта. И постараюсь описать проблемы и способы решения оных, которые с уверенностью в 90% существуют на любом пост-советском «кондовом» предприятии.

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

Предпосылки: автоматизация, создание искусственных имплантов, нейронные сети, дополненная реальность, ряд статей и комментариев на Хабре, Cnet, Popular Science, MIT technological review и ряде других подобных новостных порталах. Из последних — Human Revolution на Хабре, что ещё раз натолкнуло на необходимость публикации.

Последствия: “Мир Полудня”, “Мир Академии” (Фонда/Основания), “Мир Золотого Кольца”

Альтернатива: “Матрица”, “Терминатор”, “1984”, “Мир Мы”, “Мир Нейроманта”

Так что же нас всё-таки ожидает? (Кому лень читать — в качестве P.P.S. создано краткое резюме)

С появлением первых средств защиты информации возникли первые насущные вопросы: как узнать, что возведенные баррикады работают и защищают? как быстрее реагировать на оповещения? как понять, какие угрозы удалось предотвратить? Работает ли наш файерволл, можно узнать, выполнив ICMP ping: если правила в ACL (access control list) работают, то ответов, содержащих echo reply, быть не должно. Можно через консоль устройства просмотреть журнал событий, разбирая сотни или тысячи строк вручную и пытаясь увидеть отраженную или выявленную угрозу.

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

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

В данной статье я бы хотел рассказать об одном из вариантов организации сетевого взаимодействия в программах, написанных на Qt, используя библиотеку QexRemint. Эта библиотека позволяет сериализовать/десериализовать сигналы и слоты. Дописав к ней сетевую часть, можно получить отличный и удобный механизм для удаленного вызова процедур (Remote Procedure Call).

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

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

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

Многие читатели Хабра знакомы с внутренней кухней разработки ПО, а ведь железо — это совсем другая история. Готовы? Тогда поехали.

Английский термин compliance означает соответствие одному из высокоуровневых стандартов (таким как SOX, PCI DSS, Basel II, GLBA). Проводить проверку на соответствие этим документам необходимо для того, чтобы определить, насколько хорошо в вашей организации соблюдаются требования, описанные данными стандартами (разрешенная длина паролей, наличие внутренних регламентов и политик, время устранения уязвимостей и т. п.).

Помимо международных стандартов существуют их отечественные аналоги, корпоративные политики и требования NIST.Проводить оценку соответствия этим документам также необходимо. Стандарты содержат наборы требований: выполнение всех требований стандарта фактически означает соответствие ему. Пример отдельного требования: «Должен иметься дисциплинарный процесс для служащих, которые произвели нарушение защиты» (ИСО/МЭК 2005 A.8.2.3).