что такое spice модель

Node-SPICE: Моделирование переходных процессов в электрической сети

Всем привет! Сегодня я хочу рассказать об одном своем проекте, который создавался как один из инструментов получения данных для диссертации, и так как на данный момент он свою основную задачу выполнил, я хочу пустить его в GPLv3-плавание — быть может, он будет полезен кому-то еще. Однако перед тем, как отдать швартовы, я решил воспользоваться профилировщиком Intel Vtune Amplifier, чтобы убедиться в том, что мой пакет имитационного моделирования древовидной сети электроснабжения оптимально расходует вычислительные ресурсы компьютера.

Под катом подробности про себя, про проект и про оптимизацию производительности (которую за полчаса удалось повысить более, чем в два раза)

Введение

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

Представьте себе обычный асинхронный электродвигатель. Тысячи их. Выглядят так:

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

Так вот, замечали когда-нибудь, что если дома запускается старый холодильник, свет моргает? Этот эффект — фликер — возникает из-за того, что при пуске электродвигатель потребляет ток в 5-7 раз больше номинального. В самые первые моменты пуска намагничивание статора отсутствует, индуктивное сопротивление минимально и сеть фактически нагружается чисто довольно малым активным сопротивлением обмотки статора. Потом, когда двигатель начинает набирать обороты, статор намагничивается, реактивное сопротивление обмотки статора увеличивается и ток уменьшается.

А теперь представьте себе электрическую сеть предприятия:

Рис. 1 — Магистральные схемы питания электроприемников: а — с распределенными нагрузками; б — с сосредоточенными нагрузками; в — блок трансформатор — магистраль; 1 — распределительный щит подстанции; 2 — распределительный силовой пункт; 3 — электроприемник; 4 — магистраль; 5 — шинная сборка.

Это такая древовидная разветвленная электрическая сеть с множеством электроприемников. В обобщенном виде ее можно нарисовать вот так:

Рис. 2 — Обобщенная структурная схема питания электроприемников.

В схеме на рис. 2 узел Ve является точкой подключения источника питания сети(промышленная сеть переменного тока, судовой генератор, инвертор ветрогенератора и т.п.), в результате чего напряжение узла становится равным Ue. К источнику посредством активно-индуктивной питающей линии с сопротивлением Ze=Re+jLe, подключен распределительный узел V0 с напряжением U0, которое определяется как:

где I_ — ток потребляемый от узла Ve, который равен сумме токов, потребляемых нижестоящими нагрузками:

где N— число нагрузок, запитанных от данного узла. Для схемы на рис. 2 от узла Ve питаются все имеющиеся в системе узлы-нагрузки — V3 — V6. К узлу V1 подключены узлы-нагрузки V3, V4; а к узлу V2 узлы-нагрузки V5, V6 соответственно.

Зачем создавался Node-SPICE

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

Схему на рис. 2 Вполне себе можно нарисовать в пакете Matlab Simulink. Но есть одна загвоздка — если схема большая, или этих схем много, то рисовать каждую схему, запускать моделирование, снимать и сохранять результаты моделирования, графики переходных процессов, чертовски муторно, и решил я, что создать свой собственный моделлер будет быстрее (фигушки) и интереснее (а вот тут я был прав).

Для того, чтобы разработка была еще более интересной и полезной, я, суровый Сишник-железячник, в качестве языка разработки решил разобраться уже наконец с C++.

Установка

Исходники представляют собой проект Visual Studio 2013 и выложены на GitHub.
Для сборки приложения необходимо скачать библиотеку линейной алгебры Eigen и указать путь к папке с библиотекой с помощью системной переменной среды $(EIGEN_DIR). Visual Studio должна будет подхватить путь к этой папке и без особых шорохов скомпилировать приложение.

Для вывода и сохранения графиков приложение использует пакет gnuplot с модулем cairo — gnuplot должен уметь сохранять изображения в формате PNG. Проверить это можно выполнив в консоли gnuplot команду set terminal png. Gnuplot не должен ругаться на неверный аргумент — последним грешил gnuplot, идущий в комплекте с octave. Путь к gnuplot должен быть указан в $(PATH).

Архитектура приложения

Приложение должно было состоять из независимых друг от друга модулей(рис 3), но что-то пошло не так:

Рис. 3 — Структурная схема программы

Основными модулями системы являются:

Команда запуска выглядит следующим образом:

Формат конфигурационного файла — текстовый, состоящий из строк вида:

