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

О чем все это

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

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

Вот что входит в его обязанности (обобщённо) в избыточном варианте:

Тема поста навеяна новостью об очередной российской авиакатастрофе, на этот раз в Казани.

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

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

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

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

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

C тех пор как мы опубликовали это, нам не пришло больше ни одного вопроса о том, когда же выйдет диаграмма Ганта. Все понимали: ждать осталось совсем чуть-чуть. Злосчастную тысячу сердечек мы, конечно, так и не набрали, но диаграмму все же выпустили.

Выхода диаграммы Ганта действительно ждали все. Ждали практически 2 года — и пользователи, и отдел маркетинга, и руководство. В разделе отзывов и пожеланий для разработчиков TeamLab Gantt Chart давным давно стоит на первом месте с количеством голосов, перевалившем за 1000. Так почему же пришлось ждать так долго? В этот раз мы решили дать слово непосредственным участникам процесса.

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

Всем доброго пятничного дня!
Хотел бы рассказать немного о том, как создаются прототипы. Уверен что многие сталкивались с подобным и знают как это делается не по наслышке, вряд ли Вы почерпнете из этой статьи что-то новое для себя. Данная статья предназначена для тех кто только начинает свой путь в DIY (сделай сам) и призвана немного структурировать разрозненную информацию.

Разработка, Направленная на Создание Мусора

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

Главным продуктом РНСМ являются бессмысленности, написанные по столь «ценным» идеям: концепты, графики, описания дизайна и прочие продукты, создаваемые для одной лишь цели — быть выброшенными в корзину.

Это работает так:

ЦОАСУ (англ. GOMA — Goal oriented management automation) — это “Принципы, модели и методологии для анализа, проектирования и интеграции целеориентированных социально-экономических автоматизированных систем управления”. Задача ЦОАСУ — достичь максимально возможного уровня автоматизации; в идеале — полностью заменить людей машинами. Используя принципы ЦОАСУ люди способны создать системы подобные Скайнет или Матрице.

На самом деле не только о протоколах, а скорее о логике взаимодействия сложных систем. Это не BigData, конечно, но все равно есть над чем поломать голову и копья.



Еще в самом начале разработки, я грозился что буду рассказывать о ней в прямом эфире, чтобы любой читатель мог поучаствовать в этом занимательном процессе. И вот, время пришло. Прототип у нас почти готов, и мы сейчас занялись документацией для производства и для разработки сервера и мобильного приложения. И поняли, что прототип — это самое простое, и все те задачи, что мы решали в нем — это так, детский сад, штаны на лямках.
Вот вы задумались когда-нибудь, насколько сложная логика работает, когда вы отправляете твит или постите фотку? Ее не видно, в 99.9% она скрыта от пользователя, и ее совершенно незаметно. Я ее тоже не замечал, до того момента, когда мне пришлось проектировать ее самому.

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

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

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

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

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

Нет-нет, статья не про план резервного копирования. Статья про план «Б».
Поддавшись массовой истерии, решил я перейти в НПФ. (Нет! Статья не про НПФ!)
Почитал обзоры и рейтинги, выяснил, что разные источники без зазрения совести публикуют разную доходность по одним и тем же НПФ (опять отвлекаюсь)… и решил перевести в ХХХ24 (нет смысла обсуждать).

Прихожу в отделение, сижу с талончиком 1 час (один час) в очереди из трех человек, наконец попадаю на приём и выясняю, что «у нас сегодня система висит и почти не работает». (Вот! Вот про это статья.)
Ну что ж, я понимаю, бывает.
Через два дня, в эту пятницу, я прихожу в другое отделение ХХХ24 и уже совершенно без очереди узнаю, что у них тоже система «висит и не работает». И нет, без системы они не могут принять заявление.
— Как же так? — говорю — Все отделения что-ли не работают?
— Вот в понедельник ещё всё работало нормально. Вы приходите на следующей неделе.
Я даже на минуту задумался, когда у меня на следующей неделе будет возможность уйти с работы, чтобы прийти в банк, но тут же меня осенило:
— Нельзя в такой банк переводить свои деньги!

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

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

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

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

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

Введение

В один прекрасный день я получил по почте извещение о долге за горячую воду, по причине несвоевременного оповещения коммунальных служб о показаниях водомеров. К этому моменту я, праздного любопытства ради, осваивал WiFi радиомодуль от “Roving Networks” с целью «обучить» его дистанционно включать/отключать электрический водонагреватель для экономии электроэнергии при долгом отсутствии пользователей. И так все сошлось, что решил я свести эти задачи и еще некоторые задумки «умного дома» к практической реализации. Ну и конечно, было бы не интересно, если бы я использовал знакомые мне технологии, поэтому я решил использовать как можно больше нового и интересного.

Сейчас популярна тема онлайн-образования: все слышали про Coursera, Udacity, EdX. Это отличные образовательные платформы, содержащие много полезных курсов. Но можно ли их сделать более интеллектуальными? Вообще исследования по интеллектуальным обучающим системам (intelligent tutoring systems) ведутся давно и у ученых есть что предложить программистам-практикам. В этой статье в научно-популярной форме рассматриваются результаты и выводы, полученные научным сообществом, по построению конкретного вида интеллектуальных обучающих систем. Затрагиваются вопросы построения подсистем проверки решений задач, моделей обучаемого, алгоритмов управления учебным процессом.

Введение

Широко распространены обучающие программы с тестами, содержащими вопросы с вариантами выбора ответа, в числе которых один правильный, а остальные неверные, содержащие типичные ошибки. Теоретическую основу для создания подобных систем в 50-х гг. XX века разработали известный психолог Б.Ф. Скиннер и исследователь Н.А. Кроудер. Предложенные ими концепции неоднократно подвергались критике. В частности, критики отмечали, что контролироваться должны не только ответы, но и пути, ведущие к ним. Ну действительно, ведь главная цель обучения – не зазубривание правильных ответов, а формирование рациональных приемов решения типичных задач изучаемого предмета. Поэтому научная мысль пошла по новому пути. Во-первых, ученые начали создавать обучающие программы, способные распознать не только конечный ответ, но и оценить ход рассуждений обучаемого при выполнении задания (см. часть 1 этой статьи). Во-вторых, ученые начали разрабатывать средства измерения характеристик обучаемых, важных для управления процессом обучения (так называемые «модели обучаемого», см. часть 2) и алгоритмы управления учебным процессом (см. часть 3).

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

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

В конце 2012 года мне пришла в голову идея, что нельзя останавливаться на разработке системы только для транспортных средств, нужно мыслить шире. Так в системе появились новые узлы. Я их назвал: Машина, Дорога, Светофор, Сервер.

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

Итак, вы ☐ твитнули, ☐ написали в блог, ☐ опубликовали пресс-релиз, ☐ написали в комментариях о том, что знаете способ преодолеть CAP-теорему. Ваша идея не сработает. И вот почему:

☐ вы предполагаете, что сбоев софта\железа\сети никогда не случается
☐ вы на самом деле всего-лишь перенесли проблему на другой логический слой
☐ ваше решение эквивалетно одному уже существующему, которое не преодолевает CAP-теорему
☐ вы на самом деле построили AP-систему (доступность и устойчивость к разделению, но не постоянная согласованность данных)
☐ вы на самом деле построили CP-систему(согласованность данных и устойчивость к разделению, но не постоянная доступность)
☐ вы на самом деле построили нераспределенную систему

А особенно в ваших планах плохо следующее: