Программно-инженерные аллюзии в системной инженерии - system-approach.ru

Программно-инженерные аллюзии в системной инженерии

21 октября 2013 г

APetrov

Знакомство не прошедших “боевого” крещения будущих программистов с основами системной инженерии имеет шанс на успех лишь при условии, что общий системноинженерный дискурс будет сопровождаться прицельно подобранными примерами применения (или демонстрацией неприменимости!) рассматриваемых концепций в сфере программной инженерии. Опыт показывает: с увеличением количества соответствующих примеров аудитория становится активнее, а вопросы — “правильнее”, да и звучат чаще.

К примеру, последовательную декомпозицию сложной инженерной системы прекрасно проиллюстрировал ряд “информационная система — подсистема хранения данных — система управления базой данных — библиотеки и утилиты — реализации алгоритмов“, анализ которого позволил установить, на сколько уровней “вниз” простирается область интересов системного архитектора, и насколько далеко “вверх” от уровня алгоритмов смотрит инженер-программист.

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

Системы связи и автоматики были названы как пример систем в операционном окружении, а служба обучения и поддержки операторов ИС — как пример обеспечивающей системы.

Обсуждение функционального описания систем с акцентом на невозможность разрешения ряда противоречий в требованиях заинтересованных сторон через переговорный процесс вывело на рассмотрение неустранимых конфликтов в архитектуре программных систем и CAP-теоремы как яркой иллюстрации таковых (осмысленный анализ и доказательство существования более простых на первый взгляд конфликтов: “гибкость — простота” и др., — увы, требуют подготовки в области объектно-ориентированного проектирования).

Обсуждение роли внешних и внутренних интерфейсов в организации систем привело к обсуждению модульности как критерия статического качества ПО, а через него — к разговору о статическом качестве программных систем вообще, роли стандарта ISO/IEC 9126 и модели SQuaRE в частности.

Инструментальное обеспечение системной инженерии в виде PLM-систем удалось успешно проиллюстрировать важным для будущих технических руководителей команд разработки классом ALM-систем и его самыми известными представителями (Eclipse Mylyn и др.). При обсуждении же поддерживающей практики управления изменениями и конфигурацией уместным оказался краткий обзор систем контроля версий (Apache Subversion,GitGoogle Code и др.), а также систем учета и контроля дефектов в ПО (SourceForge,Redmine и т.д.).

Наконец, классическим примером модели жизненного цикла производства системы, одновременно проявляющей каскадные и итеративные свойства, стал унифицированный процесс IBM RUP.

 

Ссылка на источник

Понравилась статья?

Получайте лучшие материалы на e-mail!