Программно-инженерные аллюзии в системной инженерии
Знакомство не прошедших “боевого” крещения будущих программистов с основами системной инженерии имеет шанс на успех лишь при условии, что общий системноинженерный дискурс будет сопровождаться прицельно подобранными примерами применения (или демонстрацией неприменимости!) рассматриваемых концепций в сфере программной инженерии. Опыт показывает: с увеличением количества соответствующих примеров аудитория становится активнее, а вопросы — “правильнее”, да и звучат чаще.
К примеру, последовательную декомпозицию сложной инженерной системы прекрасно проиллюстрировал ряд “информационная система — подсистема хранения данных — система управления базой данных — библиотеки и утилиты — реализации алгоритмов“, анализ которого позволил установить, на сколько уровней “вниз” простирается область интересов системного архитектора, и насколько далеко “вверх” от уровня алгоритмов смотрит инженер-программист.
Функциональные и конструктивные элементы системы обратили взоры студентов к серверной стойке, шасси которой весьма кстати оказалось в аудитории. Внимательно присмотревшись, будущие системные инженеры обнаружили в составе оборудования электронные, электромеханические и даже тепломеханические элементы.
Системы связи и автоматики были названы как пример систем в операционном окружении, а служба обучения и поддержки операторов ИС — как пример обеспечивающей системы.
Обсуждение функционального описания систем с акцентом на невозможность разрешения ряда противоречий в требованиях заинтересованных сторон через переговорный процесс вывело на рассмотрение неустранимых конфликтов в архитектуре программных систем и CAP-теоремы как яркой иллюстрации таковых (осмысленный анализ и доказательство существования более простых на первый взгляд конфликтов: “гибкость — простота” и др., — увы, требуют подготовки в области объектно-ориентированного проектирования).
Обсуждение роли внешних и внутренних интерфейсов в организации систем привело к обсуждению модульности как критерия статического качества ПО, а через него — к разговору о статическом качестве программных систем вообще, роли стандарта ISO/IEC 9126 и модели SQuaRE в частности.
Инструментальное обеспечение системной инженерии в виде PLM-систем удалось успешно проиллюстрировать важным для будущих технических руководителей команд разработки классом ALM-систем и его самыми известными представителями (Eclipse Mylyn и др.). При обсуждении же поддерживающей практики управления изменениями и конфигурацией уместным оказался краткий обзор систем контроля версий (Apache Subversion,Git, Google Code и др.), а также систем учета и контроля дефектов в ПО (SourceForge,Redmine и т.д.).
Наконец, классическим примером модели жизненного цикла производства системы, одновременно проявляющей каскадные и итеративные свойства, стал унифицированный процесс IBM RUP.
Ссылка на источник