где a,b,c,d,e — ключи параметров, часть из которых (a, b) имеют булев тип данных — активную или неактивную опцию или режим. Другая часть, например c, d, e — имеющие текстовое или числовое значение параметра.

Конфигурационный файл, в котором в трехфазному источнику напряжения через анализатор качества подключен электромотор и несимметричная нагрузка выглядит следующим образом:

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

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

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

Общий вид команды load:

Существуют следующие общие для всех узлов ключи конфигурации:

Реализованые типы элементарных узлов Node:

Предполагается, что каждый рабочий стол представляет собой некую схему и должна существовать возможность создавать вложенные схемы, т. е. вложенные рабочие столы. Эта возможность заложена в тестовой версии программы(но, естественно, не реализована :)). Уникальные ключи для рабочего стола отсутствуют. Так как может существовать несколько рабочих столов, после введения второго и более рабочего стола для узлов следует указывать, к какому рабочему столу они относятся. Если ключ -wb не указать, то элементарный узел будет размещен на последнем созданном рабочем столе.

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

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

На рисунке 5 показан процесс моделирования источника напряжения без нагрузки:

Рис. 5 — Графики тока и напряжения источника напряжения, работающего в режиме холостого хода

Анализатор качества потребления включается в любой участок системы и анализирует различные параметры потребления. Данный узел отвечает за построение графиков.

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

Данный элементарный узел реализует математическую модель асинхронного электродвигателя.

На рисунке 6 показан процесс пуска асинхронного электродвигателя. В момент времени 1 с. к валу прикладывается момент 700 Н*м и двигатель переходит в рабочий режим.

Рис. 6 — Графики частоты вращения вала двигателя, а также момента на валу и статического момента при пуске двигателя

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

Моделируем кратковременное КЗ в сети:

КЗ 0,1 с. Скорость не успевает упасть ниже критической, двигатель восстанавливает скорость после снятия КЗ.

КЗ 0,5 с, двигатель успевает затормозиться и после включения момент двигателя становится меньше момента на валу и происходит аварийный останов двигателя

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

Оптимизация кода

Вообще, как оказалось в результате, сам основной процесс моделирования написан достаточно аккуратно и по результатам моделирования каких-либо архитектурных изменений сделано не было. Но дьявол кроется в деталях.
Открываем Intel Vtune Amplifier, создаем новый проект:

Указываем путь к нашей программе и ключи запуска. Неплохо будет воспользоваться кнопками Binary/Symbol Search и Source Search и указать пути к исходному коду и бинарникам с Debud-символами – потом будет удобнее перемещаться по проекту и исходному коду.

Используем следующий конфиг:

Все приведенные конфиг-файлы есть в папке /doc проекта.

Начнем с самого простого basic hotspot с интервалом 1ms

И запускаем.

Top Hotspots:

Святые нейтроны… Я конечно знал что iostream работает медленно, но чтобы настолько… Это, кстати, с отключением синхронизации с

20 секунд процессорного времени из общих 35 секунд. Больше 50% времени. Это не лезет ни в какие ворота.
Больше о том, насколько медленны потоки можно прочитать здесь. Имеет смысл переписать все на бронепаровозный fprintf(). Еще меня заинтересовало что в таблице функция cout фигурирует дважды. И точно — прослойка для gnuplot создает временные файлы, а потом удаляет их. Добавим ключик -raw к node для сохранения сырых файлов графиков. Есть ключи — сохранил, нет, не сохранил.
Запускаем профилировщик. Ха!

Top Hotspots:

В лидерах по-прежнему файловый вывод, но потребляющий уже меньше 5% процессорного времени. Серьезный успех! Смотрим Bottom-Up three

Второе и третье место занимают указатели и итераторы:

И что весьма логично — места достаются анализатору качества электроэнергии, ибо последний делает кучу всякой работы.

Данный код писался как проверка концепции скользящего режима измерений. Как видно из кода, каждый новый шаг солвера сопряжен со сдвигом небольшого (64-128 символов), но все же массива. Имеет смысл воспользоваться кольцевым буфером для решения данной задачи. Тогда операция добавления нового элемента будет иметь стоимость О(1) вместо О(N).

«Зачем это надо?» скажете вы, мол, анализатор качества один в системе, моторов лучше добавь в конфиг. И окажетесь наполовину правы — моторы мы обязательно добавим, вот только анализаторов в системе может быть ровно столько сколько в системе узлов — это фишка моей диссертации такая.
Глянем заодно что там такого с GetVoltage и GetCurrent нехорошего:

Хм, как насчет воспользоваться ссылками?

Top Hotspots:

