Автор: dmitryshm

Содержание других частей.

• Анонс и введение
• 1 этап (требования)
• 2 этап (требования)
• 3 этап (требования)
• 4 этап (пред. проект)
• 5 этап (пред. проект)
• 6 этап (ок. проект)
• 7 этап (ок. проект)

Первая статья из цикла про этапы разработки программного обеспечения, про его проектирование. Здесь и далее все этапы ICONIX про выстраивание полезного прироста (дельты) к программному обеспечению или системе. Напомню также согласно анонсу, что в качестве CASE-инструмента используется Sparx EA, хотя похожие работы могут выполняться и на других CASE-инструментах.

Первым этапом ICONIX при работе над нашей дельтой полезных изменений является моделирование предметной области. В руках есть CASE-инструмент и с самого начала всё, что мы можем сделать (если раньше этого не делали) — создать модель. В целом существует множество доменов моделирования. В используемом нами Sparx EA для первого этапа есть модель предметной области.

ICONIX, как упрощение RUP, на первом этапе предлагает сразу заняться моделированием предметной области. И в случае простых и средних по сложности программ и систем это смесь потоков работ бизнес-моделирования и моделирования требований. Моделирование предметной области является строго говоря этапом анализа требований, но если в проекте не было никакой бизнес-модели или как часто это бывает вообще никаких моделей, то придётся как раз при анализе требований в моделировании предметной области учитывать как бизнес так и требования технического характера.

В Sparx EA создайте пока пустую модель предментной области. Если работа происходит над существующим программным обеспечением или системой, и проект предполагает выстроить прирост относительно существующего, то сразу на первом этапе надо создавать не одну, в две модели. Первая модель — это модель предметной области того, как есть (As Is), а вторая модель предметной области того, как заказчик мыслит себе то, что должно получиться в ходе проделанной работы (To Be). И сначала валидируется с заказчиком As Is, а потом уже To Be, подсвечивая разницу между ними. Идеальной разницей будет добавление новых классов, а не изменение старых (принцип открытия-закрытия, среди прочих).

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

Каждая абстракция, создаваемая в модели предметной области ICONIX, является экземпляром класса UML, но т.к. созданная модель — это именно модель предметной области, то главными типами отношений между создаваемыми классами должны быть обобщение (generalization) и агрегирование (отношение целое-часть, аggregation).

Те из вас, кто уже всерьёз моделировал в UML могут задаться вопросом, не стоит ли модель предметной области связывать с прецедентами (Use Case — обсуждаются в стадующей статье). Сразу отвечу, что нет. В ICONIX намеренно начинают с модели предметной области с тем, чтобы при моделировании прецедентов рассматривать их уже в контексте объектной модели предметной области, связывая далее статические и динамические части.

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

Что всё же можно учесть в модели предметной области, так это возможное повторное использование. Классы в модели должны ясно описывать абстракции реального мира. Рекомендуется следовать методикам OMT (object modelling technique — техника объектного моделирования), когда начинают с ключевых объектов, а потом рассматривают, с какими ещё объектами они взаимодействуют. Источниками для модели предметной области являются различные высокоуровневые описания задачи от заказчика или записанное со слов заказчика. Кстати, такие записи можно делать в модели требований Sparx EA, например, сразу структурируя их. Существительные имеют большие шансы стать классами, а глаголы связями между ними.

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

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

Содержание других частей.

• Анонс и введение
• 1 этап (требования)
• 2 этап (требования)
• 3 этап (требования)
• 4 этап (пред. проект)
• 5 этап (пред. проект)
• 6 этап (ок. проект)
• 7 этап (ок. проект)

Анонсирую цикл статей про этапы разработки программного обеспечения, в особенности про его проектирование. Не буду особо останавливаться на важных стандатрах, например таких, как их комплекс ГОСТ 34 серии и прочих. Знание стандартов либо уже осознанно специалистом, либо ещё предстоит. Целью данной статьи является краткое описание RUP/ICONIX, активно применяемое у нас.

