?

Log in

No account? Create an account
Лабораторный журнал -- Day [entries|friends|calendar]
Anatoly Levenchuk

[ website | Лабораторный журнал ]
[ userinfo | livejournal userinfo ]
[ calendar | livejournal calendar ]

Второе мая [02 May 2008|10:49am]
Впервые столкнулся с ограничением на число табов в браузере. Оказывается, у 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? Гармонизировать весь этот зверинец, подобрать софт, отработать техники внедрения...
2 comments|post comment

Процессы жизненного цикла системной инженерии, архитектура: ISO 15288 [02 May 2008|02:04pm]
Все эти новомодные понятия системной инженерии представляют собой явное введение в организационную практику современных парадигм создания рукотворных продуктов и сервисов -- через предписание следовать международным стандартам. Не знали вы, что такое жизненный цикл, так узнаете, когда вам в контракт впишут требование следовать 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), но далее действует замечание, что "все сложные системы стремительно становятся с существенной софтовой компонентой" -- и замышлять, проектировать, разрабатывать, эксплуатировать и выкидывать их нужно так же, как софт. "К чему бы ни прикоснулся компьютер, то само становится компьютером".
post comment

Ссылочки [02 May 2008|04:59pm]
Срочно закрываем все табы, пока все не подвисло.

Российское проектное управление задает образец для мирового сообщества: доклад Либерзона сотоварищи 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/

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

navigation
[ viewing | May 2nd, 2008 ]
[ go | previous day|next day ]