Bottom-Up three показывает, что первый в списке опять таки наш fprintf и pango, вылезающий из-под gnuplot – в них лезть уже не будем (хотя стоило бы).

А что действительно радует, так это то что NewStep, от которого пара шагов до Solve вырвался в лидеры. Запустим моделирование на 40 секунд и посмотрим как изменится картина:

Эффект масштабируется, так что здесь нам пока делать нечего.

Подведем итог

Неплохо для получаса работы?
Добавим в систему пяток моторов:

Из Bottom-Up three мало что уже понятно:

Вот если заглянуть в Caller counter то можно увидеть куда деваются ресурсы. На решение матричных уравнений при расчете мат. модели электродвигателя — большую часть времени работает библиотека Eigen.

В библиотеку мы не полезем, лучше заменим моторы на rl-нагрузки. Они для меня намного важнее — можно создавать всякие разные перекосы фаз, КЗ, возмущения и прочие радости.

Так как на один тик толком считать ничего не надо, увеличим частоту тактирования солвера, да и нагрузок доведем до 10 штук.

Fprintf мы не трогаем, а вот основной виновник:

Здесь мы копируем векторы double[4] друг в друга. Как видно, копирование вектора средствами самого вектора не очень оптимально. Забабахаем-ка мы цикл — для 4-х элементов особо изгаляться не стоит:

И последний раз

Выводы:

А нету их. Я решил для себя, что негоже в OpenSource выкладывать тормозные приложения и посидел немножко с удобным и мощным инструментом профилирования. В отличие от расстановки таймстампов внутри кода, Vtune, что называется, «мордой тычет» в медленный код, намекая на то, что неплохо бы тот или иной кусок переписать.

Мое приложение, на самом деле, можно бесконечно оптимизировать — ибо костыль на костыле. Можно выкинуть Eigen и переписать Acmotor используя Boost, можно на том же Boost написать вывод графиков, можно переписать кучу мест используя векторные инструкции(здесь кстати будет кстати профилировщик Intel Advisor), переписать программу используя многопоточность(TBB, OpenMP, OpenCL) и т.д.

Кстати вот здесь можно получить бесплатную версию Intel parallel Studio для студенческих и обучающих нужд.

Источник

Не так сложен SPICE, как его написали

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

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

