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

Публикуем доклад Печенкина Григория с предыдущей конференции Analyst Days 2013.

Аннотация:

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

Видео доклада:

Салют коллеги!
24 мая в Москве пройдет 3-я конференция по системному и бизнес анализу Analyst Days.

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

Об организации конференции

24 мая в Москве пройдет III Международная конференция по системному и бизнес-анализу Analyst Days. Кому она нужна, как стать бизнес-аналитиком, и стоит ли вообще к этому стремиться? Об этом расскажет Максим Цепков, главный архитектор дирекции развития решений, группа компаний CUSTIS

INTRO

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

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

Итак, для начала отвечу на главный вопрос: для чего всё это нужно.
Есть несколько причин.

Ура! Мы закончили работу над переводом замечательной книги об архитектуре JavaScript-приложения. Работать над переводом было очень приятно — мы получили около 40 пулл-реквестов от совершенно незнакомых нам людей, которые помогли исправить множество опечаток, неточностей и различных багов на сайте! Ссылка на наш перевод упоминалась в курсе «Фронтенд-разработка», читаемом во втором семестре Технопарка Mail.ru, а также в некоторых независимых подкастах.

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

Читать книгу можно на сайте перевода. Также можно скачать книгу в удобном формате: epub, mobi, fb2. Исходный код проекта доступен в репозитории на GitHub

Постановка

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

• Количество проданного товара за 1-ый квартал текущего года
• Сумма проданного товара в разрезе продавцов за прошлый год
• Динамика продаж определенного вида товара в ежемесячном срезе
• И многие др

При этом, если речь идет о холдинге, в который входят – магазины, рестораны, прочие виды деятельности, то количество данных возрастает, что так же ведет порой и к увеличению видов представлений аналитических данных.
Таким образом перед разработчиком встает проблема по предоставлению максимально широкого, эффективного и удобного инструмента для анализа данных. На помощь приходят OLAP решения, предлагаемые различными брендами, такими как Oracle, SAP, Microsoft, MicroStrategy, Pentaho и многие др.

Москва, 28 февраля 2014. Последняя возможность на привилегированных условиях (по цене на 35 % выгоднее майской!) пройти регистрацию на III Международную конференцию по системному и бизнес-анализу Analyst Days, которая состоится в Москве 24 мая 2014 года.

Доклад с прошлогодней конференции специалистов системного и бизнеса анализа — Analyst Days 2013 года от старшего аналитика питерского офиса компании DELL — Петрашева Дмитрия

На странице доклада можно найти презентацию и видео, а здесь текст…

Имея головной офис в США, наша команда заинтересовалась новостями международного аэропорта Ньюарка. Ньюарка, расположенный в черте городов Ньюарк и Элизабет (Нью-Джерси) аэропорт, находится в 24 километрах к юго-западу от нью-йоркского района Мидтаун. Ньарка – второй по величине аэропорт после аэропорта Хьюстон Интерконтинентал авиакомпании Continental Airlines.

И сегодня посетители терминала B в международном аэропорте Ньюарк Либерти могут заметить яркое, чистое освещение, интерьер аэропорта недавно дополнен 171 светодиодной лампой. Но посетители, вероятнее всего, не будет понимать, что эти светильники являются основой системы, которая за ними наблюдает.

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

Перевод pdf файла с сайта http://www.mcdonaldland.info/ с описанием 23-х шаблонов проектирования GOF. Каждый пункт содержит [очень] короткое описание паттерна и UML-диаграмму. Сама шпаргалка доступна в pdf, в виде двух png файлов (как в оригинале), и в виде 23-х отдельных частей изображений. Для самых нетерпеливых — все файлы в конце статьи.

Под катом — много картинок.

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

«Только со смертью догмы начинается наука.»
// Галилео Галилей

«Я начал завидовать рабам. Они всё знают заранее. У них твёрдые убеждения.»
// х/ф Марка Захарова «Убить дракона» по мотивам пьесы Евгения Шварца

