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

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

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

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

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

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

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

Для такой операции, в MongoDB штатно предусмотрена функция $sample, которую можно использовать в составе pipeline при проведении агрегации данных. Однако, как показала практика, выполнение выборки полей таким образом на большой коллекции может занимать весьма ощутимое время. Чтобы сократить время выполнения таких выборок, потребовалось разработать собственный алгоритм, который на порядки увеличил скорость работы. Ниже приведен подход и вариант реализации данного алгоритма.

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

Сформулированная гипотеза выглядела так:

"Объемно-временные характеристики пакетов, принадлежащих к различным видам трафика, могут служить для его классификации".

Цель данной статьи - проверить, можно ли подтвердить эту гипотезу средствами Knime.

В предыдущей статье я вкратце упомянул, что Knime умеет работать с базами данных, в том числе с NoSQL базой MongoDB. На мой взгляд, MongoDB является довольно простым и эффективным решением для хранения информации, представленной в виде коллекций документов, состоящих из различных наборов полей и, по сути, являющихся обычными JSON файлами. Мне показалась интересным попробовать связку Knime - MongoDB в действии. Именно этой связке и посвящена данная статья.

Продолжение статьи об автоматизации создания комплектов проектных документов по ЕСКД и СПДС.

При выполнении проектов, в которых требуется разработка конструкторской документации соответствующей ГОСТам ЕСКД или СПДС, возникает много задач, связанных с ее корректным изготовлением. Часть этих задач связана с непосредственным оформлением документов – заполнением основных надписей, полей в форматных рамках документа. Другая часть задач связана с поддержанием связности информации в пределах комплекта документов -  единство используемых децимальных номеров, названий изделий, используемых в тексте наименований и тому подобных вещей. Такие задачи можно решать по разному, но автоматизация, безусловно, облегчит жизнь разработчику.

В данной статье, я расскажу о своем подходе к автоматизации такой работы на примере документов Word. Этот же подход применим и к Visio и к AutoCAD и к любому продукту, в котором предусмотрена возможность использования Visual Basic for Application (VBA).

Представим себе такие входные условия для решения:

в составе документации должны быть документы по ГОСТ 2.102, в том числе текстовые, оформленные с учетом ГОСТ 2.105, схемы по ГОСТ 2.701 и, не дай бог, что-то еще строительное по ГОСТ 21.101. А из инструментов есть только стандартный Microsoft Office, Microsoft Visio, Autodesk AutoCAD (это если бог был немилостив) и собственное желание оформить все как можно быстрее, лучше и не затрачивая усилий (то есть, в наличии имеется продуктивная лень).

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

А можно ли проанализировать эти примеры и выбрать интересующие нас используя при этом сам KNIME?

Можно! Давайте смотреть, как.