Попробуем схематически интерпретировать базовые элементы стандарта SPICE (Software Process Improvement Capability dEtermination), официально именуемого ISO/IEC TR 15504 — «Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем» [1]. В отличие от других стандартов ISO, он открыт (см. http://www.sqi.gu.edu.au/spice).

Стандартов, регламентирующих программные процессы и качество программ, а также способы их усовершенствования, довольно много. SPICE — попытка объединить наиболее значимые из них. Это, прежде всего ISO 12207, регламентирующий процессы жизненного цикла программного обеспечения; CMM, определяющий модель зрелости процесса разработки ПО; стандарты серии ISO 9000, рассматривающие проблемы управления качеством, а также ряд национальных стандартов и нормативов крупных компаний. В результате, несмотря на отсылки к смежным стандартам ISO, при уточнении деталей объем SPICE превысил 500 страниц. Если же учесть, что являющаяся сердцевиной стандарта модель программных процессов содержит перечни и таблицы в сотни пунктов, то становится понятно, почему его сторонятся менеджеры проектов.

Основные цели SPICE — помощь потребителям (заказчикам) программной продукции в выборе надежного поставщика и поддержка поставщика (разработчика) в его стремлении усовершенствовать процессы разработки. Для достижения поставленной цели предлагается оценить, как ведется работа. Оценка, в свою очередь, производится путем сравнения с эталонной моделью (фактически той же, но несколько менее детальной, что и в ISO 12207). Рассмотрим модель и оценочные показатели, на основе которых производится сравнение: это, с одной стороны, наиболее сложные, а с другой, ключевые для понимания стандарта в целом компоненты. Остальное в основном связано с установкой рейтингов, подбором команды оценщиков и т.п., все это наглядно и толково сопровождается иллюстративными примерами из жизни — и более связано с общими проблемами управления, чем со спецификой программирования.

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

Эталонная модель SPICE

Деятельность по созданию и приобретению программного продукта или услуги, в соответствии с эталонной моделью SPICE представляет собой взаимодействующие процессы без каких-либо ограничений на последовательность. Каждый процесс должен включать в себя некоторые базовые операции (base practice). Процессы оцениваются в зависимости от степени организации/управления:

Для того чтобы оценить уровень процесса, проверяется наличие у него некоторых общих свойств, формулируемых в терминах обобщенных операций (generic practice). Такая операция представляет собой действия, уместные для любого процесса: выполнение, планирование, фиксация состояния, подготовка методики, использование количественных оценок, обучение персонала распределение ответственности и т. п.

В SPICE заявлена наглядная форма, иллюстрирующая отношения процессов и их базовых операций к обобщенным операциям. Форма представляет собой таблицу, в столбцах которой размещаются категория процесса, потребитель, а в строках — уровень, общие свойства, обобщенная операция. Тот факт, что некоторый процесс X использует обобщенную операцию Y (крестик на пересечении соответствующего столбца и строки), означает наличие определенной базовой операции в этом процессе. К сожалению, в стандарте не дается заполненной таблицы. Вместо этого базовые операции приведены списками для соответствующих процессов. Ясное сопоставление базовых операций обобщенным отсутствует. Более того, некоторые из обобщенных операций вынесены в базовые операции служебных (supporting) процессов (документирование, управление конфигурациями и др.). По-видимому, исторически сложившийся и унаследованный из ранних стандартов список базовых операций не был упорядочен, в соответствии с позднее выдвинутой наглядной и компактной двумерной формой.

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

В качестве центральной может быть рассмотрена любая операция, как непосредственно связанная с разработкой программы, так и из окружающих ее слоев. Например, операция контроля требует документирования, обеспечения инструментом, ресурсами и т.д. Таким образом, предложенная модель определяет значительно более широкий спектр операций, чем список базовых операций SPICE; в частности, возможны стандарты на разработку стандартов или контроль операций контроля. На практике (особенно в начале упорядочения) вполне хватает и одной итерации.

Модель была бы более наглядной, если бы в качестве обобщенной операции была выделена операция «Обеспечение связи/коммуникации». Чрезвычайно важным свойством SPICE является то, что вслед за ISO 12207 в явной форме рассмотрены проблемы взаимоотношения различных сторон. Обсуждение контракта, приемка/сдача готового продукта, определение взаимоотношений между разработчиками, информирование об изменениях, а также многие другие операции являются конкретными формами реализации этой операции. Такого рода операции уместно отнести ко второму уровню возможностей.

Рабочие продукты SPICE

Основным инструментом оценки процессов в соответствии со SPICE являются их показатели (process indicators). Для оценки адекватности процесса или операции предлагается исследовать наличие и содержание рабочих продуктов (work product), составляющих его вход/выход. К сожалению, как список рабочих продуктов (состоит из 109 неупорядоченных пунктов), так и двадцатистраничная таблица соответствия «базовая операция — входные/выходные рабочие продукты» в SPICE представлены в неудобоваримом сложном виде.

Усугубляет ситуацию то, что часть из перечисляемых в общем списке рабочих продуктов носит конкретный характер, а другие представляют обобщенные свойства. В частности, имеется рабочий продукт под названием Рабочий продукт, а есть План вообще и конкретные планы. Для того чтобы понять, какие рабочие продукты используются в SPICE, разумно их классифицировать, причем классифицировать в двух смыслах: общеметодическом (разбить на группы) и в программистском (сопоставить общую структуру и единообразные механизмы работы с ними).

1. Инженерные рабочие продукты. Первую группу, очевидную для программистов, не сталкивавшихся с проблемами управления проектами, составляют инженерные рабочие продукты.

Целью разработки в соответствии со SPICE является создание Системы. Очень полезное свойство SPICE — явное разделение Системы и Программного продукта (Software). Собственно программный продукт составляет лишь часть Системы, в которую, кроме того, входит оборудование, персонал, средства инфраструктуры. Разработчики с советским стажем вспомнят соответствующие этому разделению стандарты на автоматические системы и программное обеспечение [2]. SPICE выделяет в целевые рабочие продукты некоторые части Системы (Компонент системы, Интегрированный программный продукт, Клиентская документация, Тестовый план клиентской документации).

Чтобы достичь поставленной цели, разработка (инженерные процессы) детализирует и формализует исходную информацию, закрепляя промежуточные результаты в рабочих продуктах озаглавленных Требования, Проект (Design) [Общий/Детальный(High/Low Level)].

В SPICE перечислены не все возможные инженерные рабочие продукты, причем это касается не только иерархии целевой Системы, представленной избранными компонентами, но и промежуточных документов. Например, выделяется Проект Базы данных (Database Design), но ничего не говорится относительно целевой Базы данных и относительно проектов, выделяемых компонентов Системы. Полную картину всех возможных инженерных продуктов может представить таблица, в строках которой перечисляются элементы иерархии целевой Системы, а в графах — уровни разработки (Требования, Проекты, Реализация). Клетки таблицы будут соответствовать возможным рабочим продуктам.

2. Управленческие рабочие продукты. Создание/приобретение программного продукта проводится группой людей в некоторые сроки с использованием определенного оборудования. Выделение работ, сроков, распределение между персоналом, обеспечение ресурсами — все это фиксируют управленческие рабочие продукты: Планы, Графики, Обязательства и пр. Рабочие продукты этого класса являются результирующими для операций, соотнесенных с обобщенными операциями Планирование, Определение ответственности, Распределение ресурсов.

3. Оперативные рабочие продукты. Оперативные рабочие продукты — документы, фиксирующие некоторые факты, в частности, как соотносится текущее состояние разрабатываемых продуктов и их окружения с ожидаемым, наличие дефектов, проблем, запросов на изменение, предложений, ответов и пр. В терминах SPICE — это, прежде всего, всевозможные Записи (Records), а также Отчеты (Reports), Протоколы собраний и др., которые можно рассматривать как агрегаты Записей. Запись содержит определенное число полей, большинство из которых имеет четко очерченный набор значений. Часть из них определяет контекст: дату, автора, ссылочные документы/продукты. Другие представляют оценочные значения, причем чтобы обеспечить однозначность в интерпретации (избежать сравнения «неплохой» с «нормальный») необходима нормативная регламентация используемых значений. С точки зрения обобщенных операций оперативные рабочие продукты, прежде всего, представляют результаты Контроля. Суть оперативных рабочих продуктов в передаче информации для сведения (принятия решения, исправления, ответа) от одного лица к другому (другим), а также ее фиксации (для памяти). Таким образом, они составляют предмет опеки для выделенных нами операций коммуникации.

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

5. Конфигурационные рабочие продукты. Состав сложных рабочих продуктов, история их изменения, а также информационные и причинно-следственные связи между ними задаются при помощи конфигурационных рабочих продуктов. Они озаглавливаются Список, Отображение (Mapping). С конфигурационными рабочими продуктами имеют дело не только операции Управления конфигурации в том смысле, в котором они упоминаются в SPICE, но и все операции, для которых существенен сложный состав рабочих продуктов.

6. Инструментальные рабочие продукты. В качестве входных/выходных продуктов для базовых операций в SPICE перечислен ряд инструментальных рабочих продуктов (инструментов): Коммуникационный механизм, Хранилище повторно используемых объектов, Средства управления конфигурациями. Представленный список, конечно же, не исчерпывает всех используемых в разработке инструментов, но выделяет наиболее важные с точки зрения оценки организованности проведения работ.

Перечислим отношения между рабочими продуктами: обобщение — конкретизация; целое — часть; исходный — результирующий документ операции; предыдущая — следующая версия/вариант; задание — результат выполнения задания; объект — результат контроля; методика — результат применения методики; инструмент — формируемый инструментом продукт.

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

С «продуктоцентрической» точки зрения (аналогичной «программированию от данных») большинство действий программных процессов формулируются как действия над рабочими продуктами:

Оставшиеся действия — это действия с персоналом (подбор, обучение, управление) и оборудованием (приобретение/подготовка и обеспечение работоспособности).

В операциях (в том числе, в базовых операциях SPICE) возможно присутствие нескольких действий при превалировании одного. Например, при создании некоторого продукта может выявиться наличие дефектов в исходных данных, что соответствует их контролю. Действия по разработке характерны для инженерных процессов, планированию, подготовке методик, инструментов. Их результат подвергается изменениям.

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

На рис. 2 представлены операции разработки и контроля, пунктиром отмечены отношения между рабочими продуктами.

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

Увы, многие программисты пользуются объектно-ориентированными языками значительно успешнее, чем языком естественным. Когда, пытаясь навести порядок в потоке экстремального программирования, менеджер проекта предлагает: «Иван, положи свой таск в прожект» (зафиксируй свое задание в проектном списке), Иван выдает текст, состоящий в основном из обернутых в приставки и суффиксы английских аббревиатур расширений файлов. А ведь его в школе учили: «Дано: — Требуется доказать:», и его задание должно быть сформулировано подобным же образом:

Исходный документ X версии N. Требуется скорректировать результирующий документ Y версии M, так чтобы он отвечал запросам на изменения Z1. Z2. Результирующий документ должен соответствовать стандарту S, версии K, а при его разработке должен использоваться инструмент I конфигурации IC версии J.

Выводы

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

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

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

Источник