Уже пару лет и дня не проходит, чтобы я не услышал (или не прочитал) от людей, начинающих новые проекты, фразу типа «Возьмем серверный движок для REST API и MVC, и погнали». Сначала я думал, что у этих слов есть один источник, может книжку какую завезли во все магазины или где-то в топе поисковиков лежит статья, зомбирующая разработчиков. Если же выяснять у них, что они понимают под REST и MVC, то можно повредиться умом. Ну с MVC уже все ясно, об этом я уже давно писал, ничего не изменилось, только усугубилось, стоит набрать в Google Images «mvc» и мы увидим страшное, стрелочки в любые стороны. Ну а про REST отвечают следующее: ну как же, нам нужно из браузерного GUI и мобильного приложения вызывать серверные методы, например: setUserCity(userId, cityId) или calculateMatrix(data) или startVideoConverter(options, source, destination) а потом мы столкнемся с большой нагрузкой и архитектура REST все решит. Дальше я задаю вопросы, от которых глаза округляются уже у тех, кто недавно еще горел праведной верой, рвался в бой и точно знал, что к чему в этом мире. Теперь можно перейти к рассмотрению терминологической катастрофы, в эпицентре которой мы с вами пребываем.

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

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

Что такое физический дизайн структур хранения

Основная цель, преследуемая в ходе разработки физической модели данных, — создание таких объектов для конкретной платформы/СУБД, которые позволят достигнуть максимальной производительности запросов/приложений, создающих основную нагрузку, сведя при этом дополнительные затраты, такие как необходимость поддерживать дополнительные индексы, выполнять материализацию производных данных и т. п., к минимуму.
Все реляционные СУБД построены на одних принципах, но каждой платформе присущи уникальные черты в виде наличия различных типов объектов и особенностей их реализации. По этой причине процесс физического моделирования является платформенно-зависимым, в отличие от логического моделирования, основная цель которого — достоверно описать данные и бизнес-процессы.

От B2C-порталов ожидается прежде всего масштабирование. К сожалению, масштабирование слишком часто объявляется вопросом Технологии — достаточно выбрать модную технологию и все проблемы решены. То, что это не так, может проявиться, позднее всего, уже в production mode (на рабочей системе).
Вместо того, чтобы махать технологической булавой, расскажу о том, как при помощи продуманной архитектуры и сознательного отказа от модели данных разработать высоко доступный (highly available), масштабируемый (scalable) портал. Первая часть опишет общие концепты, а возможные сценарии и их решения последуют.

Короткая предыстория

Беседовал я некоторое время назад со знакомым роботом. Устроился он временно на Почту России сортировщиком писем. Работёнка не пыльная, смотрит индекс на письме и помещает их в нужное отверстие. Но есть проблема с письмами, у которых в индексе сделана опечатка. На выяснение правильного индекса уходит много времени и пиво успевает выдыхаться.

Заноза в голове

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

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

Многие из нас сталкивались в своей работе с СУБД. На текущий момент базы данных в том или ином виде окружают нас повсюду, начиная с мобильных телефонов и заканчивая социальными сетями, в число которых входит и любимый нами хабр. Реляционные СУБД являются наиболее распространенными представителями семейства СУБД, и большинство из них являются транзакционными.
В институте нас заставляли заучивать определение ACID и стоящие за ним свойства, но почему-то стороной обходились подробности реализации этой парадигмы. В данной статье я постараюсь частично заполнить этот пробел, рассказав о MVCC, которая используется в таких СУБД как Oracle, Postgres, MySQL, etc. и является весьма простой и наглядной.

В недалеком прошлом на этом замечательном ресурсе была опубликована статья Разработка технического задания (ТЗ) на программный продукт с точки зрения заказчика. Статья — сама по себе неплохая — содержит, к сожалению, ряд неточностей, о которых следует упомянуть. Сделаем это в «один проход» по абзацам. По второму абзацу:

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

Уточнения:

1. Технические задания не пишут (составляют, подготавливают, оформляют и пр.), а разрабатывают, см. хотя бы п. 1.2 ГОСТ 34.602-89;
2. Если заказчик и исполнитель руководствуются требованиями ГОСТов, то совершенно противоположных мнений у них в принципе быть не может и не должно. Если же взаимодействие осуществляется «по понятиям» — как сейчас принято — то без «плюрализЬма мнений» тут, конечно, никак не обойтись.