May 2nd, 2008

2019

Второе мая

Впервые столкнулся с ограничением на число табов в браузере. Оказывается, у Maxthon есть такой параметр! Решил параметр не менять, а закрыть десяток-другой уже ненужных.
* * *
Илларионов о Национальной Ассамблее -- http://www.kasparov.ru/material.php?id=4817869E328F5

Как я понимаю, основная идея состоит в том, чтобы выборы в России перестали быть похожими на выборы в СССР, от силовиков гражданами бы ожидалась защита, а не опасность (очень знаковый пост на эту тему -- http://meatreach.livejournal.com/264995.html). Только после этого можно было бы заниматься спорами про развитие рынка или закрытие рынка.

На этой Ассамблее пугает жуткая путаница между "все", "многие" и "некоторые", присутствующая во всех (многих, некоторых) ее текстах.
* * *
Architecture-Driven Modernization (ADM): Knowledge Discovery Meta-Model (KDM), v1.0 от OMG в ISO/IEC 19506. Нужно поглядеть, что это.
* * *
Доступен тьюториал по использованию COLA для создания языков -- на примере простого языка brainfuck: http://www.swa.hpi.uni-potsdam.de/tutorials/cola/index.html. Кто не знает еще про язык brainfuck -- им сюда 5
http://esoteric.voxelperfect.net/wiki/Brainfuck, http://en.wikipedia.org/wiki/Brainfuck. По факту это язык машины Тьюринга.
* * *
Купил Panasonic Lumix DMC-FX500, таскаю уже несколько дней. Вывод: по качеству изображения никакой разницы с предыдущими моделями. Эти 10Мпикс ничем не лучше 6Мпикс, которые были. Заявленная чувствительность до 6400 ISO -- маркетинговая обманка. Пятикратный зум -- дикий шум на длинном конце (125мм), автоматика резко поднимает чувствительность, чтобы убавить выдержку и снять шевеленку, поэтому вряд ли им хорошо пользоваться.

Существенная разница в тач-скрине, при помощи которого можно ткнуть пальцем в любой объект на экране, и аппарат сфокусируется именно на нем. И в легкости доступа к функциям типа приоритета диафрагмы или выдержки -- за счет того же тач-скрина. И в широком фокусе (от 25мм). И в 3" экране, вместо 2.5" (это оказалось очень заметно).

Пресловутое HD-видео (720p) по-прежнему без зуммирования во время съемки, и такое же шумное, как и все остальное -- может, на ярком солнце оно и будет хорошо, но никак не при квартирных съемках. И все-таки это HD, а не VGA.

Купил к аппарату SDHC на 16Гбайт. Странно видеть счетчик доступного места на более чем 3 тысячи кадров.

Вот думаю, отдать аппарат жене (которая нынче ботанег -- снимает все подряд желтые цветочки и потом определяет их названия -- в Москве, оказывается, тьма тьмущая разных желтых цветочков растет! Ну, и наш цветочек жизни регулярно попадает ей в кадр), или попользоваться самому. Попользуюсь, наверное, еще недельку-другую, поснимаю свои флипчарты, а потом таки отдам.
* * *
Французские мультфильмы оказались сравнимыми с аниме -- у их авторов тоже крыша свернута, хотя и в другую сторону, нежели у японцев.
* * *
Мы таки списались с голландцем, который занимается 15926+15288+DEMO. Для начала будем делать с ним семинар.
* * *
Уже понятно, куда выкручивать очередную версию PraxOS:
1. Системный подход к циклу жизни рукотворных продуктов и сервисов -- раскручивается через ISO 15288. Сюда же -- архитектурный заход, трассировка требований и т.д.
2. Поелику для системного инжиниринга требуется (был эксперимент) объединять до 22 моделей данных, то это делается через 15926 и его расширение Gellish (General Engineering Language).
3. Организации тоже инжинирятся, организационное моделирование -- DEMO.
4. Планирование и контроль выполнения планов: Lean Project Management и CCPM.
5. Инфраструктурные сервисы (похоже, что не только IT): ITIL.

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

Что делать в PraxOS? Гармонизировать весь этот зверинец, подобрать софт, отработать техники внедрения...
2019

Процессы жизненного цикла системной инженерии, архитектура: ISO 15288

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

Система -- это набор взаимодействующих частей, у которых есть цель. В системе явно вводится наблюдатель, с точки зрения которого выделяется интересующая-система (system-of-interest) и жесткое определение границ системы. Сервис -- это тоже система (или сервис производится системой). Обеспечивающая (enabling) система -- это система, которая пропихивает system-of-interest по этапам жизненного цикла (производственная система, ремонтная система для систем-продуктов и т.д.). Элементы системы могут быть описаны отдельно как системы, поэтому их можно заказать по контракту.

Все не так просто: этот заход существенно отличается от захода системной инженерии" стандарта ISO 26702, который описывает разработку системы, а не ее жизненный цикл. Впрочем, отличия описаны в самом тексте стандарта ISO 15288 (в приложении F).

Жизненный цикл -- эволюция системы, продукта, сервиса, проекта или другой сущности, порожденной людьми, от концепта до отхода ее от дел (life cycle -- the evolution of a system, product, service, project or other human-made entity from conception through retirement. [ISO/IEC 12207:2007 and ISO/IEC 15288:2007] ).

Модель жизненного цикла -- относящийся к жизненному циклу фреймворк процессов и действий (которые могут быть организованы по стадиям), который также действует как общая рекомендация для общения и понимания. (life cycle model -- a framework of processes and activities (which may be organized into stages) concerned with the life cycle, which also acts as a common reference for communication and understanding. [ISO/IEC 12207:2007 and ISO/IEC 15288:2007] )

"Каждая система, независимо от сорта или размера, следует какой-то модели жизненного цикла от ее начальной концептуализации до конечного отхода от дел. Проход системы в любой последовательности и любым способом через части модели, называется жизненным циклом. Модель жизненного цикла, тем самым, это концептуальное сегментирование определения нужды в системе, ее создания как продукта или сервиса, и ее использования, эволюции и выкидывания. Модель жизненного цикла системы обычно сегментирована на стадии, чтобы помочь планированию, обеспечению, функционированию и поддержке интересующей-системы. Эти сегменты обеспечивают упорядоченное продвижение системы через установленные барьеры принятия решений с целью уменьшить риск и убедиться в достаточности прогресса. Нужда принять решение согласно специфическому критерию перед тем как система сможет перейти на следующую стадию -- это наиболее важный довод для использования модели жизненного цикла" -- из проекта ISO TR 24748. Эти тексты невозможно адекватно перевести на русский язык!

Оттуда же (ISO TR 24748) -- апдейт процессного подхода. Процессы имеют собственника (ответственного за их выполнение), модульны (т.е. каждый процесс посвящен одной и только одной функции, а число интерфейсов между процессами держится минимальным. Функция процесса описывается как его специфическая цель, продукты/outcomes и набор действий). Процесс по ходу жизненного цикла может использовать другой процесс для специализированной функции. Каждый процесс вызывается из организационного фреймворка. Если процесс A вызывается процессом B, и только процессом B, то A принадлежит B. Если функция вызывается более чем одним процессом, то эта функция сама становится процессом. Должно быть возможным верифицировать любую функцию в модели жизненного цикла. Каждый процесс должен иметь внутреннюю структуру, достаточно определенную, чтобы быть выполнимым. Процесс должен быть описан так, чтобы к нему можно было применить стандарт проверки его выполнения ISO 15504.

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

Контрактации:
-- приобретения
-- поставки
Организационные, обеспечивающие проектность:
-- управления моделью жизненного цикла
-- управления инфраструктурой
-- управления портфелем проектов
-- управления человеческими ресурсами
-- управления качеством
Проектные (не-инжиниринговые):
-- Управления проектами
   -- Планирования проекта
   -- Оценки проекта и контроля
-- Поддержки проектов
   -- управления решениями (управленческими!)
   -- управления рисками
   -- управления конфигурацией
   -- управления информацией
   -- измерений (ISO 15937)
Технические (собственно работа, а не ее организация):
   -- Определения требований заинтересованных лиц
   -- Анализа требований
   -- Архитектурного проектирования
   -- изготовления
   -- Интеграции
   -- Верификации
   -- Перехода
   -- Валидации
   -- Функционирования
   -- Обслуживания
   -- устранения

Это не стадии жизненного цикла, это именно процессы. А стадии могут быть любыми, например:
Для системы (ISO 15288):
-- концепт
-- разработка
-- производство
-- эксплуатация
-- поддержка
-- вывод из эксплуатации
Для софта (ISO 12207):
-- концепт
-- разработка
-- сопровождение
-- вывод из эксплуатации
Для хардвера:
-- концепт
-- проектирование
-- изготовление
-- функционирование и обслуживание
-- вывод из эксплуатации
Для людей (ISO 18529):
-- определение скиллов
-- покупка
-- тренинг
-- использование скилов и приобретение опыта
-- увольнение
Для зданий:
-- эскиз
-- проектирование
-- получение разрешения
-- строительство
-- функционирование и обслуживание
-- вывод из эксплуатации
Для процессов:
-- определение продукта (output)
-- рисование прямоугольников и стрелочек (flowcharting)
-- оформление
-- пилотное использование
-- использование и улучшение
-- вывод из эксплуатации
Для естественных сущностей (вода, минералы и т.д.):
-- приобретение
-- разработка
-- эксплуатация
-- вывод из эксплуатации

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

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

Такая жесткая бюрократия наводится на все творчество криэйторов -- которые, конечно, взвывают от этого, но зато построенные ими мосты имеют много меньшую вероятность обвалиться, а весь цикл разработки занимает много меньше времени -- если учесть всю экономию от более простого внесения изменений в проект. Все эти требования стандарта просто отражают современную практику, и вряд ли могут быть реализованы без информационной модели целевой системы (system-of-interest).

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

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

Ссылочки

Срочно закрываем все табы, пока все не подвисло.

Российское проектное управление задает образец для мирового сообщества: доклад Либерзона сотоварищи 6 мая в Чикаго -- http://www.pmforum.org/blogs/news/2008/04/archibald-liberzon-mello-to-showcase.html

Отличия Spider Project от западных пакетов: http://www.spiderproject.ru/library/difference.ppt. Автоматически выбирать назначение на роли из пула скиллов они научились. И бригады у них есть. И поддержка самых уродливых форм российского нормирования работ ("объемы работ") -- есть. Есть "движение материалов" (что является шагом к моделированию производственных процессов). Сравнение версий проекта. Движение денежных средств. Анализ трендов (самый писк моды в измерениях!). И так далее -- огромный список. Критический ресурсный путь (сильно усложненный вариант критической цепочки) тоже есть.

Про ProChain я уже давал ссылку, но повторюсь: http://www.prochain.com/

Таинственные поставщики Gellish-браузера: http://www.steplib.com/Products/main.htm

Сайт по RM-ODP (The Reference Model of Open Distributed Processing, RM-ODP, ITU-T Rec. X.901-X.904 | ISO/IEC 10746) -- http://www.rm-odp.net/

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