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

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

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

В какое прекрасное время мы живём! Вот пишешь ты программу и понадобилась тебе библиотека для чего-нибудь — она точно найдется! Многие библиотеки лежат в opensource и даже распространяются по приятным лицензиям типа LGPL, взял — и решил проблему. Делов-то: способ подключения описан в readme, библиотека предоставляет красивые интерфейсы, демка есть (она даже компилируется и работает). Вообще ООП со всеми его идеями абстракций, интерфейсов, инкапсуляции внутренних данных — мощнейшая штука (тут без иронии).

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


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

Примечание переводчика: представляю вниманию почтенной публики статью Якоба Энгблома (Jakob Engblom), в которой он демонстрирует внесение «аналогового» устройства в общем-то дискретный симулятор. Сам я также использую и разрабатываю модели для Simics, но с несколько других позиций, из-за чего редко вижу конечные плоды всей деятельности. Поэтому мне было очень интересно узнать, чем занимаются мои коллеги из Wind River, а затем захотелось поделиться с вами. Тех, кому тема полноплатформенной симуляции или конкретно Simics показались интересными, рекомендую обратить внимание на свежайший выпуск Intel Technology Journal Simics Unleashed – Applications of Virtual Platforms. Я также могу рассказать о Simics более детально и на Хабре в последующих своих постах. Жду ваших комментариев!

Встраиваемая вычислительная система редко работает в изоляции. Тогда как персональные компьютеры и потребительская электроника обычно могут работать самостоятельно с относительно нечастным вмешательством человека, большинство встроенных компьютеров тесно взаимодействуют с окружающим их миром. Они «чувствуют» его, исполняют управляющие алгоритмы, считывают показания датчиков, используют всевозможные актуаторы для того, чтобы изменять внешнюю среду. Они — активные участники непрерывно эволюционирующей кибер-физической реальности. Симуляция таких систем не может быть ограничена моделью изолированного цифрового компьютера — приходится вносить в неё часть физического мира. На следующем видео на Youtube демонстрируется, как это можно осуществить с помощью Wind River Simics.

Хочу задать этот вопрос Хабровчанам.

Современные информационные системы строятся на различных видах СУБД и все же реляционные СУБД остаются самыми распространенными и используемыми. Интересная статистика на эту тему ТУТ и ТУТ.


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

Объем ручного кода остается большим даже несмотря на

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

Главный вопрос руководства компаний при работе с внешними подрядчиками звучит так: как можно защитить свой проект от копирования? Рассмотрим оптимальные варианты ответа.

Каждый, кто начинает разрабатывать бизнес процессы в BPMN нотации, сталкивается с проблемой выбора оптимального инструмента. Даже когда этот инструмент спускается сверху (мы в нашей организации работаем только на …) или коллега советует программу (меня полностью устраивает …), очень хочется, чтобы огласили весь список, который поможет понять, что Вы сделали верный выбор, ну или, что существуют более эффективные инструменты, чем те, на которых Вы вынуждены работать.
Для разработки схем процессов в соответствии с нотацией BPMN наработано уже довольно много программ. Этот обзор – результат небольшого исследования рынка для поиска того программного продукта, которое можно будет использовать для работы. Обзор не претендует на полный анализ рынка и может быть использован для получения первичной информации. Следует иметь ввиду, что все рассматриваемые программы рассмотрены в первую очередь с точки зрения «рисования» процесса, без учета реального позиционирования этих программ на рынке. Основные возможности, которые востребованы в рамках рассматриваемого контекста и по которым оценивались программы, это:

• полнота и соответствие нотации BPMN 2.0;
• удобство разработки схем процессов в нотации BPMN 2.0 и скорость дизайна;
• возможность проверки схем и выгрузки результатов в общепринятых форматах.

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

О чем все это

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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