Re: Резюме
0. Я не забываю повторять свой тезис: я потратил в том самом помянутом зале битых пару часов, тыкая пальцем в табличку из трех слоёв (рисунок 5 из http://www.opengroup.org/archimate/doc/ts_archimate/chap3.html) и обращая внимание на невозможность формулирования архитектуры исходя только из средней полосочки applications (то есть софта). Я согласен, что это моё тыкание по большому счёту было проигнорировано -- но обсуждение функций (как критериев пригодности софта заявляемым целям) таки пошло. Но всё одно обидно, если даже вы не услышали моего многократного повторения тезиса про подчиненную организации работ ("бизнесу") роль софта, и неполноценность архитектурного описания с "чиста софовым содержанием" не услышали -- значит мне еще тренироваться и тренироваться в донесении этой мысли...
1. А вот тут я как раз был успешен: я сумел развернуть обсуждение к подробному рассмотрению функций. Функции же как раз и определяют систему, как "чёрный ящик" (в отличие от конструкции/механизма, которые определяют проектные решения, т.е. "белый ящик"). Это неважно, что функции рассматривались не сами по себе, а "в приложении к софтине". Главное, что список функций был обсуждён до конца (обсуждение шло еще и несколько часов второго дня). Это и есть работа по норме, явное выделение "чёрного ящика". Функции же не сводятся только к детальному описанию входящей и исходящей по интерфейсам информации и ее обработке, это только в IDEF0 "функции" так определяются.
И тут не нужно забывать мою оговорку, что в связи с сервис-ориентированным подходом потихоньку появляются методы, в которых явно говорится о важности рассмотрения "белого ящика" с самого начала -- но я еще не слишком с этим подходом разобрался (пункт 5 в http://ailev.livejournal.com/938820.html).
2. Я, вроде, специально написал этот пункт для разъяснения: зачем вводить понятие "коллизия", когда уже есть понятие "изменения". Помянутый вами опрос, конечно, показал непонимание. Вполне возможно, что нужно было больше уделять внимания разъяснению понятия "коллизия" -- доводя это разъяснение до уровня "лифтового теста" (т.е. умения разъяснить отличия "коллизий" и "изменений" за одноминутную поездку в лифте так, чтобы собеседник понял всё на 100%). Надеюсь, этот постинг чуть приблизил к такой цели.
3. Я бы отдельно объяснял про управление конфигурацией, отдельно про коллизии и управление изменениями. Ибо отсутствие в головах терминологии управления конфигурацией (прежде всего -- базис) и жизненного цикла (прежде всего -- понимание разнообразия видов жизненного цикла и методов разработки) приводят к невозможности обсуждения иных способов работы, кроме уже имеющихся и утвержденных допотопными ГОСТами докомпьютерной эпохи. Воевать с этими "писаными кровью уставами" сегодня -- это как воевать с уставами времен лошадей, стрел и луков во времена вертолётов и пулемётов. Время "писания уставов кровью" важно, и нужно не промахнуть мимо поворота.
Я соглашусь, что обсуждаемые в постинге вопросы затрагивают не только собственно системную инженерию и архитектуру, но и инженерный менеджмент. Но многосотстраничные учебники и по первой дисциплине, и по второй не засунешь в головы одномоментно. Нужно время...