RUP/ICONIX используется как методология проектирования для небольших и средних проектов, сложность которых косвенно оценивается до 1 млн. строк кода и меньше. Для более сложных проектов рекомендуется RUP без упрощений. Модели строятся в Sparx EA, что позволяет генерировать документы, связанные с изменениями в проекте, выполнять обратный инжиниринг и многое из того, что упрощает работу по приведению документации, моделей и кода в соответствие друг другу. Читатель без труда выберет для себя удобный CASE-инструмент, кроме Sparx EA, т.к. описываемое здесь выполнимо и с другими инструментами.

Повествование в целом согласуется с методичкой «Применение объектного моделирования с использованием UML и анализ прецедентов на примере разработки книжного Internet-магазина» Кендалла Скотта и Дуга Розенберга. Хотя обстоятельное освоение UML как такового рекомендуется начать с «UML 2.0. Объектно-ориентированное моделирование и разработка» Джеймса Рамбо и М. Блаха.

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

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

Статьи будут полезными как для начинающих аналитиков, так и для тех, кто хочет укрепиться во владении своей профессией. Конечно же статьи также полезны и ИТ-архитекторам разных уровней. Любителям масала-диаграмм и проектирования на коленке в особенности рекомендуется прочесть анонсируемый материал, как возможность освоить профессию, пройдя от стадии отрицания до стадии принятия методологии и связанного с ней инструментария. Многим аналитикам на рынке труда, чья роль сводится сейчас к передаче слов заказчика с оформлением в Word и прикладыванием пары Visio-картинок на UML также очень рекомендуется к прочтению, т.к. у них появляется шанс всё-таки начать осваивать свою профессию.

С обилием отечественных операционных систем приходит обилие штатных репозиториев и нежелание переусложнять свои системы на ровном месте просто из-за того, что кто-то захотел поставить эту операционную систему, а не ту, которая поддерживается инженерами предприятия. Скажем, принято в компании пользоваться Astra Linux или Alt Linux, и значит желательно пользоваться дистрибутивами программного обеспечения именно под эту операционную систему. И далеко не всегда свободно распространяемый пакет (deb или rpm) сразу подходит. Это и разные системные окружения (например, версии базовых библиотек другие) и разные механизмы работы с пакетами (rpm для Alt Linux отличается от rpm для Red Hat).

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

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

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

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

Долой имитаторов, дорогу инноваторам!

Хотите открыть новые направления бизнеса?
Продвинуть проект, а внутренних ресурсов не хватает?
Привести в порядок процессы собственной разработки?
Начать то, до чего давно не доходят руки?

До 25 ноября для вас приготовлены БОНУСЫ.

Купон EXPCONS — 60% бонус для экспресс-консультации.
Купон CONS — 40% бонус для полноценной дневной консультации.

Пожалуйста обращайтесь!

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

Имеется участок кода на bash с определением функции, работающей с переменными.

#!/bin/bash

set -e

#
#  <Описание c параметрами>
#
function get_stats ()
{
    local CURL_COMMAND_URL="${VAR_ROOT_URL}api/jobs?return_timeout=${VAR_TIMEOUT_SECONDS}&fields=description"
    local CURL_RESULT="$(curl --silent -k "${CURL_COMMAND_URL}")"
    # <обработка ошибок 1>
    local JOB_RECORDS="$(echo "${CURL_RESULT}" | jq --raw-output --compact-output ".records[]")"
    # <обработка ошибок 2>
    while IFS= read -r VAR_JOB_OBJECT; do
        # формирование отчёта ...
    done <<< "${JOB_RECORDS}"
}

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

Так и происходит набор специалистов, например, на проектные работы.

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

Итак, вашему вниманию: экспресс консультации и экспресс требования.

Как-то ознакомился со списком докладов на JPoint 2024 и м.б. слишком привередлив, но не зацепило. Платить 42 килорубля за то, чтобы тебя хантили или за то, чтобы смотреть на все эти замечательные лица инженеров-программистов? Да этого и забесплатно навалом. Где-то в глубине души понимаю, что надо бы там появиться, но явную причину не вижу. Ведь из года в год одно и то же.